开源容器集群管理系统Kubernetes架构及组件介绍

共计 6920 个字符，预计需要花费 18 分钟才能阅读完成。

本文来源于 Infoq 的一篇文章（见参考部分），并在难懂的地方自己理解的基础上做了修改。实际在 Ubuntu 上部署 kubernetes 操作另见文章。

Together we will ensure that Kubernetes is a strong and open container management framework for any application and in any environment, whether in a private, public or hybrid cloud. –Urs Hölzle, Google

Kubernetes 作为 Docker 生态圈中重要一员，是 Google 多年大规模容器管理技术的开源版本，是产线实践经验的最佳表现。如 Urs Hölzle 所说，无论是公有云还是私有云甚至混合云，Kubernetes 将作为一个为任何应用，任何环境的容器管理框架无处不在。正因为如此，目前受到各大巨头及初创公司的青睐，如 Microsoft、VMWare、Red Hat、CoreOS、Mesos 等，纷纷加入给 Kubernetes 贡献代码。随着 Kubernetes 社区及各大厂商的不断改进、发展，Kuberentes 将成为容器管理领域的领导者。

接下来我们一起探索 Kubernetes 是什么、能做什么以及怎么做。

1. 什么是 Kubernetes

Kubernetes 是 Google 开源的容器集群管理系统，使用 Golang 开发，其提供应用部署、维护、扩展机制等功能，利用 Kubernetes 能方便地管理跨机器运行容器化的应用，其主要功能如下：

使用 Docker 对应用程序包装(package)、实例化(instantiate)、运行(run)。
以集群的方式运行、管理跨机器的容器。
解决 Docker 跨机器容器之间的通讯问题。
Kubernetes 的自我修复机制使得容器集群总是运行在用户期望的状态。

当前 Kubernetes 支持 GCE、vShpere、CoreOS、OpenShift、Azure 等平台，除此之外，也可以直接运行在物理机上。

这个官方给出的完整的架构图：（可放大看）

开源容器集群管理系统 Kubernetes 架构及组件介绍

2. Kubernetes 的主要概念

2.1 Pods

在 Kubernetes 系统中，调度的最小颗粒不是单纯的容器，而是抽象成一个 Pod，Pod 是一个可以被创建、销毁、调度、管理的最小的部署单元。把相关的一个或多个容器（Container）构成一个 Pod，通常 Pod 里的容器运行相同的应用。Pod 包含的容器运行在同一个 Minion(Host)上，看作一个统一管理单元，共享相同的 volumes 和 network namespace/IP 和 Port 空间。

2.2 Services

Services 也是 Kubernetes 的基本操作单元，是真实应用服务的抽象，每一个服务后面都有很多对应的容器来支持，通过 Proxy 的 port 和服务 selector 决定服务请求传递给后端提供服务的容器，对外表现为一个单一访问地址，外部不需要了解后端如何运行，这给扩展或维护后端带来很大的好处。

这一点 github 上的官网文档 services.md 讲的特别清楚。

2.3 Replication Controllers

Replication Controller，理解成更复杂形式的 pods，它确保任何时候 Kubernetes 集群中有指定数量的 pod 副本 (replicas) 在运行，如果少于指定数量的 pod 副本(replicas)，Replication Controller 会启动新的 Container，反之会杀死多余的以保证数量不变。Replication Controller 使用预先定义的 pod 模板创建 pods，一旦创建成功，pod 模板和创建的 pods 没有任何关联，可以修改 pod 模板而不会对已创建 pods 有任何影响，也可以直接更新通过 Replication Controller 创建的 pods。对于利用 pod 模板创建的 pods，Replication Controller 根据 label selector 来关联，通过修改 pods 的 label 可以删除对应的 pods。Replication Controller 主要有如下用法：

Rescheduling
如上所述，Replication Controller 会确保 Kubernetes 集群中指定的 pod 副本 (replicas) 在运行，即使在节点出错时。

Scaling
通过修改 Replication Controller 的副本 (replicas) 数量来水平扩展或者缩小运行的 pods。

Rolling updates
Replication Controller 的设计原则使得可以一个一个地替换 pods 来滚动更新（rolling updates）服务。

Multiple release tracks
如果需要在系统中运行 multiple release 的服务，Replication Controller 使用 labels 来区分 multiple release tracks。

以上三个概念便是用户可操作的 REST 对象。Kubernetes 以 RESTfull API 形式开放的接口来处理。

2.4 Labels

