擴大 Google Distributed Cloud 叢集

與任何 Kubernetes 叢集一樣，Google Distributed Cloud 叢集的可擴充性有許多相互關聯的維度。本文旨在協助您瞭解可調整的主要維度，以便擴充叢集，同時不中斷工作負載。

瞭解限制

Google Distributed Cloud 是一個複雜的系統，整合介面廣泛。影響叢集擴充性的因素有很多，舉例來說，節點數量只是 Google Distributed Cloud 是否能夠擴充的眾多維度之一。其他維度還包括 Pod 和 Service 的總數。許多維度 (例如每個節點的 Pod 數和每個叢集的節點數) 彼此相關。如要進一步瞭解會影響可擴充性的維度，請參閱 GitHub 上 Kubernetes 社群存放區的「Scalability Special Interest Group (SIG)」(可擴充性特別興趣小組) 部分，瞭解 Kubernetes 可擴充性門檻。

此外，叢集執行的硬體和節點設定也會影響擴充性限制。本文所述限制是在與您環境不同的環境中驗證，因此，如果基礎環境是限制因素，您可能無法重現相同的數字。

如要進一步瞭解 Google Distributed Cloud 叢集的適用限制，請參閱「配額和限制」。

準備資源調度

準備擴充 Google Distributed Cloud 叢集時，請考量下列各節所述的規定和限制。

控制層節點 CPU 和記憶體需求

下表列出執行實際工作負載的叢集，建議使用的控制平面節點 CPU 和記憶體設定：

Pod 和服務數量

叢集中的 Pod 和 Service 數量受下列設定控管：

• clusterNetwork.pods.cidrBlocks 指定叢集允許的 Pod 數量。

• nodeConfig.podDensity.maxPodsPerNode 指定可在單一節點上執行的 Pod 數量上限。

• clusterNetwork.services.cidrBlocks 指定叢集中允許的服務數量。

Pod CIDR 和節點數量上限

為叢集中的 Pod 保留的 IP 位址總數，是叢集擴充的限制因素之一。這項設定與每個節點的 Pod 數量上限設定搭配使用，可決定叢集中的節點數量上限，避免 Pod 的 IP 位址用盡。

請考量下列事項：

• 為叢集中的 Pod 保留的 IP 位址總數，是以 clusterNetwork.pods.cidrBlocks 指定，並採用 CIDR 標記法指定 IP 位址範圍。舉例來說，預先填入的值 192.168.0.0/16 會指定 65,536 個 IP 位址的範圍，從 192.168.0.0 到 192.168.255.255。

• 單一節點上可執行的 Pod 數量上限以 nodeConfig.podDensity.maxPodsPerNode 指定。

• Google Distributed Cloud 會根據每個節點的 Pod 數上限設定，為節點佈建約兩倍的 IP 位址。額外的 IP 位址有助於避免在短時間內不慎重複使用 Pod IP。

• 將 Pod IP 位址總數除以每個節點上佈建的 Pod IP 位址數，即可得出叢集中的節點總數。

舉例來說，如果 Pod CIDR 為 192.168.0.0/17，您總共有 32,768 個 IP 位址 (2^(32-17) = 2¹⁵ = 32,768)。如果您將每個節點的最大 Pod 數設為 250，Google Distributed Cloud 會佈建大約 500 個 IP 位址的範圍，這大致相當於 /23 CIDR 區塊 (2^(32-23) = 2⁹ = 512)。因此，在本例中，節點數上限為 64 個 (2¹⁵ 個位址/叢集除以 2⁹ 個位址/節點 = 2^(15-9) 個節點/叢集 = 2⁶ = 64 個節點/叢集)。

clusterNetwork.pods.cidrBlocks和 nodeConfig.podDensity.maxPodsPerNode都無法變更，因此請仔細規劃叢集的未來成長，以免節點容量不足。如要查看根據測試結果建議的每個叢集 Pod 數上限、每個節點 Pod 數上限，以及每個叢集節點數上限，請參閱「限制」。

Service CIDR

您可以更新 Service CIDR，在擴充叢集時新增更多服務。但無法縮減 Service CIDR 範圍。詳情請參閱「擴大服務網路範圍」。

系統精靈保留的資源

