kubernetes源码-ReplicaSet Controller 原理和源码分析
ReplicaSet Controller 原理和源码分析,源码为 kubernetes 的 release-1.22 分支 .
写在前面
前面因为一时兴起看了 job 控制器的源码,还不算难,所以打算由浅入深,从 ReplicaSet 控制器开始,再到后面的其他控制器,都看一遍。
入口函数
入口函数位于 kubernetes/cmd/kube-controller-manager/app/apps.go 下,可以看到 rs 也是属于 kube-controller-manager 的一员。
|
|
NewReplicaSetController
我们可以看到,其实每个控制器的其实函数都是差不多的,都是统一规范来的。
|
|
NewReplicaSetController 实际是调用 NewBaseController 方法去完成构造的。还是老样子,没什么变化,跟 job 控制器一样,无非就是 job 类型的 Informer 换成了 ReplicaSet 类型。
|
|
Run
和所有控制器一样,启动流程为:Run -> worker -> processNextWorkItem -> syncHandler。
|
|
addRS/updateRS/deleteRS
我们先不急往下走,先看看 增加、更新和删除 ReplicaSet 的方法。注释已经解释得很详细了。
|
|
enqueueRS
增加和更新函数都是调用 enqueueRS 入列的。
|
|
addPod
我们再看看 pod 相关事件的一些方法,监听到 pod add 事件的处理逻辑。
|
|
updatePod
监听到 pod update 事件的处理逻辑。
|
|
deletePod
监听到 pod delete 事件的处理逻辑。
|
|
NewUIDTrackingControllerExpectations
前面我们在 job 控制的源码里面看到过 ControllerExpectations ,有没有很眼熟?
|
|
uid 其实就是 pod 的 [命名空间/pod名称] 这样的组合
在 ControllerExpectations 的基础上多了一个集合的 map
key | values |
---|---|
ns/rsname | [“ns1/pod1”,“ns1/pod2”, …] |
这样就可以记录到具体的 rs 删除哪些 pod ,注意只有删除 pod 的时候才需要这样做。
worker
worker 这里也是启用多个协程来从队列里面获取并处理 ReplicaSet 对象的事件
|
|
syncReplicaSet
如果期望达成,则进行 ReplicaSet 同步。
|
|
manageReplicas
这里是管理 ReplicaSet pod 个数的地方。
|
|
总结
-
总体来看, ReplicaSet 的逻辑并不难,理解起来也很简单,跟 job 控制器差不多。
-
ReplicaSet 控制器启动后监听 ReplicaSet 增删改事件,和其他控制器一样,它监听到事件后并没有直接做操作,而是加入到队列里面,通过队列来实现多线程操作。
-
在入列的时候,更新事件会检查 ReplicaSet 副本数和 uid 是否相同,删除事件会做一个删除期望记录的操作。
-
ReplicaSet 控制器也引入了 pod 控制器,用来创建/删除/更新 pod 信息,这个 pod 控制器是再 controller_util 里面对 Clientset 操作 Pod 接口的再封装。
-
跟其他控制器一样,监听到 pod 事件时, 先判断 pod 是否处于删除状态,再判断 pod 是否属于 ReplicaSet 对象的,是的话,将 pod 的父对象加入队列,更新 ReplicaSet 对象的状态什么的。
-
我们注意到 NewUIDTrackingControllerExpectations 这个东西,这个在 job 控制的源码里面看到过 ControllerExpectations 的很类似,只不过多了一个集合用来记录 ReplicaSet 的 pod 集合,key 是 ReplicaSet 的 key ,用 pod 命名空间和 pod 名 来做 uid 。
-
syncReplicaSet 期望达成才进入下一步的操作。
-
manageReplicas 这里是控制 pod 数量的地方,多则删除,少则新增。