Kubernetes工作流程分析

总流程

image

以deployment为例，分析一下Kubernetes提交一个Deployment YAML文件后的工作流程

1. 准备好一个Deployment的YAML文件，然后通过kubectl发送到Api Server
2. ApiServer接收到客户端的请求并将资源内容存储到数据库etcd中
3. Controller组件（包括Scheduler、replication、endpoint）监控资源变化并做出反应
4. ReplicaSet检查数据库变化，创建期望数量的Pod实例
5. Scheduler再次检查数据库变化，发现尚未被分配到具体节点的Pod，然后根据一组相关规则将Pod分配到可以运行它们的节点上，并更新数据库记录，记录Pod分配情况
6. Kubelet监控数据库变化，管理后续Pod生命周期，发现被分配到它所在节点上运行的那些Pod。如果发现新Pod，则会在该节点上运行这个新Pod
7. kubeproxy运行在集群各个主机上，管理网络通信，服务发现，负载均衡。当有数据发送到主机时，其将路由到正确的pod或容器，对于主机上发出的数据，它可以基于请求地址发现远程服务器，并将数据正确路由，在某些情况下会使用轮询调度算法将请求发送到集群中的多个实例

Api Server的工作

当YAML文件被提交到Api Server后

首先，Api Server会过滤这个请求，并完成一些前置性工作，比如授权、超时、处理、审计等。

然后，进入MUX和Routes流程。MUX和Routes要做的就是完成URL和Handler绑定的场所。Handler则是按照/api(apis)/Groups/Version/Resource，对于Deployment来说则是/api/v1/deployments（node、pod、deployment是“ ”）找到Deployment类型的定义

接着，Api Server会根据这个Deployment类型的定义，使用用户提交的YAML文件里的字段，创建一个CronJob对象。在这个过程中，API Server会进行一个Convert工作，即：把用户提交的YAML文件转换成一个叫做Super Version的对象，它正是该API资源类型所有版本的字段全集。这样用户提交不同版本的YAML文件，就都可以用这个Super Version对象来进行处理了。

接下来，API Server会先后进行Admission（）和Validation（）操作。Validation负责验证这个对象的各个字段是否合法。这个被验证过的API对象，都保存在API Server中一个叫做Registry的数据结构中。

最后，APIServer会把验证过的API对象转换为用户最初提交的版本，进行序列化操作，并调用Etcd的API保存起来

Controller的工作

image

首先，从Kubernetes的API Server中获取它所关心的对象。这个操作依靠Informer完成的。Informer和API对象一一对应。在创建Informer的时候，需要传递一个networkClient，Informer通过networkClient和APIServer建立了连接。真正负责维护这个连接的，是Informer的Reflector，Reflector使用ListAndWatch方法获取并监听API对象实例的变化。

在ListAndWatch机制下，一旦APIServer有新的API实例被创建、删除或者更新，Reflector都会收到“事件通知”。

这时，该事件和它所对应的API对象这个组合，就被称为增量（Delta），它被放进一个Delta FIFO Queue中。

另一方面，Informer会从这个队列中读取增量。每拿到一个增量，Informer就会判断这个增量里的事件类型，然后创建或者更新本地对象缓存（Store）；并且Informer会根据这个事件类型，触发事先注册好的ResourceEventHandler。这些Handler需要在创建控制器的时候注册给它对应的Informer。

在控制器中，还有一个工作队列（WorkQueue）,这个工作队列的作用就是负责同步Informer和控制循环之间的数据。

比如在Handler中注册了三个Handler（AddFunc、UpdateFunc、DeleteFunc），然后将该事件对应的API对象的Key加入到工作队列中。

后面的控制循环，则会不断从工作队列中拿到API对象的Key，然后到缓存中去查询对应的API对象。执行真正的控制逻辑。