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

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

# 获取集群中节点列表
[root@imzcy ~]# kubectl get nodes
NAME           STATUS   ROLES    AGE    VERSION
192.168.2.41   Ready    <none>   543d   v1.22.5-tke.6
192.168.2.15   Ready    <none>   436d   v1.22.5-tke.12
192.168.2.8    Ready    <none>   540d   v1.22.5-tke.6

#使用 kubectl drain 命令来驱逐指定节点上 pod
[root@imzcy ~]# kubectl drain --ignore-daemonsets 192.168.2.41
node/192.168.2.41 cordoned
WARNING: ignoring DaemonSet-managed Pods: kube-monitor/node-exporter-knxrq, kube-system/csi-nodeplugin-cfsplugin-xz66b
evicting pod uat/zcy-test-0418-6688fbff7b-kmrj4
pod/zcy-test-0418-6688fbff7b-kmrj4 evicted
node/192.168.2.41 evicted

drain 子命令的效果相当于：

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

使节点重新变可用

# 重新维护好节点后，需要使用 kubectl uncordon，这将使节点重新变为可调度。
[root@imzcy ~]# kubectl uncordon 192.168.2.41

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

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

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

1 如果存在新的、能够容忍 node.kubernetes.io/unschedulable 等污点的 Pod， 那么这些 Pod 可能会被调度到你已经清空的节点上。所以除了 DaemonSet 之外，请避免容忍此污点（避免容忍所有污点）。 如果你或另一个 API 用户（绕过调度器）直接为 Pod 设置了 nodeName 字段， 则即使你已将该节点清空并标记为不可调度，Pod 仍将被绑定到这个指定的节点并在该节点上运行。

2 如果节点上存在不受控制器管理的 pod（replication controller, replica set, daemon set, stateful set, 或 job），则必须添加使用 --force 选项，否则 drain 不会删除任何Pod。

3 由于执行 drain 命令会将节点所有 pod 驱逐到其他节点上运行，所以如果节点本身承载大量的 pod ，需要注意评估该节点上所有 pod 被重新调度到其他节点上运行时是否会对集群资源造成压力。

4 确保没有外部没有直接调用此节点的 IP 进行业务请求的（NodePort），否则会导致重启期间无法正常访问。