k8s node节点停机维护，pod如何迁移？
点击上方蓝色字体，关注我们
读完需 10 分钟
速读需 5 分钟
k8s集群中的node节点要升级内存，以应对服务迁入、pod扩缩容导致的资源短缺；亦或是node节点宕机，此时都需要对node节点进行停机维护，那么node节点上的pod应该如何处理呢？
默认迁移
当node节点关机后，k8s集群并没有立刻发生任何自动迁移动作，如果该node节点上的副本数为1，则会出现服务中断的情况。其实事实并非如此，k8s在等待5分钟后，会自动将停机node节点上的pod自动迁移到其他node节点上。
具体过程如下：
# 1.模拟node节点停机，停止kubeletsystemctl stop kubelet
# 2.集群状态# 此时停机的node点处于NotReady状态# kubectl get nodeNAME STATUS ROLES AGE VERSIONk8s-3-217 Ready master 88d v1.18.2k8s-3-218 NotReady <none> 88d v1.18.2k8s-3-219 Ready <none> 88d v1.18.2
# 3.监控pod状态，大约等待5分钟左右，集群开始有动作# kubectl get pod -n test -o wide -n test -wNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATEShelloworld-79956d95b4-q7jjg 1/1 Running 0 19h 10.244.1.154 k8s-3-218 <none> <none>helloworld-79956d95b4-q7jjg 1/1 Running 0 19h 10.244.1.154 k8s-3-218 <none> <none># 5分钟后，pod终止并进行重建helloworld-79956d95b4-q7jjg 1/1 Terminating 0 19h 10.244.1.154 k8s-3-218 <none> <none>helloworld-79956d95b4-nnlrq 0/1 Pending 0 0s <none> <none> <none> <none>helloworld-79956d95b4-nnlrq 0/1 Pending 0 0s <none> k8s-3-219 <none> <none>helloworld-79956d95b4-nnlrq 0/1 ContainerCreating 0 1s <none> k8s-3-219 <none> <none>
helloworld-79956d95b4-nnlrq 0/1 Running 0 3s 10.244.2.215 k8s-3-219 <none> <none>helloworld-79956d95b4-nnlrq 1/1 Running 0 66s 10.244.2.215 k8s-3-219 <none> <none>
# 4.访问测试：在pod重新迁移到其他node节点时，服务是不可用的。# curl -x 192.168.3.219:80 hello.test.cn<html><head><title>503 Service Temporarily Unavailable</title></head><body><center><h1>503 Service Temporarily Unavailable</h1></center><hr><center>nginx/1.17.8</center>
# 5.迁移完毕：服务正常访问# curl -x 192.168.3.219:80 hello.test.cnHello,world!从以上过程看出，停机node节点上的pod在5分钟后先终止再重建，直到pod在新节点启动并由readiness探针检测正常后并处于"1\1 Running"状态才可以正式对外提供服务。因此服务中断时间=停机等待5分钟时间+重建时间+服务启动时间+readiness探针检测正常时间。
在此大家可能有一个疑问：为什么pod在5分钟后开始迁移呢？
此时需要涉及到k8s中的Taint（污点）和 Toleration（容忍），这是从Kubernetes
1.6开始提供的高级调度功能。Taint和Toleration相互配合，可以避免pod被分配到不合适的节点上。每个节点上都可以应用一个或多个Taint，这表示对于那些不能容忍Taint的pod，是不会被该节点接受的。如果将Toleration应用于pod上，则表示这些pod可以（但不要求）被调度到具有匹配Taint的节点上。
具体来分析下：
# 1.查看停止服务节点的状态# kubelet停止后，node节点自动添加了Taints；# kubectl describe node k8s-3-218
Name: k8s-3-218Roles: <none>CreationTimestamp: Fri, 22 May 2020 11:36:16 +0800Taints: node.kubernetes.io/unreachable:NoExecute node.kubernetes.io/unreachable:NoScheduleUnschedulable: falseLease: HolderIdentity: k8s-3-218 AcquireTime: <unset> RenewTime: Wed, 19 Aug 2020 09:31:22 +0800Conditions: Type Status LastHeartbeatTime LastTransitionTime Reason Message ---- ------ ----------------- ------------------ ------ ------- NetworkUnavailable False Tue, 18 Aug 2020 09:07:59 +0800 Tue, 18 Aug 2020 09:07:59 +0800 FlannelIsUp Flannel is running on this node MemoryPressure Unknown Wed, 19 Aug 2020 09:29:56 +0800 Wed, 19 Aug 2020 09:32:07 +0800 NodeStatusUnknown Kubelet stopped posting node status. DiskPressure Unknown Wed, 19 Aug 2020 09:29:56 +0800 Wed, 19 Aug 2020 09:32:07 +0800 NodeStatusUnknown Kubelet stopped posting node status. PIDPressure Unknown Wed, 19 Aug 2020 09:29:56 +0800 Wed, 19 Aug 2020 09:32:07 +0800 NodeStatusUnknown Kubelet stopped posting node status. Ready Unknown Wed, 19 Aug 2020 09:29:56 +0800 Wed, 19 Aug 2020 09:32:07 +0800 NodeStatusUnknown Kubelet stopped posting node status....省略...Events: <none>
# 2.查看pod状态# kubectl describe pod helloworld-8565c4687b-rrfmj -n testName: helloworld-8565c4687b-rrfmjNamespace: testPriority: 0......Node-Selectors: <none>Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s node.kubernetes.io/unreachable:NoExecute for 300sEvents: <none>
此时pod的Tolerations 默认对于具有相应Taint的node节点容忍时间为300s，超过此时间pod将会被驱逐到其他可用node节点上。因此5分钟后node节点上所有的pod重新被调度，在此期间服务是中断的。
既然默认的pod迁移无法避免服务中断，那么我们在node节点停机前，我们手动迁移是否可以？
手动迁移
为避免等待默认的5分钟，我们还可以使用cordon、drain、uncordor三个命令实现节点的主动维护。此时需要用到以下三个命令：
cordon：标记节点不可调度，后续新的pod不会被调度到此节点，但是该节点上的pod可以正常对外服务；
drain：驱逐节点上的pod至其他可调度节点；
uncordon：标记节点可调度；
具体操作过程如下：
# 1.标记节点不可调度# kubectl cordon k8s-3-219node/k8s-3-219 cordoned
# 查看节点状态，此时219被标记为不可调度# kubectl get nodeNAME STATUS ROLES AGE VERSIONk8s-3-217 Ready master 89d v1.18.2k8s-3-218 Ready <none> 88d v1.18.2k8s-3-219 Ready,SchedulingDisabled <none> 88d v1.18.2
# 2.驱逐pod# kubectl drain k8s-3-219 --delete-local-data --ignore-daemonsets --forcenode/k8s-3-219 already cordonedWARNING: ignoring DaemonSet-managed Pods: ingress-nginx/nginx-ingress-controller-gmzq6, kube-system/kube-flannel-ds-amd64-5gfwh, kube-system/kube-proxy-vdckkevicting pod kube-system/tiller-deploy-6c65968d87-75pfmevicting pod kube-system/metrics-server-7f96bbcc66-bgt7jevicting pod test/helloworld-79956d95b4-nnlrq
# 参数如下：--delete-local-data 删除本地数据，即使emptyDir也将删除；--ignore-daemonsets 忽略DeamonSet，否则DeamonSet被删除后，仍会自动重建；--force 不加force参数只会删除该node节点上的ReplicationController, ReplicaSet, DaemonSet,StatefulSet or Job，加上后所有pod都将删除；
# 3. 查看驱逐，219上的pod迁移到218上了。# kubectl get pod -n test -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATEShelloworld-79956d95b4-gg58c 0/1 Running 0 20s 10.244.1.165 k8s-3-218 <none> <none>helloworld-79956d95b4-nnlrq 1/1 Terminating 0 77m 10.244.2.215 k8s-3-219 <none> <none>
此时与默认迁移不同的是，pod会先重建再终止，服务中断时间=重建时间+服务启动时间+readiness探针检测正常时间，必须等到"1/1 Running"服务才会正常。因此在单副本时迁移时，服务终端是不可避免的。
如何能够做到平滑迁移呢？我们继续往下看。
平滑迁移
要做到平滑迁移就需要用的pdb(PodDisruptionBudget)，即主动驱逐保护。无论是默认迁移和手动迁移，都会导致服务中断，而pdb能可以实现节点维护期间不低于一定数量的pod正常运行，从而保证服务的可用性。
在仍以helloworld为例，由于只有一个副本，因此需要保证维护期间这个副本在迁移完成后，才会终止。
具体过程如下：
# 从218 驱逐到 219# 1.标记节点不可调度# kubectl cordon k8s-3-218node/k8s-3-218 cordoned
# 2.新建pdbvim pdb-test.yamlapiVersion: policy/v1beta1kind: PodDisruptionBudgetmetadata: name: pdb-test namespace: testspec: minAvailable: 1 selector: matchLabels: app: helloworld
# 2.应用并查看状态# kubectl apply -f pdb-test.yaml# kubectl get pdb -n testNAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGEpdb-test 1 N/A 0 7s
# 3.驱逐# kubectl drain k8s-3-218 --delete-local-data --ignore-daemonsets --forcenode/k8s-3-218 already cordonedWARNING: ignoring DaemonSet-managed Pods: ingress-nginx/nginx-ingress-controller-hhb6h, kube-system/kube-flannel-ds-amd64-pb4d7, kube-system/kube-proxy-rzdcjevicting pod kube-system/tiller-deploy-6c65968d87-ktqmmevicting pod kube-system/metrics-server-7f96bbcc66-6p6wmevicting pod test/helloworld-79956d95b4-gg58cerror when evicting pod "helloworld-79956d95b4-gg58c" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.evicting pod test/helloworld-79956d95b4-gg58cerror when evicting pod "helloworld-79956d95b4-gg58c" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.pod/tiller-deploy-6c65968d87-ktqmm evicted
#此时由于只有一个副本，最小可用为1，则ALLOWED就为0，因此在一个副本通过pdb是不会发生驱逐的。我们需要先扩容，将副本数调整为大于1。
# 3.手动调整副本数，将replicas为2kubectl edit deploy helloworld -n test# 再次查看pdb# kubectl get pdb -n testNAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGEpdb-test 1 N/A 1 13m
#此时最小可用为1 ，ALLOWED为1，此时是数量会自动计算。
# 4.驱逐# kubectl drain k8s-3-218 --delete-local-data --ignore-daemonsets --force
# 5.维护完毕，将node调整为可调度# kubectl uncordon k8s-3-218
本次驱逐，由于helloworld始终保持有一个pod在提供服务，因此服务是不中断的。
最后将副本数可以调节为1并将node节点调整为可调度，维护完毕。
注意：pod只有一个副本，最小可用为1，则ALLOWED就为0，因此在一个副本通过pdb是不会发生驱逐的。我们需要先扩容，将副本数调整为大于1。
总结
通过Pod迁移简单了解了Taint（污点）和 Toleration（容忍）作用，我们既可以通过设置tolerationSeconds来缩短等待时间，也可以自行定义匹配规则实现符合实际情况的调度规则。
另外还要注意先重建再终止和先终止再重建，在此过程中服务启动时间和探针检测时间决定你的服务中断时间。
2.Jenkins多分支流水线：Webhook按分支触发自动构建
6.蓝鲸实现vsphere虚拟机交付 -虚拟机管理(VSPHERE)