文档中心

容器服务

弹性伸缩

节点弹性伸缩最佳实践

火山引擎容器服务（VKE）支持根据工作负载的资源需求调整节点容量，在业务高峰补充可用资源，在负载回落后回收冗余节点。合理配置节点池、资源请求和缩容保护，有助于兼顾业务可用性、启动时延与资源成本。

说明

配置节点弹性伸缩时，推荐优先使用 Karpenter 方案。它支持多个节点池使用多个实例规格同时扩容，根据 Pending Pod 的调度要求选择合适的节点组合。对于节点池采用资源容量一致的实例规格、计划继续使用集群自动伸缩的业务，也可选择 Cluster Autoscaler 方案。

应用场景

业务场景	常见诉求	节点伸缩建议
在线业务流量波动	高峰补足承载新增副本的节点，低谷减少闲置。	优先使用 Karpenter，并按冷启动时间保留热容量。
固定时段高峰或集中发布	活动开始前完成节点和应用准备。	由工作负载或缓冲 Pod 提前提出需求，给节点、CSI 和镜像准备留足时间。
批任务、EMR 或混合资源需求	为不同资源大小的 Pod 选择容量，减少等待与浪费。	使用多节点池和多个实例规格，额外核对 CSI 客户端开销。
GPU、固定可用区卷或专用硬件	满足设备、拓扑和恢复条件。	按必要边界划分节点池，保持资源模型和新节点属性一致。
对成本敏感且可恢复的任务	固定容量使用包年包月实例，可中断的弹性任务使用抢占式实例。	配置 VKE 节点池混合实例策略，并准备重试与检查点。

选择伸缩方式

业务场景	推荐方式	主要作用
多节点池、多实例规格与突发需求	【优先推荐】节点即时弹性（Karpenter）	根据 Pending Pod 调度要求选择实例规格，支持多个节点池使用多个实例规格同时扩容，并尽可能减少新增节点总数。
已有节点池使用资源容量一致的实例规格，并继续使用集群自动伸缩	节点自动伸缩（Cluster Autoscaler，CA）	按节点池模板与扩容策略调整容量，同一节点池后备实例规格需满足等价调度条件。
短期、大量、突发容器任务且希望减少节点管理	按业务适配情况评估 VCI	使用弹性容器实例承载 Pod。网络、存储、设备与运行约束需单独确认，详情请参见什么是弹性容器实例。

说明

HPA 等工作负载伸缩组件负责增加 Pod 副本，而节点弹性组件负责补充承载这些 Pod 的节点。仅有 CPU 使用率升高、没有新增待调度需求时，不一定会增加节点。按业务需要组合使用。工作负载弹性伸缩的配置，请参见工作负载弹性伸缩最佳实践。

节点池配置

节点池配置是节点弹性伸缩的基础，决定可供给节点的实例规格、可用区、容量范围和调度属性。建议首先完成以下规划，再配置工作负载与伸缩组件。更多节点池信息，请参见节点池概述。

按容量和隔离需求划分节点池

节点池用途	规划方式	启用前检查
系统稳定节点池	为 DNS、监控及其他关键组件保留稳定容量，并按可用性要求分散副本；自托管控制器所在节点池应保留容量，避免节点池缩到零后依赖该控制器恢复。	业务弹性节点池缩容或单节点故障后，控制器、DNS 和必需插件仍有健康副本及可调度容量。
通用弹性节点池	按资源比例和必要隔离边界划分节点池，避免每个微服务都单独创建节点池。	Karpenter 可在多个节点池中配置不同 CPU/内存实例规格； CA 使用同等资源实例规格，同一节点池配置多个实例规格时，以第一个实例规格作为容量基准。
GPU 或其他设备节点池	按设备型号、数量、共享模式和驱动要求拆分，配置污点及容忍。	模板资源名、实际可分配资源和业务请求一致。
有状态或严格可用区业务	按存储与故障域需求选择节点池，具体配置见通过节点池配置可用区。	新节点能够访问目标卷，有足够重建和迁移容量。

每个节点池最多配置 10 个实例规格。Karpenter 根据 Pending Pod 的资源请求和调度要求，从这些实例规格中选择若干合适的实例规格，并尽可能减少需要扩容的节点总数。选择结果还受节点池容量范围、库存和调度约束影响，不代表每次都会使用所有候选实例规格。

