kubernetes 污點與容忍

前言

本文通過自身理解進行述說，如有不准確的地方，請指正。

在講述一系列相關專業術語之前，先嘗試用一個通俗易懂的故事來說明 Kubernetes 中 node 與 pod 之間的愛恨情仇。

雄性（node）| 雌性（pod）

在銀河系以外的一個星球上，有着一群兩性生物，分別是雌性（pod）和雄性（node）。雌性生物居多，而雄性生物由於優勝劣汰，只剩下3只優質的雄性生物（node）。雄雌在一起就容易產生吸引，就會有以下的情況產生：

（1）雄（node）少雌（pod）多，而這三只優質的雄性生物性格、優點都是一致的，雌性生物選誰都一樣。於是，雌性生物就分為均等分為三列和三只雄性生物在一起。這種類似於平均分配的原則。

k8s中的概念：在k8s中是最常見最普通的 pod 分布方式，常用與 deployment 和 daemonset 控制器。

（2）時間一長，生物開始了進化。三只雄性（node）生物各自有了不一樣的地方，編號1的雄性學會了種植（node01 label skill='grow'）；編號2的雄性學會了打獵（node02 label skill='hunt'）；編號3的雄性啥也沒學會（沒學會就保持默認）。普通的雌性（pod）仍然保持着平均分配的原則。而一些進化快的雌性（pod）生物發現了三只優質雄性（node）生物各自的不同，各自也開始有了一些選擇。一些雌性更加青睞學會種植的雄性生物（nodeSelector skill='grow'） ；一些雌性更加青睞學打獵的雄性生物（nodeSelector skill='hunt'） ；而有些雌性生物喜歡的特點很奇特，它們喜歡會飛的雄性，而僅存的三只雄性生物都無法滿足這一特點。如果有天一只雄性生物進化會飛了，它們就會依附與會飛的雄性生物，如果始終沒有進化出會飛的雄性生物，則它們一直等下去這在 k8s 中，就是 yaml 文件中 nodeSelector 的使用。

k8s中的概念：當 node 打上特定的標簽后，會出現如下情況：

1. pod 中未指定 nodeSelector ，則保持默認 schedule 調度算法的方式；
2. pod 中指定了 nodeSelector ，且指定 nodeSelector 中的 key、value 符合某一個 node 中的某一個key、value，則這個pod 直接調度到該node；
3. pod 中指定了 nodeSelector ，指定 nodeSelector 中的 key、value 不包含在任何一個 node 中，則這個 pod 會一直處於 padding 狀態。

（3）三只雄性（node）不僅優點增長了，缺點也隨之而來。編號1的雄性喜歡打臉（node01 taint hobby='face'）；編號2的雄性喜歡打屁股（node01 taint hobby='hunkers'）；編號3的雄性喜歡踩腳（node01 taint hobby='foot'）；普通的雌性（pod）生物仍然保持平均分配的原則，而一些再次進化的雌性生物也有了自己的性格。能夠容忍打臉的雌性則和編號1的雄性在一起（tolerations hobby='face'），但是這個容忍可能是永久，也可能是1天（tolerationSeconds=86400）。而這三只雄性生物偶爾會在一起鬼混，編號1的雄性生物說不定哪天就嗜好就變為了喜歡睡懶覺。而一些無法容忍它睡懶覺嗜好的雌性生物就會隔一段時間或者馬上就離開它。

k8s中的概念：這就是 污點 與 容忍。

污點和容忍還有其他的選項參數，后文展開解說。

nodeSelector

將 pod 分配給指定的節點。

集群如下：

[root@k8s-master ~]# kubectl get nodes
NAME         STATUS   ROLES    AGE   VERSION
k8s-master   Ready    master   20h   v1.19.7
k8s-node01   Ready    <none>   20h   v1.19.7
k8s-node02   Ready    <none>   20h   v1.19.7

為 k8s-node01 添加一個標簽

[root@k8s-master ~]# kubectl label nodes k8s-node01 disktype=ssd
node/k8s-node01 labeled

查看標簽

