文檔教程云原生【免費(fèi)下載鏈接】docsUser documentation for Knative components.項(xiàng)目地址https://gitcode.com/gh_mirrors/docs1/docs點(diǎn)擊查看免費(fèi)下載本文基于 Knative 官方文檔中的《Configuring concurrency》docs/versioned/serving/autoscaling/concurrency.md展開系統(tǒng)講解 Knative Serving 中并發(fā)控制的兩類限制軟限制 / 硬限制及其全部配置鍵、示例與默認(rèn)值并結(jié)合倉(cāng)庫(kù)中的請(qǐng)求流文檔、config-defaults配置說明和官方autoscale-go壓測(cè)樣例幫你建立從配置到驗(yàn)證的完整閉環(huán)。讀完本文你可以獨(dú)立完成按 Revision 或全局粒度的并發(fā)目標(biāo)設(shè)定、硬性并發(fā)上限設(shè)定與目標(biāo)利用率調(diào)優(yōu)并用樣例服務(wù)驗(yàn)證擴(kuò)縮容行為是否符合預(yù)期。并發(fā)在 Knative Serving 中的含義Concurrency并發(fā)決定了應(yīng)用的每個(gè)副本replica在同一時(shí)刻能夠處理的同時(shí)進(jìn)行中的請(qǐng)求數(shù)量它是 Knative 自動(dòng)擴(kuò)縮容默認(rèn)由 Knative Pod AutoscalerKPA 提供最核心的輸入信號(hào)之一。Knative 的并發(fā)配置分為兩個(gè)作用域按 Revisionper-revision針對(duì)單個(gè)修訂版本設(shè)置。文檔明確指出要配置按 Revision 的并發(fā)你必須同時(shí)設(shè)置autoscaling.knative.dev/metric與autoscaling.knative.dev/target這兩個(gè)注解來形成軟限制soft limit或者使用containerConcurrency字段來形成硬限制hard limit全局global對(duì)整個(gè)集群生效。全局并發(fā)通過config-autoscalerConfigMap 中的container-concurrency-target-default鍵設(shè)置。從請(qǐng)求鏈路的實(shí)現(xiàn)文檔可以印證其底層機(jī)制每個(gè) Revision Pod 中都會(huì)注入一個(gè) queue-proxy sidecar它負(fù)責(zé)測(cè)量并發(fā)請(qǐng)求數(shù)并作為 autoscaler 的指標(biāo)來源同時(shí)正是它負(fù)責(zé)實(shí)現(xiàn)containerConcurrency硬限制下的請(qǐng)求排隊(duì)見 docs/versioned/serving/request-flow.md 中對(duì) Queue-Proxy 職責(zé)的說明其中明確列出了 “Implements thecontainerConcurrencyhard limit on request concurrency”。軟限制與硬限制的區(qū)別Knative 允許你為并發(fā)設(shè)置軟限制或硬限制兩者語(yǔ)義完全不同軟限制Soft Limit硬限制Hard Limit語(yǔ)義一個(gè)目標(biāo)值targeted limit而非嚴(yán)格邊界一個(gè)強(qiáng)制執(zhí)行的上界enforced upper bound突發(fā)流量下可能被突破exceeded尤其在請(qǐng)求突增burst時(shí)達(dá)到上限后多余的請(qǐng)求會(huì)被緩沖buffered必須等待有容量釋放才能被執(zhí)行配置方式autoscaling.knative.dev/metricautoscaling.knative.dev/target注解或全局container-concurrency-target-defaultRevision spec 中的containerConcurrency字段兩點(diǎn)關(guān)鍵約束必須牢記兩者同時(shí)指定時(shí)取較小值生效。文檔原話說明這樣做是為了防止 Autoscaler 拿到一個(gè)不被硬限制允許的目標(biāo)值the smaller of the two values will be used。謹(jǐn)慎使用硬限制。官方給出了明確警告只有當(dāng)你的應(yīng)用存在清晰的硬性并發(fā)需求時(shí)才建議設(shè)置硬限制過低的硬限制可能損害應(yīng)用吞吐量和延遲并可能引發(fā)額外的冷啟動(dòng)。配置軟限制并發(fā)目標(biāo)值軟限制是 Autoscaler 努力維持的并發(fā)目標(biāo)。相關(guān)配置鍵如下全局鍵Global keycontainer-concurrency-target-default按 Revision 注解鍵autoscaling.knative.dev/target取值整數(shù)默認(rèn)值100注意target注解是**指標(biāo)無關(guān)metric agnostic**的整數(shù)可配合concurrency或rps等不同指標(biāo)使用參見 docs/versioned/serving/autoscaling/autoscaling-targets.md。當(dāng) metric 為concurrency時(shí)它就是每個(gè)副本的目標(biāo)并發(fā)數(shù)。示例三種作用域均繼承自官方文檔原文按 Revision 配置apiVersion: serving.knative.dev/v1 kind: Service metadata: name: helloworld-go namespace: default spec: template: metadata: annotations: autoscaling.knative.dev/target: 200全局配置ConfigMapapiVersion: v1 kind: ConfigMap metadata: name: config-autoscaler namespace: knative-serving data: container-concurrency-target-default: 200全局配置OperatorapiVersion: operator.knative.dev/v1alpha1 kind: KnativeServing metadata: name: knative-serving spec: config: autoscaler: container-concurrency-target-default: 200!!! 實(shí)踐要點(diǎn)按 Revision 的注解必須寫在revision templatespec.template.metadata.annotations中而不是某個(gè) Revision 的頂層 metadata。只有在 template 中設(shè)置每次新建 Revision 時(shí)注解才會(huì)隨之應(yīng)用——這一點(diǎn)在 docs/versioned/serving/autoscaling/autoscaler-types.md 的 Per-revision settings 一節(jié)有專門提示。全局與按 Revision 設(shè)置的優(yōu)先級(jí)規(guī)則是未指定按 Revision 設(shè)置時(shí)使用全局設(shè)置指定了按 Revision 設(shè)置時(shí)其覆蓋全局設(shè)置詳見 docs/versioned/serving/autoscaling/autoscaler-types.md。配置硬限制containerConcurrency硬限制通過 Revision spec 中的containerConcurrency字段指定且它是一個(gè) spec 字段不是 annotation。與軟限制的一個(gè)顯著差異是config-autoscalerConfigMap 中不存在硬限制的全局鍵因?yàn)閏ontainerConcurrency的影響超出了擴(kuò)縮容范疇還牽涉請(qǐng)求的緩沖與排隊(duì)行為這也解釋了為什么由 queue-proxy 而非 autoscaler 來執(zhí)行它。不過你可以在config-defaultsConfigMap 中為containerConcurrency設(shè)置一個(gè)集群級(jí)默認(rèn)值全局鍵container-concurrency位于config-defaultsConfigMap按 Revision spec 鍵containerConcurrency取值整數(shù)默認(rèn)值0即不限制流入副本的請(qǐng)求數(shù)量默認(rèn)值0的含義是沒有上限任何大于0的值表示同一時(shí)刻允許流入該副本的確切請(qǐng)求數(shù)。示例三種作用域均繼承自官方文檔原文按 Revision 配置apiVersion: serving.knative.dev/v1 kind: Service metadata: name: helloworld-go namespace: default spec: template: spec: containerConcurrency: 50全局默認(rèn)值Defaults ConfigMapapiVersion: v1 kind: ConfigMap metadata: name: config-defaults namespace: knative-serving data: container-concurrency: 50全局默認(rèn)值OperatorapiVersion: operator.knative.dev/v1alpha1 kind: KnativeServing metadata: name: knative-serving spec: config: defaults: container-concurrency: 50與config-defaults相關(guān)的兩個(gè)配套鍵。查閱 docs/versioned/serving/configuration/config-defaults.md 可以看到config-defaults中與并發(fā)相關(guān)的設(shè)置并不止container-concurrency一個(gè)還包括兩個(gè)集群管理員級(jí)別的“護(hù)欄”全局鍵默認(rèn)值作用container-concurrency0containerConcurrency的默認(rèn)值大于 0 時(shí)超過閾值的請(qǐng)求會(huì)被排隊(duì)0 表示放行 Pod 收到的全部請(qǐng)求container-concurrency-max-limit1000禁止單個(gè) Revision 使用任意大的并發(fā)值或 autoscaling 目標(biāo)值container-concurrency默認(rèn)值必須不超過該值allow-container-concurrency-zerotrue控制用戶是否可以把containerConcurrency設(shè)為0無界設(shè)為false后用戶無法再指定無界并發(fā)這意味著即便普通開發(fā)者可以為自己的 Revision 設(shè)置硬限制集群管理員仍可通過這兩個(gè)鍵約束上限、或在安全要求下全面禁止“無界”配置。目標(biāo)利用率Target Utilization除了上面兩類字面配置Knative 還提供一個(gè)目標(biāo)利用率target utilization value用于進(jìn)一步調(diào)整 Autoscaler 實(shí)際瞄準(zhǔn)的并發(fā)比例。這個(gè)值規(guī)定了 Autoscaler 應(yīng)當(dāng)以之前設(shè)定的目標(biāo)值的百分之多少作為實(shí)際擴(kuò)縮容觸發(fā)點(diǎn)。它也可以理解為副本運(yùn)行的“熱度hotness”——讓 Autoscaler 在硬限制被觸及之前就開始擴(kuò)容。官方文檔給出的例子直接引用原文場(chǎng)景若containerConcurrency設(shè)置為10目標(biāo)利用率設(shè)置為70百分比則當(dāng)所有現(xiàn)有副本的平均并發(fā)請(qǐng)求數(shù)達(dá)到7時(shí)Autoscaler 就會(huì)創(chuàng)建新副本。編號(hào) 7 到 10 的請(qǐng)求仍會(huì)發(fā)送到現(xiàn)有副本但此舉讓系統(tǒng)在containerConcurrency上限到達(dá)之前提前啟動(dòng)額外副本。相關(guān)配置鍵全局鍵container-concurrency-target-percentage按 Revision 注解鍵autoscaling.knative.dev/target-utilization-percentage取值浮點(diǎn)數(shù)默認(rèn)值70數(shù)值表示形式在 docs/versioned/serving/autoscaling/autoscaler-types.md 展示的默認(rèn)config-autoscalerConfigMap 示例中該鍵寫作container-concurrency-target-percentage: 0.7與本文檔所述的默認(rèn) 70即 70%是同一默認(rèn)值的兩種表示形式。示例三種作用域均繼承自官方文檔原文按 Revision 配置apiVersion: serving.knative.dev/v1 kind: Service metadata: name: helloworld-go namespace: default spec: template: metadata: annotations: autoscaling.knative.dev/target-utilization-percentage: 80 spec: containers: - image: ghcr.io/knative/helloworld-go:latest全局配置ConfigMapapiVersion: v1 kind: ConfigMap metadata: name: config-autoscaler namespace: knative-serving data: container-concurrency-target-percentage: 80全局配置OperatorapiVersion: operator.knative.dev/v1alpha1 kind: KnativeServing metadata: name: knative-serving spec: config: autoscaler: container-concurrency-target-percentage: 80配置值如何協(xié)同生效把三組配置放在一起可以理清 Autoscaler 的決策邏輯軟限制決定“目標(biāo)”KPA 以autoscaling.knative.dev/target或全局container-concurrency-target-default為每副本并發(fā)目標(biāo)目標(biāo)利用率決定“何時(shí)動(dòng)手”實(shí)際觸發(fā)擴(kuò)容的并發(fā)水位 目標(biāo) × 利用率百分比。例如默認(rèn) 70% 下目標(biāo) 100 意味著平均并發(fā)達(dá)到約 70 就開始擴(kuò)容而不是等到 100硬限制決定“天花板”containerConcurrency由 queue-proxy 強(qiáng)制排隊(duì)執(zhí)行當(dāng)軟、硬同時(shí)存在時(shí)Autoscaler 的有效目標(biāo)取兩者中的較小值利用率百分比再在這個(gè)有效目標(biāo)上打折使擴(kuò)容提前于容量耗盡發(fā)生。這套機(jī)制在 KPA 的穩(wěn)定窗口 / panic 窗口之上工作常規(guī)情況下指標(biāo)在stable-window默認(rèn)60s內(nèi)平滑求平均突發(fā)流量下若 panic 窗口內(nèi)并發(fā)超過panic-threshold-percentage默認(rèn) 200%KPA 進(jìn)入 panic 模式用更短窗口快速擴(kuò)容見 docs/versioned/serving/autoscaling/kpa-specific.md。用官方 autoscale-go 樣例驗(yàn)證并發(fā)目標(biāo)倉(cāng)庫(kù)內(nèi)置了 docs/versioned/serving/autoscaling/autoscale-go/ 樣例Go 編寫的壓測(cè)目標(biāo)服務(wù)其 service.yaml 正是按 Revision 并發(fā)軟限制的典型配置# docs/versioned/serving/autoscaling/autoscale-go/service.yaml spec: template: metadata: annotations: # Target 10 in-flight-requests per pod. autoscaling.knative.dev/target: 10樣例的 README 給出了完整的驗(yàn)證過程與算法分析部署樣例后用hey壓測(cè)工具維持 50 個(gè)在途in-flight并發(fā)請(qǐng)求發(fā)送 30 秒hey -z 30s -c 50 \ http://autoscale-go.your-cluster-domain/?sleep100prime10000bloat5 \ kubectl get pods觀察副本數(shù)由于目標(biāo)并發(fā)為 10KPA 會(huì)創(chuàng)建 5 個(gè) Pod50 concurrent requests / target of 10 5 pods壓測(cè)后kubectl get pods可見 5 個(gè)autoscale-go-00001-deployment-*Pod。壓測(cè)參數(shù)由 autoscale.go 中的 handler 解析sleep讓請(qǐng)求并行占用固定時(shí)間拉長(zhǎng)在途時(shí)長(zhǎng)、直接推高并發(fā)prime消耗 CPUbloat分配內(nèi)存。通過sleep100讓每個(gè)請(qǐng)求在途約 100ms50 個(gè)并發(fā)請(qǐng)求 ÷ 每副本目標(biāo) 10 個(gè)在途請(qǐng)求 需要 5 個(gè)副本與擴(kuò)容結(jié)果一致。樣例文檔還說明了窗口行為KPA 默認(rèn)以 60 秒穩(wěn)定窗口求平均并發(fā)因此系統(tǒng)穩(wěn)定到目標(biāo)并發(fā)水位約需一分鐘但當(dāng) 6 秒 panic 窗口內(nèi)的并發(fā)達(dá)到目標(biāo)的 2 倍時(shí)會(huì)立即進(jìn)入 panic 模式按更敏感的短窗口快速擴(kuò)容直到 panic 條件在 60 秒內(nèi)不再滿足才回到穩(wěn)定窗口。如果你希望在本地完整復(fù)現(xiàn)這一驗(yàn)證前提是一個(gè)已安裝 Knative Serving 的 Kubernetes 集群和heygo install github.com/rakyll/heylatest部署命令為kubectl apply -f docs/versioned/serving/autoscaling/autoscale-go/service.yaml清理命令為kubectl delete -f同一文件完整步驟見樣例 README。配置檢查清單結(jié)合上文落庫(kù)前可以用以下清單自查軟限制確認(rèn)autoscaling.knative.dev/metric與autoscaling.knative.dev/target成對(duì)出現(xiàn)且注解位于spec.template.metadata.annotations而非 Revision 頂層硬限制確認(rèn)containerConcurrency寫在spec.template.spec下它不是注解默認(rèn)0表示不排隊(duì)、不設(shè)限軟硬共存預(yù)期生效的是兩者較小值避免“目標(biāo) 200、硬上限 50”這類自相矛盾的配置利用率調(diào)高target-utilization-percentage會(huì)讓擴(kuò)容更積極更早擴(kuò)容、副本更多調(diào)低則更“省副本”但更容易觸及硬限制排隊(duì)集群護(hù)欄管理員側(cè)檢查config-defaults中的container-concurrency-max-limit與allow-container-concurrency-zero確認(rèn)單個(gè) Revision 的并發(fā)/目標(biāo)上限符合集群治理策略核對(duì)現(xiàn)狀用kubectl get configmap -n knative-serving config-defaults -oyaml查看當(dāng)前默認(rèn)并發(fā)設(shè)置命令見 docs/versioned/serving/configuration/config-defaults.md用kubectl get configmap -n knative-serving config-autoscaler -oyaml查看全局并發(fā)目標(biāo)。延伸閱讀docs/versioned/serving/autoscaling/README.mdKnative 自動(dòng)擴(kuò)縮容總覽docs/versioned/serving/autoscaling/autoscaler-types.mdKPA / HPA 兩種 Autoscaler 類型與全局/按 Revision 配置的優(yōu)先級(jí)docs/versioned/serving/autoscaling/autoscaling-metrics.md 與 docs/versioned/serving/autoscaling/autoscaling-targets.md指標(biāo)類型與目標(biāo)值配置docs/versioned/serving/autoscaling/kpa-specific.mdstable/panic 窗口與擴(kuò)縮容速率docs/versioned/serving/autoscaling/scale-bounds.md副本數(shù)上下界min-scale / max-scale配置贊分享文檔教程云原生【免費(fèi)下載鏈接】docsUser documentation for Knative components.項(xiàng)目地址https://gitcode.com/gh_mirrors/docs1/docs點(diǎn)擊查看免費(fèi)下載相關(guān)推薦Knative Serving 服務(wù)資源請(qǐng)求與限制配置實(shí)戰(zhàn)指南Knative Serving 服務(wù)資源請(qǐng)求與限制配置實(shí)戰(zhàn)指南 本文面向 Knative Serving 開發(fā)者圍繞如何為單個(gè) Knative Service文檔教程云原生Knative Serving 自動(dòng)擴(kuò)縮容指標(biāo)類型詳解KPA 的 concurrency/rps 與 HPA 的 cpu/memory 配置實(shí)戰(zhàn)Knative Serving 自動(dòng)擴(kuò)縮容指標(biāo)類型詳解KPA 的 concurrency/rps 與 HPA 的 cpu/memory 配置實(shí)戰(zhàn) 本文聚焦 K文檔教程云原生Trigger.dev 任務(wù)并發(fā)控制詳解concurrency 選項(xiàng)、共享限制與 concurrencyLimits 運(yùn)行時(shí)管理Trigger.dev 任務(wù)并發(fā)控制詳解concurrency 選項(xiàng)、共享限制與 concurrencyLimits 運(yùn)行時(shí)管理 本文基于 Trigger.dAI Agent后端任務(wù)調(diào)度開發(fā)工具可觀測(cè)性AI 應(yīng)用上一篇btop 項(xiàng)目下載及安裝教程下一篇[課程名稱]創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考