负责把APIServer上存储的对象定义实例化到集群上的程序就是控制器。控制器需要运行为守护进程：一方面，注册监视API Server上隶属该控制器类型的对象定义（spec）的变动，及时将变动反映到集群中的对象实例之上；另一方面，通过控制循环（control loop，也可称为控制回路）持续监视集群上由其负责管控的对象实例的实际状态，在因故障、更新或其他原因导致当前状态（Status）发生变化而与期望状态（spec）时，通过实时运行相应的程序代码尝试让对象的真实状态向期望状态迁移和逼近。

Kubernetes的核心就是控制理论，控制器中实现的控制回路是一种闭环（反馈）控制系统，该类型的控制系统基于反馈回路将目标系统的当前状态与预定义的期望状态相比较，二者之间的差异作为误差信号产生一个控制输出作为控制器的输入，以减少或消除目标系统当前状态与期望状态的误差，这种控制循环在Kubernetes上也称为调谐循环（reconciliation loop）。

对Kubernetes来说，无论控制器的具体实现有多么简单或多么复杂，它基本都是通过定期重复执行如下3个步骤来完成控制任务。

1）从API Server读取资源对象的期望状态和当前状态。

2）比较二者的差异，而后运行控制器中的必要代码操作现实中的资源对象，将资源对象的真实状态修正为Spec中定义的期望状态，例如创建或删除Pod对象，以及发起一个云服务API请求等。

3）变动操作执行成功后，将结果状态存储在API Server上的目标资源对象的status字段中。

工作负载范畴的控制器资源类型包括ReplicationController、ReplicaSet、Deployment、DaemonSet、StatefulSet、Job和CronJob等，它们各自代表一种类型的Pod控制器资源，分别实现不同的应用编排机制。

几乎所有的工作负载型控制器资源对象都是通过持续性地监控集群中运行着的Pod资源对象来确保受其管控的资源严格符合用户期望的状态，例如确保资源副本的数量要精确符合期望等。通常，一个工作负载控制器资源通常应该包含3个基本的组成部分。

• 标签选择器：匹配并关联Pod对象，并据此完成受其管控的Pod对象的计数。

• 期望的副本数：期望在集群中精确运行受控的Pod对象数量。

• Pod模板：用于新建Pod对象使用的模板资源。

Pod模板资源是Kubernetes API的常用资源类型，常用于为控制器指定自动创建Pod资源对象时所需的配置信息。内嵌于控制器的Pod模板的配置信息中不需要apiVersion和kind字段，除此之外的其他内容跟定义自主式Pod对象所支持的字段几乎完全相同，这包括metadata和spec及其内嵌的其他各字段。

生产环境中运行的Pod对象务必要添加存活探针和就绪探针，否则Kubernetes无法准确判定应用的存活状态和就绪状态，而只能把处于运行中的容器进程一律视为在健康运行，而健康运行的容器进程则一律视为就绪。