K8s etcd 集群崩溃异常恢复
内容提要
K8s集群因etcd故障无法操作，apiserver报504超时。etcd三节点中仅一个存活，另一节点WAL日志损坏导致重启失败。恢复方案：若其他两节点健康，移除坏节点并重新加入；若全部故障，用快照恢复。建议先备份数据，检查其他节点状态，再按场景操作。
延伸解读
WAL损坏的常见诱因
文章指出，etcd节点无法启动的直接原因是WAL日志文件损坏，报错“failed to read WAL, cannot be repaired”。这类损坏通常由磁盘I/O错误、非正常关机（如断电）或文件系统问题引发。在K8s生产环境中，etcd数据目录所在磁盘的稳定性至关重要，建议确保存储具备冗余和定期健康检查，以降低此类故障风险。
恢复前先确认集群多数派状态
etcd是强一致性集群，只要多数派（3节点中至少2个）存活，集群仍可对外服务。但本文案例中kubectl卡死，说明API Server无法连接健康节点，可能其他节点也存在问题。因此，恢复操作的第一步是登录其他节点检查etcd健康状态，再决定采用“移除坏节点重新加入”还是“全量快照恢复”方案，避免盲目操作。
快照备份是灾难恢复的最后防线
当所有etcd节点均故障或数据损坏时，只能依赖之前的快照进行全集群恢复。文中提到系统中有定时任务执行`etcdctl snapshot save`，这提示定期备份etcd数据是必要的。恢复时需确保快照文件可用，并注意恢复参数（如`--initial-cluster`）与原集群配置一致，否则可能导致集群无法正常组建。
Q&A
K8s集群中etcd节点WAL日志损坏导致重启失败，如何恢复？
如果其他两个etcd节点健康，可以移除损坏节点并重新加入集群；如果所有节点都故障，则使用快照恢复。具体操作：先备份数据，检查其他节点状态，然后根据场景选择恢复方案。
etcd报错 'failed to read WAL, cannot be repaired' 是什么原因？
该错误表示etcd的WAL日志文件损坏，且自动修复失败。通常由磁盘I/O错误、非正常关机或文件系统问题导致。
etcd集群中一个节点故障，如何安全移除并重新加入？
在健康节点上使用etcdctl member remove移除故障节点，然后使用etcdctl member add重新添加，并恢复该节点的etcd静态Pod。操作前需备份数据并确认其他节点健康。
etcd集群全部节点故障，如何用快照恢复？
使用etcdctl snapshot restore命令从备份快照恢复数据，需在每台节点上执行，并确保参数与原集群配置一致。恢复后启动所有节点的etcd。
etcd集群故障时，kubectl命令卡住怎么办？
kubectl卡住是因为API Server无法连接etcd。一旦etcd恢复，API Server会自动重连，kubectl命令会自动恢复响应，无需重启API Server。
etcdctl snapshot save进程卡住如何处理？
该进程因连接不上本地etcd而卡住，可以直接kill掉该进程（如PID 3560716），以免影响后续操作或占用资源。
