叢集架構

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

工作節點託管構成應用程式工作負載的 Pod。控制平面管理叢集中的工作節點和 Pod。在生產環境中，控制平面通常跨多臺計算機執行，叢集通常執行多個節點，從而提供容錯和高可用性。

本文件概述了構成一個完整且可工作的 Kubernetes 叢集所需的各種元件。

關於此架構

圖 1 中的圖表展示了一個 Kubernetes 叢集的示例參考架構。元件的實際分佈可能因特定的叢集設定和要求而異。

在圖中，每個節點都執行 kube-proxy 元件。你需要在每個節點上部署一個網路代理元件，以確保 Service API 和相關行為在你的叢集網路中可用。然而，一些網路外掛提供了自己的第三方代理實現。當你使用這類網路外掛時，節點不需要執行 kube-proxy。

控制平面元件

控制平面的元件對叢集做出全域性決策（例如，排程），以及檢測和響應叢集事件（例如，當 Deployment 的 replicas 欄位不滿足時啟動一個新的 Pod）。

控制平面元件可以在叢集中的任何機器上執行。然而，為簡單起見，安裝指令碼通常在同一臺機器上啟動所有控制平面元件，並且不在該機器上執行使用者容器。有關跨多臺機器執行的控制平面設定示例，請參閱使用 kubeadm 建立高可用叢集。

kube-apiserver

API 伺服器是 Kubernetes 控制平面 的一個元件，它暴露 Kubernetes API。API 伺服器是 Kubernetes 控制平面的前端。

Kubernetes API 伺服器的主要實現是 kube-apiserver。kube-apiserver 設計為水平擴充套件——即，透過部署更多例項進行擴充套件。你可以執行多個 kube-apiserver 例項並在這些例項之間平衡流量。

etcd

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

如果你的 Kubernetes 叢集使用 etcd 作為其後端儲存，請確保你有一個數據備份計劃。

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

kube-scheduler

控制平面元件，用於監視新建立的但未分配 節點 的 Pod，併為它們選擇一個執行節點。

排程決策考慮的因素包括：單獨和集體 資源 要求、硬體/軟體/策略約束、親和性和反親和性規範、資料區域性性、工作負載間干擾以及截止日期。

kube-controller-manager

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

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

控制器有許多不同的型別。一些例子包括：

• 節點控制器：負責在節點下線時進行感知和響應。
• Job 控制器：監視表示一次性任務的 Job 物件，然後建立 Pod 來完成這些任務。
• EndpointSlice 控制器：填充 EndpointSlice 物件（提供 Service 和 Pod 之間的連結）。
• ServiceAccount 控制器：為新的名稱空間建立預設的 ServiceAccount。

以上並非詳盡列表。

雲控制器管理器

一個 Kubernetes 控制平面 元件，它嵌入了雲特定的控制邏輯。雲控制器管理器讓你將叢集連結到雲提供商的 API，並將與該雲平臺互動的元件與僅與叢集互動的元件分離。

雲控制器管理器只執行特定於你的雲提供商的控制器。如果你在自己的本地環境或自己的 PC 中的學習環境中執行 Kubernetes，則叢集沒有云控制器管理器。

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

以下控制器可能依賴於雲提供商

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

---

節點元件

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

kubelet

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

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

kube-proxy（可選）

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

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

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

如果你使用一個 網路外掛，它自行實現 Service 的包轉發，並提供與 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 叢集至關重要。

控制平面部署選項

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

傳統部署

控制平面元件直接在專用機器或虛擬機器上執行，通常作為 systemd 服務進行管理。

靜態 Pod

控制平面元件作為靜態 Pod 部署，由特定節點上的 kubelet 管理。這是 kubeadm 等工具使用的常見方法。

自託管

控制平面作為 Pod 在 Kubernetes 叢集本身內部執行，由 Deployment 和 StatefulSet 或其他 Kubernetes 原語管理。

託管 Kubernetes 服務

雲提供商通常抽象掉控制平面，將其元件作為其服務產品的一部分進行管理。

工作負載放置注意事項

工作負載（包括控制平面元件）的放置可能因叢集大小、效能要求和操作策略而異

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

叢集管理工具

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

Kubernetes 架構的靈活性允許組織根據特定需求定製其叢集，平衡操作複雜性、效能和管理開銷等因素。

定製和可擴充套件性

Kubernetes 架構允許進行顯著的定製

• 可以部署自定義排程器與預設的 Kubernetes 排程器協同工作，或者完全替代它。
• API 伺服器可以透過 CustomResourceDefinitions 和 API Aggregation 進行擴充套件。
• 雲提供商可以使用雲控制器管理器與 Kubernetes 深度整合。

Kubernetes 架構的靈活性允許組織根據特定需求定製其叢集，平衡操作複雜性、效能和管理開銷等因素。

下一步

瞭解更多資訊：

• 節點 以及它們與控制平面的通訊。
• Kubernetes 控制器。
• Kubernetes 的預設排程器 kube-scheduler。
• Etcd 的官方文件。
• Kubernetes 中的幾種容器執行時。
• 使用 cloud-controller-manager 與雲提供商整合。
• kubectl 命令。