Pesquisar por Docker vs Kubernetes sugere que você deve escolher um, mas esse enquadramento causa muita confusão. É um pouco como comparar um contêiner com o porto que organiza milhares deles. Eles operam em níveis diferentes e muitas vezes são usados ​​lado a lado.

Este guia explica o que cada um faz, mostra o mesmo pequeno aplicativo em ambos e termina com uma forma prática de decidir. Os comandos e arquivos aqui são exemplos padrão que não executamos neste artigo, portanto, compare-os com as versões que você instalou.

A resposta curta

Docker é uma plataforma para empacotar um aplicativo e suas dependências em uma imagem e, em seguida, executar essa imagem como um contêiner. Ele responde à pergunta “como faço para que este aplicativo funcione da mesma maneira em todos os lugares?”

Kubernetes, geralmente escrito K8s, é um orquestrador de contêineres. Ele decide onde os contêineres são executados em muitas máquinas, reinicia-os quando falham e os dimensiona de acordo com a demanda. Ele responde à pergunta “como mantenho centenas de contêineres funcionando de maneira confiável?”

Docker x Kubernetes lado a lado

O que o Docker faz

Antes dos containers, “funciona na minha máquina” era um problema diário, pois cada servidor tinha versões diferentes de tudo. O Docker agrupa seu código, tempo de execução e bibliotecas em uma imagem. Uma cópia em execução dessa imagem é um contêiner e compartilha o kernel do host, portanto inicia mais rápido e usa menos memória do que uma máquina virtual completa.

O fluxo de trabalho tem três etapas:

1. Construir: a Dockerfile descreve como criar a imagem.
2. Enviar: envia a imagem para um registro, como o Docker Hub.
3. Executar: inicia contêineres a partir dessa imagem em qualquer máquina compatível.

Para praticar, comece com nosso tutorial do Docker para iniciantes e depois leia nossas práticas recomendadas do Dockerfile.

O que o Kubernetes faz

O Docker em um servidor funciona bem até que o servidor falhe, o tráfego o supere ou você tenha dezenas de serviços para coordenar. O Kubernetes cuida destes trabalhos operacionais:

• Programação: colocação de contêineres em máquinas com capacidade livre suficiente.
• Autocorreção: substituição de contêineres com falha e remoção do trabalho de nós com falha.
• Escalonamento: adição ou remoção de cópias, manualmente ou com base em métricas.
• Descoberta de serviço: dar a um grupo variável de contêineres um nome estável.
• Atualizações contínuas: lançamento de novas versões gradualmente, com uma simples reversão.
• Configuração: gerenciamento de configurações e segredos separadamente das imagens.

A ideia central é estado desejado. Você declara que deveriam existir três cópias, e os controladores continuam comparando isso com a realidade e corrigindo qualquer diferença. Nosso tutorial do Kubernetes para iniciantes aborda isso em um cluster local.

Como Docker e Kubernetes funcionam juntos

Um caminho típico do laptop de um desenvolvedor até a produção é assim:

1. Um desenvolvedor escreve um Dockerfile e testa o contêiner localmente.
2. Um pipeline de CI/CD cria a imagem e executa os testes.
3. O pipeline envia uma imagem com versão para um registro.
4. Um manifesto do Kubernetes é atualizado para usar essa versão da imagem.
5. O Kubernetes extrai a imagem e a distribui pelo cluster.

Portanto, o trabalho do Docker está praticamente concluído antes do início do Kubernetes. A imagem é o ponto de transferência entre eles.

Um aplicativo, nos dois sentidos

Aqui está um pequeno serviço web. A imagem é construída da mesma forma, independentemente da ferramenta que a executa:

# Dockerfile
FROM python:3.13-slim
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
CMD ["python", "app.py"]

Executando com Docker

docker build -t shop-api:1.0 .
docker run -d --name shop -p 8080:8000 --restart unless-stopped shop-api:1.0

Dois comandos e ele está em execução. Isso é simples e adequado para muitos projetos pequenos. Mas há uma cópia em uma máquina e, se a máquina morrer, o serviço vai junto.

Executando com Kubernetes