[root@k8s-master ~]# kubectl get nodes --show-labels
NAME         STATUS   ROLES    AGE   VERSION   LABELS
k8s-master   Ready    master   20h   v1.19.7   ..., kubernetes.io/hostname=k8s-master
k8s-node01   Ready    <none>   20h   v1.19.7   ..., disktype=ssd,kubernetes.io/hostname=k8s-node01
k8s-node02   Ready    <none>   20h   v1.19.7   ..., kubernetes.io/hostname=k8s-node02

可以看到 k8s-node01 節點標簽：disktype=ssd

創建一個調度到 選擇節點的 Pod

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: ngx
  name: ngx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: ngx
  template:
    metadata:
      labels:
        app: ngx
    spec:
      containers:
      - image: nginx:alpine-arm64
        name: nginx
      nodeSelector:
        disktype: ssd    ### 選擇服務 key: value 的節點

創建pod 查看是否調度到指定的節點

[root@k8s-master ~]# kubectl apply -f  ngx.yaml
deployment.apps/ngx created
[root@k8s-master ~]# kubectl get po -o wide
NAME                   READY   STATUS    RESTARTS   AGE   IP            NODE         NOMINATED NODE   READINESS GATES
ngx-5f4df66559-hjmzg   1/1     Running   0          10s   10.244.1.13   k8s-node01   <none>           <none>
ngx-5f4df66559-wqgdb   1/1     Running   0          10s   10.244.1.14   k8s-node01   <none>           <none>

k8s 親和性

說道親和性，親和性主要分為兩類：nodeAffinity 和 podAffinity 。

nodeAffinity

nodeAffinity 就是節點親和性，調度可以分成軟策略和硬策略兩種方式，軟策略就是如果你沒有滿足調度要求的節點的話，POD 就會忽略這條規則，繼續完成調度過程，說白了就是滿足條件最好了，沒有的話也無所謂了的策略；而硬策略就比較強硬了，如果沒有滿足條件的節點的話，就不斷重試直到滿足條件為止，簡單說就是你必須滿足我的要求，不然我就不干的策略。nodeAffinity就有兩上面兩種策略：

• requiredDuringSchedulingIgnoredDuringExecution ：硬策略

• preferredDuringSchedulingIgnoredDuringExecution ： 軟策略

硬策略

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: ngx
  name: ngx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: ngx
  template:
    metadata:
      labels:
        app: ngx
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: disktype	# key 的值
                operator: In	# 包括
                values:
                - ssd	# value 
      containers:
      - image: nginx:alpine-arm64
        name: nginx
      nodeSelector:
        disktype: ssd

上面這兩個 pod 只會運行在 滿足 node label disktype=value 的節點上，如果沒有節點滿足這個條件，則一直處於 pending 狀態。

[root@k8s-master ~]# kubectl get po -o wide
NAME                  READY   STATUS    RESTARTS   AGE     IP            NODE         NOMINATED NODE   READINESS GATES
ngx-7b65b44bc-gff9x   1/1     Running   0          3m53s   10.244.1.15   k8s-node01   <none>           <none>
ngx-7b65b44bc-w7bsf   1/1     Running   0          3m53s   10.244.1.16   k8s-node01   <none>           <none>
[root@k8s-master ~]# kubectl get nodes k8s-node01 --show-labels
NAME         STATUS   ROLES    AGE   VERSION   LABELS
k8s-node01   Ready    <none>   22h   v1.19.7   ..., disktype=ssd,kubernetes.io/arch=arm64,kubernetes.io/hostname=k8s-node01

軟策略

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: ngx
  name: ngx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: ngx
  template:
    metadata:
      labels:
        app: ngx
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 10
            preference:
              matchExpressions:
              - key: disktype
                operator: In
                values:
                - hdd

      containers:
      - image: nginx:alpine-arm64
        name: nginx

軟策略就是，第一選擇是 node label disktype=hdd 的節點，如果沒有，就采用默認 scheduler 的調度策略，沒有強制性。

[root@k8s-master ~]# kubectl get po -o wide
NAME                  READY   STATUS    RESTARTS   AGE     IP            NODE         NOMINATED NODE   READINESS GATES
ngx-d4754b6fd-lr96g   1/1     Running   0          2m55s   10.244.2.13   k8s-node02   <none>           <none>
ngx-d4754b6fd-ns7hs   1/1     Running   0          2m55s   10.244.1.28   k8s-node01   <none>           <none>

