Kubernetes 故障注入用 Chaos Mesh 模拟 GPU 节点宕机一、GPU 节点宕机的真正代价不是计算中断是调度链的雪崩GPU 节点是推理集群中最昂贵的资源。一台 8×A100 的节点单月成本可能超过 5 万元。当这样一台节点宕机时运维的第一反应是赶紧把它拉回来。但这个思路是错误的——真正需要关心的是宕机事件在集群调度链上引发了什么连锁反应。典型场景一个 GPU 节点突然 NotReady。Kubernetes 调度器在 5 分钟后将上面的 Pod 标记为 Terminating然后尝试将它们重新调度到其他 GPU 节点上。但此时其他节点可能没有足够的 GPU 资源——它们已经被其他推理服务占满了。Pod 进入 Pending 状态HPA 检测到可用副本数下降尝试扩容——但扩容需要新节点加入集群而新节点的启动包括 GPU 驱动加载、模型预拉取需要 5-8 分钟。在这 5-8 分钟里剩余的 GPU Pod 承担了全部流量。如果它们扛不住服务就会降级上游触发熔断整个链路进入降级模式——而这一切的根因只是一台 GPU 节点宕机。故障注入的目的不是制造灾难而是在受控条件下再现这个场景测量系统的实际恢复时间和业务影响。如果恢复时间超过 SLO 允许的窗口就需要重新设计调度和弹性策略。二、Chaos Mesh 的 GPU 节点故障注入架构Chaos Mesh 是 CNCF 沙箱项目提供了 PodChaos、NetworkChaos、StressChaos 等多种故障类型。模拟 GPU 节点宕机核心使用的是 PodChaos 和 NodeChaos。graph TD subgraph Chaos Mesh 控制面 A[Chaos Dashboard / kubectl] -- B[chaos-controller-manager] B -- C[chaos-daemon] end subgraph 目标集群 C -- D[GPU Node 1] C -- E[GPU Node 2] C -- F[GPU Node 3] D -- G[推理 Pod A1] D -- G2[推理 Pod A2] E -- H[推理 Pod B1] F -- I[推理 Pod C1] F -- I2[推理 Pod C2] end subgraph 故障注入 B -- J[PodChaos: pod-kill] J -- G J -- G2 B -- K[NodeChaos: node-reset] K -- D end subgraph 观测验证 L[Prometheus] -- M[Pod 恢复时间] L -- N[推理错误率] L -- O[GPU 利用率变化] L -- P[HPA 扩缩行为] endChaos Mesh 提供了两种粒度的 GPU 故障模拟PodChaos pod-kill精细控制——只杀特定 Label 的推理 Pod不触发节点级事件。适合验证单个服务的自愈能力。NodeChaos node-reset更真实的模拟——直接让节点不可达所有该节点上的 Pod 同时被驱逐。这是最接近真实 GPU 节点宕机的场景。对比手动 kubectl delete podChaos Mesh 支持定时执行、条件触发如每 30 分钟杀 30% 的 Pod、自动停止错误率超过 10% 或运行 1 小时后自动回滚。手动操作无法提供这些安全网。三、Chaos Mesh 故障注入的生产配置# 1. 安装 Chaos Mesh如果尚未安装 # helm repo add chaos-mesh https://charts.chaos-mesh.org # helm install chaos-mesh chaos-mesh/chaos-mesh --namespacechaos-mesh --create-namespace --- # 2. PodChaos: 定期随机杀推理 Pod apiVersion: chaos-mesh.org/v1alpha1 kind: PodChaos metadata: name: kill-inference-pods-weekly namespace: chaos-testing # 在专用命名空间执行 spec: action: pod-kill mode: fixed-percent value: 30 # 每次杀 30% 的匹配 Pod selector: namespaces: - inference-prod # 目标命名空间生产环境 labelSelectors: app: llm-inference # 只影响推理服务 scheduler: cron: 0 3 * * 3 # 每周三凌晨 3 点执行 duration: 5m # 实验持续 5 分钟 gracePeriodSeconds: 0 # 立即杀不等待优雅终止 --- # 3. NetworkChaos: 模拟 GPU 节点网络分区 apiVersion: chaos-mesh.org/v1alpha1 kind: NetworkChaos metadata: name: gpu-node-network-partition namespace: chaos-testing spec: action: partition mode: one # 只影响一个节点模拟单节点故障 selector: nodes: - gpu-node-03 # 指定 GPU 节点 direction: both target: mode: all selector: namespaces: - kube-system - monitoring duration: 10m # 10 分钟后自动恢复 scheduler: cron: 0 14 * * 5 # 每周五下午 2 点 --- # 4. StressChaos: GPU 内存压力测试 apiVersion: chaos-mesh.org/v1alpha1 kind: StressChaos metadata: name: gpu-memory-stress namespace: chaos-testing spec: mode: one selector: nodes: - gpu-node-02 stressors: memory: workers: 4 size: 80% # 占用 80% 内存验证 OOM 行为 duration: 15m配合观测指标的 Prometheus 查询# Pod 恢复时间从 Terminating 到 Ready 的时间差 max( time() - kube_pod_status_ready_time{ pod~llm-inference.* } ) by (pod) # 推理服务错误率混沌实验期间 sum(rate(http_requests_total{ servicellm-inference, code~5.. }[1m])) / sum(rate(http_requests_total{ servicellm-inference }[1m])) # HPA 副本数变化 kube_hpa_status_current_replicas{ hpallm-inference-hpa }安全网设置——Chaos Mesh 支持自动回滚条件# 在 PodChaos 上添加条件性停止注解 metadata: annotations: experiment.chaos-mesh.org/pause-if: | rate(http_requests_total{code~5..}[2m]) 0.05 experiment.chaos-mesh.org/stop-if: | kube_deployment_status_replicas_available 1四、生产环境故障注入的风险管控命名空间隔离是第一道防线。永远不要在没有 Namespace 过滤的情况下运行 PodChaos。一个没有selector.namespaces限制的 pod-kill 可能意外杀死 kube-system 下的核心组件CoreDNS、kube-proxy。从 Staging 到 Production 的渐进策略。第一周在 Staging 跑 pod-kill 20%第二周加到 50%第三周在 Production 的非核心服务上跑 10%。逐步放大比例和影响范围每一步都要确认观测指标正常后才进入下一步。这个过程不能压缩——一个未经 staging 验证的混沌实验直接进生产和直接在生产环境上跑rm -rf没有区别。人不在就别跑原则。混沌实验的定时执行时间必须选在核心工程师在线的时间段。凌晨 3 点自动杀 Pod 后如果恢复失败第二天早上用户投诉堆积如山这是可以避免的操作风险。建议在正常工作时间如上午 10 点执行首次实验团队随时待命。三周后如果实验稳定通过再移到低流量时段。GPU 节点的特殊性。GPU 节点宕机和普通计算节点宕机有本质区别GPU Pod 的重调度需要满足 GPU 资源约束nvidia.com/gpu: 1而集群中 GPU 资源通常高度紧张。一个 GPU 节点的宕机可能导致 GPU Pod 无法重调度没有符合要求的节点而不是被调度到其他节点。这要求在 Chaos 实验的验证清单中明确加入GPU Pod 重调度成功率这一指标。五、总结GPU 节点宕机不是会不会发生的问题而是发生之后系统需要多久恢复的问题。Chaos Mesh 提供了可控的故障注入能力让团队在受控条件下测量这一时间并在问题暴露给用户之前修复调度链的薄弱环节。落地三步第一步在 Staging 集群安装 Chaos Mesh运行首次 PodChaos pod-kill 实验杀 20% 推理 Pod测量恢复时间和错误率第二步将实验固化为 CronJob每周自动执行并将恢复指标接入 Prometheus 告警恢复时间 60s 则告警第三步逐步将实验扩展到 GPU NodeChaos验证完整的节点宕机恢复链路。基础设施不需要漂亮话。它需要的是在 GPU 节点真的宕机的那一天你不会收到凌晨 3 点的告警电话。