在工作節點與主節點斷開連接配接後，工作節點上的 Pod 是什麼狀态，是否在繼續運作？Kubernetes 控制器又在做什麼？本文對此進行了執行個體研究，一一解答。
作者：Bhargav Bhikkaji
翻譯：Bach(才雲)
校對：星空下的文仔(才雲)、bot(才雲)
由于各種原因，工作節點與主節點斷開連接配接的情況會經常發生。在這種情況下，其實有很多問題，例如，主節點是否删除了在無法連接配接的節點上運作的 Pod？Kubernetes 控制器的行為如何？Pod 是否在工作節點上繼續運作？簡而言之，我們想知道當節點變得不可通路時，Kubernetes 系統行為是什麼樣子的？
定義：在 Kubernetes 中，無法連接配接的節點稱為隔離節點(partitioned node)。
為了具體了解，讓我們建立一個隔離節點案例并了解其行為。
K8sMeetup
示例叢集
示例叢集具有一個主節點(master node)和 3 個工作節點(worker node)。這裡建立了具有 2 個副本的 Nginx Deployment。這些副本在不同的節點上運作：kind-worker2 和 kind-worker3。圖 1 展示了示例叢集的狀态：
圖1：示例叢集的狀态
K8sMeetup
建立一個隔離節點
建立一個隔離節點的簡單方法是删除節點的 IP 位址，即 kind-worker2。圖 2 展示了必要的步驟：
圖2：建立一個隔離節點
K8sMeetup
Kubernetes 系統的表現如何？
工作節點(kind-worker2)被設定為 NotReady 狀态，但 Pod 仍在繼續運作，這是因為負責節點的 kube-controller-manager 的 node-controller 部分在等待 pod-eviction-timeout，這是確定在 Pod 删除之前該節點是無法通路的。
pod-eviction-timeout 預設設定為 5 分鐘，可以在 kube-controller-manager 啟動過程中進行修改。
在 pod-eviction-timeout(示例中為 5 分鐘)之後，node-controller 将在隔離節點上運作的 pod 排程為 Termination 狀态。kube-controller-manager 的 Deployment Controller 部分開始在不同的節點上建立新的副本和排程。在示例中，我們在 kind-worker 節點上建立了一個 Nginx 副本。 圖 3 展示了 Kubernetes 系統上的所有狀态更改：
圖 3：主節點上的情況
K8sMeetup
隔離工作節點上運作的 Pod 會如何？
進入隔離工作節點，讓我們看看發生了什麼。從圖 4 中，我們可以觀察到 Pod 還在繼續運作，這是因為 API server 無法與隔離節點的 Kubelet 通信來删除 Pod。同樣，Kubelet 也無法控制運作哪些 Pod。
圖 4：Pod 繼續在隔離工作節點上運作
一旦隔離節點加入叢集，Pod 就能删除。
K8sMeetup
總結
當節點斷開連接配接後，很多事情都在背後發生，以下是簡單的總結：
- 當節點變得不可通路時，主節點會将節點設定為“NotReady”狀态。
- 主節點在執行任何操作之前會等待 pod-eviction-timeout。作為 kube-controller-manager 引導過程的一部分，預設情況下，pod-eviction-timeout 參數設定為 5 分鐘。
- 在 pod-eviction-timeout 時間之後，主節點的隔離節點 Pod 處于“Terminating”狀态，并會在不同節點上建立 Pod 新執行個體。
- 這些 Pod 會繼續在隔離節點上運作。
原文連結：https://medium.com/tailwinds-navigator/kubernetes-tip-what-happens-to-pods-running-on-node-that-become-unreachable-3d409f734e5d
推薦閱讀：
在看點一下