集群在运行过程中会面临节点宕机、服务雪崩、资源耗尽、网络分区等各类故障。传统运维依赖人工登录服务器执行命令，不仅响应慢，而且操作一致性难以保证。故障自愈的理念是把常见的故障处理逻辑抽象成自动化流程，让系统在检测到异常后立即执行预定义的修复动作，并通过验证机制确认服务恢复。要做到这一点，不能只靠一两段零散的脚本，而是需要一套结构化的自动化修复剧本，把“发现、诊断、隔离、修复、验证”串联成闭环。
一、集群故障自愈的设计原则
故障自愈系统不是简单地检测到异常就执行重启，它的设计需要遵循几个核心原则。首先是幂等性，同一个修复剧本在短时间内可能被重复触发，如果脚本不具备幂等性，很可能会加剧故障。例如重启某个服务的操作，如果脚本连续执行两次，第二次会因服务尚未完全启动而失败，甚至会触发更严重的级联影响。因此修复动作应当是可重复执行的，执行前先检查当前状态，执行后再验证结果。
其次是隔离优先原则。当某个节点或服务出现异常时，第一时间不是尝试修复，而是将其从服务流量中摘除，避免故障扩散。例如在Kubernetes集群中，可以通过给节点打上不可调度标记，让调度器不再分配新的Pod到故障节点上，然后再进入诊断和修复流程。隔离动作必须快速且可回滚，一旦确认故障恢复，再解除隔离。
第三是可观测性支撑。没有完善的监控和日志数据，故障自愈就像蒙眼走路。系统需要根据Prometheus指标、事件流、探针结果等信号判断故障类型，而不是盲目执行固定动作。例如同样是节点高负载，可能是CPU压力过大，也可能是内存泄漏，处理方式完全不同。因此设计修复剧本时，需要把关键指标和阈值作为触发条件，并记录每次动作前后的状态变化，为后续复盘和优化提供数据。
二、自动化修复剧本的组成与实现
自动化修复剧本是对人工故障处理流程的形式化描述，它包含触发条件、诊断步骤、修复动作、验证方法和回滚策略五个部分。触发条件定义了何时启动剧本，例如Prometheus告警触发、节点状态变化事件、定时巡检等。诊断步骤通过执行命令或调用API收集故障现场的详细数据，帮助定位根因。修复动作是具体的操作，比如重启容器、驱逐节点上的Pod、清理磁盘空间等。验证方法用来确认修复是否生效，避免“假恢复”。回滚策略则是在修复失败或产生副作用时恢复到原始状态。
实现方式可以轻量也可以重。轻量方案基于Shell或Python脚本，配合告警系统的webhook实现。例如Alertmanager收到告警后，调用指定的HTTP接口，由该接口执行一段修复脚本。这种方案部署简单，适合故障类型较少、团队规模不大的场景。重方案则引入Kubernetes Operator或独立的自愈控制器，自定义资源定义描述故障场景和修复策略，控制器监听集群状态并自动执行剧本。这种方式扩展性强，可以处理复杂的多步骤修复流程，并且能利用Kubernetes的声明式机制保证最终一致性。
无论采用哪种实现，修复剧本都应当以代码形式存放在版本控制系统中，并经过评审和测试。很多故障修复逻辑看似简单，但边界条件复杂，比如判断Pod是否真正健康，不能只看Running状态，还要检查就绪探针和实际流量处理情况。因此剧本中的每一个判断分支都需要有明确的依据，避免在异常状态下做出错误决策。
三、典型故障场景与代码示例
下面以节点NotReady和Pod频繁重启两个典型场景为例，展示修复剧本的具体设计。节点NotReady通常由网络分区、kubelet崩溃或系统资源耗尽引起。一个基础的修复流程是：先检查节点状态和kubelet服务，如果kubelet未运行则尝试启动；如果节点负载过高，则暂时将节点标记为不可调度并驱逐部分低优先级Pod；如果网络不可达，则调用云厂商API重启节点。代码示例展示了一个简化版的Python修复脚本。
import subprocess
import sys
NODE_NAME = sys.argv[1]
def run_cmd(cmd):
result = subprocess.run(cmd, shell=True, capture_output=True, text=True)
return result.returncode, result.stdout.strip()
def mark_unschedulable():
code, _ = run_cmd(f"kubectl cordon {NODE_NAME}")
return code == 0
def check_kubelet():
code, _ = run_cmd(f"ssh {NODE_NAME} 'systemctl is-active kubelet'")
return code == 0
def restart_kubelet():
code, _ = run_cmd(f"ssh {NODE_NAME} 'systemctl restart kubelet'")
return code == 0
def main():
# 先隔离节点，防止新Pod调度上来
if not mark_unschedulable():
print("cordon失败，终止剧本")
return
# 检查kubelet状态
if not check_kubelet():
print("kubelet未运行，尝试重启")
restart_kubelet()
else:
print("kubelet运行中，检查节点资源状态")
# 这里可进一步执行诊断命令，例如检查内存、磁盘等
# 验证节点是否恢复，此处通过kubectl get node查看状态
code, out = run_cmd(f"kubectl get node {NODE_NAME} -o jsonpath='{{.status.conditions[?(@.type==\"Ready\")].status}}'")
if code == 0 and "True" in out:
print("节点已恢复Ready")
run_cmd(f"kubectl uncordon {NODE_NAME}")
else:
print("节点未恢复，等待人工介入")
if __name__ == "__main__":
main()
这段脚本展示了隔离、诊断、修复和验证的完整链路。实际生产环境中，还需要接入告警系统和审批流程，避免误操作导致大范围影响。对于Pod频繁重启的问题，剧本可以先通过 kubectl describe pod 查看事件和退出原因。如果是内存超限，可以调整资源限制或触发自动扩容；如果是镜像拉取失败，则检查镜像仓库连通性和凭证。修复动作可能涉及更新Deployment配置，这时需要记录变更历史，以便回滚。
在设计修复剧本时，还应该充分考虑故障恢复后的验证时机。有些服务启动后需要一段时间预热，立即验证可能得到错误的结论。例如数据库主从切换后，从库需要追赶主库的WAL日志，如果过早将流量切换过去，可能导致数据不一致。因此验证步骤中应包含延迟检查或就绪探测，只有当所有条件满足后才宣告恢复成功。
四、落地实践与注意事项
将故障自愈系统落地到生产环境是一个循序渐进的过程。建议先从低风险、高频率的故障类型开始，例如磁盘空间不足、进程僵死等。这些故障的处理方式相对明确，即使自动修复失败，也不会造成严重后果。通过实际运行积累经验和信心后，再逐步扩展到网络分区、节点宕机等高风险场景。
在实践过程中，需要注意几个关键点。第一，修复剧本必须经过严格的测试，包括单元测试和故障注入演练。可以利用Chaos Mesh或Litmus等混沌工程工具模拟各种故障，验证剧本的触发条件和执行效果。第二，每次自动修复动作都要记录完整的审计日志，包括触发原因、执行时间、执行结果和后续状态。这些日志不仅用于故障复盘，还能帮助团队发现自动化流程自身的缺陷。第三，人工介入通道必须保留。即使自愈系统再完善，也无法覆盖所有未知故障，当剧本执行失败或达到最大重试次数时，应立即升级到值班工程师处理。
集群故障自愈不是银弹，它更多是一种将运维经验固化为代码、减少人为失误、提升恢复速度的手段。通过合理设计自动化修复剧本，结合可观测性平台和持续迭代的机制，团队可以在复杂的分布式环境中建立起可靠的应急响应能力。