Lyft retira su operador propio de Flink y migra cientos de jobs al de Apache
La compañía abandona el operador que construyó en 2020 tras años de mantenimiento manual en cada actualización de Flink, y gana actualizaciones con estado, autoscaling in-place y ajuste de recursos.
Lyft ha retirado el operador de Flink que construyó en 2020 y ha trasladado cientos de jobs de streaming en producción al Apache Flink Kubernetes Operator. Lo cuenta su equipo de streaming en un post del 31 de agosto: el operador propio exigía mantenimiento en cada actualización de Flink y no cubría ni el autoscaling ni los rollbacks.
El problema estaba en cómo se desplegaba. Las actualizaciones duales levantaban un segundo clúster, tomaban un savepoint, cancelaban el job viejo y restauraban desde ahí. El modo BlueGreen del operador antiguo mantenía los dos clústeres vivos hasta que alguien cambiaba el tráfico a mano. El disparo del savepoint no tenía reintentos ni idempotencia: un timeout en un job con mucho estado podía tumbar el despliegue o reiniciar el job sin estado si no había un checkpoint reciente. Y la reserva de memoria no-JVM dependía de un único parámetro, systemMemoryFraction, que era una apuesta sobre el overhead que necesitaban los harness de Python de Apache Beam. Si se quedaba corto, el TaskManager moría por OOM; si se pasaba, la flota malgastaba memoria.
Traducción en la frontera
En lugar de reescribir las plantillas Jsonnet, la API de despliegue de Lyft tradujo las especificaciones FlinkApplication heredadas a recursos FlinkDeployment en el límite: jarName pasó a jarURI, los node selectors se elevaron a objetos PodTemplateSpec, se inyectaron las variables de entorno antiguas y las actualizaciones se dejaron en last-state por defecto. El operador de Apache arranca primero los JobManagers para gestionar el ciclo de vida de los TaskManagers, y trata last-state como modo de actualización de primera clase: restaura desde los metadatos de alta disponibilidad o desde el último checkpoint aunque el JobManager esté inservible.
El precio fue el corte. Al dejar atrás los despliegues duales, las actualizaciones pasaron a ser parar y arrancar: entre 3 y 6 minutos de caída en un despliegue típico y unos 20 minutos en los jobs más grandes. Para eso adoptaron FlinkBlueGreenDeployment, un CRD que todavía estaba en desarrollo cuando empezaron a probarlo y que llegó con el operador 1.14.0, el 15 de febrero de 2026. Por el camino se toparon con un bug de renombrado de configuración, el FLINK-38548, y subieron el arreglo a upstream. Los ingenieros Maheep Myneni, Arda Kuyumcu y Prem Santosh Udaya Shankar lo resumen así: "Cuando vimos el bug de BlueGreen, abrimos una incidencia y el arreglo llegó a upstream en días".
También subieron a Flink 1.19 para autoscalar. La 1.17 obligaba a reiniciar para cambiar el paralelismo, algo que los jobs que más necesitaban escalar no podían permitirse, y el operador documenta el escalado in-place desde la 1.18. La 1.19 desbloqueó además KinesisStreamsSource, disponible en flink-connector-aws 5.0.0 desde noviembre de 2024 y que emite métricas de backlog igual que la fuente de Kafka. El autotuning, en cambio, choca con el escalado in-place porque redimensiona la memoria del contenedor y exige reiniciar el pod. Lyft separó por criticidad: pricing y routing escalan sin autotuning, mientras las cargas menos críticas aceptan reinicios. Con el autoscaling basado en reinicios, un scheduler propio empaqueta los pods y Karpenter aprovisiona capacidad en EC2.
No es el único camino. Netflix corre más de 30.000 jobs de Flink y mantiene a la vez su autoscaler interno y el open source, convergiendo hacia el segundo en lugar de adoptar el operador de Kubernetes; Spotify usa un fork del de Google, ya deprecado; y Amazon Managed Service for Apache Flink se lleva el mantenimiento pero no permite personalizar sidecars a nivel de pod. En Lyft, el equipo sostiene que "el autoscaler está haciendo lo que esperábamos: dimensionar bien una flota que estaba sobredimensionada en unos pocos millones de dólares al año".
