火山引擎容器服务（VKE）支持根据业务负载变化自动调整工作负载的 Pod 副本数，帮助您在流量高峰时增加处理能力、在低谷时减少资源闲置。本文介绍指标伸缩（HPA）、定时伸缩（CronHPA）、事件驱动伸缩（KEDA）和智能伸缩（IHPA）的适用场景、配置建议及常见问题。 ## 应用场景 |**业务场景** |**常见诉求** |**伸缩建议** | |---|---|---| |在线业务流量波动 |请求量上升时保障响应时间，低谷时减少空闲资源。 |选择能反映应用压力的指标，自动调整副本数。 | |促销、直播或固定时段高峰 |在活动开始前完成应用预热，减少等待扩容的时间。 |按已知高峰安排提前扩容，并保留实时指标伸缩。 | |消息消费与异步任务 |加快处理积压，空闲时减少常驻消费者。 |根据队列或任务量伸缩；可以接受冷启动时评估缩至零。 | |具有稳定周期的业务 |根据历史规律提前准备容量，减少人工维护定时规则。 |先预览预测结果，再逐步启用智能伸缩。 | ## 选择伸缩方式 |**业务场景** |**推荐方式** |**主要作用** | |---|---|---| |在线服务随实时负载变化 |指标伸缩（HPA） |根据 CPU、内存或业务指标自动调整 Pod 副本数。 | |促销、直播等高峰时间已知 |定时伸缩（CronHPA） |在预设时间调整副本数，提前为业务高峰准备容量。 | |队列消费、事件处理或按需执行任务 |事件驱动伸缩（KEDA） |根据队列积压或事件量伸缩，支持空闲时缩至零。 | |业务流量具有稳定周期 |智能伸缩（IHPA） |根据历史数据预测需求，提前调整副本数。 | 根据业务场景选择伸缩方式后，可在下文查看配置步骤。需要组合使用时，请参见 [兼容性说明](https://docs.volcengine.com/docs/6460/1452993#Pk85fARw)。 ![图片](https://portal.volccdn.com/obj/volcfe/cloud-universal-doc/upload_fb9b8ae9ae80f612bfac8128b1a0867d.png) ## 前提条件 |**准备项** |**要求** | |---|---| |集群与权限 |* 已创建 VKE 集群，具备目标命名空间中工作负载和伸缩策略的管理权限。

* 新建或升级集群时选择仍在维护期内的版本。 | |伸缩组件 |通过 VKE 组件管理安装所选方案依赖的组件，包括但不限于 Metrics Server、Prometheus Adapter、CronHPA、Keda、Katalyst 等组件。 | |应用与指标 |* 应用能够通过增加副本分担负载，已配置资源请求和健康探针。

* 配置策略前确认指标有值、单位正确且能反映业务压力。

* 指标组件仅授予必要的查询与对象访问权限，认证信息通过 Secret 等受支持方式引用。 | |可用容量 |* 节点资源或 VCI 能够承载新增 Pod。

* 配额、IP、存储和下游服务容量满足预期峰值。 | |已有策略 |检查目标工作负载已有的 HPA、CronHPA、ScaledObject、IHPA 和发布配置，明确后续由哪个策略管理副本数。 |

说明

CronHPA、KEDA 默认已启用高可用配置。为控制资源消耗，组件工作负载默认仍以单副本运行；如需更高的可用性，可直接对相应组件工作负载进行水平扩容，增加副本数。

本文的伸缩示例以 Deployment 为主。StatefulSet 需先具备成员加入、退出及数据迁移能力；自定义工作负载需提供 Scale 子资源和准确的 Pod 选择器。DaemonSet 不适用 HPA；按需执行并结束的任务参见事件驱动伸缩（KEDA）中的任务模式说明。

HPA 控制器由 Kubernetes 控制面提供，若应用不能通过增加副本分担负载，应先调整架构或为单实例增加资源冗余。

