规模不是一个数字：Kubernetes 控制平面空间不足的三种情形
内容提要
文章指出Kubernetes控制平面存在三类瓶颈：训练集群受节点数量限制，代理平台因对象频繁创建销毁而承受高写入压力，平台集群则因大量对象常驻内存而受限。作者提出四个“接缝”方案：分离存储、优化节点心跳、按哈希分片、控制缓存驻留，主张采用上游原生组件和经过规模测试的配置来解决，而非简单增加apiserver。
延伸解读
三种瓶颈，三种解法
文章将控制平面压力分为节点绑定、频繁写入绑定和状态绑定三类，分别对应训练集群、代理平台和平台集群。关键点在于三者相互独立：解决节点数量问题不会缓解频繁写入压力，增加 apiserver 也不会减少常驻内存。因此，按节点数统一调优可能适得其反，需要先识别集群属于哪一类瓶颈。
增加 apiserver 为何可能更糟
文章指出，每增加一个 apiserver 都会复制整个 watch 缓存，虽然提升了请求处理能力，却以内存为代价。对于状态绑定的平台集群，这恰恰加剧了问题。作者强调，规模扩展的关键在于明确每个存储组件应承载什么，而非简单堆叠 apiserver；上游原生组件经过规模测试的配置才是可行路径。
四个接缝的现状与缺口
文章提出存储契约、节点存活契约、分片轴和缓存驻留四个接缝。存储契约可通过 --etcd-servers-overrides 路由内置资源，但尚不支持自定义资源；节点存活契约可借助 etcd 内存租约刷新降低写入；分片轴有 KEP-5866 的哈希范围过滤基础，但协调与控制器分片仍待完善；缓存驻留尚无上游实现，原型仅将堆内存减半。这些缺口意味着方案尚未完整落地。
规模测试配方仍缺失
文章坦言，目前只有节点数量这一轴有测量数据支撑，频繁写入绑定和状态绑定集群尚无公开的规模测试配方。作者主张以 CI 测试的配置形式发布上游原生组件，使规模变化能通过测试失败提前暴露。读者应注意，现有方案多为原型或草案，实际采用需评估成熟度与自身瓶颈类型。
Q&A
Kubernetes控制平面空间不足有哪几种典型情形？
文章指出三种情形：1）节点绑定型：训练集群节点数量大，kubelet心跳产生大量写入；2）变更绑定型：代理平台对象频繁创建销毁，写入压力大；3）状态绑定型：平台集群对象多且常驻内存，每个apiserver都保存全量副本。
为什么简单增加apiserver数量可能让问题更糟？
因为每个新增的apiserver都会复制整个watch缓存，虽然增加了请求处理能力，但内存消耗也成倍增加，对于状态绑定型集群尤其有害。
什么是“接缝”（seams）？文章提出了哪四个接缝？
接缝是组件之间的契约，通常位于网络边界，可替换而不修改上游。四个接缝是：1）存储契约：分离存储；2）节点存活契约：优化心跳；3）分片轴：按哈希分片；4）缓存驻留：控制缓存驻留。
如何缓解节点数量大导致的心跳写入压力？
有两种可组合的方法：1）在控制平面前置一个面向节点的层级，处理续约并只传播真实状态变化；2）通过etcd的内存租约刷新来路由续约，避免完整的Raft提交。
对于对象频繁创建销毁的代理平台，有什么存储层的优化方案？
可以使用--etcd-servers-overrides将临时性资源（如事件、租约）路由到不同的后端存储，减轻主etcd的压力。但该参数目前只支持内置资源，无法路由自定义资源。
状态绑定型集群面临的主要问题是什么？如何解决？
主要问题是每个apiserver都持有所有对象的缓存副本，内存占用大。解决方案是控制缓存驻留，例如通过分片减少每个apiserver的缓存对象，原型显示两分片可减少约一半堆内存。