实例规格还需满足业务的 GPU 型号和操作系统要求。存在精确机型或设备约束时，使用匹配的专用节点池，并检查实际交付节点的标签和资源是否一致。

CA 以节点池首个实例规格作为容量估算基准。后备实例规格应具有同等资源容量，并满足等价调度条件；否则可能出现模拟可调度、实际节点却无法容纳 Pod 的情况。自定义标签、污点等属性的参考来源见保持节点标签与调度条件一致。

系统稳定节点池也需要随集群规模调整。新增大量节点或 Pod 后检查 CoreDNS 请求负载、延迟及失败情况，并按所用组件的配置方式补充容量。跨节点或跨可用区分散副本时，要同时保留足够的可调度节点，避免硬反亲和使系统组件在缩容后无法重建。

通过节点池配置可用区

Pod 需要在指定可用区运行时，通过节点亲和性选择目标节点池，并配置该节点池的子网与扩容策略。优先让每个节点池只对应一个可用区；同一个可用区可以对应多个节点池。这样可以明确每个节点池对应的节点可用区，便于配置调度约束和排查问题。

需要跨可用区部署业务时，为各可用区准备相应节点池，再按工作负载的调度要求选择目标节点池。例如，同一可用区可以分别建立在线业务节点池和批任务节点池；另一个可用区使用各自的节点池。

配置步骤	操作	结果检查
规划节点池与可用区	在目标可用区选择子网，核对 IP、实例规格和存储条件。	节点池内子网的位置和可用资源满足预期。
选择目标节点池	在 Pod 的必需节点亲和性中使用目标节点池的标签键和值；Karpenter 拓扑亲和场景同时保留 machine-name 的 Exists 条件	Pod 匹配指定节点池，新节点具有对应节点池标签和所需拓扑键。
设置节点池扩容策略	核对节点池内子网 IP、候选实例规格和库存，按业务要求选择节点池支持的扩容策略。	从伸缩记录和实际节点核对所用子网、可用区及实例规格。
检查业务结果	核对 Pod 所在节点池、节点可用区、卷挂载及 Pod Ready 状态。	业务在目标可用区运行；失败时按亲和性、节点池子网/策略、库存和卷约束依次定位。

如需单个节点池在多个可用区创建节点时，可配置多可用区子网与扩容策略，并额外核对每次扩容实际使用的可用区。已有固定可用区数据卷时，候选子网必须满足数据卷的可用区约束；跨可用区创建节点不会迁移已有数据卷，候选节点仍需满足业务硬约束。

保持节点标签与调度条件一致

扩容时，CA 与 Karpenter 对自定义标签、污点等调度属性的参考来源不同。

组件	节点池状态	自定义标签、污点的参考来源
Karpenter	无论是否有存量节点	始终从节点池配置派生
CA	有存量节点	以存量节点作为参考
CA	没有存量节点	从节点池配置派生

在节点池中统一维护业务需要的自定义标签和污点，并检查存量节点是否与节点池配置一致。

CA 在有存量节点时参考其属性，节点池缩到零后则参考节点池配置；仅修改存量节点可能影响 CA 的扩容判断，但不会保证新节点获得相同属性。

Karpenter 始终参考节点池配置，仅修改存量节点不会改变其扩容时使用的调度属性。

允许缩容到零的节点池，应提前在节点池配置中补齐业务所需标签和污点。扩容后检查新节点的实际属性；如 Pod 仍因标签或污点不匹配而 Pending，按上表核对对应来源，并修正节点池配置与节点属性。Karpenter 的系统拓扑键按“配置 Karpenter 的拓扑亲和”设置存在性条件，不为所有节点填写同一个固定值。系统组件、控制器和必需插件应保留可独立运行的稳定容量。

配置硬亲和性、污点和拓扑约束时，确认至少有一个节点池能够同时满足这些条件。对于调度偏好，可使用软亲和性；使用拓扑分布约束时，可按业务需要设置whenUnsatisfiable: ScheduleAnyway。设备、数据和隔离等必须满足的要求应使用硬约束。