根據預設，Google Distributed Cloud 會自動在節點上預留資源，供系統精靈 (例如 sshd 或 udev) 使用。系統會為節點上的系統 Daemon 保留 CPU 和記憶體資源，確保這些 Daemon 擁有所需資源。如果沒有這項功能，Pod 可能會耗用節點上的大部分資源，導致系統精靈無法完成工作。

具體來說，Google Distributed Cloud 會在每個節點上保留 80 millicore 的 CPU (80 mCPU) 和 280 Mebibytes (280 MiB) 的記憶體，供系統精靈使用。請注意，CPU 單位 mCPU 代表千分之一的核心，因此每個節點會保留 80/1000 或 8% 的核心供系統精靈使用。保留的資源量很小，不會對 Pod 效能造成重大影響。不過，如果 Pod 使用的 CPU 或記憶體超出分配給 Pod 的數量，節點上的 kubelet 可能會將 Pod 逐出。

使用 MetalLB 建立網路

您可能需要增加 MetalLB 揚聲器數量，以解決下列問題：

• 頻寬：負載平衡服務的整個叢集頻寬取決於音箱數量和每個音箱節點的頻寬。網路流量增加，需要更多音箱。

• 容錯能力：更多音箱可降低單一音箱故障造成的整體影響。

MetalLB 需要負載平衡節點之間的第 2 層連線。在這種情況下，您可能會受限於具有第 2 層連線的節點數量，而這些節點是您可放置 MetalLB 揚聲器的地方。

請仔細規劃要在叢集中加入多少 MetalLB 揚聲器，並決定需要多少第 2 層節點。詳情請參閱「MetalLB 可擴充性問題」。

此外，使用隨附的負載平衡模式時，控制層節點也必須位於同一個第 2 層網路。手動負載平衡則沒有這項限制。詳情請參閱「手動負載平衡器模式」。

執行大量節點、Pod 和服務

新增節點、Pod 和 Service 是擴充叢集的方式。下列章節將介紹一些額外設定和設定，當您增加叢集中的節點、Pod 和服務數量時，應考慮這些設定和設定。如要瞭解這些維度的限制，以及這些限制之間的關聯，請參閱「限制」一文。

建立不含 kube-proxy 的叢集

如要建立高效能叢集，並擴充至使用大量服務和端點，建議您建立叢集時不要使用 kube-proxy。如果沒有 kube-proxy，叢集會以 kube-proxy-replacement 模式使用 GKE Dataplane V2。這個模式可避免維護大量 iptables 規則所需的資源耗用。

您無法為現有叢集停用 kube-proxy。建立叢集時，必須設定這項設定。如需操作說明和詳細資訊，請參閱「建立不含 kube-proxy 的叢集」。

CoreDNS 設定

本節說明 CoreDNS 的哪些方面會影響叢集的可擴充性。

Pod DNS

根據預設，Google Distributed Cloud 叢集會將 Pod 注入類似下列內容的 resolv.conf：

nameserver KUBEDNS_CLUSTER_IP
search <NAMESPACE>.svc.cluster.local svc.cluster.local cluster.local c.PROJECT_ID.internal google.internal
options ndots:5

選項 ndots:5 表示少於 5 個半形句號的主機名稱不視為完整網域名稱 (FQDN)。DNS 伺服器會附加所有指定的搜尋網域，然後查詢原始要求的主機名稱，解析 google.com 時的查詢順序如下：

1. google.com.NAMESPACE.svc.cluster.local
2. google.com.svc.cluster.local
3. google.com.cluster.local
4. google.com.c.PROJECT_ID.internal
5. google.com.google.internal
6. google.com

系統會針對 IPv4 (A 記錄) 和 IPv6 (AAAA 記錄) 執行每次查詢，因此每個非 FQDN 查詢都會產生 12 個 DNS 要求，大幅增加 DNS 流量。為減輕這個問題的影響，建議您新增尾隨點 (google.com.)，將要查閱的主機名稱宣告為 FQDN。這項宣告必須在應用程式工作負載層級完成。詳情請參閱 resolv.conf 手冊頁面。

IPv6

如果叢集未使用 IPv6，可以消除對上游 DNS 伺服器的 AAAA 記錄查詢，將 DNS 要求減少一半。如需停用 AAAA 查閱的協助，請與 Cloud Customer Care 聯絡。

專屬節點集區

由於 DNS 查詢在應用程式生命週期中至關重要，因此我們建議您為 coredns 部署作業使用專屬節點。這個部署作業的失敗網域與一般應用程式不同。如需協助為 coredns Deployment 設定專屬節點，請與 Cloud Customer Care 聯絡。

