Skip to content

title: K8S自愈与故障恢复 summary: Kubernetes' built-in mechanisms for handling node and Pod failures, including automatic rescheduling, recovery procedures, and infrastructure load balancing adjustments to maintain service availability. sources: - 400-devops__06-Kubernetes__k8s-paas__05.K8S结合CI&CD持续交付和集中管理配置.md kind: concept createdAt: "2026-04-28T04:45:35.910Z" updatedAt: "2026-04-28T04:45:35.910Z" tags: - kubernetes - disaster-recovery - high-availability - operations aliases: - k8s-self-healing confidence: 0.9 provenanceState: extracted inferredParagraphs: 0

K8S自愈与故障恢复

K8S自愈与故障恢复是指在 Kubernetes 集群遭遇硬件故障或节点宕机等灾难性事件时，利用平台自身的调度机制和运维干预，实现应用服务自动重建与恢复的过程^[400-devops__06-Kubernetes__k8s-paas__05.K8S结合CI&CD持续交付和集中管理配置.md]。

故障模拟与现象

在生产环境中，节点宕机是常见风险。为了验证系统的高可用性，通常会进行模拟测试。例如，通过强制关闭节点（如执行 halt 命令）来模拟服务器宕机^[400-devops__06-Kubernetes__k8s-paas__05.K8S结合CI&CD持续交付和集中管理配置.md]。

当运算节点宕机时，会产生以下现象： * 管理平面失联: Kubernetes Dashboard 可能会出现 503 错误，无法访问^[400-devops__06-Kubernetes__k8s-paas__05.K8S结合CI&CD持续交付和集中管理配置.md]。 * 业务中断: 如果应用实例仅分布在故障节点上，外部流量将无法访问服务^[400-devops__06-Kubernetes__k8s-paas__05.K8S结合CI&CD持续交付和集中管理配置.md]。

故障恢复流程

在确认节点离线后，运维人员需要执行一系列操作来触发 Kubernetes 的自愈机制并恢复集群负载均衡。

1. 清除离线节点

Kubernetes 集群可能会将短暂的网络波动视为节点不可达，并尝试不断重连。为了明确告知集群该节点已永久下线，需要手动删除对应的 Node 资源^[400-devops__06-Kubernetes__k8s-paas__05.K8S结合CI&CD持续交付和集中管理配置.md]。

[kubectl delete](<./kubectl-delete.md>) node <offline-node-hostname>

删除节点后，Kubernetes 控制器会检测到 Pod 数量低于期望值，并立即在剩余健康的运算节点上重建这些 Pod^[400-devops__06-Kubernetes__k8s-paas__05.K8S结合CI&CD持续交付和集中管理配置.md]。

2. 调整基础设施负载均衡

在节点宕机后，集群入口（如 Nginx 或 Traefik）如果仍然向故障节点转发流量，会导致部分请求失败。为了确保服务连续性，必须手动调整负载均衡器的配置，剔除故障节点的地址^[400-devops__06-Kubernetes__k8s-paas__05.K8S结合CI&CD持续交付和集中管理配置.md]。

示例配置调整^[400-devops__06-Kubernetes__k8s-paas__05.K8S结合CI&CD持续交付和集中管理配置.md]:

  • API Server 入口 (Nginx):
    • 修改 /etc/nginx/nginx.conf，注释掉指向故障节点的 server 行（如 server 10.4.7.21:6443）。
  • 集群 Ingress 入口 (Traefik):
    • 修改 /etc/nginx/conf.d/od.com.conf，注释掉故障节点的后端配置（如 server 10.4.7.21:81 ...）。

修改完成后，重载配置（nginx -s reload）。此时，流量将精准路由至健康节点，配合已重建的 Pod，服务将完全恢复^[400-devops__06-Kubernetes__k8s-paas__05.K8S结合CI&CD持续交付和集中管理配置.md]。

节点修复后的回迁

当故障节点修复并重新上线后，需要将其重新纳入集群管理并恢复负载均衡配置^[400-devops__06-Kubernetes__k8s-paas__05.K8S结合CI&CD持续交付和集中管理配置.md]。

1. 节点重新入网

启动节点后，需确保其服务正常，并重新打上 Kubernetes 标签以恢复其角色^[400-devops__06-Kubernetes__k8s-paas__05.K8S结合CI&CD持续交付和集中管理配置.md]。

# 重新添加 Master/Node 角色标签
[kubectl](<./kubectl.md>) label node <hostname> node-role.kubernetes.io/master=
[kubectl](<./kubectl.md>) label node <hostname> node-role.kubernetes.io/node=

2. 资源再平衡

节点恢复后，默认情况下资源可能仍集中在故障期间运行服务的节点上。为了平衡集群负载，运维人员可以手动删除部分 Pod，触发 Kubernetes 调度器将其重新调度至新恢复的节点上^[400-devops__06-Kubernetes__k8s-paas__05.K8S结合CI&CD持续交付和集中管理配置.md]。

3. 恢复负载均衡配置

最后，将 Nginx 和 Traefik 配置文件中之前注释掉的后端地址恢复，并再次重载配置，从而使集群完全恢复到多节点高可用状态^[400-devops__06-Kubernetes__k8s-paas__05.K8S结合CI&CD持续交付和集中管理配置.md]。

Sources

  • 400-devops__06-Kubernetes__k8s-paas__05.K8S结合CI&CD持续交付和集中管理配置.md