如果没有节点池或实例规格满足要求，需补充相应资源，或经业务确认后调整约束。节点弹性会遵循这些硬约束；增加节点数量无法解决约束不匹配，也不会自动增加业务副本或重新均衡现有 Pod。

设置容量上下限和故障余量

容量项	设置方法	需要核对的结果
节点池最小节点数	覆盖稳定负载及业务允许的故障范围；允许冷启动且具备完整节点池配置的低频业务节点池可设为 0；关键系统组件保留稳定容量。	最小节点数是配置下限，不能代替 Ready 节点和业务可用副本检查。
节点池最大节点数	覆盖峰值、发布额外副本、故障转移和迁移余量。	未因节点池最大节点数限制而持续 Pending。
云资源配额和库存	按候选实例规格、可用区确认配额；为缺货准备可替代实例规格或故障域。	配额足够且云端活动能够成功创建实例；配额不保证库存。
子网和网络	预留新增节点及 Pod 所需 IP，核对 CNI 模式和网卡限制。	实例创建后可以注册节点并分配 Pod 网络。
业务热容量	按可接受启动时延保留可立即承载业务的余量。	突发期间 Pod Ready 时间满足业务目标，详情请参见性能与扩容效率。

为允许故障转移的工作负载预留后备节点池容量，并确认节点亲和性和卷约束允许使用这些节点池。

使用支持延迟绑定的存储时，在 StorageClass 配置volumeBindingMode: WaitForFirstConsumer，同时核对 CSI 能力、allowedTopologies 和已有 PV 的nodeAffinity。配置方法见 Kubernetes 存储类和拓扑分布约束。

节点池上下限不能替代云资源配额。预计峰值超过账户节点、实例或其他资源配额时，提前按如何提升配额（Quota）申请调整，并为库存不足准备满足业务约束的后备实例规格。

核算容量时，分别统计每个节点池的配置上限、已有节点、正在创建的实例和 Ready 节点，并统一核算多个节点池共享的账户配额、子网资源和可用区库存。例如：假设两个节点池的最大节点数均为 20，合计配置上限为 40；如果共享账户的剩余实例配额为 10，后续扩容仍受这 10 个实例额度约束，实际可扩数量还取决于已有容量、在途请求和库存等条件。

提高节点池最小节点数或节点池最大节点数后，继续核对伸缩记录和实际 Ready 容量；降低节点池最大节点数也不应当作立即强制删除节点的命令。节点归属、在途请求和业务保护都会影响实际结果，修改后以目标节点池状态和活动记录确认。

混合使用按量付费与抢占式实例

VKE 节点池支持通过节点分布策略混合使用按量付费实例与抢占式实例，适合能够接受实例回收、具备重试或恢复能力的弹性业务。混合策略中的按量基础容量用于保留该节点池内的按量付费实例，不替代固定容量的包年包月规划。

配置目标	节点池配置	使用要点
保留按量基础容量	节点分布比例策略中的“按量实例基础容量”	设置需要由按量实例承载的基础节点数量，并与节点池容量范围一致。
分配剩余容量的计费类型	“按量实例比例”	比例作用于扣除按量基础容量后的剩余节点，不是整个节点池的固定比例。
抢占式实例无法提供容量时补充资源	“按量实例补充抢占式容量”	候选实例规格应同时支持两种计费方式；补充后按量比例可能超过原设置，已补充的按量实例不会因抢占式库存恢复而自动换回。

具体配置和适用范围见创建抢占式实例节点池。该文档还介绍节点池层的抢占式实例补偿策略，按业务恢复要求选择，并检查活动结果与实际费用。

控制弹性资源费用

根据容量使用时长和业务可中断性选择计费方式，将固定容量与弹性容量分别规划。

容量类型	推荐计费方式	配置重点
长期稳定的固定容量	包年包月实例	按稳定业务需求采购；与需要自动扩缩容的弹性容量分开规划
随业务变化的弹性容量	按量付费实例或弹性预约实例	按实际需求与预约条件选择，并为高峰预留配额和可用容量
可接受实例自动回收的弹性容量	抢占式实例	业务具备重试、检查点或恢复能力；结合按量补充策略控制供给和费用
为缩短业务等待保留的热缓冲	按保留时长选择相应计费方式	占位 Pod 的 requests 会占用可调度容量，维持这部分缓冲所需的节点会产生费用，应计入容量和费用预算

