kube-controller-manager组件剖析-优快云博客

本文链接：https://blog.youkuaiyun.com/lhq1363511234/article/details/137210321

kube-controller-manager组件剖析

概述

kube-controller-manager 是 Kubernetes 集群中的核心控制组件之一，它运行在 master 节点上，负责管理和维护集群中各种对象的期望状态（Desired State）。

kube-controller-manager 是一个进程，其中包含了多个并行运行的“控制器”（controllers），每个控制器都专注于特定的集群管理任务。

控制器几类及其功能介绍

1. Replication Controller 或 Deployment Controller（副本调度控制器）：

RC负责维护指定数量的 Pod 副本，当实际数量与用户定义的数量不符时，会创建或删除 Pod，以保持一致性。
Deployment Controller
- 它确保Pod按期望状态运行，就像管家确保家庭秩序井然。
- 如果把Deployment看作是新一代的掌门人，那它取代了老一辈的RC（Replication Controller）。RC虽然曾经功勋卓著，但现在退居幕后，不再更新升级了，取而代之的是不断成长壮大的Deployment，它持续接收新的功能和改进。
- 控制器双管齐下，同时掌控Deployment和由其产生的ReplicaSet。
- 创建Deployment后，控制器自动构建ReplicaSet；升级时，通过新建ReplicaSet实现滚动更新。

每次Deployment对象修改后（如果修改会影响到部署的pod）,Deployment控制器都会滚动升级到新的版本。通过创建一个ReplicaSet，然后按照Deployment中定义的策略同时伸缩新、旧RelicaSet，直到旧pod被新的代替。并不会直接创建任何pod。

看门人创业做糕点的故事

Replication Controller（RC）是看门人，它的工作重点是确保在Kubernetes集群里，对应它管理的Pod始终有固定数量的副本在运行。就好比有个严格的管家，检查家里宠物猫的数量，要是多了就送走几只，少了就领养新的，直到和主人要求的数量对得上。

不过，这位管家只对那些设置了“永远重生”（RestartPolicy=Always）属性的Pod负责，也就是说，这些Pod要出问题就得立马原地复活。一般来说，一旦Pod正常出生并开始干活，除非它们完成使命后长时间没动静（超时后系统会回收），否则是不会凭空消失的。这时候，管家就会在别的地方再生一只同样的Pod来顶替。

RC里的Pod模板就像做糕点的模具，糕点做好出炉后，模具怎么变都不会影响已经做好的糕点。同样道理，一旦Pod按照模板造出来了，就算模板后来改头换面，也不影响已存在的Pod。另外，Pod还能通过改标签的方式“离家出走”，不再受RC管束，这招在转移Pod或者修复数据的时候挺有用。但别担心，只要RC还觉得数量不够，它就会马上用新模板生出新的Pod来替补。

如果有一天你想把整个RC“解散”，注意这只是取消了未来新增Pod的指令，之前由RC创建的Pod并不会因此消失。要想真正删掉RC所控制的所有Pod，你得先把RC设定的副本数减到0，这样一来，所有受控的Pod都会被清理干净。

总之，尽量不要撇开RC单枪匹马去创建Pod，因为让RC帮你打理Pod的生生死死，不仅能自动维护所需副本数量，更能应对各种突发状况，大大提升系统的稳定性和恢复能力。哪怕你的应用只需要一个Pod副本，也最好交给RC来安排

我这种讲述恐怕小孩也能看懂学习的吧

2. Node Controller：

监控节点（Worker Node）的状态，处理节点的加入、离开、不可达等情况，包括标记未响应节点、驱逐节点上的 Pods 等。
节点健康状况包含“就绪”（True）“未就绪”（False）和“未知”（Unknown）三种。
Node Controller通过API Server实时获取Node的相关信息，实现管理和监控集群中的各个Node的相关控制功能
职责

节点的生命周期

监测新节点的加入，验证节点是否符合集群要求，并将其纳入集群管理范围。
当节点离线、无法通讯或健康状况出现问题时，及时检测到这些变化，并采取相应的措施，比如标记节点为不可调度（Unschedulable）或非健康状态（Not Ready 或 Unhealthy）。

节点异常状态

当节点长时间无响应或者网络故障导致节点不可达时，Node Controller会标记该节点为NotReady状态。

若节点持续不可达，Node Controller将进一步标记为Unreachable或Unknown状态，并依据配置策略决定是否对节点上的Pod进行强制驱逐（Eviction），以防止业务长时间停滞且数据无法同步至其他健康节点。

Pod驱逐和再调度

在节点发生故障或被手动删除的情况下，Node Controller会触发Pod驱逐流程，将原本运行在故障节点上的Pod安全地从该节点移除，并重新调度至健康的节点上，确保服务的高可用性。

节点清理

