在机器人技术和自动化领域，控制回路是一个非终止回路，用于调节系统状态。
这是控制回路的一个示例：房间中的恒温器。
设定温度后，便会告诉恒温器我们想要的状态。实际室温是当前状态。恒温器通过打开或关闭设备来使当前状态更接近所需状态。
在 Kubernetes 中，控制器是控制环，它们会监视集群的状态，然后再需要时进行更改或请求更改。每个控制器都会尝试将当前集群状态移动到更接近所需状态。
控制器模式
控制器跟踪至少一种 Kubernetes 资源类型。这些对象的 spec 字段代表所需的状态。该资源的控制器负责使当前状态更接近于所需状态。
控制器可以自行执行操作；更常见的是，在 Kubernetes 中，控制器会将具有有副作用的消息发送到 API 服务器。我们将在下面看到该示例。
通过 API 服务器进行控制
Job 控制器是 Kubernetes 内置控制器的一个示例。内置控制器通过与集群 API 服务器进行交互来管理状态。
Job 是一个 Kubernetes 资源，它运行 Pod 或可能是多个 Pod 来执行任务然后停止。
（一旦调度（敬请期待～～），Pod 对象将成为 kubelet 所需状态的一部分）。
当作业控制器看到一个新任务时，它确保在集群中的某个位置，一组节点上的 kubelet 运行正确数量的 Pod 以完成工作。Job 控制器本身不会运行任何 Pod 或容器。而是，作业控制器通知 API 服务器创建或删除 Pod。舵面中的其他组件根据新信息起作用（有新的 Pod 计划和运行），最终完成工作。
创建新作业后，对该作业所期望的状态是完成。Job 控制器使该 Job 的当前状态更接近于我们想要的状态：创建 Pod 来完成我们要对该 Job 进行的工作，从而使 Job 接近完成。
控制器还更新配置它们的对象。例如：完成作业的工作后，作业控制器将更新该作业对象以将其标记为 “完成”。
（这有点像某些恒温器如何关闭灯以指示我们的房间现在处于我们设定的温度）。
直接控制
与 Job 相比，某些控制器需要对集群外部的内容进行更改。
例如，如果我们使用控制循环来确保集群中有足够的节点，则该控制器需要当前集群之外的内容以在需要时设置新的节点。
与外部状态进行交互的控制器从 API 服务器中找到所需的状态，然后直接与外部系统进行通信以使当前状态更加紧密。
（实际上，有一个控制器可以水平伸缩集群中的节点，请参阅集群自伸缩（敬请期待～～））。
期望状态与当前状态
Kubernetes 采用云原生系统试图，并且能够处理不断的变化。
随着工作的进行，我们的集群可能随时随地发生变化，并且控制环会自动修复故障。这意味着，我们的集群可能永远无法达到稳定状态。
只要我们集群的控制器正在运行并且能够进行有用的更改，总体状态是否稳定都没有关系。
设计
作为其设置宗旨，Kubernetes 使用许多控制器，每个控制器管理集群状态的特定方面。最常见的是，特定的控制环（控制器）使用一种资源作为其期望状态，并使用另一种资源来设法使期望状态发生。例如，用于 Job 的控制器跟踪 Job 对象（以发现新作业）和 Pod 对象（以运行 Job，然后查看作业何时完成）。在这种情况下，其它东西将创建作业，而作业控制器将创建 Pod。
使用简单的控制器而不是一组相互链接的单体控制回路很有用。控制器可能会失败，因此 Kubernetes 旨在解决这一问题。
注意：可以有多个控制器创建或更新相同类型的对象。在幕后，Kubernetes 控制器确保仅关注与控制资源链接的资源。
例如，我们可以具有 “部署和作业”；这些都创造了 Pod。作业控制器不会删除我们的 Deployment 创建的 Pod，因为控制器可以使用某些信息（标签）来区分这些 Pod。
控制器运行方式
Kubernetes 带有一组在 kube-controller-manager 内部运行的内置控制器。这些内置控制器提供了重要的核心行为。
Deployment 控制器和 Job 控制器是 Kubernetes 本身的一部分（“内置” 控制器）控制器的示例。Kubernetes 允许我们运行弹性舵面，这样，如果任何内置控制器出现故障，舵面的另一部分将接管工作。
我们可以找到在舵面之外运行的控制器来扩展 Kubernetes。或者，如果需要，我们可以自己编写一个新的控制器。我们可以将自己的控制器作为一组 Pod 运行，也可以在 Kubernetes 外部运行。最合适的选择取决于特定控制器的功能。
下一步是什么
- 阅读有关 Kubernetes 舵面的信息
- 探索一些基本的 Kubernetes 对象
- 了解有关 Kubernetes API 的更多信息
- 如果要编写自己的控制器，请参阅扩展 Kubernetes 中的扩展模式（敬请期待～～）