多个实例规格的单价不同，不能只按节点数量比较成本。持续核对节点小时、计费类型和账单；抢占式容量由按量实例补充后，费用可能增加。节点回收后，还应按保留策略检查独立云盘、快照等资源是否继续计费。

在相近业务量、可用性和启动时延下评估成本变化。节点池最大节点数用于限制容量，不能替代费用预算；费用告警只用于提醒，不会自动停止扩容。

工作负载配置

根据已规划的节点池，设置工作负载的资源请求和调度约束。确认节点池提供的资源与调度属性能够满足 Pod 需求后，再优化伸缩速度。若扩容后 Pod 仍无法调度，优先检查资源请求和调度约束是否与新节点匹配。

为工作负载声明完整资源需求

为业务容器设置 CPU、内存 requests，并计入 Sidecar、Init Container、临时存储和设备需求。结合历史负载和峰值校准，避免用 limits 或当前使用率代替请求量。

以节点实际 Allocatable 为基础，扣除预计运行的 DaemonSet 等 Pod 的资源请求，估算业务可用容量。节点预留资源的计算规则见节点预留资源，已计入 Allocatable 的预留资源无需重复扣除。至少应有一个满足调度条件的候选实例规格，能够在扣除这些开销后容纳单个 Pod 的有效请求。

检查节点可容纳的 Pod 数量、子网剩余 IP、网卡资源和卷挂载数量。任一资源达到上限，都可能使新增 Pod 无法调度或启动。

配置 Namespace 的ResourceQuota和LimitRange，减少资源请求漏配并限制资源异常增长。若 Pod 因配额限制而创建失败，先解决创建问题，再检查节点容量；节点弹性负责补充承载 Pod 的节点。

计算请求时应区分容器生命周期。普通 Init Container 顺序执行，不能把所有 Init Container 的 requests 与业务容器简单相加；应按集群版本对应的调度规则核对 Pod 的有效请求。Sidecar、设备插件及业务启动方式变化后重新评估，配置规则见。

为 CSI 客户端预留额外资源

使用 CSI 存储的工作负载，除节点预留资源和 DaemonSet 请求外，还需检查 CSI 组件是否额外创建客户端 Static Pod。Karpenter 在选择实例规格时不会额外计入这类 CSI 客户端资源，业务应根据客户端实际请求预留容量，并避免与 CSI DaemonSet 请求重复计算；否则新节点创建成功后，业务 Pod 仍可能因资源不足而无法调度。

存储组件	容量规划重点	操作建议
csi-vepfs	除 CSI DaemonSet 外，核对每节点额外客户端 Pod 的 CPU、内存请求。	检查客户端实际配置，并在可供业务使用的容量中预留额外客户端开销。
csi-fsx	核对每节点客户端的额外请求及自定义配置。	按客户端实际请求和业务所需资源预留容量，并检查新节点是否能容纳业务 Pod。
csi-tos	客户端请求可配置，资源占用随每节点挂载的 PV 数量增长。	按预计每节点挂载数量预留余量，并检查实际客户端请求。详情请参见 TOS 存储配置。

配置 Karpenter 的拓扑亲和

使用 Karpenter 且 Pod 配置了拓扑亲和时，必须使用cluster.vke.volcengine.com/machine-name作为 topologyKey。同时在 Pod 的nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution中，对同一标签键配置operator: Exists，确保 Pod 只调度到具有该拓扑键的节点。

如下示例为工作负载 Pod 模板的spec配置，通过软反亲和尽量将同一业务的 Pod 分散到不同节点，并通过节点亲和性限定目标节点池。示例权重为 weight: 100，请按业务需要调整。使用时，将节点池标签键、标签值和业务标签值替换为实际配置；节点池标签应以目标节点池中配置的键和值为准。

拓扑键存在性和节点池选择条件放在同一个nodeSelectorTerm的matchExpressions中，表示同时满足。若已有多个候选nodeSelectorTerm，每个候选项都应保留该拓扑键的 Exists 条件。配置后检查新节点是否具有该标签、Pod 是否落在目标节点池，以及亲和规则是否满足；存在性检查不通过时，先核对节点标签和节点池配置。

