Lyft将数百个Flink任务迁至官方Kubernetes Operator

Lyft已将数百个生产环境Apache Flink Job从自研Kubernetes Operator迁移至官方Apache Flink Kubernetes Operator，主要原因是旧系统需要在每次Flink升级时维护，且自动扩缩容和回滚存在可靠性问题。迁移后，Lyft在集群范围内启用了基于上次状态（last-state）的升级、原地自动扩缩容和资源自动调优能力。

Lyft于2020年开发自研Operator，当时社区尚无专门面向Kubernetes运行Flink的控制平面。旧版采用双部署升级：启动新集群、创建保存点、取消旧Job并恢复；蓝绿模式则要求新旧集群并行运行，直到工程师手动切换流量。原保存点触发器缺少重试和幂等机制，大状态Job超时且没有可用检查点时，可能部署失败或无状态重启。非JVM内存还仅由systemMemoryFraction粗略控制，设置过低会导致TaskManager内存溢出，设置过高则造成浪费。

官方Operator将last-state恢复设为标准升级方式，即使JobManager异常，也能从高可用元数据或最新检查点恢复。为避免重写Jsonnet模板，Lyft在部署API边界层把旧版FlinkApplication转换为FlinkDeployment，完成jarName到jarURI、节点选择器到PodTemplateSpec的映射，并注入旧环境变量及默认升级策略。由于新模式优先启动JobManager，Lyft把双部署改为“先停后启”，普通部署会停机3至6分钟，大型Job最长约20分钟。

为降低停机影响，Lyft引入FlinkBlueGreenDeployment自定义资源。该功能在测试期间仍在开发，后于2026年2月15日随Operator 1.14.0发布，支持新旧版本切换前并行运行。针对配置重命名缺陷FLINK-38548，Lyft提交了上游修复代码并在数日内完成合并。

Lyft将Flink升级到1.19，以支持自动扩缩容。Flink 1.17调整并行度仍需重启Job，而1.18起支持原地扩缩容；1.19还支持独立发布的KinesisStreamsSource，该组件随flink-connector-aws 5.0.0于2024年11月推出，可提供Kinesis积压指标。自动调优曾回收Beam Python进程占用的JVM余量，导致集群再次OOM，最终通过把Beam运行环境迁移到拥有独立资源限制的Sidecar容器解决。

由于自动调优需要调整容器内存并重启Pod，无法与原地扩缩容同时使用，Lyft按业务重要性拆分策略：定价和路由Job采用不含自动调优的原地扩缩容，低优先级负载则允许重启调优。Pod迁移时，定制的most-allocated调度器会高密度打包任务，配合Karpenter按需配置EC2资源，从而下线低利用率节点。

Spotify的Operator也采用Beam Python SDK harness Sidecar方案；Amazon Managed Service for Apache Flink可托管检查点，但不支持Pod级Sidecar定制。Netflix同时运行自研和开源Flink Autoscaler，正逐步转向后者，其Job规模超过3万，远高于Lyft的数百个。Lyft下一步计划加快市场定价循环并处理自动驾驶遥测数据；团队称自动扩缩容已帮助一个过去每年因过度配置浪费数百万美元算力的集群合理缩容。