对于已经永久下线或不再需要的节点，Node Controller还会协助清理相关资源，如删除关联的Pods、释放节点名称等，以保持集群资源的有效利用。

3. DaemonSet Controller：

确保在每个符合条件的节点上都运行一个 Daemon 类型的 Pod，通常用于运行集群级别的守护进程。

4. Namespace Controller：

管理 Namespace 的生命周期，如根据策略自动清理废弃的 Namespace。

5. Persistent Volume (PV) Controller：

处理 PersistentVolumeClaim (PVC) 与 PersistentVolume (PV) 的绑定，以及 PV 的回收。

6. Service Account & Token Controllers：

自动为每个 Namespace 创建默认的 Service Account，并管理相应的 Secret 以供 Pod 内部认证使用。

7. ResourceQuota Controller：

监控并实施 Namespace 级别的资源配额限制。

8. Endpoints Controller：

更新 Service 对应的 Endpoints 对象，保证 Service 与实际后端 Pod 之间的映射始终是最新的。

9. CronJob Controller：

负责按照 Cron 表达式调度 Job 执行，适用于定时任务的场景。

简单的架构源码剖析

看不懂就对了，可以先了解一下，坚持学习下去一定会懂一点点的，我始终相信那种恍然大悟的感觉是极其让人感到兴奋且快乐，又是还会带有一些成就感。

1. 包结构与启动过程：

kube-controller-manager 的主体逻辑位于 k8s.io/kubernetes/cmd/kube-controller-manager 包中。它的启动过程始于 main() 函数，通过初始化配置、设置信号处理函数、加载插件以及启动控制器工厂来启动各个控制器。

2. 控制器工厂与启动器：

controllermanager.NewControllerManager() 函数构建了一个 ControllerManager 对象，它包含了多个控制器的工厂方法，如 NewBootstrapSignerControllers、NewCloudNodeController 等。这些工厂方法用于生成具体的控制器实例。
StartControllers() 函数负责启动所有的控制器，每个控制器都是一个 Controller 接口的实现，它们会在单独的 goroutine 中运行各自的 Reconciliation Loop。

3. nformer 与 ListWatch：

控制器通过调用 sharedIndexInformer.Informer() 方法创建 Informer，Informer 内部实现了资源对象的本地缓存，并利用 List-Watch 模式与 API Server 保持通信，监听资源对象的变化事件。

4. 控制器工作流程：

以 ReplicationController 为例，其内部会创建一个 DeploymentController，监听 Deployments 和 ReplicaSets 的变化。当检测到实际副本数与期望副本数不符时，会通过调用 scaleReplicaSet() 等方法去更新 ReplicaSet 的副本数，进而影响底层 Pod 的数量。

5. 同步与异步处理：

控制器在处理事件时，根据实际情况选择同步或异步方式。比如，对于一些紧急或者重要的操作（如节点不可达时驱逐Pod），可能会立即触发；而对于一些非紧急操作，则可能放入队列异步处理，避免阻塞主循环。

6. 错误处理与重试机制：

控制器在执行操作过程中可能会遇到错误，例如 API 请求失败。此时，控制器通常会采用重试机制，确保操作最终能够成功完成。

7. Leader Election：

对于高可用场景下的 Leader Election，kube-controller-manager 使用了 k8s.io/client-go/tools/leaderelection 包提供的接口，通过在特定的 ConfigMap 或 Lease 上竞争锁，实现选举主控器的功能。

彩蛋🤩🤩🤩（源码白话解释）

欢迎步入 Kubernetes 的梦幻乐园——kube-controller-manager！起初，我们站在大门前（🎈🎉），这是程序的 main() 函数入口，一位亲切的向导（👨‍💼）开始引导我们参观这座奇妙的城堡。

紧接着，遇见我们的超级英雄——ControllerManager（🦸‍♂️），他手持魔杖（wand），犹如哈利波特般施展魔法，创造并唤醒沉睡中的小精灵（也就是各种控制器们，💖🌟）。

比如，他会让“云节点守护神”（ Node Controller 🌩️🌍）和“复制克隆大师”（Replication Controller 🪐_duplicate_）跃然登场，开始履行各自的职责。

这些小精灵们每个人都拥有一双透视眼——Informer（👀），它们能够实时洞察城堡内的每一件宝藏（Kubernetes 资源对象）的动态变化。

它们通过隐形的魔法纽带（🌐📡）与城堡的信息中枢（API Server）紧密相连，任何风吹草动都能被捕捉。

看看“复制克隆大师”，它密切关注着能够自我复制的小怪物军团（Deployment 和 ReplicaSet，😈军团）。当察觉到某个军团的实际力量与理想状态不符时，它便挥舞手中的魔棒（🔧），调整神秘阵法（更新 ReplicaSet 的副本数），以此改变战场上小怪物的数量（🎃 hver-changing army）。

