叢集架構

Kubernetes 背後的架構概念。

Kubernetes 叢集由控制平面以及一組稱為節點的工作機器組成，這些機器執行容器化應用程式。每個叢集至少需要一個工作節點才能執行 Pod。

工作節點託管 Pod，這些 Pod 是應用程式工作負載的元件。控制平面管理叢集中的工作節點與 Pod。在生產環境中，控制平面通常跨多部電腦執行，而叢集通常執行多個節點，以提供容錯能力與高可用性。

本文件概述完整且可運作的 Kubernetes 叢集所需的各種元件。

The control plane (kube-apiserver, etcd, kube-controller-manager, kube-scheduler) and several nodes. Each node is running a kubelet and kube-proxy. — 圖 1. Kubernetes 叢集元件。

關於此架構

圖 1 中的圖表呈現 Kubernetes 叢集的範例參考架構。元件的實際分佈可能因特定的叢集設定與需求而異。

在圖表中，每個節點都執行 kube-proxy 元件。您需要在每個節點上安裝網路代理元件，以確保服務 API 與相關行為可在您的叢集網路上使用。然而，部分網路外掛程式提供它們自己的協力廠商代理實作。當您使用該類型的網路外掛程式時，節點不需要執行 kube-proxy。

控制平面元件

控制平面的元件會對叢集做出全域決策 (例如，排程)，以及偵測與回應叢集事件 (例如，當部署的 複本 欄位不符合時，啟動新的 pod)。

控制平面元件可以在叢集中的任何機器上執行。然而，為了簡化，設定腳本通常在同一部機器上啟動所有控制平面元件，並且不在這部機器上執行使用者容器。請參閱使用 kubeadm 建立高可用性叢集，以取得跨多部機器執行的範例控制平面設定。

kube-apiserver

API 伺服器是 Kubernetes 控制平面的元件，其公開 Kubernetes API。API 伺服器是 Kubernetes 控制平面的前端。

Kubernetes API 伺服器的主要實作是 kube-apiserver。kube-apiserver 旨在水平擴充，也就是說，它透過部署更多執行個體來擴充。您可以執行多個 kube-apiserver 執行個體，並在這些執行個體之間平衡流量。

etcd

一致且高度可用的鍵值儲存，用作 Kubernetes 的後端儲存以儲存所有叢集資料。

如果您的 Kubernetes 叢集使用 etcd 作為其後端儲存，請確保您有資料的備份計畫。

您可以在官方文件中找到關於 etcd 的深入資訊。

kube-scheduler

控制平面的元件，會監看新建立且尚未指派Pod 的節點，並為它們選擇一個節點來執行。

排程決策考量的因素包括：個別和集體資源需求、硬體/軟體/政策限制、親和性與反親和性規範、資料區域性、工作負載間的干擾和截止期限。

kube-controller-manager

控制平面的元件，執行控制器處理程序。

邏輯上，每個控制器都是一個獨立的處理程序，但為了降低複雜性，它們都被編譯成單一二進位檔案，並在單一處理程序中執行。

有許多不同類型的控制器。其中一些範例是

節點控制器：負責注意節點何時停機並做出回應。
Job 控制器：監看代表一次性任務的 Job 物件，然後建立 Pod 以執行這些任務直到完成。
EndpointSlice 控制器：填充 EndpointSlice 物件（以在服務和 Pod 之間提供連結）。
ServiceAccount 控制器：為新的命名空間建立預設的 ServiceAccount。

以上並非詳盡的清單。

cloud-controller-manager

Kubernetes 元件，嵌入了雲端特定的控制邏輯。雲端控制器管理器讓您可以將叢集連結到雲端供應商的 API，並將與該雲端平台互動的元件，與僅與叢集互動的元件分開。

cloud-controller-manager 僅執行特定於您的雲端供應商的控制器。如果您在自己的場所或自己電腦內的學習環境中執行 Kubernetes，則叢集沒有雲端控制器管理器。

與 kube-controller-manager 一樣，cloud-controller-manager 將幾個邏輯上獨立的控制迴圈組合成一個二進位檔案，您可以將其作為單一處理程序執行。您可以水平擴展（執行多個副本）以提高效能或幫助容忍故障。

以下控制器可能具有雲端供應商依賴性

節點控制器：用於檢查雲端供應商，以確定節點停止回應後是否已在雲端中刪除
路由控制器：用於在底層雲端基礎架構中設定路由
服務控制器：用於建立、更新和刪除雲端供應商負載平衡器

節點元件

節點元件在每個節點上執行，維護正在執行的 Pod 並提供 Kubernetes 執行階段環境。

