文档教程云原生【免费下载链接】docsUser documentation for Knative components.项目地址https://gitcode.com/gh_mirrors/docs1/docs点击查看免费下载本文基于 Knative 官方文档中的《Configuring concurrency》docs/versioned/serving/autoscaling/concurrency.md展开系统讲解 Knative Serving 中并发控制的两类限制软限制 / 硬限制及其全部配置键、示例与默认值并结合仓库中的请求流文档、config-defaults配置说明和官方autoscale-go压测样例帮你建立从配置到验证的完整闭环。读完本文你可以独立完成按 Revision 或全局粒度的并发目标设定、硬性并发上限设定与目标利用率调优并用样例服务验证扩缩容行为是否符合预期。并发在 Knative Serving 中的含义Concurrency并发决定了应用的每个副本replica在同一时刻能够处理的同时进行中的请求数量它是 Knative 自动扩缩容默认由 Knative Pod AutoscalerKPA 提供最核心的输入信号之一。Knative 的并发配置分为两个作用域按 Revisionper-revision针对单个修订版本设置。文档明确指出要配置按 Revision 的并发你必须同时设置autoscaling.knative.dev/metric与autoscaling.knative.dev/target这两个注解来形成软限制soft limit或者使用containerConcurrency字段来形成硬限制hard limit全局global对整个集群生效。全局并发通过config-autoscalerConfigMap 中的container-concurrency-target-default键设置。从请求链路的实现文档可以印证其底层机制每个 Revision Pod 中都会注入一个 queue-proxy sidecar它负责测量并发请求数并作为 autoscaler 的指标来源同时正是它负责实现containerConcurrency硬限制下的请求排队见 docs/versioned/serving/request-flow.md 中对 Queue-Proxy 职责的说明其中明确列出了 “Implements thecontainerConcurrencyhard limit on request concurrency”。软限制与硬限制的区别Knative 允许你为并发设置软限制或硬限制两者语义完全不同软限制Soft Limit硬限制Hard Limit语义一个目标值targeted limit而非严格边界一个强制执行的上界enforced upper bound突发流量下可能被突破exceeded尤其在请求突增burst时达到上限后多余的请求会被缓冲buffered必须等待有容量释放才能被执行配置方式autoscaling.knative.dev/metricautoscaling.knative.dev/target注解或全局container-concurrency-target-defaultRevision spec 中的containerConcurrency字段两点关键约束必须牢记两者同时指定时取较小值生效。文档原话说明这样做是为了防止 Autoscaler 拿到一个不被硬限制允许的目标值the smaller of the two values will be used。谨慎使用硬限制。官方给出了明确警告只有当你的应用存在清晰的硬性并发需求时才建议设置硬限制过低的硬限制可能损害应用吞吐量和延迟并可能引发额外的冷启动。配置软限制并发目标值软限制是 Autoscaler 努力维持的并发目标。相关配置键如下全局键Global keycontainer-concurrency-target-default按 Revision 注解键autoscaling.knative.dev/target取值整数默认值100注意target注解是**指标无关metric agnostic**的整数可配合concurrency或rps等不同指标使用参见 docs/versioned/serving/autoscaling/autoscaling-targets.md。当 metric 为concurrency时它就是每个副本的目标并发数。示例三种作用域均继承自官方文档原文按 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 中设置每次新建 Revision 时注解才会随之应用——这一点在 docs/versioned/serving/autoscaling/autoscaler-types.md 的 Per-revision settings 一节有专门提示。全局与按 Revision 设置的优先级规则是未指定按 Revision 设置时使用全局设置指定了按 Revision 设置时其覆盖全局设置详见 docs/versioned/serving/autoscaling/autoscaler-types.md。配置硬限制containerConcurrency硬限制通过 Revision spec 中的containerConcurrency字段指定且它是一个 spec 字段不是 annotation。与软限制的一个显著差异是config-autoscalerConfigMap 中不存在硬限制的全局键因为containerConcurrency的影响超出了扩缩容范畴还牵涉请求的缓冲与排队行为这也解释了为什么由 queue-proxy 而非 autoscaler 来执行它。不过你可以在config-defaultsConfigMap 中为containerConcurrency设置一个集群级默认值全局键container-concurrency位于config-defaultsConfigMap按 Revision spec 键containerConcurrency取值整数默认值0即不限制流入副本的请求数量默认值0的含义是没有上限任何大于0的值表示同一时刻允许流入该副本的确切请求数。示例三种作用域均继承自官方文档原文按 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相关的两个配套键。查阅 docs/versioned/serving/configuration/config-defaults.md 可以看到config-defaults中与并发相关的设置并不止container-concurrency一个还包括两个集群管理员级别的“护栏”全局键默认值作用container-concurrency0containerConcurrency的默认值大于 0 时超过阈值的请求会被排队0 表示放行 Pod 收到的全部请求container-concurrency-max-limit1000禁止单个 Revision 使用任意大的并发值或 autoscaling 目标值container-concurrency默认值必须不超过该值allow-container-concurrency-zerotrue控制用户是否可以把containerConcurrency设为0无界设为false后用户无法再指定无界并发这意味着即便普通开发者可以为自己的 Revision 设置硬限制集群管理员仍可通过这两个键约束上限、或在安全要求下全面禁止“无界”配置。目标利用率Target Utilization除了上面两类字面配置Knative 还提供一个目标利用率target utilization value用于进一步调整 Autoscaler 实际瞄准的并发比例。这个值规定了 Autoscaler 应当以之前设定的目标值的百分之多少作为实际扩缩容触发点。它也可以理解为副本运行的“热度hotness”——让 Autoscaler 在硬限制被触及之前就开始扩容。官方文档给出的例子直接引用原文场景若containerConcurrency设置为10目标利用率设置为70百分比则当所有现有副本的平均并发请求数达到7时Autoscaler 就会创建新副本。编号 7 到 10 的请求仍会发送到现有副本但此举让系统在containerConcurrency上限到达之前提前启动额外副本。相关配置键全局键container-concurrency-target-percentage按 Revision 注解键autoscaling.knative.dev/target-utilization-percentage取值浮点数默认值70数值表示形式在 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配置值如何协同生效把三组配置放在一起可以理清 Autoscaler 的决策逻辑软限制决定“目标”KPA 以autoscaling.knative.dev/target或全局container-concurrency-target-default为每副本并发目标目标利用率决定“何时动手”实际触发扩容的并发水位 目标 × 利用率百分比。例如默认 70% 下目标 100 意味着平均并发达到约 70 就开始扩容而不是等到 100硬限制决定“天花板”containerConcurrency由 queue-proxy 强制排队执行当软、硬同时存在时Autoscaler 的有效目标取两者中的较小值利用率百分比再在这个有效目标上打折使扩容提前于容量耗尽发生。这套机制在 KPA 的稳定窗口 / panic 窗口之上工作常规情况下指标在stable-window默认60s内平滑求平均突发流量下若 panic 窗口内并发超过panic-threshold-percentage默认 200%KPA 进入 panic 模式用更短窗口快速扩容见 docs/versioned/serving/autoscaling/kpa-specific.md。用官方 autoscale-go 样例验证并发目标仓库内置了 docs/versioned/serving/autoscaling/autoscale-go/ 样例Go 编写的压测目标服务其 service.yaml 正是按 Revision 并发软限制的典型配置# 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并发请求发送 30 秒hey -z 30s -c 50 \ http://autoscale-go.your-cluster-domain/?sleep100prime10000bloat5 \ kubectl get pods观察副本数由于目标并发为 10KPA 会创建 5 个 Pod50 concurrent requests / target of 10 5 pods压测后kubectl get pods可见 5 个autoscale-go-00001-deployment-*Pod。压测参数由 autoscale.go 中的 handler 解析sleep让请求并行占用固定时间拉长在途时长、直接推高并发prime消耗 CPUbloat分配内存。通过sleep100让每个请求在途约 100ms50 个并发请求 ÷ 每副本目标 10 个在途请求 需要 5 个副本与扩容结果一致。样例文档还说明了窗口行为KPA 默认以 60 秒稳定窗口求平均并发因此系统稳定到目标并发水位约需一分钟但当 6 秒 panic 窗口内的并发达到目标的 2 倍时会立即进入 panic 模式按更敏感的短窗口快速扩容直到 panic 条件在 60 秒内不再满足才回到稳定窗口。如果你希望在本地完整复现这一验证前提是一个已安装 Knative Serving 的 Kubernetes 集群和heygo install github.com/rakyll/heylatest部署命令为kubectl apply -f docs/versioned/serving/autoscaling/autoscale-go/service.yaml清理命令为kubectl delete -f同一文件完整步骤见样例 README。配置检查清单结合上文落库前可以用以下清单自查软限制确认autoscaling.knative.dev/metric与autoscaling.knative.dev/target成对出现且注解位于spec.template.metadata.annotations而非 Revision 顶层硬限制确认containerConcurrency写在spec.template.spec下它不是注解默认0表示不排队、不设限软硬共存预期生效的是两者较小值避免“目标 200、硬上限 50”这类自相矛盾的配置利用率调高target-utilization-percentage会让扩容更积极更早扩容、副本更多调低则更“省副本”但更容易触及硬限制排队集群护栏管理员侧检查config-defaults中的container-concurrency-max-limit与allow-container-concurrency-zero确认单个 Revision 的并发/目标上限符合集群治理策略核对现状用kubectl get configmap -n knative-serving config-defaults -oyaml查看当前默认并发设置命令见 docs/versioned/serving/configuration/config-defaults.md用kubectl get configmap -n knative-serving config-autoscaler -oyaml查看全局并发目标。延伸阅读docs/versioned/serving/autoscaling/README.mdKnative 自动扩缩容总览docs/versioned/serving/autoscaling/autoscaler-types.mdKPA / HPA 两种 Autoscaler 类型与全局/按 Revision 配置的优先级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副本数上下界min-scale / max-scale配置赞分享文档教程云原生【免费下载链接】docsUser documentation for Knative components.项目地址https://gitcode.com/gh_mirrors/docs1/docs点击查看免费下载相关推荐Knative Serving 服务资源请求与限制配置实战指南Knative Serving 服务资源请求与限制配置实战指南 本文面向 Knative Serving 开发者围绕如何为单个 Knative Service文档教程云原生Knative Serving 自动扩缩容指标类型详解KPA 的 concurrency/rps 与 HPA 的 cpu/memory 配置实战Knative Serving 自动扩缩容指标类型详解KPA 的 concurrency/rps 与 HPA 的 cpu/memory 配置实战 本文聚焦 K文档教程云原生Trigger.dev 任务并发控制详解concurrency 选项、共享限制与 concurrencyLimits 运行时管理Trigger.dev 任务并发控制详解concurrency 选项、共享限制与 concurrencyLimits 运行时管理 本文基于 Trigger.dAI Agent后端任务调度开发工具可观测性AI 应用上一篇btop 项目下载及安装教程下一篇[课程名称]创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Knative Serving 并发（Concurrency）配置详解：软限制、硬限制与目标利用率
文档教程云原生【免费下载链接】docsUser documentation for Knative components.项目地址https://gitcode.com/gh_mirrors/docs1/docs点击查看免费下载本文基于 Knative 官方文档中的《Configuring concurrency》docs/versioned/serving/autoscaling/concurrency.md展开系统讲解 Knative Serving 中并发控制的两类限制软限制 / 硬限制及其全部配置键、示例与默认值并结合仓库中的请求流文档、config-defaults配置说明和官方autoscale-go压测样例帮你建立从配置到验证的完整闭环。读完本文你可以独立完成按 Revision 或全局粒度的并发目标设定、硬性并发上限设定与目标利用率调优并用样例服务验证扩缩容行为是否符合预期。并发在 Knative Serving 中的含义Concurrency并发决定了应用的每个副本replica在同一时刻能够处理的同时进行中的请求数量它是 Knative 自动扩缩容默认由 Knative Pod AutoscalerKPA 提供最核心的输入信号之一。Knative 的并发配置分为两个作用域按 Revisionper-revision针对单个修订版本设置。文档明确指出要配置按 Revision 的并发你必须同时设置autoscaling.knative.dev/metric与autoscaling.knative.dev/target这两个注解来形成软限制soft limit或者使用containerConcurrency字段来形成硬限制hard limit全局global对整个集群生效。全局并发通过config-autoscalerConfigMap 中的container-concurrency-target-default键设置。从请求链路的实现文档可以印证其底层机制每个 Revision Pod 中都会注入一个 queue-proxy sidecar它负责测量并发请求数并作为 autoscaler 的指标来源同时正是它负责实现containerConcurrency硬限制下的请求排队见 docs/versioned/serving/request-flow.md 中对 Queue-Proxy 职责的说明其中明确列出了 “Implements thecontainerConcurrencyhard limit on request concurrency”。软限制与硬限制的区别Knative 允许你为并发设置软限制或硬限制两者语义完全不同软限制Soft Limit硬限制Hard Limit语义一个目标值targeted limit而非严格边界一个强制执行的上界enforced upper bound突发流量下可能被突破exceeded尤其在请求突增burst时达到上限后多余的请求会被缓冲buffered必须等待有容量释放才能被执行配置方式autoscaling.knative.dev/metricautoscaling.knative.dev/target注解或全局container-concurrency-target-defaultRevision spec 中的containerConcurrency字段两点关键约束必须牢记两者同时指定时取较小值生效。文档原话说明这样做是为了防止 Autoscaler 拿到一个不被硬限制允许的目标值the smaller of the two values will be used。谨慎使用硬限制。官方给出了明确警告只有当你的应用存在清晰的硬性并发需求时才建议设置硬限制过低的硬限制可能损害应用吞吐量和延迟并可能引发额外的冷启动。配置软限制并发目标值软限制是 Autoscaler 努力维持的并发目标。相关配置键如下全局键Global keycontainer-concurrency-target-default按 Revision 注解键autoscaling.knative.dev/target取值整数默认值100注意target注解是**指标无关metric agnostic**的整数可配合concurrency或rps等不同指标使用参见 docs/versioned/serving/autoscaling/autoscaling-targets.md。当 metric 为concurrency时它就是每个副本的目标并发数。示例三种作用域均继承自官方文档原文按 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 中设置每次新建 Revision 时注解才会随之应用——这一点在 docs/versioned/serving/autoscaling/autoscaler-types.md 的 Per-revision settings 一节有专门提示。全局与按 Revision 设置的优先级规则是未指定按 Revision 设置时使用全局设置指定了按 Revision 设置时其覆盖全局设置详见 docs/versioned/serving/autoscaling/autoscaler-types.md。配置硬限制containerConcurrency硬限制通过 Revision spec 中的containerConcurrency字段指定且它是一个 spec 字段不是 annotation。与软限制的一个显著差异是config-autoscalerConfigMap 中不存在硬限制的全局键因为containerConcurrency的影响超出了扩缩容范畴还牵涉请求的缓冲与排队行为这也解释了为什么由 queue-proxy 而非 autoscaler 来执行它。不过你可以在config-defaultsConfigMap 中为containerConcurrency设置一个集群级默认值全局键container-concurrency位于config-defaultsConfigMap按 Revision spec 键containerConcurrency取值整数默认值0即不限制流入副本的请求数量默认值0的含义是没有上限任何大于0的值表示同一时刻允许流入该副本的确切请求数。示例三种作用域均继承自官方文档原文按 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相关的两个配套键。查阅 docs/versioned/serving/configuration/config-defaults.md 可以看到config-defaults中与并发相关的设置并不止container-concurrency一个还包括两个集群管理员级别的“护栏”全局键默认值作用container-concurrency0containerConcurrency的默认值大于 0 时超过阈值的请求会被排队0 表示放行 Pod 收到的全部请求container-concurrency-max-limit1000禁止单个 Revision 使用任意大的并发值或 autoscaling 目标值container-concurrency默认值必须不超过该值allow-container-concurrency-zerotrue控制用户是否可以把containerConcurrency设为0无界设为false后用户无法再指定无界并发这意味着即便普通开发者可以为自己的 Revision 设置硬限制集群管理员仍可通过这两个键约束上限、或在安全要求下全面禁止“无界”配置。目标利用率Target Utilization除了上面两类字面配置Knative 还提供一个目标利用率target utilization value用于进一步调整 Autoscaler 实际瞄准的并发比例。这个值规定了 Autoscaler 应当以之前设定的目标值的百分之多少作为实际扩缩容触发点。它也可以理解为副本运行的“热度hotness”——让 Autoscaler 在硬限制被触及之前就开始扩容。官方文档给出的例子直接引用原文场景若containerConcurrency设置为10目标利用率设置为70百分比则当所有现有副本的平均并发请求数达到7时Autoscaler 就会创建新副本。编号 7 到 10 的请求仍会发送到现有副本但此举让系统在containerConcurrency上限到达之前提前启动额外副本。相关配置键全局键container-concurrency-target-percentage按 Revision 注解键autoscaling.knative.dev/target-utilization-percentage取值浮点数默认值70数值表示形式在 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配置值如何协同生效把三组配置放在一起可以理清 Autoscaler 的决策逻辑软限制决定“目标”KPA 以autoscaling.knative.dev/target或全局container-concurrency-target-default为每副本并发目标目标利用率决定“何时动手”实际触发扩容的并发水位 目标 × 利用率百分比。例如默认 70% 下目标 100 意味着平均并发达到约 70 就开始扩容而不是等到 100硬限制决定“天花板”containerConcurrency由 queue-proxy 强制排队执行当软、硬同时存在时Autoscaler 的有效目标取两者中的较小值利用率百分比再在这个有效目标上打折使扩容提前于容量耗尽发生。这套机制在 KPA 的稳定窗口 / panic 窗口之上工作常规情况下指标在stable-window默认60s内平滑求平均突发流量下若 panic 窗口内并发超过panic-threshold-percentage默认 200%KPA 进入 panic 模式用更短窗口快速扩容见 docs/versioned/serving/autoscaling/kpa-specific.md。用官方 autoscale-go 样例验证并发目标仓库内置了 docs/versioned/serving/autoscaling/autoscale-go/ 样例Go 编写的压测目标服务其 service.yaml 正是按 Revision 并发软限制的典型配置# 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并发请求发送 30 秒hey -z 30s -c 50 \ http://autoscale-go.your-cluster-domain/?sleep100prime10000bloat5 \ kubectl get pods观察副本数由于目标并发为 10KPA 会创建 5 个 Pod50 concurrent requests / target of 10 5 pods压测后kubectl get pods可见 5 个autoscale-go-00001-deployment-*Pod。压测参数由 autoscale.go 中的 handler 解析sleep让请求并行占用固定时间拉长在途时长、直接推高并发prime消耗 CPUbloat分配内存。通过sleep100让每个请求在途约 100ms50 个并发请求 ÷ 每副本目标 10 个在途请求 需要 5 个副本与扩容结果一致。样例文档还说明了窗口行为KPA 默认以 60 秒稳定窗口求平均并发因此系统稳定到目标并发水位约需一分钟但当 6 秒 panic 窗口内的并发达到目标的 2 倍时会立即进入 panic 模式按更敏感的短窗口快速扩容直到 panic 条件在 60 秒内不再满足才回到稳定窗口。如果你希望在本地完整复现这一验证前提是一个已安装 Knative Serving 的 Kubernetes 集群和heygo install github.com/rakyll/heylatest部署命令为kubectl apply -f docs/versioned/serving/autoscaling/autoscale-go/service.yaml清理命令为kubectl delete -f同一文件完整步骤见样例 README。配置检查清单结合上文落库前可以用以下清单自查软限制确认autoscaling.knative.dev/metric与autoscaling.knative.dev/target成对出现且注解位于spec.template.metadata.annotations而非 Revision 顶层硬限制确认containerConcurrency写在spec.template.spec下它不是注解默认0表示不排队、不设限软硬共存预期生效的是两者较小值避免“目标 200、硬上限 50”这类自相矛盾的配置利用率调高target-utilization-percentage会让扩容更积极更早扩容、副本更多调低则更“省副本”但更容易触及硬限制排队集群护栏管理员侧检查config-defaults中的container-concurrency-max-limit与allow-container-concurrency-zero确认单个 Revision 的并发/目标上限符合集群治理策略核对现状用kubectl get configmap -n knative-serving config-defaults -oyaml查看当前默认并发设置命令见 docs/versioned/serving/configuration/config-defaults.md用kubectl get configmap -n knative-serving config-autoscaler -oyaml查看全局并发目标。延伸阅读docs/versioned/serving/autoscaling/README.mdKnative 自动扩缩容总览docs/versioned/serving/autoscaling/autoscaler-types.mdKPA / HPA 两种 Autoscaler 类型与全局/按 Revision 配置的优先级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副本数上下界min-scale / max-scale配置赞分享文档教程云原生【免费下载链接】docsUser documentation for Knative components.项目地址https://gitcode.com/gh_mirrors/docs1/docs点击查看免费下载相关推荐Knative Serving 服务资源请求与限制配置实战指南Knative Serving 服务资源请求与限制配置实战指南 本文面向 Knative Serving 开发者围绕如何为单个 Knative Service文档教程云原生Knative Serving 自动扩缩容指标类型详解KPA 的 concurrency/rps 与 HPA 的 cpu/memory 配置实战Knative Serving 自动扩缩容指标类型详解KPA 的 concurrency/rps 与 HPA 的 cpu/memory 配置实战 本文聚焦 K文档教程云原生Trigger.dev 任务并发控制详解concurrency 选项、共享限制与 concurrencyLimits 运行时管理Trigger.dev 任务并发控制详解concurrency 选项、共享限制与 concurrencyLimits 运行时管理 本文基于 Trigger.dAI Agent后端任务调度开发工具可观测性AI 应用上一篇btop 项目下载及安装教程下一篇[课程名称]创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考