自主式Pod对象由调度器绑定至目标Node节点后即由相应节点上的kubelet负责监控其容器的存活性，容器主进程崩溃后，kubelet能够自动重启相应的容器，不过，kubelet对非主进程崩溃类的容器错误却无从感知，这依赖于用户为Pod资源对象自定义的存活性探测机制，以便kubelet能够感知到此类故障。然而，在Pod对象遭到意外删除，或者工作节点自身发生故障时，又该如何处理呢？

kubelet是kubernetes集群节点代理程序，它在每个工作节点上都运行着一个实例。因而，集群中的某工作节点发生故障时，其kubelet也必将不在可用，于是，节点上Pod资源的健康状态将无从得到保证，也无法再由kubelet重启，此类场景中的Pod存活性一般要由工作节点之外的Pod控制器来保证。事实上，遭到意外删除Pod资源的恢复也依赖于其控制器。

Pod控制器由master的kube-controller-manager组件提供，常见的此类控制器有Replication、Controller、ReplicaSet、Deployment、DaemonSet、StatefulSet、Job和CronJob等，它们分别以不同的方式管理Pod资源对象。实践中，对Pod对象的管理方式通常都是由某种控制器的特定对象来实现，包括其创建、删除以及重新调度等操作。

关于Pod控制器

我们可以把API Server类比成一个存储对象的数据库系统，它向客户端提供来API，并负责存储由用户创建的各种资源对象，至于各对象的当前状态如何才能符合用户期望的状态，则需要交由另一类称为控制器的组件来负责完成，Kubernetes提供了众多的控制器来管理各种类型的资源。通过控制器创建完成Pod后，每个控制器对象都可以通过内部的和解循环(reconciliation loop)，不断的监控着由其负责的所有资源并确保其处于或不断逼近用户定义的目标状态。

尽管能够由kubelet为其提供自愈能力，但在节点宕机时，自主式Pod对象的重建式自愈机制则需要由Pod控制器对象负责提供，并且由它来负责实现周期中的各类自动管理行为，如创建及删除等。

控制器于Pod对象

Pod控制器资源通过持续性地监控集群中运行着的Pod资源对象来确保其管控的资源严格符合用户期望的状态，例如资源副本的数量要精确符合期望等，通常，一个Pod控制器至少应该包含三个基本的组成部分。

• 标签选择器：匹配并关联Pod资源对象，并根据此完成受其管控的Pod资源计数。
• 期望的副本数：期望在集群中精确运行着的Pod资源对象数量。
• Pod模版：用于新建Pod资源对象的Pod模版资源。

DaemonSet控制器用于确保集群中的每个工作节点或符合条件的每个节点上都运行着一个Pod副本，而不是某个精确的数量值，因此不具有上面组成部分中的第三项。

Pod模版资源

Pod Template是Kubernetes API的常用资源类型，常用于为控制器指定自动创建Pod资源对象时所需的配置信息，因为要内嵌于控制器中使用，所以Pod模版的配置信息中不需要apiVersion和kind字段，但除此之外的其它内容于定义自主式Pod对象所支持的字段几乎完全相同，这包含metadata、spec及其内嵌的其它各个字段。Pod控制器资源的spec字段通常都要内嵌replicas、selector、template字段，其中template即为Pod模版的定义。下面是一个定义在ReplicaSet资源中的模版资源示例：

如上图所示，spec.template字段在定义时仅给出了metadata和spec两个字段，它的使用方法与自主式Pod资源完全相同。

常用控制器

下面几个章节中介绍以下几种控制器：

• 1.ReplicaSet控制器
• 2.Deployment控制器
• 3.DaemonSet控制器
• 4.StatefulSet控制器
• 5.Job控制器
• 6.CronJob控制器