這是本節的多頁可打印視圖。點擊此處打印.

最佳實務

1: 大型叢集的考量事項
2: 跨區域執行

1 - 大型叢集的考量事項

叢集是由一組執行 Kubernetes 代理程式的節點（實體機器或虛擬機器）所組成，並由控制平面進行管理。 Kubernetes v1.35 支援最多 5,000 個節點的叢集。更具體來說，Kubernetes 的設計可支援符合以下所有準則的配置：

每個節點不超過 110 個 Pod
不超過 5,000 個節點
Pod 總數不超過 150,000
容器總數不超過 300,000

您可以透過新增或移除節點來調整叢集規模。具體作法取決於叢集的部署方式。

雲端供應商資源配額

為了避免碰到雲端供應商的配額問題，在建立多個節點的叢集時，建議考量：

申請提高雲端資源的配額，例如：
- 運算執行個體
- CPU
- 儲存卷
- 使用中的 IP 位址
- 封包過濾規則
- 負載平衡器的數量
- 子網路
- 日誌串流
控制叢集的擴展流程，分批啟動新節點，並在各批之間加入間隔，因為部分雲端供應商會限制新執行個體的建立速率。

控制平面組件

對於大型叢集，您需要一個具備足夠運算及其他資源的控制平面。

通常您會在每個故障區執行一到兩個控制平面執行個體，並優先對這些執行個體進行垂直擴展；直到垂直擴展達到邊際效益遞減的臨界點後，再進行水平擴展。

您應該在每個故障區執行至少一個執行個體來提供容錯能力。 Kubernetes 節點不會自動將流量導向位於相同故障區的控制平面端點；然而，您的雲端供應商可能有其獨有的機制來做到這一點。

例如，使用託管的負載平衡器時，您可以設定此負載平衡器將源於故障區 A 的 kubelet 與 Pod 流量僅導向同樣位於故障區 A 的控制平面主機。如果故障區 A 內的單一控制平面主機或端點離線，這意味著 A 區節點的所有控制平面流量現在都將改為跨區傳輸。在每個區域中執行多個控制平面主機可以降低發生這種情況的可能性。

etcd 儲存

為了提升大型叢集的效能，您可以將 Event 物件儲存於一個獨立且專屬的 etcd 執行個體中。

您可以使用自訂工具，在建立叢集時：

啟動並設定額外的 etcd 執行個體
設定 API 伺服器將 Event 儲存在該執行個體中

請參閱針對 Kubernetes 維運 etcd 叢集與使用 kubeadm 架設高可用性 etcd 叢集，以了解為大型叢集設定與管理 etcd 的詳細資訊。

附加元件資源

Kubernetes 資源限制有助於將記憶體洩漏，以及 Pod 與容器對其他組件的影響降至最低。這些資源限制同樣適用於附加元件的資源，也適用於應用程式工作負載。

例如，您可以為日誌組件設定 CPU 與記憶體限制：

  ...
  containers:
  - name: fluentd-cloud-logging
    image: fluent/fluentd-kubernetes-daemonset:v1
    resources:
      limits:
        cpu: 100m
        memory: 200Mi

附加元件的預設限制，通常是基於在小型或中型 Kubernetes 叢集上執行各個附加元件的經驗所蒐集的資料。當在大型叢集上執行時，某些資源的使用量可能會超過預設限制。若在部署大型叢集時未調整這些數值，附加元件可能會因為不斷觸及記憶體限制而反覆被終止；或者，附加元件雖能維持執行，但會受 CPU 時間切片限制影響而效能低落。

為了避免遇到叢集附加元件的資源問題，在建立包含多個節點的叢集時，建議考量以下事項：

部分附加元件採垂直擴展 — 整個叢集或每個故障區僅執行一個附加元件副本。對於此類附加元件，當您擴展叢集規模時，請增加其資源請求與限制。
許多附加元件採水平擴展 — 透過增加 Pod 數量來提升容量；但在超大型叢集中，您可能仍需稍微提高 CPU 或記憶體限制。 Vertical Pod Autoscaler 可以以recommender 模式執行，以提供資源請求與限制的建議值。
部分附加元件以每個節點一個副本的方式執行，並由 DaemonSet 進行控制：例如節點級別的日誌聚合器。與水平擴展的附加元件類似，您可能也需要稍微調高 CPU 或記憶體限制。

優先處理叢集關鍵組件

為了確保叢集的必要組件（例如 CoreDNS、metrics-server 與其他關鍵附加元件）優先於其他工作負載進行排程，且不會被較低優先權的 Pod 搶佔，請使用系統的 PriorityClass 來設定這些組件的優先順序，例如 system-cluster-critical 或 system-node-critical。

接下來

VerticalPodAutoscaler 是一個您可以部署到叢集中的自訂資源，用來協助您管理 Pod 的資源請求與限制。請參閱 Vertical Pod Autoscaler 以了解更多資訊，並學習如何使用它來調整叢集組件的規模，包括叢集關鍵的附加元件。

