在 Kubernetes（k8s）的生态体系中，控制器模式是实现 声明式 API 的核心基石，也是理解 K8s 自愈能力、自动化运维的关键。
你日常使用的 Deployment、StatefulSet、Service 等资源的自动化管理，本质上都是控制器模式的具体落地。
本文将从控制器模式的核心原理出发，解析 kube-controller-manager 的作用，以 Deployment 为例拆解其创建流程，并深入讲解 Operator 模式的实现逻辑与实践。
Kubernetes 的控制器模式本质是实现 实际状态（Actual State）向 期望状态（Desired State）无限逼近的闭环控制系统，核心逻辑可概括为：
观察（Observe）→ 对比（Compare）→ 行动（Act）
这个循环被称为“调和循环”（Reconciliation Loop），是所有 k8s 控制器的通用骨架，其核心目标是 最终一致性 —— 不保证立即达到期望状态，但会持续尝试直到状态匹配。
一个标准的 k8s 控制器通常包含以下核心模块：
| 模块 | 作用说明 |
| Informer | 监听 API Server 的资源事件（增 / 删 / 改），缓存资源数据，避免频繁请求 API Server |
| WorkQueue | 异步处理资源事件的任务队列，实现 解耦 和 削峰填谷 |
| Sync/Reconcile 函数 | 核心业务逻辑，实现 “观察 - 对比 - 行动” 的核心逻辑 |
| Client | 与 API Server 交互的客户端（如 client-go），用于读写 k8s 资源 |
kube-controller-manager 作为 Kubernetes 控制平面的 核心管控中枢，是实现集群 声明式 API 和 状态自洽 的关键组件。它本身不执行具体管控逻辑，而是通过独立 goroutine 运行多个专业控制器，统一监听 apiserver 的资源状态变化，持续对比 期望状态 与 实际状态，一旦发现偏差立即触发 纠偏操作，最终让集群始终贴合用户定义的状态。
其核心运行逻辑可概括为：监听（apiserver）→ 对比（状态）→ 纠偏（操作）→ 反馈（更新），所有内置控制器均遵循这一通用逻辑，仅针对不同资源的管控细节做差异化实现。下面结合文字解析 + 时序图，详细讲解其整体工作流程和六大核心控制器的具体实现。
kube-controller-manager 的核心运行逻辑，就是 以标准化的监听 - 队列 - 处理框架为基础，通过声明式调和逻辑，让集群的实际状态最终贴合用户定义的期望状态，这也是 Kubernetes 自动化运维的底层核心。
kube-controller-manager 运行在控制平面节点，与 kube-apiserver、kube-scheduler 并称 控制平面三个核心，其核心架构特点：
┌───────────────┐ ┌──────────────────┐ ┌──────────────────────┐ │ 用户/其他组件 │ │ kube-apiserver │ │ kube-controller-manager │ └───────┬───────┘ └─────────┬────────┘ └──────────┬─────────┘ │ │ │ │ 1、定义期望状态（创建/更新资源） │ │ │ ──────────────────────────→ │ │ │ │ │ │ 2、资源状态变更，触发Watch事件 │ │ │ ───────────────────────────→ │ │ │ │ │ │ 3、控制器接收事件，对比 期望状态 与 实际状态 │ │ │ （从apiserver拉取最新实际状态） │ │ ←─────────────────────────── │ │ │ │ │ │ 4、发现状态偏差，执行纠偏操作（调用apiserver API） │ │ ←─────────────────────────── │ │ │ │ │ 5、apiserver执行操作，更新资源实际状态 │ │ │ │ │ │ 6、状态更新完成，反馈给控制器 │ │ │ ───────────────────────────→ │ │ │ │ │ │ 7、控制器确认状态一致，结束本次管控流程 └───────────────┘ └──────────────────┘ └──────────────────────┘
帮助 SRE 理解关键核心点：
Informer 是 控制器 与 apiserver 之间的桥梁，核心作用是高效监听资源变化，并对事件做预处理，避免控制器直接面对复杂的 Watch 流。
Informer 屏蔽了 apiserver Watch API 的底层细节（如重连、分片、事件乱序），让控制器只需关注 资源变化事件，无需处理网络异常、事件重复等问题。
WorkQueue 是控制器的 事件缓冲区，核心作用是解耦 Informer 的事件生产和 Handler 的事件消费，实现削峰填谷。
即使 apiserver 短时间推送大量事件（如集群扩容时 1000 个 Pod 同时创建），WorkQueue 也能缓存这些事件，控制器按自身处理能力逐步消费，避免控制器过载崩溃。
Handler 是控制器的 大脑，核心作用是实现 状态对比 - 纠偏 的核心逻辑，也是不同控制器差异化的核心所在。执行流程（所有控制器通用）：
kube-controller-manager 内置的六大核心控制器各司其职，覆盖节点、Pod、Service、命名空间等核心资源的全生命周期管控，下面逐一讲解其 核心作用、工作机制、时序图 和 实际应用场景。
监控集群所有节点的健康状态，自动识别节点故障，触发节点标记和 Pod 驱逐，保证集群节点的可用性和业务连续性。
┌──────────────┐ ┌──────────────────┐ ┌──────────────────────┐
│ kubelet │ │ kube-apiserver │ │ Node Controller │
└───────┬──────┘ └─────────┬────────┘ └──────────┬─────────┘
│ │ │
│ 1、正常向apiserver上报节点状态（心跳+资源使用） │
│ ──────────────────────────> │
│ │ │
│ 2、节点故障（宕机/网络中断），停止上报心跳 │
│ │ │
│ │ 3、控制器Watch到节点状态无更新，开始计时
│ │ ───────────────────────────>
│ │ │
│ │ │ 4、达到40s阈值，将节点标记为Unknown状态（调用apiserver）
│ │ <───────────────────────────
│ │ │
│ │ 5、继续计时，等待5min驱逐阈值 │
│ │ │
│ │ │ 6、阈值到达，检查节点上Pod的控制器归属（是否属于Deployment/RS）
│ │ <───────────────────────────
│ │ │
│ │ │ 7、对有控制器的Pod，触发驱逐（通知apiserver删除故障节点上的Pod）
│ │ <───────────────────────────
│ │ │
│ │ 8、apiserver更新Pod状态，触发kube-scheduler重新调度
│ │ │
│ │ │ 9、新Pod在健康节点创建，控制器确认节点故障处理完成
└──────────────┘ └──────────────────┘ └──────────────────────┘
集群某节点因硬件故障宕机，Node Controller 会在 5 分 40 秒 后自动将该节点上的业务 Pod 驱逐，kube-scheduler 会将这些 Pod 重新调度到其他健康节点，保证业务不中断。
保证指定数量的 Pod 副本始终运行，是 Deployment、ReplicaSet 的底层实现基础（ReplicaSet 是 RC 的升级版，支持更丰富的标签选择器，逻辑与 RC 完全一致）。
┌───────────────┐ ┌──────────────────┐ ┌──────────────────────┐ │ 用户定义RC │ │ kube-apiserver │ │ Replication Controller │ └───────┬───────┘ └─────────┬────────┘ └──────────┬─────────┘ │ │ │ │ 1、创建RC，指定replicas:3 + Pod模板 + 标签选择器 │ │ ──────────────────────────> │ │ │ │ │ │ 2、Watch到RC创建事件，推送给控制器 │ │ ───────────────────────────> │ │ │ │ │ │ 3、控制器通过标签选择器查询实际运行的Pod数（初始为0） │ │ <─────────────────────────── │ │ │ │ │ │ 4、发现实际数(0) < 期望数(3)，触发创建Pod操作（调用apiserver，基于Pod模板创建3个Pod） │ │ <─────────────────────────── │ │ │ │ │ 5、apiserver创建Pod，触发kube-scheduler调度 │ │ │ │ │ 6、Pod调度到节点并运行，kubelet上报Pod状态为Running │ │ <─────────────────────────── │ │ │ │ │ 7、控制器Watch到Pod状态更新，重新查询实际Pod数(3) │ │ ───────────────────────────> │ │ │ │ │ │ 8、实际数=期望数，状态一致，结束本次处理 │ │ │ │ │ │ 9、若某Pod异常退出（实际数变为2），控制器立即补建1个Pod，恢复副本数为3 │ │ <─────────────────────────── └───────────────┘ └──────────────────┘ └──────────────────────┘
用户创建 RC 部署 3 个 Nginx Pod，其中 1 个 Pod 因容器崩溃退出，RC 会在几秒内自动新建 1 个 Nginx Pod，始终保持 3 个副本运行。
┌───────────────┐ ┌──────────────────┐ ┌──────────────────────┐ │ Service/Pod │ │ kube-apiserver │ │ Endpoint Controller │ └───────┬───────┘ └─────────┬────────┘ └──────────┬─────────┘ │ │ │ │ 1、创建Service，指定标签选择器app:nginx │ │ ──────────────────────────> │ │ │ │ │ 2、创建3个带app:nginx标签的Pod并运行 │ │ ──────────────────────────> │ │ │ │ │ │ 3、Watch到Service和Pod创建事件，推送给控制器 │ │ ───────────────────────────> │ │ │ │ │ │ 4、控制器通过Service的标签选择器，筛选出匹配的3个Pod │ │ <─────────────────────────── │ │ │ │ │ │ 5、创建/更新Endpoints资源，写入3个Pod的IP:Port │ │ <─────────────────────────── │ │ │ │ │ 6、kube-proxy Watch到Endpoints变化，更新节点iptables/IPVS规则 │ │ ───────────────────────────> │ │ │ │ │ │ 7、若1个Pod异常删除，控制器立即从Endpoints中移除其IP:Port │ │ <─────────────────────────── │ │ │ │ │ 8、kube-proxy同步更新转发规则，避免访问到已删除的Pod └───────────────┘ └──────────────────┘ └──────────────────────┘
用户访问 Service 的 ClusterIP 时，请求会通过 kube-proxy 的转发规则，转发到 Endpoints 中的任意一个 Pod IP，实现 Service 对 Pod 的透明访问和负载均衡。
┌───────────────┐ ┌──────────────────┐ ┌──────────────────────┐
│ 用户操作NS │ │ kube-apiserver │ │ Namespace Controller │
└───────┬───────┘ └─────────┬────────┘ └──────────┬─────────┘
│ │ │
│ 1、执行kubectl delete ns test │
│ ──────────────────────────> │
│ │ │
│ │ 2、将ns/test标记为Terminating状态，推送给控制器 │
│ │ ───────────────────────────>
│ │ │
│ │ │ 3、控制器查询ns/test下的所有资源（Pod/Service/RC等）
│ │ <───────────────────────────
│ │ │
│ │ │ 4、递归删除所有子资源（按依赖顺序：先删除RC，再删除Pod，最后删除Service/ConfigMap等）
│ │ <───────────────────────────
│ │ │
│ │ 5、逐个删除资源，持续检查子资源剩余数量
│ │ <───────────────────────────
│ │ │
│ │ │ 6、确认ns/test下无任何子资源
│ │ <───────────────────────────
│ │ │
│ │ │ 7、最终删除ns/test资源，解除Terminating状态
│ │ <───────────────────────────
│ │ │
│ │ 8、命名空间删除完成，事件推送给apiserver
└───────────────┘ └──────────────────┘ └──────────────────────┘
用户删除测试命名空间 test，Namespace Controller 会自动清理该命名空间下的所有测试 Pod、Service、RC 等资源，无需人工逐个删除，避免集群资源残留。
┌───────────────┐ ┌──────────────────┐ ┌──────────────────────┐
│ 命名空间/Pod │ │ kube-apiserver │ │ ServiceAccount Controller │
└───────┬───────┘ └─────────┬────────┘ └──────────┬─────────┘
│ │ │
│ 1、创建新命名空间 ns/test │
│ ──────────────────────────> │
│ │ │
│ │ 2、Watch到NS创建事件，推送给控制器
│ │ ───────────────────────────>
│ │ │
│ │ │ 3、为ns/test自动创建default ServiceAccount
│ │ <───────────────────────────
│ │ │
│ │ │ 4、为default ServiceAccount自动创建Secret令牌（包含JWT认证信息）
│ │ <───────────────────────────
│ │ │
│ │ 5、在ns/test中创建Pod，未指定ServiceAccount
│ │ <───────────────────────────
│ │ │
│ │ │ 6、控制器自动将default ServiceAccount的Secret令牌挂载到Pod的/var/run/secrets/kubernetes.io/serviceaccount目录
│ │ <───────────────────────────
│ │ │
│ │ 7、Pod内应用通过挂载的令牌，向apiserver发起认证并请求API
│ │ <───────────────────────────
│ │ │
│ │ 8、若删除ServiceAccount，控制器自动删除对应的Secret令牌
│ │ <───────────────────────────
└───────────────┘ └──────────────────┘ └──────────────────────┘
Pod 内的监控应用（如 Prometheus）需要查询集群的 Pod 列表和节点状态，应用会通过挂载的令牌向 apiserver 认证，通过后即可调用 k8s API 获取所需信息。
┌───────────────┐ ┌──────────────────┐ ┌──────────────────────┐
│ 父资源/子资源 │ │ kube-apiserver │ │ Garbage Collector │
└───────┬───────┘ └─────────┬────────┘ └──────────┬─────────┘
│ │ │
│ 1、创建Deployment，自动创建RS，RS自动创建Pod（均设置OwnerReference）
│ ──────────────────────────> │
│ │ │
│ 2、执行kubectl delete deploy test（默认cascade=true）
│ ──────────────────────────> │
│ │ │
│ │ 3、Watch到Deployment删除事件，推送给控制器
│ │ ───────────────────────────>
│ │ │
│ │ │ 4、控制器通过OwnerReference，查询到Deployment的子资源RS
│ │ <───────────────────────────
│ │ │
│ │ │ 5、先删除子资源RS
│ │ <───────────────────────────
│ │ │
│ │ │ 6、再通过OwnerReference查询到RS的子资源Pod，删除所有Pod
│ │ <───────────────────────────
│ │ │
│ │ │ 7、检查是否有孤儿资源（无OwnerReference的资源），发现1个手动创建的无归属Pod
│ │ <───────────────────────────
│ │ │
│ │ │ 8、自动删除该孤儿Pod，释放节点资源
│ │ <───────────────────────────
│ │ │
│ │ 9、所有依赖资源和孤儿资源清理完成
└───────────────┘ └──────────────────┘ └──────────────────────┘
用户手动创建了一个 Pod 用于测试，测试完成后忘记删除，该 Pod 异常退出后成为孤儿资源，垃圾回收控制器会在一定时间后自动清理该 Pod，释放节点的 CPU / 内存资源。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。