返回首页

Kubernetes:30% 节点故障测试

本文描述了生产 Kubernetes 集群中通过禁用 30% 节点进行的紧急演练。识别出 Kyverno、调度问题以及关于 PDB、拓扑约束的建议。团队成功标准和检查清单。

在 K8s 中禁用 30% 节点:真实中断和修复
Advertisement 728x90

Kubernetes故障转移演练:生产环境宕机30%节点

团队在基于OKD的Kubernetes生产集群中,主动关闭了30%的节点,以暴露系统韧性中的真实短板。此次演练检验了控制平面、基础设施组件及应用服务在重大基础设施故障下的响应能力。此前在正常运行时难以察觉的Webhook控制器问题与副本分布缺陷,在此次测试中清晰浮现。

测试中的集群架构

该集群部署于云环境,横跨三个可用区,每个区域位于独立数据中心,彼此间延迟低于1毫秒。全网状拓扑结构模拟了本地网络行为。

关键组件:

Google AdInline article slot
  • 用户流量负载均衡器:后端为3个基础设施节点,运行Ingress Pod和持久卷控制器。
  • API负载均衡器:后端为3个主节点,承载控制平面。
  • 工作节点:均匀分布在各可用区,共N个。

此架构支持模拟整个可用区故障,同时不破坏集群法定人数——etcd可承受最多一个主节点丢失。

灾难演练准备计划

演练方案包含8个步骤:

  • 验证集群与服务的基础健康状态。
  • 对主节点和基础设施节点进行快照,以便快速回滚。
  • 关闭一个可用区的所有节点(或1个主节点、1个基础设施节点 + 30%的工作节点)。
  • 监控1–2小时:记录失败日志、收集指标、协调支持团队。
  • 恢复已关闭节点。
  • 重新验证集群状态。
  • 完成演练。
  • 整理待办事项并归档。

演练中优先使用快照而非etcd备份——恢复更快,风险更低。工作节点无需备份,因其状态由etcd管理;而基础设施节点因持有持久卷,必须备份。

Google AdInline article slot

30%是一个合理目标:既模拟了现实中的节点故障场景(用于测试反亲和性、PDB、副本复制),又不至于造成灾难性后果。主节点法定人数可承受最高33%的损失。

成功标准:

  • API接口保持可访问。
  • 能够创建和删除Pod。
  • 持久卷持续可用。
  • 服务正常运行。
  • 副本恢复时间在10–15分钟内。
  • 所有告警恢复正常(除离线节点引发的告警外)。

演练#1:开发环境集群

关闭1/3节点:1个主节点、1个基础设施节点、约80个工作节点核心。负载均衡器在一分钟内移除了不健康的后端。API保持响应,但节点进入未知状态长达300秒(默认超时),随后变为NotReady/Unreachable。

Google AdInline article slot

Pod未在10分钟内重启。尝试创建新Pod时出现错误:

Error from server (InternalError): error when creating "pod.yaml": Internal error occurred: failed calling webhook "mutate.kyverno.svc-fail": failed to call webhook: Post "https://infra-kyverno-svc.infra-kyverno.svc:443/mutate/fail?timeout=30s": dial tcp 10.128.4.174:9443: connect: connection refused

Kyverno(准入/变更Webhook)每个类型仅有一个Pod,其中2/3位于被关闭的可用区,现已进入终止状态。无活跃Webhook导致变更无法写入etcd。系统命名空间已排除在Kyverno管控之外,防止死锁。

增加Kyverno副本数后,事件显示调度受阻,原因应为资源不足(虽未明说,但上下文可推断)。

问题与解决方案

Kyverno:调整为每类Webhook至少3个副本,并采用跨可用区拓扑分布策略。

调度阻塞:检查受影响命名空间的资源配额与限制。

在生产环境(演练#2与#3)中,类似场景的大规模测试揭示了部分服务因缺乏正确反亲和性配置而导致PDB违规,以及持久卷迁移延迟等问题。

应用团队收到一份检查清单:

  • 至少设置3个副本。
  • 配置PodDisruptionBudget,使用minAvailable
  • 使用TopologySpreadConstraints或nodeAffinity实现可用区分布。
  • 设置合理的CPU/RAM请求与限制。
  • 健康探针设置5–10秒超时,重试3次。

最关键的经验

  • 关闭30%节点能暴露出常规状态下隐藏的Webhook与调度问题。
  • Kyverno需部署多个副本,且均匀分布在不同可用区。
  • 300秒的NotReady/Unreachable超时是默认值,但需预留缓冲资源。
  • 基础设施与主节点的快照对安全演练至关重要。
  • 完全恢复耗时:副本恢复10–15分钟 + 告警清除。

给团队的建议

对服务开发者:

  • 设置PDB:minAvailable: 50%
  • 使用topologySpreadConstraints确保可用区分布。
  • 将CPU/RAM请求/限制设为观测峰值的80%。
  • 探针设置5–10秒超时,允许3次重试。

对Kubernetes管理员:

  • 确保Kyverno及其他Webhook拥有超过3个副本,具备高可用性。
  • 监控etcd领导者选举状态。
  • 规划容量时预留30%冗余。
  • 每次演练前自动执行快照。

任何节点超过100个的生产集群,此类演练都是必不可少的。

— Editorial Team

Advertisement 728x90

继续阅读