本頁面僅說明裸機適用的 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：
| 叢集類型 | 最小值 | 建議最大值 | 最大值 |
|---|---|---|---|
| 所有 HA 叢集和非 HA 使用者叢集 | 32 | 110 | 250 |
| 所有其他非 HA 叢集 | 64 | 110 | 250 |
端點數量上限
在 Red Hat Enterprise Linux (RHEL) 上，叢集層級的端點限制為 100,000 個。這個數字是 Kubernetes 服務參照的所有 Pod 總和。如果兩項服務參照同一組 Pod，這種情況會計為兩組不同的端點。這是因為 RHEL 的底層實作方式所致，並非 Google Distributed Cloud 的固有限制。nftable
緩解
對於 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 個標籤集。 |
| 每個叢集的服務端點數量上限 | 10 萬個端點是經過測試的建議上限。服務端點的硬式編碼限制為 262,000。 |
| 網路政策和規則數量上限 | 最多 40,000 項網路政策和 80,000 項規則。舉例來說，您可以指定 40,000 項網路政策，每項政策有兩條規則；也可以指定 20,000 項政策，每項政策有四條規則。 |
| 網路政策的變更率上限 | 每秒最多 20 項變更 (建立或刪除)。 |
| 不重複 Pod 標籤集數量上限 | 65,535 (216-1)。這是 Cilium 安全性身分限制。 |
| 政策選取器選取的 Pod 標籤組合數量上限 | 16,000 (固定的 eBPF 對應大小)。特定政策選取器對應關係包含以下內容：安全身分、通訊埠和通訊協定。 |
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 服務，也無法為現有服務新增節點連接埠。
根據預設，Kubernetes 會將節點通訊埠指派給 LoadBalancer 類型的 Service。這些分配作業可能會快速耗盡叢集分配到的 2,768 個可用節點埠。如要儲存節點通訊埠，請在 LoadBalancer Service 規格中，將 allocateLoadBalancerNodePorts 欄位設為 false，停用負載平衡器節點通訊埠分配作業。這項設定可防止 Kubernetes 將節點通訊埠分配給 LoadBalancer 服務。詳情請參閱 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 叢集」。
找不到您要搜尋的內容嗎？按一下「提供意見」，告訴我們缺少哪些資訊。