當(dāng)你在 Kubernetes 上使用容器時，你經(jīng)常把應(yīng)用程序組合在一個吊艙中。當(dāng)你把一個容器或一個吊艙發(fā)布到生產(chǎn)環(huán)境中時，它被稱為一個部署。如果你每天甚至每周都在使用 Kubernetes，你可能已經(jīng)這樣做過幾百次了，但你有沒有想過，當(dāng)你創(chuàng)建一個吊艙或一個部署時到底會發(fā)生什么?
我發(fā)現(xiàn)在高層次上了解事件鏈條是有幫助的。當(dāng)然，你不一定要理解它。即使你不知道為什么，它仍然在工作。我不打算列出每一件發(fā)生的小事，但我的目標(biāo)是涵蓋所有重要的事情。
這里有一張 Kubernetes 不同組件如何互動的視覺地圖。
吊艙鏈條你可能注意到，在上圖中，我沒有包括 etcd。API 服務(wù)器是唯一能夠直接與 etcd 對話的組件，而且只有它能夠?qū)?etcd 進行修改。因此，你可以認(rèn)為 etcd 在這張圖中存在于(隱藏的)API 服務(wù)器后面。
另外，我在這里只講到了兩個主要的控制器(部署控制器和復(fù)制集控制器)。其他的控制器的工作方式類似。
下面的步驟描述了當(dāng)你執(zhí)行 kubectl create 命令時會發(fā)生什么。
步驟 1
當(dāng)你使用 kubectl create 命令時，一個 HTTP POST 請求被發(fā)送到 API 服務(wù)器，其中包含部署清單。API 服務(wù)器將其存儲在 etcd 數(shù)據(jù)存儲中，并返回一個響應(yīng)給 kubectl。
步驟 2 和 3
API 服務(wù)器有一個觀察機制，所有觀察它的客戶都會得到通知。客戶端通過打開與 API 服務(wù)器的 HTTP 連接來觀察變化，API 服務(wù)器會流式地發(fā)出通知。其中一個客戶端是部署控制器。部署控制器檢測到一個部署對象，它用部署的當(dāng)前規(guī)格創(chuàng)建一個復(fù)制集。該資源被送回 API 服務(wù)器，并存儲在 etcd 數(shù)據(jù)存儲中。
步驟 4 和 5
與上一步類似，所有觀察者都會收到關(guān)于 API 服務(wù)器中的變化的通知。這一次，復(fù)制集控制器會接收這一變化。該控制器了解所需的副本數(shù)量和對象規(guī)格中定義的吊艙選擇器，創(chuàng)建吊艙資源，并將這些信息送回 API 服務(wù)器，存儲在 etcd 數(shù)據(jù)存儲中。
步驟 6 和 7
Kubernetes 現(xiàn)在擁有運行吊艙所需的所有信息，但吊艙應(yīng)該在哪個節(jié)點上運行?調(diào)度器觀察那些還沒有分配到節(jié)點的吊艙，并開始對所有節(jié)點進行過濾和排序，以選擇最佳節(jié)點來運行吊艙。一旦節(jié)點被選中，該信息將被添加到吊艙規(guī)格中。而且它被送回 API 服務(wù)器并存儲在 etcd 數(shù)據(jù)存儲中。
步驟 8、9 和 10
到目前為止的所有步驟都發(fā)生在控制平面本身。工作節(jié)點還沒有做任何工作。不過，吊艙的創(chuàng)建并不是由控制平面處理的。相反，在所有節(jié)點上運行的 kubelet 服務(wù)觀察 API 服務(wù)器中的吊艙規(guī)格，以確定它是否需要創(chuàng)建任何吊艙。在調(diào)度器選擇的節(jié)點上運行的 kubelet 服務(wù)獲得吊艙規(guī)格，并指示工作節(jié)點上的容器運行時創(chuàng)建容器。這時就會下載一個容器鏡像(如果它還不存在的話)，容器就會實際開始運行。
理解 Kubernetes 的部署
對這個一般流程的理解可以幫助你理解 Kubernetes 中的許多事件。考慮一下 Kubernetes 中的守護進程集DaemonSet或狀態(tài)集StatefulSet。除了使用不同的控制器外，吊艙的創(chuàng)建過程是一樣的。
原文地址:https://linux.cn/article-14317-1.html
