《深入剖析Kubernetes》总结五：控制器与编排

在线任务编排

控制器（Controller）：操作容器，比如Deployment，是k8s第一个重要的设计思想，叫作控制器模式

kube-controller-manager：一系列控制器的集合

$ ls -d kubernetes/pkg/controller/
deployment/ job/ podautoscaler/
cloud/ disruption/ namespace/
replicaset/ serviceaccount/ volume/
cronjob/ garbagecollector/ nodelifecycle/

该目录下的控制器遵循同一个通用编排模式：控制循环（control loop）。原理类似CAS操作，即如果对象X的实际状态等于期望状态，则可以什么都不做；如果不等于，则执行编排动作，将实际状态调整为期望状态

实际状态来源：kubelet 通过心跳汇报的容器状态和节点状态、监控系统中保存的应用监控数据，控制器主动收集的它自己感兴趣的信息等

期望状态：一般来自于用户提交的 YAML 文件

主要编排逻辑就是对比操作，被叫作调谐（Reconcile），这个调谐的过程，则被称作“Reconcile Loop”（调 谐循环）或者“Sync Loop”（同步循环）；
而调谐的最终结果，往往都是对被控制对象的某种写操作。 比如，增加 Pod，删除已有的 Pod，或者更新 Pod 的某个字段，这也是 Kubernetes “面向 API 对象编程”的一个直观体现。

以Deployment为例：

如上图所示，类似 Deployment 这样的一个控制器，实际上都是由上半部分的控制器定义（包括期望状态），加上下半部分的被控制对象的模板组成的；
Deployment 里的 replicas=2 这个字段负责定义被管理对象的期望状态；
被控制对象的定义，则来自于一个“模板”，比如，Deployment 里的 template 字段， 这个 template 字段里的内容，跟一个标准的 Pod 对象的 API 定义是一样的，所有被这个 Deployment 管理的 Pod 实例，其实都是根据这个 template 字段的内容创建出来的。

在所有 API 对象的 Metadata 里，都有一个字段叫作 ownerReference，用于保存当前这个 API 对象的拥有者（Owner）的信息；
对于一个 Deployment 所管理的 Pod，其ownerReference为ReplicaSet，详情请继续往下看

控制器模式的实现介绍：Deployment

Deployment实现了Pod 的“水平扩展 / 收缩”（horizontal scaling out/in）；
比如如果更新了 Deployment 的 Pod 模板（比如，修改了容器的镜像），那么 Deployment 就需要遵循一种叫作“滚动更新”（rolling update）的方式，来升级现有的容器。

实现方式：ReplicaSet（API对象）,其结构为：

apiVersion: apps/v1
kind: Rep