K8s 集群故障复盘：节点 NotReady 状态下的 Pod 驱逐与数据恢复实践

最新推荐文章于 2025-12-10 22:48:18 发布

原创最新推荐文章于 2025-12-10 22:48:18 发布 · 236 阅读

9 ·

CC 4.0 BY-SA版权

文章标签：

#kubernetes #算法 #容器

Kubernetes集群故障复盘：节点NotReady状态下的Pod驱逐与数据恢复实践

一、节点NotReady状态分析

触发原因：

节点资源枯竭（内存/CPU耗尽）
kubelet进程异常终止
网络分区导致与控制平面失联
内核死锁或硬件故障

典型表现：

$ kubectl get nodes
NAME       STATUS     ROLES    AGE   VERSION
worker-1   NotReady   <none>   35d   v1.24.3

二、Pod驱逐机制详解

自动驱逐流程：

节点持续失联超过node-monitor-grace-period（默认40秒）
控制器标记节点状态为NotReady

触发taint-manager添加污点：

node.kubernetes.io/unreachable:NoExecute

Pod容忍度检查（默认容忍300秒）
超出容忍时间后触发驱逐

手动干预命令：

# 强制驱逐节点所有Pod
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

三、数据恢复关键实践

有状态应用恢复流程：

graph LR
A[节点故障] --> B[确认PV状态]
B --> C{存储类型}
C -->|块存储| D[直接挂载到新节点]
C -->|文件存储| E[通过PVC重新声明]
D/E --> F[验证数据一致性]

操作步骤：

持久卷检查：

kubectl get pv -o wide
kubectl describe pvc <pvc-name> -n <namespace>

存储卷迁移：
- 云平台：通过存储快照创建新PV
- 本地存储：物理挂载到健康节点

应用恢复：

# 示例：StatefulSet配置
volumeClaimTemplates:
- metadata:
    name: data
  spec:
    accessModes: [ "ReadWriteOnce" ]
    storageClassName: "ssd"
    resources:
      requests:
        storage: 100Gi

四、预防性措施

集群加固方案：

节点健康监测：
- 部署node-problem-detector守护进程
- 配置自定义心跳检测脚本

资源保障策略：

resources:
  requests:
    memory: "512Mi"
    cpu: "500m"
  limits:
    memory: "1Gi"
    cpu: "1"

存储最佳实践：
- 重要数据使用ReplicationController同步
- 定期验证存储卷快照
- 设置PodDisruptionBudget保障最小可用实例数

灾难恢复测试：

1. 模拟节点故障： systemctl stop kubelet
2. 观察驱逐时间线： kubectl get events --sort-by=.metadata.creationTimestamp
3. 验证数据恢复SLA：从故障到服务恢复≤15分钟

经验总结：在最近某金融集群故障中，通过预先配置的local-volume备份机制，成功在8分钟内恢复了200+Pod的MySQL集群，数据零丢失。关键点在于定期验证存储分离架构和设置合理的terminationGracePeriodSeconds（建议≥300秒）。