容器故障排查与应急响应需实现“早发现、快定位、稳恢复”闭环：依托指标/日志/事件联动的可观测性基建，协同配置livenessprobe、restartpolicy与failurethreshold；聚合容器、节点、控制平面、应用四层信号构建多维告警基线；预置可编排带上下文的自动响应动作；恢复后须通过/readyz、endpoints、真实业务请求三层验证，任一失败即回滚并升级告警。
容器环境的自动化故障排查与应急响应，核心是“早发现、快定位、稳恢复”。不依赖人工盯屏或逐条命令排查，而是靠可观测性基建 + 策略化响应动作形成闭环。重点不在堆工具，而在让指标、日志、事件三者联动触发可执行动作。
健康检查与自动重启策略必须协同配置
仅设 livenessProbe 不等于高可用，必须搭配合理的 restartPolicy 和 failureThreshold 才能避免误杀或漏判。
- livenessProbe 每 10–15 秒探测一次，initialDelaySeconds 至少设为应用冷启动耗时的 1.5 倍，防止启动中被误杀
- failureThreshold 建议设为 3，配合 periodSeconds=10，即 30 秒内连续失败才重启，兼顾灵敏与稳定
- Kubernetes 中 restartPolicy 必须设为 Always（默认），否则 probe 失败不会触发重建
- 对批处理类容器，改用 OnFailure 策略，并配合 Job 的 backoffLimit 控制重试次数
故障自动识别需覆盖四层信号源
单靠 Pod 状态或 CPU 使用率容易漏判。应聚合容器运行时、宿主机、编排层、应用层四类信号，构建多维告警基线。
- 容器层：Pod 重启次数突增、CrashLoopBackOff 持续超 2 分钟、容器 OOMKilled 事件
- 节点层：kubelet NotReady、/var/lib/kubelet/pods 目录 inode 耗尽、containerd 进程异常退出
- 控制平面层：API Server request latency > 2s、etcd leader 变更频繁、scheduler pending pods 持续增长
- 应用层：/health 探针返回 5xx、关键接口 P95 延迟翻倍、数据库连接池耗尽告警
应急响应动作要预置、可编排、带上下文
告警不能只发消息，而应自动触发带参数的操作脚本，并记录完整执行上下文供复盘。
- 检测到某命名空间下 5 个以上 Pod 同时 CrashLoopBackOff，自动打标 label：emergency-recovery=true，并触发扩容副本数至原值 2 倍
- 发现节点 NotReady 且持续超 90 秒，自动驱逐该节点上所有非 critical Pod，并标记 node.kubernetes.io/unreachable:NoExecute
- 当存储插件（如 containerd-snapshotter）上报 metadata.db 校验失败，立即停止调度新 Pod，并调用备份恢复脚本还原 /var/lib/containerd/io.containerd.snapshotter.v1.*/metadata.db
- 每次自动操作生成 Event 记录，包含触发条件、执行命令、返回码、耗时，统一推送到审计日志系统
恢复验证必须闭环，不能只看 Pod Running
Pod 状态变为 Running 只代表容器进程启动了，不代表服务真正就绪。恢复验证需穿透到业务语义层。
- 调用服务自身 /readyz 接口，确认返回 HTTP 200 且 body 包含 "status":"ok"
- 检查 Service 对应的 Endpoints 数量是否与预期副本数一致
- 向该服务发起一笔真实业务请求（如模拟下单、查询用户），验证端到端链路
- 若任一验证项失败，自动回滚前序操作（如缩容副本、取消节点驱逐），并升级告警级别
