大哥，你是一眼都没看里面的架构图啊。

kube-rescheduler：重调度模块，自动轮询集群状态，并发起异常 pod 的漂移
kube-odin：弹性云的上游 pass 层，用户通过 kube-odin 接入弹性云
galahad：调度规则引擎，按标签选取业务 pod 或 node 的调度策略存储，主要解决物理机集群差异化，快速变化的需求与 k8s 集群管理的灵活度匹配
kube-hook：k8s 的 mutatingwebhook 和对应服务，用于将 galahad 注入 pod 或 node
master：原生的 k8s 三大件
ipam：弹性云的 pod ip 分配模块
IRMAS：内核组件，包括 Odin-Agent 监控数据上报、pod quota 分配等能力
kube-agent：node 组件，做真实使用率数据的获取和写入
zhivago：基于 Prometheus 的服务画像引擎，涉及数据清洗，数据分析，数据存储，大盘展示等多个模块


滴滴的 k8s 集群是跨地域、超 5k node，每个节点调度多少个 pod，pod 的生命周期多长，都是他们写的调度程序 kube-rescheduler/galahad

对于节点扩缩容也是一样的。升级的过程中，是可以只升级一部分，但是如果 api 兼容没做好的话，会让监控程序认为它挂了， 调度程序就会把监控异常的 pod 都干掉。。。

至于为什么会kill 掉控制平面，这个就看调度程序是什么毛病了。

如果用的是官方那一套自然不会出现这个问题，但滴滴没有用官方的调度、升级等逻辑。

和防火墙是一样的行为。给自己一个没有困难也要自己创造的困难