# shop.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: shop
spec:
  replicas: 3
  selector:
    matchLabels:
      app: shop
  template:
    metadata:
      labels:
        app: shop
    spec:
      containers:
        - name: api
          image: registry.example.com/shop-api:1.0
          ports:
            - containerPort: 8000
---
apiVersion: v1
kind: Service
metadata:
  name: shop
spec:
  selector:
    app: shop
  ports:
    - port: 80
      targetPort: 8000

kubectl apply -f shop.yaml
kubectl get pods -l app=shop

Há muito mais para escrever e você precisa de um cluster para executá-lo. Em troca, você recebe três cópias, um endereço interno estável e substituição automática. Essa compensação é toda a decisão em miniatura: mais complexidade em troca de mais resiliência.

O que acontece quando um contêiner falha?

A confusão dockershim

Você deve ter lido que “Kubernetes abandonou o Docker”. Isso é verdade em sentido estrito e assustou muitas pessoas desnecessariamente. O Kubernetes executa contêineres por meio de um padrão chamado Container Runtime Interface. O Docker Engine não o implementou diretamente, então o Kubernetes incluiu um adaptador chamado dockershim. Esse adaptador foi removido na versão 1.24.

Os clusters agora normalmente usam tempos de execução como containerd ou CRI-O. As imagens que você cria com o Docker ainda funcionam, porque seguem o padrão de imagem da Open Container Initiative (OCI). Assim, você pode continuar construindo com o Docker e seu cluster executará o resultado com um tempo de execução diferente.

Docker Compose x Swarm x Kubernetes

A comparação mais significativa é entre ferramentas que coordenam contêineres:

Docker Compose inicia vários contêineres relacionados a partir de um arquivo e é excelente para um aplicativo da web e um banco de dados em um laptop. O Swarm está integrado ao Docker e é muito mais fácil de aprender do que o Kubernetes, mas possui um ecossistema muito menor. O Kubernetes tem a maior comunidade e ferramentas, o que explica em grande parte o motivo pelo qual se tornou o padrão para grandes implantações.

Qual você precisa?

O Docker sozinho geralmente é suficiente quando:

• Você está desenvolvendo localmente ou executando um pequeno aplicativo em um servidor.
• Você tem uma equipe pequena e nenhuma equipe de operações dedicada.
• Breves períodos de inatividade ocasionais são aceitáveis.

Kubernetes começa a fazer sentido quando:

• Você executa muitos serviços que diferentes equipes implantam por conta própria.
• Você precisa de alta disponibilidade em diversas máquinas ou zonas.
• O tráfego varia o suficiente para que o escalonamento automático economize dinheiro real.
• Você tem as habilidades ou o orçamento para operá-lo.

Também existe um meio-termo. Plataformas de contêineres gerenciados, como AWS Fargate, Google Cloud Run ou PaaS, executam sua imagem Docker sem um cluster para manter. Para muitas empresas em crescimento, esse é o próximo passo certo, em vez de saltar direto para o Kubernetes.

Se você quiser aprender ambos por motivos profissionais, a ordem é clara: primeiro Docker, depois Kubernetes. Você não pode depurar um pod confortavelmente sem primeiro entender imagens, portas e logs de contêiner.

Erros comuns

• Adotar o Kubernetes muito cedo. Copiar a arquitetura de uma empresa gigante pode enterrar uma pequena equipe no trabalho operacional.
• Usando a tag latest na produção. Você não pode saber o que está em execução ou reverter de maneira confiável. Use tags de versão específicas.
• Armazenamento de dados dentro de contêineres. Os contêineres são descartáveis, portanto, use volumes ou um banco de dados gerenciado.
• Ignorando verificações de integridade. Sem testes de prontidão e atividade, o Kubernetes não poderá tomar boas decisões sobre seu aplicativo.
• Esquecendo os limites de recursos. Um contêiner ganancioso pode privar todo o resto de um nó.

Considerações finais

O Docker empacota seu software e o Kubernetes o executa em escala. Em vez de perguntar o que é melhor, pergunte qual é o problema que você tem hoje. Se for “meu aplicativo é difícil de instalar”, use o Docker. Se for “meus 40 serviços precisam sobreviver a falhas de servidor”, veja o Kubernetes. Comece com a ferramenta mais simples que resolve seu problema real e avance quando perceber a necessidade.

Perguntas frequentes

Continue aprendendo