文档教程云原生【免费下载链接】docsUser documentation for Knative components.项目地址https://gitcode.com/gh_mirrors/docs1/docs点击查看免费下载导读本文基于 Knative 官方 Quickstart 教程中的 Autoscaling 主题完整演示如何查看、访问一个 Knative Service并观察其「无流量缩容到零、来流量立即扩容」的全过程随后结合本仓库的 autoscaling 参考文档 与 autoscale-go 示例应用深入讲解 Knative Pod AutoscalerKPA的并发模型、Stable/Panic 双模式算法以及全局与 per-revision 两类配置体系。读完本文你将能独立完成一次完整的「部署—压测—观察缩放—缩容到零—按需扩容」实验并掌握 Knative Serving 自动扩缩容的核心配置参数。一、什么是 Knative Serving AutoscalingKnative Serving 默认提供自动扩缩容能力即autoscaling一个 Knative Service 在没有流量时默认会缩容到零个运行中的 Pod不再占用集群资源一旦有请求到达系统又会自动拉起新的 Pod 处理流量并随着并发压力的上升/下降动态调整副本数量。这套能力由 Knative 自带的Knative Pod AutoscalerKPA提供它在 Knative Serving 安装完成后即默认启用。KPA 与 Kubernetes 原生 HPA 的能力对比如下详见 Supported Autoscaler types能力KPA默认HPA是否随 Serving 默认安装是Serving 核心自带否需另行安装是否支持缩容到零支持不支持是否支持基于 CPU 扩缩容不支持支持本教程属于 Quickstart 系列中的一环建议按顺序先完成 安装 Knativequickstart 与 部署第一个 Knative Service部署一个名为hello的示例服务再继续阅读本文。二、查看你的 Knative Service部署完成后先用knCLI 查看 Knative Service 的托管 URL kn 运行以下命令列出所有 Knative Servicebash kn service list预期输出bash NAME URL LATEST AGE CONDITIONS READY hello http://hello.default.${LOADBALANCER_IP}.sslip.io hello-00001 13s 3 OK / 3 True kubectl 也可以使用 kubectl 查看bash kubectl get ksvc预期输出bash NAME URL LATESTCREATED LATESTREADY READY REASON hello http://hello.default.${LOADBALANCER_IP}.sslip.io hello-00001 hello-00001 True其中${LOADBALANCER_IP}依集群类型而不同kind集群下通常是127.0.0.1minikube集群则取决于本地 tunnel 配置。URL 中的hello.default表示服务名为hello、命名空间为default。三、访问你的 Knative Service在浏览器中打开上述 URL或直接通过命令行访问echo Accessing URL $(kn service describe hello -o url) curl $(kn service describe hello -o url)预期输出Hello World!遇到curl: (6) Could not resolve host怎么办如果看到curl: (6) Could not resolve host: hello.default.${LOADBALANCER_IP}.sslip.io通常是你的 DNS 服务器没有配置解析*.sslip.io地址。解决办法是换用一个可以解析这些地址的 nameserver具体步骤因发行版而异Ubuntu 等使用systemd-resolved的系统在/etc/systemd/resolved.conf中添加如下配置[Resolve] DNS8.8.8.8 Domains~sslip.io.然后重启服务sudo service systemd-resolved restartmacOS 用户可在系统网络设置中手动添加 DNS 与域名解析规则。四、观察自动缩容流量停止后缩容到零持续监听hello服务的 Pod 状态观察缩容到零的过程kubectl get pod -l serving.knative.dev/servicehello -w注意缩容到零可能需要最多 2 分钟。如果在缩容过程中再次访问服务会重置这个计时器。预期输出缩容过程NAME READY STATUS hello-world 2/2 Running hello-world 2/2 Terminating hello-world 1/2 Terminating hello-world 0/2 Terminating可以看到 Pod 从Running2/2逐步变为Terminating最终缩容到零。为什么会是 2 分钟从参考文档 scale-bounds.md 与 kpa-specific.md 可知KPA 在 stable 模式下基于stable-window默认60s滑动窗口内的平均并发来决策缩容到零时最后一个副本只会在整个 stable window 期间都没有流量之后才被移除。加上缩容需要逐轮收敛因此完整缩容到零通常需要约 12 分钟。另外scale-to-zero-grace-period默认30s还会为内部网络编程预留一个缓冲上限详见下文配置部分。五、扩容再次访问Pod 从零拉起重新在浏览器中访问该服务可以立刻看到一个新的 Pod 被拉起NAME READY STATUS hello-world 0/2 Pending hello-world 0/2 ContainerCreating hello-world 1/2 Running hello-world 2/2 RunningPod 依次经历Pending调度等待→ContainerCreating容器创建→1/2→2/2就绪从零恢复到运行状态。看完后按Ctrlc退出kubectl watch命令即可。六、深入原理KPA 的并发模型与缩放算法本教程中的hello服务规模很小扩容与缩容几乎是瞬时的。要真正理解 Knative 的自动扩缩容需要结合仓库中的 autoscale-go 示例应用 来剖析其算法。6.1 基于并发concurrency的目标模型Knative Serving 的自动扩缩容基于每个 Pod 的平均在途请求数并发度。系统默认的 目标并发为 100全局配置键container-concurrency-target-default而示例服务的 service.yaml 将其调整为 10apiVersion: serving.knative.dev/v1 kind: Service metadata: name: autoscale-go namespace: default spec: template: metadata: annotations: # 每个 Pod 的在途请求目标并发为 10。 autoscaling.knative.dev/target: 10 spec: containers: - image: ghcr.io/knative/autoscale-go:latest期望副本数的计算逻辑即期望副本数 平均在途请求数并发 / 目标并发当用 50 个并发请求压测该服务时50 / 10 5Autoscaler 便会拉起 5 个 Pod。6.2 Stable 与 Panic 双模式Autoscaler 在稳定窗口stable window默认 60s内计算平均并发因此系统大约需要 1 分钟才能稳定在期望的并发水平。与此同时Autoscaler 还维护一个更短的panic 窗口默认 6s即 stable window 的 10%当 panic 窗口内的并发达到目标并发的2 倍默认panic-threshold-percentage为 200时系统进入panic 模式改用更敏感的短窗口快速扩容以应对突发流量panic 模式下不会缩容以避免副本抖动churn当连续 60sstable window 时长没有触发快速反应的理由时系统退出 panic 模式回到正常的 stable 模式。注上图为 autoscale-go 示例运行时的真实请求仪表盘反映压测期间并发请求分布。6.3 示例应用是如何制造负载的autoscale.go 是一个可以按需消耗 CPU、内存与时间的 HTTP 服务它支持三个查询参数见 源码 handler 部分参数作用示例sleep睡眠指定毫秒数消耗时间sleep100prime计算小于该数的最大素数消耗 CPUprime10000bloat分配指定 MB 内存消耗内存bloat5三者通过sync.WaitGroup并发执行从而在一个请求内同时模拟时间、CPU 与内存压力。仓库还提供了配套的 load-generatortest/test.go以可配置的 QPS 与并发上限持续打流量并在运行中实时打印请求统计、成功率与平均延迟。6.4 实测压测实验使用hey负载生成工具go install github.com/rakyll/heylatest对 autoscale-go 施加 30 秒、50 个并发在途请求的压力hey -z 30s -c 50 \ http://autoscale-go.default.1.2.3.4.sslip.io?sleep100prime10000bloat5 \ kubectl get pods压测结果约178.78 req/s随后观察 Pod 数量会看到该服务被扩容到 5 个副本NAME READY STATUS RESTARTS AGE autoscale-go-00001-deployment-78cdc67bf4-2w4sk 3/3 Running 0 26s autoscale-go-00001-deployment-78cdc67bf4-dd2zb 3/3 Running 0 24s autoscale-go-00001-deployment-78cdc67bf4-pg55p 3/3 Running 0 18s autoscale-go-00001-deployment-78cdc67bf4-q8bf9 3/3 Running 0 1m autoscale-go-00001-deployment-78cdc67bf4-thjbq 3/3 Running 0 26s提示3/3 中的第 3 个容器是 Knative 注入的 queue-proxy sidecar负责并发排队与指标上报这正是 Autoscaler 获取并发指标的数据来源。七、配置体系全局配置与 per-revision 注解Knative 的扩缩容配置分为全局与每修订per-revision两类详见 autoscaler-types.md 的 Global versus per-revision settings 一节若 Revision 未指定任何 per-revision 配置则使用全局设置若两者同时存在per-revision 设置会覆盖全局设置。全局配置通过knative-serving命名空间下的config-autoscalerConfigMap 设置使用 Operator 安装时也可在KnativeServingCR 的spec.config.autoscaler中配置。默认的自动扩缩容 ConfigMap 内容如下见 autoscaler-types.mdapiVersion: v1 kind: ConfigMap metadata: name: config-autoscaler namespace: knative-serving data: container-concurrency-target-default: 100 container-concurrency-target-percentage: 0.7 enable-scale-to-zero: true max-scale-up-rate: 1000 max-scale-down-rate: 2 panic-window-percentage: 10 panic-threshold-percentage: 200 scale-to-zero-grace-period: 30s scale-to-zero-pod-retention-period: 0s stable-window: 60s target-burst-capacity: 200 requests-per-second-target-default: 200per-revision 配置通过给 Revision 模板添加autoscaling.knative.dev/...注解实现。重要如果通过 Service 或 Configuration 创建 Revision必须把注解写在revision 模板spec.template.metadata.annotations中这样每个新 Revision 都会继承写在单个 Revision 的顶层 metadata 中不会生效。八、关键配置参数详解8.1 缩容到零Scale to Zero缩容到零功能默认开启只能在使用 KPA 时启用且只能全局配置详见 scale-to-zero.md。配置全局键每修订注解取值默认值是否允许缩容到零enable-scale-to-zero无booleantrue缩容到零宽限期scale-to-zero-grace-period无Duration30s最后 Pod 保留期scale-to-zero-pod-retention-periodautoscaling.knative.dev/scale-to-zero-pod-retention-period非负 Duration0s三者含义差异enable-scale-to-zerofalse时副本最低缩到 1 而不是 0scale-to-zero-grace-period是系统内部等待 scale-from-zero 机制就位的时间上限一般不应调整除非遇到缩容到零过程中丢请求的问题它并不保证副本真的保留那么久scale-to-zero-pod-retention-period决定 Autoscaler 决定缩到零后最后 Pod 至少存活的时间与 grace-period上限互补。全局关闭缩容到零ConfigMap 方式apiVersion: v1 kind: ConfigMap metadata: name: config-autoscaler namespace: knative-serving data: enable-scale-to-zero: falseper-revision 保留最后 Pod 1 分钟apiVersion: serving.knative.dev/v1 kind: Service metadata: name: helloworld-go namespace: default spec: template: metadata: annotations: autoscaling.knative.dev/scale-to-zero-pod-retention-period: 1m5s spec: containers: - image: ghcr.io/knative/helloworld-go:latest8.2 缩放边界Scale Bounds通过上下界控制每个 Revision 的副本数详见 scale-bounds.md配置全局键每修订注解取值默认值下限min-scaleautoscaling.knative.dev/min-scaleintegerKPA 且开启缩容到零时为0否则为1上限max-scaleautoscaling.knative.dev/max-scaleinteger0不限初始规模initial-scale配合allow-zero-initial-scaleautoscaling.knative.dev/initial-scaleinteger1从零扩容的最小副本数无autoscaling.knative.dev/activation-scaleinteger1缩容延迟scale-down-delayautoscaling.knative.dev/scale-down-delay0s≤ Duration ≤1h0s要点说明初始规模Revision 创建后必须达到的初始目标副本数达到一次后即被忽略之后按实际流量缩容。创建 Revision 时会取 initial scale 与下限中的较大值作为初始目标。缩容延迟仅在默认 KPA 下支持。它规定在并发降低后、真正执行缩容前必须经过的等待窗口可用于避免冷启动惩罚与设置下限不同若低并发持续超过延迟窗口副本最终仍会被缩容。max-scale-limit全局键可以限制新 Revision 的全局/每修订最大规模上限。示例——限制副本数在 3100 之间apiVersion: serving.knative.dev/v1 kind: Service metadata: name: helloworld-go namespace: default spec: template: metadata: annotations: autoscaling.knative.dev/min-scale: 3 autoscaling.knative.dev/max-scale: 1008.3 指标类型MetricsAutoscaler 监控的指标类型通过autoscaling.knative.dev/metric注解配置详见 autoscaling-metrics.md指标支持方target 取值含义默认concurrencyKPA默认百分比配合target-utilization-percentage是rpsKPA整数每秒请求数否cpuHPA整数单位毫核millicore否memoryHPA整数单位 Mi否自定义指标HPA任意目标值否例如基于 RPS 扩缩容apiVersion: serving.knative.dev/v1 kind: Service metadata: name: helloworld-go namespace: default spec: template: metadata: annotations: autoscaling.knative.dev/metric: rps autoscaling.knative.dev/target: 1508.4 目标值Targetsautoscaling.knative.dev/target注解是指标无关的整数目标值适用于任何指标类型。全局默认并发目标为container-concurrency-target-default默认100全局默认 RPS 目标为requests-per-second-target-default默认200详见 rps-target.md。8.5 并发软限制与硬限制并发决定了每个副本同一时刻能处理的请求数详见 concurrency.md。当软硬限制同时存在时取较小值避免 Autoscaler 的目标超出硬限制。软限制目标型限制而非强制上限突发流量下可以超出。全局键container-concurrency-target-default每修订注解autoscaling.knative.dev/target默认100。硬限制强制上限达到后多余请求被缓冲排队等待容量空闲。通过 Revision spec 的containerConcurrency字段非注解配置默认0表示不限制。apiVersion: serving.knative.dev/v1 kind: Service metadata: name: helloworld-go namespace: default spec: template: spec: containerConcurrency: 50全局默认值可在config-defaults.yaml的container-concurrency键中设置。注意过低的硬限制可能损害吞吐与延迟并引发额外冷启动仅在明确适用场景下使用。目标利用率target utilization以百分比形式指定实际要达成的目标值即副本的热度使 Autoscaler 在硬限制达到之前就提前扩容。例如containerConcurrency10、利用率70时平均并发达到 7 就会创建新副本。全局键container-concurrency-target-percentage默认70每修订注解autoscaling.knative.dev/target-utilization-percentage。8.6 KPA 特有配置窗口与扩缩速率KPA 基于时间窗口内聚合的指标决策详见 kpa-specific.md。窗口越短Autoscaler 反应越快。配置全局键每修订注解取值范围默认值稳定窗口stable-windowautoscaling.knative.dev/window6s~1h60sPanic 窗口占比panic-window-percentageautoscaling.knative.dev/panic-window-percentage1.0~100.010.0Panic 触发阈值panic-threshold-percentageautoscaling.knative.dev/panic-threshold-percentage110.0~1000.0200.0最大扩容速率max-scale-up-rate无float1000.0最大缩容速率max-scale-down-rate无float2.0panic-window-percentage表示进入 panic 模式后历史数据评估窗口缩小为稳定窗口的百分比如10.0表示窗口变为稳定窗口的 10%。panic-threshold-percentage表示当前副本可承载流量的百分比阈值200.0意味着流量达到当前副本可承载量的 2 倍时进入 panic 模式。注意值不能设为100.0那会让 Autoscaler 永远处于 panic 模式。max-scale-up-rate决定单个评估周期内期望副本数与现有副本数的最大比值2.0表示一个周期内只能从N扩到2N。每个方向的最小变化始终允许 ±1 个副本。max-scale-down-rate同理控制缩容比值2.0表示一个周期内只能从N缩到N/2。九、从源码看 Autoscaler 的实现佐证本仓库虽以文档为主但 autoscale-go 给出了完整的实现与配套工具可作为理解本文全部内容的落地参照service.yaml 演示了autoscaling.knative.dev/target: 10注解的写法autoscale.go 通过sleep/prime/bloat三个参数并行消耗时间、CPU、内存为 Autoscaler 提供真实的并发压力test/test.go 实现了带 QPS/并发上限的负载生成器可精确控制压测强度Dockerfile 同时构建示例应用与load-generator两个二进制方便在集群内直接发起压测。在真实压测场景中可进一步尝试以下实验均来自 autoscale-go README 的 Other Experiments 一节# 60 秒、100 并发在途请求 hey -z 60s -c 100 \ http://autoscale-go.default.1.2.3.4.sslip.io?sleep100prime10000bloat5 # 60 秒、100 QPS、单请求 10ms观察高 QPS 低延迟下的缩放 hey -z 60s -q 100 \ http://autoscale-go.default.1.2.3.4.sslip.io?sleep10 # 60 秒、100 QPS、单请求 1s观察长请求下的并发堆积 hey -z 60s -q 100 \ http://autoscale-go.default.1.2.3.4.sslip.io?sleep1000 # 60 秒、100 QPS、重 CPU 计算prime40000000 hey -z 60s -q 100 \ http://autoscale-go.default.1.2.3.4.sslip.io?prime40000000 # 60 秒、5 并发、每请求分配 1GB 内存观察内存压力 hey -z 60s -c 5 \ http://autoscale-go.default.1.2.3.4.sslip.io?bloat1000实验结束后清理资源kubectl delete -f docs/versioned/serving/autoscaling/autoscale-go/service.yaml十、小结通过本教程你应当已经掌握使用kn service list/kubectl get ksvc查看服务并用curl访问 Knative Service通过kubectl get pod -l serving.knative.dev/servicehello -w观察「无流量缩容到零、来流量立即扩容」的完整生命周期KPA 基于并发目标的期望副本计算、stable/panic 双窗口算法全局config-autoscalerConfigMap 与 per-revision 注解两套配置体系以及缩容到零、缩放边界、指标类型、目标值、并发限制、窗口与速率等全部关键参数。如果希望进一步深入可继续阅读仓库中的 concurrency.md软/硬并发限制与目标利用率、autoscaling-metrics.md指标类型与 kpa-specific.mdKPA 特有窗口与速率参数。赞分享文档教程云原生【免费下载链接】docsUser documentation for Knative components.项目地址https://gitcode.com/gh_mirrors/docs1/docs点击查看免费下载相关推荐如何实现零缩扩容Knative Serving自动扩缩容机制揭秘如何实现零缩扩容Knative Serving自动扩缩容机制揭秘 在当今云原生时代 自动扩缩容 已成为现代应用架构的核心需求。Knative Serving云原生后端微服务Knative Serving 自动扩缩容实战PodAutoscaler 定制选项与从零到千级伸缩实践Knative Serving 自动扩缩容实战PodAutoscaler 定制选项与从零到千级伸缩实践 导读 本文以 Knative v0.3 发布中引入的自文档教程云原生GitHub_Trending/mi/minigame-unity-webgl-transform增量分包实现原理与操作步骤GitHub_Trending/mi/minigame unity webgl transform增量分包实现原理与操作步骤 你是否在开发微信小游戏时遇到过启云原生后端微服务上一篇终极小说下载器一键保存全网小说打造个人离线图书馆的完整指南下一篇Flet 应用自托管部署指南systemd 守护进程与 NGINX 反向代理完整实战创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/16 2:43:28 · 阅读 1.2k Knative Serving 自动扩缩容（Autoscaling）实战指南：从缩容到零到按需扩容
文档教程云原生【免费下载链接】docsUser documentation for Knative components.项目地址https://gitcode.com/gh_mirrors/docs1/docs点击查看免费下载导读本文基于 Knative 官方 Quickstart 教程中的 Autoscaling 主题完整演示如何查看、访问一个 Knative Service并观察其「无流量缩容到零、来流量立即扩容」的全过程随后结合本仓库的 autoscaling 参考文档 与 autoscale-go 示例应用深入讲解 Knative Pod AutoscalerKPA的并发模型、Stable/Panic 双模式算法以及全局与 per-revision 两类配置体系。读完本文你将能独立完成一次完整的「部署—压测—观察缩放—缩容到零—按需扩容」实验并掌握 Knative Serving 自动扩缩容的核心配置参数。一、什么是 Knative Serving AutoscalingKnative Serving 默认提供自动扩缩容能力即autoscaling一个 Knative Service 在没有流量时默认会缩容到零个运行中的 Pod不再占用集群资源一旦有请求到达系统又会自动拉起新的 Pod 处理流量并随着并发压力的上升/下降动态调整副本数量。这套能力由 Knative 自带的Knative Pod AutoscalerKPA提供它在 Knative Serving 安装完成后即默认启用。KPA 与 Kubernetes 原生 HPA 的能力对比如下详见 Supported Autoscaler types能力KPA默认HPA是否随 Serving 默认安装是Serving 核心自带否需另行安装是否支持缩容到零支持不支持是否支持基于 CPU 扩缩容不支持支持本教程属于 Quickstart 系列中的一环建议按顺序先完成 安装 Knativequickstart 与 部署第一个 Knative Service部署一个名为hello的示例服务再继续阅读本文。二、查看你的 Knative Service部署完成后先用knCLI 查看 Knative Service 的托管 URL kn 运行以下命令列出所有 Knative Servicebash kn service list预期输出bash NAME URL LATEST AGE CONDITIONS READY hello http://hello.default.${LOADBALANCER_IP}.sslip.io hello-00001 13s 3 OK / 3 True kubectl 也可以使用 kubectl 查看bash kubectl get ksvc预期输出bash NAME URL LATESTCREATED LATESTREADY READY REASON hello http://hello.default.${LOADBALANCER_IP}.sslip.io hello-00001 hello-00001 True其中${LOADBALANCER_IP}依集群类型而不同kind集群下通常是127.0.0.1minikube集群则取决于本地 tunnel 配置。URL 中的hello.default表示服务名为hello、命名空间为default。三、访问你的 Knative Service在浏览器中打开上述 URL或直接通过命令行访问echo Accessing URL $(kn service describe hello -o url) curl $(kn service describe hello -o url)预期输出Hello World!遇到curl: (6) Could not resolve host怎么办如果看到curl: (6) Could not resolve host: hello.default.${LOADBALANCER_IP}.sslip.io通常是你的 DNS 服务器没有配置解析*.sslip.io地址。解决办法是换用一个可以解析这些地址的 nameserver具体步骤因发行版而异Ubuntu 等使用systemd-resolved的系统在/etc/systemd/resolved.conf中添加如下配置[Resolve] DNS8.8.8.8 Domains~sslip.io.然后重启服务sudo service systemd-resolved restartmacOS 用户可在系统网络设置中手动添加 DNS 与域名解析规则。四、观察自动缩容流量停止后缩容到零持续监听hello服务的 Pod 状态观察缩容到零的过程kubectl get pod -l serving.knative.dev/servicehello -w注意缩容到零可能需要最多 2 分钟。如果在缩容过程中再次访问服务会重置这个计时器。预期输出缩容过程NAME READY STATUS hello-world 2/2 Running hello-world 2/2 Terminating hello-world 1/2 Terminating hello-world 0/2 Terminating可以看到 Pod 从Running2/2逐步变为Terminating最终缩容到零。为什么会是 2 分钟从参考文档 scale-bounds.md 与 kpa-specific.md 可知KPA 在 stable 模式下基于stable-window默认60s滑动窗口内的平均并发来决策缩容到零时最后一个副本只会在整个 stable window 期间都没有流量之后才被移除。加上缩容需要逐轮收敛因此完整缩容到零通常需要约 12 分钟。另外scale-to-zero-grace-period默认30s还会为内部网络编程预留一个缓冲上限详见下文配置部分。五、扩容再次访问Pod 从零拉起重新在浏览器中访问该服务可以立刻看到一个新的 Pod 被拉起NAME READY STATUS hello-world 0/2 Pending hello-world 0/2 ContainerCreating hello-world 1/2 Running hello-world 2/2 RunningPod 依次经历Pending调度等待→ContainerCreating容器创建→1/2→2/2就绪从零恢复到运行状态。看完后按Ctrlc退出kubectl watch命令即可。六、深入原理KPA 的并发模型与缩放算法本教程中的hello服务规模很小扩容与缩容几乎是瞬时的。要真正理解 Knative 的自动扩缩容需要结合仓库中的 autoscale-go 示例应用 来剖析其算法。6.1 基于并发concurrency的目标模型Knative Serving 的自动扩缩容基于每个 Pod 的平均在途请求数并发度。系统默认的 目标并发为 100全局配置键container-concurrency-target-default而示例服务的 service.yaml 将其调整为 10apiVersion: serving.knative.dev/v1 kind: Service metadata: name: autoscale-go namespace: default spec: template: metadata: annotations: # 每个 Pod 的在途请求目标并发为 10。 autoscaling.knative.dev/target: 10 spec: containers: - image: ghcr.io/knative/autoscale-go:latest期望副本数的计算逻辑即期望副本数 平均在途请求数并发 / 目标并发当用 50 个并发请求压测该服务时50 / 10 5Autoscaler 便会拉起 5 个 Pod。6.2 Stable 与 Panic 双模式Autoscaler 在稳定窗口stable window默认 60s内计算平均并发因此系统大约需要 1 分钟才能稳定在期望的并发水平。与此同时Autoscaler 还维护一个更短的panic 窗口默认 6s即 stable window 的 10%当 panic 窗口内的并发达到目标并发的2 倍默认panic-threshold-percentage为 200时系统进入panic 模式改用更敏感的短窗口快速扩容以应对突发流量panic 模式下不会缩容以避免副本抖动churn当连续 60sstable window 时长没有触发快速反应的理由时系统退出 panic 模式回到正常的 stable 模式。注上图为 autoscale-go 示例运行时的真实请求仪表盘反映压测期间并发请求分布。6.3 示例应用是如何制造负载的autoscale.go 是一个可以按需消耗 CPU、内存与时间的 HTTP 服务它支持三个查询参数见 源码 handler 部分参数作用示例sleep睡眠指定毫秒数消耗时间sleep100prime计算小于该数的最大素数消耗 CPUprime10000bloat分配指定 MB 内存消耗内存bloat5三者通过sync.WaitGroup并发执行从而在一个请求内同时模拟时间、CPU 与内存压力。仓库还提供了配套的 load-generatortest/test.go以可配置的 QPS 与并发上限持续打流量并在运行中实时打印请求统计、成功率与平均延迟。6.4 实测压测实验使用hey负载生成工具go install github.com/rakyll/heylatest对 autoscale-go 施加 30 秒、50 个并发在途请求的压力hey -z 30s -c 50 \ http://autoscale-go.default.1.2.3.4.sslip.io?sleep100prime10000bloat5 \ kubectl get pods压测结果约178.78 req/s随后观察 Pod 数量会看到该服务被扩容到 5 个副本NAME READY STATUS RESTARTS AGE autoscale-go-00001-deployment-78cdc67bf4-2w4sk 3/3 Running 0 26s autoscale-go-00001-deployment-78cdc67bf4-dd2zb 3/3 Running 0 24s autoscale-go-00001-deployment-78cdc67bf4-pg55p 3/3 Running 0 18s autoscale-go-00001-deployment-78cdc67bf4-q8bf9 3/3 Running 0 1m autoscale-go-00001-deployment-78cdc67bf4-thjbq 3/3 Running 0 26s提示3/3 中的第 3 个容器是 Knative 注入的 queue-proxy sidecar负责并发排队与指标上报这正是 Autoscaler 获取并发指标的数据来源。七、配置体系全局配置与 per-revision 注解Knative 的扩缩容配置分为全局与每修订per-revision两类详见 autoscaler-types.md 的 Global versus per-revision settings 一节若 Revision 未指定任何 per-revision 配置则使用全局设置若两者同时存在per-revision 设置会覆盖全局设置。全局配置通过knative-serving命名空间下的config-autoscalerConfigMap 设置使用 Operator 安装时也可在KnativeServingCR 的spec.config.autoscaler中配置。默认的自动扩缩容 ConfigMap 内容如下见 autoscaler-types.mdapiVersion: v1 kind: ConfigMap metadata: name: config-autoscaler namespace: knative-serving data: container-concurrency-target-default: 100 container-concurrency-target-percentage: 0.7 enable-scale-to-zero: true max-scale-up-rate: 1000 max-scale-down-rate: 2 panic-window-percentage: 10 panic-threshold-percentage: 200 scale-to-zero-grace-period: 30s scale-to-zero-pod-retention-period: 0s stable-window: 60s target-burst-capacity: 200 requests-per-second-target-default: 200per-revision 配置通过给 Revision 模板添加autoscaling.knative.dev/...注解实现。重要如果通过 Service 或 Configuration 创建 Revision必须把注解写在revision 模板spec.template.metadata.annotations中这样每个新 Revision 都会继承写在单个 Revision 的顶层 metadata 中不会生效。八、关键配置参数详解8.1 缩容到零Scale to Zero缩容到零功能默认开启只能在使用 KPA 时启用且只能全局配置详见 scale-to-zero.md。配置全局键每修订注解取值默认值是否允许缩容到零enable-scale-to-zero无booleantrue缩容到零宽限期scale-to-zero-grace-period无Duration30s最后 Pod 保留期scale-to-zero-pod-retention-periodautoscaling.knative.dev/scale-to-zero-pod-retention-period非负 Duration0s三者含义差异enable-scale-to-zerofalse时副本最低缩到 1 而不是 0scale-to-zero-grace-period是系统内部等待 scale-from-zero 机制就位的时间上限一般不应调整除非遇到缩容到零过程中丢请求的问题它并不保证副本真的保留那么久scale-to-zero-pod-retention-period决定 Autoscaler 决定缩到零后最后 Pod 至少存活的时间与 grace-period上限互补。全局关闭缩容到零ConfigMap 方式apiVersion: v1 kind: ConfigMap metadata: name: config-autoscaler namespace: knative-serving data: enable-scale-to-zero: falseper-revision 保留最后 Pod 1 分钟apiVersion: serving.knative.dev/v1 kind: Service metadata: name: helloworld-go namespace: default spec: template: metadata: annotations: autoscaling.knative.dev/scale-to-zero-pod-retention-period: 1m5s spec: containers: - image: ghcr.io/knative/helloworld-go:latest8.2 缩放边界Scale Bounds通过上下界控制每个 Revision 的副本数详见 scale-bounds.md配置全局键每修订注解取值默认值下限min-scaleautoscaling.knative.dev/min-scaleintegerKPA 且开启缩容到零时为0否则为1上限max-scaleautoscaling.knative.dev/max-scaleinteger0不限初始规模initial-scale配合allow-zero-initial-scaleautoscaling.knative.dev/initial-scaleinteger1从零扩容的最小副本数无autoscaling.knative.dev/activation-scaleinteger1缩容延迟scale-down-delayautoscaling.knative.dev/scale-down-delay0s≤ Duration ≤1h0s要点说明初始规模Revision 创建后必须达到的初始目标副本数达到一次后即被忽略之后按实际流量缩容。创建 Revision 时会取 initial scale 与下限中的较大值作为初始目标。缩容延迟仅在默认 KPA 下支持。它规定在并发降低后、真正执行缩容前必须经过的等待窗口可用于避免冷启动惩罚与设置下限不同若低并发持续超过延迟窗口副本最终仍会被缩容。max-scale-limit全局键可以限制新 Revision 的全局/每修订最大规模上限。示例——限制副本数在 3100 之间apiVersion: serving.knative.dev/v1 kind: Service metadata: name: helloworld-go namespace: default spec: template: metadata: annotations: autoscaling.knative.dev/min-scale: 3 autoscaling.knative.dev/max-scale: 1008.3 指标类型MetricsAutoscaler 监控的指标类型通过autoscaling.knative.dev/metric注解配置详见 autoscaling-metrics.md指标支持方target 取值含义默认concurrencyKPA默认百分比配合target-utilization-percentage是rpsKPA整数每秒请求数否cpuHPA整数单位毫核millicore否memoryHPA整数单位 Mi否自定义指标HPA任意目标值否例如基于 RPS 扩缩容apiVersion: serving.knative.dev/v1 kind: Service metadata: name: helloworld-go namespace: default spec: template: metadata: annotations: autoscaling.knative.dev/metric: rps autoscaling.knative.dev/target: 1508.4 目标值Targetsautoscaling.knative.dev/target注解是指标无关的整数目标值适用于任何指标类型。全局默认并发目标为container-concurrency-target-default默认100全局默认 RPS 目标为requests-per-second-target-default默认200详见 rps-target.md。8.5 并发软限制与硬限制并发决定了每个副本同一时刻能处理的请求数详见 concurrency.md。当软硬限制同时存在时取较小值避免 Autoscaler 的目标超出硬限制。软限制目标型限制而非强制上限突发流量下可以超出。全局键container-concurrency-target-default每修订注解autoscaling.knative.dev/target默认100。硬限制强制上限达到后多余请求被缓冲排队等待容量空闲。通过 Revision spec 的containerConcurrency字段非注解配置默认0表示不限制。apiVersion: serving.knative.dev/v1 kind: Service metadata: name: helloworld-go namespace: default spec: template: spec: containerConcurrency: 50全局默认值可在config-defaults.yaml的container-concurrency键中设置。注意过低的硬限制可能损害吞吐与延迟并引发额外冷启动仅在明确适用场景下使用。目标利用率target utilization以百分比形式指定实际要达成的目标值即副本的热度使 Autoscaler 在硬限制达到之前就提前扩容。例如containerConcurrency10、利用率70时平均并发达到 7 就会创建新副本。全局键container-concurrency-target-percentage默认70每修订注解autoscaling.knative.dev/target-utilization-percentage。8.6 KPA 特有配置窗口与扩缩速率KPA 基于时间窗口内聚合的指标决策详见 kpa-specific.md。窗口越短Autoscaler 反应越快。配置全局键每修订注解取值范围默认值稳定窗口stable-windowautoscaling.knative.dev/window6s~1h60sPanic 窗口占比panic-window-percentageautoscaling.knative.dev/panic-window-percentage1.0~100.010.0Panic 触发阈值panic-threshold-percentageautoscaling.knative.dev/panic-threshold-percentage110.0~1000.0200.0最大扩容速率max-scale-up-rate无float1000.0最大缩容速率max-scale-down-rate无float2.0panic-window-percentage表示进入 panic 模式后历史数据评估窗口缩小为稳定窗口的百分比如10.0表示窗口变为稳定窗口的 10%。panic-threshold-percentage表示当前副本可承载流量的百分比阈值200.0意味着流量达到当前副本可承载量的 2 倍时进入 panic 模式。注意值不能设为100.0那会让 Autoscaler 永远处于 panic 模式。max-scale-up-rate决定单个评估周期内期望副本数与现有副本数的最大比值2.0表示一个周期内只能从N扩到2N。每个方向的最小变化始终允许 ±1 个副本。max-scale-down-rate同理控制缩容比值2.0表示一个周期内只能从N缩到N/2。九、从源码看 Autoscaler 的实现佐证本仓库虽以文档为主但 autoscale-go 给出了完整的实现与配套工具可作为理解本文全部内容的落地参照service.yaml 演示了autoscaling.knative.dev/target: 10注解的写法autoscale.go 通过sleep/prime/bloat三个参数并行消耗时间、CPU、内存为 Autoscaler 提供真实的并发压力test/test.go 实现了带 QPS/并发上限的负载生成器可精确控制压测强度Dockerfile 同时构建示例应用与load-generator两个二进制方便在集群内直接发起压测。在真实压测场景中可进一步尝试以下实验均来自 autoscale-go README 的 Other Experiments 一节# 60 秒、100 并发在途请求 hey -z 60s -c 100 \ http://autoscale-go.default.1.2.3.4.sslip.io?sleep100prime10000bloat5 # 60 秒、100 QPS、单请求 10ms观察高 QPS 低延迟下的缩放 hey -z 60s -q 100 \ http://autoscale-go.default.1.2.3.4.sslip.io?sleep10 # 60 秒、100 QPS、单请求 1s观察长请求下的并发堆积 hey -z 60s -q 100 \ http://autoscale-go.default.1.2.3.4.sslip.io?sleep1000 # 60 秒、100 QPS、重 CPU 计算prime40000000 hey -z 60s -q 100 \ http://autoscale-go.default.1.2.3.4.sslip.io?prime40000000 # 60 秒、5 并发、每请求分配 1GB 内存观察内存压力 hey -z 60s -c 5 \ http://autoscale-go.default.1.2.3.4.sslip.io?bloat1000实验结束后清理资源kubectl delete -f docs/versioned/serving/autoscaling/autoscale-go/service.yaml十、小结通过本教程你应当已经掌握使用kn service list/kubectl get ksvc查看服务并用curl访问 Knative Service通过kubectl get pod -l serving.knative.dev/servicehello -w观察「无流量缩容到零、来流量立即扩容」的完整生命周期KPA 基于并发目标的期望副本计算、stable/panic 双窗口算法全局config-autoscalerConfigMap 与 per-revision 注解两套配置体系以及缩容到零、缩放边界、指标类型、目标值、并发限制、窗口与速率等全部关键参数。如果希望进一步深入可继续阅读仓库中的 concurrency.md软/硬并发限制与目标利用率、autoscaling-metrics.md指标类型与 kpa-specific.mdKPA 特有窗口与速率参数。赞分享文档教程云原生【免费下载链接】docsUser documentation for Knative components.项目地址https://gitcode.com/gh_mirrors/docs1/docs点击查看免费下载相关推荐如何实现零缩扩容Knative Serving自动扩缩容机制揭秘如何实现零缩扩容Knative Serving自动扩缩容机制揭秘 在当今云原生时代 自动扩缩容 已成为现代应用架构的核心需求。Knative Serving云原生后端微服务Knative Serving 自动扩缩容实战PodAutoscaler 定制选项与从零到千级伸缩实践Knative Serving 自动扩缩容实战PodAutoscaler 定制选项与从零到千级伸缩实践 导读 本文以 Knative v0.3 发布中引入的自文档教程云原生GitHub_Trending/mi/minigame-unity-webgl-transform增量分包实现原理与操作步骤GitHub_Trending/mi/minigame unity webgl transform增量分包实现原理与操作步骤 你是否在开发微信小游戏时遇到过启云原生后端微服务上一篇终极小说下载器一键保存全网小说打造个人离线图书馆的完整指南下一篇Flet 应用自托管部署指南systemd 守护进程与 NGINX 反向代理完整实战创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考