operator 提供如下幾種操作：

• In：label 的值在某個列表中
• NotIn：label 的值不在某個列表中
• Gt：label 的值大於某個值
• Lt：label 的值小於某個值
• Exists：某個 label 存在
• DoesNotExist：某個 label 不存在

如果nodeSelectorTerms下面有多個選項的話，滿足任何一個條件就可以了；如果matchExpressions有多個選項的話，則必須同時滿足這些條件才能正常調度 POD。

污點和容忍

在 Kubernetes 中，節點親和性 NodeAffinity 是 Pod 上定義的一種屬性，能夠使 Pod 按我們的要求調度到某個節點上，而 Taints(污點) 則恰恰相反，它是 Node 上的一個屬性，可以讓 Pod 不能調度到帶污點的節點上，甚至會對帶污點節點上已有的 Pod 進行驅逐。當然，對應的 Kubernetes 可以給 Pod 設置 Tolerations(容忍) 屬性來讓 Pod 能夠容忍節點上設置的污點，這樣在調度時就會忽略節點上設置的污點，將 Pod 調度到該節點。一般時候 Taints 通常與 Tolerations 配合使用。

污點（Taints）

查看污點

查看node 的污點

[root@k8s-master ~]# kubectl describe nodes k8s-master
...
Taints:             node-role.kubernetes.io/master:NoSchedule
...


也可通過下面操作查看：
[root@k8s-master ~]# kubectl get nodes k8s-master -o go-template={{.spec.taints}}
[map[effect:NoSchedule key:node-role.kubernetes.io/master]]

污點內容一般組成為 key、value 及一個 effect 三個元素，表現為：

<key>=<value>:<effect>

這里的 value 可以為空，表現形式為：

node-role.kubernetes.io/master:NoSchedule
- key: node-role.kubernetes.io/master
- value: 空
- effect: NoSchedule

設置污點

一般我們需要想要設置某個節點只允許特定的 Pod 進行調度，這時候就得對節點設置污點，可以按 kubectl taint node [node] key=value[effect] 格式進行設置，其中 effect 可取值如下：

• PreferNoSchedule： 盡量不要調度。
• NoSchedule： 一定不能被調度。
• NoExecute： 不僅不會調度, 還會驅逐 Node 上已有的 Pod。

一般時候我們設置污點，就像下面例子一樣對齊進行設置：

## 設置污點並不允許 Pod 調度到該節點
$ kubectl taint node k8s-master key1=value1:NoSchedule

## 設置污點盡量阻止污點調度到該節點
$ kubectl taint node k8s-master key2=value2:PreferNoSchedule

## 設置污點，不允許普通 Pod 調度到該節點，且將該節點上已經存在的 Pod 進行驅逐
$ kubectl taint node k8s-master key3=value3:NoExecute

刪除污點

上面說明了如何對 Node 添加污點阻止 Pod 進行調度，下面再說一下如何刪除節點上的污點，可以使用下面命令：

kubectl taint node [node] [key]-

上面語法和創建污點類似，不過需要注意的是刪除污點需要知道 key 和最后面設置一個 "-" 兩項將污點刪除，示例如下：

為了方便演示，先給節點設置污點：

## 設置污點1
# kubectl taint node k8s-master key1=value1:PreferNoSchedule
node/k8s-master tainted

## 設置污點2
# kubectl taint node k8s-master key2=value2:NoSchedule
node/k8s-master tainted

## 設置污點3，並且不設置 value
# kubectl taint node k8s-master key2=:PreferNoSchedule
node/k8s-master tainted

查看污點，可以看到上面設置的三個值：

[root@k8s-master ~]# kubectl describe nodes k8s-master
...
Taints:             key2=value2:NoSchedule
                    node-role.kubernetes.io/master:NoSchedule
                    key1=value1:PreferNoSchedule
                    key2:PreferNoSchedule
...

然后刪除污點

## 刪除污點，可以不指定 value，指定 [effect] 值就可刪除該 key[effect] 的污點
# kubectl taint node k8s-master key1:PreferNoSchedule-

