k8s-"節點控制器驅逐Pod"

1 查看node信息

# kubectl describe node <node-name>
注: Conditions-Ready-Status, 如果節點是健康的且已經就緒可以接受新的Pod。則節點Ready字段為 True。False表明了該節點不
健康，不能夠接受新的Pod, Unknown表示節點不可達。

2 節點控制器驅逐Pod

(1) 節點控制器監控節點的健康狀況。當節點變得不可觸達時（例如，由於節點已停機，節點控制器不再收到來
自節點的心跳信號），節點控制器將節點API對象的 NodeStatus Condition 取值從 NodeReady 更新為 Unknown
；然后在等待 pod-eviction-timeout 時間后，將節點上的所有 Pod 從節點驅逐。
默認40秒未收到心跳，修改 NodeStatus Condition 為 Unknown；
默認 pod-eviction-timeout 為 5分鍾
節點控制器每隔 --node-monitor-period 5秒檢查一次節點的狀態

(2) 大多數情況下，節點控制器限制了驅逐 Pod 的速率為 --node-eviction-rate （默認值是0.1）每秒，即節點控
制器每 10 秒驅逐 1 個 Pod。

(3) 如果 Ready 類型Condition 的 status 持續為 Unkown 或者 False 超過 pod-eviction-timeout（kube-controller
-manager的參數）所指定的時間，節點控制器（node controller）將對該節點上的所有 Pod 執行刪除的調度動作。默認的 pod-eviction-timeout 時間是 5 分鍾。某些情況下（例如，節點網絡故障），apiserver 不能夠與節點上的 kubelet 通信，刪除 Pod 的指令不能下達到該節點的 kubelet 上，直到 apiserver 與節點的通信重新建立，指令才下達到節點。這意味着，雖然對 Pod 執行了刪除的調度指令，但是這些 Pod 可能仍然在失聯的節點上運行。

在 kubernetes v1.5 以前，節點控制器將從 apiserver 強制刪除這些失聯節點上的 Pod。在 v1.5 及以后的版本中，節點控制器將不會強制刪除這些 Pod，直到已經確認他們已經停止運行為止。您可能會發現失聯節點上的 Pod 仍然在運行（在該節點上執行 docker ps 命令可查看容器的運行狀態），然而 apiserver 中，他們的狀態已經變為 Terminating 或者 Unknown。如果 Kubernetes 不能通過node-manager 判斷失聯節點是否已經永久從集群中移除（例如，在虛擬機或物理機上自己部署 Kubernetes 的情況），集群管理員需要手工（通過 kubectl delete node your-node-name 命令）刪除 apiserver 中的節點對象。此時，Kubernetes 將刪除該節點上的所有Pod。

在Kubernetes v1.12 中，TaintNodesByCondition 特性進入 beta 階段，此時 node lifecycle controller 將自動創建該 Condition 對應的 污點。相應地，調度器在選擇合適的節點時，不再關注節點的 Condition，而是檢查節點的污點和 Pod 的容忍。

(4) 最極端的情況是，集群中一個健康的節點都沒有，此時節點控制器 master 節點的網絡連接出現故障，並停
止所有的驅逐 Pod 的動作，直到某些連接得到恢復。

3 示例

(1) 查看pod，分布在k8s-node2節點上

(2) 停止k8s-node2主機
[root@k8s-node2 ~]# shutdown -h now
(4) 40s后節點狀態變為unknown
[root@k8s-admin ~]# kubectl describe node k8s-node2

(5) 5m40s后，原k8s-node2節點上的pod被驅逐且狀態變為Terminating，此時在k8s-node1節點上
啟動了一個新的pod

(6) 啟動k8s-node2節點，原k8s-node2節點上Terminating狀態的pod被刪除，只剩k8s-node1上的pod
# 查看k8s-node2節點狀態
[root@k8s-admin ~]# kubectl describe node k8s-node2

# 查看當前pod分布節點