5.1.1 Pod 控制器概述

master 的各组件中，API Server 仅负责将资源存储于 etcd 中，并将其变动通知给各相关的客户端程序，如 kubelet、kube-scheduler、kube-proxy 和 kube-controller-manager 等，kube-scheduler 监控到处于未绑定状态的 Pod 对象出现时遂启动调度器为其挑选适配的工作节点，然而，Kubernetes 的核心功能之一还在于要确保各资源对象的当前状态（status）已匹配用户期望的状态（spec），使当前状态不断地向期望状态“和解”（reconciliation）来完成容器应用管理，而这些则是 kube-controller-manager 的任务。kube-controller-manager 是一个独立的单体守护进程，然而它包含了众多功能不同的控制器类型分别用于各类和解任务，如图 5-1 所示。

kubernetes 可用的控制器有 attachdetach、bootstrapsigner、clusterrole-aggregation、cronjob、csrapproving、csrcleaner、daemonset、deployment、disruption、endpoint、garbagecollector、horizontalpodautoscaling、job、namspace、node、persistentvolume-expander、podgc、pvc-protection、replicaset、replication-controller、resourcequota、route、service、serviceaccount、serviceaccount-token、statefulset、tokencleaner 和 ttl 等数十种。

创建为具体的控制器对象之后，每个控制器均通过 API Server 提供的接口持续监控相关资源对象的当前状态，并在因故障、更新或其他原因导致系统状态发生变化时，尝试让资源的当前状态向期望状态迁移和逼近。简单来说，每个控制器对象运行一个和解循环负责状态和解，并将目标资源对象的当前状态写入到其 status 字段中。控制器的“和解”循环如图 5-2 所示。

List-Watch 是 Kubernetes 实现的核心机制之一，在资源对象的状态发生变动时，由 API Server 负责写入 etcd 并通过水平触发（level-triggered）机制主动通知给相关的客户端程序以确保其不会错过任何一个事件。控制器通过 API Server 的 Watch 接口实时监控目标资源对象的变动并执行和解操作，但并不会与其他控制器进行任何交互，设置彼此之间根本就意识不到对方的存在。

工作负载（workload）一类的控制器资源类型包括 ReplicationController、ReplicaSet、Deployment、DaemonSet、StatefulSet、Job 和 CronJob 等，它们分别代表了一种类型的 Pod 控制器资源，各类型的功用在 3.1.1 节中已经给出过说明。本章后面的篇幅主要介绍各控制器的特性及其应用，不过 StatefulSet 控制器依赖于存储卷资源，因此它将单独在存储卷之后的章节中给予介绍。