Container Service for Kubernetes：大規模叢集使用建議

大規模叢集使用須知

相較於使用多個叢集，構建一個大規模叢集可以有效減少叢集管理營運負擔，提高資源使用率。但在某些複雜的業務情境中，建議您根據商務邏輯或需求將服務拆分到多個叢集中，例如非生產（測試）服務與生產（開發）服務拆分、資料庫服務與前端應用拆分等。

如您有以下維度考量，我們更建議您使用多個叢集，而非單一的大規模叢集。

如您需要多叢集管理，例如應用部署、流量管理、作業分發、全域監控等，建議您啟用多叢集艦隊。

本文使用指引

本文主要面向ACK叢集Pro版的叢集開發和管理員，提供規劃和使用大規模叢集的通用性建議，實際情況仍以您的叢集環境和業務需求為準。

• 使用新版本叢集

• 關注叢集資源限制

• 合理設定管控組件參數

• 規劃叢集資源彈性速率

• 最佳化用戶端訪問叢集模式

• 合理規劃大規模工作負載

• 關注叢集控制面指標

使用新版本叢集

隨著Kubernetes版本不斷升級，Container ServiceACK會定期發布支援的Kubernetes版本，並逐步停止對到期版本的支援人員。對於到期版本，ACK將逐步停止發布新功能特性，停止修複功能缺陷、安全缺陷，且僅提供有限的支援人員。

請您通過協助文檔、控制台資訊、站內信等渠道關注版本發布情況，並在叢集升級前瞭解相應版本的升級注意事項，及時完成版本升級，避免潛在的叢集安全和穩定性問題。關於叢集升級的更多資訊，請參見手動升級叢集、自動升級叢集；關於Kubernetes版本支援資訊，請參見Kubernetes版本概覽及機制。

關注叢集資源限制

為保證大規模叢集的可用性、穩定性和各項效能，請關注下表列出的限制及對應的推薦解決方案。

合理設定管控組件參數

ACK叢集Pro版提供自訂Pro版叢集的控制面組件參數功能，支援修改kube-apiserver、kube-controller-manager、kube-scheduler等核心託管組件的參數。在大規模叢集中，您需要合理調整管控組件限流的相關參數。

kube-apiserver

為了避免大量並發請求導致控制面超載，kube-apiserver限制了它在特定時間內可以處理的並發請求數。一旦超出此限制，API Server將開始限流請求，向用戶端返回429 HTTP響應碼，即請求過多，並讓用戶端稍後再試。如果服務端沒有任何限流措施，可能導致控制面因處理超出其承載能力的請求而過載，嚴重影響整個服務或叢集的穩定性以及可用性。因此，推薦您在服務端配置限流機制，避免因控制面崩潰而帶來更廣泛的問題。

限流分類

kube-apiserver的限流分為兩種。

• v1.18以下：kube-apiserver僅支援最大並發度限流，將請求區分為讀類型和寫類型，通過啟動參數--max-requests-inflight和--max-mutating-requests-inflight限制讀寫請求的最大並發度。該方式不區分請求優先順序。某些低優先順序的慢請求可能佔用大量資源，造成API Server請求堆積，導致一些更高優先順序或更緊急的請求無法及時處理。

  ACK叢集Pro版支援自訂kube-apiserver的max-requests-inflight和max-mutating-requests-inflight的參數配置。更多資訊，請參見自訂Pro版叢集的控制面組件參數。