节点即时弹性（Karpenter）

通过 VKE 组件管理安装 Karpenter，并为目标节点池配置候选实例规格、容量范围、标签与污点。安装步骤和参数说明，请参见配置节点即时弹性（Karpenter）。

Karpenter 根据 Pending Pod 事件触发扩容评估，为新增节点能够解决的待调度需求选择节点组合。它支持多个节点池使用多个实例规格同时扩容，并在满足调度要求的前提下尽可能减少新增节点总数。已分配到节点、正在等待镜像或存储初始化的 Pod，不应仅因处于 Pending 阶段就被判定为需要扩容。新节点就绪后，还需确认业务 Pod Ready。

选择实例规格与配置节点池

配置项	设置方式	结果检查
节点池与候选实例规格	可选择多个参与弹性的 VKE 节点池，每个节点池配置不超过 10 个实例规格；容量大小可不同，关键属性须满足业务调度要求。	多个节点池可同时扩容；各节点池实际交付实例规格属于对应的有效候选，Pod 可调度。
节点池优先级（可选）	按业务需要配置节点池优先级；未显式设置时，默认优先级为 10。优先级相同的节点池之间不保证严格的扩容顺序。	优先级是软约束，应结合 Pod 调度要求判断实际选择结果。
弹性伸缩状态	Karpenter 不支持关闭弹性伸缩。	不将关闭节点池弹性伸缩作为暂停或退出 Karpenter 管理的操作。
自动缩容	单独配置节点回收。参数说明，请参见配置节点即时弹性（Karpenter）。	关闭自动缩容只暂停自动回收，不会停止扩容；已经进入退出流程的节点单独跟踪。
启动依赖	按实际插件配置启动污点及移除责任。	Node Ready 后，设备资源上报、启动污点清除、Pod Ready 均符合预期。

节点池已配置候选实例规格，并不代表该实例规格始终有可用库存。创建失败时，根据伸缩活动的错误信息检查库存、配额和网络资源，再按需调整节点池的可用区子网或候选实例规格。

节点池优先级用于扩容时选择候选节点池；Pod PriorityClass影响 Pod 的调度与抢占；节点亲和性约束 Pod 可以使用的节点。配置节点池优先级不会使 Pod 优先调度到该节点池的已有节点，也不会自动迁移已经运行的 Pod。

理解实例规格选择结果

例如：候选实例规格包含 4 vCPU/16 GiB 和 8 vCPU/32 GiB，两个业务 Pod 分别请求 3 和 5 vCPU。Karpenter 会综合内存需求、节点预留资源、DaemonSet 请求、现有容量和调度约束选择节点组合，实际结果不一定是按两种实例规格各创建一个节点。确认新增节点属于候选实例规格且能够承载待调度 Pod 后，再结合资源请求、可调度容量和实际使用量评估利用情况；节点总数本身不能代表资源利用率或成本。

节点自动伸缩（Cluster Autoscaler）

通过 VKE 组件管理安装 CA，并为参与弹性的节点池配置容量范围及调度属性。安装步骤和参数说明，请参见配置节点自动伸缩（Cluster AutoScaler）。

CA 检查 Pod 是否可通过新增节点完成调度，再根据节点池模板和扩容算法选择节点池扩容。

选择扩容策略

扩容算法、弹性灵敏度和自动缩容参数的范围及默认值，以“配置与使用文档”中的 CA 使用文档为准。按业务需求选择以下扩容算法。

扩容算法	作用	使用建议
random	从满足调度要求的节点池中随机选择。	适合没有明确节点池偏好的场景。
most-pods	倾向于选择可容纳本轮更多 Pod 的节点池。	同构负载下可能出现多个同分节点池。
least-waste	按扩容后的剩余资源选择节点池。	用于关注资源利用率的场景，不按实际价格排序。
priority	按配置的节点池优先级选择。	适合有明确容量使用顺序的场景；选择结果不符时，检查优先级规则和节点池标识。

开启自动缩容前，先配置“缩容与业务保护”中的应用保护。调整弹性灵敏度后，关注节点创建和 Pod 就绪情况；需要排查组件处理异常时，使用“启用组件观测与告警”中的日志和看板。

