Kubernetes的核心概念讲解_语言 & 开发_Tom Gallacher



 写点什么

入门 Kubernetes 是非常困难的，因为这会涉及到许多的概念和新理念，本文以图文并茂的形式总结了 Kubernetes 中的核心概念。

它本不必如此困难？

掌握 Kubernetes 是非常困难的，因为互联网上有如此多的信息，有时候很难找到理解 Kubernetes 的“核心”信息，当我们看到kubernetes.io站点上概念页面和文档如此密集时更会如此。在本文中，我们将会探索 Kubernetes 的核心概念，以便于获取关于它的基础知识，这样我们就可以一起揭开 Kubernetes 的神秘面纱。

什么是 Kubernetes？

Kubernetes 提供了基础设置和构造，帮助我们的团队构建适用于开发和部署的可用平台。用户可以通过图形化的用户界面以及命令式和声明式命令行接口管理 Kubernetes 集群，Kubernetes 旨在管理容器化应用程序和服务的整个生命周期。

借助 Kubernetes，我们可以扩展和收缩应用程序、执行滚动部署并管理由哪些服务处理特定的请求。它还提供了一个可扩展的开发框架，允许我们的团队扩展核心的 Kubernetes 原语（primitive）以满足个性化的需求。同时，它还支持创建自己的概念。

但是，与大多数框架一样，它的缺点之一是缺少许多现成的功能，无法被视为交钥匙（turn-key）解决方案。在标准发行版中，它不包含服务如何相互通信的方法（甚至不包含网络组件!），因此存在其他的发行版，另外我们也可以构建自己的版本。

容器

容器是独立、可执行的软件，它包含了运行所需的所有内容，比如代码、库和所有的外部依赖。它会确保运行的内容是完全相同的，即便是位于不同的环境中也是如此。这是通过将要运行的代码与它的运行上下文隔离开实现的。

在 Linux 中，这是通过使用名为 cgroups 的 API 来分割 Linux 内核的一个子集来实现的。这种方式提供了与操作系统的高度隔离，但不会带来像虚拟化环境（如 VMWare、KVM 等）那样的性能损耗。

Pod

pod 是 Kubernetes 中最基本的对象。

pod 是容器的集合，它们共享存储和网络，并且具备如何运行它们的规范。每个 pod 会分配自己的 IP 地址。pod 中的容器会共享这个 IP 地址、端口空间，并且能够使用 localhost 实现彼此查找。

pod 应该被视为短暂存活的原子单元。

Replicaset

根据给定的模板，replicaset 可以运行 n 个 pod。

replicaset 并不会直接使用，但是需要理解这种资源，因为在 Kubernetes 构建应用的时候，它是基础的构建块。

（按照指令）replicaset 可以按需扩展和收缩 pod 的数量。

Service

因为 pod 是短期存活的（replicaset 通过扩展和收缩 pod 的数量实现这一点），那么这就带来了一个问题，现在，除非使用非常复杂的逻辑，否则我们几乎不可能引用单个 pod 以便于跟踪拓扑结构的变化。

Service 通过在 pod 之上提供抽象来解决这个问题，它提供了一个可寻址的方法来与 pod 进行通信。

Service 操作的是 OSI 模型之中的“第 4 层”（IP 之上的 TCP/UDP）。

Deployment

Deployment 管理 replicaset，可以在应用的不同版本间执行滚动更新。

这是最常用的资源类型，它通过一个接口提供了对 replicaset 和 pod 的抽象。

在更新 Deployment 的时候，换句话说，也就是部署应用的新版本，Deployment 控制器会创建一个新的 replicaset，并管理新版本替换旧版本的滚动更新。

在 Kubernetes 1.11 版本中，Deployment 目前不会自动处理回滚。

ConfigMap

设计良好的应用应该遵循十二要素应用宣言，应用的配置应该保存到“环境”中。尽管现在通用的安全实践指出，在环境中存储配置可能会导致私密的意外泄漏，因为一些应用程序在失败时会暴露了它们的环境信息，但是无论如何，如果配置随环境（开发、staging、生产）而变化的话，那么就应该将它们与要构建的应用分开进行存储。

ConfigMaps 允许将配置文件作为环境变量或文件系统挂载到 Pod 中，从而解决了这个问题。