• v1.18及以上：引入APF(API優先順序和公平性）機制來進行更細粒度的流量管理，支援根據預設的規則和優先順序來分類和隔離請求，從而確保更重要和緊急的請求優先處理，同時遵循一定的公平性策略，保證不同類型的請求都能夠得到合理的處理機會。該特性於v1.20進入Beta階段，預設開啟。

  展開查看APF特性說明

  在v1.20及以上的Kubernetes叢集中，kube-apiserver通過--max-requests-inflight和--max-mutating-requests-inflight兩個參數的總和來配置可以並發處理的請求總數；通過FlowSchema和PriorityLevelConfiguration兩種自訂資來源物件（CRD）來控制總請求數在不同類型請求之間分配的並發數，更精細地控制請求的流量。

  • PriorityLevelConfiguration：優先順序配置，決定某個優先順序可以分配到全部並發度的比例。

  • FlowSchema：決定某個請求屬於哪個PriorityLevelConfiguration。

  PriorityLevelConfiguration和FlowSchema由kube-apiserver自動維護，Kubernetes叢集中會自動產生當前叢集版本的預設配置。您可以執行以下命令來查看。

  展開查看PriorityLevelConfiguration查詢命令與預期輸出

  kubectl get PriorityLevelConfiguration
  # 預期輸出
  NAME              TYPE      ASSUREDCONCURRENCYSHARES   QUEUES   HANDSIZE   QUEUELENGTHLIMIT   AGE
  catch-all         Limited   5                          <none>   <none>     <none>             4m20s
  exempt            Exempt    <none>                     <none>   <none>     <none>             4m20s
  global-default    Limited   20                         128      6          50                 4m20s
  leader-election   Limited   10                         16       4          50                 4m20s
  node-high         Limited   40                         64       6          50                 4m20s
  system            Limited   30                         64       6          50                 4m20s
  workload-high     Limited   40                         128      6          50                 4m20s
  workload-low      Limited   100                        128      6          50                 4m20s

  展開查看FlowSchema查詢命令與預期輸出

  說明

  ACK在FlowSchema中添加了ACK核心組件相關的分類ack-system-leader-election和ack-default。其餘與社區保持一致。

  kubectl get flowschemas
  # 預期輸出
  NAME                           PRIORITYLEVEL     MATCHINGPRECEDENCE   DISTINGUISHERMETHOD   AGE     MISSINGPL
  exempt                         exempt            1                    <none>                4d18h   False
  probes                         exempt            2                    <none>                4d18h   False
  system-leader-election         leader-election   100                  ByUser                4d18h   False
  endpoint-controller            workload-high     150                  ByUser                4d18h   False
  workload-leader-election       leader-election   200                  ByUser                4d18h   False
  system-node-high               node-high         400                  ByUser                4d18h   False
  system-nodes                   system            500                  ByUser                4d18h   False
  ack-system-leader-election     leader-election   700                  ByNamespace           4d18h   False
  ack-default                    workload-high     800                  ByNamespace           4d18h   False
  kube-controller-manager        workload-high     800                  ByNamespace           4d18h   False
  kube-scheduler                 workload-high     800                  ByNamespace           4d18h   False
  kube-system-service-accounts   workload-high     900                  ByNamespace           4d18h   False
  service-accounts               workload-low      9000                 ByUser                4d18h   False
  global-default                 global-default    9900                 ByUser                4d18h   False
  catch-all                      catch-all         10000                ByUser                4d18h   False

限流監測與推薦解決方案

用戶端可以通過返回狀態代碼429或通過監控指標apiserver_flowcontrol_rejected_requests_total來判斷服務端是否有限流行為。當觀測到有限流行為時，可以通過以下方式解決。

• 監控API Server資源用量：當資源用量較低時，可調整max-requests-inflight和max-mutating-requests-inflight參數總和提高總的限流值。

  對於500個節點以上的叢集，建議參數總和配置為2000～3000之間；對於3000個節點以上的叢集，建議參數總和配置在3000～5000之間。

• 重新設定PriorityLevelConfiguration：

  • 高優先順序請求：為不期望限流的請求劃分新的FlowSchema，匹配高優先順序的PriorityLevelConfiguration，例如workload-high或exempt。但exempt的請求不會被APF限流，請謹慎配置。您也可以為高優先順序的請求配置新的PriorityLevelConfiguration，給予更高的並發度。

  • 低優先順序請求：當的確存在某些用戶端慢請求導致API Server資源用量高或響應慢時，可以為該類請求新增一個FlowSchema，並為該FlowSchema匹配低並發度的PriorityLevelConfiguration。

kube-controller-manager和kube-scheduler

kube-controller-manager和kube-scheduler分別通過kubeAPIQPS/kubeAPIBurst、connectionQPS/connectionBurst參數控制與API Server通訊的QPS。更多資訊，請參見自訂Pro版叢集的控制面組件參數、自訂調度器參數。

• kube-controller-manager：對於1000個節點以上的叢集，建議將kubeAPIQPS/kubeAPIBurst調整為300/500以上。

• kube-scheduler：一般無需調整。Pod速率超過300/s時建議將connectionQPS/connectionBurst調整為800/1000。

kubelet

kubelet組件的kube-api-burst/qps預設值為5/10，一般無需調整。當您的叢集出現Pod狀態更新緩慢、調度延遲、儲存卷掛載緩慢等顯著性能問題時，建議您調大參數。操作步驟及說明，請參見自訂節點池kubelet配置。

規劃叢集資源彈性速率

在大規模叢集中，當叢集處於穩定運行狀態時，通常不會給控制面帶來太大的壓力。但當叢集進行大規模變更操作時，例如快速建立或刪除大量資源，或者大規模擴縮叢集節點數時，可能會造成控制面壓力過大，導致叢集效能下降、響應延遲，甚至服務中斷。

例如，在一個5,000個節點的叢集中，如果存在大量固定數量的Pod且保持穩定運行狀態，那麼它對控制面的壓力通常不會太大。但在一個1,000個節點的叢集中，如果需要在一分鐘內建立10,000個短暫啟動並執行Job，或並發擴容2,000個節點，那麼控制面的壓力會激增。

因此，在大規模叢集中進行資源變更操作時，需根據叢集運行狀態謹慎規劃彈性操作的變更速率，以確保叢集和控制面的穩定性。

推薦操作如下。

• 節點擴縮容：對於2000個節點以上的叢集，建議在通過節點池手動擴縮容節點時，單個節點池單次操作的節點數不超過100，多個節點池單次操作的總節點數不超過300。

• 應用Pod擴縮容：若您的應用關聯了Service，擴縮容過程中Endpoint、EndpointSlice的更新會推送到所有節點。在節點數量多的情境下，需要更新的相關資料也很多，可能導致叢集風暴效應。對5000節點以上的叢集，建議非Endpoint關聯的Pod更新QPS不超過300/s；Endpoints關聯的Pod更新QPS不超過10/s。例如，在Deployment中聲明Pod變換（Rolling Update）策略時，推薦您先設定較小的maxUnavailable和maxSurge取值，以降低Pod更新速率。

最佳化用戶端訪問叢集模式

在Kubernetes叢集中，用戶端（客戶商務應用程式或kubectl等）通過API Server來擷取叢集資源資訊。隨著叢集中的資源數量的增加，如果用戶端以相同的頻率進行請求，這些請求可能會給叢集控制面帶來更大的負載，導致控制面響應延遲，甚至導致管控面雪崩。在訪問叢集資源時，需瞭解並規劃訪問資源的大小和頻率。大規模叢集使用建議如下。

優先使用informer訪問本機快取資料

優先使用client-go的informer擷取資源，通過本機快取（Cache）查詢資料，避免List請求直接存取API Server，以減少API Server的負載壓力。

最佳化通過API Server擷取資源的方式

對於未訪問過的本機快取，仍需直接通過API Server擷取資源。但可以遵循以下建議。

• 在List請求中設定resourceVersion=0。

  resourceVersion表示資源狀態的版本。設定為0時，請求會擷取API Server的快取資料，而非直接存取etcd，減少API Server與etcd之間的內部互動次數，更快地響應用戶端List請求。樣本如下。

  k8sClient.CoreV1().Pods("").List(metav1.ListOptions{ResourceVersion: "0"})

• 避免全量List資源，防止資料檢索量過大。

  為了減少請求返回的資料量，應使用過濾條件（Filter）來限定List請求的範圍，例如lable-selector（基於資源標籤篩選）或field-selector（基於資源欄位篩選）。

  說明

  etcd是一個索引值（KV）儲存系統，本身不具備按label或field過濾資料的功能，請求帶有的過濾條件實際由API Server處理。因此，當使用Filter功能時，建議同時將List請求的resourceVersion設定為0。請求資料將從API Server的緩衝中擷取，而不會直接存取etcd，減少對etcd的壓力。

• 使用Protobuf（而非JSON）訪問非CRD資源。

  API Server可以以不同的資料格式向用戶端返回資來源物件，包括JSON和Protobuf。預設情況下，當用戶端請求Kubernetes API時，Kubernetes返回序列化為JSON的對象，其內容類型（Content-Type）為application/json。 用戶端可以指定請求使用Protobuf格式的資料，Protobuf在記憶體使用量和網路傳輸串流量方面相較JSON更具優勢。

  但並非所有API資源類型都支援Protobuf。發送請求時，可以在Accept要求標頭中指定多種內容類型（例如application/json、application/vnd.kubernetes.protobuf），從而支援在無法使用Protobuf時回退到預設的JSON格式。更多資訊，請參見Alternate representations of resources 。樣本如下。

  Accept: application/vnd.kubernetes.protobuf, application/json

使用中心化控制器

避免在每個節點上都建立獨立的控制器用於Watch叢集的全量資料。在這種情況下，控制器啟動時，將幾乎同時向API Server發送大量的List請求以同步當前的叢集狀態，對控制面造成巨大壓力，繼而導致服務不穩定或崩潰。

為了避免此問題，建議採用中心化的控制器設計，為整個叢集建立一個或一組集中管理的控制器執行個體，運行在單個節點或少數幾個節點上。中心化的控制器會負責監聽和處理所需的叢集資料，僅啟動一次（或少數幾次）List請求，並僅維護必要數量的Watch串連，大大減少了對API Server的壓力。

合理規劃大規模工作負載

停用自動掛載預設的Service Account

為了確保Pod中的Secret的同步更新，kubelet會為Pod配置的每個Secret建立一個Watch長串連。Watch機制可以讓kubelet即時接收Secret的更新通知。但當所有節點建立的Watch數量總和過多時，大量Watch串連可能會影響叢集控制面的效能。

• Kubernetes 1.22版本以前：建立Pod時，如果未指定ServiceAccount，Kubernetes會自動掛載預設的ServiceAccount作為Pod的Secret，使得Pod內部的應用能夠與API Server安全通訊。

  對於批處理系統和無需訪問API Server的業務Pod，建議您顯式聲明禁止自動掛載ServiceAccount Token，以避免建立相關的Secret和Watch（更多資訊，請參見automountServiceAccountToken）。在大規模叢集中，該操作可以避免建立不必要的Secret和與API Server的Watch串連，減輕叢集控制面的負擔。

• Kubernetes 1.22及之後：使用TokenRequest API來擷取一個短期的、自動輪換的令牌，並以投射卷的形式掛載此令牌。在提高Secret安全性的同時，該操作還能減少kubelet為每個ServiceAccount的Secret建立的Watch串連，降低叢集的效能開銷。

  關於如何啟用ServiceAccount Token投射卷功能，請參見使用ServiceAccount Token卷投影。

控制Kubernetes Object數量和大小

請及時清理無需使用的Kubernetes資源，例如ConfigMap、Secret、PVC等，減少系統資源的佔用，保持叢集健康、高效運轉。有以下使用建議。

• 限制Deployment記錄數：revisionHistoryLimit聲明了要為Deployment保留多少箇舊的ReplicaSet。如果取值太高，Kubernetes會保留很多歷史版本的ReplicaSet，增加kube-controller-manager的管理負擔。在大規模叢集中，如果Deployment較多且更新頻繁，您可以調低Deployment的revisionHistoryLimit的取值，清理舊的ReplicaSet。Deployment的revisionHistoryLimit預設取值為10。

• 清理無需使用的Job和相關的Pod：如果叢集中通過CronJob或其他機制建立了大量的作業（Job）對象，請使用ttlSecondsAfterFinished來自動清理叢集中較舊的Pod，指定在某個時間周期後Job和相關的Pod將完成自動清理（刪除）。

合理配置Informer類型組件的資源配置

Informer類型的組件主要用於監控和同步Kubernetes叢集的資源狀態。Informer類組件會建立對叢集API Server資源狀態的Watch串連，並在本地維護一個資來源物件的緩衝，以便快速響應資源狀態的變化。

對於Informer類型的組件，例如Controller組件、kube-scheduler等，組件記憶體佔用與其Watch的資源大小相關。大規模叢集下，請關注該類組件的記憶體資源消耗，避免組件OOM。組件頻繁OOM會導致組件持續資源監聽出現問題。組件頻繁重啟時，每次執行的List-Watch操作也會對叢集控制面（尤其是API Server）造成額外的壓力。

關注叢集控制面指標

相關文檔

• 關於ACK叢集的配額與限制，請參見配額與限制。

• 關於如何合理規劃叢集VPC網路及容器網路，請參見Kubernetes叢集網路規劃。

• 關於如何?叢集建立、工作負載的高可靠配置，請參見工作負載推薦配置。

• 使用ACK叢集時，如遇報錯或相關問題，請先參見故障排除、叢集管理FAQ自排查。