控制模板复杂度与扫描开销

CA 以节点池首个实例规格作为容量估算基准；同一节点池的后备实例规格应保持 CPU、内存等资源容量以及设备、关键调度属性等价。按实际隔离或资源需求划分节点池，避免为每个微服务单独创建节点池。参与伸缩的节点池、Pending Pod 和调度约束增多时，扫描与模拟耗时可能增加；先检查节点池划分、待调度 Pod 的数量与约束，再按 CA 使用文档调整弹性灵敏度。

仅使用 CA 时，可对不再需要伸缩的节点池关闭弹性伸缩，减少无效模拟；该做法不适用于 Karpenter。大规模突发时，检查待调度 Pod 是否持续减少，以及节点池最大节点数、云资源配额和库存是否满足需求；条件满足但扩容仍无进展时，结合组件日志和伸缩记录联系平台排查。

缩容与业务保护

先配置应用的副本保护和退出行为，再开启自动缩容，并为迁移 Pod 保留合适容量。缩容阈值、触发时延和退出超时按组件使用文档配置，相关入口统一列于“配置与使用文档”。节点持续不能回收时，先检查业务保护和迁移条件；频繁回扩时，再结合业务周期调整缓冲与缩容设置。

设置副本保护与退出时间

工作负载	操作	预期结果与异常处理
多副本无状态服务	按最小可服务副本配置 PDB，并设置 readiness、停止接流和连接排空。	通过 Eviction API 发起的驱逐受 PDB 约束；若持续阻塞，先恢复不健康副本或补足重建容量，再按业务可用性要求评估预算。
本地数据、裸 Pod 或不可重建状态	先确认数据备份、重建方式和控制器归属；迁移能力不足时保留节点。	确认数据已备份或可恢复，且工作负载能够在其他节点重建；满足迁移条件后再解除保护
Job 或训练任务	实现检查点、幂等和重试，确认退出窗口内能保存进度。	重建后能从有效状态继续；不能恢复的任务应保持保护直到完成。
有长连接或长退出流程的应用	依据实测配置 preStop、terminationGracePeriodSeconds 和组件退出时间。	应用能在期限内完成退出；超时先修复排空或检查点流程，再调整时限。

以下 PDB 示例适用于标签为app: elastic-web、至少有 3 个健康副本且业务允许同时少 1 个副本的服务。maxUnavailable: 1 为示例值，应按实际可用性要求修改。用于其他工作负载时，先替换命名空间和标签选择器，并核对健康副本数。

PDB 约束通过 Eviction API 发起的驱逐，不能阻止机器故障、云端实例回收或直接删除 Pod，也不替代 Deployment 等工作负载的滚动更新策略。单副本配合minAvailable: 1会阻止该副本的自愿驱逐；应根据业务目标选择增加副本或接受不缩容。详细配置见 Kubernetes Pod 中断与 PDB。

按组件设置必要保护

保护目标	Karpenter 配置	CA 配置
暂时保留某个 Pod 所在节点	为 Pod 注解karpenter.sh/do-not-disrupt: "true"。	为 Pod 注解cluster-autoscaler.kubernetes.io/safe-to-evict: "false"。
禁止某个节点参与自动缩容	在与该 Node 同名的 NodeClaim 对象上添加 karpenter.sh/do-not-disrupt: "true"。	在 Node 对象上添加cluster-autoscaler.kubernetes.io/scale-down-disabled: "true"。
本地存储和系统 Pod	对本地数据和不可中断负载显式设置缩容保护。	默认存在跳过本地存储及部分 kube-system Pod 的保护，检查实际选项。

将 Pod 级保护注解写入工作负载的 Pod 模板，可使新建的 Pod 沿用该保护。配置 Karpenter 节点级保护时，只编辑与 Node 同名的现有 NodeClaim；若未找到对应对象，先确认节点是否由 Karpenter 管理。任务完成或迁移条件具备后，从原对象移除临时保护，并确认节点恢复正常回收。

