Kubernetes 部署的可視化地圖

當你在 Kubernetes 上使用容器時，你經常把應用程序組合在一個 吊艙 pod 中。當你把一個容器或一個吊艙發布到生產環境中時，它被稱為一個 部署 deployment 。如果你每天甚至每周都在使用 Kubernetes，你可能已經這樣做過幾百次了，但你有沒有想過，當你創建一個吊艙或一個部署時到底會發生什麼？

我發現在高層次上了解事件鏈條是有幫助的。當然，你不一定要理解它。即使你不知道為什麼，它仍然在工作。我不打算列出每一件發生的小事，但我的目標是涵蓋所有重要的事情。

這裡有一張 Kubernetes 不同組件如何互動的視覺地圖。


你可能注意到，在上圖中，我沒有包括 etcd。API 伺服器是唯一能夠直接與 etcd 對話的組件，而且只有它能夠對 etcd 進行修改。因此，你可以認為 etcd 在這張圖中存在於（隱藏的）API 伺服器後面。

另外，我在這裡只講到了兩個主要的控制器（ 部署控制器 Deployment controller 和 複製集控制器 ReplicaSet controller ）。其他的控制器的工作方式類似。

下面的步驟描述了當你執行 kubectl create 命令時會發生什麼。

步驟 1

當你使用 kubectl create 命令時，一個 HTTP POST 請求被發送到 API 伺服器，其中包含部署清單。API 伺服器將其存儲在 etcd 數據存儲中，並返回一個響應給 kubectl。

步驟 2 和 3

API 伺服器有一個觀察機制，所有觀察它的客戶都會得到通知。客戶端通過打開與 API 伺服器的 HTTP 連接來觀察變化，API 伺服器會流式地發出通知。其中一個客戶端是部署控制器。部署控制器檢測到一個 部署 Deployment 對象，它用部署的當前規格創建一個 複製集 ReplicaSet 。該資源被送回 API 伺服器，並存儲在 etcd 數據存儲中。

步驟 4 和 5

與上一步類似，所有觀察者都會收到關於 API 伺服器中的變化的通知。這一次，複製集控制器會接收這一變化。該控制器了解所需的副本數量和對象規格中定義的吊艙選擇器，創建吊艙資源，並將這些信息送回 API 伺服器，存儲在 etcd 數據存儲中。

步驟 6 和 7

Kubernetes 現在擁有運行吊艙所需的所有信息，但吊艙應該在哪個節點上運行？ 調度器 Scheduler 觀察那些還沒有分配到節點的吊艙，並開始對所有節點進行過濾和排序，以選擇最佳節點來運行吊艙。一旦節點被選中，該信息將被添加到吊艙規格中。而且它被送回 API 伺服器並存儲在 etcd 數據存儲中。

步驟 8、9 和 10

到目前為止的所有步驟都發生在 控制平面 control plane 本身。 工作節點 worker node 還沒有做任何工作。不過，吊艙的創建並不是由控制平面處理的。相反，在所有節點上運行的 kubelet 服務觀察 API 伺服器中的吊艙規格，以確定它是否需要創建任何吊艙。在調度器選擇的節點上運行的 kubelet 服務獲得吊艙規格，並指示工作節點上的容器運行時創建容器。這時就會下載一個容器鏡像（如果它還不存在的話），容器就會實際開始運行。

理解 Kubernetes 的部署

對這個一般流程的理解可以幫助你理解 Kubernetes 中的許多事件。考慮一下 Kubernetes 中的 守護進程集 DaemonSet 或 狀態集 StatefulSet 。除了使用不同的控制器外，吊艙的創建過程是一樣的。

課後作業：如果部署被修改為有三個應用程序的副本，導致創建吊艙的事件鏈條會是什麼樣子？你可以參考圖表或列出的步驟，但你肯定有你需要弄清楚的知識。知識就是力量，你現在有了了解 Kubernetes 的一個重要組成部分。

via: https://opensource.com/article/22/3/visual-map-kubernetes-deployment

作者：Nived Velayudhan 選題：lujun9972 譯者：wxy 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive