僅限裸機的 Distributed Cloud 軟體會對 Google Cloud 專案、叢集和節點套用配額和限制。這些門檻定義了支援的機群註冊、叢集容量和節點資源限制，可協助您規劃及擴充裸機部署作業。
限制
以下各節將概略說明叢集的一些基本限制。設計要在 Google Distributed Cloud 執行的應用程式時，請考量這些限制。
每個管理員叢集的使用者叢集數量上限
管理員叢集會管理使用者叢集及其相關聯節點的生命週期。管理員叢集會控管重要的使用者叢集作業，例如建立叢集、重設叢集或節點、升級叢集，以及更新叢集。使用者叢集節點總數是限制效能和可靠性的主要因素之一。
根據持續測試，管理員叢集最多可穩定支援 100 個使用者叢集，每個叢集有 10 個節點，總共 1,000 個節點。
每個使用者叢集的 Pod 數量上限
建議您將每個使用者叢集的 Pod 數量限制在 15,000 個以下。舉例來說，如果叢集有 200 個節點，則應將每個節點的 Pod 數量限制為 75 個以下。同樣地，如果您想在每個節點執行 110 個 Pod，則應將叢集中的節點數量限制為 136 個以下。下表提供建議和不建議的設定範例。
| 每個節點的 Pod 數量。 | 每個叢集的節點數量 | 每個叢集的 Pod 數量 | 結果 |
|---|---|---|---|
| 110 | 200 | 22,000 | Pod 數量過多，不建議使用 |
| 110 | 136 | 14,960 | 未超出上限 |
| 100 | 150 | 15,000 | 未超出上限 |
| 75 | 200 | 15,000 | 未超出上限 |
每個使用者叢集的 Pod 數量上限建議，優先於下列各節中每個節點的 Pod 數量和每個使用者叢集的節點數量建議。
每個使用者叢集的節點數量上限
我們測試 Google Distributed Cloud，執行最多 500 個節點的工作負載。不過，為確保最佳效能和穩定性，建議您在正式環境中執行工作負載時，每個叢集的節點數量不要超過 200 個。
| 叢集類型 | 節點數量下限 | 建議的節點數量上限 | 節點數量絕對上限 |
|---|---|---|---|
| 使用者、獨立或混合 | 1 | 200 | 500 |
如果是單一節點叢集，您必須移除 node-role.kubernetes.io/master:NoSchedule 汙點，才能在節點上執行工作負載。詳情請參閱「Kubernetes taint 和容許條件」。
每個節點的 Pod 數量上限
Google Distributed Cloud 支援在叢集設定檔的 nodeConfig.PodDensity.MaxPodsPerNode 設定中，設定每個節點的 Pod 數量上限。下表列出 MaxPodsPerNode 支援的最小值和最大值，包括執行外掛程式服務的 Pod：
| 叢集類型 | 最小值 | 建議最大值 | 最大值 |
|---|---|---|---|
| 所有高可用性叢集和非高可用性使用者叢集 | 32 | 110 | 250 |
| 所有其他非高可用性叢集 | 64 | 110 | 250 |
端點數量上限
在 Red Hat Enterprise Linux (RHEL) 上，叢集層級的端點數量上限為 100,000 個。這個數字是 Kubernetes 服務參照的所有 Pod 總和。如果兩項服務參照同一組 Pod，這種情況會計為兩組獨立的端點。RHEL 的基礎 nftable 實作會導致這項限制，並非 Google Distributed Cloud 的固有限制。
緩解措施
RHEL 則沒有緩解措施。如果是 Ubuntu 和 Debian 系統，建議您在大型叢集上從預設的 nftables 切換至舊版 iptables。
Dataplane V2
Google Distributed Cloud 使用 Dataplane V2，這是以 Cilium 和 eBPF 實作的叢集資料層，已針對 Kubernetes 網路進行最佳化。
Dataplane V2 NetworkPolicy 限制
Dataplane V2 使用 Cilium 管理 Kubernetes NetworkPolicy 資源。叢集適用下列限制：
| 維度 | 支援的限制 |
|---|---|
| 命名空間標籤的變更率上限 | 每個命名空間每小時最多只能變更一次。
在大多數情況下，這項限制並非必要。只要變更頻率不高 (例如每秒)，或 Cilium 身分 (不重複標籤集) 數量未接近上限：16,000 個標籤集 (採用允許所有網路政策)，或每個叢集 65,535 個標籤集。 |
| 每個叢集的 Service 端點數量上限 | 100,000 個端點是經過測試的建議上限。服務端點的硬式編碼限制為 262,000。 |
| 網路政策和規則數量上限 | 最多 40,000 項網路政策和 80,000 項規則。舉例來說，您可以指定 40,000 項網路政策，每項政策有兩項規則，也可以指定 20,000 項政策，每項政策有四項規則。 |
| 網路政策的變更率上限 | 每秒最多 20 項變更 (建立或刪除)。 |
| 不重複 Pod 標籤組合數量上限 | 65,535 (216-1)。這是 Cilium 安全性身分限制。 |
| 政策選取器選取的 Pod 標籤組合不重複數量上限 | 16,000 (固定的 eBPF 對應大小)。特定政策選取器對應項目包含下列項目：security-identity、port 和 protocol。 |
Dataplane V2 eBPF 限制
Dataplane V2 的 BPF lbmap 項目數量上限為 65,536。下列項目的增加可能會導致項目總數增加：
- 服務數量
- 每項服務的通訊埠數量
- 每項服務的後端數量
建議您監控叢集使用的實際項目數量，確保不會超過限制。使用下列指令取得目前的項目：
kubectl get po -n kube-system -l k8s-app=cilium | cut -d " " -f1 | grep anetd | head -n1 | \
xargs -I % kubectl -n kube-system exec % -- cilium bpf lb list | wc -l
我們也建議您使用自己的監控管道，從 anetd DaemonSet 收集指標。請監控下列情況，判斷項目數量是否造成問題：
cilium_bpf_map_ops_total{map_name="lb4_services_v2",operation="update",outcome="fail" } > 0
cilium_bpf_map_ops_total{map_name="lb4_backends_v2",operation="update",outcome="fail" } > 0
LoadBalancer 和 NodePort Service 的通訊埠數量限制
LoadBalancer 和 NodePort 服務的通訊埠數量上限為 2,768 個。預設通訊埠範圍為 30000-32767。如果超過限制，就無法建立新的 LoadBalancer 或 NodePort Service，也無法為現有 Service 新增節點通訊埠。
根據預設，Kubernetes 會將節點通訊埠分配給 LoadBalancer 類型的 Service。這些分配作業可能會快速耗盡叢集分配到的 2,768 個可用節點通訊埠。如要節省節點通訊埠，請在 LoadBalancer Service 規格中將 allocateLoadBalancerNodePorts 欄位設為 false，停用負載平衡器節點通訊埠分配功能。這項設定可防止 Kubernetes 將節點通訊埠分配給 LoadBalancer Service。詳情請參閱 Kubernetes 說明文件中的「停用負載平衡器 NodePort 分配」。
使用下列指令，查看分配的通訊埠數量：
kubectl get svc -A | grep : | tr -s ' ' | cut -d ' ' -f6 | tr ',' '\n' | wc -l
隨附負載平衡器節點連線限制
用於套裝組合負載平衡 (MetalLB) 的每個節點，允許的連線數量為 28,000。這些連線的預設暫時通訊埠範圍為 32768-60999。如果超過連線限制，傳送至 LoadBalancer 服務的要求可能會失敗。
如要公開能處理大量連線的負載平衡器服務 (例如 Ingress)，建議您考慮使用其他負載平衡方法，避免 MetalLB 的這項限制。
叢集配額
根據預設，每個機群最多可註冊 250 個具備全域成員資格的叢集。如要在 GKE Hub 註冊更多叢集，請在 Google Cloud 控制台提交要求，提高配額：
如要進一步瞭解依據成員資格設定的叢集配額，請參閱「分配配額」。
資源調度資訊
本文資訊有助於規劃如何擴充叢集。詳情請參閱「擴充 Google Distributed Cloud 叢集」。
找不到您要搜尋的內容嗎？請按一下「提供意見」，告訴我們缺少哪些內容。