全部文档
当前文档
最近更新时间：2026-04-29 16:10:08
KMR on KCE 的 Flink 作业提供了自动伸缩（Autoscaler）功能，通过实时监控算子的利用率、反压及积压量，结合原地扩缩容（In-place Scaling）技术动态调整并行度。该功能有效解决了 Flink 作业上线初期需耗费大量时间压测预估资源的难题，同时也缓解了运行过程中因流量波动导致的“人工调参滞后”积压及“重启代价过高”带来的业务断流等核心痛点。
本文为您介绍如何配置自动伸缩模式，以及配置过程中的注意事项。
状态依赖：仅在作业处于运行中状态时生效。
提交方式：目前仅支持通过控制台或 OpenAPI 提交的任务，暂不支持 YAML 编排提交。
资源保障：建议将开启自动伸缩的作业部署在具备 弹性伸缩能力 的节点池中。如果 K8s 物理资源枯竭，无法进行扩容，无法缓解积压。
登录KMR on KCE控制台，选择目标集群。
点击 新建作业 或选中现有Flink 作业点击 编辑。
滚动至 【自动伸缩配置】 区块：
自动调优开关：切换为“开启”。
执行模式：
原地扩缩容（推荐）：系统自动计算并执行调整动作。
仅收集指标：系统仅生成伸缩建议并在记录中展示，不实际改变作业状态。适用于上线初期的观察阶段。
参数名称 | 说明 | 推荐设置 |
静默时段 | 设定不执行伸缩的时间段。支持周/日设置。最多设置三个 | 设置在业务最核心波峰期 |
目标利用率 | 算子期望的繁忙率（Busy Time %）。 | 60%（范围10%~90%） |
利用率边界 | 容忍的波动缓冲区。实际值超过 | 20%（范围0~50%） |
调整间隔时间 | 作业伸缩重启生效一次之后，下一次再进行调优的时间间隔。 | 5 分钟（范围1~60分钟） |
指标收集窗口 | 计算决策依据的历史指标聚合时间。窗口越大越平稳，窗口越小反应越敏锐。 | 15 分钟（范围3~60分钟） |
最大并行度 | 全局最大并行度。建议选择具有较多约数的数值。 | 720 |
点击 <其他配置> 展开，在自定义配置中可以 Key-Value 形式增加精细化参数：
job.autoscaler.vertex.min-parallelism: 建议将 Source 算子设置为其对应的分区数，防止过度缩容。
job.autoscaler.scale-down.interval: 专门针对缩容的延迟时间（默认 1 小时），可合并多次缩容，减少波动。
job.autoscaler.restart.time: 预估重启耗时（如 3min），算法将依据此值计算扩容收益是否覆盖重启成本。
更多高级配置参考官方文档：Flink Autoscaler Configuration
系统会自动保存最近 50 条 伸缩事件，便于审计追踪。
进入 Flink作业详情页。
点击 状态信息 > 【自动伸缩记录】 。
列表说明：
执行时间：动作发生的精确时间
执行动作：展示是“自动扩容”、“自动缩容”还是“弹性调整”。
执行结果：展示算子变化的原始记录。
可能原因：
稳定化窗口限制：作业可能仍处于 stabilization.interval（稳定化窗口）内，系统正在观察上一次调整后的效果。
利用率未达阈值：当前算子繁忙率处于 目标值 ± 边界值 范围内（例如目标 60%，边界 20%，则 40%-80% 之间不触发）。
资源触顶：已达到全局 pipeline.max-parallelism 或高级参数中设置的 quota.cpu / memory 上限。
指标缺失：算子未暴露 busyTimeMsPerSecond 指标（常见于自定义 Source 或旧版 API）。
排查建议：
检查日志：在 JobManager 日志中检索 ScalingReport 关键字，查看系统计算出的建议值。
验证配置：通过控制台确认“执行模式”是否为“原地扩缩容”。
UI 观测：进入 Flink Web UI，确认算子（特别是 Source）的 Busy Time % 是否有数据。
若作业频繁在扩容和缩容之间切换，建议优化以下参数以增强稳定性：
调大指标窗口：将 metrics.window 延长（如从 15min 改为 30min），以平滑瞬时流量波动。
增加缓冲区：增大 target.utilization.boundary，给予负载更多波动空间。
延迟缩容：在高级配置中设置 scale-down.interval（如 1h），合并多次微小的缩容动作。
请根据业务对延迟的容忍度进行选择：
保守型 (0.4 - 0.6)：适用于金融、计费等核心链路，预留充足资源缓冲，减少重启频率。
均衡型 (0.6 - 0.7)：推荐配置，兼顾资源成本与响应速度。
激进型 (0.7 - 0.8)：适用于非实时报表或低优先级作业，追求极高的计算资源性价比。
Autoscaler 自动调整 Source 并行度需满足以下条件：
API 要求：必须使用 Flink 新版 Source API（FLIP-27）。
指标要求：连接器需支持暴露 pendingRecords（积压量）指标。
对齐分区：建议将 vertex.min-parallelism 设置为 Kafka Topic 的分区数，避免数据倾斜。
建议选择具有较多约数的数值，便于系统在扩缩容时更均匀地重新分配 KeyGroup。
注意：此值一旦设定，作业运行期间不可更改。如果设置过小，将限制 Autoscaler 的扩容上限。
会。 一旦开启自动伸缩，系统会接管并行度管理。如果您需要手动干预，请先将“执行模式”切换为“仅收集指标”或关闭该功能。
需要。 在作业参数中，建议设置： "slot.request.timeout": "900000" (即 15 分钟)。 原因：当 Autoscaler 触发扩容时，底层 KCE 节点池可能需要 5~10 分钟来弹出新机器。将超时时间设为 15 分钟，可以确保 Flink 作业在等待云原生资源拉起时不会因超时而失败。
请确认作业的 Flink 版本：
Flink 1.18+：支持原生 In-place Scaling（原地扩缩容），几乎无感。
Flink 1.17 及以下：不支持原生原位扩展。系统会通过“作业升级（Job Upgrade）”模式重启任务来应用新并行度。如果重启过程失败，并行度将回滚至旧状态。
查看记录 ：作业详情页的【自动伸缩记录】展示了扩缩容的具体原因。
详细日志：将 org.apache.flink.kubernetes.operator.autoscaler 的日志级别调整为 DEBUG，可以查看到系统对每一个算子处理速率的具体评估公式。
启用弹性伸缩：确保该作业所在的 K8s 节点池已开启 CA (Cluster Autoscaler)。
标签隔离：建议通过 nodeSelector 将开启自动伸缩的作业调度到专用的“弹性节点池”，避免扩缩容影响到核心静态资源池。
纯净模式
