1、设置节点不可调度
kubectl
cordon node02
设置node02不可调度，查看各节点状态，发现node02为SchedulingDisabled，此时master不会将新的pod调度到该节点上，但是node02上pod还是正常运行。
2、驱逐节点上的pod
kubectl drain
node02 --delete-local-data --ignore-daemonsets --force
参数说明：
–delete-local-data ：即使pod使用了emptyDir也删除；
–ignore-daemonsets ：忽略deamonset控制器的pod，如果不忽略，deamonset控制器控制的pod被删除后可能马上又在此节点上启动起来,会成为死循环；
–force ：不加force参数只会删除该NODE上由ReplicationController, ReplicaSet,DaemonSet,StatefulSet or Job创建的Pod，加了后还会删除’裸奔的pod’(没有绑定到任何replication controller)
可以看到同一时刻只有一个pod进行迁移，对外提供服务的pod始终有4个，这个也再次验证了同一时刻只有一个pod迁移，nginx服务始终有4个pod对外提供服务。
3、维护结束
kubectl uncordon node02
维护结束，重新将node02节点置为可调度状态。
4、pod回迁
pod回迁貌似还没什么好的办法，这里采用delete然后重建的方式回迁。
kubectl get po -o wide
kubectl delete pod nginx1.18-7646b89d65-7klpv nginx1.18-7646b89d65-ddn9p
可以在业务低峰nginx1.18-7646b89d65-7klpv和nginx1.18-7646b89d65-ddn9p，由于node02上的pod之前都被驱逐，此时资源使用率最低，所以pod重建时会调度值该节点，完成pod回迁。
