控制器通过apiserver来监控集群的公共状态，并致力于将当前状态转变为期望状态。一个控制器至少追踪一种类型的Kubernetes资源。这些资源对象有一个代表期望状态的spec字段，该资源的控制器就负责确保其当前状态接近期望状态。Kubernetes内置了一组控制器，运行在kube-controller-manager内，这些内置的控制器提供了重要的核心功能。而常见的工作负载控制器主要有ReplicationController、ReplicaSet、Deployment、StatefulSet、DaemonSet、Job和CronJob这几种。

本文主要对Kubernetes的常用控制器进行一个概括性的总结。

一、ReplicationController

ReplicationController确保在任何时候都有指定数量的Pod副本处于运行状态。换句话说，ReplicationController确保一个Pod或一组同类的Pod总是可用。

当Pod数量过多时，ReplicationController会终止多余的Pod。当Pod数量太少时，ReplicationController会启动新的Pod。与手动创建的Pod不同，ReplicationController创建的Pod在失败、删除或终止时会被自动替换。因此，即使应用只需要一个Pod，也应该使用ReplicationController创建Pod。ReplicationController与进程管理器类似，但是ReplicationController不是监控单个节点上的单个进程，而是监控跨多个节点的多个Pod。

不过现在已经不推荐使用ReplicationController，而是推荐使用配置ReplicaSet的Deployment来建立Pod副本管理机制。

二、ReplicaSet

ReplicaSet的目的是维护一组在任何时候都处于运行状态的Pod保持稳定的副本数。因此，它通常用来保证给定数量的完全相同的Pod的可用性。

至于RepicaSet的工作原理，首先RepicaSet是通过一组字段定义的，包括一个用来识别可获得的Pod的selector，一个用来表明应该维护的Pod副本数（replica），一个用来指定应该创建新Pod以满足副本数条件时要使用的Pod模板（template）等。每个 ReplicaSet都将根据需要创建和删除Pod以达到期望的Pod副本数。当ReplicaSet需要创建新的Pod时，会使用所提供的Pod模板。ReplicaSet通过Pod上的metadata.ownerReferences字段连接到所属Pod，该字段指定当前对象属于哪个资源。ReplicaSet所获得的Pod都在其ownerReferences字段中包含了属主ReplicaSet的标识信息。正是通过这一连接，ReplicaSet获知了它所维护的Pod集合的状态并据此计划其操作行为。ReplicaSet使用其selector来识别要获取的Pod。如果某个Pod没有OwnerReference或者其OwnerReference不是一个控制器，并且其匹配到某ReplicaSet的selector，则该Pod立即被此ReplicaSet获得。

虽然ReplicaSet可以确保任何时间都有指定数量的Pod副本运行并可以独立使用，但现在它主要是用作协调Deploymen创建、删除和更新Pod的一种机制。使用Deployment时，我们不必担心它们创建的ReplicaSet如何管理，Deployment会拥有并管理它们，并向Pod提供声明式的更新以及许多其他有用的功能，例如滚动更新，Deployment支持而ReplicaSet不支持。所以推荐使用Deployment而不是直接使用ReplicaSet，除非需要自定义更新业务流程或根本不需要更新。

三、Deployment

Deployment为Pod和ReplicaSet提供声明式的更新方式。只需要在Deployment中描述一个期望状态，Deployment控制器以受控速率更改实际状态以达到期望状态。可以定义Deployment以创建新的ReplicaSet，或删除现有的Deployment并通过新的Deployment使用其所有资源。注意不要手动管理Deployment创建的ReplicaSet，否则逾越了Deployment控制器职责。下面是关于Deployment的典型用例：

• 创建Deployment以展开（rollout）ReplicaSet。ReplicaSet在后台创建Pod。检查ReplicaSet展开的状态，查看其是否成功。
• 通过更新Deployment的PodTemplateSpec字段来声明Pod的新状态。这将创建一个新的ReplicaSet，并且Deployment管理器会以受控速率将Pod从旧ReplicaSet移动到新ReplicaSet。每个新的ReplicaSet都会更新Deployment的修订历史（revision）。
• 如果Deployment的当前状态不稳定，支持回滚到较早的Deployment历史版本。每次回滚都会更新Deployment的修订历史（revision）。
• 扩容Deployment以满足更高的负载。
• 暂停Deployment对其PodTemplateSpec进行修改，然后恢复它以启动新的展开。
• 根据Deployment的状态判断展开是否卡住。
• 清理那些不再需要的旧的ReplicaSet。

四、StatefulSet

