Kubernetes: o que é e como orquestrar containers na prática

Imagine um time que migrou três serviços para containers.

Cada serviço tem um Dockerfile, tudo roda com `docker run`.

Funciona bem em desenvolvimento.

Em produção, o primeiro container cai às 3h da manhã e ninguém sabe.

O segundo precisa escalar porque o tráfego dobrou, e alguém entra por SSH para subir mais uma instância manualmente.

O terceiro só pode subir depois do segundo, mas quem garante essa ordem é uma pessoa seguindo um runbook.

Docker resolve empacotar a aplicação.

Ele não resolve agendar, reiniciar, escalar e conectar dezenas de containers em máquinas diferentes.

Essa é a lacuna que a orquestração de containers preenche. ## O que é Kubernetes, em uma definição direta Kubernetes é uma plataforma open source de orquestração de containers.

Ele recebe um estado desejado (por exemplo, "quero três réplicas da API rodando") e trabalha continuamente para que a realidade do cluster bata com esse pedido.

Se um container morre, ele sobe outro.

Se um node inteiro sai do ar, ele redistribui as cargas.

O projeto nasceu no Google, foi anunciado em junho de 2014 e doado à Cloud Native Computing Foundation (CNCF) em julho de 2015.

O nome vem do grego kybernētēs, que significa timoneiro.

A CNCF costuma descrever o Kubernetes como o segundo maior projeto open source do mundo em atividade, atrás apenas do kernel Linux.

Uma confusão comum: Kubernetes não substitui o Docker.

Ele orquestra containers, e os containers podem ser construídos com Docker, containerd ou CRI-O.

O Kubernetes fala com esses runtimes por meio de uma interface chamada CRI (Container Runtime Interface). ## As peças de um cluster Um cluster Kubernetes divide-se em duas partes.

O control plane é o cérebro.

Os worker nodes executam a carga.

No control plane ficam quatro componentes centrais.

O kube-apiserver é a porta de entrada: todo comando passa por ele.

O etcd é o banco de dados chave-valor que guarda o estado do cluster.

O kube-scheduler decide em qual node cada pod vai rodar, considerando recursos disponíveis.

O kube-controller-manager roda os loops de controle que corrigem desvios entre o desejado e o real.

Nos worker nodes rodam dois componentes principais.

O kubelet é o agente que recebe ordens do control plane e garante que os containers definidos estejam de pé.

O kube-proxy cuida das regras de rede para que serviços se comuniquem.

A menor unidade que o Kubernetes agenda não é o container, é o Pod.

Um Pod agrupa um ou mais containers que compartilham rede e armazenamento.

Na prática, a maioria dos Pods tem um único container, e o Pod é o invólucro que o Kubernetes move entre nodes. ## Como funciona na prática: do comando ao container rodando 1.

Você escreve um manifesto YAML declarando o estado desejado, por exemplo um Deployment com três réplicas da sua API.

2.

O `kubectl apply` envia o manifesto ao kube-apiserver, que valida e grava no etcd.

3.

O kube-controller-manager percebe que ainda não existem três Pods e cria a solicitação.

4.

O kube-scheduler escolhe em qual node cada Pod deve rodar, com base em CPU, memória e regras de afinidade.

5.

O kubelet do node escolhido recebe a tarefa, pede ao runtime de container que baixe a imagem e inicie o processo.

6.

O kube-proxy configura as regras de rede para que o Service aponte para os novos Pods, distribuindo o tráfego entre eles.

7.

Se um Pod morre, o loop de controle detecta a diferença em relação ao estado desejado e cria outro.

Nenhum humano precisa intervir.

Esse ciclo é chamado de reconciliation loop.

Ele é o motivo pelo qual o Kubernetes é descrito como uma plataforma declarativa, e não imperativa.

Você declara o resultado, não os passos. ## O que o Kubernetes resolve bem Escala horizontal.

Você muda um número no manifesto e o cluster distribui as réplicas.

Auto-recuperação.

Um Pod que falha é substituído automaticamente.

Balanceamento de carga.

Um Service expõe um IP estável e o kube-proxy divide o tráfego entre os Pods vivos, mesmo que eles mudem de IP a cada reinício.

Rolling updates.

O Deployment permite subir uma nova versão de imagem substituindo Pods gradualmente, sem derrubar o serviço inteiro, e voltar atrás com um rollback se a métrica de erro subir.

Configuração separada do código.

ConfigMaps guardam variáveis de ambiente e Secrets guardam credenciais, ambos injetados nos Pods em tempo de execução. ## Quando não usar Kubernetes Operar um cluster tem custo real: curva de aprendizado, consumo de recursos do próprio control plane e a necessidade de alguém entender rede, storage e segurança.

Para um projeto pequeno com dois ou três serviços e tráfego previsível, uma única máquina com Docker Compose resolve com muito menos peças móveis.

O Kubernetes passa a valer quando o volume de serviços cresce, quando é preciso escalar de forma automática, ou quando vários times compartilham infraestrutura e precisam de isolamento.

Provedores como Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS) e Azure Kubernetes Service (AKS) cuidam do control plane, o que reduz boa parte do trabalho operacional. ## O que dá para fazer hoje, sem montar um cluster Quem quer aprender sem compromisso pode usar o minikube ou o kind para subir um cluster local em uma única máquina.

Em free tiers de provedores de nuvem é possível rodar um cluster gerenciado pequeno por custo próximo de zero.

O caminho mais rápido é escrever um Deployment simples, expor com um Service e observar o `kubectl get pods` reagir quando você apaga um Pod de propósito.

Ver o cluster recriar o que você destruiu ensina, em segundos, o que páginas de documentação levam mais tempo para fixar.