本頁面說明建立、設定及操作叢集的最佳做法，這些叢集僅使用 VMware 適用的 Google Distributed Cloud 軟體建立，可容納接近 Kubernetes 擴充性限制的工作負載。
叢集名稱規則
針對每個 Google Cloud 專案：
- 在單一 Google Cloud 專案中，每個使用者叢集都必須有不重複的名稱，不得與任何管理員叢集重複。
擴充性限制
設計應用程式時，請考量下列限制：
如果未啟用進階叢集：
每個管理員叢集最多支援 100 個使用者叢集，包括高可用性 (HA) 和非 HA 使用者叢集，並使用套裝負載平衡模式 (MetalLB) 或手動負載平衡器。
每個使用者叢集最多支援：
500 個節點，使用隨附的負載平衡模式 (MetalLB)
15,000 個 Pod
500 個 LoadBalancer Service，使用套裝組合負載平衡模式 (MetalLB)。
每個節點最多可建立 110 個 Pod (每個 Pod 可包含 1 到 2 個容器)。包括執行外掛程式系統服務的 Pod。
如果已啟用進階叢集
每個管理員叢集最多支援 100 個使用者叢集，使用者叢集必須是高可用性 (HA) 叢集，並使用套裝組合負載平衡模式 (MetalLB) 或手動負載平衡器。
每個使用者叢集最多支援：
500 個節點，使用隨附的負載平衡模式 (MetalLB)。
15,000 個 Pod
500 個 LoadBalancer Service，使用套裝組合負載平衡模式 (MetalLB)。
每個節點最多可建立 110 個 Pod (每個 Pod 可包含 1 到 2 個容器)。包括執行外掛程式系統服務的 Pod。
節點總數 (包括管理員叢集控制層節點 + 所有使用者叢集控制層節點 + worker 節點) 不得超過 500 個。
瞭解限制
Google Distributed Cloud 是複雜的系統，整合層面廣泛，因此叢集擴充性涉及許多相互關聯的面向。舉例來說，Google Distributed Cloud 可透過節點、Pod 或 Service 的數量進行資源調度。即使在較小的叢集中，一次延展多個維度也可能造成問題。舉例來說，在 500 個節點的叢集中，為每個節點排定 110 個 Pod，可能會超出 Pod 數量、每個節點的 Pod 數量和節點數量的上限。
詳情請參閱「Kubernetes 擴充性門檻」。
擴充性限制也取決於叢集執行的 vSphere 設定和硬體。這些限制是在可能與您不同的環境中驗證。因此，如果基礎環境是限制因素，您可能無法重現確切的數字。
準備資源調度
準備擴充管理員叢集或使用者叢集時，請考量下列需求和限制。
CPU、記憶體和儲存空間需求
請參閱各個 VM 的 CPU、RAM 和儲存空間需求。
磁碟和網路 I/O 需求
資料密集的工作負載和特定控制層元件，容易受到磁碟和網路 I/O 延遲的影響。舉例來說，在具有數十個節點和數千個 Pod 的叢集中，etcd 的效能和穩定性通常需要 500 個依序 IOPS (例如一般的本機 SSD 或高效能虛擬化區塊裝置)。
節點 IP 位址
每個節點都需要一個 DHCP 或靜態指派的 IP 位址。
舉例來說，如果設定包含一個非高可用性使用者叢集 (50 個節點) 和一個高可用性使用者叢集 (250 個節點)，則需要 307 個 IP 位址。
下表列出 IP 位址的細目：
| 節點類型 | IP 位址數量 |
|---|---|
| 管理員叢集控制層 VM | 3 |
| 使用者叢集 1 (非高可用性) 控制層 VM | 1 |
| 使用者叢集 1 worker 節點 VM | 50 |
| 使用者叢集 2 (HA) 控制層 VM | 3 |
| 使用者叢集 2 worker 節點 VM | 250 |
| 總計 | 307 |
在管理員叢集中執行多個使用者叢集
如要準備在管理員叢集中執行多個使用者叢集，請在建立管理員叢集時執行下列步驟。
管理員叢集中的 Pod CIDR 區塊
Pod CIDR 區塊是管理員叢集中所有 Pod 的 CIDR 區塊。這項設定是透過 admin-cluster.yaml 中的 network.podCIDR 欄位進行。
系統會從這個範圍中，為每個節點指派較小的 /24 區塊。如果所有使用者叢集都已啟用 Controlplane V2，則管理員叢集只有三個節點，且有許多可用的 Pod IP 位址。不過，每次建立使用 kubeception 而非 Controlplane V2 的使用者叢集時，管理員叢集就會新增一或三個節點：
每個高可用性 (HA) kubeception 使用者叢集都會在管理員叢集中新增三個節點。
每個非高可用性 kubeception 使用者叢集都會在管理員叢集中新增一個節點。
如果您需要 N 節點管理員叢集，請務必確保 Pod CIDR 區塊夠大，足以支援 N 個 /24 區塊。
下表說明不同 Pod CIDR 區塊大小支援的節點數量上限：
| Pod CIDR 區塊大小 | 支援的節點數量上限 |
|---|---|
| /18 | 64 |
| /17 | 128 |
| /16 | 256 |
| /15 | 512 |
管理員叢集的預設 Pod CIDR 區塊為 192.168.0.0/16，支援 256 個節點。
在具有 100 個高可用性 kubeception 使用者叢集的管理員叢集中，有 3 個管理員叢集控制層節點和 300 個使用者叢集控制層節點。節點總數為 303 (超過 256)。因此，您必須將 Pod CIDR 區塊更新為 /15，最多可支援 100 個高可用性 kubeception 使用者叢集。
如要設定 Pod CIDR 區塊，請在管理員叢集設定檔中設定 network.podCIDR 欄位。
管理員叢集中的 Service CIDR 區塊
Service CIDR 區塊是管理員叢集中所有 Service 的 CIDR 區塊。這項設定是透過 admin-cluster.yaml 中的 network.serviceCIDR 欄位進行。
下表說明不同 Service CIDR 區塊大小支援的 Service 數量上限：
| Service CIDR 區塊大小 | 支援的服務數量上限 |
|---|---|
| /24 | 256 |
| /23 | 512 |
| /22 | 1,024 |
預設值為 10.96.232.0/24，支援 256 項服務。
每個 kubeception 使用者叢集會使用 6 個 Service，管理員叢集控制層則會使用 14 個 Service。因此，如要執行 100 個 kubeception 使用者叢集，您必須變更管理員叢集中的 Service CIDR 區塊，改用 /22 範圍。
kubeception 使用者叢集的 Cloud Logging 和 Cloud Monitoring
Cloud Logging 和 Cloud Monitoring 可協助您追蹤資源。
部署在管理員叢集中的記錄和監控元件，其 CPU 和記憶體用量會根據 kubeception 使用者叢集的數量調整。
下表說明執行大量 kubeception 使用者叢集所需的管理員叢集節點 CPU 和記憶體數量：
| kubeception 使用者叢集數量 | 管理員叢集節點 CPU | 管理員叢集節點記憶體 |
|---|---|---|
| 0 到 10 | 4 個 CPU | 16 GB |
| 11 到 20 | 4 個 CPU | 32 GB |
| 20 至 100 | 4 個 CPU | 90GB |
舉例來說，如果有 2 個管理員叢集節點，且每個節點有 4 個 CPU 和 16 GB 記憶體，則可執行 0 到 10 個 kubeception 使用者叢集。如要建立超過 20 個 kubeception 使用者叢集，必須先將管理員叢集節點記憶體從 16 GB 調整為 90 GB。
啟用進階叢集時的管理員叢集節點
部署在管理員叢集中的生命週期元件，其 CPU 和記憶體用量會根據所有節點的總數調整 (節點總數包括管理員叢集控制層節點 + 所有使用者叢集控制層節點 + worker 節點)
下表說明管理員叢集節點 CPU 和記憶體數量，必須達到多少才能執行大量受管理節點：
| 節點總數 | 管理員叢集節點 CPU | 管理員叢集節點記憶體 |
|---|---|---|
| 0 至 20 | 4 個 CPU | 16 GB |
| 21 至 100 | 8 個 CPU | 16 GB |
| 101 至 500 人 | 16 個 CPU | 32 GB |
舉例來說，假設有 3 個管理員叢集節點，每個節點有 4 個 CPU 和 16 GB 記憶體，您可以使用 14 個 worker 節點執行一個高可用性使用者叢集。如要建立超過 20 個進階使用者叢集，且每個使用者叢集有超過 10 個節點，您必須先將管理員叢集節點記憶體從 16 GB 調整為 32 GB。
GKE Hub
根據預設，每個機群最多可註冊 250 個具備全域成員資格的叢集。如要在 GKE Hub 註冊更多叢集，請前往 Google Cloud 控制台提交要求，提高配額：
如要進一步瞭解依據成員資格設定的叢集配額，請參閱「分配配額」。
在使用者叢集中執行多個節點和 Pod
準備在使用者叢集中執行多個節點和 Pod 時，請在建立使用者叢集時執行下列步驟。
使用者叢集中的 Pod CIDR 區塊
Pod CIDR 區塊是使用者叢集中所有 Pod 的 CIDR 區塊。這項設定是透過 user-cluster.yaml 中的 network.podCIDR 欄位進行。
系統會從這個範圍中，為每個節點指派較小的 /24 區塊。如果您需要 N 個節點叢集，請務必確保這個區塊夠大，足以支援 N 個 /24 區塊。
下表說明不同 Pod CIDR 區塊大小支援的節點數量上限：
| Pod CIDR 區塊大小 | 支援的節點數量上限 |
|---|---|
| /18 | 64 |
| /17 | 128 |
| /16 | 256 |
| /15 | 512 |
預設的 Pod CIDR 區塊為 192.168.0.0/16，支援 256 個節點。舉例來說，如要建立含有 500 個節點的叢集，您必須變更使用者叢集中的 Pod CIDR 區塊，改用 /15 範圍。
使用者叢集中的 Service CIDR 區塊
Service CIDR 區塊是使用者叢集中所有 Service 的 CIDR 區塊。這項設定是透過 user-cluster.yaml 中的 network.serviceCIDR 欄位進行。
下表說明不同 Service CIDR 區塊大小支援的 Service 數量上限：
| Service CIDR 區塊大小 | 支援的服務數量上限 |
|---|---|
| /21 | 2,048 |
| /20 | 4,096 |
| /19 | 8,192 |
| /18 | 16,384 |
使用者叢集控制層節點
使用者叢集控制層元件的記憶體用量，會依據使用者叢集中的節點數量調整。
下表列出使用者叢集控制層節點所需的 CPU 和記憶體，具體取決於使用者叢集的大小：
| 使用者叢集節點數量 | 控制層節點 CPU | 控制層節點記憶體大小 |
|---|---|---|
| 0 至 20 | 3 個 CPU | 5 GB |
| 21 至 75 | 3 個 CPU | 6GB |
| 76 至 250 | 4 個 CPU | 8 GB |
| 251 至 500 | 4 個 CPU | 16 GB |
舉例來說，如要在使用者叢集中建立超過 250 個節點，您必須使用記憶體至少 16 GB 的使用者叢集控制層節點。
您可以透過 user-cluster.yaml 中的 masterNode 欄位，變更使用者叢集控制層節點規格。
Dataplane v2
如果是使用 Dataplane V2 的 500 節點使用者叢集，建議為使用者叢集控制層節點配置 120 GB 記憶體和 32 個 CPU 核心。
Cloud Logging 和 Cloud Monitoring
Cloud Logging 和 Cloud Monitoring 可協助您追蹤資源。
在使用者叢集中部署的叢集內代理程式，其 CPU 和記憶體用量會根據使用者叢集中的節點和 Pod 數量調整。
Cloud Logging 和 Monitoring 元件 (例如 prometheus-server 和 stackdriver-prometheus-sidecar) 的 CPU 和記憶體資源用量，會因節點和 Pod 數量而異。在擴充叢集之前，請根據這些元件的預估平均用量，設定資源要求和限制。下表列出各元件的平均用量預估值：
| 節點數量 | 容器名稱 | 預估 CPU 使用率 | 預估記憶體用量 | ||
|---|---|---|---|---|---|
| 0 個 Pod/節點 | 30 個 Pod/節點 | 0 個 Pod/節點 | 30 個 Pod/節點 | ||
| 3 到 50 | prometheus-server | 100 公尺 | 390 公尺 | 6.5 億 | 1.3G |
| stackdriver-prometheus-sidecar | 100 公尺 | 3.4 億 | 1.5G | 1.6G | |
| 51 到 100 | prometheus-server | 1.6 億 | 500 公尺 | 1.8G | 5.5G |
| stackdriver-prometheus-sidecar | 200 公尺 | 500 公尺 | 1.9G | 5.7G | |
| 101 至 250 | prometheus-server | 400 公尺 | 2500 公尺 | 6.5G | 16G |
| stackdriver-prometheus-sidecar | 400 公尺 | 1300 公尺 | 7.5G | 12G | |
| 250 至 500 | prometheus-server | 1200 公尺 | 2600 公尺 | 22G | 25G |
| stackdriver-prometheus-sidecar | 400 公尺 | 2250 公尺 | 65G | 78G | |
請確認節點大小足以排定 Cloud Logging 和 Cloud Monitoring 元件。其中一種做法是先建立小型叢集，根據上表編輯 Cloud Logging 和 Cloud Monitoring 元件資源，建立節點集區來容納元件，然後逐步將叢集擴充至較大的規模。
您可以選擇維護一個節點集區，其大小足以容納監控和記錄元件，以防止其他 Pod 排定至該節點集區。如要這麼做，您必須在節點集區中新增下列污點：
taints:
- effect: NoSchedule
key: node-role.gke.io/observability這樣一來，其他元件就不會排定在節點集區中，使用者工作負載也不會因監控元件的資源消耗而遭到淘汰。
負載平衡器
本節討論的 Service 是指 LoadBalancer 類型的 Kubernetes Service。
叢集中的節點數量，以及可在負載平衡器上設定的 Service 數量，都有上限。
如果是套裝負載平衡 (Seesaw)，健康狀態檢查數量也有限制。健康狀態檢查的數量取決於節點數量和流量本機服務數量。流量本機 Service 的 externalTrafficPolicy 設為 Local。
下表說明套裝組合負載平衡 (Seesaw) 和整合式負載平衡 (F5) 的 Service、節點和健康狀態檢查數量上限：
| 隨附的負載平衡 (Seesaw) | 整合式負載平衡 (F5) | |
|---|---|---|
| Max Services | 500 | 250 |
| 最多節點數 | 500 | 250 |
| 健康狀態檢查次數上限 | N + (L * N) <= 10K，其中 N 是節點數量，L 是流量本機服務數量 1 | 不適用2 |
1 舉例來說，假設您有 100 個節點和 99 個流量本機 Service。健康狀態檢查數量為 100 + (99 * 100) = 10,000，在 1 萬的限制範圍內。
2 詳情請洽詢 F5。這個數字會受到 F5 硬體型號、虛擬個體 CPU/記憶體和授權等因素影響。
自動調度資源系統元件
Google Distributed Cloud 會根據節點數量，自動調整使用者叢集中的系統元件，您不需要變更設定。您可以運用本節資訊規劃資源。
Google Distributed Cloud 會使用 addon-resizer，自動調整下列系統元件的 CPU 和記憶體要求/限制，執行垂直擴充：
kube-state-metrics 是在叢集 worker 節點上執行的 Deployment，會監聽 Kubernetes API 伺服器，並產生有關物件狀態的指標。CPU 和記憶體要求與限制會根據節點數量調整。
下表說明系統根據叢集中的節點數量，設定的資源要求/限制：
節點數量 大約1 CPU 要求/限制 (milli) 大約1記憶體要求/限制 (Mi) 3 到 5 105 110 6 到 500 100 + num_nodes 100 + (2 * num_nodes) 1：有 +-5% 的誤差範圍，可減少資源調度期間元件重新啟動的次數。
舉例來說，在具有 50 個節點的叢集中，CPU 要求/限制會設為 150m/150m，記憶體要求/限制則會設為 200Mi/200Mi。在具有 250 個節點的叢集中，CPU 要求/限制設為 350m/350m，記憶體要求/限制則設為 600Mi。
metrics-server 是在叢集 worker 節點上執行的 Deployment，由 Kubernetes 內建的自動調度資源管道使用。CPU 和記憶體要求與限制會根據節點數量調整。
Google Distributed Cloud 會自動在管理員叢集和使用者叢集中執行水平擴充，方法是擴充下列系統元件的副本數量：
core-dns 是用於服務探索的 DNS 解決方案。會以 Deployment 的形式，在使用者叢集 worker 節點上執行。Google Distributed Cloud 會根據叢集中的節點和 CPU 核心數量，自動調整副本數量。每新增/刪除 16 個節點或 256 個核心，就會增加/減少 1 個副本。如果叢集有
N個節點和C個核心，則預期會有max(N/16, C/256)個副本。calico-typha 是支援 Pod 網路的元件。會以 Deployment 的形式，在使用者叢集 worker 節點上執行。Google Distributed Cloud 會根據叢集中的節點數量，自動調整 calico-typha 副本數量：
節點數量 (N) calico-typha 副本數量 N = 1 1 1 < N < 200 2 N >= 200 3 部以上 Istio ingress-gateway 是支援叢集輸入的元件，會以 Deployment 的形式在使用者叢集 worker 節點上執行。Google Distributed Cloud 會根據 ingress-gateway 處理的流量，使用水平 Pod 自動配置器，依據 CPU 使用率調度副本數量，最少 2 個副本，最多 5 個副本。
konnectivity 網路 Proxy (KNP) 提供 TCP 層級的 Proxy，用於從使用者叢集控制層節點輸出。它會透過通道傳輸使用者 kube-apiserver 傳出流量，目的地為使用者叢集節點。Konnectivity 代理程式會以 Deployment 的形式，在使用者叢集 worker 節點上執行。Google Distributed Cloud 會根據叢集中的節點數量，自動調整 konnectivity 代理副本數量。
節點數量 (N) Konnectivity 代理程式副本數量 1 <= N <= 6 N 6 < N < 10 6 10 <= N < 100 8 N >= 100 12 個以上
最佳做法
本節說明資源調度最佳做法。
分階段調度叢集資源
建立 Kubernetes 節點時，系統會將節點 OS 映像檔範本複製到新的磁碟檔案，這是 I/O 密集型 vSphere 作業。複製作業和工作負載 I/O 作業之間沒有 I/O 隔離。如果同時建立太多節點，複製作業會需要很長時間才能完成，且可能會影響叢集和現有工作負載的效能和穩定性。
請務必根據 vSphere 資源，分階段調度叢集資源。舉例來說，如要將叢集大小從 3 個節點調整為 500 個節點，建議您分階段調整，例如從 150 個節點調整為 350 個節點，再調整為 500 個節點，這有助於減輕 vSphere 基礎架構的負載。
最佳化 etcd 磁碟 I/O 效能
etcd 是鍵/值儲存庫，用來做為 Kubernetes 的後端儲存庫，存放所有叢集資料。其效能和穩定性對叢集的健康狀態至關重要，且容易受到磁碟和網路 I/O 延遲的影響。
請按照下列建議，最佳化控制層 VM 所用 vSphere 資料存放區的 I/O 效能：
- 請遵循 etcd 硬體需求。
- 使用 SSD 或全快閃儲存空間。
如果延遲時間達數百毫秒，表示磁碟或網路 I/O 發生瓶頸，可能導致叢集健康狀態不佳。監控下列 etcd I/O 延遲指標並設定快訊門檻：
etcd_disk_backend_commit_duration_secondsetcd_disk_wal_fsync_duration_seconds
最佳化節點開機磁碟 I/O 效能
Pod 會使用暫時儲存空間進行內部作業，例如儲存暫存檔案。容器的可寫入層、記錄目錄和 emptyDir 磁碟區會耗用暫時儲存空間。臨時儲存空間來自節點的檔案系統，由節點的開機磁碟支援。
由於 Kubernetes 節點上沒有儲存空間 I/O 隔離，因此在臨時儲存空間上消耗極高 I/O 的應用程式，可能會耗盡 Kubelet 和 Docker Daemon 等系統元件的資源，導致節點不穩定。
確保佈建開機磁碟的資料儲存庫 I/O 效能特性，能為應用程式使用臨時儲存空間和記錄流量提供適當的效能。
監控實體資源爭用情形
請留意 vCPU 與 pCPU 的比率和記憶體超額承諾。如果比率不理想，或實體主機發生記憶體爭用情形，VM 效能可能會降低。您應監控主機層級的實體資源使用率，並分配足夠的資源來執行大型叢集。