kube-apiserver組件提供了Kubernetes的RESTful API介面,使得外部客戶端、叢集內的其他組件可以與ACK叢集互動。本文介紹kube-apiserver組件的監控指標清單、大盤使用指導以及常見指標異常解析。
使用前須知
操作入口
請參見查看叢集控制面組件監控大盤。
指標清單
指標是組件對外透出狀態和參數的方式之一。kube-apiserver組件使用的指標清單如下。
指標清單 | 類型 | 解釋 |
apiserver_request_duration_seconds_bucket | Histogram | 該指標用於統計API Server用戶端對API Server不同請求的訪問時延分布。 請求的維度包括:
API ServerHistogram的Bucket閾值為 |
apiserver_request_total | Counter | 對API Server不同請求的計數。請求的維度包括Verb、Group、Version、Resource、Scope、Component、HTTP contentType、HTTP code(響應的HTTP狀態代碼)和Client。 |
apiserver_request_no_resourceversion_list_total | Counter | 對API Server的請求中參數未配置 |
apiserver_current_inflight_requests | Gauge | API Server當前處理的請求數量。請求包括兩種:
|
apiserver_dropped_requests_total | Counter | API Server執行限流策略過程中,主動丟棄掉的請求數。HTTP傳回值為 |
etcd_request_duration_seconds_bucket | Histogram | 該指標用於統計API Server對etcd請求的訪問時延分布。 請求的維度包括操作(Operation)和操作對象的類型(Type)。 Bucket閾值為 |
apiserver_flowcontrol_request_concurrency_limit | Gauge | APF請求並發限制。表示某個優先順序隊列的最大並發限制,即該隊列理論上允許同時處理的最大請求數,供您瞭解API Server如何通過流量控制策略將資源分派給不同優先順序的隊列,從而確保高優先順序請求可以及時處理。 該指標在Kubernetes 1.30版本變為Deprecated,自1.31版本起移除,1.31及以上版本的叢集中建議使用apiserver_flowcontrol_nominal_limit_seats指標代替。 |
apiserver_flowcontrol_current_executing_requests | Gauge | 某個優先順序隊列中當前正在執行的請求數量,即該隊列的實際並發負載,供您瞭解API Server的實際負載情況,判斷是否接近系統最大並發限制,防止過載。 |
apiserver_flowcontrol_current_inqueue_requests | Gauge | 某個優先順序隊列中當前在隊列中等待處理的請求數量,即該隊列的請求積壓情況,以瞭解API Server的流量壓力以及隊列是否過載。 |
apiserver_flowcontrol_nominal_limit_seats | Gauge | APF 名義並發限制席位元量,即API Server理論上(nominal)的最大並發處理能力,以Seat為單位。供您瞭解API Server如何通過流量控制策略將資源分派給不同優先順序的隊列。 |
apiserver_flowcontrol_current_limit_seats | Gauge | APF 當前並發限制席位元量。表示某個優先順序隊列的當前並發限制(Current Concurrency Limit),即在動態調整後實際允許的最大並發席位元量,反映當前隊列的實際並發能力(可能因系統負載或其他因素而動態變化)。 與 nominal_limit_seats 不同,此值可能會受全域流量控制策略影響。 |
apiserver_flowcontrol_current_executing_seats | Gauge | APF 當前在執行的席位元量,表示某個優先順序隊列中當前正在執行的請求數對應的席位元量,反映了當前隊列中正在消耗的並發資源。供您瞭解隊列的實際負載情況。 如果 current_executing_seats 接近 current_limit_seats,表明該隊列的並發資源可能即將耗盡。 您可以提升API Server的maxMutatingRequestsInflight和maxRequestsInflight的參數取值以最佳化配置。操作入口及參數取值,請參見自訂Pro版叢集的控制面組件參數。 |
apiserver_flowcontrol_current_inqueue_seats | Gauge | APF當前隊列中席位元量,表示某個優先順序隊列中當前等待處理的請求數對應的席位元量,反映了當前隊列中等待處理的請求所佔用的資源,以供您瞭解隊列的積壓情況。 |
apiserver_flowcontrol_request_execution_seconds_bucket | Histogram | 請求的實際執行時間,記錄了請求從開始執行到最終完成所花費的時間。 時間區間分布為{0, 0.005, 0.02, 0.05, 0.1, 0.2, 0.5, 1, 2, 5, 10, 15, 30}。單位:秒。 |
apiserver_flowcontrol_request_wait_duration_seconds_bucket | Histogram | 請求在隊列中等待的時間分布,記錄了請求從進入隊列到開始執行之間的等待時間 時間區間分布為{0, 0.005, 0.02, 0.05, 0.1, 0.2, 0.5, 1, 2, 5, 10, 15, 30}。單位:秒。 |
apiserver_flowcontrol_dispatched_requests_total | Counter | 成功調度並處理的請求數量,反映了API Server成功處理的請求總數。 |
apiserver_flowcontrol_rejected_requests_total | Counter | 因超出並發限制或隊列容量而被拒絕的請求數量。 |
apiserver_admission_controller_admission_duration_seconds_bucket | Histogram | 准入控制器(Admission Controller)的處理延時。標籤包括Admission Controller名稱、操作(CREATE、UPDATE、CONNECT等)、API資源、操作類型(validate或admit)和請求是否被拒絕(true或false)。 Bucket閾值為 |
apiserver_admission_webhook_admission_duration_seconds_bucket | Histogram | 准入Webhook(Admission Webhook)的處理延時。標籤包括Admission Controller名稱、操作(CREATE、UPDATE、CONNECT等)、API資源、操作類型(validate,校正請求的合法性,或admit,在請求合法的情況下,決定是否允許該請求)和請求是否被拒絕(true或false)。 Bucket的閾值為 |
apiserver_admission_webhook_admission_duration_seconds_count | Counter | 准入Webhook(Admission Webhook)的處理請求統計。標籤包括Admission Controller名稱、操作(CREATE、UPDATE、CONNECT等)、API資源、操作類型(validate或admit)和請求是否被拒絕(true或false)。 |
cpu_utilization_core | Gauge | CPU使用量。單位:核(Core)。 |
memory_utilization_byte | Gauge | 記憶體使用量量。單位:位元組(Byte)。 |
up | Gauge | 服務可用性。
|
如下資源使用率指標已廢棄,請及時去除依賴該指標的警示和監控。
cpu_utilization_ratio:CPU使用率。
memory_utilization_ratio:記憶體使用量率。
大盤使用指導
大盤基於組件指標和相關PromQL繪製,包括關鍵計量、概覽、資源分析、QPS和時延、准入控制器和Webhook、用戶端分析部分。
篩選框
在大盤上方,您可以根據篩選框配置觀測API Server請求的Verb、資源(Resource)、分位元(Quantile)和面板使用的PromQL的採樣時間長度(Interval)。
調整分位元(Quantile)時,以0.9為例,表示大盤上Histogram類型指標的採樣值的數量占該類型指標總體採樣值的90%。分位元為0.9(簡稱為P90)的指標可以去除採樣值佔比小的長尾樣本的影響,分位元為0.99(簡稱為P99)的指標會包含長尾樣本的影響。