## 也可以根據 key 直接將該 key2 的所有 [effect] 都刪除：
# kubectl taint node k8s-master key2-

再次查看污點，可以看到以上污點都被刪除：

[root@k8s-master ~]# kubectl describe nodes k8s-master
...
Taints:             node-role.kubernetes.io/master:NoSchedule
...

容忍(toleratints)

Pod 設置容忍

為了使某些 Pod 禁止調度到某些特定節點上，就可以對節點設置污點 taints。當然，如果希望有些 Pod 能夠忽略節點的污點，繼續能夠調度到該節點，就可以對 Pod 設置容忍，讓 Pod 能夠容忍節點上設置的污點，例如：

對一個節點設置污點：

kubectl taint node k8s-node01 key=value:NoSchedule

對於Pod 設置容忍， 以下兩種方式都可以：

## 容忍的 key、value 和對應 effect 也必須和污點 taints 保持一致
......
tolerations:
- key: "key"
  operator: "Equal"
  value: "value"
  effect: "NoSchedule"

## 容忍 tolerations 的 key 和要污點 taints 的 key 一致，且設置的 effect 也相同，不需要設置 value
......
tolerations:
- key: "key"
  operator: "Exists"
  effect: "NoSchedule"

Node 和 Pod 對於污點與容忍基本概念

概念

• 一個 node 可以有多個污點；
• 一個 pod 可以有多個容忍；
• kubernetes 執行多個污點和容忍方法類似於過濾器

如果一個 node 有多個污點，且 pod 上也有多個容忍，只要 pod 中容忍能包含 node 上設置的全部污點，就可以將 pod 調度到該 node上。如果 pod 上設置的容忍不能夠包含 node 上設置的全部污點，且 node 上剩下不能被包含的污點 effect 為 PreferNoSchedule，那么也可能會被調度到該節點。

注意

當 pod 總存在 容忍，首先 pod 會選擇沒有污點的節點，然后再次選擇容忍污點的節點。

• 如果 node 上帶有污點 effect 為 NoSchedule，而 pod 上不帶響應的容忍，kubernetes 就不會調度 pod 到這台 node 上。
• 如果 Node 上帶有污點 effect 為 PreferNoShedule，這時候 Kubernetes 會努力不要調度這個 Pod 到這個 Node 上。
• 如果 Node 上帶有污點 effect 為 NoExecute，這個已經在 Node 上運行的 Pod 會從 Node 上驅逐掉。沒有運行在 Node 的 Pod 不能被調度到這個 Node 上。 一般使用與當某個節點處於  NotReady 狀態下，pod 迅速在其他正常節點啟動。

Deployment 中設置容忍

在 kubernetes 中 deployment 設置容忍，示例如下：

apiVersion: apps/vl
kind: Deployment
metadata: 
  name: example 
spec: 
  replicas: 5 
  template:
    spec: 
      ......
      tolerations: 
      - key: "key"
        operator: "Equal"
        value: "value"
        effect: "NoSchedule"

設置容忍時間

正常情況下， 如果一個污點帶有 effect=NoExecute 被添加到了這個 Node。 那么不能容忍這個污點的所有 Pod 就會立即被踢掉。 而帶有容忍標簽的 Pod 就不會踢掉。 然而，一個帶有 effect=Noexecute 的容忍可以指定一個 tolerationSeconds 來指定當這個污點被添加的時候在多長時間內不被踢掉。例如：

tolerations:
- key: "key"
  operator: "Equal"
  value: "value"
  effect: "Noexecute"
  tolerationSeconds: 3600

如果這個 Pod 已經在這個帶污點且 effect 為 NoExecute 的 node 上。這個 pod 可以一直運行到 3600s 后再被踢掉。如果這時候 Node 的污點被移除了，這個 Pod 就不會被踢掉。

容忍示例

Operator 默認是 Equal，可設置為 Equal 與 Exists 兩種，按這兩種進行示例：

Operator 是 Exists

容忍任何污點

例如一個空的key，將匹配所有的key、value、effect。即容忍任何污點。

tolerations:
- operator: "Exists"

容忍某 key 值的污點

例如一個空的 effect，並且 key 不為空，那么將匹配所有與 key 相同的 effect：

tolerations:
- key: "key"
  operator: "Exists"