## 应用配置建议 ### 根据服务目标确定容量先根据业务要求确定响应时间、错误率和可接受的队列等待时间，再通过压测测量单个就绪副本的安全吞吐量。扩容耗时包括指标采集、控制器计算、Pod 调度、节点准备、镜像拉取、应用启动及流量接入；应观测从负载上升到新增副本开始处理请求的总时间，并据此安排预扩容和基础副本。控制器的检查周期不等于扩容完成时间。可使用以下公式估算副本范围和扩容提前量。其中：ceil 表示向上取整；单副本处理能力和扩容耗时需要通过业务压测获得。 ```Plain Text 在线服务所需副本 ≈ ceil(预计请求速率 / 单副本安全请求速率) 队列消费者所需副本 ≈ ceil((持续到达速率 + 当前积压 / 目标清空时间) / 单副本处理速率) 扩容提前量 ≥ 实测端到端扩容耗时的高分位值 + 业务安全余量 ``` 例如，每个副本每秒稳定处理 20 条消息，当前积压 6000 条，希望在 30 秒内清空：没有新消息时，估算需要 10 个副本；若每秒仍新增 80 条，则需要 14 个副本。实际规划还应为重试、分区不均和消费重平衡预留余量。配置 KEDA 时，需再将处理能力换算为所选触发器的目标值。 minReplicas 应覆盖最低可用容量和冷启动期间的需求。在线服务可从 2～3 个副本开始评估，并结合可用区分布与故障容忍要求调整。maxReplicas 应同时考虑节点容量、IP、资源配额、GPU 库存、数据库连接数、下游限流和消费分区数，避免应用扩容后将压力转移到下游。 |**容量检查** |**配置与验证建议** | |---|---| |新增 Pod 能否调度 |按节点 Allocatable 计算可用资源，并计入系统组件、DaemonSet 和整个 Pod 的开销。检查 nodeSelector/nodeAffinity、污点与 tolerations、GPU 规格、存储可用区及 IP 配额；在节点池模板层维护标签和污点，使新节点具备同样条件。 | |副本打散与可用区容量 |通过拓扑分布约束或反亲和性分散副本。使用 topologySpreadConstraints 时，以 topologyKey 选择节点或可用区，maxSkew 控制分布偏差，labelSelector 选中同组 Pod，whenUnsatisfiable 决定不满足时能否调度。硬性约束可能阻塞扩容，应验证单可用区故障和峰值容量，按可用性目标评估软性约束。 | |节点准备是否满足响应时间 |HPA 增加期望副本后，仍需节点或 VCI 提供可调度容量。使用 Karpenter 或 Cluster Autoscaler 对节点进行伸缩时，通常由无法调度的 Pod 和资源请求触发节点扩容，不能把节点 CPU 利用率视为同一触发条件。对响应时间严格的业务，提前保留可调度余量或使用定时/预测扩容。 | |预留容量与伸缩组件 |如使用低优先级占位 Pod 预留容量，验证资源量、节点池匹配、业务抢占及占位 Pod 触发补容的条件，并核算闲置成本。为指标服务、伸缩控制器、DNS 等关键组件保留常驻容量，使用 VKE 支持的高可用配置，避免业务缩至零后失去恢复能力。 | |下游连接与服务发现 |将峰值副本数乘以每副本最大连接数或并发数，与数据库、缓存和外部 API 额度比较，并计入滚动发布及尚未退出的连接。必要时限制每副本连接池和并发。核对入口后端数与 Service 规模限制，自有服务发现组件应正确处理 EndpointSlice 的变化。 | |批量启动的附加开销 |观察网络初始化、准入 Webhook 超时与 DNS 请求是否拖慢新 Pod 创建，避免让无关的准入调用影响扩容。应用不访问 Kubernetes API 时，可按需关闭 ServiceAccount 凭证自动挂载；不依赖 Service 环境变量时可评估关闭 enableServiceLinks 并使用 DNS。静态 Secret 的更新流程允许时，可评估 immutable 配置。 | ### 合理声明 requests 与 limits 使用 CPU 或内存利用率（Utilization）伸缩前，为参与计算的容器设置对应的资源请求量（requests）。利用率按实际用量与请求量计算；资源使用上限（limits）不参与这一计算。缺少对应请求量会导致该指标计算失败，其他健康指标仍可能驱动扩容。外部业务指标不直接按 requests 计算，但 Pod 调度和节点容量规划仍需要合理的请求量。如果命名空间使用 LimitRange 设置默认资源值，检查实际创建的 Pod 是否获得了预期配置。结合稳态与峰值用量、CPU 限流、内存工作集和 OOM 情况设置 requests 与 limits。JVM 堆、缓存、GPU 模型内存等业务特征会影响资源需求，应通过压测确定配置。调整 CPU request 后，重新检查 HPA 目标利用率及单副本实际容量。内存工作集（working set）是对容器当前仍在使用的内存的估算，Metrics Server 采用这一口径上报内存用量。它包含进程使用的内存，也可能包含部分活跃的文件缓存，因此不等同于 RSS（常驻内存），也不是扣除全部缓存后的内存用量。对于每个容器的 resources 中设置的资源，应用使用 Pod 级资源配置时，请先确认指标组件和伸缩控制器支持该配置，再迁移现有策略。 ### 配置健康检查、预热与优雅退出 * **启动探针 ** 覆盖初始化、缓存预热和模型加载等阶段；**就绪探针 ** 在应用能够接收请求后返回成功；**存活探针 ** 检测需要重启才能恢复的进程故障。 * 存活探针应重点检查应用进程自身，避免数据库或缓存短暂异常导致所有 Pod 同时重启。就绪探针是否检查外部依赖，应结合应用的降级能力决定，避免一次依赖故障使所有副本同时停止接收流量。 * 应用启动时 CPU 用量较高，可通过启动和就绪探针区分初始化阶段，并检查 HPA 在启动期间的指标处理，避免仅提高 CPU 阈值而降低正常流量下的扩容敏感度。 * 使用长连接的服务，应通过入口负载均衡、连接重建或应用分片，让新增副本分担请求；已有连接不会自动迁移到新 Pod。 * 为缩容配置优雅退出：处理 SIGTERM，停止接收新请求或新任务，完成在途请求并提交消费进度。preStop 的执行时间计入终止宽限期；从负载均衡中移除 Pod 与容器终止是异步过程，需要结合应用处理进度确认退出时机。启动探针成功前，存活和就绪探针不会执行。按真实启动耗时设置探测周期、失败次数及超时；探针应保持轻量，避免高负载时反而增加应用压力。确认终止信号能够到达应用进程。容器入口使用 shell 脚本时，应通过 exec 启动应用，或由入口进程正确转发 SIGTERM 并回收子进程。验证正常缩容和节点维护时，请求排空与进度提交都能在宽限期内完成。以下为需要合并到 Deployment Pod 模板的片段。镜像、资源、探针路径和时长均为示例；应用应实现对应健康接口和 SIGTERM 处理。 ```YAML spec: template: spec: terminationGracePeriodSeconds: 90 containers: - name: app image: registry.example.com/team/app:release ports: - containerPort: 8080 resources: requests: cpu: "500m" memory: "512Mi" limits: memory: "1Gi" startupProbe: httpGet: path: /startup port: 8080 periodSeconds: 5 failureThreshold: 60 readinessProbe: httpGet: path: /ready port: 8080 periodSeconds: 5 livenessProbe: httpGet: path: /live port: 8080 periodSeconds: 10 ``` ### 保护有状态应用与业务可用性将会话、任务进度和持久数据保存到可恢复的存储中，或通过应用自身的复制机制保护数据。消费者应支持幂等处理，避免重启或重新分配任务后产生重复结果。为数据库等有状态应用启用自动伸缩前，确认应用支持成员加入和退出，并已处理分片迁移、仲裁及存储变化。仅创建 StatefulSet 还不足以保证这些过程安全完成。配置 Pod 中断预算（PDB），限制节点维护或节点缩容通过 Eviction API 驱逐的 Pod 数量。**PDB 不限制 HPA 缩容，也不阻止工作负载控制器直接删除 Pod。** HPA 缩容时的业务可用性，应通过最小副本数、behavior.scaleDown 和应用优雅退出共同保障；滚动发布另外配置 maxUnavailable、maxSurge。 HPA 决定期望副本数，具体删除哪些 Pod 由工作负载控制器负责，不能依靠 HPA 优先删除空闲 Pod。长任务应使用检查点、可重试的幂等处理或适合的 Job 模式；发布期间也要为 maxSurge 和正在终止的 Pod 预留额外资源，maxReplicas 不是实际 Pod 总数的绝对上限。 ```YAML apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: web-pdb namespace: autoscaling-demo spec: maxUnavailable: 1 selector: matchLabels: app: web ``` 上述 PDB 示例按最少 3 个业务副本设计，允许同时有 1 个副本因驱逐而不可用。根据业务容错能力调整该值；过严的中断预算可能阻塞节点维护，使用百分比时还需检查低副本数下的取整结果。 StatefulSet 的 PVC 保留策略在 Kubernetes 1.32 进入稳定阶段。需要保留缩容实例数据时，在 persistentVolumeClaimRetentionPolicy 中设置 whenScaled: Retain；设为 Delete 时，控制器会在满足清理条件后删除相关 PVC。 ## 指标伸缩（HPA） HPA 根据 CPU、内存或业务指标自动调整 Pod 副本数，适合负载变化可以通过实时指标反映的应用。建议先选择与单副本处理能力相关的指标，再设置副本范围、扩容速度和缩容稳定窗口。 ### 指标类型如何选择 |**指标** |**适用场景** |**配置建议** | |---|---|---| |CPU 利用率（Utilization） |CPU 与业务压力关联明确 |结合 CPU 限流、排队与延迟确定目标；50%～70% 可作为候选范围，不是统一标准。 | |CPU/内存绝对用量（AverageValue） |以绝对用量确定单副本目标 |直接设置每个副本的目标用量，确认 CPU 与内存的计量单位。 | |内存利用率/工作集 |内存可随副本分摊且能回落 |资源指标中的内存采用工作集口径。检查负载回落后能否释放；JVM 堆、缓存与内存泄漏可能使缩容长期受阻，增加副本不能修复泄漏。 | |Java 服务内存 |需要区分常驻内存与活跃文件缓存的影响 |对比 container_memory_rss 与 container_memory_working_set_bytes。前者可作为减少文件缓存影响的候选，但不是 JVM 堆专属指标；结合堆、堆外内存和 GC，在加压及负载回落阶段确认其与单副本容量的关系。RSS 需作为自定义指标接入。 | |QPS/并发请求数 |单副本处理能力可量化 |以满足响应时间目标时的单副本吞吐或并发数设置阈值，通过指标适配器接入；结合请求开销差异和流量分配检查热点。 | |网络吞吐/带宽/包速率 |单副本瓶颈是网络传输，且新增副本可分担流量 |按瓶颈选择接收或发送吞吐；小包密集场景还可评估每秒包数。累计字节数或包数先换算为速率，并明确 B/s、bit/s 或包/s。结合报文大小、连接数和单副本安全吞吐压测，同时确认节点带宽及后端能力；QPS 不能替代字节吞吐。 | |磁盘吞吐/IOPS |请求可以分散到多个副本及其存储 |当瓶颈来自单副本 I/O 且增加副本能分担读写时，可将读写吞吐或 IOPS 接入自定义指标。先确认卷和存储服务的总吞吐、IOPS 限额及数据一致性；多个副本共用同一受限后端时，单纯加副本可能加重瓶颈。 | |队列长度/消息年龄 |消费能力与积压相关 |积压驱动容量，消息年龄验证等待时间；留意新增消息、分区与重试。 | |GPU/推理指标 |CPU 不能反映推理瓶颈 |可评估 DCGM_FI_DEV_GPU_UTIL（GPU 利用率，通常为 0～100）及 DCGM_FI_PROF_SM_ACTIVE（流多处理器 SM 至少有一个线程束 warp 活跃的时间比例，通常为 0～1，跨 SM 平均）。两者口径不同，均不等同于显存占用或有效算力效率；结合请求排队、在途请求和首个输出 Token 延迟，按模型与批处理方式压测。 |

说明

控制台配置步骤参见使用 CPU 和内存指标；GPU 和网络指标的接入步骤参见使用 GPU 和网络指标。

### 确认指标单位与采集范围配置阈值前，确认指标的数据源、HPA 指标类型、单位和聚合范围。HPA 通过 Kubernetes API 聚合层读取指标，再由对应的指标服务查询数据源。下表中的请求路径是 Kubernetes API 路径，Prometheus/VMP 的查询地址配置在指标组件中。 |**指标示例** |**数据源与获取方式** |**HPA 指标类型** |**聚合 API 请求路径** |**单位与配置要点** | |---|---|---|---|---| |业务容器 CPU 利用率 |kubelet → metrics\-server |ContainerResource |/apis/metrics.k8s.io/v1beta1/namespaces/{namespace}/pods |CPU 用量/容器 requests，按百分比设置目标。确认业务容器名称和 CPU request；CPU、内存均从 PodMetrics 读取，路径末尾不追加 cpu 或 memory。 | |每 Pod QPS |应用或入口 → Prometheus/VMP → Prometheus Adapter |Pods |/apis/custom.metrics.k8s.io/v1beta2/namespaces/{namespace}/pods/\*/{metric_name} |每秒请求数，按 Pod 映射。累计请求数先换算为速率，并按集群、命名空间和工作负载过滤与去重。 | |Java 服务 RSS |kubelet/cAdvisor → Prometheus/VMP → Prometheus Adapter |Pods |/apis/custom.metrics.k8s.io/v1beta2/namespaces/{namespace}/pods/\*/{metric_name} |container_memory_rss 是 Gauge，单位为字节，无需计算速率。按业务容器筛选、去重并聚合到 Pod，映射为每 Pod 自定义指标；阈值与实际暴露单位保持一致。 | |每 Pod 网络吞吐 |kubelet/cAdvisor → Prometheus/VMP → Prometheus Adapter |Pods |/apis/custom.metrics.k8s.io/v1beta2/namespaces/{namespace}/pods/\*/{metric_name} |对 container_network_receive_bytes_total 或 container_network_transmit_bytes_total 使用 rate 得到 B/s，换算为 bit/s 时乘 8。确认 Pod 与接口映射，去除共享网络命名空间导致的重复序列，再按 Pod 汇总。 | |消息队列积压 |队列服务或独立导出器 → KEDA |External |/apis/external.metrics.k8s.io/v1beta1/namespaces/{namespace}/{metric_name} |待处理消息数，按逻辑队列或分区去重。消费者为零时，事件源仍需可读取。 | |APIG 入口请求速率 |APIG → VMP → KEDA |External |/apis/external.metrics.k8s.io/v1beta1/namespaces/{namespace}/{metric_name} |对 istio_requests_total 计算每秒请求数，按 ClusterId 和 request_host 过滤。后端为零时，APIG 仍需记录请求并持续上报指标。 | |GPU 活跃程度/推理排队 |GPU 或推理服务指标 → VMP → KEDA |External |/apis/external.metrics.k8s.io/v1beta1/namespaces/{namespace}/{metric_name} |先确认 GPU 型号、DCGM/导出器配置支持且已采集目标指标。DCGM_FI_PROF_SM_ACTIVE 的原始比例通常为 0～1，0.8 表示 80%；如查询做了百分比转换，应同步调整阈值。推理排队按待处理请求数聚合，按模型吞吐和延迟选择目标。 | |预测负载 |历史指标 → IHPA 预测服务 → 外部指标服务 |External |/apis/external.metrics.k8s.io/v1beta1/namespaces/{namespace}/{metric_name} |根据预测指标的定义设置目标，检查时间戳、有效期、提前量和实时指标。 | `{namespace}`和`{metric_name}`表示实际命名空间与指标 API 暴露的名称。KEDA 生成的外部指标名可能与 Prometheus 原始指标名不同，可从其托管 HPA 的`spec.metrics`中查看；查询时还应带上该指标使用的标签选择条件。上表展示本文采用的接入方式，指标经其他适配方式暴露时，以实际 HPA 指标类型和 API 为准。 Object 指标与一个 Kubernetes 对象关联，例如 Service；External 指标不要求绑定 Kubernetes 对象。除指标类型外，还需匹配目标类型与查询聚合方式： |**指标表达方式** |**目标与计算口径** | |---|---| |CPU/内存相对 requests 的利用率 |Resource/ContainerResource 使用 Utilization；分母是参与计算的 requests。 | |每个 Pod 各有一个业务指标值 |使用 Pods 和 AverageValue，确认适配器把序列正确映射到目标 Pod，不能将同一全局总量重复映射给每个 Pod。 | |对象或外部来源的总 QPS、队列总积压 |使用 Object/External 的 AverageValue 表达每副本目标。简化需求为“总量 ÷ 单副本目标”，不应先在查询中除以副本数后再交给 HPA 平均。 | |已经聚合为整体平均值或比例的指标 |可评估 Object/External 的 Value，按当前值与目标值的比例调整副本。只有扩容能改善该指标时才适用，例如经压测证明可以分摊的平均 GPU 负载；不要对延迟、利用率或共享瓶颈机械扩容。 | KEDA 的 Prometheus 触发器通过 metricType 选择 AverageValue 或 Value。本文 APIG 查询返回总请求速率，采用默认的 AverageValue；如改为 Value，需重新评估阈值，并注意本文所述 fallback 不适用于该类型。 HPA 状态中的数量可能使用 Kubernetes Quantity 格式：m 表示千分之一，不是百分号。例如 500m CPU 为 0.5 核，1500m 的 QPS 指标为 1.5 请求/秒；Mi 与 M 也不同。监控面板可能换算为 MiB、Mbps 等显示单位，填写阈值时应使用指标 API 的实际单位。自定义百分比也需说明分母，不能与原生按 requests 计算的利用率混用。 ### 接入托管 Prometheus（VMP） Prometheus Adapter 和 KEDA 均支持读取托管 Prometheus（VMP）中的指标。可复用已采集到 VMP 的业务、GPU 和推理指标，根据伸缩方式选择接入组件： |**接入组件** |**指标使用方式** |**适用场景** | |---|---|---| |Prometheus Adapter |将 VMP 中的时间序列映射为 Kubernetes 自定义指标，由已有 HPA 读取。 |已有 HPA，需要增加每 Pod QPS 等与 Kubernetes 对象关联的指标。配置入口见 [使用自定义指标实现弹性伸缩](https://www.volcengine.com/docs/6460/1261824)。 | |KEDA |通过 Prometheus 触发器查询 VMP，将结果作为 External 指标提供给托管 HPA。 |需要根据入口请求量、队列积压等指标伸缩；下文以 APIG 请求指标为例。 |

