AI 资源库 · 已整理 2 项

高可用

查看与高可用相关的 AI 资讯、工具、Skill、工作流和开源项目。

研究与技术

影响 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 包路径推导
# Kubernetes# 故障排查# 控制平面# OpenAPI# 高可用
☆ 收藏查看来源 ↗
评论 · 分享第一个看法
行业动态

高可用不等于韧性：为何云系统总在关键时刻失效

一位工程师在文章里讲了一次真实故障：一次普通的 TLS 1.3 升级，悄悄把 Route 53 的健康检查弄坏了，结果 CDN 不再把流量送到其实正常运转的区域，而内部监控看板却显示一切正常。作者 Alexey Golev 想说明的是，「高可用」和「韧性」是两回事——高可用指系统平时不容易坏，韧性指真出事时能不能扛住并恢复；云服务里很多关键功能依赖看不见的控制面，一旦出问题很难被发现；如果没人明确负责，恢复能力会慢慢退化。读者能借此检查自家系统是否也有这种「看板正常但其实已挂」的隐患。至于具体怎么修、有没有配套工具，原文未说明。

文中可用工具

提供的材料未提及具体可用工具。

# 云基础设施# 事故响应# 高可用# 韧性
☆ 收藏查看来源 ↗
评论 · 分享第一个看法