ACK集群的性能和可用性與集群資源數量、資源訪問頻率、訪問模式等緊密相關。不同變量組合下,API Server承載的壓力和性能差異不同。在大規模的ACK集群Pro版(通常為超過500個節點或者10,000個Pod的集群)中,集群管理者需要根據業務實際狀況合理規劃和使用規模化集群,密切關注監控指標,確保集群的穩定性和可用性。
大規模集群使用須知
相較于使用多個集群,構建一個大規模集群可以有效減少集群管理運維負擔,提高資源利用率。但在某些復雜的業務場景中,建議您根據業務邏輯或需求將服務拆分到多個集群中,例如非生產(測試)服務與生產(開發)服務拆分、數據庫服務與前端應用拆分等。
如您有以下維度的考量,我們更建議您使用多個集群,而非單一的大規模集群。
分類 | 說明 |
隔離性 | 使用多個集群可以確保不同集群(例如生產集群和測試集群)的隔離性,避免某個集群的問題影響全部業務,降低故障爆炸半徑。 |
位置 | 某些服務需要部署在離終端用戶更近的特定地理位置,以滿足可用性、低延時的需求。在此場景下,推薦您在多個地區部署多個集群。 |
單集群規模上限 | ACK托管控制面通過彈性伸縮和集群組件的性能優化來自適應集群規模。但Kubernetes架構存在性能瓶頸,超大的集群規模可能會影響集群的可用性和性能。在使用大規模集群前,您應該了解Kubernetes社區定義的容量限制與SLO,并前往配額平臺查看并申請提高容器服務 Kubernetes 版的配額上限。如果超出社區和ACK的限制,請拆分業務,使用多個集群。 |
如您需要多集群管理,例如應用部署、流量管理、作業分發、全局監控等,建議您啟用多集群艦隊。
本文使用指引
本文主要面向ACK集群Pro版的集群開發和管理人員,提供規劃和使用大規模集群的通用性建議,實際情況仍以您的集群環境和業務需求為準。
使用新版本集群
隨著Kubernetes版本不斷升級,容器服務ACK會定期發布支持的Kubernetes版本,并逐步停止對過期版本的技術支持。對于過期版本,ACK將逐步停止發布新功能特性,停止修復功能缺陷、安全缺陷,且僅提供有限的技術支持。
請您通過幫助文檔、控制臺信息、站內信等渠道關注版本發布情況,并在集群升級前了解相應版本的升級注意事項,及時完成版本升級,避免潛在的集群安全和穩定性問題。關于集群升級的更多信息,請參見手動升級集群、自動升級集群;關于Kubernetes版本支持信息,請參見Kubernetes版本概覽及機制。
關注集群資源限制
為保證大規模集群的可用性、穩定性和各項性能,請關注下表列出的限制及對應的推薦解決方案。
限制項 | 說明 | 推薦解決方案 |
etcd數據庫大小(DB Size) | etcd數據庫大小上限為8 GB。當etcd數據庫過大時,會影響其性能,包括數據讀取和寫入延遲、系統資源占用、選舉延時等,也會導致服務和數據恢復過程更加困難和耗時。 | 控制etcd DB Size的總大小在8 GB以下。
|
etcd中每種類型資源的數據總大小 | 如果資源對象總量過大,客戶端全量訪問該資源時會導致大量的系統資源消耗,嚴重時可能會導致API Server或自定義控制器(Controller)無法初始化。 | 控制每種資源類型的對象總大小在800 MB以下。
|
API Server CLB的連接數和帶寬 | 目前,ACK集群API Server使用的負載均衡類型為CLB,其連接數與帶寬有最大容量限制。CLB最大連接數可參見CLB實例概述,最大帶寬為5120Mbps。 超出CLB連接數或者帶寬限制可能會造成節點Not Ready。 | 對于1,000節點以上的集群,建議選擇按使用量計費的CLB實例。 說明 為提升網絡連接速度和帶寬,大規模集群訪問Default命名空間中的Kubernetes服務時,應使用ENI直連模式。在2023年02月以后新建的,v1.20以上的集群中,新建集群已默認使用ENI直連;存量集群的切換請提交工單。更多信息,請參見Kube API Server。 |
每個命名空間的Service數量 | kubelet會把集群中定義的Service的相關信息以環境變量的形式注入到運行在該節點上的Pod中,讓Pod能夠通過環境變量來發現Service,并與之通信。 每個命名空間中的服務數量過多會導致為Pod注入的環境變量過多,繼而可能導致Pod啟動緩慢甚至失敗 | 將每個命名空間的Service數量控制在5,000以下。 您可以選擇不填充這些環境變量,將 |
集群的總Service數量 | Service數量過多會導致kube-proxy需要處理的網絡規則增多,繼而影響kube-proxy的性能。 對于LoadBalancer類型的Service,Service數量過多會導致Service同步到SLB的時延增加,延遲可能達到分鐘級別。 | 將所有Service的總數量控制在10,000以下。 對LoadBalancer類型的Service,建議將Service總數控制在500以下。 |
單個Service的Endpoint最大數量 | 每個節點上運行著kube-proxy組件,用于監視(Watch)Service的相關更新,以便及時更新節點上的網絡規則。當某個Service存在很多Endpoint時,Service相應的Endpoints資源也會很大,每次對Endpoints對象的更新都會導致控制面kube-apiserver和節點kube-proxy之間傳遞大量流量。集群規模越大,需要更新的相關數據越多,風暴效應越明顯。 說明 為了解決此問題,kube-proxy在v1.19以上的集群中默認使用EndpointSlices來提高性能。 | 將單個Service的Endpoints的后端Pod數量控制在3,000以下。
|
所有Service Endpoint的總數量 | 集群中Endpoint數量過多可能會造成API Server負載壓力過大,并導致網絡性能降低。 | 將所有Service關聯的Endpoint的總數量控制在64,000以下。 |
Pending Pod的數量 | Pending Pod數量過多時,新提交的Pod可能會長時間處于等待狀態,無法被調度到合適的節點上。在此過程中,如果Pod無法被調度,調度器會周期性地產生事件(event),繼而可能導致事件泛濫(event storm)。 | 將Pending Pod的總數量控制在10,000以下。 |
啟用了使用阿里云KMS進行Secret的落盤加密的集群中的Secret數量 | 使用KMS v1加密數據時,每次加密都會生成一個新的數據加密密鑰(DEK)。Kubernetes集群啟動時,需要訪問并解密存儲在etcd中的Secret。如果集群存儲的Secret過多,集群在啟動或升級時需要解密大量的數據,影響集群性能。 | 將開啟KMS V1加密的集群中存儲的Secret數量控制在2,000以下。 |
合理設置管控組件參數
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階段,默認開啟。
在v1.20及以上的Kubernetes集群中,kube-apiserver通過
--max-requests-inflight
和--max-mutating-requests-inflight
兩個參數的總和來配置可以并發處理的請求總數;通過FlowSchema和PriorityLevelConfiguration兩種自定義資源對象(CRD)來控制總請求數在不同類型請求之間分配的并發數,更精細地控制請求的流量。PriorityLevelConfiguration:優先級配置,決定某個優先級可以分配到全部并發度的比例。
FlowSchema:決定某個請求屬于哪個PriorityLevelConfiguration。
PriorityLevelConfiguration和FlowSchema由kube-apiserver自動維護,Kubernetes集群中會自動生成當前集群版本的默認配置。您可以執行以下命令來查看。
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
說明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。
ACK集群Pro版會為您托管kube-apiserver組件。kube-apiserver默認為多AZ高可用,會保證至少2個副本,并隨著控制面資源使用率增大而逐漸調整至最大6個副本。
可并發的總實際請求值 = 副本數單個副本總請求量
。修改kube-apiserver的自定義參數會觸發API Server的滾動更新,可能導致客戶端Controller重新進行List-Watch操作。在大規模集群下,這可能會造成API Server負載過高,導致其服務暫時不可用。
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配置。
調大kubelet該參數會增大kubelet與API Server的通信QPS。如果kubelet發送的請求數量過多,可能會增大API Server的負載。建議您逐步增加取值,并關注API Server的性能和資源用量,確保控制面穩定性。
對節點kubelet執行變更操作時,需合理控制更新頻率。為保證變更過程中控制面的穩定性,ACK限制單節點池每批次的最大并行數不超過10。
規劃集群資源彈性速率
在大規模集群中,當集群處于穩定運行狀態時,通常不會給控制面帶來太大的壓力。但當集群進行大規模變更操作時,例如快速創建或刪除大量資源,或者大規模擴縮集群節點數時,可能會造成控制面壓力過大,導致集群性能下降、響應延遲,甚至服務中斷。
例如,在一個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)造成額外的壓力。
關注集群控制面指標
您可以查看控制面組件監控大盤,獲取控制面核心組件的指標清單、異常指標問題解析等。在大規模集群中,請重點關注以下指標。關于指標的使用說明、詳細說明,請參見控制面組件監控。
管控資源用量
目前管控組件所有資源用量均可以查看,相關指標和介紹如下:
指標名稱 | PromQL | 說明 |
內存使用量 | memory_utilization_byte{container="kube-apiserver"} | API Server的內存使用量。單位:字節。 |
CPU使用量 | cpu_utilization_core{container="kube-apiserver"}*1000 | API Server的CPU使用量。單位:毫核。 |
kube-apiserver
關于如何查看指標及指標的完整說明,請參見kube-apiserver組件監控指標說明。
資源對象數量
名稱
PromQL
說明
資源對象數量
max by(resource)(apiserver_storage_objects)
max by(resource)(etcd_object_counts)
當ACK為1.22及以上版本時, 指標名字為apiserver_storage_objects
當ACK為1.22及以下版本時,指標名字為etcd_object_counts。
說明由于兼容性問題,1.22版本中apiserver_storage_objects名稱和etcd_object_counts名稱均存在。
請求時延
名稱
PromQL
說明
GET讀請求時延
histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb="GET",resource!="",subresource!~"log|proxy"}[$interval])) by (pod, verb, resource, subresource, scope, le))
展示GET請求的響應時間,維度包括API Server Pod、Verb(GET)、Resources、Scope。
LIST讀請求時延
histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb="LIST"}[$interval])) by (pod_name, verb, resource, scope, le))
展示LIST請求的響應時間,維度包括API Server Pod、Verb(LIST)、Resources、Scope。
寫請求時延
histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb!~"GET|WATCH|LIST|CONNECT"}[$interval])) by (cluster, pod_name, verb, resource, scope, le))
展示Mutating請求的響應時間,維度包括API Server Pod、Verb(GET、WATCH、LIST、CONNECT)、Resources、Scope。
請求限流
名稱
PromQL
說明
請求限流速率
sum(irate(apiserver_dropped_requests_total{request_kind="readOnly"}[$interval])) by (name)
sum(irate(apiserver_dropped_requests_total{request_kind="mutating"}[$interval])) by (name)
API Server的限流速率 ,
No data
或者0
表示沒有限流。
kube-scheduler
關于如何查看指標及指標的完整說明,請參見kube-scheduler組件監控指標說明。
Pending Pod數
名稱
PromQL
說明
Scheduler Pending Pods
scheduler_pending_pods{job="ack-scheduler"}
Pending Pod的數量。隊列種類如下:
unschedulable:不可調度的Pod數量。
backoff:backoffQ的Pod數量,即因為某種原因暫時不能被調度的Pod數量。
active:activeQ的Pod數量,即準備就緒并等待被調度的Pod數量。
請求時延
名稱
PromQL
說明
Kube API 請求時延
histogram_quantile($quantile, sum(rate(rest_client_request_duration_seconds_bucket{job="ack-scheduler"}[$interval])) by (verb,url,le))
kube-scheduler對kube-apiserver組件發起的HTTP請求時延,從方法(Verb)和請求URL維度分析。
kube-controller-manager
關于如何查看指標及指標的完整說明,請參見kube-controller-manager組件監控指標說明。
Workqueue
名稱 | PromQL | 說明 |
Workqueue深度 | sum(rate(workqueue_depth{job="ack-kube-controller-manager"}[$interval])) by (name) | Workqueue深度在單位時間內的變化。 |
Workqueue處理時延 | histogram_quantile($quantile, sum(rate(workqueue_queue_duration_seconds_bucket{job="ack-kube-controller-manager"}[5m])) by (name, le)) | 事件在Workqueue中存在的時長。 |
etcd
關于如何查看指標及指標的完整說明,請參見etcd組件監控指標說明。
KV總數
名稱
PromQL
說明
kv總數
etcd_debugging_mvcc_keys_total
etcd集群KV對(鍵對)總數。
數據庫大小(DB Size)
名稱
PromQL
說明
磁盤大小
etcd_mvcc_db_total_size_in_bytes
etcd Backend DB總大小,即etcd后端數據庫總大小。
etcd_mvcc_db_total_size_in_use_in_bytes
etcd Backend DB實際使用大小,即etcd后端數據庫實際使用大小。
相關文檔
關于ACK集群的配額與限制,請參見配額與限制。
關于如何合理規劃集群VPC網絡及容器網絡,請參見Kubernetes集群網絡規劃。
關于如何實現集群創建、工作負載的高可靠配置,請參見工作負載推薦配置。