说明

一个 VMP 工作区支持接入多个 VKE 集群，各集群的指标通过 ClusterId 标签区分。

配置 Prometheus Adapter 映射或 KEDA 查询时，先使用目标集群的 ClusterId 过滤，再按实际的命名空间、工作负载或入口域名筛选，避免将多个集群的流量合并计算。

接入前确认组件具备工作区查询权限，并检查指标更新是否及时。

### 控制指标查询开销 |**检查项** |**调优建议** | |---|---| |指标时效与历史数据 |分别检查采集间隔、查询窗口、指标发现/有效期及 HPA 调谐周期。首次出现的新指标可能需要等待发现；缩短查询窗口也可能增加波动或空结果。metrics\-server 提供近期资源用量，长期趋势和预测使用 VMP 等时序存储。 | |规模与查询开销 |可按“HPA 数量 × 平均指标数 ÷ 实际调谐间隔”估算调用量级，再计入 KEDA 轮询、监控面板和其他客户端；缓存、批量读取与重试会改变实际后端次数。核对工作区查询额度、并发与费用，限制查询范围，避免高基数和重复全量聚合；预聚合或记录规则需检查更新延迟。 | |数据来源与完整性 |多入口或多采集端应覆盖目标业务的完整请求，并去除重复上报。由日志提取指标时，日志格式变化后同步调整解析规则；空闲时持续提供可信的零值，将缺失、过期和查询失败单独识别。 | |容量与故障处理 |观察指标服务的 CPU、内存、请求排队、延迟及错误率，按 VKE 组件支持方式扩充资源。自建指标客户端应设置超时、有限重试、退避与随机延迟；监听大量 Kubernetes 对象时复用 watch/informer，列表查询做范围过滤与分页，避免启动时集中请求。 | |控制面压力与定位 |除 Pod 数量外，还需关注对象总数、单个对象大小和配置变更频率。出现持续延迟时，按调用方、资源类型及 API 动作查看请求量、失败率和延迟，区分业务扩容、采集查询及无效重试；避免不必要的大对象与高频全量更新。 | |缓存与权限 |组件支持指标缓存时，在降低查询量与样本新鲜度之间权衡，并验证故障检测和零副本激活时延。确认指标服务到数据源的网络、证书和只读权限；不要用关闭 TLS 校验解决证书问题。 | 多级服务可以将上游请求量采集到 VMP，由各级 KEDA Prometheus 触发器查询，为下游预扩容。使用前量化调用放大、单请求开销、启动耗时和下游安全吞吐，并保留下游实时指标校验；业务关系变化后重新压测。若依据上游副本数估算容量，还需确认它与真实需求的关系及所用组件支持范围。 ### 结合 Pod 用量分布设置 CPU 阈值先通过单副本压测确定满足服务目标的安全 CPU 用量，再在多副本场景观察用量分布，确认所选阈值能及时扩容且不会掩盖热点。 |**观察项** |**评估方法与配置建议** | |---|---| |统一 Pod 与容器范围 |使用 ClusterId、命名空间和工作负载的实际 Pod 归属筛选，去除重复采集序列。对 container_cpu_usage_seconds_total 使用同一时间窗口的 rate 得到 CPU 核数，再按 Pod 汇总所选容器；ContainerResource 只观察目标业务容器，Resource 与 Pod 资源指标口径保持一致。 | |比较平均值与最大值 |在同一时刻和统计窗口内，对各 Pod 的 CPU 用量计算平均值与最大值：平均值观察整体利用水平，最大值发现热点。若两者长期差距较大，先检查流量分配、长连接、任务分片和实例性能差异，并验证增加副本能否分担热点。 | |结合服务目标选择阈值 |同时观察平均/最大用量、P95/P99 延迟、错误率、排队和 CPU 限流，在性能明显劣化前选择目标并预留启动余量。核心与非核心业务按响应时间和成本要求权衡；最大值用于容量分析，HPA 的资源利用率仍按总用量与总 requests 计算。 | 例如，压测后选择的目标用量为每个业务容器 600m CPU，且每个容器的 CPU request 都为 1000m，则可设置 averageUtilization: 60。如果 requests 不同，应按参与计算的容器或 Pod 的总 CPU 用量 ÷ 总 CPU requests × 100% ** ** 评估利用率，不能直接平均各 Pod 的百分比；直接按绝对用量设置目标时，可使用 AverageValue，此例为 600m。 ### 同一组 Pod 只允许一个生效 HPA 同一工作负载需要同时依据 CPU、QPS、队列长度伸缩时，将这些指标配置在同一个 HPA 的 metrics 中。KEDA 和 IHPA 创建的托管 HPA 也计入这一限制。在 Kubernetes 1.30 及以上版本中，多个 HPA 选择同一批 Pod 时，控制器会报告 AmbiguousSelector，将 ScalingActive 设为 False，并停止该次指标副本计算。为同一个已有 Pod 的 Deployment 配置两个 HPA，两个对象都可能持续报错。创建 HPA 成功后，仍需检查其运行状态；上述冲突不一定在 API 创建时立即报错。排查时同时检查 scaleTargetRef 和 Pod 选择器，即使目标名称不同，也应避免选中相同的 Pod。 HPA 与其伸缩目标必须位于同一命名空间，scaleTargetRef 的 API 版本、类型和名称需与实际对象一致。对于 Deployment，将 HPA 指向 Deployment，由其管理底层 ReplicaSet；不要直接绑定滚动发布过程中创建的 ReplicaSet。自定义工作负载还需验证 scale 子资源的副本字段和 Pod 选择器。 ### 按业务容器 CPU 配置 HPA 以下示例使用 autoscaling/v2 和 ContainerResource 指标；后者在 Kubernetes 1.30 进入稳定阶段，适合包含日志、代理等 Sidecar 的 Pod。autoscaling/v2beta2 已从 Kubernetes 1.26 移除，旧清单应先迁移到 autoscaling/v2。示例作用于 autoscaling\-demo/web，该 Deployment 的业务容器名必须为 app，且已声明 CPU request。CPU 60%、3～50 副本和缩容速率是配置起点，需要结合业务容量调整。 ```YAML apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: web-hpa namespace: autoscaling-demo spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: web minReplicas: 3 maxReplicas: 50 metrics: - type: ContainerResource containerResource: name: cpu container: app target: type: Utilization averageUtilization: 60 behavior: scaleUp: stabilizationWindowSeconds: 0 selectPolicy: Max policies: - type: Percent value: 100 periodSeconds: 15 - type: Pods value: 4 periodSeconds: 15 scaleDown: stabilizationWindowSeconds: 300 selectPolicy: Min policies: - type: Percent value: 20 periodSeconds: 60 - type: Pods value: 5 periodSeconds: 60 ``` |**示例配置** |**实际效果** | |---|---| |扩容：15 秒内增加 100% 或 4 个 Pod，选择较大值 |根据指标计算结果增加副本，允许的变化量采用两项策略中较大的一项。 | |缩容稳定窗口：300 秒 |参考最近 300 秒的建议副本数，采用较高值，减少短暂流量回落引起的缩容。 | |缩容：60 秒内减少 20% 或 5 个 Pod，选择较小值 |按两项策略中较小的幅度回收副本，保留更多时间处理在途请求。 | 策略中的 periodSeconds 表示统计副本变化的时间范围，HPA 会扣除这一范围内已发生的变化。稳定窗口用于评估历史建议值，不要求每次操作后固定等待。最终副本数仍受指标计算及最小、最大副本数约束。扩容稳定窗口选择窗口内较低的副本建议，缩容稳定窗口选择较高的建议。扩容窗口过长可能延后真实高峰获得容量，应与指标查询窗口及业务可接受的等待时间一起评估。按业务容器伸缩可减少日志、代理等 Sidecar 对指标的干扰；节点资源规划仍应计入整个 Pod。业务容器需要改名时，先让同一个 HPA 同时跟踪新旧容器名，滚动发布完成后移除旧容器指标，并检查过渡期的指标和缩容状态。 ### 在同一 HPA 中组合业务指标如果 CPU 不能完整反映业务压力，可以在上述 HPA 中增加每 Pod QPS 等指标。以下片段要求 Prometheus Adapter 已将 VMP 或其他 Prometheus 数据源中的请求指标映射为 http_requests_per_second，并正确关联到 Pod；单副本 100 QPS 是需要通过压测确认的示例目标。区分服务总需求与每个 Pod 的需求，避免重复聚合。 ```YAML # 添加到同一个 HPA 的 spec.metrics 列表 - type: Pods pods: metric: name: http_requests_per_second target: type: AverageValue averageValue: "100" ``` 计算 QPS 时，对累计请求数使用 PromQL 的 rate() 得到每秒速率；increase() 返回查询窗口内的增量，使用时需与目标值单位一致。查询 VMP 指标时，先使用 ClusterId 限定目标集群，再按实际的命名空间、工作负载或 Pod 标签筛选并去重；每 Pod QPS 应按 Pod 汇总。如果指标更新滞后，优先检查采集、查询和指标发现周期，再调整伸缩参数。 ### 理解副本计算和多指标行为简化的副本计算公式如下，实际结果还要经过容差、缺失指标处理、稳定窗口、速率限制及副本上下限约束： ```Plain Text 期望副本数 = ceil(当前副本数 × 当前指标值 / 目标指标值) ``` 对于资源利用率，控制器以参与计算容器的用量总和与对应 request 总和计算利用率。request 一致时可直观理解为平均利用率；request 不一致时，不能把各 Pod 的利用率简单算术平均。ContainerResource 只关注指定容器。多个指标会分别计算期望副本数，HPA 采用其中的最大值。因此，CPU 已回落而队列仍有积压时，副本数可能保持不变。部分指标读取失败时，其他健康指标仍可驱动扩容；如果健康指标建议缩容但另有指标失败，HPA 通常会跳过这次基于指标的缩容。缺失 Pod 指标、未就绪 Pod 和初始化 CPU 采样也会使调整更保守。 Pod 样本缺失与整个指标读取失败是两类问题。存在缺失样本时，HPA 会保守地重新计算；CPU 指标还会按初始化和就绪状态处理样本。新建或滚动更新的 Pod 即使已 Ready，也可能尚未形成完整采样，应区分正常采样等待与持续采集故障。HPA 状态显示的原始指标值未必包含保守调整，应结合 Pod 状态、conditions 和事件判断，不能只凭 TARGETS 超过阈值断定控制器失效。 ### 按业务场景选择伸缩行为通过 behavior 设置扩缩容速度与稳定窗口。表中数值为调优示例；“窗口”指 stabilizationWindowSeconds，速率中的时间指 periodSeconds，Min/Max 分别选择允许变化量较小/较大的策略。批量创建 Pod 会增加控制面 API/etcd、调度器、kubelet 和网络插件的压力，并集中访问镜像仓库、DNS 及下游服务。应从较小扩容速率开始压测，结合 Pod 就绪耗时、组件和业务的延迟、错误率及下游连接数逐步调优；同时观察启动和预热负载，避免进一步放大扩容需求。 |**业务目标** |**核心配置（示例）** |**行为** |**验证重点** | |---|---|---|---| |在线流量突增：快扩慢缩 |scaleUp：窗口 0s；100%/15s 与 4 Pods/15s 取 Max。