PDB 和 do-not-disrupt 会约束 Karpenter 的自愿缩容，但不能依靠事后追加保护注解撤销已经开始的节点删除。节点进入退出流程后，应按组件使用文档中的退出时限跟踪应用退出；保护注解不能阻止机器故障或云端实例回收。

本地卷需要区分可丢失缓存和持久数据。safe-to-evict 只影响驱逐判断，不会复制或迁移数据；只有已确认可重建的数据才能放行。kube-system 中非 DaemonSet、非 Mirror Pod 的保护也应结合实际 CA 配置检查。多个重叠 PDB 可能同时限制驱逐，应优先使用清晰的副本可用性约束，并检查剩余健康副本。

在大促、发布或迁移窗口需要减少自愿中断时，可提前按支持入口调整自动缩容配置或为必要负载设置临时保护，记录恢复条件和负责人。窗口结束后恢复原配置，并确认回收能力恢复。保护配置应在节点进入退出流程前生效；已经开始的删除和云端实例回收仍需继续跟踪。

性能与扩容效率

通过预留热容量、提前准备高峰资源和使用自定义系统镜像，减少业务等待新节点与容器启动的时间。以 Pod Ready 和业务可服务为判断依据，结合实际容量费用选择方案。

为有启动时延要求的业务保留缓冲

可用低优先级占位 Pod 预留可调度容量：平时通过 requests 预留资源，符合抢占条件的高优先级业务 Pod 到来后可抢占缓冲；占位 Pod 重新等待调度并满足扩容条件时，节点弹性补充容量。应按计划预留的 CPU、内存等资源设置 requests，匹配对应的节点池、可用区和设备需求，并确保占位 Pod 能快速退出。

操作	通过条件	异常时处理
根据冷启动窗口内的新增需求和故障余量设置缓冲	突发业务可在目标时间内获得可用容量。	延迟仍高时检查缓冲是否处于正确的节点池/可用区，或是否不足。
设置业务优先级高于缓冲	业务能抢占缓冲，缓冲随后恢复。	检查 PriorityClass、抢占策略、硬约束和节点池最大节点数。
让缓冲参与扩容	确认占位 Pod 等待调度时能触发节点扩容。	占位 Pod 未触发补容时，检查其优先级、调度约束和节点池可用容量。
降载后回收多余容量	缓冲保留到规划规模，无持续来回扩缩。	检查缓冲副本、缩容等待和业务周期是否匹配。

以下 PriorityClass 示例将缓冲优先级设为 -10。请按业务实际优先级调整该值，确保业务优先级更高，并确认名称未被占用。将该 PriorityClass 用于配套的占位 Deployment；GPU 等资源仍需在占位 Pod 中声明。配置后，检查业务 Pod 能否抢占缓冲，以及占位 Pod 能否触发扩容并恢复到预设规模。

提前准备固定高峰和大批任务

已知活动开始时间时，使用已部署的定时工作负载伸缩能力，提前增加业务或占位 Pod。预留时间应覆盖节点交付、存储与网络初始化、镜像准备和应用启动；活动开始前确认节点及业务 Pod 已就绪，结束后恢复基线。

集中提交大批任务前，核对节点池最大节点数、云资源配额和候选实例规格的可用容量。业务允许时分批提交，关注待调度任务数量的变化；扩容活动失败或新节点长时间未就绪时，结合组件日志和节点池伸缩记录定位原因。

优化节点与容器镜像准备

大量 Pod 使用相同大镜像时，可将业务容器镜像提前预置到自定义系统镜像中。新节点完成初始化、网络和存储等依赖就绪后，可复用本地容器镜像启动业务，减少从镜像仓库下载的等待。

操作	需要确认的结果
选择 VKE 兼容的基础系统镜像	基础镜像与所用实例规格、容器运行时和设备要求匹配。
预先拉取业务容器镜像并制作自定义系统镜像	镜像位于 kubelet 使用的容器运行时镜像存储中；业务使用的镜像名称、版本或 digest 与预置内容一致。
在节点池中选择自定义系统镜像	后续扩容的新节点使用该系统镜像；已存在节点不会仅因更新配置而自动改变。
核对新节点上的启动结果	容器复用本地镜像、Pod 正常 Ready；如仍发生下载，检查镜像标识、拉取策略和缓存是否保留。

