编排其实很简单：谈谈“控制器”模型

• 简短
• 精细

kube-controller-manager 组件

https://github.com/kubernetes/kubernetes/tree/master/pkg/controller
该目录下每一个控制器都负责某种编排功能，包括 Deployment。

它们遵循 Kubernetes 项目中一个通用编排模式：控制循环(control loop)。

比如，一个带编排对象X，有一个对应控制器，用 Go 为代码描述这个控制循环：

for{
    实际期望 := 获取集群中对象X的实际状态(Actual State)
    期望状态 := 获取集群中对象X的期望状态(Desired State)
    if 实际状态 == 期望状态 {
        什么都不做
    } else {
        执行编排动作，将实际状态调整为期望状态
    }
}

具体实现中，实际状态往往来自于 Kubernetes 集群本身。
如：kubectl 通过心跳汇报的容器状态和节点状态，或监控系统中保存的应用监控数据，或控制器主动收集感兴趣的信息等…
期望状态，一般来自于用户提交的 YAML文件。

Kubernetes 对象的主要编排逻辑，是在获取实际状态和期望状态后的“比较”阶段完成。
这个操作，叫做 调谐(Reconcile)。调谐的过程叫做 调谐循环(Reconcile Loop) 或 同步循环(Sync Loop)。

调谐，控制循环，的最终结果都是对被控制对象的某种写操作，增加、删除、更新Pod，这是 Kubernetes 项目“面向 API 对象编程”的直观体现。

Deployment 定义的 template 字段，在 Kubernetes 项目中有个专有名字，PodTemplate（Pod模版）。