Muitos de nós fomos ensinados que, para manter a vizinhança do cluster em harmonia, precisamos colocar rédeas curtas em todo mundo. Então, por puro instinto de sobrevivência (ou trauma de alguma conta da AWS de cinco dígitos), enchemos o manifesto de limits: cpu: "200m".

Achamos que estamos sendo engenheiros prudentes, mas estamos criando uma armadilha perfeita.

A verdade é que a CPU é um recurso compressível. Ela não é como a memória RAM, que se estourar toma um OOMKill na cabeça e cai morta. Se o pod precisa de mais processamento e ele está disponível no nó, o kernel do Linux sabe fatiar esse tempo de forma inteligente.

O problema começa quando você define um CPU limit. Para fazer esse teto valer, o Kubernetes joga a responsabilidade para o mecanismo de CFS (Completely Fair Scheduler) do Linux. O CFS não liga se o seu nó está com 85% de folga; ele trabalha com janelas rígidas de tempo (geralmente de 100ms). Se o seu container é multithread ou precisa mastigar uma carga pesada e consome a cota milimétrica de milissegundos logo no início dessa janela, o CFS age como um leão: ele congela a sua aplicação pelo resto do período.

O resultado? Uma requisição que levaria 10ms passa a levar 100ms. O container sofre um CPU throttling violento. A latência (P99) explode, o cliente reclama e você passa a noite caçando assombração em loop de código ou culpando o banco de dados, enquanto a CPU real do nó está operando confortavelmente com 15% de uso. É a punição por um crime que a aplicação não cometeu.

A virtude não está em impor restrições arbitrárias para simular ordem, mas em compreender a natureza do kernel e agir de acordo com a razão. No ecossistema Kubernetes, o caminho da sabedoria e do desapego é simples: pare de usar CPU limits e confie nos mecanismos nativos de priorização. O verdadeiro escudo contra a ganância de um pod maluco não é o limite que o estrangula preventivamente, mas sim a reserva de mercado justa que garante a sobrevivência de todos quando o bicho pega.

Para virar essa chave sem quebrar o cluster, adote três pilares práticos:

1. Defina CPU Requests com precisão cirúrgica

É aqui que o jogo é ganho. O requests é o seu contrato de fidelidade com o nó. Ele garante que, mesmo se o cluster estiver pegando fogo, aquela fatia de processamento está blindada e reservada para o seu container. Não chute esse valor. Use ferramentas de observabilidade ou o próprio KRR (Kubernetes Resource Recommendations) da Robusta para olhar o histórico do Prometheus e calibrar esse peso com base no mundo real, não no achismo.

2. Olhe para as métricas certas (O veredito do Prometheus)

Se você não mede, você está pilotando às cegas. Antes e depois de remover os limites, configure seus dashboards para monitorar a métrica container_cpu_cfs_throttled_seconds_total. Se esse contador estiver subindo, sua aplicação está sendo amordaçada pelo Scheduler do Linux. Quando você limpa o limit, esse gráfico zera, e o seu P99 agradece.

3. Deixe a aplicação respirar (Bursting)

Sem o teto artificial do limits, seu pod ganha o direito de fazer bursting. Ele pode pegar a CPU ociosa do nó emprestada para engolir um pico repentino de requisições ou acelerar o startup da aplicação (um cenário onde runtimes como Java e Node.js sofrem muito com throttling) e voltar ao normal logo em seguida. Isso mantém a experiência do usuário lisa, sem cobrar um centavo a mais por isso na infraestrutura.

4. Mantenha os limites estritos apenas para Memória

Lembre-se sempre de separar o trigo do joio. Memória RAM é um recurso incompressível. Se faltar, o processo morre ou o nó capota para se defender. Para memória, manter o limits igual ou muito próximo ao requests continua sendo uma prática virtuosa (garantindo a classe de QoS Guaranteed) para evitar o efeito dominó de despejos e instabilidade generalizada no cluster.

Retirar os limites de CPU pode parecer, à primeira vista, um salto de fé no vazio. É um desapego que dá um frio na barriga de qualquer SRE que já teve que explicar um downtime para a diretoria. Mas a engenharia de verdade se apoia na realidade matemática do kernel, não no conforto psicológico de um arquivo YAML simétrico.

No fim do expediente, quando o cluster roda suave, a gente percebe que a simplicidade não é a ausência de controle, mas o controle exercido com inteligência. Pague a sua rodada, respire fundo e apague aquela linha de limits.cpu do seu Helm chart amanhã cedo. Sua saúde mental agradece.