Operator 是 Equal

node 上有一個污點

Node 和 Pod 的 key 為 key1、value1 與 effect 相同則能調度：

#污點
key1=value1:NoSchedule

#Pod設置
tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"

node 上有多個污點

Node 的污點的 key、value、effect 和 Pod 容忍都相同則能調度：

# 設置污點
key1=value1:NoSchedule
key2=value2:NoExecute

# Pod設置容忍
tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"
- key: "key2"
  operator: "Equal"
  value: "value2"
  effect: "NoExecute"

Node 的污點和 Pod 的大部分都相同，不同的是 Node 污點 effect 為 PreferNoSchedule 的，可能會調度：

# 污點
key1=value1:NoSchedule
key2=value2:NoExecute
key3=value3:PreferNoSchedule

# Pod設置容忍
tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"
- key: "key2"
  operator: "Equal"
  value: "value2"
  effect: "NoExecute"

Node 的污點和 Pod 的大部分都相同，不同的是 Node 污點 effect 為 NoSchedule 和 NoExecute 的，不會被調度：

# 污點
key1=value1:NoSchedule
key2=value2:NoExecute
key3=value3:PreferNoSchedule

# Pod設置容忍
tolerations:
- key: "key1"
  operator: "Equal"
  value: "value1"
  effect: "NoSchedule"
- key: "key3"
  operator: "Equal"
  value: "value3"
  effect: "PreferNoSchedule"

對比理解 Exists 和 Equal 之間的區別：

• Exists 是包含，Equal 是等於，Exists 使用范圍更廣，而 Equal 則是精准匹配。
• 當污點中存在 NoExecute 時，而容忍中不存在 NoExecute時，不會被調度到該節點。
• Exists 可以不寫 value ， 而 Equal 則一定要指定對應的 value

污點驅逐

在使用 kubernetes 時，會遇到 某個 node 節點明明已經 宕機了，查看 node 狀態從 Ready 狀態變為 NotReady 狀態，但是 節點所在的 pod 卻已經處於 running 狀態，過了很長一段時間才會轉為 Terminating 狀態，這是為什么呢？

污點是對於 node 節點來講，如果 node 節點 effect 設置為 NoExecute ，它會影響節點上已經運行的 Pod，如下所示：

• 立即將沒有匹配容忍的 pod 驅逐。
• 設置容忍但是沒有指定 tolerationSeconds 參數的，那么該容忍永久生效，不會被驅逐。
• 設置容忍但是有指定 tolerationSeconds 參數的，那么在指定的時間內容忍有效，超過指定時間后將被剔除。 （pod 默認設置，tolerationSeconds = 300s）

此外，當某些條件為 true 時，節點控制器會自動污染節點。內置以下污點：

key	注釋
node.kubernetes.io/not-ready	節點尚未准備好。這對應於 NodeCondition Ready 為 false。
node.kubernetes.io/unreachable	無法從節點控制器訪問節點。這對應於 NodeCondition Ready 為 Unknown。
node.kubernetes.io/out-of-disk	節點磁盤不足。
node.kubernetes.io/memory-pressure	節點有內存壓力。
node.kubernetes.io/disk-pressure	節點有磁盤壓力。
node.kubernetes.io/network-unavailable	節點的網絡不可用。
node.kubernetes.io/unschedulable	節點不可調度。
node.cloudprovider.kubernetes.io/uninitialized	當 kubelet 從 "外部" 雲提供程序開始時，此污點在節點上設置為將其標記為不可用。來自 cloud-controller-manager 的控制器初始化此節點后，kubelet 刪除此污點。

通過上面知識的鋪墊，當一個節點宕機時，kubernetes集群會給它打上什么樣的污點呢？

一個 Ready 狀態的節點

[root@k8s-master(192.168.1.11) ~]#kubectl get node k8s-node02 -o go-template={{.spec.taints}}
<no value>

一個 NotReady 狀態的節點

[root@k8s-master(192.168.1.11) ~]#kubectl get node k8s-node02 -o go-template={{.spec.taints}}
[map[effect:NoSchedule key:node.kubernetes.io/unreachable timeAdded:2021-12-23T13:49:58Z] map[effect:NoExecute key:node.kubernetes.io/unreachable timeAdded:2021-12-23T13:50:03Z]]

