OpenAI dez/2024: serviço de telemetria derruba o plano de controle do Kubernetes e o DNS

01 · CONTEXTO

Centenas de clusters e duas camadas com papéis diferentes

Em 11 de dezembro de 2024, todos os serviços da OpenAI ficaram fora do ar ou muito degradados. A causa foi uma mudança interna para implantar telemetria nova na frota: o serviço de coleta sobrecarregou o plano de controle do Kubernetes e, com ele, a descoberta de serviços. Não houve incidente de segurança. O post-mortem público da própria empresa é a fonte deste caso.

A OpenAI opera centenas de clusters Kubernetes no mundo. Cada cluster tem duas camadas: o plano de controle, que administra o cluster, e o plano de dados, onde as cargas, como a inferência de modelos, de fato rodam. O plano de dados opera quase sem o de controle, o que dá uma sensação de isolamento, mas há exceções.

02 · O GATILHO

Um agente de observabilidade que cobrou caro de cada nó

Como parte de um esforço para melhorar a observabilidade da frota, a equipe implantou um serviço para coletar métricas detalhadas do plano de controle. Serviços de telemetria têm pegada ampla, e a configuração desse fez cada nó de cada cluster executar operações caras na API do Kubernetes, com custo que cresce com o tamanho do cluster.

Com milhares de nós fazendo isso ao mesmo tempo, os servidores de API ficaram sobrecarregados e o plano de controle caiu na maioria dos clusters grandes. A ironia é que a ferramenta de observabilidade criada para dar mais visibilidade foi a que derrubou o que ela observava.

1. No estado normal, os serviços resolvem nomes pelo DNS do cluster, que por trás consulta o servidor de API.

2. O novo serviço de telemetria entra em cada nó do cluster.

3. Cada nó passa a fazer operações caras no servidor de API, e o custo cresce com o tamanho do cluster.

4. Sob essa carga, o servidor de API deixa de responder e o plano de controle cai.

5. O DNS depende do plano de controle, então a descoberta de serviços quebra e os serviços não conseguem se localizar.

03 · POR QUE NÃO FOI PEGO

Teste que passou e cache que atrasou o sintoma

A mudança foi testada em um cluster de staging e nada apareceu. O efeito dependia do tamanho do cluster, e o problema foi mais forte nos maiores. Antes do deploy, a preocupação principal era o consumo de CPU e memória do novo serviço, e a carga no servidor de API não foi avaliada. O rollout acompanhava a saúde dos serviços, mas não a saúde dos clusters.

Havia ainda um atraso embutido: o cache de DNS em cada nó entregava registros antigos, porém funcionais. Eles foram expirando ao longo de uns 20 minutos, e só então os serviços começaram a falhar. Esse intervalo deixou o rollout seguir adiante antes de o problema aparecer inteiro: a mudança foi aplicada a todos os clusters em menos de meia hora.

Quando os caches esvaziaram, a carga sobre os servidores de DNS se multiplicou e somou mais pressão ao plano de controle, o que dificultou ainda mais a mitigação.

04 · TRAVADO FORA

A correção exigia o sistema que estava quebrado

O reverter normalmente é simples, e aqui a detecção funcionou: os alertas dispararam antes de os clientes sentirem impacto. O problema é que a correção era remover o serviço de telemetria, e fazer isso exigia acessar o plano de controle, justamente o que a carga nos servidores de API impedia. A própria empresa aponta o efeito de bloqueio como motivo da lentidão.

1. O pipeline aplica a mudança de configuração, que passa pelo servidor de API de cada cluster.

2. Os alertas funcionam e chamam a engenharia antes de o impacto chegar aos clientes.

3. Para remover o serviço, a equipe precisa passar pelo servidor de API, que está sobrecarregado e não atende.

4. Enquanto isso, o tráfego é desviado para clusters que ainda funcionam.

Três frentes foram abertas em paralelo: reduzir o tamanho dos clusters para diminuir a carga agregada na API, bloquear o acesso de rede às APIs de administração para impedir novas requisições caras e dar tempo aos servidores de se recuperar, e aumentar os servidores de API para absorver as requisições pendentes. Juntas, devolveram controle suficiente para remover o serviço.

A recuperação ainda teve um efeito colateral: alguns clusters seguiram degradados porque muitos serviços tentaram baixar recursos ao mesmo tempo, saturando limites e exigindo intervenção manual. Os clusters voltaram aos poucos, e o impacto durou de 3:16 PM até 7:38 PM no horário do Pacífico.

05 · O QUE O DESENHO PRECISA PROVAR

Rollout em ondas, plano de dados autônomo e acesso de emergência

A OpenAI listou medidas que atacam cada elo da cadeia. A primeira é tornar todo rollout de configuração de infraestrutura uma implantação em fases robusta, com monitoramento contínuo tanto dos serviços quanto dos clusters, plano de controle incluído.

As demais tratam do isolamento e da recuperação. Elas incluem testes de injeção de falhas para que o plano de dados sobreviva mais tempo sem o de controle, mecanismos de emergência para acessar a API em qualquer circunstância, e desacoplar de vez os dois planos para que o de controle não seja essencial às cargas críticas. Para recuperar mais rápido, a empresa prevê caches melhores, limitadores de taxa dinâmicos e exercícios regulares de substituir um cluster inteiro.

1. A mudança vai primeiro a um cluster canário grande, que se comporta como os maiores da frota.

2. A saúde do cluster e do plano de controle é medida, não só a dos serviços, e por tempo maior que o cache de DNS.

3. Sem sinal saudável, o pipeline trava a próxima onda e a mudança não sai do canário.

4. Com sinal saudável, a mudança avança onda a onda para o restante da frota.

5. Se o plano de controle travar mesmo assim, o acesso de emergência ainda permite remover a mudança.