控制器的协同原理
最对K8s这种分布式的系统，它是微服务管理系统，就是我有一个业务流，但是这个业务流是由不同的组件配合完成的，高内聚，松耦合。
就是将同一个职责放在一个组件里面去，把不同的职责放在不同的组件，k8s遵循了这样一个原则，将不同的职责放到不同的对象里面而已。
deployment对象描述的是一次部署行为，行为里面描述了需要什么样的pod，然后副本数是多少，这个副本级本身就会由replicaset来代表，replicaset语义就是无状态的副本集，replicaset里面也是有这个信息，比如pod的模板是什么，replicas数是多少，然后就需要去建立副本了，所以就是一个一个的pod，所以从api的定义来说，针对无状态应用最上面是deployment，因为定义的是部署的策略，所以它里面有额外的updatestrategy，replicastet定义的是副本集，pod是真正的应用实例，这三者配合完成整个无状态应用部署的目的。
那么kubermets就是由不同的控制器协同工作来完成统一的目的。
针对deployment来说，它默认属性是哪些呢？就是有一个rolling update strategy，还有一个reversion history，所以deployment就是用来定义一次部署策略和描述部署行为。
在升级时候的策略是滚动升级，它里面有两个重要的属性，一个是maxsurge，一个是maxunaviliable。
maxsurge是pod升级的时候，先启动25%，假设原来100个pod，先启动25%就是先启动25个pod，maxunaviliable是说如果有25%的pod不ready，那我这次部署就需要停下来。
滚动升级策略就是我有100个副本的时候，那么我会去批次升级，同时控制好频度。
reversion history limit记录的就是说我要存多少版本，这样方便我回滚。
deployment创建好之后，controler manager里面就有deployment controler，它会watch deployment，除了之前的升级策略，还会看replicas多少个副本，template模板是什么。
副本加模板组合其实就是副本集，所以control职责就是监听deployment的对象，并且创建replicaset。
replicaste创建出来之后，control manager里面replicaset controller就监听了这个创建事件，他就会根据replicaset里面定义的模板和副本数去创建pod。
pod创建完之后就会使用调度器去调度pod，因为pod本身，在创建的时候还没有还没有被调度。
所以它现在是pending的状态，它的nodename是没有的，之后完成调度和节点产生绑定关系。
这个节点上面有kubelet，kubelet会去监听和我这个节点产生绑定关系的pod，比如使用get pod -o wide可以查看到，那么kubelet就会去看调度的节点和我当前的节点hostname是否是一致的，那么说明我这里面是要启动这个pod的，那么kubelet就会去调用cri，来启动容器实例，调用cni为pod配置网络，如果有存储需求，那么就会调用csi接口。
可以看到建立了诸多组件的配合。
