建站
咨詢
售后
建站咨詢
新聞中心
API 優(yōu)先級和公平性
FEATURE STATE: Kubernetes v1.20 [beta]
目前成都創(chuàng)新互聯(lián)已為千余家的企業(yè)提供了網(wǎng)站建設(shè)、域名、網(wǎng)絡(luò)空間、成都網(wǎng)站托管、企業(yè)網(wǎng)站設(shè)計、東安網(wǎng)站維護(hù)等服務(wù)，公司將堅持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。
對于集群管理員來說，控制 Kubernetes API 服務(wù)器在過載情況下的行為是一項關(guān)鍵任務(wù)。 kube-apiserver 有一些控件（例如：命令行標(biāo)志 ?--max-requests-inflight? 和 ?--max-mutating-requests-inflight? ）, 可以限制將要接受的未處理的請求，從而防止過量請求入站，潛在導(dǎo)致 API 服務(wù)器崩潰。 但是這些標(biāo)志不足以保證在高流量期間，最重要的請求仍能被服務(wù)器接受。
API 優(yōu)先級和公平性（APF）是一種替代方案，可提升上述最大并發(fā)限制。 APF 以更細(xì)粒度的方式對請求進(jìn)行分類和隔離。 它還引入了空間有限的排隊機(jī)制，因此在非常短暫的突發(fā)情況下，API 服務(wù)器不會拒絕任何請求。 通過使用公平排隊技術(shù)從隊列中分發(fā)請求，這樣， 一個行為不佳的 控制器 就不會餓死其他控制器（即使優(yōu)先級相同）。
本功能特性在設(shè)計上期望其能與標(biāo)準(zhǔn)控制器一起工作得很好； 這類控制器使用通知組件（Informers）獲得信息并對 API 請求的失效作出反應(yīng)， 在處理失效時能夠執(zhí)行指數(shù)型回退。其他客戶端也以類似方式工作。
Caution: 屬于“長時間運(yùn)行”類型的請求（主要是 watch）不受 API 優(yōu)先級和公平性過濾器的約束。 如果未啟用 APF 特性，即便設(shè)置 ?
--max-requests-inflight? 標(biāo)志，該類請求也不受約束。
啟用/禁用 API 優(yōu)先級和公平性
API 優(yōu)先級與公平性（APF）特性由特性門控控制，默認(rèn)情況下啟用。 有關(guān)特性門控的一般性描述以及如何啟用和禁用特性門控， 請參見特性門控。 APF 的特性門控稱為 ?APIPriorityAndFairness?。 此特性也與某個 API 組 相關(guān)： (a) ?v1alpha1 ?版本，默認(rèn)被禁用； (b) ?v1beta1 ?和 ?v1beta2 ?版本，默認(rèn)被啟用。 你可以在啟動 ?kube-apiserver? 時，添加以下命令行標(biāo)志來禁用此功能門控及 API Beta 組：
kube-apiserver \
--feature-gates=APIPriorityAndFairness=false \
--runtime-config=flowcontrol.apiserver.K8S.io/v1beta1=false,flowcontrol.apiserver.k8s.io/v1beta2=false \
# ...其他配置不變 或者，你也可以通過 ?--runtime-config=flowcontrol.apiserver.k8s.io/v1alpha1=true? 啟用 API 組的 v1alpha1 版本。
命令行標(biāo)志 ?--enable-priority-fairness=false? 將徹底禁用 APF 特性，即使其他標(biāo)志啟用它也是無效。
概念
APF 特性包含幾個不同的功能。 傳入的請求通過 FlowSchema 按照其屬性分類，并分配優(yōu)先級。 每個優(yōu)先級維護(hù)自定義的并發(fā)限制，加強(qiáng)了隔離度，這樣不同優(yōu)先級的請求，就不會相互餓死。 在同一個優(yōu)先級內(nèi)，公平排隊算法可以防止來自不同 flow 的請求相互餓死。 該算法將請求排隊，通過排隊機(jī)制，防止在平均負(fù)載較低時，通信量突增而導(dǎo)致請求失敗。
優(yōu)先級
如果未啟用 APF，API 服務(wù)器中的整體并發(fā)量將受到 ?kube-apiserver? 的參數(shù) ?--max-requests-inflight? 和 ?--max-mutating-requests-inflight? 的限制。 啟用 APF 后，將對這些參數(shù)定義的并發(fā)限制進(jìn)行求和，然后將總和分配到一組可配置的 優(yōu)先級 中。 每個傳入的請求都會分配一個優(yōu)先級；每個優(yōu)先級都有各自的配置，設(shè)定允許分發(fā)的并發(fā)請求數(shù)。
例如，默認(rèn)配置包括針對領(lǐng)導(dǎo)者選舉請求、內(nèi)置控制器請求和 Pod 請求都單獨(dú)設(shè)置優(yōu)先級。 這表示即使異常的 Pod 向 API 服務(wù)器發(fā)送大量請求，也無法阻止領(lǐng)導(dǎo)者選舉或內(nèi)置控制器的操作執(zhí)行成功。
排隊
即使在同一優(yōu)先級內(nèi)，也可能存在大量不同的流量源。 在過載情況下，防止一個請求流餓死其他流是非常有價值的 （尤其是在一個較為常見的場景中，一個有故障的客戶端會瘋狂地向 kube-apiserver 發(fā)送請求， 理想情況下，這個有故障的客戶端不應(yīng)對其他客戶端產(chǎn)生太大的影響）。 公平排隊算法在處理具有相同優(yōu)先級的請求時，實(shí)現(xiàn)了上述場景。 每個請求都被分配到某個 流 中，該 流 由對應(yīng)的 FlowSchema 的名字加上一個 流區(qū)分項（Flow Distinguisher） 來標(biāo)識。 這里的流區(qū)分項可以是發(fā)出請求的用戶、目標(biāo)資源的名稱空間或什么都不是。 系統(tǒng)嘗試為不同流中具有相同優(yōu)先級的請求賦予近似相等的權(quán)重。 要啟用對不同實(shí)例的不同處理方式，多實(shí)例的控制器要分別用不同的用戶名來執(zhí)行身份認(rèn)證。
將請求劃分到流中之后，APF 功能將請求分配到隊列中。 分配時使用一種稱為 混洗分片（Shuffle-Sharding） 的技術(shù)。 該技術(shù)可以相對有效地利用隊列隔離低強(qiáng)度流與高強(qiáng)度流。
排隊算法的細(xì)節(jié)可針對每個優(yōu)先等級進(jìn)行調(diào)整，并允許管理員在內(nèi)存占用、 公平性（當(dāng)總流量超標(biāo)時，各個獨(dú)立的流將都會取得進(jìn)展）、 突發(fā)流量的容忍度以及排隊引發(fā)的額外延遲之間進(jìn)行權(quán)衡。
豁免請求
某些特別重要的請求不受制于此特性施加的任何限制。這些豁免可防止不當(dāng)?shù)牧骺嘏渲猛耆?nbsp;API 服務(wù)器。
資源
流控 API 涉及兩種資源。 PriorityLevelConfigurations 定義隔離類型和可處理的并發(fā)預(yù)算量，還可以微調(diào)排隊行為。 FlowSchemas 用于對每個入站請求進(jìn)行分類，并與一個 PriorityLevelConfigurations 相匹配。 此外同一 API 組還有一個 ?v1alpha1 ?版本，其中包含語法和語義都相同的資源類別。
PriorityLevelConfiguration
一個 PriorityLevelConfiguration 表示單個隔離類型。每個 PriorityLevelConfigurations 對未完成的請求數(shù)有各自的限制，對排隊中的請求數(shù)也有限制。
PriorityLevelConfigurations 的并發(fā)限制不是指定請求絕對數(shù)量，而是在“并發(fā)份額”中指定。 API 服務(wù)器的總并發(fā)量限制通過這些份額按例分配到現(xiàn)有 PriorityLevelConfigurations 中。 集群管理員可以更改 ?--max-requests-inflight? （或 ?--max-mutating-requests-inflight? ）的值， 再重新啟動 ?kube-apiserver? 來增加或減小服務(wù)器的總流量， 然后所有的 PriorityLevelConfigurations 將看到其最大并發(fā)增加（或減少）了相同的比例。
Caution: 啟用 APF 功能后，服務(wù)器的總并發(fā)量限制將設(shè)置為 ?
--max-requests-inflight? 和 ?
--max-mutating-requests-inflight? 之和。 可變請求和不可變請求之間不再有任何區(qū)別； 如果對于某種資源，你需要區(qū)別對待不同請求，請創(chuàng)建不同的 FlowSchema 分別匹配可變請求和不可變請求。
當(dāng)入站請求的數(shù)量大于分配的 PriorityLevelConfigurations 中允許的并發(fā)級別時， ?type ?字段將確定對額外請求的處理方式。 ?Reject ?類型，表示多余的流量將立即被 HTTP 429（請求過多）錯誤所拒絕。 ?Queue ?類型，表示對超過閾值的請求進(jìn)行排隊，將使用閾值分片和公平排隊技術(shù)來平衡請求流之間的進(jìn)度。
公平排隊算法支持通過排隊配置對優(yōu)先級微調(diào)：
- ?
queues?遞增能減少不同流之間的沖突概率，但代價是增加了內(nèi)存使用量。 值為 1 時，會禁用公平排隊邏輯，但仍允許請求排隊。 - ?
queueLengthLimit?遞增可以在不丟棄任何請求的情況下支撐更大的突發(fā)流量， 但代價是增加了等待時間和內(nèi)存使用量。 - 修改 ?
handSize?允許你調(diào)整過載情況下不同流之間的沖突概率以及單個流可用的整體并發(fā)性。
Note: 較大的 ?
handSize?使兩個單獨(dú)的流程發(fā)生碰撞的可能性較小（因此，一個流可以餓死另一個流）， 但是更有可能的是少數(shù)流可以控制 apiserver。 較大的 ?
handSize?還可能增加單個高并發(fā)流的延遲量。 單個流中可能排隊的請求的最大數(shù)量為 ?
handSize * queueLengthLimit? 。
下表顯示了有趣的隨機(jī)分片配置集合， 每行顯示給定的老鼠（低強(qiáng)度流）被不同數(shù)量的大象擠壓（高強(qiáng)度流）的概率。 表來源請參閱： https://play.golang.org/p/Gi0PLgVHiUg
| 隨機(jī)分片 | 隊列數(shù) | 1 個大象 | 4 個大象 | 16 個大象 |
|---|---|---|---|---|
| 12 | 32 | 4.428838398950118e-09 | 0.11431348830099144 | 0.9935089607656024 |
| 10 | 32 | 1.550093439632541e-08 | 0.0626479840223545 | 0.9753101519027554 |
| 10 | 64 | 6.601827268370426e-12 | 0.00045571320990370776 | 0.49999929150089345 |
| 9 | 64 | 3.6310049976037345e-11 | 0.00045501212304112273 | 0.4282314876454858 |
| 8 | 64 | 2.25929199850899e-10 | 0.0004886697053040446 | 0.35935114681123076 |
| 8 | 128 | 6.994461389026097e-13 | 3.4055790161620863e-06 | 0.02746173137155063 |
| 7 | 128 | 1.0579122850901972e-11 | 6.960839379258192e-06 | 0.02406157386340147 |
| 7 | 256 | 7.597695465552631e-14 | 6.728547142019406e-08 | 0.0006709661542533682 |
| 6 | 256 | 2.7134626662687968e-12 | 2.9516464018476436e-07 | 0.0008895654642000348 |
| 6 | 512 | 4.116062922897309e-14 | 4.982983350480894e-09 | 2.26025764343413e-05 |
| 6 | 1024 | 6.337324016514285e-16 | 8.09060164312957e-11 | 4.517408062903668e-07 |
FlowSchema
FlowSchema 匹配一些入站請求，并將它們分配給優(yōu)先級。 每個入站請求都會對所有 FlowSchema 測試是否匹配， 首先從 ?matchingPrecedence ?數(shù)值最低的匹配開始（我們認(rèn)為這是邏輯上匹配度最高）， 然后依次進(jìn)行，直到首個匹配出現(xiàn)。
Caution: 對一個請求來說，只有首個匹配的 FlowSchema 才有意義。 如果一個入站請求與多個 FlowSchema 匹配，則將基于 ?
matchingPrecedence?值最高的請求進(jìn)行篩選。 如果一個請求匹配多個 FlowSchema 且 ?
matchingPrecedence?的值相同，則按 ?
name?的字典序選擇最小， 但是最好不要依賴它，而是確保不存在兩個 FlowSchema 具有相同的 ?
matchingPrecedence?值。
當(dāng)給定的請求與某個 FlowSchema 的 ?rules ?的其中一條匹配，那么就認(rèn)為該請求與該 FlowSchema 匹配。 判斷規(guī)則與該請求是否匹配，不僅要求該條規(guī)則的 ?subjects ?字段至少存在一個與該請求相匹配， 而且要求該條規(guī)則的 ?resourceRules ?或 ?nonResourceRules ?（取決于傳入請求是針對資源URL還是非資源URL）字段至少存在一個與該請求相匹配。
對于 ?subjects ?中的 ?name ?字段和資源和非資源規(guī)則的 ?verbs?，?apiGroups?，?resources?，?namespaces ?和 ?nonResourceURLs ?字段， 可以指定通配符 ?*? 來匹配任意值，從而有效地忽略該字段。
FlowSchema 的 ?distinguisherMethod.type? 字段決定了如何把與該模式匹配的請求分散到各個流中。 可能是 ?ByUser ?，在這種情況下，一個請求用戶將無法餓死其他容量的用戶； 或者是 ?ByNamespace ?，在這種情況下，一個名稱空間中的資源請求將無法餓死其它名稱空間的資源請求； 或者它可以為空（或者可以完全省略 ?distinguisherMethod?）， 在這種情況下，與此 FlowSchema 匹配的請求將被視為單個流的一部分。 資源和你的特定環(huán)境決定了如何選擇正確一個 FlowSchema。
默認(rèn)值
每個 kube-apiserver 會維護(hù)兩種類型的 APF 配置對象：強(qiáng)制的（Mandatory）和建議的（Suggested）。
強(qiáng)制的配置對象
有四種強(qiáng)制的配置對象對應(yīng)內(nèi)置的守護(hù)行為。這里的行為是服務(wù)器在還未創(chuàng)建對象之前就具備的行為， 而當(dāng)這些對象存在時，其規(guī)約反映了這類行為。四種強(qiáng)制的對象如下：
- 強(qiáng)制的 ?
exempt?優(yōu)先級用于完全不受流控限制的請求：它們總是立刻被分發(fā)。 強(qiáng)制的 ?exempt?FlowSchema 把 ?system:masters? 組的所有請求都?xì)w入該優(yōu)先級。 如果合適，你可以定義新的 FlowSchema，將其他請求定向到該優(yōu)先級。 - 強(qiáng)制的 ?
catch-all? 優(yōu)先級與強(qiáng)制的 ?catch-all? FlowSchema 結(jié)合使用， 以確保每個請求都分類。一般而言，你不應(yīng)該依賴于 ?catch-all? 的配置， 而應(yīng)適當(dāng)?shù)貏?chuàng)建自己的 ?catch-all? FlowSchema 和 PriorityLevelConfiguration （或使用默認(rèn)安裝的 ?global-default? 配置）。 因?yàn)檫@一優(yōu)先級不是正常場景下要使用的，?catch-all? 優(yōu)先級的并發(fā)度份額很小， 并且不會對請求進(jìn)行排隊。
建議的配置對象
建議的 FlowSchema 和 PriorityLevelConfiguration 包含合理的默認(rèn)配置。 你可以修改這些對象或者根據(jù)需要創(chuàng)建新的配置對象。如果你的集群可能承受較重負(fù)載， 那么你就要考慮哪種配置最合適。
建議的配置把請求分為六個優(yōu)先級：
- ?
node-high? 優(yōu)先級用于來自節(jié)點(diǎn)的健康狀態(tài)更新。 - ?
system?優(yōu)先級用于 ?system:nodes? 組（即 kubelet）的與健康狀態(tài)更新無關(guān)的請求； kubelets 必須能連上 API 服務(wù)器，以便工作負(fù)載能夠調(diào)度到其上。 - ?
leader-election? 優(yōu)先級用于內(nèi)置控制器的領(lǐng)導(dǎo)選舉的請求 （特別是來自 ?kube-system? 名稱空間中 ?system:kube-controller-manager? 和 ?system:kube-scheduler? 用戶和服務(wù)賬號，針對 ?endpoints?、?configmaps?或 ?leases?的請求）。 將這些請求與其他流量相隔離非常重要，因?yàn)轭I(lǐng)導(dǎo)者選舉失敗會導(dǎo)致控制器發(fā)生故障并重新啟動， 這反過來會導(dǎo)致新啟動的控制器在同步信息時，流量開銷更大。 - ?
workload-high? 優(yōu)先級用于內(nèi)置控制器的其他請求。 - ?
workload-low? 優(yōu)先級用于來自所有其他服務(wù)帳戶的請求，通常包括來自 Pod 中運(yùn)行的控制器的所有請求。 - ?
global-default? 優(yōu)先級可處理所有其他流量，例如：非特權(quán)用戶運(yùn)行的交互式 ?kubectl?命令。
建議的 FlowSchema 用來將請求導(dǎo)向上述的優(yōu)先級內(nèi)，這里不再一一列舉。
強(qiáng)制的與建議的配置對象的維護(hù)
每個 ?kube-apiserver? 都獨(dú)立地維護(hù)其強(qiáng)制的與建議的配置對象， 這一維護(hù)操作既是服務(wù)器的初始行為，也是其周期性操作的一部分。 因此，當(dāng)存在不同版本的服務(wù)器時，如果各個服務(wù)器對于配置對象中的合適內(nèi)容有不同意見， 就可能出現(xiàn)抖動。
每個 ?kube-apiserver? 都會對強(qiáng)制的與建議的配置對象執(zhí)行初始的維護(hù)操作， 之后（每分鐘）對這些對象執(zhí)行周期性的維護(hù)。
對于強(qiáng)制的配置對象，維護(hù)操作包括確保對象存在并且包含合適的規(guī)約（如果存在的話）。 服務(wù)器會拒絕創(chuàng)建或更新與其守護(hù)行為不一致的規(guī)約。
對建議的配置對象的維護(hù)操作被設(shè)計為允許其規(guī)約被重載。刪除操作是不允許的， 維護(hù)操作期間會重建這類配置對象。如果你不需要某個建議的配置對象， 你需要將它放在一邊，并讓其規(guī)約所產(chǎn)生的影響最小化。 對建議的配置對象而言，其維護(hù)方面的設(shè)計也支持在上線新的 ?kube-apiserver? 時完成自動的遷移動作，即便可能因?yàn)楫?dāng)前的服務(wù)器集合存在不同的版本而可能造成抖動仍是如此。
對建議的配置對象的維護(hù)操作包括基于服務(wù)器建議的規(guī)約創(chuàng)建對象 （如果對象不存在的話）。反之，如果對象已經(jīng)存在，維護(hù)操作的行為取決于是否 ?kube-apiserver? 或者用戶在控制對象。如果 ?kube-apiserver? 在控制對象， 則服務(wù)器確保對象的規(guī)約與服務(wù)器所給的建議匹配，如果用戶在控制對象， 對象的規(guī)約保持不變。
關(guān)于誰在控制對象這個問題，首先要看對象上的 ?apf.kubernetes.io/autoupdate-spec? 注解。如果對象上存在這個注解，并且其取值為?true?，則 kube-apiserver 在控制該對象。如果存在這個注解，并且其取值為?false?，則用戶在控制對象。 如果這兩個條件都不滿足，則需要進(jìn)一步查看對象的 ?metadata.generation?。 如果該值為 1，則 kube-apiserver 控制對象，否則用戶控制對象。 這些規(guī)則是在 1.22 發(fā)行版中引入的，而對 ?metadata.generation? 的考量是為了便于從之前較簡單的行為遷移過來。希望控制建議的配置對象的用戶應(yīng)該將對象的 ?apf.kubernetes.io/autoupdate-spec? 注解設(shè)置為 ?false?。
對強(qiáng)制的或建議的配置對象的維護(hù)操作也包括確保對象上存在 ?apf.kubernetes.io/autoupdate-spec? 這一注解，并且其取值準(zhǔn)確地反映了是否 kube-apiserver 在控制著對象。
維護(hù)操作還包括刪除那些既非強(qiáng)制又非建議的配置，同時注解配置為 ?apf.kubernetes.io/autoupdate-spec=true? 的對象。
健康檢查并發(fā)豁免
推薦配置沒有為本地 kubelet 對 kube-apiserver 執(zhí)行健康檢查的請求進(jìn)行任何特殊處理 ——它們傾向于使用安全端口，但不提供憑據(jù)。 在推薦配置中，這些請求將分配 ?global-default? FlowSchema 和 ?global-default? 優(yōu)先級， 這樣其他流量可以排除健康檢查。
如果添加以下 FlowSchema，健康檢查請求不受速率限制。
Caution: 進(jìn)行此更改后，任何敵對方都可以發(fā)送與此 FlowSchema 匹配的任意數(shù)量的健康檢查請求。 如果你有 Web 流量過濾器或類似的外部安全機(jī)制保護(hù)集群的 API 服務(wù)器免受常規(guī)網(wǎng)絡(luò)流量的侵?jǐn)_， 則可以配置規(guī)則，阻止所有來自集群外部的健康檢查請求。
apiVersion: flowcontrol.apiserver.k8s.io/v1beta2
kind: FlowSchema
metadata:
name: health-for-strangers
spec:
matchingPrecedence: 1000
priorityLevelConfiguration:
name: exempt
rules:
- nonResourceRules:
- nonResourceURLs:
- "/healthz"
- "/livez"
- "/readyz"
verbs:
- "*"
subjects:
- kind: Group
group:
name: system:unauthenticated
問題診斷
啟用了 APF 的 API 服務(wù)器，它每個 HTTP 響應(yīng)都有兩個額外的 HTTP 頭： ?X-Kubernetes-PF-FlowSchema-UID? 和 ?X-Kubernetes-PF-PriorityLevel-UID?， 注意與請求匹配的 FlowSchema 和已分配的優(yōu)先級。 如果請求用戶沒有查看這些對象的權(quán)限，則這些 HTTP 頭中將不包含 API 對象的名稱， 因此在調(diào)試時，你可以使用類似如下的命令：
kubectl get flowschemas -o custom-columns="uid:{metadata.uid},name:{metadata.name}"
kubectl get prioritylevelconfigurations -o custom-columns="uid:{metadata.uid},name:{metadata.name}" 來獲取 UID 到 FlowSchema 的名稱和 UID 到 PriorityLevelConfigurations 的名稱的映射。
可觀察性
指標(biāo)
Note: 在 Kubernetes v1.20 之前的版本中，標(biāo)簽 ?
flow_schema?和 ?priority_level? 的名稱有時被寫作 ?flowSchema?和 ?priorityLevel?，即存在不一致的情況。 如果你在運(yùn)行 Kubernetes v1.19 或者更早版本，你需要參考你所使用的集群 版本對應(yīng)的文檔。
當(dāng)你開啟了 APF 后，kube-apiserver 會暴露額外指標(biāo)。 監(jiān)視這些指標(biāo)有助于判斷你的配置是否不當(dāng)?shù)叵拗屏酥匾髁浚?nbsp;或者發(fā)現(xiàn)可能會損害系統(tǒng)健康的，行為不良的工作負(fù)載。
- ?
apiserver_flowcontrol_rejected_requests_total?是一個計數(shù)器向量， 記錄被拒絕的請求數(shù)量（自服務(wù)器啟動以來累計值）， 由標(biāo)簽 ?flow_chema?（表示與請求匹配的 FlowSchema），?priority_evel?（表示分配給請該求的優(yōu)先級）和 ?reason?來區(qū)分。 ?reason?標(biāo)簽將具有以下值之一： - ?
queue-full? ，表明已經(jīng)有太多請求排隊， - ?
concurrency-limit?，表示將 PriorityLevelConfiguration 配置為 ?Reject?而不是 ?Queue?，或者 - ?
time-out?, 表示在其排隊時間超期的請求仍在隊列中。 - ?
apiserver_flowcontrol_dispatched_requests_total? 是一個計數(shù)器向量， 記錄開始執(zhí)行的請求數(shù)量（自服務(wù)器啟動以來的累積值）， 由標(biāo)簽 ?flow_schema?（表示與請求匹配的 FlowSchema）和 ?priority_level?（表示分配給該請求的優(yōu)先級）來區(qū)分。 - ?
apiserver_current_inqueue_requests?是一個表向量， 記錄最近排隊請求數(shù)量的高水位線， 由標(biāo)簽 ?request_kind?分組，標(biāo)簽的值為 ?mutating?或 ?readOnly?。 這些高水位線表示在最近一秒鐘內(nèi)看到的最大數(shù)字。 它們補(bǔ)充說明了老的表向量 ?apiserver_current_inflight_requests?（該量保存了最后一個窗口中，正在處理的請求數(shù)量的高水位線）。 - ?
apiserver_flowcontrol_read_vs_write_request_count_samples?是一個直方圖向量， 記錄當(dāng)前請求數(shù)量的觀察值， 由標(biāo)簽 ?phase?（取值為 ?waiting?和 ?executing?）和 ?request_kind?（取值 ?mutating?和 ?readOnly?）拆分。定期以高速率觀察該值。 - ?
apiserver_flowcontrol_read_vs_write_request_count_watermarks?是一個直方圖向量， 記錄請求數(shù)量的高/低水位線， 由標(biāo)簽 ?phase?（取值為 ?waiting?和 ?executing?）和 ?request_kind?（取值為 ?mutating?和 ?readOnly?）拆分；標(biāo)簽 ?mark?取值為 ?high?和 ?low?。 ?apiserver_flowcontrol_read_vs_write_request_count_samples?向量觀察到有值新增， 則該向量累積。這些水位線顯示了樣本值的范圍。 - ?
apiserver_flowcontrol_current_inqueue_requests?是一個表向量， 記錄包含排隊中的（未執(zhí)行）請求的瞬時數(shù)量， 由標(biāo)簽 ?priorityLevel?和 ?flowSchema?拆分。 - ?
apiserver_flowcontrol_current_executing_requests?是一個表向量， 記錄包含執(zhí)行中（不在隊列中等待）請求的瞬時數(shù)量， 由標(biāo)簽 ?priority_level?和 ?flow_schema?進(jìn)一步區(qū)分。 - ?
apiserver_flowcontrol_request_concurrency_in_use?是一個規(guī)范向量， 包含占用座位的瞬時數(shù)量，由標(biāo)簽 ?priority_level?和 ?flow_schema?進(jìn)一步區(qū)分。 - ?
apiserver_flowcontrol_priority_level_request_count_samples?是一個直方圖向量， 記錄當(dāng)前請求的觀測值，由標(biāo)簽 ?phase?（取值為?waiting?和 ?executing?）和 ?priority_level?進(jìn)一步區(qū)分。 每個直方圖都會定期進(jìn)行觀察，直到相關(guān)類別的最后活動為止。觀察頻率高。 - ?
apiserver_flowcontrol_priority_level_request_count_watermarks?是一個直方圖向量， 記錄請求數(shù)的高/低水位線，由標(biāo)簽 ?phase?（取值為 ?waiting?和 ?executing?）和 ?priority_level?拆分； 標(biāo)簽 ?mark?取值為 ?high?和 ?low?。 ?apiserver_flowcontrol_priority_level_request_count_samples?向量觀察到有值新增， 則該向量累積。這些水位線顯示了樣本值的范圍。 - ?
apiserver_flowcontrol_request_queue_length_after_enqueue?是一個直方圖向量， 記錄請求隊列的長度，由標(biāo)簽 ?priority_level?和 ?flow_schema?進(jìn)一步區(qū)分。 每個排隊中的請求都會為其直方圖貢獻(xiàn)一個樣本，并在添加請求后立即上報隊列的長度。 請注意，這樣產(chǎn)生的統(tǒng)計數(shù)據(jù)與無偏調(diào)查不同。
Note: 直方圖中的離群值在這里表示單個流（即，一個用戶或一個名稱空間的請求， 具體取決于配置）正在瘋狂地向 API 服務(wù)器發(fā)請求，并受到限制。 相反，如果一個優(yōu)先級的直方圖顯示該優(yōu)先級的所有隊列都比其他優(yōu)先級的隊列長， 則增加 PriorityLevelConfigurations 的并發(fā)份額是比較合適的。
- ?
apiserver_flowcontrol_request_concurrency_limit?是一個表向量， 記錄并發(fā)限制的計算值（基于 API 服務(wù)器的總并發(fā)限制和 PriorityLevelConfigurations 的并發(fā)份額），并按標(biāo)簽 ?priority_level?進(jìn)一步區(qū)分。 - ?
apiserver_flowcontrol_request_wait_duration_seconds?是一個直方圖向量， 記錄請求排隊的時間， 由標(biāo)簽 ?flow_schema?（表示與請求匹配的 FlowSchema ）， ?priority_level?（表示分配該請求的優(yōu)先級） 和 ?execute?（表示請求是否開始執(zhí)行）進(jìn)一步區(qū)分。
Note: 由于每個 FlowSchema 總會給請求分配 PriorityLevelConfigurations， 因此你可以為一個優(yōu)先級添加所有 FlowSchema 的直方圖，以獲取分配給 該優(yōu)先級的請求的有效直方圖。
- ?
apiserver_flowcontrol_request_execution_seconds?是一個直方圖向量， 記錄請求實(shí)際執(zhí)行需要花費(fèi)的時間， 由標(biāo)簽 ?flow_schema?（表示與請求匹配的 FlowSchema ）和 ?priority_level?（表示分配給該請求的優(yōu)先級）進(jìn)一步區(qū)分。
調(diào)試端點(diǎn)
啟用 APF 特性后， kube-apiserver 會在其 HTTP/HTTPS 端口提供以下路徑：
- ?
/debug/api_priority_and_fairness/dump_priority_levels? —— 所有優(yōu)先級及其當(dāng)前狀態(tài)的列表。你可以這樣獲?。?/li>kubectl get --raw /debug/api_priority_and_fairness/dump_priority_levels輸出類似于：
PriorityLevelName, ActiveQueues, IsIdle, IsQuiescing, WaitingRequests, ExecutingRequests, workload-low, 0, true, false, 0, 0, global-default, 0, true, false, 0, 0, exempt,, , , , , catch-all, 0, true, false, 0, 0, system, 0, true, false, 0, 0, leader-election, 0, true, false, 0, 0, workload-high, 0, true, false, 0, 0,
- ?
/debug/api_priority_and_fairness/dump_queues? —— 所有隊列及其當(dāng)前狀態(tài)的列表。 你可以這樣獲?。?/li>kubectl get --raw /debug/api_priority_and_fairness/dump_queues輸出類似于：
PriorityLevelName, Index, PendingRequests, ExecutingRequests, VirtualStart, workload-high, 0, 0, 0, 0.0000, workload-high, 1, 0, 0, 0.0000, workload-high, 2, 0, 0, 0.0000, ... leader-election, 14, 0, 0, 0.0000, leader-election, 15, 0, 0, 0.0000, - ?
/debug/api_priority_and_fairness/dump_requests? ——當(dāng)前正在隊列中等待的所有請求的列表。 你可以這樣獲?。?/li>kubectl get --raw /debug/api_priority_and_fairness/dump_requests輸出類似于：
PriorityLevelName, FlowSchemaName, QueueIndex, RequestIndexInQueue, FlowDistingsher, ArriveTime, exempt,, , , , , system, system-nodes, 12, 0, system:node:127.0.0.1, 2020-07-23T15:26:57.179170694Z, 針對每個優(yōu)先級別，輸出中還包含一條虛擬記錄，對應(yīng)豁免限制。
你可以使用以下命令獲得更詳細(xì)的清單：
kubectl get --raw '/debug/api_priority_and_fairness/dump_requests?includeRequestDetails=1'輸出類似于：
PriorityLevelName, FlowSchemaName, QueueIndex, RequestIndexInQueue, FlowDistingsher, ArriveTime, UserName, Verb, APIPath, Namespace, Name, APIVersion, Resource, SubResource, system, system-nodes, 12, 0, system:node:127.0.0.1, 2020-07-23T15:31:03.583823404Z, system:node:127.0.0.1, create, /api/v1/namespaces/scaletest/configmaps, system, system-nodes, 12, 1, system:node:127.0.0.1, 2020-07-23T15:31:03.594555947Z, system:node:127.0.0.1, create, /api/v1/namespaces/scaletest/configmaps,
文章標(biāo)題：創(chuàng)新互聯(lián)kubernetes教程：KubernetesAPI優(yōu)先級和公平性
網(wǎng)站URL：http://www.5511xx.com/article/dpjjhpi.html
