OpenAI (2024): como um novo serviço de telemetria derrubou o control plane do Kubernetes

No dia 11 de dezembro de 2024, a equipe de infraestrutura da OpenAI iniciou o rollout de um novo serviço de coleta de telemetria. A intenção era legítima e comum: melhorar a observabilidade interna da frota Kubernetes, que sustenta toda a infraestrutura de inferência do ChatGPT, da API pública e do Sora. O agente foi empacotado como um DaemonSet, o mecanismo padrão do Kubernetes para rodar um pod em cada nó da frota, e a implantação foi disparada de forma ampla, atingindo um número muito grande de nós simultaneamente.

O problema não estava no código do agente em si. Estava no comportamento emergente de milhares de instâncias desse agente inicializando ao mesmo tempo e, ao fazê-lo, cada uma delas estabelecendo conexões persistentes com os API servers do Kubernetes para observar o estado do cluster, o padrão watch da API do Kubernetes. Em uma frota de escala de produção da OpenAI, isso significa que centenas ou milhares de conexões watch foram abertas em uma janela de tempo muito curta. Os API servers, que são o ponto central de controle de todo o cluster, começaram a ser saturados.

O que torna esse incidente particularmente instrutivo é o papel do cache de DNS. Durante os primeiros minutos após o início do rollout, o impacto não foi imediatamente visível nos indicadores de saúde dos serviços de usuário final. O DNS interno do cluster ainda estava resolvendo endereços a partir de entradas em cache, o que significa que o tráfego de aplicação continuou fluindo normalmente por um período. Isso criou uma janela de falsa segurança, os alertas de latência e erro dos serviços de produto não dispararam imediatamente, o que atrasou o reconhecimento de que algo estava fundamentalmente errado na camada de infraestrutura.

Quando os caches de DNS começaram a expirar e as novas resoluções precisaram passar pelos mecanismos de descoberta de serviço do Kubernetes (que dependem dos API servers já saturados), o impacto cascateou rapidamente para o plano de dados. Pods não conseguiam ser agendados, serviços não conseguiam ser descobertos, e o tráfego de usuário começou a falhar em escala global.

Um dos aspectos mais tecnicamente interessantes desse incidente é o papel do cache de DNS interno do cluster, e como ele transformou um problema detectável em um problema que se revelou tarde demais para uma resposta rápida.

Em um cluster Kubernetes, a resolução de nomes de serviço é feita pelo CoreDNS (ou equivalente). Quando um pod precisa se comunicar com outro serviço, ele resolve o nome DNS do serviço, que aponta para o ClusterIP correspondente. Essas resoluções são cacheadas localmente nos pods e nos resolvers intermediários com um TTL definido, tipicamente entre 5 e 30 segundos para DNS de cluster, mas a implementação real depende de como o ndots, search e os TTLs do CoreDNS estão configurados.

No momento em que o DaemonSet de telemetria começou a saturar os API servers, o tráfego de aplicação entre os serviços de produto (ChatGPT, API, Sora) continuou funcionando normalmente porque as resoluções DNS já estavam em cache. Os pods não precisavam consultar o CoreDNS para cada requisição, eles já tinham os endereços IP resolvidos. Isso criou uma janela de tempo, estimada em 15 a 20 minutos com base na progressão do incidente, durante a qual o control plane estava degradando severamente, mas os SLIs de produto (taxa de erro, latência) permaneciam dentro dos limites normais.

Essa janela de falsa normalidade é uma armadilha clássica em sistemas distribuídos: a camada de caching absorve o impacto inicial e mascara a degradação da camada subjacente. Quando os caches expiraram e as novas resoluções precisaram passar pelo CoreDNS, que por sua vez depende dos endpoints do Kubernetes atualizados pelos API servers saturados, o impacto se tornou imediato e total. Não houve degradação gradual visível para os usuários finais: foi uma transição abrupta de "tudo funcionando" para "nada funcionando".

Isso tem implicações diretas para o design de alertas: monitorar apenas SLIs de produto não é suficiente quando existe uma camada de caching entre o usuário e a infraestrutura. É necessário monitorar a saúde do control plane de forma independente, com alertas que disparem muito antes de o cache expirar, não depois.

A fase de remediação desse incidente expõe uma das propriedades mais perigosas de falhas no control plane do Kubernetes: o sistema que você usa para corrigir o problema é o mesmo sistema que está quebrado.

Quando a equipe identificou o DaemonSet de telemetria como a causa e tentou executar o rollback, seja via kubectl rollout undo, via um operador de GitOps como ArgoCD ou Flux, ou via chamadas diretas à API, todas essas operações precisam que os API servers do Kubernetes aceitem e processem requisições de escrita. Um API server saturado por milhares de conexões watch ativas não tem capacidade de processamento disponível para aceitar novos comandos de controle de forma confiável. As requisições de rollback eram enfileiradas, atingiam timeouts ou falhavam completamente.

Isso não é um bug do Kubernetes, é uma consequência arquitetural esperada de um design centralizado de control plane. O etcd, que persiste o estado do cluster, também estava sob pressão de leitura elevada devido ao volume de watch connections, o que degradou ainda mais a capacidade dos API servers de processar qualquer coisa.

A recuperação só foi possível de forma gradual: à medida que alguns nós conseguiam processar o rollback do DaemonSet (reduzindo o número de conexões watch ativas), a pressão sobre os API servers diminuía incrementalmente, liberando capacidade para processar mais operações de rollback. Foi um processo de recuperação auto-limitante, cada rollback bem-sucedido habilitava o próximo, mas o progresso era lento porque cada operação competia com as conexões watch remanescentes.

A lição operacional aqui é que qualquer plano de resposta a incidentes para um ambiente Kubernetes de larga escala precisa incluir mecanismos de remediação que não dependam exclusivamente dos API servers. Isso pode incluir: acesso direto aos nós via SSH ou SSM para remover manualmente pods do DaemonSet; scripts de emergência que operam fora do ciclo normal de reconciliação do Kubernetes; ou, em casos extremos, procedimentos de cordon e drain que podem ser executados com conectividade parcial ao control plane. Nenhum desses mecanismos substitui a prevenção, mas a ausência de um plano de remediação alternativo transforma um incidente grave em um incidente catastrófico.