以下篩選框可以選擇觀測的時間段和頁面重新整理周期。
關鍵計量
可觀測性展示
功能解析
名稱 | PromQL | 說明 |
API QPS | sum(irate(apiserver_request_total[$interval])) | API Server的總QPS。 |
讀請求成功率 | sum(irate(apiserver_request_total{code=~"20.*",verb=~"GET|LIST"}[$interval]))/sum(irate(apiserver_request_total{verb=~"GET|LIST"}[$interval])) | API Server處理讀請求的成功率。 |
寫請求成功率 | sum(irate(apiserver_request_total{code=~"20.*",verb!~"GET|LIST|WATCH|CONNECT"}[$interval]))/sum(irate(apiserver_request_total{verb!~"GET|LIST|WATCH|CONNECT"}[$interval])) | API Server處理寫請求的成功率。 |
在處理讀請求數量 | sum(apiserver_current_inflight_requests{requestKind="readOnly"}) | API Server當前在處理的讀請求數量。 |
在處理寫請求數量 | sum(apiserver_current_inflight_requests{requestKind="mutating"}) | API Server當前在處理的寫請求數量。 |
請求限流速率 | sum(irate(apiserver_dropped_requests_total[$interval])) | Dropped Request Rate。 API Server限流策略過程中,主動丟棄掉的請求數所佔總請求數的比例。 |
概覽
可觀測性展示
功能解析
名稱 | 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。 |
在處理讀請求數量 | apiserver_current_inflight_requests{request_kind="readOnly"} | API Server正在處理的讀請求數量。 |
在處理寫請求數量 | apiserver_current_inflight_requests{request_kind="mutating"} | API Server正在處理的寫請求數量。 |
請求限流速率 | 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的限流速率 , |
資源分析
可觀測性展示
功能解析
名稱 | PromQL | 說明 |
記憶體使用量量 | memory_utilization_byte{container="kube-apiserver"} | API Server的記憶體使用量量。單位:位元組。 |
CPU使用量 | cpu_utilization_core{container="kube-apiserver"}*1000 | API Server的CPU使用量。單位:毫核。 |
資來源物件數量 |
|
說明 由於相容性問題,1.22版本中apiserver_storage_objects名稱和etcd_object_counts名稱均存在。 |
QPS和時延
可觀測性展示
功能解析
名稱 | PromQL | 說明 |
按Verb維度分析QPS | sum(irate(apiserver_request_total{verb=~"$verb"}[$interval]))by(verb) | 按Verb維度,統計單位時間(1s)內的請求QPS。 |
按Verb+Resource維度分析QPS | sum(irate(apiserver_request_total{verb=~"$verb",resource=~"$resource"}[$interval]))by(verb,resource) | 按Verb+Resource維度,統計單位時間(1s)內的請求QPS。 |
按Verb維度分析請求時延 | histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb=~"$verb", verb!~"WATCH|CONNECT",resource!=""}[$interval])) by (le,verb)) | 按Verb維度,分析請求時延。 |
按Verb+Resource維度分析請求時延 | histogram_quantile($quantile, sum(irate(apiserver_request_duration_seconds_bucket{verb=~"$verb", verb!~"WATCH|CONNECT", resource=~"$resource",resource!=""}[$interval])) by (le,verb,resource)) | 按Verb+Resource維度,分析請求時延。 |
非2xx傳回值的讀請求QPS | sum(irate(apiserver_request_total{verb=~"GET|LIST",resource=~"$resource",code!~"2.*"}[$interval])) by (verb,resource,code) | 統計非2xx傳回值(除成功以外的所有情況,例如4xx、5xx等)的讀請求QPS。 |
非2xx傳回值的寫請求QPS | sum(irate(apiserver_request_total{verb!~"GET|LIST|WATCH",verb=~"$verb",resource=~"$resource",code!~"2.*"}[$interval])) by (verb,resource,code) | 統計非2xx傳回值(除成功以外的所有情況,例如4xx、5xx等)的寫請求QPS。 |
Apiserver對etcd請求時延 | histogram_quantile($quantile, sum(irate(etcd_request_duration_seconds_bucket[$interval])) by (le,operation,type,instance)) | 統計API Server對etcd的請求時延。 |
APF限流
APF限流相關指標監控處於灰階發布中。
APF相關指標僅支援1.20及以上版本叢集。如需升級,請參見手動升級叢集。
APF相關指標大盤還依賴如下組件的升級,請參見組件監控升級說明完成升級:
容器叢集監控組件:0.06及以上版本。
ack-arms-prometheus組件:v1.1.31及以上版本。
託管探針:v1.1.31及以上版本。
可觀測性展示


