需求

k8s集群中的node节点要升级内存,以应对服务迁入、pod扩缩容导致的资源短缺,需要对node节点进行停机维护,那么此时node节点上的pod应该如何处理呢?

下面我们来看一下。

默认迁移

当node节点关机后,k8s集群并没有立刻发生任何自动迁移动作,如果该node节点上的副本数为1,则会出现服务中断的情况。其实事实并非如此,k8s在等待5分钟后,会自动将停机node节点上的pod自动迁移到其他node节点上。

具体过程如下:

# 1.模拟node节点停机,停止kubelet
systemctl stop kubelet

# 2.集群状态
# 此时停机的node点处于NotReady状态
# kubectl get node
NAME                STATUS     ROLES     AGE   VERSION
k8s-3-217   Ready        master     88d   v1.18.2
k8s-3-218   NotReady   <none>   88d   v1.18.2
k8s-3-219   Ready        <none>   88d   v1.18.2

# 3.监控pod状态,大约等待5分钟左右,集群开始有动作
# kubectl get pod -n test -o wide -n test -w
NAME                                   READY   STATUS    RESTARTS   AGE   IP             NODE           NOMINATED NODE   READINESS GATES
helloworld-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.cn
Hello,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-218
Roles:              <none>
CreationTimestamp:  Fri, 22 May 2020 11:36:16 +0800
Taints:             node.kubernetes.io/unreachable:NoExecute
                    node.kubernetes.io/unreachable:NoSchedule
Unschedulable:      false
Lease:
  HolderIdentity:  k8s-3-218
  AcquireTime:     <unset>
  RenewTime:       Wed, 19 Aug 2020 09:31:22 +0800
Conditions:
  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 test
Name:                      helloworld-8565c4687b-rrfmj
Namespace:                 test
Priority:                  0
......
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:          <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-219
node/k8s-3-219 cordoned

# 查看节点状态,此时219被标记为不可调度
# kubectl get node
NAME           STATUS                     ROLES    AGE   VERSION
k8s-3-217   Ready                      master   89d   v1.18.2
k8s-3-218   Ready                      <none>   88d   v1.18.2
k8s-3-219   Ready,SchedulingDisabled   <none>   88d   v1.18.2

# 2.驱逐pod
# kubectl drain k8s-3-219 --delete-local-data --ignore-daemonsets --force
node/k8s-3-219 already cordoned
WARNING: ignoring DaemonSet-managed Pods: ingress-nginx/nginx-ingress-controller-gmzq6, kube-system/kube-flannel-ds-amd64-5gfwh, kube-system/kube-proxy-vdckk
evicting pod kube-system/tiller-deploy-6c65968d87-75pfm
evicting pod kube-system/metrics-server-7f96bbcc66-bgt7j
evicting 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 wide
NAME                                   READY   STATUS        RESTARTS   AGE   IP             NODE           NOMINATED NODE   READINESS GATES
helloworld-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-218
node/k8s-3-218 cordoned

# 2.新建pdb
vim pdb-test.yaml
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: pdb-test
  namespace: test
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: helloworld

# 2.应用并查看状态
# kubectl apply -f pdb-test.yaml
# kubectl get pdb -n test
NAME       MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
pdb-test   1                         N/A                          0                                       7s

# 3.驱逐
# kubectl drain k8s-3-218 --delete-local-data --ignore-daemonsets --force
node/k8s-3-218 already cordoned
WARNING: ignoring DaemonSet-managed Pods: ingress-nginx/nginx-ingress-controller-hhb6h, kube-system/kube-flannel-ds-amd64-pb4d7, kube-system/kube-proxy-rzdcj
evicting pod kube-system/tiller-deploy-6c65968d87-ktqmm
evicting pod kube-system/metrics-server-7f96bbcc66-6p6wm
evicting pod test/helloworld-79956d95b4-gg58c
error 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-gg58c
error 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为2
kubectl edit deploy helloworld -n test
# 再次查看pdb
# kubectl get pdb -n test
NAME       MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
pdb-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节点调整为可调度,维护完毕。

总结

通过简单了解了Taint(污点)和 Toleration(容忍)作用,我们既可以通过设置tolerationSeconds来缩短等待时间,也可以自行定义匹配规则实现符合实际情况的调度规则。
另外还要注意先重建再终止和先终止再重建,在此过程中服务启动时间和探针检测时间决定你的服务中断时间。

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