1.这三个命令是正式release的1.2新加入的命令，三个命令一起介绍，是因为三个命令配合使用可以实现节点的维护。在1.2之前，因为没有相应的命令支持，如果要维护一个节点，只能stop该节点上的kubelet将该节点退出集群，是集群不在将新的pod调度到该节点上。如果该节点上本生就没有pod在运行，则不会对业务有任何影响。如果该节点上有pod正在运行，kubelet停止后，master会发现该节点不可达，而将该节点标记为notReady状态，不会将新的节点调度到该节点上。同时，会在其他节点上创建新的pod替换该节点上的pod。这种方式虽然能够保证集群的健壮性，但是任然有些暴力，如果业务只有一个副本，而且该副本正好运行在被维护节点上的话，可能仍然会造成业务的短暂中断。
1.2中新加入的这3个命令可以保证维护节点时，平滑的将被维护节点上的业务迁移到其他节点上，保证业务不受影响。
如下图所示是一个整个的节点维护的流程（为了方便demo增加了一些查看节点信息的操作）：
1）首先查看当前集群所有节点状态，可以看到共两个节点都处于ready状态；
kubectl get nodes
查看当前tomcat两个副本运行在node1两个节点上；
kubectl get pod -o wide
2）使用cordon命令将node1标记为不可调度；
kubectl cordon node1-192.168.52.132
再使用kubectl get nodes查看节点状态，发现node1虽然还处于Ready状态，但是同时还被禁能了调度，这意味着新的pod将不会被调度到node1上。
再查看tomcat状态，没有任何变化，两个副本仍运行在node1上；
kubectl get pod -o wide
3）执行drain命令，将运行在node1上运行的pod平滑的赶到其他节点上；
kubectl drain node1-192.168.52.132
再查看tomcat的状态发现，node1上的副本已经被迁移到node2上；这时候就可以对node1进行一些节点维护的操作，如升级内核，升级Docker等；
kubectl get pod -o wide
4）节点维护完后，使用uncordon命令解锁node1，使其重新变得可调度；
kubectl uncordon node1-192.168.52.132
检查节点状态，发现node1重新变回Ready状态。
kubectl get nodes
若想去掉某个节点，可以直接 只有kubectl delete node ip 则就会直接把节点删除了。
若想把这个节点再从新加入，只需要重启节点的kubelet kube-proxy 就可以了
2.Node节点禁止调度（平滑维护）方式- cordon，drain，delete
cordon、drain和delete三个命令都会使node停止被调度，后期创建的pod不会继续被调度到该节点上，但操作的暴力程度却不一样。
一、cordon 停止调度（不可调度，临时从K8S集群隔离）
影响最小，只会将node标识为SchedulingDisabled不可调度状态。
之后K8S再创建的pod资源，不会被调度到该节点。
旧有的pod不会受到影响，仍正常对外提供服务。
禁止调度命令"kubectl cordon node_name"。
恢复调度命令"kubectl uncordon node_name"。（恢复到K8S集群中，变回可调度状态）
二、drain 驱逐节点（先不可调度，然后排干）
首先，驱逐Node上的pod资源到其他节点重新创建。
接着，将节点调为SchedulingDisabled不可调度状态。
禁止调度命令"kubectl drain node_name --force --ignore-daemonsets --delete-local-data"
恢复调度命令"kubectl uncordon node_name"。（恢复到K8S集群中，变回可调度状态）
drain方式是安全驱逐pod，会等到pod容器应用程序优雅停止后再删除该pod。
drain驱逐流程：先在Node节点删除pod，然后再在其他Node节点创建该pod。所以为了确保drain驱逐pod过程中不中断服务（即做到"无感知"地平滑驱逐），必须保证要驱逐的pod副本数大于1，并且采用了"反亲和策略"将这些pod调度到不同的Node节点上了！也就是说，在"多个pod副本+反亲和策略"的场景下，drain驱逐过程对容器服务是没有影响的。
需要注意：
对节点执行维护操作之前（例如：内核升级，硬件维护等），您可以使用 kubectl drain 安全驱逐节点上面所有的 pod。
drain安全驱逐方式将会允许 pod 里面的容器遵循指定的 PodDisruptionBudgets 执行优雅中止。也就是说，drain安全驱逐可以做到：优雅地终止pod里的容器进程。
kubectl drain 返回成功表明所有的 pod （除了排除的那些）已经被安全驱逐（遵循期望优雅的中止期，并且没有违反任何应用程序级别的中断预算）。
然后，通过对物理机断电或者在云平台上删除节点所在的虚拟机，都能安全的将节点移除。
默认情况下，kubectl drain 会忽略那些不能杀死的系统类型的 pod。drain命令中需要添加三个参数：–force、–ignore-daemonsets、–delete-local-data
–force 当一些pod不是经 ReplicationController, ReplicaSet, Job, DaemonSet 或者 StatefulSet 管理的时候就需要用–force来强制执行 (例如:kube-proxy)
–ignore-daemonsets 无视DaemonSet管理下的Pod。即–ignore-daemonsets往往需要指定的,这是因为deamonset会忽略unschedulable标签(使用kubectl drain时会自动给节点打上不可调度标签),因此deamonset控制器控制的pod被删除后可能马上又在此节点上启动起来,这样就会成为死循环.因此这里忽略daemonset。
–delete-local-data 如果有mount local volumn的pod，会强制杀掉该pod。
drain禁止调度的操作步骤：
确定要排空的节点的名称
# kubectl get nodes
查看pod
# kubectl get po
命令node节点开始释放所有pod，并且不接收新的pod进程
# kubectl drain [node-name] --force --ignore-daemonsets --delete-local-data
此时可以对该node节点进行平滑维护，后续需要恢复到k8s集群中：
# kubectl uncordon [node-name]
delete 删除节点
首先，驱逐Node节点上的pod资源到其他节点重新创建。
驱逐流程：先在Node节点删除pod，然后再在其他Node节点上创建这些pod。
node节点删除，master失去对其控制，该节点从k8s集群摘除。
delete是一种暴力删除node的方式。在驱逐pod时是强制干掉容器进程，做不到优雅终止Pod。相比较而言，显然drain更安全。
Node节点平滑维护
通常情况下，如果要对K8S集群中的一台Node节点进行平滑维护，如升级或调整配置。正确的操作：
cordon临时从K8S集群隔离出来，标识为SchedulingDisabled不可调度状态。
drain排干该节点上的pod资源到其他node节点上。
对该节点展开平滑维护操作，如升级或调整配置。
uncordon恢复，重新回到K8S集群，变回可调度状态。
同时注意：为了确保drain驱逐pod的时候，容器应用服务不中断，必须满足：
要驱逐的pod副本数量必须大于1
要配置"反亲和策略"，确保被驱逐的pod被调度到不同的Node节点上
deployment采用滚动更新，设置maxUnavailable为0，maxSurge为1
kubectl cordon node1 #设置不可调度
kubectl uncordon node1 #恢复可调度
kubectl drain node1 --force --ignore-daemonsets #设置不可调度
实际应用
kubectl get nodes
kubectl get pod -A -o wide | grep cn-shenzhen.10.0.14.48 | grep yxyw
kubectl drain cn-shenzhen.10.0.14.48 --force --ignore-daemonsets --delete-local-data
kubectl uncordon cn-shenzhen.10.0.14.48