基础概念
k8s操作pod对象的所有业务逻辑 都是由各种控制器来完成的
k8s的所有控制器都存储在pkg/controller目录下 这个目录下的每个控制器都以自己的方式负责某种编排功能
它们都遵循着一种通用的编排模式 控制循环(control loop)= 调谐循环 = 同步循环
通过在一个无限循环中 比较某个编排对象的两种状态 使对象的实际状态无限的等于对象的期望状态
1.期望状态来源 用户提交的YAML文件 保存在etcd中
2.实际状态来源 集群中的动态信息
控制器的定义
被控制对象的定义,则来自于一个“模板”.比如，Deployment 里的 template 字段.可以看到,Deployment 这个 template 字段里的内容,跟一个标准的 Pod 对象的 API 定义,丝毫不差.而所有被这个 Deployment 管理的 Pod 实例,其实都是根据这个 template 字段的内容创建出来的.
像 Deployment 定义的 template 字段,在 Kubernetes 项目中有一个专有的名字,叫作 PodTemplate(Pod 模板).大多数控制器，都会使用 PodTemplate 来统一定义它所要管理的 Pod.还有其他类型的对象模板,比如 Volume 的模板.
在所有 API 对象的 Metadata 里,都有一个字段叫作 ownerReference,用于保存创建当前这个 API(Pod) 对象的拥有者（Owner）的信息
控制循环的编排原理
这些控制循环最后的执行结果,要么就是创建,更新一些 Pod(或者其他的 API 对象,资源),要么就是删除一些已经存在的Pod(或者其他的 API 对象,资源)
正是在这个统一的编排框架下,不同的控制器可以在具体执行过程中,设计不同的业务逻辑,从而达到不同的编排效果
这个实现思路,正是 Kubernetes 项目进行容器编排的核心原理
“控制器模式”和“事件驱动”的区别
事件往往是一次性的,如果操作失败比较难处理,但是控制器是循环一直在尝试的,更符合kubernetes申明式API,最终达到与申明一致