功能解析
下表中部分指標按PL、Instance、FS維度進行統計。
PL:Priority Level維度,即根據不同優先順序進行統計。
Instance:根據API Server執行個體維度進行統計。
FS:Flow Schema維度,即根據請求分類進行統計。
關於APF及上述維度詳細資料,請參見APF。
名稱 | PromQL | 說明 |
APF 請求並發限制(維度:PL) | sum by(priority_level) (apiserver_flowcontrol_request_concurrency_limit) | 按 PL 或 Instance + PL 維度統計 APF 請求並發限制,即某個優先順序隊列理論上允許同時處理的最大請求數。 apiserver_flowcontrol_request_concurrency_limit 在Kubernetes 1.30版本變為Deprecated,自1.31版本起移除,1.31及以上版本的叢集中建議使用apiserver_flowcontrol_nominal_limit_seats指標代替。 |
APF 請求並發限制(維度:Instance + PL) | sum by(instance,priority_level) (apiserver_flowcontrol_request_concurrency_limit) | |
APF 當前執行請求數量(維度:FS + PL) | sum by(flow_schema,priority_level) (apiserver_flowcontrol_current_executing_requests) | 按 FS + PL 或 Instance + FS + PL 維度統計 APF 當前正在執行的請求數量。 |
APF 當前執行請求數量(維度:Instance + FS + PL) | sum by(instance,flow_schema,priority_level)(apiserver_flowcontrol_current_executing_requests) | |
APF當前在隊列中待處理請求數量(維度:FS + PL) | sum by(flow_schema,priority_level) (apiserver_flowcontrol_current_inqueue_requests) | 按 FS + PL 或 Instance + FS + PL 維度統計當前隊列中待處理的請求數量。 |
APF 當前隊列中待處理請求數量(維度:Instance + FS + PL) | sum by(instance,flow_schema,priority_level) (apiserver_flowcontrol_current_inqueue_requests) | |
APF 名義並發限制席位元量 | sum by(instance,priority_level) (apiserver_flowcontrol_nominal_limit_seats) | 按 Instance + PL 維度統計APF席位元量的相關指標。包括以下指標:
|
APF 當前並發限制席位元量 | sum by(instance,priority_level) (apiserver_flowcontrol_current_limit_seats) | |
APF 當前在執行的席位元量 | sum by(instance,priority_level) (apiserver_flowcontrol_current_executing_seats) | |
APF 當前隊列中席位元量 | sum by(instance,priority_level) (apiserver_flowcontrol_current_inqueue_seats) | |
APF 請求執行時間 | histogram_quantile($quantile, sum(irate(apiserver_flowcontrol_request_execution_seconds_bucket[$interval])) by (le,instance, flow_schema,priority_level)) | 請求從開始執行到最終完成所花費的時間。 |
APF 請求等待時間 | histogram_quantile($quantile, sum(irate(apiserver_flowcontrol_request_wait_seconds_bucket[$interval])) by (le,instance, flow_schema,priority_level)) | 請求從進入隊列到開始執行之間的等待時間。 |
APF 成功調度並處理的請求QPS | sum(irate(apiserver_flowcontrol_dispatched_requests_total[$interval]))by(instance,flow_schema,priority_level) | 成功調度並處理的請求QPS。 |
APF 拒絕請求QPS | sum(irate(apiserver_flowcontrol_rejected_requests_total[$interval]))by(instance,flow_schema,priority_level) | 因超出並發限制或隊列容量而被拒絕的請求QPS。 |
准入控制器和Webhook
可觀測性展示
功能解析
名稱 | PromQL | 說明 |
准入控制器時延[admit] | histogram_quantile($quantile, sum by(operation, name, le, type, rejected) (irate(apiserver_admission_controller_admission_duration_seconds_bucket{type="admit"}[$interval])) ) | 使用到的admit類型的Admission Controller名稱、操作、是否拒絕以及相應的執行時間。 指標Bucket的閾值為 |
准入控制器時延[validate] | histogram_quantile($quantile, sum by(operation, name, le, type, rejected) (irate(apiserver_admission_controller_admission_duration_seconds_bucket{type="validate"}[$interval])) ) | 使用到的validate類型的Admission Controller名稱、操作、是否拒絕以及相應的執行時間。 指標Bucket的閾值為 |
准入Webhook時延[admit] | histogram_quantile($quantile, sum by(operation, name, le, type, rejected) (irate(apiserver_admission_webhook_admission_duration_seconds_bucket{type="admit"}[$interval])) ) | 使用到的admit類型的Webhook名稱、操作、是否拒絕以及相應的執行時間。 指標Bucket的閾值為 |
准入Webhook時延[validating] | histogram_quantile($quantile, sum by(operation, name, le, type, rejected) (irate(apiserver_admission_webhook_admission_duration_seconds_bucket{type="validating"}[$interval])) ) | 使用到的admit類型的Webhook名稱、操作、是否拒絕以及相應的執行時間。 指標Bucket的閾值為 |
准入Webhook請求QPS | sum(irate(apiserver_admission_webhook_admission_duration_seconds_count[$interval]))by(name,operation,type,rejected) | 准入Webhook的請求QPS。 |
用戶端分析
可觀測性展示
功能解析
名稱 | PromQL | 說明 |
按Client維度分析QPS | sum(irate(apiserver_request_total{client!=""}[$interval])) by (client) | 按Client維度分析QPS。用於分析訪問API Server的用戶端以及QPS。 |
按Verb+Resource+Client維度分析QPS | sum(irate(apiserver_request_total{client!="",verb=~"$verb", resource=~"$resource"}[$interval]))by(verb,resource,client) | 按Verb+Resource+Client維度分析QPS。 |
按Verb+Resource+Client維度分析LIST請求QPS(無resourceVersion欄位) | sum(irate(apiserver_request_no_resourceversion_list_total[$interval]))by(resource,client) |
|
常見指標異常
如果組件的常見指標異常,請對照下文的情況說明排查是否為預期內情況。
讀/寫請求成功率
情況說明
正常情況 | 異常情況 | 說明 |
讀請求成功率和寫請求成功率接近100%。 | 讀請求成功率和寫請求成功率維持在較低百分比,例如小於90%。 | 存在較多非200傳回值請求。 |
推薦解決方案
查看面板,定位非2xx傳回值的讀請求QPS和非2xx傳回值的寫請求 QPS中導致非200傳回值請求類型和資源。請評估該類請求是否符合預期,並隨之採取措施進行最佳化。例如,如果有GET/deployment 404,表示存在GET Deployment返回404的請求,會導致讀請求成功率降低,請判斷是否為預期行為。
GET/LIST讀請求時延和寫請求時延
情況說明
正常情況 | 異常情況 | 說明 |
GET讀請求時延、LIST讀請求時延、寫請求時延與訪問的叢集資源數量和叢集規模相關聯,沒有固定的正常與異常的時間分界,只要不影響業務即在接受範圍內。例如,如果訪問的某種資源量越大,那麼LIST請求時間就會越長。一般情況下,GET讀請求時延、寫請求時延小於1s,LIST讀請求時延小於5s,為正常現象。 |
| 請求的響應時延過長時,需要排除叢集資源數量多、Webhook調用慢等因素的影響。 |
推薦解決方案
查看面板,定位GET讀請求時延、LIST讀請求時延、寫請求時延中導致非200傳回值的請求類型和資源,並採取解決措施。
請求延時指標
apiserver_request_duration_seconds_bucket的最大閾值是60s,超過60s的請求都會統計為60s。而登入Pod的請求POST pod/exec、讀取日誌的請求會建立長連結,該類請求時間通常會超過60s。問題定位時,您可忽略該類請求。
參見准入Webhook時延,分析是否由於Webhook執行較慢,導致API Server請求延時間長度。
在處理讀/寫請求數量和請求限流速率
情況說明
正常情況 | 異常情況 | 說明 |
通常情況下,在處理讀請求數量和在處理寫請求數量小於100,請求限流速率為0,為正常現象。 |
| 當前在處理請求的隊列積壓時,需要排除短時請求量湧入導致處理延時、Webhook調用慢等因素的影響。超過隊列長度時,API Server會限流,導致請求限流速率大於0,影響叢集穩定性。 |
推薦解決方案
查看QPS和時延和用戶端分析,分析請求中佔比位於頭部的請求,評估是否符合預期。如果請求為實際業務發起,您可以判斷是否需降低請求量。
參見准入Webhook時延,分析是否因為Webhook執行慢導致API Server請求處理慢。
准入Webhook時延
情況說明
正常情況 | 異常情況 | 說明 |
准入Webhook時延小於0.5s。 | 持續出現准入Webhook時延大於0.5s。 | Webhook響應慢會影響API Server的響應時延。 |
推薦解決方案
排查Webhook日誌等資訊,判斷是否符合預期。如果不需要某個Webhook,請卸載。
相關文檔
關於其他叢集控制面組件監控的指標詳情、大盤使用指引和常見指標異常說明,請參見:
關於如何通過控制台或API擷取Prometheus監控資料,請參見通過PromQL查詢Prometheus監控資料。
關於如何通過阿里雲Prometheus監控自訂PromQL配置警示規則,請參見建立Prometheus警示規則。