Kubernetes vs Docker: diferenças e como funcionam juntos

Perguntar-se se usar Kubernetes ou Docker é 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, o registo público mais utilizado.

Esquema que compara máquinas virtuais com sistema operativo completo e contentores apoiados num único kernel — 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 — 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: 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 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 é 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, kind 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, 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 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 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.