守护者们有情商啊，面对紧急状况（💥 Crisis!）会立刻采取行动（同步处理），如闪电侠一般疾速响应（⚡️）。而在非紧急时刻，则像一群悠哉的猫咪（🐈），按顺序排队等待执行任务（异步处理）。

即使遭遇施法失误（🤦‍♂️），它们也会坚韧不拔地再次尝试（💪 错误处理与重试机制）。

最精彩的莫过于“领导权争夺赛”（Leader Election，⚔️ vs 🏆），每个守护者都试图在一块神奇公告板（configMap 或 Lease，📜✨）上刻下自己的印记，最先夺得公告板的那位将成为临时领导者，

佩戴象征权力的金色王冠（👑 Leadership Crown）。

如此这般，kube-controller-manager 就如同一部生动活泼的交响乐章（🎵 Symphony），每一个音符（即组件）都在精准和谐地演奏，共同维系着 Kubernetes 集群这个宏大宇宙的秩序与活力。

总结

功能点	Replication Controller (RC) 描述	Replication Controller (RC) 应用场景	Deployment Controller (DC) 描述	Deployment Controller (DC) 应用场景
副本维护	确保集群中指定数量的Pod实例始终运行，当Pod意外终止或节点故障时自动创建新的Pod	高可用性应用，需要确保一定数量的副本始终在线	同样确保Pod实例数量恒定，且具有更丰富策略和管理功能，如健康检查和就绪检查	高可用性应用，需要精细化管理Pod的健康和就绪状态
水平扩展与收缩	通过更改`.spec.replicas`字段调整Pod副本数量	根据业务需求动态调整资源规模	提供更灵活的扩展与收缩策略，如按百分比调整、动态调整等	根据实时负载或策略自动调整资源规模
滚动更新	基础滚动更新支持，逐步替换旧Pod为新Pod	版本更新，但不支持暂停、逐步或按比例控制更新速率	提供丰富的滚动更新策略，包括暂停/继续、分批次、可配置的更新间隔时间及最大不可用Pod比例等	安全、可控地进行应用版本更新和回滚操作
版本控制与回滚	不具备版本管理和回滚机制	手动管理版本更新和回滚	提供版本历史记录和一键式回滚到之前任何版本的功能	无缝回滚到任意历史版本，减少故障恢复时间
高级特性	无内置的高级状态跟踪和智能错误处理机制	适用于简单副本管理和低复杂度更新场景	记录并展示每个修订版本的状态和进度，具备完善的错误处理机制	适用于复杂应用部署、滚动更新、故障恢复等场景

控制器

控制器名称	作用与用途	关键功能
Replication Controller / Deployment Controller	管理Pod副本数量，确保集群中运行的Pod实例数目与用户设定一致，并支持滚动更新和版本管理	创建、删除Pod以保持副本数量，执行滚动更新策略
Node Controller	监控节点状态，处理节点加入、离开、不可达等问题	标记未响应节点、驱逐节点上的Pod，确保集群资源健康稳定
DaemonSet Controller	确保每个（或特定）节点上运行一个Pod副本，适用于部署守护进程服务	每个节点仅运行一个指定Pod，自动在节点上创建或删除Pod
Namespace Controller	管理命名空间的生命周期，实现资源隔离和访问控制	创建、更新、删除命名空间，确保资源在不同命名空间间的独立性
PersistentVolume (PV) Controller	管理集群持久化存储资源	根据PersistentVolumeClaim动态供应和回收存储资源
PersistentVolume Claim (PVC) Controller	帮助用户请求和绑定持久化存储资源	根据用户需求匹配并绑定PersistentVolume
ServiceAccount & Token Controllers	为Pod注入身份凭证，实现与Kubernetes API服务器的安全通信	创建默认ServiceAccount，生成和管理认证令牌
StatefulSet Controller	管理有状态应用，确保Pod实例具有唯一标识符和持久化存储	有序创建和销毁Pod，保证Pod间的有序性和数据一致性
Horizontal Pod Autoscaler (HPA)	根据资源使用情况自动调整Pod副本数	监控资源使用量，动态扩展或收缩Pod副本数以优化资源利用率
ResourceQuota Controller	限制命名空间中资源总量，防止资源滥用	在命名空间级别设置资源配额，确保资源公平分配和使用
Job Controller	运行一次性任务，确保任务至少成功执行一次或达到最大重试次数后终止	创建并管理一次性任务的生命周期，自动重启失败任务
CronJob Controller	根据预设的Cron风格时间表达式执行周期性任务	定时创建Job，实现定时任务自动化执行
PodDisruptionBudget Controller	保护应用在集群维护期间的可用性	设置最小Pod数量，防止在维护期间过度中断服务