service 和 replicationController 只是建立在 pod 之上的抽象，最终是要作用于 pod 的，那么它们如何跟 pod 联系起来呢？这就引入了 label 的概念：label 其实很好理解，就是为 pod 加上可用于搜索或关联的一组 key/value 标签，而 service 和 replicationController 正是通过 label 来与 pod 关联的。为了将访问 Service 的请求转发给后端提供服务的多个容器，正是通过标识容器的 labels 来选择正确的容器；Replication Controller 也使用 labels 来管理通过 pod 模板创建的一组容器，这样 Replication Controller 可以更加容易，方便地管理多个容器。

如下图所示，有三个 pod 都有 label 为 ”app=backend”，创建 service 和 replicationController 时可以指定同样的 label:”app=backend”，再通过 label selector 机制，就将它们与这三个 pod 关联起来了。例如，当有其他 frontend pod 访问该 service 时，自动会转发到其中的一个 backend pod。

开源容器集群管理系统 Kubernetes 架构及组件介绍

3. Kubernetes 构件

Kubenetes 整体框架如下图，主要包括 kubecfg、Master API Server、Kubelet、Minion(Host)以及 Proxy。

开源容器集群管理系统 Kubernetes 架构及组件介绍

3.1 Master

Master 定义了 Kubernetes 集群 Master/API Server 的主要声明，包括 Pod Registry、Controller Registry、Service Registry、Endpoint Registry、Minion Registry、Binding Registry、RESTStorage 以及 Client, 是 client(Kubecfg)调用 Kubernetes API，管理 Kubernetes 主要构件 Pods、Services、Minions、容器的入口。Master 由 API Server、Scheduler 以及 Registry 等组成。从下图可知 Master 的工作流主要分以下步骤：

Kubecfg 将特定的请求，比如创建 Pod，发送给 Kubernetes Client。
Kubernetes Client 将请求发送给 API server。
API Server 根据请求的类型，比如创建 Pod 时 storage 类型是 pods，然后依此选择何种 REST Storage API 对请求作出处理。
REST Storage API 对的请求作相应的处理。
将处理的结果存入高可用键值存储系统 Etcd 中。
在 API Server 响应 Kubecfg 的请求后，Scheduler 会根据 Kubernetes Client 获取集群中运行 Pod 及 Minion 信息。
依据从 Kubernetes Client 获取的信息，Scheduler 将未分发的 Pod 分发到可用的 Minion 节点上。

开源容器集群管理系统 Kubernetes 架构及组件介绍
下面是 Master 的主要构件的详细介绍。

Minion Registry 负责跟踪 Kubernetes 集群中有多少 Minion(Host)。Kubernetes 封装 Minion Registry 成实现 Kubernetes API Server 的 RESTful API 接口 REST，通过这些 API，我们可以对 Minion Registry 做 Create、Get、List、Delete 操作，由于 Minon 只能被创建或删除，所以不支持 Update 操作，并把 Minion 的相关配置信息存储到 etcd。除此之外，Scheduler 算法根据 Minion 的资源容量来确定是否将新建 Pod 分发到该 Minion 节点。

可以通过 curl http://{master-apiserver-ip}:4001/v2/keys/registry/minions/ 来验证 etcd 中存储的内容。

Pod Registry 负责跟踪 Kubernetes 集群中有多少 Pod 在运行，以及这些 Pod 跟 Minion 是如何的映射关系。将 Pod Registry 和 Cloud Provider 信息及其他相关信息封装成实现 Kubernetes API Server 的 RESTful API 接口 REST。通过这些 API，我们可以对 Pod 进行 Create、Get、List、Update、Delete 操作，并将 Pod 的信息存储到 etcd 中，而且可以通过 Watch 接口监视 Pod 的变化情况，比如一个 Pod 被新建、删除或者更新。

Service Registry 负责跟踪 Kubernetes 集群中运行的所有服务。根据提供的 Cloud Provider 及 Minion Registry 信息把 Service Registry 封装成实现 Kubernetes API Server 需要的 RESTful API 接口 REST。利用这些接口，我们可以对 Service 进行 Create、Get、List、Update、Delete 操作，以及监视 Service 变化情况的 watch 操作，并把 Service 信息存储到 etcd。

Controller Registry 负责跟踪 Kubernetes 集群中所有的 Replication Controller，Replication Controller 维护着指定数量的 pod 副本 (replicas) 拷贝，如果其中的一个容器死掉，Replication Controller 会自动启动一个新的容器，如果死掉的容器恢复，其会杀死多出的容器以保证指定的拷贝不变。通过封装 Controller Registry 为实现 Kubernetes API Server 的 RESTful API 接口 REST，利用这些接口，我们可以对 Replication Controller 进行 Create、Get、List、Update、Delete 操作，以及监视 Replication Controller 变化情况的 watch 操作，并把 Replication Controller 信息存储到 etcd。

