Kubernetes系统架构简介

时间 2019-11-10

原文原文链接

Kubernetes系统架构简介mysql

【摘要】

Together we will ensure that Kubernetes is astrong and open container management framework for any application and in anyenvironment, whether in a private, public or hybrid cloud.git

Urs Hlzle, Googlegithub

Kubernetes做为Docker生态圈中重要一员，是Google多年大规模容器管理技术的开源版本。如Urs Hlzle所说，不管是共有云仍是私有云甚至混合云，Kubernetes将做为一个为任何应用，任何环境的容器管理框架无处不在。正由于如此，目前受到各大巨头及初创公司的青睐，如Microsoft、VMWare、Red Hat、CoreOS、Mesos等，纷纷加入给Kubernetes贡献代码。随着Kubernetes社区及各大厂商的不断完善、改进、发展，Kuberentes将成为容器管理领域的领导者。算法

接下来本文会对Kubernetes的主要概念、MasterAPI Server、Kubelet、Proxy构件的详细介绍，后期用一系列文章带领你们逐一详细地探索Kubernetes的深层原理。sql

1. 什么是Kubernetes

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

使用Docker对应用程序包装(package)、实例化(instantiate)、运行(run)。后端
以集群的方式运行、管理跨机器的容器。缓存
解决Docker跨机器容器之间的通信问题。安全
Kubernetes的自我修复机制使得容器集群老是运行在用户指望的状态。网络

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

2. Kubernetes主要概念

2.1. Pods

Pod是Kubernetes的基本操做单元，把相关的一个或多个容器构成一个Pod，一般Pod里的容器运行相同的应用。Pod包含的容器运行在同一个Minion(Host)上，看做一个统一管理单元，共享相同的volumes和network namespace/IP和Port空间。

2.2. Services

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

2.3. Replication Controllers

ReplicationController确保任什么时候候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

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

Scaling

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

Rolling updates

ReplicationController的设计原则使得能够一个一个地替换pods来rolling updates服务。

Multiple release tracks

若是须要在系统中运行multiplerelease的服务，Replication Controller使用labels来区分multiple release tracks。

2.4. Labels

Labels是用于区分Pod、Service、ReplicationController的key/value键值对，Pod、Service、 Replication Controller能够有多个label，可是每一个label的key只能对应一个value。Labels是Service和ReplicationController运行的基础，为了将访问Service的请求转发给后端提供服务的多个容器，正是经过标识容器的labels来选择正确的容器。一样，Replication Controller也使用labels来管理经过pod 模板建立的一组容器，这样Replication Controller能够更加容易，方便地管理多个容器，不管有多少容器。

3. Kubernetes构件

Kubenetes总体框架以下图3-1，主要包括kubecfg、Master APIServer、Kubelet、Minion(Host)以及Proxy。

图3-1 KubernetesHigh Level构件

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等组成。从下图3-2可知Master的工做流主要分如下步骤：

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

下面是Master的主要构件的详细介绍：

图3-2 Master主要构件及工做流

3.1.1. Minion Registry

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节点。

3.1.2. Pod Registry

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

3.1.3. Service Registry

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。

3.1.4. Controller Registry

ControllerRegistry负责跟踪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。

3.1.5. Endpoints Registry

EndpointsRegistry负责收集Service的endpoint，好比Name："mysql"，Endpoints: ["10.10.1.1:1909"，"10.10.2.2:8834"]，同PodRegistry，Controller Registry也实现了Kubernetes API Server的RESTful API接口，能够作Create、Get、List、Update、Delete以及watch操做。

3.1.6. Binding Registry

Binding包括一个须要绑定Pod的ID和Pod被绑定的Host，Scheduler写BindingRegistry后，需绑定的Pod被绑定到一个host。Binding Registry也实现了Kubernetes API Server的RESTful API接口，但Binding Registry是一个write-only对象，全部只有Create操做可使用，不然会引发错误。

3.1.7. Scheduler

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。
Kubelet

图3-3 Kubernetes详细构件

根据上图3-3可知Kubelet是Kubernetes集群中每一个Minion和Master APIServer的链接点，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的容器健康状态信息。
在容器中运行命令。
Proxy

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

4. 下篇主题

下篇讲述在CentOS7上用Kubernetes来管理容器。