MetalLB 擴充性問題

MetalLB 會以主動-被動模式執行，也就是說，在任何時間點，只有一個 MetalLB 揚聲器會為特定 LoadBalancer VIP 提供服務。

容錯移轉

在 Google Distributed Cloud 1.28.0 版發布前，大規模 MetalLB 容錯移轉可能需要很長時間，且可能對叢集造成可靠性風險。

連線限制

如果特定 LoadBalancer VIP (例如 Ingress 服務) 預期會有接近或超過 3 萬個並行連線，處理 VIP 的音箱節點可能會耗盡可用連接埠。由於架構限制，MetalLB 無法解決這個問題。建議您在建立叢集前，改用搭配 BGP 的組合式負載平衡，或使用其他 Ingress 類別。詳情請參閱「Ingress 設定」。

負載平衡器音箱

根據預設，Google Distributed Cloud 會對控制層和資料層使用相同的負載平衡器節點集區。如未指定負載平衡器節點集區 (loadBalancer.nodePoolSpec)，系統會使用控制層節點集區 (controlPlane.nodePoolSpec)。

如要使用控制層節點集區進行負載平衡，並增加喇叭數量，請增加控制層機器的數量。對於實際部署作業，建議您使用三個控制平面節點，確保高可用性。如果增加控制層節點數量超過三個，以容納額外的音箱，可能無法有效運用資源。

輸入設定

如果您預期單一 LoadBalancer 服務 VIP 會湧入近 3 萬個並行連線，MetalLB 可能無法支援。

您可以考慮透過其他機制 (例如 F5 BIG-IP) 公開 VIP。或者，您也可以使用使用 BGP 進行套裝組合負載平衡建立新叢集，這樣就不會受到相同限制。

微調 Cloud Logging 和 Cloud Monitoring 元件

在大型叢集中，Cloud Logging 和 Cloud Monitoring 元件的預設資源設定可能不足，具體情況取決於應用程式設定檔和流量模式。如要瞭解如何調整可觀測性元件的資源要求和限制，請參閱設定 Stackdriver 元件資源。

特別是，如果叢集有大量服務和端點，kube-state-metrics 可能會導致kube-state-metrics本身和同一節點上的 gke-metrics-agent 記憶體用量過高。指標伺服器的資源用量也會根據節點、Pod 和 Service 進行調整。如果這些元件發生資源問題，請與 Cloud Customer Care 聯絡。

使用 sysctl 設定作業系統

建議您根據工作負載用途，微調節點的作業系統設定。控制 inotify 資源數量的 fs.inotify.max_user_watches 和 fs.inotify.max_user_instances 參數通常需要調整。舉例來說，如果看到下列錯誤訊息，您可能需要調整這些參數：

The configured user limit (128) on the number of inotify instances has been reached

ENOSPC: System limit for number of file watchers reached...

調整方式通常會因工作負載類型和硬體設定而異。您可以向作業系統供應商諮詢特定作業系統的最佳做法。

最佳做法

本節將說明擴充叢集的最佳做法。

一次調整一個維度

為盡量減少問題並方便還原變更，請一次只調整一個維度。即使是在較小的叢集中，同時調度多個維度也可能會導致發生問題。舉例來說，嘗試將每個節點排定的 Pod 數量增加至 110 個，同時將叢集中的節點數量增加至 250 個，可能不會成功，因為 Pod 數量、每個節點的 Pod 數量和節點數量會擴展得太大。

分階段調度叢集資源

擴充叢集可能會耗用大量資源。為降低叢集作業失敗或叢集工作負載中斷的風險，建議您不要嘗試在單一作業中建立含有大量節點的大型叢集。

建立不含工作站節點的混合式或獨立叢集

如要建立超過 50 個工作站節點的大型混合或獨立叢集，建議先建立具有控制層節點的高可用性 (HA) 叢集，然後逐步擴充。叢集建立作業會使用啟動程序叢集，但這並非高可用性叢集，因此可靠性較低。建立高可用性混合或獨立叢集後，即可使用該叢集擴充更多節點。

分批增加工作站節點數量

如要將叢集擴展至更多工作站節點，建議分階段擴展。建議一次新增的節點不要超過 20 個。對於執行重要工作負載的叢集而言，更是如此。