StatefulSet是用来管理有状态应用的工作负载API对象。StatefulSet管理一组Pod的部署和伸缩，并为这些Pod提供序号和唯一性保证。StatefulSet与Deployment相同的是都管理了基于相同容器定义的一组Pod，但与Deployment不同的是，StatefulSet为它所管理的每一个Pod维护了一个固定的ID。这些Pod都是基于相同的声明来创建的，但是不能相互替换，无论怎么调度，每个Pod都有一个永久不变的ID。

StatefulSet适用于有以下某个或多个需求的应用：

• 稳定、唯一的网络标识符。
• 稳定、持久化存储。
• 有序、优雅的部署和伸缩。
• 有序、自动的滚动更新。

StatefulSet是为了解决有状态服务的问题而设计的，Deployments和ReplicaSets是为无状态服务而设计。如果应用程序不需要任何稳定的标识符或有序的部署、删除或伸缩，则应该使用由一组无状态的副本控制器提供的工作负载来部署应用程序，比如Deployments或ReplicaSets。

StatefulSet具有以下局限性：

• 给定Pod的存储必须由PersistentVolume Provisioner根据请求的storage class进行配置，或由管理员预先配置。
• 删除或者伸缩StatefulSet并不会删除之关联的存储卷。这确保了数据安全性，它通常比自动清除StatefulSet所有相关的资源更有价值。
• StatefulSet目前需要Headless Service来负责Pod的网络标识。要使用StatefulSet必须创建此服务。
• 当删除StatefulSet时，StatefulSet不提供任何终止Pod的保证。为了实现StatefulSet中的Pod可以有序和优雅的终止，可以在删除之前将StatefulSet缩减为0。
• 在通过默认Pod管理策略（OrderedReady）使用滚动更新是时，可能会进入需要手动干预才能修复的损坏状态。

StatefulSet的Pod具有唯一的标识，该标识与Pod绑定，不管它被调度到哪个节点。该标识包括：

• 有序索引：对于具有N个Pod副本的StatefulSet，StatefulSet中的每个Pod都将被分配一个整数序号，从0到N-1，该序号在StatefulSet上唯一。
• 稳定的网络ID： StatefulSet通过Headless Service控制它的Pod的网络域。在每个Pod创建成功时就会得到一个匹配的DNS子域，格式为$(podname).$(governing service domain)，其中所属服务由StatefulSet的serviceName字段设定。Pod的DNS的完整格式为$(statefulset name)-$(ordinal).$(governing service name).$(namespace).svc.cluster.local。
  • Pod主机名（podname）：根据StatefulSet的名称和Pod的序号派生出来，格式为$(statefulset name)-$(ordinal)。
    • statefulset name：StatefulSet的名称。
    • ordinal：Pod所在序号。
  • 所属服务域名（governing service domain）：所属服务域名的格式为$(governing service name).$(namespace).svc.cluster.local。
    • governing service name：StatefulSet所属服务名。
    • namespace：服务所属名称空间。
    • cluster.local：集群域，默认会被设置为cluster.local。
• 稳定的存储：Kubernetes会为每个VolumeClaimTemplate创建一个PersistentVolume（持久卷）。 当一个Pod被调度或重新调度到节点上时，它的volumeMounts将挂载与其PersistentVolumeClaim相关联的PersistentVolume。注意，当Pod或StatefulSet被删除时，与PersistentVolumeClaim（PVC）相关联的PersistentVolume不会被删除，要删除它必须通过手动方式完成。

五、DaemonSet

DaemonSet确保全部（或者某些）节点（Node）上运行一个Pod的副本。当有节点加入集群时，也会为他们新增一个Pod 。当有节点从集群移除时，这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod。DaemonSet的一些典型用法如下：

• 在每个节点上运行集群存储守护进程。例如glusterd、ceph。
• 在每个节点上运行日志收集守护进程。例如fluentd、logstash。
• 在每个节点上运行监控守护进程。例如Prometheus Node Exporter、collectd、Datadog agent、New Relic agent和Ganglia gmond等。

六、Job

Job会创建一个或者多个Pod，并确保指定数量的Pod成功终止。随着Pod成功结束，Job会跟踪记录成功完成的Pod个数。当数量达到指定的成功个数阈值时，任务即Job结束。删除Job会清除所创建的全部Pod。

七、CronJob

CronJob创建基于时间调度的Job。一个CronJob对象类似于crontab (cron table)文件中的一行。它用Cron格式进行编写，并周期性地在给定的调度时间执行Job。CronJobs对于创建周期性的、重复的任务很有用，例如执行数据备份或者发送邮件。CronJobs也可以用来计划在指定时间来执行的独立任务，例如计划当集群看起来很空闲时执行某个Job。

在创建CronJob资源清单时，需确保所提供的名称是一个合法的DNS子域名。名称不能超过52个字符，因为CronJob控制器将自动在提供的Job名称后附加11个字符，并且存在一个Job名称的最大长度不能超过63个字符的限制。

cs