Kubernetes 如何进行集群节点的平滑下线维护-linux运维-PHP中文网

平滑下线kubernetes节点需三步校验、分批执行、参数完备、维护后验证：先查pdb配置、资源余量和异常pod；每次仅drain1–2节点，严格等待pod迁移完成并监控达标；命令必加--ignore-daemonsets等参数；最后uncordon并确认节点ready。

kubernetes 如何进行集群节点的平滑下线维护

平滑下线 Kubernetes 集群节点，关键不在“怎么敲命令”，而在于节奏、校验和兜底。直接 kubectl drain 一把梭，大概率引发服务抖动、PDB 触发失败、API Server 延迟飙升，甚至短暂不可用。

90% 的 drain 卡住或中断，都源于准备不足。这三件事缺一不可：

查 PodDisruptionBudget（PDB）配置：运行 kubectl get pdb --all-namespaces，确认核心业务设置了 minAvailable（如 2 副本至少保留 1 个）或 maxUnavailable: 0。没配 PDB 的应用，drain 可能直接驱空全部副本，服务瞬间中断。
看集群资源余量：用 kubectl top nodes 和 kubectl describe node <node-name></node-name> 检查其他节点的 CPU/Mem Allocatable 是否足够承接迁移 Pod。若剩余可分配资源低于 20%，先扩容或暂缓操作。
扫异常 Pod 类型：执行 kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=<node></node>，重点关注：
– 无控制器管理的孤立 Pod（需加 --force）
– 使用 emptyDir 或本地存储的 Pod（数据会丢失，必要时加 --delete-emptydir-data）
– DaemonSet 类型 Pod（不加 --ignore-daemonsets 会直接阻断 drain）

大集群里同时 drain 多个节点，等于向调度器和 etcd 突然发起海量写请求，极易拖垮整个集群响应能力。

Kubernetes Skills

针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。

下载

每次只处理 1–2 个节点，按可用区（AZ）或机架维度分组，每组最多并行 1 个；
每个 drain 命令后，等待 kubectl get pods -A --field-selector spec.nodeName=<node></node> 返回空结果，且新 Pod 全部进入 Running 状态；
观察监控面板上 5 分钟内的服务延迟（如 95% RT）、错误率、Pod 启动成功率是否回归基线，确认稳定后再动下一个。

生产环境严禁使用裸 kubectl drain <node></node>。推荐组合如下：

节点物理维护完成后，不能直接等它自动上线：

先确认 kubelet 和 containerd 已正常启动（systemctl status kubelet containerd）；
执行 kubectl uncordon <node-name></node-name> 恢复调度能力；
检查 kubectl get node <node-name> -o wide</node-name> 状态是否为 Ready；
用 kubectl describe node <node-name> | grep -A5 Conditions</node-name> 确认所有健康条件通过。