處於 NotReady 狀態的節點被打上了下面兩個污點：

Taints:             node.kubernetes.io/unreachable:NoExecute
                    node.kubernetes.io/unreachable:NoSchedule

接下來測試 kubernetes 集群會給 Pod 分配什么樣的容忍。

[root@k8s-master(192.168.1.11) ~]#kubectl get po nginx-745b4df97d-mgdmp -o yaml
...
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300  # 300/60=5min
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300	# 300/60=5min
...

看到這里，Pod 的失效機制已經很明白了， 當 node 節點處於 NotReady 狀態或者 unreachable 狀態時，Pod 會容忍它 5 分鍾，然后被驅逐。而這 5 分鍾內就算 Pod 處於 running 狀態，也是無法正常提供服務的。因此，可以在 yaml 清單中 手動指明 0 容忍，清單文件如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      tolerations:
      - effect: NoExecute
        key: node.kubernetes.io/not-ready
        operator: Exists
        tolerationSeconds: 0
      - effect: NoExecute
        key: node.kubernetes.io/unreachable
        operator: Exists
        tolerationSeconds: 0
      containers:
      - image: nginx:alpine
        name: nginx

生成Pod

[root@k8s-master(192.168.1.11) ~]#kubectl get po -o wide
NAME                    READY   STATUS    RESTARTS   AGE   IP            NODE         NOMINATED NODE   READINESS GATES
nginx-84f6f75c6-c76fm   1/1     Running   0          6s    10.244.3.16   k8s-node02   <none>           <none>
nginx-84f6f75c6-hsxq5   1/1     Running   0          6s    10.244.3.15   k8s-node02   <none>           <none>
nginx-84f6f75c6-wkt52   1/1     Running   0          6s    10.244.1.63   k8s-node01   <none>           <none>
nginx-84f6f75c6-xmkjs   1/1     Running   0          6s    10.244.3.17   k8s-node02   <none>           <none>

接下來強制關閉 k8s-node02 節點，查看 Pod是否轉移。

[root@k8s-master(192.168.1.11) ~]#kubectl get po -o wide
NAME                    READY   STATUS        RESTARTS   AGE    IP            NODE         NOMINATED NODE   READINESS GATES
nginx-84f6f75c6-c76fm   1/1     Terminating   0          116s   10.244.3.16   k8s-node02   <none>           <none>
nginx-84f6f75c6-csqf4   1/1     Running       0          13s    10.244.1.66   k8s-node01   <none>           <none>
nginx-84f6f75c6-hsxq5   1/1     Terminating   0          116s   10.244.3.15   k8s-node02   <none>           <none>
nginx-84f6f75c6-r2v4p   1/1     Running       0          13s    10.244.1.64   k8s-node01   <none>           <none>
nginx-84f6f75c6-v4knq   1/1     Running       0          13s    10.244.1.65   k8s-node01   <none>           <none>
nginx-84f6f75c6-wkt52   1/1     Running       0          116s   10.244.1.63   k8s-node01   <none>           <none>
nginx-84f6f75c6-xmkjs   1/1     Terminating   0          116s   10.244.3.17   k8s-node02   <none>           <none>

在 node 節點轉為 NotReady 狀態后，Pod 立刻進行了轉移。這是通過 在yaml清單文件中明確指定 容忍時間。還可以直接修改 apiserver 配置來修改默認容忍時間。

vim /etc/kubernetes/manifests/kube-apiserver.yaml
...
spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=192.168.1.11
    - --default-not-ready-toleration-seconds=1    # 新增行
    - --default-unreachable-toleration-seconds=1  # 新增行
...

修改保存后， kube-apiserver-k8s-master pod 會自動重載最新配置。

[root@k8s-master(192.168.1.11) ~]#kubectl get po nginx-84f6f75c6-wkt52 -o yaml 
...
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 0
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 0
...

對於小型集群，可以直接設置全局變量。

注意：當kubernetes集群只有一個 node 節點時，無法做到 Pod 轉移，因為 Pod 已經無路可退了。

參考鏈接：
http://www.mydlq.club/article/69/

--- EOF ---