啟用並行映像檔提取作業

根據預設，kubelet 會依序提取映像檔。如果與映像檔登錄伺服器的上游連線品質不佳，映像檔提取作業可能會失敗，導致特定節點集區的整個佇列停滯。

為減輕這種情況，建議您在自訂 kubelet 設定中，將 serializeImagePulls 設為 false。如需操作說明和詳細資訊，請參閱「設定 kubelet 映像檔提取設定」。啟用平行提取映像檔可能會導致網路頻寬或磁碟 I/O 的消耗量暴增。

微調應用程式資源要求和限制

在密集封裝的環境中，應用程式工作負載可能會遭到驅逐。 Kubernetes 會使用參照機制，在 Pod 遭到驅逐時進行排序。

設定容器資源時，建議您將要求和限制的記憶體用量設為相同，並將 CPU 限制設為較大或無限制。詳情請參閱 Cloud Architecture Center 的「準備雲端 Kubernetes 應用程式」。

使用儲存空間合作夥伴提供的功能

建議您使用GDC Ready 儲存空間合作夥伴，進行大規模部署。請務必向特定儲存空間合作夥伴確認下列資訊：

• 儲存空間部署作業遵循儲存空間方面的最佳做法，例如高可用性、優先順序設定、節點親和性，以及資源要求和限制。
• 儲存空間版本會根據特定 Google Distributed Cloud 版本進行資格認證。
• 儲存空間供應商可支援您想部署的高規模。

設定高可用性叢集

請務必稽核大規模部署作業，並盡可能確保重要元件已設定為高可用性。Google Distributed Cloud 支援所有叢集類型的高可用性部署選項。詳情請參閱「選擇部署模型」。如需高可用性部署作業的叢集設定檔範例，請參閱「叢集設定範例」。

此外，稽核其他元件也很重要，包括：

• 儲存空間供應商
• 叢集 Webhook

監控資源用量

本節提供大規模叢集的基本監控建議。

密切監控使用率指標

請務必監控節點和個別系統元件的使用情況，並確保這些元件有足夠的安全餘裕。如要瞭解預設提供的標準監控功能，請參閱「使用預先定義的資訊主頁」。

監控頻寬用量

密切監控頻寬消耗量，確保網路不會飽和，以免叢集效能降低。

提升 etcd 效能

磁碟速度是 etcd 效能和穩定性的關鍵。磁碟速度緩慢會增加 etcd 要求延遲時間，可能導致叢集穩定性問題。為提升叢集效能，Google Distributed Cloud 會將 Event 物件儲存在專屬的獨立 etcd 執行個體中。標準 etcd 執行個體會使用 /var/lib/etcd 做為資料目錄，並使用通訊埠 2379 處理用戶端要求。etcd-events 執行個體會使用 /var/lib/etcd-events 做為資料目錄，並使用 2382 埠處理用戶端要求。

建議您為 etcd 儲存空間使用固態硬碟 (SSD)。如要獲得最佳效能，請將個別磁碟掛接到 /var/lib/etcd 和 /var/lib/etcd-events。使用專屬磁碟可確保兩個 etcd 執行個體不會共用磁碟 I/O。

如要在實際工作環境中執行叢集時確保 etcd 達到最佳效能，請參閱 etcd 說明文件中的硬體建議。

如要檢查 etcd 和磁碟效能，請在 Metrics Explorer 中使用下列 etcd I/O 延遲指標：

• etcd_disk_backend_commit_duration_seconds：第 99 個百分位數 (p99) 的時間長度應小於 25 毫秒。
• etcd_disk_wal_fsync_duration_seconds：第 99 個百分位數 (p99) 的時間長度應少於 10 毫秒。

如要進一步瞭解 etcd 效能，請參閱「What does the etcd warning "apply entries took too long" mean?」(etcd 警告「apply entries took too long」是什麼意思？) 和「What does the etcd warning "failed to send out heartbeat on time" mean?」(etcd 警告「failed to send out heartbeat on time」是什麼意思？)。

如需其他協助，請與 Cloud Customer Care 團隊聯絡。如要進一步瞭解支援資源，包括下列項目，請參閱「取得支援」：

• 提出支援案件的規定。
• 工具：協助您排解問題，例如環境設定、記錄和指標。
• 支援的元件。

後續步驟

• 安裝先決條件總覽

• 選擇部署模式

• 配額與限制