Lyft完成数百生产任务迁移：弃用自研控制器，全面转向 Apache Flink Kubernetes Operator

一句话结论

Lyft 迁移流式计算集群至 Apache Flink Kubernetes Operator，启用基于上次状态升级与原地自动扩缩容，重构集群资源调度机制。

关键要点

• Lyft 淘汰 2020 年自研 Flink Operator，核心动因是每次 Flink 升级均需维护，且自动伸缩与回滚能力存在缺陷。
• 迁移覆盖数百个生产环境 Apache Flink 作业，解锁基于上次状态（last-state）升级、原地自动伸缩与资源自动调优功能。
• 部署模式从双部署（dual-deployment）替换为先停后启（stop-then-start），常规作业产生 3 至 6 分钟停机时间。
• 为支持自动扩缩容，Flink 升级至 1.19 版本，该版本支持原地扩缩容并解锁 KinesisStreamsSource 组件。
• 自动调优与原地自动扩缩容存在冲突，Lyft 按业务关键性拆分功能，高关键作业采用不带自动调优的原地扩缩容。

背景与事实

Lyft 于 2020 年构建自研 Operator，彼时开源社区尚未提供运行在 Kubernetes 上 Flink 的专用控制平面。早期双部署升级会启动第二个集群、创建保存点、取消旧作业并从保存点恢复。遗留 Operator 的 BlueGreen 模式要求在工程师手动切换流量前保持两个集群同时运行。原有保存点触发器缺乏重试逻辑与幂等性，对于较大状态作业，超时且无可用最近检查点时会导致部署失败或作业在完全无状态情况下重启。非 JVM 内存预留仅由 systemMemoryFraction 参数控制，该参数本质是对 Apache Beam Python 运行环境额外开销的粗略估计。若设置过低，TaskManager 会因内存溢出被系统杀掉；设置过高则浪费整个集群内存。

此次迁移将数百个生产作业从自研 Kubernetes Operator 转移至 Apache Flink Kubernetes Operator。Lyft 工程师在文章中说明，此次迁移在集群范围内解锁了基于上次状态升级、原地自动伸缩与资源自动调优功能。Apache Flink Operator 将基于上次状态恢复作为第一等级升级模式，即使 JobManager 处于不健康状态，也能从高可用元数据或最新检查点进行恢复。为避免重写 Jsonnet 模板，Lyft 部署 API 在边界层将遗留 FlinkApplication 规格自动转换为 FlinkDeployment 资源。该转换层将 jarName 映射为 jarURI，将节点选择器提取并转换为 PodTemplateSpec 对象，注入遗留环境变量，并将升级策略默认设为从上次状态恢复。

Apache Operator 优先启动 JobManager 以管理 TaskManager 生命周期。在弃用旧版 Operator 时，Lyft 将双部署模式替换为先停后启部署模式。这导致常规部署产生 3 至 6 分钟停机时间，大型作业停机时间长达约 20 分钟。为此，Lyft 引入 FlinkBlueGreenDeployment 自定义资源定义（CRD），允许新旧版本在切换前并行运行。Lyft 团队在测试期间该功能仍在开发中，随后于 2026 年 2 月 15 日随 Operator 1.14.0 版本正式发布。团队遇到被追踪为 FLINK-38548 的配置重命名缺陷后，贡献了上游修复代码。Myneni、Kuyumcu 和 Udaya Shankar 指出，发现蓝绿部署缺陷后提交 Issue，几天内修复代码即被合并至上游。

为启用自动扩缩容，Lyft 将 Flink 升级至 1.19 版本。1.17 版本修改并行度需要重启作业，而最需要扩缩容的作业往往无法承受这种中断。Operator 文档指出，从 Flink 1.18 开始支持原地扩缩容。升级至 1.19 还解锁独立发布的 KinesisStreamsSource 组件，该组件于 2024 年 11 月随 flink-connector-aws 5.0.0 版本发布，要求 Flink 1.19 或更高版本。它像 Kafka Source 一样为 Kinesis 流提供记录积压指标，为自动扩缩容器提供此前在 Kinesis 绑定作业中缺失的信号。随后，自动调优回收 Beam Python 进程占用的 JVM 开销，导致 Beam 集群再次发生内存溢出，直至 Lyft 将该运行环境迁移到具有独立资源限制的专用 Sidecar 容器中才解决问题。

由于自动调优调整容器内存大小并需要重启 Pod，与原地自动扩缩容存在冲突。Lyft 按业务关键性对功能拆分：定价和路由作业使用不带自动调优的原地扩缩容，关键性较低工作负载允许通过重启调优资源。当基于重启的自动扩缩容触发 Pod 迁移时，自定义的最大分配调度器将高密度打包，使 Lyft 能够下线利用率不足的节点，同时由 Karpenter 按需配置 EC2 算力。

影响分析

这是基于技术迁移事实的分析判断。对于中文开发者与从业者而言，Lyft 的迁移路径提供了从自研 Kubernetes Operator 转向开源 Apache Flink Kubernetes Operator 的完整参考案例。首先，基于上次状态升级模式在 JobManager 不健康时仍能恢复，显著降低了升级失败风险，这对高可用流式计算场景具有直接借鉴价值。其次，原地自动扩缩容与自动调优的冲突处理方式，即按业务关键性拆分功能，为资源受限场景下的调度策略设计提供了可复用思路。最后，Beam Python 运行环境迁移至独立 Sidecar 容器的解决方案，解决了非 JVM 语言与 Java 任务管理器内存管理冲突的普遍问题，对混合语言流式计算架构设计具有参考价值。

适用边界

该结论在以下条件下不成立：若企业工作负载规模远小于数百个作业，或业务对 3 至 20 分钟停机时间高度敏感，直接采用先停后启模式将导致业务中断不可接受，必须引入蓝绿部署或更高级别零停机方案。对于未使用 Apache Beam Python 或非 JVM 运行环境的企业，Beam Sidecar 容器解决方案不适用，内存管理策略需根据实际运行环境重新设计。此外，基于重启的自动调优仅适用于关键性较低工作负载，高关键路径业务必须排除重启依赖，资源调优策略需按业务等级差异化配置。

孤本观察

Lyft 贡献的 FLINK-38548 修复代码在提交 Issue 后几天内被合并上游，表明开源社区对该 Operator 的响应速度足以支撑生产级迁移节奏。Spotify 从谷歌废弃 Operator 分支演进、将 Beam Python SDK 作为 Sidecar 容器并排运行的架构，与 Lyft 在经历自动调优导致内存溢出后最终采用的架构高度一致，这种跨公司技术路径收敛现象提示该架构模式可能正在成为行业标准实践。

来源：InfoQ 中文 AI