自主式Pod对象由调度器绑定至目标工作节点后即由相应节点上的kubelet负责监控其容器的存活性，容器主进程崩溃后，kubelet能够自动重启相应的容器。不过，kubelet对非主进程崩溃类的容器错误却无从感知，这依赖于用户为Pod资源对象自定义的存活性探测(liveness Probe)机制，即便kubelet能够探知到此类故障，然而，在Pod对象遭到意外删除，或者工作节点自身发生故障时，又该如何处理呢？
kubelet是K8S集群节点代理程序，它在每个工作节点上都运行着一个实例。因而，集群中的某工作节点发生故障时，其kubelet也将不再可用。于是，节点上的Pod资源的健康状态将无法得到保证，也无法再由kubelet重启。此种场景中的Pod存活性一般要由工作节点之外的Pod控制器来保证。事实上，遭到意外删除的Pod资源的恢复也依赖于其控制器
Pod控制器由master的kube-controller-manager组件提供，常见的此类控制器由Replication、Cintroller、RelicaSet、Deployment、DaemonSet、StatefuSet、job和Cronjob等，他们分别以不同的方式管理Pod资源对象。实践中，对Pod对象的管理通常都是由某种控制器的特定对象来实现的，包括其创建、删除及重新调度等操作

关于Pod控制器

我们可以把API Server类比成一个存储对象的数据库系统，它向客户端提供了API，并负责存储由用户创建的各种资源对象，至于各对象的当前状态如何才能符合用户期望的状态，则需要交由另外一类称为控制的组件来负责完成。K8S提供了众多的控制器来管理各种类型的资源，如Node lifecycle controller、namespace controller、service controller和deployment controller等，他们的功用几乎可以做到见名知义，每一个控制器对象都可以通过内部的和解循环，不间断的监控着由其负责的所有资源并确保其处于或不断的与用户的期望目标状态保持一致 尽管能够由kubelet为其提供自愈能力，但在节点宕机时，自主式Pod对象的重建式自愈机制则需要由Pod控制器对象负责提供，并且由它来负责实现生命周期中的各类自动管理行为

Pod控制器概述

master的各组件中，API Server仅负责将资源存储于etcd中，并将其变动通知给各相关的客户端，如kubelet、kube-scheduler、kube-proxy和kube-controller-manager等，kube-scheduler监控到处于未绑定状态的Pod对象出现时，便开始启动调度器为其挑选适配的工作节点，然而，k8s的核心功能之一还在于要确保个资源对象的当前状态（status）以匹配用户的期望状态，使当前状态不间断的向期望状态“和解”来完成容器应用管理，而这些则是kube-controller-manager的任务。kube-controller-manager是一个独立的单体守护进程，然而它包含了众多功能不同控制器分别用于各类和解任务 K8S可用的控制器有attachdetach、bootstrapsigner、clusterrole-aggregation、cronjob、csrapproving、csrcleaner、csrigning、daemonset、deployment、disruption、endpoint、garbagecollector、horizontalpodautoscaling、job、namespace、node、persistentvvolume-binder、persistentvloume-expander、podgc、pvc-protection、replicaset、replication-controller、resoureequota、route、service、serviceaccount、serviceaccount-token、statefulset，tokencleaner和ttl等数十种 创建为具体的Pod控制器对象之后，每个控制器均通过API Server提供的接口持续监控相关资源对象的当前状态，并在因故障、更新或其他原因导致系统状态发生变化时，尝试让资源的当前状态向期望状态迁移和逼近。简单来说，每个控制器对象都运行一个和解循环负责状态和解并将目标资源对象的当前状态写入到其status字段中，控制器的“和解”list-watch是K8S实现的核心机制之一，在资源对象的状态发生变动时，由API Server负责写入etcd并通过水平触发（level-triggered）机制主动通知给相关的客户端程序以确保其不会错过任何一个事件。控制器通过API Server的watch接口实时监控目标资源对象的变动并执行和解操作，但并不会与其它控制器进行交互，甚至彼此之间根本就意识步到对方的存在 工作负载（workload）一类的控制器资源类型包括ReplicationController、replicaSet、Deployment、daemonSet、statefulSet、job和conjob等。他们分别代表了一种类型的Pod控制器资源，各类型的功用之前有说过。不过statefulSet控制器依赖于存储卷资源

控制器与Pod对象

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

  • 标签选择器：匹配并关联Pod资源对象，并据此完成受其管控的Pod资源计数
  • 期望的副本数:期望在集群中精确运行着的Pod资源的对象数量
  • Pod模板：用于新建Pod资源对象的Pod模板资源
    DaemonSet用于确保集群中的每个工作节点或符合条件的每个节点上都运行着一个Pod副本，而不是某个精确的数量值，因此不具备上面组成部分中的第二项
    例如，一个Dployment控制器资源使用的标签选择为“role=be-eshop”，它期望相关的Pod资源副本数量为3个，少于此数量的缺失部分由控制器通过Pod模板予以创建，而多出的副本也将由控制器负责终止删除

Pod资源模板

