Swap no Kubernetes: densidade maior só vale se a latência continuar aceitável

O blog do Kubernetes publicou benchmarks de swap em SSD local NVMe para cargas com picos de memória e períodos ociosos, com resultado máximo de três vezes mais sandboxes Python por nó.[9] O suporte chegou à disponibilidade geral no Kubernetes 1.34 e o desenho usa cgroup v2 para contabilizar swap separadamente.[9] A oportunidade não é trocar toda a RAM por disco, mas avaliar quanto custa manter estado inativo residente.

O que muda para quem desenvolve

No cenário Python, sessões isoladas processando dados do MovieLens passaram de 80 para 240 sandboxes simultâneas; segundo os autores, na densidade máxima a elevação de latência veio principalmente da competição por CPU.[9] A densidade, portanto, não deve ser a única variável de aceite de um serviço.

Os testes com Chromium também variaram conforme o isolamento: gVisor passou de 80 para 160 pods, enquanto Kata Containers passou de 40 para 50 microVMs antes de saturar CPU.[9] Não trate esses ambientes como opções intercambiáveis só porque seus números cabem na mesma tabela.

Minha recomendação é modelar o ciclo de vida da carga. Quanto tempo uma sessão trabalha, quanto tempo espera e quanto estado precisa conservar? Se a hipótese for memória ociosa como gargalo, um experimento com swap faz sentido. Se o conjunto ativo já pressionar CPU ou disco, aumentar a concorrência pode apenas deslocar o problema.

Como aplicar

Reproduza uma carga representativa em homologação, mantendo o mesmo runtime de isolamento, as mesmas entradas e o mesmo perfil de atividade. Compare execução sem swap e com swap em SSD local. Meça sessões concluídas, OOM, CPU, I/O, tempo de retomada e latência de cauda.

A configuração descrita inclui failSwapOn: false e memorySwap.swapBehavior: LimitedSwap no kubelet.[9] O artigo orienta workloads Burstable, com limites de memória acima das requisições, além do disco local rápido.[9] Confira os requisitos do seu ambiente antes de reproduzir a configuração; não copie dois campos para produção sem validar a política do cluster.

Aumente a concorrência por etapas e interrompa o teste quando a latência ou a taxa de conclusão violar a meta definida antes do experimento. Inclua uma fase de retomada simultânea de sessões, não apenas o período em que elas ficam paradas. Compare o custo do SSD e da operação com a alternativa de mais RAM ou menos sessões por nó.

Reserve uma avaliação para dados sensíveis que possam ser paginados, proteção do armazenamento e comportamento durante substituição do nó. Esses itens devem entrar no desenho do teste, não ser descobertos após a adoção.

Cuidados e limites

Na compilação de kernel apresentada, 300 MB de limite de RAM com swap produziram um resultado favorável, mas a redução para 200 MB aumentou o tempo em mais de 40%.[9] O limite do conjunto ativo importa mais que a ideia abstrata de “ter swap”.

Os números publicados são condições específicas dos benchmarks, não uma previsão universal para aplicações JVM, navegadores ou agentes.[9] Use-os para formular uma hipótese. Aprovação operacional exige demonstrar que a carga mantém seu tempo de resposta, seu isolamento e sua confiabilidade com o custo total proposto.

Fonte

[9] Fonte: Kubernetes Blog