請參閱節點自動擴展

addon resizer 可協助您隨著叢集規模的變化，自動調整附加元件的資源配置。

2 - 跨區域執行

本頁面說明如何跨多個區域執行 Kubernetes。

背景

Kubernetes 的設計使單一叢集能夠跨多個故障區（Failure Zone）執行；這些故障區通常隸屬於一個稱為**「地區」（Region）的邏輯分組。主要的雲端供應商將地區定義為一組故障區，亦稱為可用區（Availability Zone）**，並提供一致的功能：在同一個地區內，各故障區提供相同的 API 與服務。

典型的雲端架構旨在將單一故障區故障對其他故障區服務的影響降至最低。

控制平面行為

所有控制平面組件都支援以可互換資源池的方式執行，並為各個組件建立多個副本

當您部署叢集控制平面時，需將控制平面組件的副本分散部署於多個故障區。若高可用性是重要考量，應選擇至少三個故障區，並為各個控制平面組件（API 伺服器、排程器、etcd、叢集控制器管理器）建立多個副本，分散部署於這些故障區中。若有使用雲端控制器管理器，也應將它複製到您所選擇的所有故障區中。

說明：

Kubernetes 不會為 API 伺服器端點提供跨故障區的系統韌性。您可以使用多種技術來改善叢集 API 伺服器的可用性，包括 DNS 輪詢、SRV 記錄，或是具備健康檢查功能的第三方負載平衡方案。

節點行為

Kubernetes 會自動將工作負載資源（例如 Deployment 或 StatefulSet）的 Pod 分散部署於叢集中的不同節點。這種分散部署有助於降低故障造成的影響。

當節點啟動時，每個節點上的 kubelet 會自動在 Kubernetes API 中代表此特定節點的 Node 物件加上標籤。這些標籤可以包含區域資訊。

如果您的叢集跨越多個故障區或地區，您可以結合使用節點標籤與 Pod 拓撲散佈限制，來控制 Pod 在叢集中的各個故障域（地區、故障區，甚至特定節點）之間的分佈方式。這些提示可讓排程器將 Pod 排程到更有利於可用性的位置，從而降低相關故障影響整個工作負載的風險。

例如，您可以設定一項限制：確保在可行的情況下，一個 StatefulSet 的 3 個副本分別執行於不同的故障區您可以透過宣告式的方式來定義此限制，不需要為每個工作負載明確指定使用哪些可用區。

跨區域分散節點

Kubernetes 核心本身不會為您建立節點；您需要自行建立，或使用像是 Cluster API 的工具來代為管理節點。

透過使用 Cluster API 等工具，您可以定義一組機器，將其分散在多個故障域中作為叢集的工作節點執行，並定義規則，在發生整個區域的服務中斷時自動修復叢集。

手動為 Pod 指定區域

您可以套用節點選擇器限制到您建立的 Pod，以及 Deployment、StatefulSet 或 Job 等工作負載資源中的 Pod 模板。

區域的儲存存取

當建立持久卷時，Kubernetes 會自動為連結至特定故障區的 PersistentVolume 加上區域標籤。接著排程器會透過 NoVolumeZoneConflict 預選規則，確保使用該 PersistentVolume 的 Pod 只會被排程到與該卷相同的故障區。

請注意到區域標籤的新增方式可能取決於您使用的雲端供應商與儲存佈建器。請務必參考適用於您環境的特定文件，確保配置正確。

您可以為 PersistentVolumeClaims 指定一個StorageClass，用來指定該類別中的儲存空間可以使用的故障域（區域）。要了解配置能夠感知到故障域或區域的 StorageClass，請參閱允許的拓撲。

網路

Kubernetes 本身並不包含故障區感知的網路功能。您可以使用網路外掛來配置叢集網路，而選用的網路解決方案可能包含與特定故障區相關的設定。例如，如果您的雲端供應商支援 type=LoadBalancer 的 Service，負載平衡器可能只會將流量傳送至與處理此連線的負載平衡器位於相同區域的 Pod。請查看您的雲端供應商文件以瞭解詳情。

對於自訂或本地端部署，類似的考量同樣適用。 Service 與 Ingress 的行為，包含對不同故障區的處理方式，會根據您叢集的實際部署方式而有所不同。

故障復原

當您架設叢集時，還需要考慮：若某個地區內的所有故障區同時離線，您的架構是否能恢復服務，以及應如何恢復。例如，是否仰賴某個故障區中至少有一個節點能夠執行 Pod？請確保任何叢集關鍵的修復工作，都不依賴叢集中至少有一個健康節點。例如：如果所有節點皆處於不健康狀態，您可能需要執行一個帶有特殊容許的修復 Job，使修復能順利完成，並讓至少一個節點恢復運作。

Kubernetes 並未提供此問題的解法；但在規劃時仍需納入考量。

接下來

若想了解排程器如何在叢集中依照設定的限制來排程 Pod，請參閱排程與驅逐。