影响Kubernetes控制面可用性的隐蔽失败路径

Kubernetes控制面虽设计为隔离单点故障，但可用性仍取决于关键路径组件在压力下的行为；舰队规模下组件不必崩溃也能参与宕机，合法机制可通过共享元数据、同步启动工作或过于激进的健康检查放大局部缺陷。例如informer为控制器提供集群状态本地视图，避免反复查询API服务器，独立启动时高效；但大量控制器同时重启重建视图会给控制面带来显著压力，informer本身变成放大器。文章剖析三例：其一，扩展API服务器在依赖升级后发布无效模式，阻断从未使用该API的客户端；其二，DaemonSet代理在大舰队重启，把例行启动变成API服务器无法消化的请求风暴；其三，API请求路径上组件的深度存活检查把依赖中断当成进程故障，在依赖仍不可用时反复重启。对运行扩展API、监视大量对象的控制器，以及依赖深度检查的API路径组件的团队尤具参考。某集群中，仅含标准资源的Helm部署开始失败：失败经元数据与合并各注册API定义的schema文档传播，用户在请求到达API服务器前就看到校验错误。聚合API服务器以组/版本/kind对外呈现，生成OpenAPI描述对象字段；OpenAPI v2是/openapi/v2上的单一合并文档，扩展损坏波及面大；v3按API组与版本拆分，使用核心API的客户端不必拉取每个扩展文档，冲击面更窄。