scaleDown：窗口 300s；20%/60s 与 5 Pods/60s 取 Min。 |扩容选较大增量；缩容参考过去 300 秒的最高副本建议，再以较小减量限制回收。 |扩容期间的延迟和错误率、可用节点资源、数据库连接数，以及新增 Pod 的就绪速度。 | |可排队任务：固定数量慢扩 |scaleUp：窗口 0s；仅配置 2 Pods/60s。 |以固定 Pod 数量限制扩容预算，允许的增量不随规模同比放大。 |结合积压量和最老消息年龄告警，确认受限的扩容速度仍满足处理时限。 | |持续增长：先快后慢扩容 |scaleUp：窗口 0s；100%/60s 与 20 Pods/60s；selectPolicy: Min。 |副本较少时允许按比例增长；规模增大后，每 60 秒的扩容预算最多为 20 个 Pod，相对增长速度降低。 |在低副本和高副本区间分别压测，确认增长速度满足业务时限，且批量启动不会压满节点或下游。 | |负载回落：稳定后快速缩容 |scaleDown：窗口 300s；仅配置 100%/15s。 |过去 300 秒的最高建议仍可能阻止回收；稳定后，速率策略允许较大幅度缩容。流量下降后，仍需满足稳定窗口和副本建议条件。 |适用于负载回落可信、任务可安全终止且连接可排空的业务；验证突发回弹时的容量余量与恢复耗时。 | |平稳回收：固定数量缩容 |scaleDown：窗口 300s；仅配置 2 Pods/60s。 |稳定后以固定数量限制回收预算；大规模场景回收所需时间可能较长。 |确认回收时长、Pod 排空时间与剩余容量；接近最小副本数时，实际减量可能不足 2。 | |规模回落：百分比转固定数量缩容 |scaleDown：窗口 300s；50%/60s 与 5 Pods/60s；selectPolicy: Max。 |高副本时由百分比决定减量，低副本时由固定数量决定；Max 选择允许删除更多 Pod 的策略。 |低副本尾段删除 5 个 Pod 可能占较高比例；校验容量余量，必要时减小固定数量，并设置合适的 minReplicas。 | |大促窗口：暂时禁止 HPA 缩容 |behavior.scaleDown.selectPolicy: Disabled；活动后恢复原策略。 |仅关闭本 HPA 的缩容方向，扩容仍按其策略运行。 |会增加成本；不能阻止 CronHPA、KEDA 归零、人工或发布系统直接修改副本。 | |指标短毛刺：平滑伸缩判断 |先检查信号和查询窗口，再评估较长缩容稳定窗口；扩容窗口按允许的响应延迟决定。 |稳定窗口参考历史副本建议来抑制往返伸缩；不应理解为每次必须重新等待固定时长。 |扩容窗口越长，对突发流量的响应可能越慢；同时验证毛刺与真实峰值场景。 | **速率策略规定上限，实际伸缩由指标需求和剩余预算决定。** periodSeconds 是回看已发生伸缩的滚动时间窗口；控制器会据此计算剩余预算与百分比基数。Percent 的 value 表示变化量占基数的百分比，扩容 100% 表示最多新增与基数相同数量的 Pod。百分比换算为整数副本时需要取整，小副本时实际比例可能更大。最终副本数还受稳定窗口、minReplicas／maxReplicas、指标需求和控制器同步时机约束，可能只使用部分预算或不执行伸缩；表中的趋势不代表固定副本变化序列。 ### 显式设置伸缩规则与容差 HPA 通常每 15 秒计算一次伸缩需求，实际周期由集群控制面配置决定。使用 Kubernetes 的默认 behavior 规则时，扩容窗口为 0，允许每 15 秒增加 100% 或 4 个 Pod，取较大值；缩容窗口为 300 秒，允许每 15 秒缩减 100%。生产环境建议显式设置符合业务要求的双向规则。旧策略未配置 behavior 时，历史窗口内的较高建议值可能继续推动后续扩容。改为显式配置、并将扩容窗口设为 0 后，不会仅依据该历史高值继续扩容。迁移时应观察高峰和流量回落两个阶段，确认副本变化符合预期。容差用于忽略目标值附近的小幅波动。Kubernetes 控制器的默认容差为 0.1，实际值由集群配置决定；以 CPU 目标 60% 为例，约 54%～66% 范围内通常不因该指标触发伸缩，边界还会受取整和其他保护机制影响。 #### 分别设置扩容和缩容容差 behavior.scaleUp.tolerance 和 behavior.scaleDown.tolerance 在 Kubernetes 1.33 引入、1.35 进入 Beta。使用前，请确认目标集群的支持情况： |**集群版本** |**使用要求** | |---|---| |Kubernetes 1.30、1.32 |不支持上述字段，清单中不要添加。 | |VKE 1.34 |需已开放该功能，并启用 HPAConfigurableTolerance。 | |VKE 1.36 |使用前确认 VKE 已开放该功能，并检查所用伸缩组件支持情况。 | 可通过 VKE 功能说明或技术支持确认功能是否开放。确认支持后，将以下片段合并到已有 behavior 中。 ```YAML # 仅用于目标集群确认支持 HPAConfigurableTolerance 的场景 # 与已有 behavior 的稳定窗口和速率配置合并，不要覆盖掉其他字段 scaleUp: tolerance: "0.02" scaleDown: tolerance: "0.10" ``` 较低的扩容容差能响应更小的指标变化，也可能增加频繁扩缩容，应结合业务指标的波动验证；容差不改变指标查询周期。由 KEDA 或 IHPA 管理 HPA 时，需在相应配置入口设置这些字段，并确认组件版本支持；直接修改托管 HPA 的值可能被控制器覆盖。 ## 定时伸缩（CronHPA） CronHPA 适用于高峰时间已知的业务，可以按预设时间调整工作负载副本数。根据应用启动和节点准备耗时设置提前量，使新增 Pod 在高峰到来前就绪。 ### 两种关联方式：工作负载或 HPA 创建 CronHPA 时，就需要明确关联方式，并将目标写入 spec.scaleTargetRef。可选择以下两种方式： * **直接关联工作负载：** 未配置 HPA 时，可将 CronHPA 指向 Deployment 或 StatefulSet，计划到期后直接调整工作负载的期望副本数。 * **关联 HPA：** 已配置 HPA 时，将 CronHPA 指向该 HPA，根据定时目标修改 HPA 的副本范围，由 HPA 继续处理实时指标变化；部分扩容条件下，CronHPA 也会直接修改工作负载的期望副本数。以下表格说明创建时写入的目标与实际行为。关联方式由 spec.scaleTargetRef 保存，后续新增 HPA 不会触发自动刷新。若已经关联的 HPA 被删除，且配置了 scaleWorkloadRef，则可能回退到工作负载引用；这是目标缺失时的处理，不是自动发现新的 HPA。 |**scaleTargetRef 指向** |**实际行为** |**配置要点** | |---|---|---| |直接关联工作负载：Deployment/StatefulSet 等支持 scale 的工作负载 |计划到期时，直接写入工作负载的 scale，修改期望副本数。 |后续新增 HPA 不会自动改变已有 CronHPA 的关联方式；需显式更新 spec.scaleTargetRef，指向该 HPA，才能按 HPA 协作方式伸缩。 | |关联 HPA：已存在的 HPA |根据定时目标、工作负载当前期望副本数，以及 HPA 的 minReplicas、maxReplicas 判断动作；可能调整 HPA，并在特定分支直接写入工作负载的 scale。 |同时检查 HPA 的副本范围和工作负载期望副本数，具体条件参见“CronHPA 与 HPA 协作时的副本变化”。 | |关联 HPA 时的回退：目标 HPA 不存在，且配置了 scaleWorkloadRef |改用 scaleWorkloadRef 指向的工作负载；成功处理后，可能将回退引用保存到 spec.scaleTargetRef，作为后续伸缩目标。 |删除 HPA 前检查 CronHPA 的回退配置；恢复 HPA 后，重新检查并更新目标引用。 | 通过控制台或 YAML 创建 CronHPA 后，应检查 spec.scaleTargetRef 中已保存的目标。CronHPA 不会因后续新建 HPA 自动刷新关联方式；需要关联新建或恢复的 HPA 时，应显式更新并确认目标引用。目标 HPA 缺失时的回退可能改变已保存的引用，需结合上表检查 scaleWorkloadRef 配置。 ### 时区与示例通过 Cron 表达式的`CRON_TZ=`前缀指定时区；未指定时，使用组件进程的本地时区。VKE CronHPA 不使用独立的 timeZone 字段。使用 YAML 时，建议显式声明时区，并确认所用组件与配置入口支持该表达式；使用控制台时按界面说明填写，检查最终对象和实际执行时刻。 ```YAML apiVersion: vke.volcengine.com/v1alpha1 kind: CronHPA metadata: name: web-cronhpa namespace: autoscaling-demo spec: scaleTargetRef: apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler name: web-hpa scaleWorkloadRef: apiVersion: apps/v1 kind: Deployment name: web crons: - schedule: "CRON_TZ=Asia/Shanghai 30 8 * * 1-5" target: 20 - schedule: "CRON_TZ=Asia/Shanghai 0 22 * * 1-5" target: 3 ``` 示例在工作日 08:30 执行目标副本数为 20 的规则，在 22:00 执行目标副本数为 3 的规则，两个目标均未超过 HPA 的 50 副本上限。实际副本数与 HPA 下限的变化取决于下一节列出的条件。首次上线时，请在可控时段检查执行时刻、minReplicas 和工作负载副本数，确认时区与规则符合预期。如果环境明确按 UTC 使用裸五字段表达式，换算如下： |**北京时间** |**UTC** |**裸五字段表达式** | |---|---|---| |每天 09:00 |每天 01:00 |0 1 \* \* \* | |每天 22:00 |每天 14:00 |0 14 \* \* \* | |每周一 08:00 |每周一 00:00 |0 0 \* \* 1 | |每周一 02:00 |每周日 18:00 |0 18 \* \* 0 | 北京时间 00:00～07:59 换算为 UTC 后落在前一天，08:00 不跨天。生产配置建议统一使用五字段 Cron 表达式，并单独核对跨月、节假日和夏令时安排。VKE CronHPA 不提供节假日排除配置，节假日的扩缩容计划需单独安排。涉及月内日期、星期、月末跨月或节假日的规则，应列出期望执行日期，并核对实际触发时刻；尤其验证日期与星期同时设置时的结果，避免额外触发或漏掉关键扩容计划。 ### CronHPA 与 HPA 协作时的副本变化关联 HPA 时，CronHPA 按表中顺序判断条件。target 表示定时目标副本数，current 表示工作负载当前期望副本数，区别于已就绪的副本数；minReplicas、maxReplicas 分别为 HPA 的副本下限和上限。使用前请显式设置 HPA 的 minReplicas。 |**条件** |**CronHPA 的动作** |**使用含义** | |---|---|---| |目标数小于 HPA minReplicas，或 minReplicas 未设置。 |修改 minReplicas；非正数修正为 1。 |不直接强制缩容，实际回收由 HPA 决定。 | |否则，目标数大于 maxReplicas。 |同时增大 minReplicas、maxReplicas，并将工作负载期望副本数改为目标数。 |后续低目标规则不会自动恢复上限；此分支会将 current 写为目标数，若 current 因其他修改已高于目标数，也会减少期望副本。 | |否则，目标数大于 current。 |抬高 minReplicas 并增加工作负载期望副本数。 |常见的定时提前扩容路径。 | |目标数不大于 current，且处于原副本区间内。 |不更新副本范围或期望副本数。 |此分支保持原有 minReplicas，不会将它抬到定时目标数。 | **伸缩速率取决于最终由谁修改副本数。** 直接关联工作负载时，CronHPA 直接更新副本数，不使用 HPA 的 behavior。关联 HPA 时，仅修改副本范围后的指标伸缩由 HPA 处理；如果命中上表中直接更新工作负载的条件，该次更新同样不受 HPA 的速率限制。例如，符合条件时可直接将期望副本数从 3 改为 20。设置定时目标前，请检查节点容量及批量启动 Pod 对下游服务的影响。活动期间需要持续保持至少 20 副本时，请通过统一的 HPA 配置入口设置并检查 minReplicas。已使用 KEDA 时，可通过其内置 cron 触发器设置时段容量下限。CronHPA 仅在计划触发时按上述条件修改副本范围或副本数，能否设置下限取决于触发时的状态；定时目标本身不始终保证整个时段的容量下限。组件升级后，请重新验证执行结果。下表展示常见初始状态下的执行结果，示例均假设 HPA 已显式设置 minReplicas。 |**执行前 min/max** |**执行前 current** |**定时 target** |**执行后 min/max** |**CronHPA 直接写入的 current** | |---|---|---|---|---| |3/50 |3 |20 |20/50 |20 | |3/50 |30 |20 |3/50 |不变，仍为 30 | |20/50 |30 |3 |3/50 |不变；后续由 HPA 判断是否缩容 | |3/50 |30 |60 |60/60 |60 | ### 检查执行结果上线前，确认 VKE 组件管理中的支持范围、所用关联方式、目标引用和时区；关联 HPA 时，核对全部定时目标与 HPA 上限。随后在可控时段验证计划，检查工作负载期望副本数和可用副本数；关联 HPA 时同时检查其副本范围。暂停或删除规则前，先确认活动所需容量已有保障；恢复规则后，检查下一次计划是否正常执行。 CronHPA 仅在计划到期的分钟窗口内执行，失败后可在该窗口内重试；错过窗口后不会补执行，关键计划需按人工容量保障方案处理。同一目标的时间规则应集中管理，避免多个 CronHPA 或同时到期的规则发生冲突；规则处理顺序不代表业务优先级。检查 status.lastScheduleTime，可了解最近一次成功处理到期计划的时间。当次到期动作存在失败时，时间戳不更新；其他尚未到期的规则不影响本次更新。对象创建成功表示通过 CRD 校验，之后还需验证 Cron 表达式、目标是否存在及实际伸缩结果，确认计划能够正常运行。 ```Bash kubectl -n autoscaling-demo get cronhpa web-cronhpa -o yaml kubectl -n autoscaling-demo get hpa web-hpa -o yaml kubectl -n autoscaling-demo get deployment web ``` 为关键扩容计划同时设置“计划已按时执行”和“业务可用副本达到目标”两个检查点，并监控组件可用性，确认新增容量已能承接业务。 ## 事件驱动伸缩（KEDA） KEDA 根据队列积压、待处理任务等事件提供伸缩能力，可用于持续运行的工作负载，也可按需创建独立任务。使用前确认目标集群支持所需事件源，并完成组件安装与授权。详情请参见 [KEDA 组件安装与配置](https://www.volcengine.com/docs/6460/2276752)。 ### 选择工作负载模式或任务模式 ScaledObject 和 ScaledJob 都是 KEDA 提供的自定义资源，使用前需要安装 KEDA 组件。根据应用的运行方式选择： |**应用运行方式** |**KEDA 资源** |**伸缩方式** | |---|---|---| |Deployment 等持续运行的应用或消费者。 |ScaledObject |关联已有工作负载，由 KEDA 创建并管理 HPA 调整副本数；满足事件源条件时支持缩至零后再激活。 | |收到任务后启动、处理完成后退出的作业。 |ScaledJob |根据事件源中的任务需求创建 Kubernetes Job，通过任务并发和执行策略控制处理规模。 | Kubernetes 原生 Job 用于执行完成后结束的任务，本身不依赖 KEDA。需要根据外部事件自动创建和扩展这类任务时，再使用 ScaledJob。本节后续示例采用 ScaledObject；ScaledJob 的并发、重试和清理参数应按任务模式单独配置，不套用 HPA 的 behavior。 |**任务配置** |**使用建议** | |---|---| |任务领取与并发 |明确指标是否包含已领取或处理中任务，选择匹配的 scalingStrategy，避免重复扣除运行中任务而少建 Job。结合原子领取、消费确认及幂等防止重复处理；按单任务能力设置 maxReplicaCount，核对 parallelism/completions、分区和下游额度。Job 数不等于 Pod 并发数，也不等于成功任务数。 | |超时、重试与退出 |结合任务时长设置 activeDeadlineSeconds、backoffLimit，并处理重复投递、检查点与幂等。验证任务成功、失败和中断后都能正确更新外部队列或任务状态。 | |历史保留与结果检查 |按组件版本配置 successfulJobsHistoryLimit、failedJobsHistoryLimit 等保留数量，或使用受支持的完成后清理策略。先集中保存必要日志，再清理对象；检查 Complete/Failed、退出码、实际业务结果与消费位点，确认积压确已处理。 | ### ScaledObject 的伸缩与零副本激活 * **常规伸缩：** HPA 负责 1～N 的指标伸缩，扩缩容速率由 behavior 管理。pollingInterval 设置 KEDA 的轮询间隔，HPA 按自身调谐周期运行。 * **零副本激活：** KEDA 轮询事件源，在满足激活条件时将副本数从 0 恢复。 * **空闲归零：** cooldownPeriod 主要控制触发器不活跃后缩至零的等待时间。冷却结束后的直接归零不受 HPA 每分钟缩减比例约束，可能从当时的 N 个副本直接改为 0。上线前，请验证应用能安全排空全部在途任务。 **缩至零后，事件源仍需能独立提供触发信号。** 可使用队列长度、外部任务库、独立运行的入口或指标导出器。若 HTTP QPS 仅由应用 Pod 导出，所有 Pod 停止后通常无法感知新请求。同步在线服务还需独立验证请求缓存、排队或重试能力；普通 Service／Ingress 配合 Prometheus 触发器不会自动提供这些能力。尚未具备可靠激活入口时，请至少保留一个副本。需要缩至零时，使用经过验证的 KEDA 激活方案。原生 HPA 的 HPAScaleToZero 到 Kubernetes 1.36 仍是默认关闭的 Alpha 特性，且要求 Object 或 External 指标，不作为 VKE 通用配置。 ### 配置与验证步骤 |**步骤** |**操作要点** |**检查结果** | |---|---|---| |准备组件与指标 |安装 KEDA；使用 APIG 场景时，配置 APIG Ingress 并将入口指标采集到 VMP。 |operator、准入 Webhook、metrics\-apiserver 和 CRD 版本匹配且可用；后端为零时仍能看到 APIG 请求指标。 | |配置指标查询 |确认 VMP 查询权限，按 ClusterId 和实际业务标签筛选指标。 |查询对应目标集群和入口，能区分真实零值与采集失败。 | |配置 ScaledObject |设置目标、指标阈值和副本范围；需要调整 1～N 伸缩速率时，配置 advanced.horizontalPodAutoscalerConfig.behavior，由 ScaledObject 统一管理托管 HPA。 |同一批 Pod 只有一个生效 HPA，ScaledObject Ready 状态正常。 | |观察伸缩效果 |对照请求速率、HPA 期望副本和工作负载可用副本。 |新增副本就绪并分担请求，空闲回收符合配置。 | |检查零副本恢复 |验证入口独立采集、冷启动时请求处理与再次激活。 |应用能从零恢复，请求重试及可接受等待时间满足业务要求。 | ### 使用 APIG 请求指标实现零副本伸缩 APIG 在后端 Pod 停止后仍可接收入口请求并记录请求指标。将这些指标采集到 VMP，再由 KEDA 查询请求速率，可以在空闲时将后端工作负载缩至零，并在出现新请求后重新扩容。该方式适合能够接受冷启动等待和请求重试的业务。从零扩容期间，新增 Pod 尚未就绪，请求可能失败或超时。该配置不会自动缓存并重放请求，应由客户端或入口配置合适的重试。不能接受这段不可用时间的业务，应保留常驻副本。配置前完成 APIG 入口、VMP 指标采集与 KEDA 鉴权。操作步骤参见 [创建 APIG Ingress](https://www.volcengine.com/docs/6460/1222547) 和 [事件驱动伸缩（KEDA）](https://docs.volcengine.com/docs/6460/1520275)。以下保留需要按业务调整的核心配置： * 为已有 Deployment 配置 Service 和 APIG Ingress。示例使用 autoscaling\-demo/web，入口域名为 example.com。 * VMP 已采集 istio_requests_total；使用 ClusterId 限定集群、request_host 限定入口，并确认后端为零时请求仍会被记录。 * VMP 已开启 Basic Auth，并在目标命名空间创建引用用户名、密码 Secret 的 TriggerAuthentication。示例名称为 vmp\-trigger\-auth，应替换为实际已配置的名称。以下为 [使用 APIG 网络指标实现弹性伸缩](https://docs.volcengine.com/docs/6460/1520276) 的`ScaledObject.spec`配置片段，需合并到目标 ScaledObject 中。将``替换为可访问的 VMP HTTPS 查询地址，并填写实际 ClusterId、入口域名和鉴权对象名称。 ```YAML # ScaledObject.spec 的核心配置 scaleTargetRef: name: web pollingInterval: 15 cooldownPeriod: 300 idleReplicaCount: 0 minReplicaCount: 1 maxReplicaCount: 30 triggers: - type: prometheus metricType: AverageValue metadata: serverAddress: "" query: 'sum(rate(istio_requests_total{ClusterId="",request_host="example.com"}[1m]))' threshold: "100" activationThreshold: "0" ignoreNullValues: "false" authModes: "basic" authenticationRef: name: vmp-trigger-auth ``` 创建前确认 web 没有另一个生效 HPA；前文的 web\-hpa 与本节配置是两种方案，使用时只选择其中一种。创建后检查 ScaledObject 的 Ready 状态、托管 HPA 的 External 指标和工作负载可用副本。出现查询错误时，检查 VMP 查询地址、Basic Auth 凭证、ClusterId 和 request_host 的实际值。 |**核心配置** |**含义与调整建议** | |---|---| |idleReplicaCount: 0、minReplicaCount: 1 |空闲时允许缩至零；触发器重新激活后恢复到至少 1 个副本。需要常驻副本时，移除 idleReplicaCount 并设置非零下限。 | |maxReplicaCount: 30 |副本上限为示例值，应结合节点资源和下游承载能力调整。 | |pollingInterval: 15、cooldownPeriod: 300 |每 15 秒检查激活条件；持续空闲并满足冷却条件后归零。实际恢复耗时还包括指标采集、查询窗口、调度和启动。 | |threshold: "100"、AverageValue |每副本目标为 100 QPS，需经压测校准。总请求速率为 500 QPS 时，该指标建议约 5 个副本，再受上下限与伸缩规则约束。 | |activationThreshold: "0"、ignoreNullValues: "false" |有效请求速率大于 0 时激活；空查询按错误处理。请求停止后，查询窗口内的历史请求仍可能延后归零。 | |authenticationRef |引用同一命名空间中已配置的 TriggerAuthentication，通过 Secret 提供 VMP Basic Auth 凭证。 | 按业务峰值校准请求阈值，同时观察错误率、响应时间和下游容量。首次启用零副本时，确认从入口产生请求到 Pod 可服务的全过程，并检查客户端重试是否覆盖冷启动。若需要始终保留副本，移除 idleReplicaCount，将 minReplicaCount 设置为业务所需的非零下限。 ### 防止空指标造成误缩容 Prometheus 查询需返回单一聚合结果。本例将 ignoreNullValues 显式设为 false，使空查询按错误处理，避免默认行为将空结果按 0 处理。若使用 or vector(0) 将空结果补为 0，应先通过独立健康指标确认采集链路正常，再判断业务值是否确实为零。 **故障回退（fallback）的适用条件** * **指标类型：** 本节使用的 fallback 仅对受支持的 AverageValue 外部指标提供 fallback，CPU／内存触发器不在支持范围内。 * **触发条件：** 连续失败计数**超过 ** failureThreshold 后，KEDA 生成兜底指标。触发时间取决于实际指标请求节奏；失败次数不能直接换算成固定轮询次数或固定秒数。已被按 0 处理的空查询不会触发错误回退。 * **运行依赖：** fallback 依赖 KEDA 指标链路正常工作。控制器（operator）、指标服务（metrics\-apiserver）或控制面故障时，无法保证恢复到兜底副本数。 * **零副本场景：** 单独验证指标故障时能否激活工作负载。业务若需要在激活链路故障时仍保持处理能力，应保留基础副本。 ### 在一个 ScaledObject 内组合定时与事件已使用 KEDA 的工作负载，可在同一个 ScaledObject 中组合 cron 和请求指标触发器。例如，为上述 Web 服务配置工作日常驻副本下限，其他时段再按 APIG 请求指标伸缩。时间窗口内，desiredReplicas 作为动态下限参与同一个 HPA 的多指标计算，无需额外创建 HPA 或 CronHPA。 |**定时触发器字段** |**示例设置** | |---|---| |type |cron | |timezone |Asia/Shanghai | |start／end |0 9 \* \* 1\-5／0 22 \* \* 1\-5 | |desiredReplicas |10 | 在同一个 ScaledObject 的 triggers 中增加上述 cron 触发器后，工作日北京时间 09:00～22:00 的副本下限为 10。窗口外该下限失效；APIG 请求指标也不活跃时，KEDA 在满足冷却条件后缩至零。窗口结束不会无条件停止仍有请求的业务。 ### 队列消费与使用限制 * 同一目标由一个 ScaledObject 管理。默认准入检查会拒绝与其他 ScaledObject 或独立 HPA 冲突的配置。已有 HPA 时，使用组件支持的 HPA 接管方式，确认后续由 ScaledObject 统一管理，避免生成两个生效 HPA。 * 仅使用 CPU／内存触发器不能从零恢复；需要零副本时配置可独立获取的外部触发器，且明确其激活条件。资源触发器还需满足有效资源声明要求。 * Kafka 消费并行度通常受可消费分区数约束。除消息总积压量（lag）外，还需检查消费组、重平衡和分区倾斜，并明确新消费组尚未提交消费位点（offset）以及位点无效时的处理策略。 * 使用 ScaledJob 时，需按任务执行方式单独配置并发、完成和重试策略。ScaledObject 使用托管 HPA 的 behavior 控制伸缩速率，两类资源应分别配置。 * 根据故障时所需容量设置 fallback.replicas，并按退出或迁移方案决定 restoreToOriginalReplicaCount。后者设为 true 时，恢复的是创建策略时记录的副本数，可能为 0 或已不适合当前负载，启用前应确认该值仍然安全。 ## 智能伸缩（IHPA） ### 基本概念 IHPA 适用于流量存在可学习周期、希望提前扩容的工作负载。突发热点、业务重构或首次大促可能超出历史规律，应保留实时指标、容量下限和人工容量保障方案。启用前，确认目标集群已安装和配置好所需的观测及 katalyst 智能伸缩功能。 IHPA 将预测结果转换为 External（外部）指标，并创建、维护一个 HPA。配置中已有的实时指标会保留。需要实时负载保护时，请在 IHPA 中配置相应指标，并检查生成的 HPA 是否同时包含预期的实时和预测指标，两类指标均应能正常读取。预测指标异常时，HPA 可能暂缓缩容；正常的实时指标仍可能推动扩容。上线前应验证这两种场景，确认基础容量满足业务要求。 |**阶段** |**操作** |**判断依据** | |---|---|---| |数据准备 |检查指标连续性、采样频率、历史保留期及业务代表性。 |覆盖完整业务周期，避免把节假日、故障和发布异常当作常态。 | |预览 |使用控制台“预览”模式，保持现有 HPA 对真实业务生效。 |对照预测需求与真实吞吐、延迟、最低可用容量。 | |小范围自动运行 |为少量工作负载切换“自动”模式，并完成旧 HPA 的控制权交接。 |只有一个 HPA 作用于真实业务 Pod。 | |持续评估 |观察预测偏低、偏高、提前量、成本与人工介入次数。 |用服务目标与成本共同衡量效果。 | |业务变化后 |重启预览评估或回到确定的实时策略。 |重新确认历史数据是否仍有代表性。 | IHPA 预览模式（API 中为 Preview）将托管 HPA 指向 VirtualWorkload（虚拟工作负载），用于模拟副本结果，不调整真实工作负载。已有 HPA 可继续管理真实业务，便于并行评估预测效果。切换自动模式前，保存原策略以便回退，并确认同一批真实业务 Pod 只有一个生效 HPA。 ### 评估预览结果在同一时间轴展示业务需求、实时指标、预测需求、建议副本数、实际可用副本数与服务目标。除比较预测曲线与 CPU 走势外，还应检查提前量能否覆盖 Pod／节点就绪时间、高峰期间容量是否充足，以及低谷期是否持续过量保留，用服务目标和成本共同判断收益。具备流量回放条件时，可在隔离环境使用同一段代表性负载，对比实时策略与预测策略的建议副本、可用副本、延迟和错误率。回放结果还需与真实业务预览结合，确认节假日、业务变化和指标缺失时的效果。 |**检查点** |**预览期应回答的问题** |**切自动模式前的条件** | |---|---|---| |数据连续性 |采样中断、发布或异常活动是否使历史数据偏离正常业务规律。 |能识别缺失数据，并将其与真实零值区分。 | |高峰准备 |预测是否足够早，建议增加的 Pod 能否在高峰前就绪。 |提前量能覆盖实测的 Pod 和节点准备时间。 | |低谷成本 |是否过量保留、频繁伸缩或反复冷启动。 |成本与服务目标均达到业务期望。 | |预测异常 |实时指标、下限和人工保障是否仍可用。 |已检查生成 HPA 的指标配置及指标故障时的伸缩行为。 | |控制权交接 |预览 HPA 是否指向虚拟目标，自动模式是否由 IHPA 托管 HPA 管理真实目标。 |同一批业务 Pod 仅保留一个生效 HPA。 | |退出与回退 |退出自动模式后，由哪个伸缩策略或人工操作接管容量。 |保留原策略和安全副本，避免交接空窗。 | 周周期业务可先按约两周历史数据、一个到两个业务周期的预览时间规划评估，再根据数据完整性、算法配置和业务风险调整。冷启动提前量、预测分位数及副本上下限，也应结合实际业务确定。准备预测输入时，先用 ClusterId、命名空间和工作负载归属限定范围，再按采集来源及完整时序标签识别重复上报，保留不同 Pod 的有效序列。区分真实业务峰值与发布、启动预热、采集故障造成的异常，通过预览验证剔除或标记方式，避免误删真实高峰。所用算法支持分位数配置时，较高值通常增加容量余量与成本，较低值需检查峰值欠配风险；不能把单一分位数作为所有业务的标准。 IHPA 托管 HPA 后，请通过 IHPA 配置入口调整指标和 behavior。直接修改托管 HPA 的配置，会被后续自动同步覆盖。 ## 兼容性说明组合使用上述不同的伸缩方式前，请先确认以下约束。**同一组业务 Pod 只保留一个生效 HPA**，KEDA 和 IHPA 创建的托管 HPA 也计入其中；IHPA 预览使用虚拟目标，可以与真实业务上的 HPA 并行。KEDA 与 katalyst 智能伸缩的组合限制，请以 VKE 组件管理的支持范围及互斥要求为准。 |**组合** |**使用方式** | |---|---| |同一工作负载配置多个独立 HPA |不支持将多个 HPA 用作并行或主备伸缩。Kubernetes 1.30 及以上发现同一批 Pod 被多个 HPA 选择时，会报告 AmbiguousSelector；需要多个指标时，将其配置在同一个 HPA 中。 | |同一 HPA 的多个指标 |推荐；HPA 取各指标建议副本数的最大值。部分指标异常时可能暂停缩容，正常指标仍可能触发扩容。 | |HPA + CronHPA |将 CronHPA 的目标引用显式指向 HPA，并按“CronHPA 与 HPA 协作时的副本变化”检查定时目标和实际容量。 | |一个 ScaledObject 的队列 + cron + 资源触发器 |可组合；统一由 KEDA 托管 HPA，缩至零前确认仍有独立可用的激活信号。 | |现有 HPA + IHPA 预览 |可并行评估；现有 HPA 管理真实工作负载，预览 HPA 指向虚拟目标。 | |现有 HPA + IHPA 自动模式 |切换自动模式时，完成原 HPA 与 IHPA 托管 HPA 的管理权交接，确保真实目标仅由一个 HPA 控制。 | |KEDA + IHPA／katalyst |按 VKE 组件管理中的互斥要求选择 KEDA 或 katalyst 智能伸缩。两者均使用集群级外部指标 API，安装到不同命名空间不能消除冲突。 | |HPA + VPA |避免同时依据同一 CPU/内存利用率自动调整；可评估 HPA 业务指标 + VPA 资源调整或 VPA 仅建议模式。 | |GitOps／Helm 固定 replicas + 自动伸缩 |调整发布模板和同步规则，将工作负载 spec.replicas 交由伸缩控制器管理，避免发布时恢复旧副本数。 | 需要将 HPA 与 VPA 组合时，还应检查资源建议如何应用： |**组合中的检查点** |**建议** | |---|---| |先评估资源建议 |已安装且受支持的 VPA 可使用 updatePolicy.updateMode: Off 只生成建议，先积累覆盖业务高峰与低谷的代表性样本。通过 resourcePolicy.containerPolicies 设置容器范围及 minAllowed/maxAllowed，排除不需要调整的容器。 | |自动应用前确认影响 |核对节点可调度容量、ResourceQuota、LimitRange 和应用资源要求。根据 VPA 版本及更新模式确认会重建 Pod 还是原地调整，验证可用性和 PDB 等约束，并检查实际 Pod 的 requests，不能只看 Deployment 模板。 | |复核 HPA 目标 |在用量不变时，提高 CPU request 会降低 HPA 看到的 CPU 利用率。例如 500m 用量对应 request 1000m 为 50%，request 2000m 时为 25%；资源调整后需重新评估阈值和单副本安全容量。 | 节点池启用自动伸缩后，也应在 Terraform 等配置工具中明确节点数字段的管理方式，避免声明配置持续覆盖自动调整结果；工作负载副本与节点数的管理规则需要分别检查。选择指标组件时，请检查其注册的指标 API。KEDA 与 IHPA 均使用 external.metrics.k8s.io，应遵循 VKE 组件管理中的互斥要求；VKE 的 prometheus\-adapter 方案提供 custom.metrics.k8s.io。同一个 APIService 只能连接一个后端服务，因此接入多个指标来源需要使用平台支持的统一适配方案；安装或升级组件后应核对实际注册项。 ## 监控与排障 ### 监控指标与告警 |**监控对象** |**重点信号** |**需要识别的异常** | |---|---|---| |业务服务质量 |请求速率、错误率、P99 延迟、队列长度与最老消息年龄。 |业务已经过载，但伸缩指标没有反映压力。 | |伸缩策略状态 |HPA 当前/期望副本数、conditions、扩缩事件、KEDA scaler errors、IHPA 预测与实时差距。 |指标缺失、冲突、触顶、持续预测偏低。 | |Pod 调度与就绪 |期望/已更新/可用副本数、PodScheduled、Ready、镜像拉取、启动和终止耗时。 |期望副本已增加但新 Pod 未就绪；缩容时在途任务未处理完成。 | |节点资源与组件 |节点池上限、库存、IP、APIService、组件重启、查询错误和延迟。 |Pending、指标 API 中断、计划窗口错过。 | |**HPA 状态** |**如何判断** | |---|---| |AbleToScale |表示是否能访问伸缩目标并处理伸缩请求。为 False 时，结合 reason 检查目标引用、scale 子资源、访问权限及暂时性限制。 | |ScalingActive |为 False 时检查 reason/message，区分无有效指标、选择器冲突、目标缩至零等情况；为 True 只说明能够进行指标计算，不保证此次必须改变副本数。 | |ScalingLimited |表示计算结果受到限制，需要区分副本上下限与伸缩速率策略。触及限制不一定是故障，应同时判断可用容量与业务目标是否满足。 | 分别设置指标采集异常和业务指标越界告警，区分“业务负载为零”与“指标没有上报”。判断伸缩状态时，还需结合业务场景： * CronHPA：在计划执行后检查 lastScheduleTime 是否更新；非计划时间保持不变属于正常情况。 * KEDA：无待处理事件时，Active=False 可以是正常空闲状态。 * HPA：出现 ScalingLimited=True 时，检查副本数是否触及上限或下限，再结合业务负载判断是否需要调整范围。 CronHPA、KEDA 均支持指标采集、监控看板和一键配置告警。可通过组件看板查看运行状态，并一键配置组件告警；在此基础上，可按业务需要进一步补充指标告警。 ### 常见问题处理发现伸缩异常时，先检查业务响应和可用副本，再依次查看 HPA 状态、指标、Pod 调度与就绪情况、节点资源。以下命令对应本文示例对象；使用时选择目标工作负载及已安装的组件。资源指标可先通过`kubectl -n autoscaling-demo top pod`确认是否所有 Pod 都缺少数据；自定义或外部指标则从 HPA 的`spec.metrics`读取实际名称与选择器，再按前文 API 路径使用`kubectl get --raw`查询。需要核对多指标和行为字段时，可显式读取`horizontalpodautoscaler.v2.autoscaling`。 ```Bash kubectl -n autoscaling-demo get deployment web kubectl -n autoscaling-demo get pods -l app=web kubectl -n autoscaling-demo describe hpa web-hpa kubectl -n autoscaling-demo get hpa -o yaml kubectl -n autoscaling-demo get events --sort-by=.lastTimestamp kubectl get apiservice kubectl -n kube-system get deployment,pods,services kubectl -n autoscaling-demo describe scaledobject apig-web kubectl -n autoscaling-demo get cronhpa web-cronhpa -o yaml ``` |**现象** |**优先检查** |**处理建议** | |---|---|---| |两个 HPA 都报告 AmbiguousSelector |HPA 目标、ownerReferences 和 Pod 选择器。 |合并指标并保留唯一生效 HPA；由 KEDA 或 IHPA 管理时，从对应源对象修改配置。 | |HPA 的 TARGETS 为 unknown |describe hpa 的 reason/message、指标 API、容器 requests、映射与更新时间。 |按“指标服务不可用—查询无结果—值有效但口径错误”分层定位。API 超时或 503 先恢复后端；空列表检查采集与选择器；有值则核对单位、聚合范围和目标类型。 | |APIService 报告 FailedDiscoveryCheck |后端 Service/Endpoints、组件 Pod、证书与控制面连接。 |分别检查控制面到指标服务、指标服务到 kubelet 或数据源的连接。组件 Pod 缺失时检查事件和准入 Webhook 是否阻断创建；恢复后确认 APIService Available 和实际查询均正常。 | |组件反复重启或资源受限 |OOM、CPU 限流、探针、查询耗时与队列长度。 |按组件支持方式调整资源或简化高开销查询，观察重启次数和查询、处理延迟是否恢复。 | |指标已超过目标但未扩容 |容差、缺失或未就绪样本、速率限制与最大副本数。 |查看 HPA conditions 和事件；缺失指标时先恢复采集，触及上限时先确认节点与下游容量再调整 maxReplicas | |期望副本增加，可用副本未增加 |Pod 调度、亲和性/污点、配额、IP、GPU、镜像、探针和存储可用区。 |Pending 时先确认是否存在满足所有约束的节点池，检查节点扩容失败原因；已调度但未就绪时检查镜像、初始化和探针。资源总量充足不代表 Pod 一定可调度。 | |副本迟迟不下降 |其他指标、指标读取失败、缩容窗口、CronHPA 设置的下限与长连接。 |确认是否仍有负载需求；恢复失败指标或调整不合适的下限，检查应用是否完成在途请求。 | |CronHPA 到点未执行 |时区表达式、分钟窗口、目标引用与组件日志。 |确认是否错过执行窗口、目标引用是否有效；错过关键扩容计划时人工补足业务容量并修正规则。 | |CronHPA 执行后 HPA 上限变大 |规则 target 是否超过原 maxReplicas。 |同时核对规则 target 和 HPA 的 minReplicas、maxReplicas，使计划目标与允许范围一致。 | |KEDA 无法创建策略 |已有 HPA/ScaledObject、资源触发器、Webhook 和认证引用。 |按准入错误修正冲突或配置；迁移现有 HPA 时使用组件支持的所有权接管方式。 | |缩至零后无法恢复 |外部事件是否仍可读取、激活阈值、operator 和指标源。 |恢复独立运行的事件源；同步 HTTP 请求需要专门的激活入口和请求保留机制。 | |发布后副本数突然变小 |Helm/GitOps 中的 replicas 及字段管理者。 |调整发布配置，让伸缩控制器管理副本数，并检查首次移除 replicas 时的默认值处理。 | |缩容期间出现 5xx 或消息重复 |流量停止转发、SIGTERM、退出宽限期、在途任务和消费进度。 |完善优雅退出、重试和幂等处理；PDB 不会阻止 HPA 直接缩容。 | |未超过 maxReplicas，但总 Pod 数更多 |滚动发布额外副本、正在终止的 Pod 和其他同标签工作负载。 |分别核对 HPA 期望副本、实际 Pod 总数和可用副本，按滚动发布策略规划资源。 | |FailedGetScale 或目标不存在 |scaleTargetRef、同命名空间目标对象、API 类型和权限。 |修正目标引用；自定义工作负载确认已实现 scale 子资源。目标为 Deployment 时不要指向其临时 ReplicaSet。 | |指标配置无效或反复出现查询错误 |HPA 的 metrics 结构、指标名、标签选择器和目标类型。 |Utilization 对应 averageUtilization，AverageValue 对应 averageValue，Value 对应 value。验证实际指标 API 查询，检查不支持的标签、重名时序、空值和非数值结果，再确认 HPA 能正常计算。 | |应用已缩容但节点未回收 |节点池下限、资源 requests、PDB、系统 Pod、本地数据及剩余节点是否可容纳工作负载。 |分别检查工作负载缩容和节点回收条件。按节点弹性事件处理阻塞，不通过批量删除业务 Pod 或绕过驱逐保护强制回收。 | |当前指标未达阈值，却发生了扩容 |扩容决策时的指标、所有指标建议、Pod 选择器的实际命中对象和发布状态。 |对照事件时刻的数据，确认同标签 Pod 均属于目标工作负载，再结合多指标和历史建议解释变化；不要用当前指标直接回推过去的决策。 | 处理后，结合 Pod 就绪状态、可用副本、业务吞吐和响应时间确认恢复。配置告警时使用实际暴露的指标名和标签，并区分期望副本增加与新增 Pod 已可服务这两个阶段。将指标采样、HPA 建议与伸缩事件、Pod 创建／退出、Ready 时间及请求日志放在同一时间轴。事件可能被聚合展示，应同时检查首次时间、最近时间和发生次数；日志需提前集中采集，必要时关联分布式追踪定位跨服务瓶颈。伸缩过程类告警可考虑正常采样、启动及稳定窗口，业务错误率和延迟告警则按服务目标独立设置，不能被缩容窗口统一延后。 |**验证情景** |**结果应满足的条件** | |---|---| |逐步加压与预期峰值 |指标反映业务压力，期望副本按配置增加；新增 Pod 就绪并分担请求，延迟、错误率和排队时间满足业务目标。 | |稳定负载与下游压力 |副本能收敛，不持续向上限增长或频繁往返；连接池、外部 API 限流、DNS 与存储没有成为新的瓶颈。 | |负载回落后再次上升 |回收符合窗口和速率，退出时无不可接受的 5xx、任务丢失或重复；再次增长时基础容量足够。 | |部分指标中断或 Pod 未就绪 |能区分真实零值与故障，告警及保护行为符合预期；恢复后同时检查指标、可用副本和业务服务质量。 | ### 临时暂停与恢复伸缩 * KEDA：使用所安装版本支持的 ScaledObject 暂停配置，例如 autoscaling.keda.sh/paused\-replicas。恢复时移除相应注解，并检查策略已重新接管。 * 普通 HPA：故障处理期间可将最小、最大副本数设为同一个非零安全值，确认节点资源足够，且没有其他定时规则或发布任务继续修改副本数。恢复时还原原有范围并观察业务指标。手动将普通 HPA 的目标工作负载缩至零，可能使 HPA 进入隐式维护状态，无法依靠原有指标自动恢复。需要零副本自动激活时，按 KEDA 的事件源要求配置。删除普通 HPA 只停止该对象的自动伸缩，不会自动恢复创建前的副本数。停用前保存策略并确定需要保留的安全副本，停用后检查实际副本和其他管理对象。KEDA 或 IHPA 托管的 HPA 应从对应源对象管理；KEDA 删除 ScaledObject 后是否恢复原副本，还取决于 advanced.restoreToOriginalReplicaCount 等配置。定期清理不再需要的已完成 Job 和旧 ReplicaSet，但保留必要的任务审计与发布回退记录。使用 revisionHistoryLimit、Job 历史数量或完成后 TTL 等受支持的生命周期配置，避免用批量删除替代正常的资源保留策略。