CPU alta no Docker? Como limitar recursos com cgroups

O desafio invisível da disputa por recursos no Docker

Quando rodamos múltiplos containers em um mesmo servidor, é comum que a infraestrutura sofra com a lei da selva digital: a aplicação que consome mais CPU acaba sufocando as demais. Em ambientes multi-tenant, onde diferentes serviços ou clientes dividem o mesmo hardware, essa falta de governança pode derrubar sistemas inteiros da noite para o dia. Na prática, isso significa que um único processo mal otimizado pode monopolizar os núcleos do processador, gerando lentidão generalizada e queda de disponibilidade. Para entender a gravidade do problema, vale lembrar que, assim como discutimos em nossa análise sobre por que o Kubernetes deixa pods presos no CrashLoopBackOff, a falta de limites claros de recursos é a raiz de grande parte das falhas em infraestruturas modernas baseadas em containers.

O que são os cgroups e como o kernel Linux gerencia o silício

Por baixo do capô, o Docker não inventou a roda da virtualização; ele apenas empacota tecnologias nativas do sistema operacional Linux, sendo os cgroups (control groups) o mecanismo central de controle. Um cgroup é um recurso do kernel que restringe, contabiliza e isola o uso de recursos físicos — como CPU, memória e I/O de disco — para um conjunto de processos. Quando você inicia um container, o Docker instrui o kernel a colocá-lo dentro de uma árvore isolada de cgroups. Na prática, isso cria uma cerca invisível ao redor do processo, impedindo que ele ultrapasse a fatia de hardware que lhe foi alocada, garantindo que o sistema operacional continue respirando mesmo sob estresse severo.

Limitando a força bruta: como funcionam CPU shares e períodos

Para controlar o apetite dos containers pela CPU, o Docker oferece duas abordagens principais: a prioridade relativa e o limite rígido de tempo de processamento. As chamadas CPU shares definem o peso de cada container quando há disputa por ciclos de processamento livre; se o container A tem peso 1024 e o B tem peso 512, o primeiro receberá o dobro de tempo de CPU caso o servidor atinja 100% de uso. Por outro lado, parâmetros como cpu-period e cpu-quota permitem impor um teto absoluto. Configurar esses limites é tão essencial quanto otimizar seus processos de build, tema que abordamos detalhadamente ao explicar como otimizar builds com cache e Docker em ambientes de integração contínua.

Colocando a mão na massa: configurando limites no Docker Compose

A melhor forma de aplicar essa governança na prática é através dos arquivos de configuração do Docker Compose, onde podemos declarar os limites de forma clara e versionável. Abaixo, veja um exemplo prático de como restringir o uso de CPU para um serviço web pesado, garantindo que ele utilize no máximo o equivalente a um núcleo completo e mantenha uma prioridade controlada.

version: '3.8'services:  api-backend:    image: my-company/api:latest    deploy:      resources:        limits:            cpus: '1.5'            memory: 1024M        reservations:            cpus: '0.5'            memory: 512M

Neste trecho de configuração, o campo limits impede que o container ultrapasse um ano e meio de núcleo de CPU, enquanto o campo reservations garante que o Docker só iniciará o serviço se houver pelo menos meio núcleo livre no servidor hospedeiro. Essa estratégia evita o comportamento caótico de sobrealocação, protegendo a estabilidade geral do homelab ou do ambiente de produção corporativo.

Ferramentas visuais e monitoramento em tempo real

Escrever regras no arquivo de configuração é apenas o primeiro passo; monitorar o comportamento dessas restrições no dia a dia é o que separa um ambiente estável de uma caixa-preta imprevisível. O uso de painéis visuais como o Portainer ou ferramentas leves de métricas ajuda a enxergar exatamente qual container está batendo no teto de CPU configurado pelos cgroups. Além disso, combinar essas travas de kernel com soluções de automação e observabilidade garante que você receba alertas antes que o afogamento de recursos cause indisponibilidade real para os usuários finais da aplicação.

Garantindo a estabilidade a longo prazo com governança de hardware

A governança de recursos computacionais não deve ser vista como uma burocracia restritiva, mas sim como um pilar fundamental de arquitetura e resiliência. Ao dominar os mecanismos nativos do kernel Linux como os cgroups, engenheiros e administradores ganham o superpoder de prever o comportamento de cargas de trabalho intensivas, eliminando surpresas desagradáveis em produção. Seja gerenciando um servidor caseiro de homelab ou uma frota corporativa de microsserviços, impor limites inteligentes assegura que cada aplicação receba exatamente o que precisa para rodar com eficiência, sem canibalizar o ecossistema ao seu redor.