自主式pod对象由调度器绑定至目标工作节点后即由相应节点上的kubelet负责监控其容器的存活性，容器主进程崩溃后，kubelet能够自动重启相应的容器。不过，kubelet对非主进程崩溃类的容器错误却无感知，这依赖于用户为pod资源对象自定义的存活性探测机制，以便kubelet能够探知到此类故障。然而，在pod对象遭到意外删除，或者工作节点自身发生故障时，又该如何处理呢。
kubelet时k8s集群节点代理程序，它在每个工作节点上都运行着一个实例。因而，集群中的某工作几点发生故障时，其kubelet也必将不再可用，于是，节点上的pod资源的健康状态将无法得到保障，也无法再由kubelet重启。此种场景中的pod存活性一般要由工作节点之外的pod控制器来保证。事实上，遇到意外删除的pod资源的恢复也依赖于其控制器。
pod控制器由master的kube-controller-manager组件提供，常见的此类别的控制器有ReplicationController、ReplicaSet、Deployment、DaemonSet、StatefulSet、Job和ConJob等，它们分别以不同的方式管理pod资源对象。
一、pod控制器概述
master的各组件中，apiserver仅负责将资源存储于etcd中，并将其变动通知给各相关的客户端程序，如kubelet、kube-scheduler、kube-porxy和kube-controller-manager等，kube-scheduler监控到处于未绑定状态的pod对象出现时遂启动调度器为其挑选适配的工作节点，然而，k8s的核心功能之一还在于要确保各资源对象的当前状态以匹配用户期望状态，使当前状态不断地向期望状态和解来完成容器应用管理，而这些则是kube-controller-manager的任务。kube-controller-manager是一个独立的单体守护进程，然而它包含了众多功能不同的控制器类型分别用于各类和解任务。
创建为具体的控制器对象后，每个控制器均通过apiserver提供的接口持续监控相关资源对象的当前状态，并在因故障、更新或其他原因导致系统状态发生变化时，尝试让资源的当前状态向期望状态迁移和逼近。简单来说，每个控制器对象运行一个和解循环负责状态和解，并将目标资源对象的当前状态写入到其status字段中。
List-Watch时k8s实现的核心机制之一，在资源对象的状态发生变动时，由api server负责写入etcd并通过水平触发机制主动通知给相关的客户端程序以确保其不会错过任何一个事件。控制器通过api server的watch接口实时监控目标资源对象的变动并执行和解操作，但并不会与其他控制器进行任何交互，甚至彼此之间根本就意识不到对方的存在。
工作负载一类的控制器资源类型包括ReplicationController、ReplicaSet、Deployment、DaemonSet、Job和ConJob等，它们分别代表了一种类型的pod控制器资源。
二、控制器与pod对象
pod控制器资源通过持续性地监控集群中运行着的pod资源对象来确保受其管控的资源严格符合用户期望的状态，例如资源副本的数量要精确符合期望等。通常一个pod控制器资源至少应该包含三个基本的组成部分。
标签选择器：匹配并关联pod资源对象，并根据此完成受其管控的pod资源计数
期望的副本数：期望在集群中精确运行着的pod资源的对象数量
pod模板：用于新建pod资源对象的pod模板资源。
三、pod模板资源
PodTemplate是k8s api的常用资源类型，常用于为控制器指定自动创建pod资源对象时所需的配置信息。因为要内嵌于控制器中使用，所以pod模板的配置信息中不需要apiVersion和kind字段，但除此之外的其他内容与自定义自主式pod对象所支持的字段几乎完全相同，这包括metadata和spec及其内嵌的其他各个字段。pod控制器类资源的spec字段通常都要内嵌replicas、selector和template字段，其中template即为pod模板的定义。如下：
apiVersion: apps/v1 kind: ReplicaSet matadata: name: rs-example spec: replicas: 2 selector: matchLabels: app: rs-demo template: matadata: labels: app: rs-demo spec: containers: - name: myapp image: ikubernetes/myapp:v1 ports: - name: http containerPort: 80