影响 Kubernetes 控制平面可用性的隐藏故障路径
这件事讲了什么
这篇文章讲的是 Kubernetes 控制平面在集群规模变大后,一些平时看起来正常的设计反而会把小问题放大成故障。作者举了三个真实例子:一个扩展 API 升级依赖后发布了不合法的 OpenAPI 模式,结果连只用普通 Kubernetes 资源、根本没用这个扩展的 Helm 部署也失败,因为 OpenAPI v2 把所有 API 的定义合并成一份文档,一个扩展出错就拖累所有人;大批 DaemonSet 代理同时重启,启动时的正常请求叠加成风暴,API 服务器扛不住;还有组件把依赖服务的短暂不可用误判成自己进程坏了,反复重启。文章建议用 OpenAPI v3 缩小影响范围、控制重启节奏、别让健康检查过度依赖下游。这是经验分享文章,没有发布新工具,文中提到的 OpenAPI v2/v3、informer、聚合 API 服务器、PR #131755 都是已有机制或改动。
可以使用的工具
文中可用工具
- OpenAPI v2把所有 API 的接口定义合并成一份文档供客户端读取校验
- OpenAPI v3按 API 组和版本分开提供接口定义,缩小单个扩展出错的影响范围
- informer让控制器在本地缓存集群状态,减少反复查询 API 服务器
- 聚合 API 服务器(aggregated API server)在不改核心 API 服务器的前提下给 Kubernetes 增加新 API
- Helm部署图表前会读取 OpenAPI 文档做校验,因此可能被无关扩展的错误波及
- DaemonSet在集群每个节点上运行代理,大规模重启时会集中产生请求
- Kubernetes PR #131755让 OpenAPI 模型名称由作者显式声明,而不是从 Go 包路径推导
讨论 0
登录后参与讨论,阅读资讯无需注册。
还没有评论,来分享第一个看法。