介紹
幾天前，我在我曾經就讀的大學舉辦了一場關於 Kubernetes 及其元件的演講。我媽媽說她喜歡這個演講，所以我把它變成了一篇部落格文章。
許多軟體工程師傾向於忽視與 Kubernetes 相關的任何東西，儘管他們可能每天都會使用它。乍一看，它似乎很複雜，就像一個需要潛入的全新世界。是的，確實如此，但在這篇文章中，我將介紹 Kubernetes 叢集的所有主要元件，並在範例中解釋它們的作用。
在這篇文章結束時，您不會成為 Kubernetes 專家，但您可能會很好地了解要尋找什麼以及如何建立 Kubernetes 最初看起來的混亂狀態。
代表 Kubernetes 架構的圖片取自 Kubernetes 網站
向我們展示您的支持🙏🏻
在我們開始之前，如果您為我們的儲存庫加註星標並幫助我們在其他開發人員面前獲得我們的工具，我們將非常高興。我們的 GitHub 儲存庫位於：https://github.com/cyclops-ui/cyclops ⭐
成分
首先，我們可以將 Kubernetes 叢集分為兩部分：控制平面和工作節點。控制平面負責整個操作並控制集群的狀態。我們很快就會了解這意味著什麼。另一方面，我們的工作節點本質上只是監聽控制平面告訴它們要做什麼的電腦。它們是我們集群的運算能力。我們在叢集中執行的任何應用程式都將在這些節點上執行。
讓我們進一步分解。
控制平面
正如我們所說，控制平面確保我們的叢集能如預期運作。它透過與叢集用戶通訊、調度工作負載、管理叢集狀態等來實現這一點。
控制平面由四個關鍵元件組成。它們本身很簡單，但一起建立了一個複雜的系統。這些元件是：
-
API
-
ETCD
-
調度程序
-
控制器經理
控制平面元件可以在叢集中的任何機器上執行，但通常在一組單獨的機器上執行，通常稱為主節點。這些機器不用於執行任何其他容器或應用程式，而是為 Kubernetes 控制平面保留。
API
Kubernetes API 充當叢集的前端接口，允許使用者與叢集互動、定義所需狀態以及執行建立、更新和刪除資源等操作。
這是我們與集群的唯一聯繫點。此外，沒有其他元件直接相互通信，但所有通信都是透過 API 進行的。
ETCD
ETCD 是 API 的資料庫；就這麼簡單。當您告訴 Kubernetes 建立部署時，它會與所有其他建立的資源一起儲存在 ETCD 中。
ETCD 的一個特點是它的鍵值儲存被組織為檔案系統。 ETCD 的另一個出色功能是用戶可以訂閱事件並獲得有關更改的通知。例如，建立新 Pod 時讓我知道。
調度程序
顧名思義，調度程式決定 pod 將在哪個節點上執行。它透過一組規則來實現這一點，您可以在 Kubernetes 文件 中閱讀。 這就是我說你不會成為專家時的意思，但你會知道要谷歌什麼:)
調度程序訂閱保存在 ETCD 中的所有新建立的 pod，但它只能與 API 通訊來取得此更新。
當它發現 Pod 已建立時，它會計算在哪個工作節點上執行它。一旦決定，調度程序不會在任何機器上執行任何東西；它只是告訴 API 在特定節點上執行 pod。
控制器管理器
控制平面的最後一個元件是控制器管理器。我們可以把它當作我們集群的恆溫器。它的工作是將集群的當前狀態轉變為所需的狀態。
這意味著它將在幕後建立所有需要的資源來滿足我們的需求並使我們的應用程式啟動並執行。
它執行多個控制器進程，這些進程訂閱了 ETCD 上的更改，並編譯成相同的二進位檔案以便於部署。控制器管理員的角色以及這些控制器的作用將在部落格後面進行更詳細的定義。
工作節點
現在我們已經了解了整個叢集的管理方式，接下來讓我們深入了解容器在哪裡運作以及如何實現這一點。
Kubernetes 叢集中的每個節點上執行 3 個元件。當然，您可以在叢集中擁有多個節點，但每個節點都需要這三個元件來託管您的應用程式。
那些是：
-
容器運作時
-
kubelet
-
成為代理
容器執行時
允許 Kubernetes 執行容器並管理節點上容器的生命週期的元件是容器執行時。
支援多個容器執行時，例如conatinerd、cri-o 或其他CRI 相容執行時。
庫貝萊特
另一個訂閱 pod 事件的元件是 Kubelet。每次在節點上調度 pod 時，該節點上執行的 Kubelet 都會聽到該訊息並啟動所有定義的容器。最重要的是，Kubelet 還執行健康檢查，以確保一切能如預期運作。
成為代理
Kubernetes 中的 KubeProxy 管理叢集中 pod 之間的網路連接，處理負載平衡和網路路由等任務。它透過維護網路規則並將服務抽象轉換為可操作的網路策略來確保 Pod 之間的無縫通訊。
從部署到正在執行的容器
現在我們已經列出了 Kubernetes 叢集中的所有元件及其角色，接下來讓我們講述一個有關 Kubernetes 部署如何成為在叢集中的各種電腦上執行的一組容器的故事。
Pod、副本集和部署
快速提醒這三者的關係：Pod、Replicaset 和 Deployment。
我們可以在 Kubernetes 叢集中部署的最小單元是 pod。有了它，我們將定義我們的容器。
最有可能的是，我們需要同一應用程式的幾個實例，並且我們可以定義如何使用 Replicaset 複製我們的 pod。它將透過啟動和終止來確保我們有所需數量的 Pod 執行。
太棒了，現在我們已經複製了我們的應用程式，但我們想推出新版本的應用程式。我們必須拆除現有的 Pod/Replicaset 並建立新的。部署將自動執行此流程，使我們能夠安全地推出我們的功能。
威望
現在我們已經了解了所有術語並觸及了所有 Kubernetes 元件及其角色，讓我們看看當我們將 Deployment「套用」到 Kubernetes 叢集時會發生什麼。
假設我們已經建立了一個定義應用程式的「deployment.yaml」檔案（您可以在此處了解如何執行此操作）並執行「kubectl apply -f deployment. yaml” 。 kubectl 現在將把我們的部署定義提交到叢集的唯一的聯絡點 - Kubernetes API。
我們的簡單 API 將把我們的部署儲存在 ETCD 資料庫中。每次將 Deployment 物件儲存到 ETCD 時，它都會讓 API 知道 Deployments 發生了更改，並且它應該讓每個訂閱此類事件的人知道這一點。
控制平面中有一個元件想要知道何時產生新的部署，這就是控制器管理器。當它聽到新的 Deployment 時，它將根據 Deployment 配置建立一個新的 Replicaset。為了建立此 Replicaset，它將透過建立請求來呼叫 API。
建立 Replicaset 與建立 Deployment 非常相似。 API 將接收一個 Replicaset 來建立並儲存到 ETCD 中。這將使 ETCD 告訴 API 有人建立了一個 Replicaset 並將該資訊傳遞給所有訂閱的元件，這又是控制器管理器。
當 Controller Manager 聽到新的 Replicaset 時，它會透過呼叫 API 來建立使用該 Replicaset 定義的所有 Pod，您猜對了，該 API 會將所有這些 Pod 儲存到 ETCD 中。
正如我們所說，發生了很多事情，因此我們決定建立一個 GIF 來幫助您了解整個過程。
在這裡，我們包括了 Scheduler，它訂閱了 Pod 建立事件。每次聽到新的 Pod 時，它都會決定應該在哪個節點上執行。 Scheduler 並沒有執行 Pod，只是告訴 API** 它為其選擇了哪個節點。然後 API 將保存該資訊。
另一個監聽 Pod 事件的元件是 Kubelet，它是執行在 Kubernetes 叢集中每個工作節點上的元件。每次 API 告訴 Kubelet Scheduler 決定在其節點上執行 Pod 時，Kubelet 將啟動 Pod 定義的所有容器。
最後，我們將配置變成了在機器上執行的應用程式！這是一個漫長的過程，有很多移動部分，但這可能是我最喜歡的部分。
每個元件只承擔部署應用程式的一小部分責任，但它們一起解決了一個相當複雜的問題。
最後的想法
希望本文能幫助您掌握 Kubernetes 元件，並幫助您揭開最受歡迎的編排器的神秘面紗。我們鼓勵您自行挖掘，因為我們很高興了解這一點。
我們推薦學習 Kubernetes 的一本書是 Marko Lukša 的《Kubernetes in action》。它非常受歡迎，並且很好地概述了 Kubernetes 背後發生的事情以及如何使用它。
原文出處：https://dev.to/cyclops-ui/complexity-by-simplicity-a-deep-dive-into-kubernetes-components-4l59
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式