Configurações críticas que causaram falhas de OOM no Spark no Kubernetes

Ao migrar pipelines Spark para Azure Kubernetes Service, duas configurações de infraestrutura interagiram de forma destrutiva. A primeira foi ativar o spark.kubernetes.local.dirs.tmpfs=true, que faz com que o shuffle spill use RAM ao invés de disco, aumentando o risco de consumo excessivo de memória. A segunda foi uma regra rígida de podAffinity que forçou todos os executores a rodarem no mesmo nó, agravando ainda mais o uso de memória.

O resultado foi uma série de kills de OOM que não eram detectados pelos diagnósticos tradicionais, deixando a equipe sem pistas claras do problema. Na prática, essas configurações parecem inofensivas, mas juntas, criaram um efeito cascata que impactou a estabilidade.

No meu entendimento, é fundamental validar o impacto de configurações que parecem isoladas. Quando lidamos com clusters compartilhados ou com cargas pesadas, um ajuste errado pode passar despercebido até causar uma falha grave. Revisar as configurações de memória e alocação, além de fazer testes controlados, ajuda a evitar esses transtornos.

Quem já passou por algo parecido? Como vocês costumam monitorar essas interações de configuração?

Acho que a dica é sempre evitar mudanças isoladas na infraestrutura sem testar o impacto em cenários reais. A estabilidade passa por controle e validação contínuos. Por isso, o recorte precisa considerar manutenção, validação e caminho de volta. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar. A decisão fica mais saudável quando o time consegue medir o impacto depois. Sem esse critério, a solução pode parecer simples no começo e cara no suporte. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco.