1 .概要在控制器(controllers )机器人技术和自动化领域，控制电路(Control Loop )是用于调节系统状态的非终端电路。
这是控制环的例子。 是房间的温度自动调节器。
twdjj设定了温度，向温度自动调节器传达了你的期待状态(Desired State )。 房间的实际温度是“当前状态”。 通过机器的开关控制，温度自动调节器使当前状态接近所需状态。
在Kubernetes上，输入控制器通过监控集群的公共状态，并致力于将当前状态转变为期望的状态。
控制器管理器
控制器管理器由kube-controller-manager和云控制器- manager组成，是Kubernetes的大脑，通过apiserver监视集群的整体状态，并
2.kube -控制器- manager
kube-controller-manager由一系列控制器组成，由这些控制器可以划分为三组
1.必须启动的控制器
replicationcontrollerreplicationcontroller确保始终运行特定数量的Pod拷贝。 也就是说，复制控制器确保一个Pod或一组同类Pod始终可用。
如果复制控制器运行的Pod太多，则复制控制器将终止多余的Pod。 如果Pod数量较少，复制控制器将启动新Pod。 与手动创建的Pod不同，在复制控制器中创建的Pod将在失败、删除或退出时自动替换。 例如，在停止维护(如内核升级)之后，您的Pod将在节点上重新创建。 因此，即使APP应用程序只需要一个Pod，也必须使用复制控制器创建Pod。 复制控制器类似于“进程管理器”，但复制控制器不会监视单个节点上的单个进程，而是监视跨多个节点的多个Pod。
在讨论中，复制控制器通常缩写为“rc”，并用作kubectl命令的快捷方式。
复制控制器角色复制控制器仅确保所需的Pod数与标签选择运算符匹配并可操作。
复制控制器永远限制在这个狭窄的职责范围内。 它本身既不检测准备状态，也不检测活动状态。 由外部自动缩放器控制，而不是执行自动缩放，并更改replicas字段中的值。 不将计划策略添加到复制控制器。 也不要验证受控制的Pod是否与当前指定的模板匹配，以阻止自动调整大小和其他自动化过程。 同样，完成期限、相关性组织、配置扩展和其他特性也属于其他地方。
复制副本控制器复制副本的工作原理
RepicaSet由一组字段定义，包括用于标识可用Pod集合的选择运算符、指示要保留的副本数的数字以及在创建新Pod以满足副本数条件时使用的Pod模板。 每个复制副本都可以根据需要创建和删除Pod，以使副本数量达到预期值，从而实现存在价值。 当复制副本需要创建新的Pod时，将使用提供的Pod模板。
ReplicaSet通过Pod的metadata.ownerReferences字段连接到随附的Pod，以提供当前对象的所有者资源。 ReplicaSet获取的Pod在ownerReferences字段中包含所有者ReplicaSet的标识信息。 通过该连接，ReplicaSet知道它所维持的Pod集合的状态，并据此计划动作。
ReplicaSet使用其选择运算符标识要检索的Pod集合。 如果Pod没有OwnerReference，或者OwnerReference与ReplicaSet的选择运算符相匹配，则此ReplicaSet将立即检索Pod。
何时使用复制集
ReplicaSet确保始终运行指定数量的Pod拷贝。 但是，部署是一个更高级的概念，它管理复制副本并为Pod提供声明性更新和许多其他有用的功能。 因此，建议使用Deploy
ment 而不是直接使用 ReplicaSet，除非 你需要自定义更新业务流程或根本不需要更新。这实际上意味着，你可能永远不需要操作 ReplicaSet 对象：而是使用 Deployment，并在 spec 部分定义你的应用。
ReplicaSet 是 ReplicationController 的后继者。二者目的相同且行为类似，只是 ReplicationController 不支持 标签用户指南 中讨论的基于集合的选择算符需求。 因此，相比于 ReplicationController，应优先考虑 ReplicaSet。
DeploymentController（推荐）
Deployment 是一个 可以拥有 ReplicaSet 并使用声明式方式在服务器端完成对 Pods 滚动更新的对象。 尽管 ReplicaSet 可以独立使用，目前它们的主要用途是提供给 Deployment 作为 编排 Pod 创建、删除和更新的一种机制。当使用 Deployment 时，你不必关心 如何管理它所创建的 ReplicaSet，Deployment 拥有并管理其 ReplicaSet。 因此，建议你在需要 ReplicaSet 时使用 Deployment。
一个 Deployment 为 Pods 和 ReplicaSets 提供声明式的更新能力。
你负责描述 Deployment 中的 目标状态，而 Deployment 控制器（Controller） 以受控速率更改实际状态， 使其变为期望状态。你可以定义 Deployment 以创建新的 ReplicaSet，或删除现有 Deployment， 并通过新的 Deployment 收养其资源。
StatefulSetController
StatefulSet 是用来管理有状态应用的工作负载 API 对象。
StatefulSet 用来管理某 Pod 集合的部署和扩缩， 并为这些 Pod 提供持久存储和持久标识符。
和 Deployment 类似， StatefulSet 管理基于相同容器规约的一组 Pod。但和 Deployment 不同的是， StatefulSet 为它们的每个 Pod 维护了一个有粘性的 ID。这些 Pod 是基于相同的规约来创建的， 但是不能相互替换：无论怎么调度，每个 Pod 都有一个永久不变的 ID。
如果希望使用存储卷为工作负载提供持久存储，可以使用 StatefulSet 作为解决方案的一部分。 尽管 StatefulSet 中的单个 Pod 仍可能出现故障， 但持久的 Pod 标识符使得将现有卷与替换已失败 Pod 的新 Pod 相匹配变得更加容易。
DaemonSetController
DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。 当有节点加入集群时， 也会为他们新增一个 Pod 。 当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。
DaemonSet 的一些典型用法：
在每个节点上运行集群守护进程
在每个节点上运行日志收集守护进程
在每个节点上运行监控守护进程
一种简单的用法是为每种类型的守护进程在所有的节点上都启动一个 DaemonSet。 一个稍微复杂的用法是为同一种守护进程部署多个 DaemonSet；每个具有不同的标志， 并且对不同硬件类型具有不同的内存、CPU 要求。
JobController
Job 会创建一个或者多个 Pods，并将继续重试 Pods 的执行，直到指定数量的 Pods 成功终止。 随着 Pods 成功结束，Job 跟踪记录成功完成的 Pods 个数。 当数量达到指定的成功个数阈值时，任务（即 Job）结束。 删除 Job 的操作会清除所创建的全部 Pods。 挂起 Job 的操作会删除 Job 的所有活跃 Pod，直到 Job 被再次恢复执行。
一种简单的使用场景下，你会创建一个 Job 对象以便以一种可靠的方式运行某 Pod 直到完成。 当第一个 Pod 失败或者被删除（比如因为节点硬件失效或者重启）时，Job 对象会启动一个新的 Pod。你也可以使用 Job 以并行的方式运行多个 Pod。
CronJobController
CronJob 创建基于时隔重复调度的 Jobs。一个 CronJob 对象就像 crontab (cron table) 文件中的一行。 它用 Cron 格式进行编写， 并周期性地在给定的调度时间执行 Job。
为 CronJob 资源创建清单时，请确保所提供的名称是一个合法的 DNS 子域名. 名称不能超过 52 个字符。 这是因为 CronJob 控制器将自动在提供的 Job 名称后附加 11 个字符，并且存在一个限制， 即 Job 名称的最大长度不能超过 63 个字符。
CronJobs 对于创建周期性的、反复重复的任务很有用，例如执行数据备份或者发送邮件。 CronJobs 也可以用来计划在指定时间来执行的独立任务，例如计划当集群看起来很空闲时 执行某个 Job。
注意：
所有 CronJob 的 schedule: 时间都是基于 kube-controller-manager. 的时区。
如果你的控制平面在 Pod 或是裸容器中运行了 kube-controller-manager， 那么为该容器所设置的时区将会决定 Cron Job 的控制器所使用的时区。
TTLController
TTL 控制器现在只支持 Job。集群操作员可以通过指定 Job 的 .spec.ttlSecondsAfterFinished 字段来自动清理已结束的作业（Complete 或 Failed），如 示例 所示。
TTL 控制器假设资源能在执行完成后的 TTL 秒内被清理，也就是当 TTL 过期后。 当 TTL 控制器清理资源时，它将做级联删除操作，即删除资源对象的同时也删除其依赖对象。 注意，当资源被删除时，由该资源的生命周期保证其终结器（Finalizers）等被执行。
可以随时设置 TTL 秒。以下是设置 Job 的 .spec.ttlSecondsAfterFinished 字段的一些示例：
在资源清单（manifest）中指定此字段，以便 Job 在完成后的某个时间被自动清除。将此字段设置为现有的、已完成的资源，以采用此新功能。在创建资源时使用 mutating admission webhook 动态设置该字段。集群管理员可以使用它对完成的资源强制执行 TTL 策略。使用 mutating admission webhook 在资源完成后动态设置该字段，并根据资源状态、标签等选择不同的 TTL 值。
EndpointController
PodGCController
ResourceQuotaController
NamespaceController
ServiceAccountController
GarbageCollectorController
HPAController
DisruptionController
CSRSigningController
CSRApprovingController
2.默认启动的可选控制器，可通过选项设置是否开启
TokenController
NodeController
ServiceController
RouteController
PVBinderController
AttachDetachController
3.默认禁止的可选控制器，可通过选项设置是否开启
BootstrapSignerController
TokenCleanerController
3.cloud-controller-manager
cloud-controller-manager 在 Kubernetes 启用 Cloud Provider 的时候才需要，用来配合云服务提供商的控制，也包括一系列的控制器，如
Node Controller（节点控制器）节点控制器负责在云基础设施中创建了新服务器时为之 创建 节点（Node）对象。 节点控制器从云提供商获取当前租户中主机的信息。节点控制器执行以下功能：
针对控制器通过云平台驱动的 API 所发现的每个服务器初始化一个 Node 对象；利用特定云平台的信息为 Node 对象添加注解和标签，例如节点所在的 区域（Region）和所具有的资源（CPU、内存等等）；获取节点的网络地址和主机名；检查节点的健康状况。如果节点无响应，控制器通过云平台 API 查看该节点是否 已从云中禁用、删除或终止。如果节点已从云中删除，则控制器从 Kubernetes 集群 中删除 Node 对象。某些云驱动实现中，这些任务被划分到一个节点控制器和一个节点生命周期控制器中。
Route Controller（路由控制器）Route 控制器负责适当地配置云平台中的路由，以便 Kubernetes 集群中不同节点上的 容器之间可以相互通信。
取决于云驱动本身，路由控制器可能也会为 Pod 网络分配 IP 地址块。
Service Controller（服务控制器）服务（Service）与受控的负载均衡器、 IP 地址、网络包过滤、目标健康检查等云基础设施组件集成。 服务控制器与云驱动的 API 交互，以配置负载均衡器和其他基础设施组件。 你所创建的 Service 资源会需要这些组件服务。
从 v1.6 开始，cloud provider 已经经历了几次重大重构，以便在不修改 Kubernetes 核心代码的同时构建自定义的云服务商支持。
参考文档
控制器 | Kuberneteshttps://kubernetes.io/zh/docs/concepts/architecture/controller/kube-controller-manager - Kubernetes指南https://kubernetes.feisky.xyz/concepts/components/controller-manager工作负载资源 | Kuberneteshttps://kubernetes.io/zh/docs/concepts/workloads/controllers/