Kubernetes 控制器管理总结
内容提要
Kubernetes控制器在同一进程的不同goroutine中独立循环，通过Informer的List&Watch机制订阅资源事件，以降低API Server压力。控制器不直接运行资源，而是向API Server声明期望状态，由其他组件配合完成。例如JobController通过API Server创建Pod，由调度器和kubelet执行。Controller Manager负责注册和管理所有控制器。
延伸解读
控制器为何不直接运行资源
控制器通过 API Server 声明期望状态，而非直接创建或运行资源。例如 JobController 创建 Pod 时，只向 API Server 发送请求，实际由调度器分配节点、kubelet 启动容器。这种设计解耦了控制逻辑与执行，使各组件职责单一，便于独立扩展和维护。
Informer 如何减轻 API Server 压力
若控制器直接轮询 API Server 获取资源变更，大量控制器并发访问会导致 API Server 负载过高。Informer 通过 List & Watch 机制缓存增量事件，控制器只需订阅 Informer 事件，无需关心数据源访问和并发问题，从而显著降低控制面板压力。
Controller Manager 的注册与容错
Controller Manager 在初始化时注册所有内置控制器，注册表以控制器名称为键，确保唯一性。若重复注册同名控制器，程序会直接 panic，这体现了 Kubernetes 对控制器管理严谨性的要求，避免运行时冲突。
控制器内部的事件处理流程
每个控制器独立运行在 goroutine 中，内部为无限循环。控制器订阅 Informer 的 Add/Update/Delete 事件，将事件放入队列，再由多个 goroutine 消费并执行操作，最后将期望状态回填到 API Server。这种模式保证了事件处理的高效与并发安全。
Q&A
Kubernetes 控制器是如何保证资源状态向期望值收敛的？
控制器通过监控集群资源状态，不断执行控制逻辑，使当前状态向期望状态收敛。每个控制器内部是一个无限循环，订阅 Informer 资源事件，根据事件执行操作，并通过 API Server 声明期望状态。
为什么 Kubernetes 控制器要在同一个进程中运行？
为了降低管理复杂度和代码实现难度，所有控制器在同一个进程中运行，但每个控制器在独立的 goroutine 中执行，互不干扰。
Informer 在控制器中起什么作用？
Informer 通过 List & Watch 机制缓存增量事件数据，降低 API Server 压力，同时作为中间缓存层，让开发者只需订阅事件并专注于业务逻辑，无需处理数据源访问和并发问题。
JobController 是如何创建和管理 Pod 的？
JobController 自身不直接运行 Pod，而是通过 API Server 声明创建或删除 Pod 的请求，由调度器分配 Node，kubelet 在节点上创建并运行 Pod。
Controller Manager 的职责是什么？
Controller Manager 负责注册和管理集群中的各类控制器，在初始化时注册所有常见控制器，确保它们正常运行。
控制器之间如何通信？
控制器之间不会直接通信，它们甚至不知道其他控制器的存在，每个控制器独立处理自身逻辑，通过 API Server 间接协作。