kubelet

在叢集中每個節點上執行的代理程式。它確保容器正在 Pod 中執行。

kubelet 接收透過各種機制提供的一組 PodSpec，並確保這些 PodSpec 中描述的容器正在執行且健康。kubelet 不管理非 Kubernetes 建立的容器。

kube-proxy（選用）

kube-proxy 是一個網路代理，在叢集中每個節點上執行，實作 Kubernetes 服務概念的一部分。

kube-proxy 維護節點上的網路規則。這些網路規則允許從叢集內部或外部的網路連線與您的 Pod 進行網路通訊。

如果作業系統封包過濾層存在且可用，kube-proxy 會使用它。否則，kube-proxy 會自行轉發流量。

如果您使用網路外掛程式，該外掛程式本身實作服務的封包轉發，並提供與 kube-proxy 等效的行為，則您不需要在叢集中的節點上執行 kube-proxy。

容器執行階段

一個基礎元件，使 Kubernetes 能夠有效地執行容器。它負責管理 Kubernetes 環境中容器的執行和生命週期。

Kubernetes 支援容器執行階段，例如 containerd、CRI-O 和 Kubernetes CRI（容器執行階段介面）的任何其他實作。

附加元件

附加元件使用 Kubernetes 資源（DaemonSet、Deployment 等）來實作叢集功能。由於這些提供叢集層級的功能，因此附加元件的命名空間資源屬於 kube-system 命名空間。

以下描述了選定的附加元件；如需可用附加元件的擴充清單，請參閱附加元件。

DNS

雖然其他附加元件並非嚴格要求，但所有 Kubernetes 叢集都應具有叢集 DNS，因為許多範例都依賴它。

叢集 DNS 是一個 DNS 伺服器，除了您環境中的其他 DNS 伺服器外，它還為 Kubernetes 服務提供 DNS 記錄。

Kubernetes 啟動的容器會自動在其 DNS 搜尋中包含此 DNS 伺服器。

Web UI（儀表板）

儀表板是一個通用的、基於 Web 的 Kubernetes 叢集 UI。它允許使用者管理和疑難排解叢集中執行的應用程式，以及叢集本身。

容器資源監控

容器資源監控記錄關於容器的通用時間序列指標到中央資料庫中，並提供一個 UI 用於瀏覽該資料。

叢集層級記錄

叢集層級記錄機制負責將容器日誌儲存到具有搜尋/瀏覽介面的中央日誌儲存區。

網路外掛程式

網路外掛程式是實作容器網路介面 (CNI) 規範的軟體元件。它們負責為 Pod 分配 IP 位址，並使它們能夠在叢集內彼此通訊。

架構變化

雖然 Kubernetes 的核心元件保持一致，但它們的部署和管理方式可能會有所不同。了解這些變化對於設計和維護滿足特定操作需求的 Kubernetes 叢集至關重要。

控制平面部署選項

控制平面元件可以透過幾種方式部署

傳統部署: 控制平面元件直接在專用機器或 VM 上執行，通常作為 systemd 服務進行管理。
靜態 Pod: 控制平面元件部署為靜態 Pod，由特定節點上的 kubelet 管理。這是 kubeadm 等工具常用的方法。
自架託管: 控制平面作為 Pod 在 Kubernetes 叢集本身內執行，由 Deployment 和 StatefulSet 或其他 Kubernetes 基礎元件管理。
託管 Kubernetes 服務: 雲端供應商通常會抽象化控制平面，將其元件作為其服務產品的一部分進行管理。

工作負載放置考量

工作負載（包括控制平面元件）的放置可能會根據叢集大小、效能需求和操作政策而有所不同

在較小或開發叢集中，控制平面元件和使用者工作負載可能會在相同的節點上執行。
較大的生產叢集通常會將特定節點專用於控制平面元件，將它們與使用者工作負載分開。
有些組織在控制平面節點上執行重要的附加元件或監控工具。

叢集管理工具

kubeadm、kops 和 Kubespray 等工具提供了部署和管理叢集的不同方法，每種方法都有其自己的元件佈局和管理方式。

Kubernetes 架構的彈性允許組織根據特定需求調整其叢集，從而在操作複雜性、效能和管理負擔等因素之間取得平衡。

自訂和可擴展性

Kubernetes 架構允許進行顯著的自訂

可以部署自訂排程器以與預設 Kubernetes 排程器協同工作或完全取代它。
API 伺服器可以使用 CustomResourceDefinitions 和 API 聚合進行擴充。
雲端供應商可以使用 cloud-controller-manager 與 Kubernetes 深度整合。