Kubernetes集群节点NotReady自愈方案：基于Event监控的自动化故障恢复实践

Kubernetes节点NotReady问题的自动化处理思路

Kubernetes集群运行中，节点进入NotReady状态是运维高频事件。kubelet失联、容器运行时挂死、网络插件异常都可能导致节点状态变为NotReady。手动处理耗时且响应慢，本文给出基于Kubernetes Event监控的自愈方案，实现从检测到恢复的全自动化流程。

节点NotReady的常见触发原因分类

按频率排序：

1. kubelet进程异常：kubeletOOM、磁盘写满导致kubelet无法写入checkpoint、kubelet与API Server通信超时
2. 容器运行时故障：containerd/docker daemon挂死、CNI插件冲突导致网络配置失败
3. 节点资源耗尽：磁盘100%满、内存耗尽触发OOM导致kubelet无响应
4. 云厂商宿主机故障：底层VM异常重启、云盘卸载

Event驱动的节点异常检测方案

Kubernetes的Node状态变化会产生Event对象。通过Watch API监听节点状态变更Event，可以在节点NotReady后的30秒内检测到异常：

import kubernetes.client
from kubernetes.watch import Watch

api = kubernetes.client.CoreV1Api()
watcher = Watch()
for event in watcher.stream(api.list_node, timeout_seconds=0):
node = event['object']
for cond in node.status.conditions:
if cond.type == 'Ready' and cond.status != 'True':
print(f"节点 {node.metadata.name} 进入NotReady, 原因: {cond.reason}")
trigger_recovery(node.metadata.name, cond.reason)

分级自愈策略设计

根据NotReady持续时间和原因，实施不同力度的恢复动作：

Level 1 – 轻度干预（NotReady < 3分钟）

通过SSH远程执行kubelet重启：

systemctl restart kubelet

等待60秒检查节点是否恢复Ready。约70%的kubelet临时失联场景在此阶段恢复。

Level 2 – 中度干预（NotReady 3-10分钟，Level 1未恢复）

重启容器运行时并清理网络配置缓存：

systemctl restart containerd
rm -rf /var/lib/cni/networks/*
systemctl restart kubelet

适用于containerd卡死或CNI网络配置残留导致节点无法恢复的场景。

Level 3 – 重度干预（NotReady > 10分钟，前两级未恢复）

驱逐节点上的Pod并标记节点为不可调度，等待人工介入或云厂商自动替换：

kubectl drain {node_name} --ignore-daemonsets --delete-emptydir-data --force --timeout=120s
kubectl cordon {node_name}

自愈Controller的完整实现

将上述逻辑封装为Kubernetes Operator，部署在集群内持续运行：

apiVersion: apps/v1
kind: Deployment
metadata:
name: node-recover-controller
namespace: kube-system
spec:
replicas: 1
selector:
matchLabels:
app: node-recover-controller
template:
metadata:
labels:
app: node-recover-controller
spec:
serviceAccountName: node-recover-sa
containers:
- name: controller
image: registry.example.com/node-recover:v1.0
env:
- name: LEVEL1_TIMEOUT
value: "180"
- name: LEVEL2_TIMEOUT
value: "600"
- name: SSH_KEY_PATH
value: "/etc/ssh-keys/id_rsa"
resources:
requests:
cpu: 100m
memory: 128Mi

对应的RBAC配置：

apiVersion: v1
kind: ServiceAccount
metadata:
name: node-recover-sa
namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: node-recover-role
rules:
- apiGroups: [""]
resources: ["nodes"]
verbs: ["get", "list", "watch", "patch", "update"]
- apiGroups: [""]
resources: ["pods"]
verbs: ["list", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: node-recover-binding
subjects:
- kind: ServiceAccount
name: node-recover-sa
namespace: kube-system
roleRef:
kind: ClusterRole
name: node-recover-role
apiGroup: rbac.authorization.k8s.io

自愈操作的安全边界与回滚机制

自动化恢复存在风险，必须设置安全边界：

1. 白名单机制：只对标注了特定annotation的节点执行自愈动作，避免对关键数据库节点误操作：
kubectl annotate node {name} node-recover/enabled=true

2. 每日操作上限：同一节点24小时内最多触发3次自愈，超过后仅告警不执行。

3. 操作审计：每次自愈动作写入Event和ConfigMap记录，包含操作时间、节点、动作类型、执行结果，便于事后审计。

4. 回滚预案：Level 2操作前先备份containerd配置和CNI网络状态，恢复失败时可通过kubectl uncordon重新调度Pod。

这套方案在50+节点的生产集群中运行3个月，节点NotReady平均恢复时间从人工处理的45分钟降至4分钟以内，自愈成功率82%。