---
title: "Kubernetes vs Docker: diferenças e como funcionam juntos"
description: "Não são alternativas: um cria e executa containers, o outro coordena-os em várias máquinas. Descobre o papel de cada um e quando precisas do segundo."
url: "https://www.alemasone.com/pt/diferencas-kubernetes-e-docker-como-funciona/"
language: "pt"
published: 2026-04-04
updated: 2026-09-20
categories: ["Programação E Desenvolvimento"]
translations:
  it: "https://www.alemasone.com/it/kubernetes-e-docker-differenze/"
  en: "https://www.alemasone.com/en/kubernetes-vs-docker-differences-how-they-work/"
  es: "https://www.alemasone.com/es/diferencias-kubernetes-y-docker/"
  fr: "https://www.alemasone.com/fr/difference-kubernetes-docker-orchestration/"
  de: "https://www.alemasone.com/de/kubernetes-vs-docker-unterschiede-zusammenarbeit/"
---

# Kubernetes vs Docker: diferenças e como funcionam juntos

Perguntar-se se usar [Kubernetes](https://kubernetes.io/) ou [Docker](https://www.docker.com/) é um pouco como perguntar se deves comprar um camião ou construir um porto. **O Docker cria e executa os contentores. O Kubernetes coordena centenas de contentores em dezenas de máquinas.** Trabalham em dois níveis diferentes e, frequentemente, são usados em conjunto. Ou então usas apenas o Docker, porque muitos projetos não têm o problema que o Kubernetes resolve.

Para entenderes a diferença, ajuda a comparação com o transporte de mercadorias, de onde estas ferramentas tiraram os nomes e logótipos: a baleia do Docker carrega contentores; o leme do Kubernetes (em grego *kubernetes* significa precisamente «timoneiro») guia-os.

## O contentor e o porto

**O contentor** é uma caixa padrão. Dentro colocas a aplicação, as suas bibliotecas e a versão exata da linguagem de que ela precisa. Por fora, é sempre a mesma caixa, com os mesmos encaixes: quem a move não precisa de saber o que está lá dentro. Assim, desaparece o clássico «na minha máquina funciona».

Ao contrário de uma máquina virtual, um contentor não traz consigo um sistema operativo inteiro: utiliza o kernel do sistema que o aloja. Por isso, arranca num segundo e pesa dezenas de megabytes em vez de gigabytes. Em contrapartida, é menos isolado do que uma VM, e um contentor Linux precisa de um kernel Linux.

**Docker** é a oficina que constrói a caixa e o guindaste que a carrega para o camião. Escreves as instruções num **Dockerfile**, o Docker produz uma **imagem** e executa-a com o **Docker Engine**. Encontras imagens prontas no **[Docker Hub](https://hub.docker.com/)**, o registo público mais utilizado.

![Esquema que compara máquinas virtuais com sistema operativo completo e contentores apoiados num único kernel](architettura-container-e-virtuali-kubernetes-docker.png "O contentor partilha o kernel: é isto que o torna leve")

**Kubernetes** é o porto. Não constrói caixas nem as abre: decide **em que navio vai cada uma**, quantas cópias da mesma carga manter espalhadas, o que fazer quando um navio afunda e como encaminhar os camiões que chegam para a doca certa. Se uma caixa cair ao mar, carrega imediatamente outra idêntica e ninguém nota.

Na prática, um cluster Kubernetes tem um **control plane**, que toma as decisões, e vários **nós** (as máquinas) que executam o trabalho. Os contentores correm dentro de **pods**, a unidade mais pequena que o Kubernetes gere: normalmente um pod contém um contentor; por vezes, dois ou três que têm de estar juntos.

Um porto com três contentores é um pátio com três caixas: organizá-lo custa mais do que o problema que resolve. É por isso que muitos projetos ficam perfeitamente bem apenas com Docker.

![Esquema de um cluster Kubernetes com o control plane e os nós worker que alojam pods e contentores](architettura-kubernetes-e-docker.png "O control plane decide, os nós executam")

## O que cada um faz

| | Docker | Kubernetes |
|---|---|---|
| Âmbito | Uma máquina | Muitas máquinas juntas |
| Tarefa | Construir e executar contentores | Distribuí-los, monitorizá-los, substituí-los |
| Problema que resolve | «Funciona em todo o lado da mesma forma» | «Mantém-se de pé e aguenta a carga» |
| Dificuldade | O essencial aprendes numa tarde | Semanas, e nunca terminas |
| Quando é necessário | Em quase todos os projetos | Quando a escala o exige |

O Kubernetes justifica-se com cinco funções. Se não precisas de nenhuma delas, não precisas do Kubernetes:

- **Reinício automático** daquilo que deixa de funcionar (*self-healing*).
- **Escalabilidade**: aumenta e reduz as cópias com base na carga.
- **Distribuição de tráfego** entre as cópias ativas.
- **Atualizações graduais**, que substituem as cópias uma a uma sem interrupções, com retorno à versão anterior se algo correr mal.
- **Configuração declarativa**: escreves num ficheiro YAML o estado que desejas e o sistema trabalha para o manter, em vez de executares comandos um a um.

## «O Kubernetes abandonou o Docker»: o que aconteceu

Esta notícia volta à tona de vez em quando, e normalmente é mal contada.

Na versão 1.24, lançada em maio de 2022, o Kubernetes removeu o *dockershim*, a peça que lhe permitia usar o **motor do Docker** para executar os contentores. Hoje utiliza runtimes mais leves que respeitam o padrão CRI, como o **containerd** (que, entretanto, é o mesmo motor que o Docker usa internamente) e o **CRI-O**.

As imagens não têm nada a ver: as criadas com Docker seguem o padrão aberto OCI e correm de forma idêntica no Kubernetes. Para quem desenvolve, nada mudou: constróis com Docker e executas no Kubernetes como antes. A alteração afetou apenas quem administra os clusters.

## O que usar, dependendo de onde estás

**Uma única aplicação num servidor.** Só o Docker basta: uma imagem, um comando para a iniciar e a opção `--restart unless-stopped` para reiniciar sozinha. Adicionar um orquestrador aqui significa ter um segundo sistema para manter apenas para gerir uma única coisa.

**Vários serviços ligados numa máquina**, por exemplo: aplicação, base de dados e cache. Aqui precisas do **[Docker Compose](https://docs.docker.com/compose/)**: um ficheiro `compose.yaml` descreve todos os serviços e como comunicam entre si, e `docker compose up` arranca-os em conjunto. Cobre o [ambiente de desenvolvimento](/pt/melhores-alternativas-xampp-desenvolvimento-local/) de quase todos os projetos e muitas instalações em produção de pequena dimensão.

**Várias máquinas, carga variável, nenhuma interrupção permitida.** Aqui o Kubernetes começa a valer a pena. O critério: se um serviço tem de continuar ativo enquanto uma máquina avaria, e o número de cópias deve mudar sozinho conforme o tráfego, estás no sítio certo.

**Os meios-termos.** O **[k3s](https://k3s.io/)** é um Kubernetes leve que oferece as funções essenciais com muito menos complexidade, ideal para um par de máquinas ou um Raspberry Pi. O **Docker Swarm**, incluído no Docker, junta várias máquinas com comandos que já conheces. E os serviços geridos dos grandes fornecedores, **Amazon EKS**, **Google GKE** e **Azure AKS**, tratam do *control plane* por ti, embora tenhas de aprender o modelo do Kubernetes de qualquer forma. Na AWS também existe o **ECS**, que executa contentores sem precisar de Kubernetes.

> **Aprende nesta ordem.** Primeiro a construir uma imagem e a executá-la; depois Compose para alguns serviços numa máquina; só depois o Kubernetes, localmente com [minikube](https://minikube.sigs.k8s.io/), [kind](https://kind.sigs.k8s.io/) ou o cluster integrado no Docker Desktop. Quem salta os dois primeiros passos acaba por copiar ficheiros YAML que não entende, e é daí que nasce a fama de ferramenta incompreensível.

## Os custos ocultos

Quem coloca o Kubernetes num projeto pequeno descobre rapidamente que a conta não é apenas técnica:

- **As máquinas do cluster consomem recursos** mesmo sem tráfego, porque os componentes do sistema estão sempre a correr.
- **Exige competência contínua**: rede interna, volumes persistentes, gestão de credenciais, atualizações de versão. O Kubernetes lança três versões por ano e cada uma é suportada durante cerca de quatorze meses, por isso não o instalas e te esqueces dele.
- **O debug torna-se mais longo**: entre o teu código e a requisição do utilizador existem mais camadas, e aprender a lê-las exige tempo.
- **O Docker Desktop é pago para grandes empresas**: gratuito para uso pessoal, estudo e empresas com menos de 250 funcionários e 10 milhões de dólares de faturação; caso contrário, precisas de uma subscrição. Se precisares de uma alternativa aberta, existem o [Podman](https://podman.io/), Rancher Desktop e, no Mac, OrbStack ou Colima.

São excelentes motivos para não o usares quando não for necessário, e nenhum destes é um motivo para o evitares quando for preciso.

> **Quem é que o levanta às três da manhã?** Conta quantas pessoas no grupo saberiam fazê-lo. Se a resposta for «uma», uma infraestrutura complexa é um risco adicional. A disponibilidade contínua obtém-se com ferramentas que o grupo conhece bem, mesmo que sejam menos potentes.

## Perguntas frequentes

### Devo aprender Docker antes de Kubernetes?

Sim, e isso poupa-te tempo. O Kubernetes coordena contentores: se não souberes o que é uma imagem, como se constrói e como se inicia, vais acabar por copiar configurações sem saber o que elas fazem.

### O Kubernetes pode funcionar sem Docker?

Sim, e essa é a norma: desde 2022 que os clusters usam containerd ou CRI-O para executar os contentores. No entanto, o Docker continua a ser a ferramenta mais prática para construir as imagens que o Kubernetes depois executa.

### Qual é a diferença entre um contentor e uma máquina virtual?

A [máquina virtual](/pt/melhores-softwares-virtualizacao-guia-comparativo/) contém um sistema operativo completo, pesa gigabytes e demora algum tempo a arrancar. O contentor utiliza o kernel do sistema que o aloja, pesa muito menos e arranca num segundo. Em contrapartida, é menos isolado; para executar contentores Linux em Windows ou Mac, precisas de uma pequena máquina virtual, algo que o [Docker Desktop](/pt/virtualizacao-mac-apple-silicon-windows-linux/) gere sozinho.

### O Kubernetes substitui o Docker Compose?

Numa única máquina não, e muitos projetos ficam no Compose para sempre. O Compose descreve vários serviços num computador, sendo perfeito para desenvolvimento e instalações pequenas. O Kubernetes descreve os mesmos serviços distribuídos por várias máquinas, com regras de resiliência a falhas.

### Serve para um site ou um blog?

Não, na grande maioria dos casos. Um site estático, um blog ou uma aplicação com algumas centenas de visitas por dia correm bem num servidor com Docker, ou até sem ele. A orquestração começa a valer a pena quando a escala e os requisitos de disponibilidade o impõem.

### Quando escolher Docker Swarm em vez de Kubernetes?

Quando tens poucas máquinas, um grupo pequeno e queres começar rapidamente: o Swarm ativa-se com `docker swarm init` e utiliza ficheiros semelhantes aos do Compose. No entanto, é muito menos difundido, com um ecossistema reduzido. Se planeias crescer, compensa investir diretamente em Kubernetes, talvez começando pelo k3s.

### Quanto custa um cluster gerido?

Depende do fornecedor e das dimensões. O item principal costuma ser as máquinas que o compõem, sempre ligadas, mais uma pequena taxa horária pelo *control plane* em alguns serviços. Um ambiente mínimo com redundância custa, de qualquer forma, mais do que um servidor único: faz as contas antes de começares.