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