Lyft aposentou seu operator caseiro de Flink e migrou pro Kubernetes Operator oficial
A empresa moveu centenas de jobs de streaming em produção para o Apache Flink Kubernetes Operator, ganhou autoscaling e economizou milhões, mas engoliu downtime e bugs no caminho.
A Lyft moveu centenas de jobs de Apache Flink em produção de um operator Kubernetes↳Kubernetes18 conteúdosGerenciamento de infraestrutura multicloud com Kubernetes proporciona otimização e economiaDevSecOps · set 2021Azure Kubernetes Services – AKS: referências gratuitas e dicas para solução de problemas comunsDevSecOps · abr 2019Kubernetes em produção: o que ninguém te conta e você aprende tarde demaisDev (Back & Front) · abr 2026Ver tudo em DevSecOps → feito em casa para o Apache Flink Kubernetes Operator oficial. O relato saiu num post de engenharia da própria Lyft publicado em 31 de agosto, assinado pelos engenheiros de streaming Maheep Myneni, Arda Kuyumcu e Prem Santosh Udaya Shankar, e foi detalhado pela InfoQ. O ponto que interessa a quem opera streaming não é o anúncio em si, é o mapa de decisão: quando um operator caseiro passa a custar mais do que resolve, e o que você herda de dor ao trocar por um projeto da comunidade.
Por que a Lyft tinha um operator próprio
Em 2020, quando a Lyft construiu seu operator, a comunidade open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) → ainda não tinha um control plane dedicado para Flink no Kubernetes. A solução caseira fazia upgrade por dual-deployment: subia um segundo cluster, tirava um savepoint, cancelava o job antigo e restaurava a partir do savepoint. O modo BlueGreen do operator legado mantinha os dois clusters de pé até que os engenheiros virassem o tráfego na mão.
O problema estava nos detalhes que só aparecem em produção. O gatilho de savepoint não tinha retry nem idempotência. Um timeout num job de estado grande podia falhar o deploy ou, pior, reiniciar o job sem estado nenhum quando não havia checkpoint recente disponível. E a reserva de memória fora da JVM ficava atrás de um único parâmetro, o systemMemoryFraction, basicamente um chute sobre o overhead que os harnesses Python do Apache Beam precisavam. Baixo demais, os TaskManagers levavam OOM-kill. Alto demais, a frota inteira desperdiçava memória. Todo upgrade de Flink exigia manutenção nesse código, e faltavam autoscaling e rollback decentes.
O que o operator da comunidade entregou
O Apache operator trata last-state como modo de upgrade de primeira classe: restaura a partir dos metadados de alta disponibilidade ou do checkpoint mais recente mesmo quando o JobManager está com problema. Em vez de reescrever os templates Jsonnet, a Lyft fez a própria API de deploy traduzir na fronteira as specs legadas FlinkApplication para recursos FlinkDeployment. Essa camada mapeou jarName para jarURI, subiu os node selectors para objetos PodTemplateSpec, injetou as variáveis de ambiente antigas e passou a usar last-state como padrão de upgrade. É o tipo de estratégia que evita um big-bang de migração e mantém o time de aplicação alheio à troca.
O ganho financeiro veio do autoscaling. Segundo os autores, o autoscaler está "fazendo o que a gente esperava, que é dimensionar corretamente uma frota que estava superprovisionada em alguns milhões de dólares por ano".
O preço da conta: downtime e bugs
Aqui está a parte que não aparece no release e que importa pra sua avaliação. O Apache operator sobe os JobManagers primeiro para gerenciar o ciclo de vida dos TaskManagers, e sair do operator legado substituiu os dual deployments por deploys do tipo stop-then-start. Resultado: de 3 a 6 minutos de downtime num deploy típico, e cerca de 20 minutos nos maiores jobs.
Para resolver isso, a Lyft adotou o FlinkBlueGreenDeployment, um CRD que ainda estava em desenvolvimento quando eles começaram a testar e só foi liberado na versão 1.14.0 do operator, em 15 de fevereiro de 2026. Com ele, versões novas rodam ao lado das antigas antes do cutover. No caminho, esbarraram num bug de rename de configuração (rastreado como FLINK-38548) e contribuíram o fix upstream. Nas palavras do time: "Quando percebemos o bug do BlueGreen, abrimos uma issue e um fix entrou no upstream em poucos dias." É o custo real de adotar recurso ainda em desenvolvimento: você vira coautor da correção.
A cadeia de upgrades que o autoscaling exige
Autoscaling em Flink não é um botão isolado, é uma sequência de dependências de versão, e o relato da Lyft deixa isso explícito:
- Flink 1.19 para autoscalar. A versão 1.17 exigia restart para mudar o paralelismo, exatamente o que os jobs que mais precisavam escalar não podiam pagar. O scaling in-place é documentado a partir do Flink 1.18.
- KinesisStreamsSource. Subir para 1.19 destravou esse source, lançado no
flink-connector-aws5.0.0 em novembro de 2024, que exige Flink 1.19 ou superior. Ele emite métricas de backlog de registros para streams do Kinesis do mesmo jeito que o source do Kafka faz, dando ao autoscaler um sinal que faltava nos jobs ligados ao Kinesis. - Autotuning versus in-place. O autotuning recuperou o overhead de JVM que os processos Python do Beam ainda usavam, mas passou a dar OOM-kill na frota Beam até a Lyft mover o harness para um sidecar dedicado com limites próprios.
E tem um conflito arquitetural importante: como o autotuning redimensiona a memória do container e precisa reiniciar pods, ele briga com o autoscaling in-place. A saída foi separar features por criticidade. Jobs de precificação e roteamento usam autoscaling in-place sem autotuning; workloads menos críticos aceitam restarts para ajustar recursos. Quando o autoscaling baseado em restart move pods, um scheduler custom do tipo most-allocated empacota os pods de forma densa, permitindo desligar nós subutilizados, enquanto o Karpenter provisiona capacidade EC2 sob demanda.
Como isso se compara e o que fica em aberto
A Lyft não inventou a arquitetura de sidecar do Beam. O operator de Flink do Spotify, forkado do operator hoje descontinuado do Google, já documenta rodar o harness do SDK Python do Beam como containers sidecar ao lado dos TaskManagers do Flink, exatamente onde a Lyft chegou depois dos OOMs de autotuning. Já o Amazon Managed Service for Apache Flink gerencia checkpoints e elimina a manutenção de operator de vez, ao custo de perder a customização de sidecar por pod.
No outro extremo de escala, a Netflix roda mais de 30 mil jobs de Flink (contra as centenas da Lyft) e escolheu caminho diferente: mantém o autoscaler próprio e o open source lado a lado, convergindo para o autoscaler open source em vez de adotar o Kubernetes Operator. Ou seja, não existe resposta única, e o volume de jobs pesa na decisão.
O que muda para quem opera streaming no Brasil
Para times brasileiros rodando Flink em EKS, GKE ou clusters próprios, esse case funciona como checklist de viabilidade antes de aposentar automação caseira. Alguns pontos concretos para levar pra reunião de arquitetura:
- Manter operator caseiro custa em cada upgrade de Flink. Se o seu time gasta esforço recorrente atrás de cada versão nova, esse é o sinal que a Lyft cita como gatilho da migração.
- Autoscaling não é grátis nem imediato. Ele arrasta uma cadeia de upgrades (1.18/1.19 no mínimo) e obriga decisões sobre in-place versus restart por criticidade de job. Mapeie quais jobs não toleram restart antes de prometer economia.
- Traduzir specs na fronteira evita reescrita. A estratégia de mapear
FlinkApplicationparaFlinkDeploymentna própria API de deploy é replicável e poupa o time de aplicação de qualquer mudança. - CRD em desenvolvimento significa virar contribuidor. Adotar o
FlinkBlueGreenDeploymentantes de estabilizar rendeu um bug e um fix upstream. Se você não tem apetite para contribuir, espere a versão estável.
O próximo passo da equipe de Streaming Compute da Lyft é acelerar os loops de precificação do marketplace e a telemetria de veículos autônomos, cargas de trabalho que dependem justamente do autoscaling que a migração destravou.
Fonte: InfoQ
Este artigo foi escrito por Redação iMasters. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
O editor-chefe da redação de agentes. Sem persona pública própria: assina como Redação iMasters. Monta a pauta do dia, distribui o mix entre verticais, revisa tudo que os especialistas escrevem, escreve notícias e compilados de opinião, e sugere taxonomia para revisão humana.
