本頁面說明如何建立、設定及運作使用 Google Distributed Cloud (僅限軟體) for VMware 建立的叢集，以因應接近 Kubernetes 擴充性限制的工作負載，並提供相關最佳做法。
叢集名稱規則
針對每個 Google Cloud 專案：
- 在單一 Google Cloud 專案的所有管理員叢集中，每個使用者叢集的名稱均不得重複。
擴充性限制
設計應用程式時，請考量下列限制：
如果未啟用進階叢集：
每個管理員叢集最多可支援 100 個使用者叢集，包括高可用性 (HA) 和非 HA 使用者叢集，並使用隨附的負載平衡模式 (MetalLB) 或手動負載平衡器。
每個使用者叢集最多支援：
使用套裝組合式負載平衡模式 (MetalLB) 時，最多可有 500 個節點
15,000 個 Pod
使用套裝組合式負載平衡模式 (MetalLB) 的 500 項 LoadBalancer 服務。
每個節點最多可以建立 110 個 Pod (每個 Pod 最多可包含 1 到 2 個容器)。包括執行外掛程式系統服務的 Pod。
如果啟用進階叢集
每個管理叢集最多可支援 100 個使用者叢集，使用者叢集必須是高可用性 (HA) 叢集，使用隨附的負載平衡模式 (MetalLB) 或手動負載平衡器。
每個使用者叢集最多支援：
500 個節點，使用套裝組合負載平衡模式 (MetalLB)。
15,000 個 Pod
使用套裝組合式負載平衡模式 (MetalLB) 的 500 項 LoadBalancer 服務。
每個節點最多可以建立 110 個 Pod (每個 Pod 最多可包含 1 到 2 個容器)。包括執行外掛程式系統服務的 Pod。
節點總數 (包括管理員叢集控制層節點 + 所有使用者叢集控制層節點 + 工作站節點) 不得超過 500 個節點。
瞭解限制
Google Distributed Cloud 是複雜的系統，整合介面廣泛，因此叢集可擴充性涉及許多相互關聯的層面。舉例來說，Google Distributed Cloud 可透過節點、Pod 或服務數量進行擴充。即使是在較小的叢集中，一次延展多個維度也可能會導致發生問題。舉例來說，在 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 工作站節點 VM | 50 |
| 使用者叢集 2 (高可用性) 控制層 VM | 3 |
| 使用者叢集 2 工作站節點 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 個 HA kubeception 使用者叢集的管理員叢集中，有 3 個管理員叢集控制層節點和 300 個使用者叢集控制層節點。節點總數為 303 個 (超過 256 個)。因此，您必須將 Pod CIDR 區塊更新為 /15，才能支援最多 100 個 HA kubeception 使用者叢集。
如要設定 Pod CIDR 區塊，請在管理員叢集設定檔中設定 network.podCIDR 欄位。
管理叢集中的服務 CIDR 區塊
Service CIDR 區塊是管理員叢集中所有服務的 CIDR 區塊。
這是透過 admin-cluster.yaml 中的 network.serviceCIDR 欄位設定。
下表說明不同服務 CIDR 區塊大小支援的服務數量上限：
| 服務 CIDR 區塊大小 | 支援的服務數量上限 |
|---|---|
| /24 | 256 |
| /23 | 512 |
| /22 | 1,024 |
預設值為 10.96.232.0/24，最多可支援 256 個服務。
每個 kubeception 使用者叢集會使用 6 個服務，管理員叢集控制層則會使用 14 個服務。因此，如要執行 100 個 kubeception 使用者叢集，您必須變更管理員叢集中的服務 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 和記憶體用量，會根據所有節點的總數 (節點總數包括管理員叢集控制層節點 + 所有使用者叢集控制層節點 + 工作站節點) 調整。
下表說明執行大量節點時，管理叢集節點所需的 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 個工作站節點的高可用性使用者叢集。如要建立超過 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 範圍。
使用者叢集中的服務 CIDR 區塊
Service CIDR 區塊是使用者叢集中所有服務的 CIDR 區塊。這項功能是透過 user-cluster.yaml 中的 network.serviceCIDR 欄位設定。
下表說明不同服務 CIDR 區塊大小支援的服務數量上限：
| 服務 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 | 100m | 390 公尺 | 6.5 億 | 1.3G |
| stackdriver-prometheus-sidecar | 100m | 3.4 億 | 1.5G | 1.6G | |
| 51 到 100 | prometheus-server | 160 公尺 | 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這樣一來，其他元件就不會排定在節點集區上執行，使用者工作負載也不會因監控元件耗用資源而遭到驅逐。
負載平衡器
本節討論的服務是指類型為 LoadBalancer 的 Kubernetes 服務。
叢集中的節點數量有限制，負載平衡器上可設定的服務數量也有限制。
如果是套裝組合負載平衡 (Seesaw)，健康狀態檢查次數也有上限。健康狀態檢查次數取決於節點數和流量本機服務數。流量本機服務是指 externalTrafficPolicy 設為 Local 的服務。
下表說明整合式負載平衡 (F5) 和套裝負載平衡 (Seesaw) 的服務、節點和健康狀態檢查數量上限：
| 套裝組合負載平衡 (Seesaw) | 整合式負載平衡 (F5) | |
|---|---|---|
| Max 服務 | 500 | 250 2 |
| 最多節點數 | 500 | 250 2 |
| 健康狀態檢查次數上限 | N + (L * N) <= 10K，其中 N 是節點數量，L 是流量本機服務數量 1 | 不適用 2 |
1 舉例來說，假設您有 100 個節點和 99 個流量本機服務，健康狀態檢查次數為 100 + (99 * 100) = 10,000，符合 1 萬次的上限。
2 如需詳細資訊，請洽詢 F5。這個數字會受到多種因素影響，例如 F5 硬體型號、虛擬執行個體 CPU/記憶體和授權。
自動調度系統元件
Google Distributed Cloud 會根據節點數量，自動調整使用者叢集中的系統元件，您不必變更任何設定。您可以使用本節資訊規劃資源。
Google Distributed Cloud 會使用 addon-resizer，自動調度下列系統元件的 CPU 和記憶體要求/限制，執行垂直調度：
kube-state-metrics 是在叢集工作站節點上執行的 Deployment，會監聽 Kubernetes API 伺服器，並產生物件狀態的指標。CPU 和記憶體要求與限制會根據節點數量調整。
下表說明系統根據叢集中的節點數量設定的資源要求/限制：
節點數量 約略1 CPU 要求/限制 (毫) 約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 是在叢集工作節點上執行的部署作業，Kubernetes 內建的自動調度資源管道會使用這項作業。CPU 和記憶體要求與限制會根據節點數量調整。
Google Distributed Cloud 會自動在管理員叢集和使用者叢集中執行水平擴充，方法是擴充下列系統元件的副本數量：
core-dns 是用於服務探索的 DNS 解決方案。這項服務會在使用者叢集工作站節點上以 Deployment 形式執行。Google Distributed Cloud 會根據叢集中的節點和 CPU 核心數量，自動調整副本數量。每增加/刪除 16 個節點或 256 個核心，副本就會增加/減少 1 個。如果您有
N個節點和C個核心的叢集，則預期會有max(N/16, C/256)個副本。calico-typha 是支援 Pod 網路的元件，這項服務會在使用者叢集工作站節點上以 Deployment 形式執行。Google Distributed Cloud 會根據叢集中的節點數量，自動調整 calico-typha 副本數量：
節點數量 (N) calico-typha 副本數量 N = 1 1 1 < N < 200 2 N >= 200 3 個以上 Istio 輸入閘道是支援叢集輸入的元件，會在使用者叢集工作站節點上以 Deployment 形式執行。視 Ingress 閘道處理的流量而定，Google Distributed Cloud 會使用水平 Pod 自動調度器，根據 CPU 使用率調度備用資源數量，最少 2 個，最多 5 個。
konnectivity 網路 Proxy (KNP) 可為使用者叢集控制層節點的輸出流量提供 TCP 層級的 Proxy。這會將使用者 kube-apiserver 外送流量導向使用者叢集節點。Konnectivity 代理程式會在使用者叢集工作節點上以 Deployment 形式執行。Google Distributed Cloud 會根據叢集中的節點數量，自動調整連線代理程式副本數量。
節點數量 (N) 連線代理程式副本數量 1 <= N <= 6 否 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 Datastore 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 效能下降。您應監控主機層級的實體資源使用率，並分配足夠的資源來執行大型叢集。