控制器

在机器人技术和自动化中，控制环是一个控制系统状态的不终止的循环。

这是一个控制环的例子：房间里的温度自动调节器。

当你设置了温度，告诉了温度自动调节器你的*期望状态*。房间的实际温度是*当前状态*。通过对设备的开关控制，温度自动调节器让其当前状态接近期望状态。

控制器通过 apiserver主节点上负责提供 Kubernetes API 服务的组件；它是 Kubernetes 控制面的前端。 监控集群的公共状态，并致力于将当前状态转变为期望的状态。

控制器模式

一个控制器至少追踪一种类型的 Kubernetes 资源。这些对象有一个代表期望状态的指定字段。控制器负责确保其追踪的资源对象的当前状态接近期望状态。

控制器可能会自行执行操作；在 Kubernetes 中更常见的是一个控制器会发送信息给 API 服务器主节点上负责提供 Kubernetes API 服务的组件；它是 Kubernetes 控制面的前端。 ，这会有副作用。看下面这个例子。

通过 API 服务器来控制

JobJob 是需要运行完成的确定性的或批量的任务。 控制器是一个 Kubernetes 内置控制器的例子。内置控制器通过和集群 API 服务器交互来管理状态。

Job 是一种 Kubernetes 资源，它运行一个 PodPod 是 Kubernetes 的原子对象。Pod 表示您的集群上一组正在运行的容器。 ，或者可能是多个 Pod，来执行一个任务然后停止。

（一旦被调度了），对 kubelet 来说 Pod 对象就会变成了期望状态的一部分。

在集群中，当 Job 控制器拿到新任务时，它会保证一组 Node 节点上的 kubelet 可以运行正确数量的 Pod 来完成工作。 Job 控制器不会自己运行任何的 Pod 或者容器。Job 控制器是通知 API 服务器来创建或者移除 Pod。 控制平面容器编排层，它暴露 API 和接口来定义、部署容器和管理容器的生命周期。 中的其它组件根据新的消息而反应（调度新的 Pod 并且运行它）并且最终完成工作。

创建新 Job 后，所期望的状态就是完成这个 Job。Job 控制器会让 Job 的当前状态不断接近期望状态：创建为 Job 要完成工作所需要的 Pod，使 Job 的状态接近完成。

控制器也会更新配置对象。例如：一旦 Job 的工作完成了，Job 控制器会更新 Job 对象的状态为 Finished。

（这有点像温度自动调节器关闭了一个灯，以此来告诉你房间的温度现在到你设定的值了）。

直接控制

相比 Job 控制器，有些控制器需要对集群外的一些东西进行修改。

例如，如果你使用一个控制环来保证集群中有足够的节点Kubernetes 中的工作机器称作节点。 ，那么控制就需要当前集群外的一些服务在需要时创建新节点。

和外部状态交互的控制器从 API 服务器获取到它想要的状态，然后直接和外部系统进行通信并使当前状态更接近期望状态。

（实际上有一个控制器可以水平地扩展集群中的节点。请看集群自动扩缩容）。

期望状态与当前状态

Kubernetes 采用了系统的云原生视图，并且可以处理持续的变化。

在任务执行时，集群随时都可能被修改，并且控制环会自动的修复故障。这意味着很可能集群永远不会达到稳定状态。

只要集群中控制器的在运行并且进行有效的修改，整体状态的稳定与否是无关紧要的。

设计

作为设计的一个原则，Kubernetes 使用了很多控制器，每个控制器管理集群状态的一个特定方面。最常见的一个特定的控制器使用一种类型的资源作为它的期望状态，控制器管理控制另外一种类型的资源向它的期望状态发展。

使用简单的控制器而不是一组相互连接的单体控制环是很有用的。控制器会失败，所以 Kubernetes 的设计是考虑到了这一点。

例如：为 Job 追踪 Job 对象（发现新工作）和 Pod 对象（运行 Job，并且等工作完成）的控制器。在本例中，其它东西创建作业，而作业控制器创建 Pod。

注意：

可以有多个控制器来创建或者更新相同类型的对象。在这之后，Kubernetes 控制器确保他们只关心和它们控制资源相关联的资源。

例如，你可以有 Deployments 和 Jobs；它们都可以创建 Pod。Job 控制器不删除 Deployment 创建的 Pod，因为有信息(标签用来为对象设置可标识的属性标记；这些标记对用户而言是有意义且重要的。 )让控制器可以区分这些 Pod。

运行控制器的方式

Kubernetes 自带有一组内置的控制器，运行在 kube-controller-manager主节点上运行控制器的组件。 内。这些内置的控制器提供了重要的核心功能。

Deployment 控制器和 Job 控制器是 Kubernetes 内置控制器的典型例子。Kubernetes 运行一个弹性的控制平面，所以如果任意内置控制器失败了，控制平面的另外一部分会接替它的工作。

你会发现控制平面外面运行的控制器，扩展了 Kubernetes 的能力。或者，如果你愿意，你也可以写一个新控制器。你可以以一组 Pod 来运行你的控制器，或者运行在 Kubernetes 外面。什么是最合适的控制器，这将取决于特定控制器的功能。

接下来