Lyft将流式计算集群迁移到Apache Flink Kubernetes Operator

Lyft淘汰了其内部开发的Flink operator，其原因包括每次Flink升级都需要进行维护，以及自动伸缩和回滚方面存在的缺陷。 Lyft已经将数百个生产环境的 Apache Flink " Job从自研的 Kubernetes operator "迁移到了 Apache Flink Kubernetes Operator "。在最近发布的 Lyft Engineering文章 "中，流计算工程师 Maheep Myneni "、 Arda Kuyumcu "与Prem Santosh Udaya Shankar表示，此次迁移在集群范围内解锁了基于上次状态（last-state）进行升级、原地自动伸缩与资源自动调优功能。 Lyft在2020年构建了自研的Operator，当时开源社区还没有为在Kubernetes上运行的Flink构建专用的控制平面。双部署（dual-deployment）升级会启动第二个集群、创建保存点（Savepoint）、取消旧Job并从该保存点恢复。遗留Operator的BlueGreen模式会在工程师手动切换流量之前保持两个集群同时运行。 原有的保存点触发器既没有重试逻辑，也不具备幂等性。对于较大状态的Job，如果发生超时且没有可用的最近检查点（Checkpoint），就会导致部署失败，或者使Job在完全没有状态的情况下重启。此外，非JVM内存的预留仅由一个systemMemoryFraction参数来控制，这本质上是对 Apache Beam " Python运行环境所需额外开销的一种粗略估计。如果该值设置过低，TaskManager就会因内存溢出（OOM）被系统杀掉，如果设置过高，整个集群又会白白浪费内存。 Apache Flink Operator将基于 上次状态（last-state） "恢复作为第一等的升级模式，即使JobManager处于不健康状态，也能从高可用的元数据或最新的检查点进行恢复。为了避免重写Jsonnet模板，Lyft的部署API在边界层将遗留的FlinkApplication规格自动转换成了FlinkDeployment资源。这一转换层将jarName映射为jarURI，将节点选择器提取并转换为PodTemplateSpec对象，注入了遗留的环境变量，并将升级策略默认设为从上次状态恢复。 Apache Operator会优先启动JobManager，以便管理TaskManager的生命周期。在弃用旧版Operator的同时，Lyft也将“双部署（dual deployments）”模式替换为了“先停后启（stop-then-start）”的部署模式。这导致常规部署会产生3到6分钟的停机时间，而大型Job的停机时间则长达约20分钟。为此，Lyft引入了 FlinkBlueGreenDeployment（一种自定义资源定义，CRD）。在Lyft开始测试时该功能仍在开发中，随后于2026年2月15日随Operator 1.14.0版本正式发布。它允许新旧版本在切换前并行运行。在遇到了一个被追踪为 FLINK-38548 "的配置重命名缺陷后，Lyft贡献了 上游修复代码 "。Myneni、Kuyumcu和Udaya Shankar这样写到：“当我们发现这个蓝绿部署的缺陷时，我们提交了Issue，几天内修复代码就被合并到了上游。” 为了实现自动扩缩容，Lyft将Flink升级到了1.19版本。在1.17版本中，修改并行度需要重启Job，而那些最需要扩缩容的Job往往无法承受这种中断。Operator的文档指出，从Flink 1.18开始支持原地扩缩容。升级到1.19版本还解锁了独立发布的KinesisStreamsSource（该组件于2024年11月随flink-connector-aws 5.0.0版本发布，并且要求Flink 1.19或更高版本）。它像Kafka Source一样为Kinesis流提供记录积压（backlog）指标，从而为自动扩缩容器提供了此前在Kinesis绑定Job中缺失的信号。随后，自动调优（Autotuning）回收了Beam Python进程仍在占用的JVM开销，但这导致Beam集群会再次发生OOM，直到Lyft将该运行环境迁移到具有独立资源限制的专用Sidecar容器中才解决了问题。 由于自动调优会调整容器内存大小并需要重启Pod，它与原地自动扩缩容存在冲突。Lyft按业务关键性对功能进行了拆分：定价和路由Job使用不带自动调优的原地扩缩容，而关键性较低的工作负载则允许通过重启来调优资源。当基于重启的自动扩缩容触发Pod迁移时，一个自定义的最大分配调度器（most-allocated scheduler）会将它们高密度地打包，这使得Lyft能够下线利用率不足的节点，同时由 Karpenter "按需配置EC2算力。 Spotify的Flink Operator "是从谷歌现已废弃的Operator分支而来，它的文档同样记录了将Beam Python SDK harness作为Sidecar容器与Flink TaskManager并排运行的做法，这与Lyft在经历自动调优导致的OOM后最终所采用的架构不谋而合。 Amazon Managed Service for Apache Flink "能够托管检查点并免除Operator的维护工作，但它缺乏Pod级别的Sidecar自定义能力。 相比之下， Netflix目前同时运行着其内部自研的Flink Autoscaler和开源版本 "，并正在逐步向后者收敛，而不是采用Kubernetes Operator。Netflix运行着超过30000个Flink Job，而Lyft只有数百个。Lyft的流计算团队接下来希望实现更快的市场定价循环以及自动驾驶车辆的遥测数据处理。Myneni、Kuyumcu和Udaya Shankar这样写到：“自动扩缩容器正如我们所期望的那样运作，它对一个此前每年被过度配置了数百万美元算力的集群进行了合理的规模调整。” 查看英文原文： Lyft Moves Streaming Fleet to Apache Flink Kubernetes Operator "