k8s 重启维护节点，这样操作才安全！

原创不爱吃肉运维技术 2024-05-27 08:10 上海听全文

背景

一个项目用的 k8s 集群发现了个 bug ，处理完成后需要重启节点才能彻底修复。为了避免业务受到影响，在操作节点重启前我们需要将当前节点上运行的所有业务 pod 都驱逐到其他节点上以继续提供服务。这里记录下操作方法及注意事项，特别是结尾总结的注意事项，一定要认真检查。

将 pod 驱逐到其他节点

一般情况下要将某节点上 pod 都驱逐出去我们可以直接使用 kubectl drain 命令来实现，如下所示：

1、获取集群中节点列表

[root@imzcy ~]# kubectl get nodesNAME           STATUS   ROLES    AGE    VERSION192.168.2.41   Ready    <none>   543d   v1.22.5-tke.6192.168.2.15   Ready    <none>   436d   v1.22.5-tke.12192.168.2.8    Ready    <none>   540d   v1.22.5-tke.6[root@imzcy ~]#

2、使用 kubectl drain 命令来驱逐指定节点上 pod

[root@imzcy ~]# kubectl drain --ignore-daemonsets 192.168.2.41node/192.168.2.41 cordonedWARNING: ignoring DaemonSet-managed Pods: kube-monitor/node-exporter-knxrq, kube-system/csi-nodeplugin-cfsplugin-xz66bevicting pod uat/zcy-test-0418-6688fbff7b-kmrj4pod/zcy-test-0418-6688fbff7b-kmrj4 evictednode/192.168.2.41 evicted[root@imzcy ~]#

drain 子命令的效果相当于：

给指定节点添加 node.kubernetes.io/unschedulable:NoSchedule 污点。
将节点状态标记为不可调度。
给指定节点上所有运行中的 Pod 发送 SIGTERM 信号以优雅终止 pod。

3、使节点重新变可用

重新维护好节点后，需要使用 kubectl uncordon，这将使节点重新变为可调度。

[root@imzcy ~]# kubectl uncordon 192.168.2.41

知道了 drain 命令的工作逻辑，我们也可以自己手动操作（使得过程更加可控）：

给节点新增一个不能被现有 pod 容忍的污点，并将 effect 字段值设置为 NoSchedule（新的 Pod 不会被调度到此节点上，当前正在节点上运行的 Pod 不会被驱逐）。
手动将当前节点上运行的 pod delete 掉，由于设置了污点所以 delete 掉的 pod 不会被重新调度到当前节点。
指定 pod 被 delete 掉后，可以观察下是否在其他节点重新调度并正常运行，新 pod 调度到其他节点后资源负载情况是否在正常使用阈值内，如果一切正常，再继续 delete 下一个 pod 一直到全部完成。
确认没有业务 pod 在节点上运行了，再重启节点进行维护。
重启完成确认问题修复后，删除节点上之前定义好的污点。

特别注意

使用 drain 命令等清空节点时需要注意：

如果存在新的、能够容忍 node.kubernetes.io/unschedulable 等污点的 Pod，那么这些 Pod 可能会被调度到你已经清空的节点上。所以除了 DaemonSet 之外，请避免容忍此污点（避免容忍所有污点）。
如果你或另一个 API 用户（绕过调度器）直接为 Pod 设置了 nodeName 字段，则即使你已将该节点清空并标记为不可调度，Pod 仍将被绑定到这个指定的节点并在该节点上运行。
如果节点上存在不受控制器管理的 pod（replication controller, replica set, daemon set, stateful set, 或 job），则必须添加使用 --force 选项，否则 drain 不会删除任何Pod。
由于执行 drain 命令会将节点所有 pod 驱逐到其他节点上运行，所以如果节点本身承载大量的 pod ，需要注意评估该节点上所有 pod 被重新调度到其他节点上运行时是否会对集群资源造成压力。
确保没有外部没有直接调用此节点的 IP 进行业务请求的（NodePort），否则会导致重启期间无法正常访问。