图解 Deployment Controller 工作流程

最编程 2024-02-11 22:13:47

...

本文基于对 Kubernetes v1.16 的源码阅读，通过流程图描述 Deployment Controller 的工作流程，但也包含相关代码以供参考。

上一篇文章《Kubernetes Controller Manager 工作原理》讲解了 Controller Manager 是怎么管理 Controller 的，我们知道 Controller 只需要实现相关事件 handler，无须再关心上层逻辑。本文将基于这篇文章，介绍 Deployment Controller 在接收到来自 Informer 的事件后，做了哪些工作。

Deployment 与控制器模式

在 K8s 中，pod 是最小的资源单位，而 pod 的副本管理是通过 ReplicaSet(RS) 实现的；而 deployment 实则是基于 RS 做了更上层的工作。

这就是 Kubernetes 的控制器模式，顶层资源通过控制下层资源，来拓展新能力。deployment 并没有直接对 pod 进行管理，是通过管理 rs 来实现对 pod 的副本控制。deployment 通过对 rs 的控制实现了版本管理：每次发布对应一个版本，每个版本有一个 rs，在注解中标识版本号，而 rs 再每次根据 pod template 和副本数运行相应的 pod。deployment 只需要保证任何情况下 rs 的状态都在预期，rs 保证任何情况下 pod 的状态都在预期。

K8s 是怎么管理 Deployment 的

了解了 deployment 这一资源在 K8s 中的定位，我们再来看下这个资源如何达到预期状态。

Kubernetes 的 API 和控制器都是基于水平触发的，可以促进系统的自我修复和周期协调。

水平触发这个概念来自硬件的中断，中断可以是水平触发，也可以是边缘触发：

水平触发 : 系统仅依赖于当前状态。即使系统错过了某个事件（可能因为故障挂掉了），当它恢复时，依然可以通过查看信号的当前状态来做出正确的响应。

边缘触发 : 系统不仅依赖于当前状态，还依赖于过去的状态。如果系统错过了某个事件（“边缘”），则必须重新查看该事件才能恢复系统。

Kubernetes 水平触发的 API 实现方式是：控制器监视资源对象的实际状态，并与对象期望的状态进行对比，然后调整实际状态，使之与期望状态相匹配。

水平触发的 API 也叫声明式 API，而监控 deployment 资源对象并确定符合预期的控制器就是 deployment controller，对应的 rs 的控制器就是 rs controller。

Deployment Controller

架构

首先看看 DeploymentController 在 K8s 中的定义：

  
  
  
type DeploymentController struct {
   
   
    rsControl controller.RSControlInterface
   
   
    client clientset.Interface
   
   
    eventRecorder record.EventRecorder
   
   
   

   
   
    syncHandler func(dKey string) error
   
   
    enqueueDeployment func(deployment *apps.Deployment)
   
   
   

   
   
    dLister appslisters.DeploymentLister
   
   
    rsLister appslisters.ReplicaSetLister
   
   
    podLister corelisters.PodLister
   
   
   

   
   
    dListerSynced cache.InformerSynced
   
   
    rsListerSynced cache.InformerSynced
   
   
    podListerSynced cache.InformerSynced
   
   
   

   
   
    queue workqueue.RateLimitingInterface
   
   
   }

主要包括几大块内容：

rsControl 是一个 ReplicaSetController 的工具，用来对 rs 进行认领和弃养工作； client 就是与 APIServer 通信的 client；

eventRecorder 用来记录事件； syncHandler 用来处理 deployment 的同步工作； enqueueDeployment 是一个将 deployment 入 queue 的方法；

dLister、 rsLister、 podLister 分别用来从 shared informer store 中获取资源的方法； dListerSynced、 rsListerSynced、 podListerSynced 分别是用来标识 shared informer store 中是否同步过；

queue 就是 workqueue，deployment、replicaSet、pod 发生变化时，都会将对应的 deployment 推入这个 queue， syncHandler() 方法统一从 workqueue 中处理 deployment。

工作流程

接下来看看 deployment controller 的工作流程。

