k8s控制器模型介绍

基础概念

          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,最终达到与申明一致