Pod Template是K8S API的常用资源类型，常用于为控制器自动创建Pod资源对象时所需要的配置信息，因为要内嵌于控制器中使用，所以Pod模板的配置信息中不需要apiVersion和Kind字段，但除此之外的其他内容与定义自主式Pod对象所支持的字段几乎完全相同，这包括metadata和spec及其内嵌的其他各个字段。Pod控制器类型的资源的spec字段通常都需要内嵌relicas、selector和template字段，其中template字段即为Pod模板的定义。selector字段用于关联template字段里面定义的Pod标签，并且通过该标签将Pod与控制器关联起来。下面是一个定义在Replicaset资源中的模板资源示例

  1. apiVersion: apps/v1
  2. kind: ReplicaSet
  3. metadata:
  4.   name: rs
  5. spec:
  6.   replicas: 2
  7.   selector:
  8.     matchLabels:
  9.       app: rs-damo
  10.   template:
  11.     metadata:
  12.       labels:
  13.         app: rs-damo
  14.   spec:
  15.     containers:
  16.     - name: rs-busybox
  17.       image: registry.cn-hangzhou.aliyuncs.com/jiangyida/busybox:0.1
  18.       ports:
  19.       - name: http
  20.         containerPort: 80

如上面的示例中，spec.template字段在定义时仅给出了metadata和spec两个字段，它的使用方法与自主式Pod完全相同，通常我们在使用例如Deployment控制器的时候也是使用相同的方式来定义deployment资源类型 我们可以使用kubectl explain ReplicaSet.spec来看看其字段信息,然后根据可以根据对应的字段查找对应的嵌套字段 因为template主要用用于定义Pod的模板信息，所以它不需要定义apiVersion和kind字段

  1. 1.先看看relicaSet字段的信息
  2. [root@k8s-master01 con]# kubectl explain replicaSet
  3. KIND:     ReplicaSet
  4. VERSION:  apps/v1
  6. DESCRIPTION:
  7.      ReplicaSet ensures that a specified number of pod replicas are running at
  8.      any given time.
  10. FIELDS:
  11.    apiVersion    <string>
  12.      APIVersion defines the versioned schema of this representation of an
  13.      object. Servers should convert recognized schemas to the latest internal
  14.      value, and may reject unrecognized values. More info:
  15.      https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
  17.    kind    <string>
  18.      Kind is a string value representing the REST resource this object
  19.      represents. Servers may infer this from the endpoint the client submits
  20.      requests to. Cannot be updated. In CamelCase. More info:
  21.      https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
  23.    metadata    <Object>
  24.      If the Labels of a ReplicaSet are empty, they are defaulted to be the same
  25.      as the Pod(s) that the ReplicaSet manages. Standard object's metadata. More
  26.      info:
  27.      https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
  29.    spec    <Object>
  30.      Spec defines the specification of the desired behavior of the ReplicaSet.
  31.      More info:
  32.      https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
  34.    status    <Object>
  35.      Status is the most recently observed status of the ReplicaSet. This data
  36.      may be out of date by some window of time. Populated by the system.
  37.      Read-only. More info:
  38.      https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
  40. [root@k8s-master01 con]#
  42. 2.再看看replicaSet.spec字段
  43. [root@k8s-master01 con]# kubectl explain replicaSet.spec
  44. KIND:     ReplicaSet
  45. VERSION:  apps/v1
  47. RESOURCE: spec <Object>
  49. DESCRIPTION:
  50.      Spec defines the specification of the desired behavior of the ReplicaSet.
  51.      More info:
  52.      https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
  54.      ReplicaSetSpec is the specification of a ReplicaSet.
  56. FIELDS:
  57.    minReadySeconds    <integer>
  58.      Minimum number of seconds for which a newly created pod should be ready
  59.      without any of its container crashing, for it to be considered available.
  60.      Defaults to 0 (pod will be considered available as soon as it is ready)
  62.    replicas    <integer>
  63.      Replicas is the number of desired replicas. This is a pointer to
  64.      distinguish between explicit zero and unspecified. Defaults to 1. More
  65.      info:
  66.      https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/#what-is-a-replicationcontroller
  68.    selector    <Object> -required-
  69.      Selector is a label query over pods that should match the replica count.
  70.      Label keys and values that must match in order to be controlled by this
  71.      replica set. It must match the pod template's labels. More info:
  72.      https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors
  74.    template    <Object>
  75.      Template is the object that describes the pod that will be created if
  76.      insufficient replicas are detected. More info:
  77.      https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#pod-template
  79. [root@k8s-master01 con]#
  81. 3.再看看replicaSet.spec.template字段，可以看到在template字段里面还可以定义一个spec字段，这个spec字段定义的信息与我们创建自主式Pod定义的信息是一模一样的
  82. [root@k8s-master01 con]# kubectl explain replicaSet.spec.template
  83. KIND:     ReplicaSet
  84. VERSION:  apps/v1
  86. RESOURCE: template <Object>
  88. DESCRIPTION:
  89.      Template is the object that describes the pod that will be created if
  90.      insufficient replicas are detected. More info:
  91.      https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#pod-template
  93.      PodTemplateSpec describes the data a pod should have when created from a
  94.      template
  96. FIELDS:
  97.    metadata    <Object>
  98.      Standard object's metadata. More info:
  99.      https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
  101.    spec    <Object>
  102.      Specification of the desired behavior of the pod. More info:
  103.      https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
  105. [root@k8s-master01 con]#