镜像制作与适用要求见操作系统镜像概述。希望优先复用预置镜像时，可按发布要求使用imagePullPolicy: IfNotPresent，并通过明确版本或 digest 管理镜像，避免可变标签命中旧缓存。使用 Always 时仍需访问镜像仓库完成解析与鉴权，已缓存的镜像层可以复用。业务镜像更新后，应同步更新系统镜像中的预置内容，并确认后续新增节点使用了预期的业务镜像。

还可通过精简容器镜像、减少不必要的启动脚本和预拉取镜像，进一步缩短启动准备时间。使用占位 Pod 保留热容量时，仍需分别准备业务镜像、卷和设备环境。

兼容性说明

组合使用要求

组合	配置要求
工作负载伸缩与节点伸缩	HPA、CronHPA 或 KEDA 等负责产生 Pod 需求，节点组件补充节点。工作负载伸缩的配置方式，请参见选择伸缩方式。
Karpenter 与 CA	同一集群选择一种节点弹性组件；同一节点池的期望容量由一个伸缩方案管理。
IaC/GitOps 与节点伸缩	明确由节点弹性管理的容量字段，并调整 IaC/GitOps 的同步配置，避免将伸缩后的节点数量反复恢复为固定值
托管组件的高可用与性能	Karpenter 和 CA 均由 VKE 托管，用户无需管理组件部署；通过组件管理查看状态，通过日志、指标和看板排查问题。

监控与告警

持续关注业务可用容量、等待时间和云端交付结果。按集群、节点池及组件区分数据，避免把其他集群的伸缩事件计入当前业务。

Karpenter 和 Cluster Autoscaler 均提供日志、指标和监控看板，并将预置告警集成在控制面服务告警模板中，可一键开启。请先启用云原生观测，再基于控制面服务观测配置组件采集与告警。

操作	结果检查
在集群左侧导航栏中，选择观测配置 > 基础观测，启用控制面服务观测，确认所用伸缩组件的采集配置。	能查询对应组件的日志和指标；没有数据时先检查采集是否开启、组件是否安装及查询时间范围。
在集群左侧导航栏中，选择监控中心 > 监控看板，在核心组件监控中查看 Karpenter 或 Cluster Autoscaler 看板。	结合相同时间范围的日志、节点池伸缩记录和 Pod 状态查看节点扩容与回收情况。
在控制面服务的编辑配置 > 告警中开启预置告警模板，并配置告警聚合和通知策略。	规则已启用，通知策略覆盖需要接收告警的人员；若未看到节点弹性相关规则，检查模板版本和集群配置。

优先启用组件异常与伸缩状态相关的预置规则，收到告警后按下表定位。具体阈值、持续时间及规则是否启用，以当前告警配置为准。

预置告警	关注的现象	处理建议
Karpenter 异常	组件采集目标持续不可用	检查指标采集链路、组件状态及日志，联系平台处理托管组件异常。
Cluster Autoscaler 异常	组件采集目标持续不可用	检查指标采集链路、组件状态及日志，确认是否影响待调度 Pod。
Cluster Autoscaler 无法安全伸缩	集群未满足伸缩安全条件	检查 NotReady、未注册或长时间处于伸缩中间态的节点，并关联伸缩记录。
Karpenter 集群状态未同步	组件状态尚未与节点、Pod 信息同步	检查组件日志中的状态同步错误，关联实际节点和 Pod 状态，必要时联系平台处理。

除预置告警外，还应按业务目标关注可用副本数、Pod Pending 最长等待时间、Pod Ready 时延和请求错误率。提交排查信息时，提供发生时间、对象名称、伸缩活动编号和已脱敏的错误信息。成本评估应结合实际节点小时和账单，同时考虑 Pod 重新调度、缓存重建和任务重试产生的开销。

配置对象	相关操作	使用文档
VKE 节点池	配置实例规格、子网、容量上下限、标签与污点等节点属性。	节点池概述
Karpenter	安装节点即时弹性组件，调整弹性规则和自动缩容配置。	配置节点即时弹性（Karpenter）
Cluster Autoscaler	安装节点自动伸缩组件，配置扩容策略、弹性灵敏度及自动缩容。	配置节点自动伸缩（CA）