Kubernetes ou Docker Compose: quando vale a pena migrar no seu servidor dedicado

Kubernetes ou Docker Compose? Compare complexidade, alta disponibilidade, recursos e equipe para decidir o que usar no seu servidor dedicado.

Para que serve

A dúvida Kubernetes ou Docker Compose aparece quando as aplicações em container começam a crescer. Este artigo ajuda você a decidir com critérios práticos, considerando o cenário típico de um servidor dedicado: uma máquina física potente, muitas vezes com Proxmox VE e várias VMs. Não há resposta única: Compose é mais simples e suficiente para muita coisa; Kubernetes resolve problemas que só aparecem com mais serviços, mais gente mexendo e exigência de disponibilidade.

Para instalar o Docker e o Compose, veja o artigo Como instalar Docker e Docker Compose no Debian e no Ubuntu.

Pré-requisitos para a decisão

• Inventário do que roda hoje: quantos serviços, quais guardam dados (bancos, uploads) e quais são sem estado (APIs, front-ends).
• Quantas pessoas fazem deploy e com que frequência.
• Quanto tempo de parada é aceitável numa atualização ou numa falha.

O que cada um faz

Docker Compose descreve um conjunto de containers em um arquivo YAML e os executa em um único host. Ele cria redes, volumes e reinicia containers que caem (com restart: unless-stopped), mas não move cargas entre máquinas nem faz atualização gradual com verificação de saúde de forma nativa.

Kubernetes é um orquestrador: você declara o estado desejado (quantas réplicas, quanta CPU e memória, qual versão) e o cluster trabalha continuamente para mantê-lo, em um ou vários nós. Ele traz atualização gradual (rolling update) com rollback, sondas de saúde, escalonamento automático, descoberta de serviços, controle de acesso por papéis (RBAC) e um ecossistema enorme (Helm, cert-manager, operadores de banco).

Comparação lado a lado

Critério	Docker Compose	Kubernetes (k3s)
Curva de aprendizado	Baixa: um arquivo, poucos conceitos	Alta: pods, deployments, services, ingress, PVC, RBAC
Número de hosts	Um	Um ou muitos
Alta disponibilidade	Não nativa	Réplicas, reagendamento e etcd em quórum
Atualização sem parada	Manual (ou com proxy e truques)	Rolling update e rollback nativos
Consumo extra de recursos	Praticamente nenhum	Plano de controle: cerca de 0,5 a 1 GB de RAM por servidor no k3s
HTTPS automático	Com proxy à parte (Traefik, Caddy)	Ingress + cert-manager
Volumes persistentes	Diretórios ou volumes locais	PVC com local-path, Longhorn, NFS, Ceph
Multiusuário e permissões	Quem acessa o Docker é root na prática	RBAC por namespace
Depuração	Simples: docker logs	Mais camadas para investigar

Quando ficar no Docker Compose

• Até umas dez ou quinze aplicações, em uma VM ou servidor, mantidas por uma ou duas pessoas.
• Pode haver alguns minutos de parada em atualização, agendada fora do horário comercial.
• A aplicação principal é um banco de dados ou ERP monolítico, que não ganha nada com réplicas.
• A disponibilidade já vem de outra camada: backup das VMs no Proxmox com restauração testada, por exemplo.

Nesse cenário, Kubernetes acrescenta complexidade sem benefício real. Um Compose bem feito, com variáveis em arquivo .env, versões de imagem fixas, healthchecks e backup, atende muito bem.

Quando migrar para Kubernetes

• Muitos serviços pequenos (microsserviços) com deploys diários, feitos por equipes diferentes.
• Necessidade de atualizar sem parada e voltar atrás com um comando.
• Você quer espalhar a carga por várias VMs ou servidores e sobreviver à perda de um nó.
• Precisa isolar clientes ou equipes por namespace, com cotas de CPU e memória (comum em MSPs e SaaS).
• Você já usa pipelines de CI/CD e quer GitOps (Argo CD, Flux).

Caminho intermediário

1. Comece com k3s em uma VM, lado a lado com o Compose atual. Migre primeiro um serviço sem estado (um site ou API).
2. Converta os arquivos com o kompose para ter um ponto de partida:

   kompose convert -f compose.yaml -o k8s/

   O resultado precisa de revisão: ajuste requests e limits de recursos, sondas de saúde, Secrets no lugar de variáveis com senha e PVCs com o StorageClass certo.
3. Deixe bancos de dados por último. Muita gente mantém o banco em VM própria (fora do cluster) e coloca só as aplicações no Kubernetes. É uma escolha válida e mais simples de operar.
4. Só então expanda para três nós, quando o time estiver confortável com o dia a dia.

Existe também o Docker Swarm, que usa uma sintaxe próxima do Compose e oferece réplicas em vários hosts. Ele continua mantido, mas o ecossistema é muito menor; para projetos novos que precisam de orquestração, Kubernetes costuma ser a aposta mais segura.

Como saber se a escolha funcionou

• Você consegue recriar o ambiente do zero a partir de arquivos versionados no Git.
• Uma atualização de rotina não exige ninguém acordado de madrugada.
• A restauração de backup foi testada nos últimos meses.

Se o Kubernetes está consumindo mais tempo de operação do que economiza, voltar ao Compose não é fracasso: é ajuste de ferramenta ao tamanho do problema.

Problemas comuns

"Migrei e ficou mais lento"

Geralmente são limits de CPU apertados demais (o container sofre throttling) ou volumes em armazenamento de rede. Revise os limits e use armazenamento local para cargas sensíveis a latência.

"O banco perdeu dados ao reiniciar o pod"

Os dados estavam no sistema de arquivos do container, não em um PersistentVolumeClaim. Veja Armazenamento persistente no Kubernetes: local-path ou Longhorn.

Perguntas frequentes

Kubernetes substitui o Proxmox?

Não. Eles atuam em camadas diferentes: o Proxmox cria VMs, e o Kubernetes orquestra containers dentro delas. É comum usar os dois juntos.

Preciso de três servidores físicos para usar Kubernetes?

Não. Um nó único já funciona; três VMs no mesmo servidor permitem aprender e fazer manutenção sem parar, embora não protejam contra falha do hardware.

Os arquivos do Compose funcionam no Kubernetes?

Não diretamente. O kompose converte boa parte, mas o resultado deve ser revisado à mão.

Kubernetes gasta muita memória?

O k3s é leve; o plano de controle cabe em menos de 1 GB. Em servidores com 128 GB ou mais, o custo extra é pequeno comparado ao das aplicações.

Leitura complementar

• Visão geral do Kubernetes (documentação oficial)
• Convertendo arquivos Compose com kompose
• Documentação do Docker Compose

Precisa de ajuda?

Se você quer dimensionar VMs para um cluster dentro do seu servidor dedicado, abra um ticket informando a configuração atual e as aplicações que pretende rodar.