deployment controller 利用了 informer 的工作能力，实现了资源的监听，同时与其他 controller 协同工作。主要使用了三个 shared informer —— deployment informer、rs informer、pod informer。

首先 deployment controller 会向三个 shared informer 中注册钩子函数，三个钩子函数会在相应事件到来时，将相关的 deployment 推进 workqueue 中。

deployment controller 启动时会有一个 worker 来控制 syncHandler 函数，实时地将 workqueue 中的 item 推出，根据 item 来执行任务。主要包括：领养和弃养 rs、向 eventRecorder 分发事件、根据升级策略决定如何处理下级资源。

workqueue

首先看看 workqueue，这其实是用来辅助 informer 对事件进行分发的队列。整个流程可以梳理为下图。

可以看到，workqueue 分为了三个部分，一是一个先入先出的队列，由切片来实现；还有两个是名为 dirty 和 processing 的 map。整个工作流程分为三个动作，分别为 add、get、done。

add 是将消息推入队列。消息是从 informer 过来的，其实过来的消息并不是事件全部，而是资源 key，即 namespace/name，以这种形式通知业务逻辑有资源的变更事件过来了，需要拿着这个 key 去 indexer 中获取具体资源。如上图绿色的过程所示，在消息进行之后，先检查 dirty 中是否存在，若已存在，不做任何处理，表明事件已经在队列中，不需要重复处理；若 dirty 中不存在，则将该 key 存入 dirty 中（将其作为 map 的键，值为空结构体），再推入队列一份。

get 是 handle 函数从队列中获取 key 的过程。将 key 从队列中 pop 出来的同时，会将其放入 processing 中，并删除其在 dirty 的索引。这一步的原因是将 item 放入 processing 中标记其正在被处理，同时从 dirty 中删除则不影响后面的事件入队列。

done 则是 handle 在处理完 key 之后，必须执行的一步，相当于给 workqueue 发一个 ack，表明我已经处理完毕，该动作仅仅将其从 processing 中删除。

有了这个小而美的先入先出的队列，我们就可以避免资源的多个事件发生时，从 indexer 中重复获取资源的事情发生了。下面来梳理 deployment controller 的具体流程。

replicaSet 的认领和弃养过程

在 deployment controller 的工作流程中，可以注意到除了 deployment 的三个钩子函数，还有 rs 和 pod 的钩子函数，在 rs 的三个钩子函数中，涉及到了 deployment 对 rs 的领养和弃养过程。

rs 认亲

首先来看 rs 的认亲过程：

在 rs 的三个钩子函数中，都会涉及到认亲的过程。

当监听到 rs 的变化后，会根据 rs 的 ownerReferences 字段找到对应的 deployment 入 queue；若该字段为空，意味着这是个孤儿 rs，启动 rs 认亲机制。

认亲过程首先是遍历所有的 deployment，判断 deployment 的 selector 是否与当前 rs 的 labels 相匹配，找到所有与之匹配的 deployment。

然后判断总共有多少个 deployment，若为 0 个，就直接返回，没有人愿意认领，什么都不做，认领过程结束；若大于 1 个，抛错出去，因为这是不正常的行为，不允许多个 deployment 同时拥有同一个 rs；若有且仅有一个 deployment 与之匹配，那么就找到了愿意领养的 deployment，将其入 queue。

addReplicaSet() 和 updateReplicaSet() 的认领过程类似，这里只展示 addReplicaSet() 的代码：

  
  
  
func (dc *DeploymentController) addReplicaSet(obj interface{}) {
   
   
    rs := obj.(*apps.ReplicaSet)
   
   
   

   
   
    if rs.DeletionTimestamp != nil {
   
   
    dc.deleteReplicaSet(rs)
   
   
    return
   
   
    }
   
   
   

   
   
    if controllerRef := metav1.GetControllerOf(rs); controllerRef != nil {
   
   
    d 
						

							上一篇：							
								React里的生命周期方法钩子详解							
						

						
							下一篇：							
								C# 中的钩子函数应用指南


															
						
							推荐阅读						
						
														
								
									
										图解 Deployment Controller 工作流程