apiserver、kube-scheduler、kube-controller-manager原理分析

Aggregator、kubeapiserver、apiExtensionServer

1、 Aggregator相当于7层负载，提供各种路由转发

        资源的注册与删除、openapi文档的同步、管理crd

2、kubeapiserver处理通用请求

        处理api resource的操作请求、为api提供restfulapi

3、apiExtensionServer处理（CRD）Customer Resource Definition的请求

        list wathc是apiserver最核心的设计，通过rpc的双向推流，将数据退给scheduler、controller、kubelet，将所有组件间的交互给解耦开，

list watch的关键设计：

• 基于chunk的消息通知
• 本地缓存&本地索引
• 无界队列&事件去重
• 基于观察者模式的注册

即使部署了多节点，在1个时点只能有1个kube-scheduler、kube-controller-manager起作用

与etcd一致其他节点只负责转发

kube-controller-manager是大内总管-控制所有的控制器

事件分发、接受和处理事件

工作流程：获取事件、informer分发、调用controller

从apiserver获取状态，并且向对应的状态迁移

主要用于计算，分配调度pod到集群内的节点，通过两种方式：两层循环、两次确认

scheduler计算适合pod的节点， 相当于上帝为天使寻找父母，

通过硬编码实现好的固定计算逻辑

        预选（节点剩余资源、节点port是否冲突、lable是否匹配、节点磁盘空间是否匹配）、

        优选阶段（通过可量化的算法计算出节点的得分）

第一次循环：

（1）创建一个informer ，从apiserver拿最新的pod和node数据，找到需要创建的pod

（2）根据预选算法，选择预选家庭，数据主要是从listwatch的缓存里筛选出来的，listwatch的缓存里的数据是和etcd一致的

第二次循环：

（1）按多种维度对节点进行排序、打分，得分最高的是pod可以创建的节点

两次确认：

（1）调用apiserver，将计算出的node节点结果给到apiserver 

（2）apiserver将这个结果，再给到计算出的node节点上的kubelet

（3）kubelet进行确认，判断当前节点是否满足创建pod，确认后将结果给到apiserver

（4）apiserver将消息给到scheduler，如果结果是节点不满足，会将节点排除掉，然后再将另一个节点给到apiserver，再给到对应节点的kubelet进行判断，确认后再将结果给会apiserver，直到找到符合的节点；如果kebelet回复的结果是没问题且创建成功，apiserver记录创建结果到etcd，etcd更新成功后，apiserver将结果推送给scheduler

（5）scheduler更新自己cache的数据

（6）同时apiserver也会将消息推送给controllermanager，controllermanager触发他对应的controller，去检查pod有没有创建好，并监控pod的状态，

大部分都是通过硬编码实现好的固定计算逻辑，可自定义控制的只有NodeSelector、NodeAffinity、PodAffinity、污点与容忍

scheduler通过两层循环，两次确认挑选出合适创建pod的节点

scheduler通过内置的预选和优选规则挑选节点，可以根据业务实现自定义调度器