Endpoints Registry 负责收集 Service 的 endpoint，比如 Name：”MySQL”，Endpoints: [“10.10.1.1:1909″，”10.10.2.2:8834”]，同 Pod Registry，Controller Registry 也实现了 Kubernetes API Server 的 RESTful API 接口，可以做 Create、Get、List、Update、Delete 以及 watch 操作。

Binding 包括一个需要绑定 Pod 的 ID 和 Pod 被绑定的 Host，Scheduler 写 Binding Registry 后，需绑定的 Pod 被绑定到一个 host。Binding Registry 也实现了 Kubernetes API Server 的 RESTful API 接口，但 Binding Registry 是一个 write-only 对象，所有只有 Create 操作可以使用，否则会引起错误。

Scheduler 收集和分析当前 Kubernetes 集群中所有 Minion 节点的资源 (内存、CPU) 负载情况，然后依此分发新建的 Pod 到 Kubernetes 集群中可用的节点。由于一旦 Minion 节点的资源被分配给 Pod，那这些资源就不能再分配给其他 Pod，除非这些 Pod 被删除或者退出，因此，Kubernetes 需要分析集群中所有 Minion 的资源使用情况，保证分发的工作负载不会超出当前该 Minion 节点的可用资源范围。具体来说，Scheduler 做以下工作：

实时监测 Kubernetes 集群中未分发的 Pod。
实时监测 Kubernetes 集群中所有运行的 Pod，Scheduler 需要根据这些 Pod 的资源状况安全地将未分发的 Pod 分发到指定的 Minion 节点上。
Scheduler 也监测 Minion 节点信息，由于会频繁查找 Minion 节点，Scheduler 会缓存一份最新的信息在本地。
最后，Scheduler 在分发 Pod 到指定的 Minion 节点后，会把 Pod 相关的信息 Binding 写回 API Server。

3.2 Kubelet

开源容器集群管理系统 Kubernetes 架构及组件介绍
根据上图可知 Kubelet 是 Kubernetes 集群中每个 Minion 和 Master API Server 的连接点，Kubelet 运行在每个 Minion 上，是 Master API Server 和 Minion 之间的桥梁，接收 Master API Server 分配给它的 commands 和 work，与持久性键值存储 etcd、file、server 和 http 进行交互，读取配置信息。Kubelet 的主要工作是管理 Pod 和容器的生命周期，其包括 Docker Client、Root Directory、Pod Workers、Etcd Client、Cadvisor Client 以及 Health Checker 组件，具体工作如下：

通过 Worker 给 Pod 异步运行特定的 Action
设置容器的环境变量
给容器绑定 Volume
给容器绑定 Port
根据指定的 Pod 运行一个单一容器
杀死容器
给指定的 Pod 创建 network 容器
删除 Pod 的所有容器
同步 Pod 的状态
从 cAdvisor 获取 container info、pod info、root info、machine info
检测 Pod 的容器健康状态信息
在容器中运行命令。

3.3 Proxy

Proxy 是为了解决外部网络能够访问跨机器集群中容器提供的应用服务而设计的，运行在每个 Minion 上。Proxy 提供 TCP/UDP sockets 的 proxy，每创建一种 Service，Proxy 主要从 etcd 获取 Services 和 Endpoints 的配置信息（也可以从 file 获取），然后根据配置信息在 Minion 上启动一个 Proxy 的进程并监听相应的服务端口，当外部请求发生时，Proxy 会根据 Load Balancer 将请求分发到后端正确的容器处理。

所以 Proxy 不但解决了同一主宿机相同服务端口冲突的问题，还提供了 Service 转发服务端口对外提供服务的能力，Proxy 后端使用了随机、轮循负载均衡算法。关于更多 kube-proxy 的内容 KUBERNETES 代码走读之 MINION NODE 组件 KUBE-PROXY。

4. etcd

etcd 在上面架构图上提到过几次，但它并不是 kubernetes 的一部分，它是 CoreOS 团队发起的一个管理配置信息和服务发现（service discovery）项目，目标是构建一个高可用的分布式键值（key-value）数据库。与 kubernetes 和 docker 一样还是在快速迭代开发中的产品，没有 ZooKeeper 那样成熟。有机会再另外通过文章介绍。

参考