O que é Kubernetes? Guia completo

Kubernetes é uma plataforma de orquestração de contêineres: um sistema que decide em qual máquina cada contêiner roda, reinicia o que falha, distribui tráfego entre réplicas e ajusta a quantidade de cópias de uma aplicação sem intervenção manual. Criado pelo Google e mantido hoje pela Cloud Native Computing Foundation (CNCF), é a ferramenta padrão de mercado para quem precisa rodar contêineres em produção, em escala maior do que um único servidor consegue segurar.

O problema que o Kubernetes resolve

Um contêiner isolado resolve empacotamento: a aplicação roda igual em qualquer máquina com Docker (ou outro runtime compatível) instalado. O problema aparece quando essa aplicação precisa rodar em dezenas ou centenas de cópias, espalhadas em várias máquinas, com atualizações sem downtime, recuperação automática de falhas e capacidade de crescer sob demanda. Fazer isso na mão — com scripts, cron jobs e monitoramento manual — funciona até um certo tamanho e depois vira uma fonte constante de incidentes. O Kubernetes existe para automatizar exatamente essa camada: ele não substitui o contêiner, ele orquestra muitos deles.

Como funciona por dentro: a arquitetura

Um cluster Kubernetes é dividido em duas partes: o control plane, que toma as decisões, e os nodes (nós), máquinas que efetivamente rodam as aplicações. Essa separação é o que permite ao Kubernetes reconciliar continuamente o estado real do cluster com o estado desejado que você declarou — se um node cai, o control plane percebe e recria as cargas que estavam nele em outro lugar.

Control plane

• kube-apiserver — a porta de entrada: expõe a API HTTP do Kubernetes e é o único componente que fala diretamente com o restante do cluster.
• etcd — banco de dados chave-valor consistente e altamente disponível que guarda todo o estado do cluster.
• kube-scheduler — decide em qual node cada Pod recém-criado deve rodar, com base em recursos disponíveis e restrições declaradas.
• kube-controller-manager — roda os controladores (loops de controle) que mantêm o estado real igual ao estado desejado.
• cloud-controller-manager — componente opcional que integra o cluster com a nuvem específica (AWS, Azure, GCP), por exemplo para provisionar load balancers.

Nodes (nós de trabalho)

• kubelet — agente que roda em cada node, garante que os contêineres descritos nos Pods atribuídos a ele estejam de fato rodando e reporta o status ao control plane.
• kube-proxy — mantém as regras de rede do node para que o tráfego chegue aos Pods certos através dos Services.
• Container runtime — o software que efetivamente executa os contêineres (containerd e CRI-O são os mais usados hoje, seguindo o padrão OCI).

Pod: a menor unidade que o Kubernetes gerencia

O Kubernetes não gerencia contêineres soltos — ele gerencia Pods. Um Pod é um grupo de um ou mais contêineres que compartilham rede (o mesmo endereço IP e espaço de portas) e, opcionalmente, armazenamento, sempre agendados juntos na mesma máquina. Na prática, a grande maioria dos Pods roda um único contêiner; múltiplos contêineres no mesmo Pod só fazem sentido quando eles precisam estar fortemente acoplados (um contêiner principal e um sidecar de log, por exemplo).

Pods são efêmeros por design: quando um Pod é destruído, ele não volta sozinho, e um novo Pod criado no lugar recebe um IP diferente. Por isso a documentação oficial recomenda não criar Pods diretamente, nem mesmo Pods avulsos — na prática, quase ninguém escreve um Pod manifest e aplica sozinho; o normal é descrever o resultado desejado através de um Deployment (ou de um Job, StatefulSet ou DaemonSet, dependendo do caso) e deixar o controlador correspondente criar e recriar os Pods conforme necessário.

apiVersion: v1
kind: Pod
metadata:
  name: exemplo-nginx
spec:
  containers:
    - name: nginx
      image: nginx:1.27
      ports:
        - containerPort: 80

Deployment: como o Kubernetes mantém o estado desejado

Um Deployment descreve declarativamente quantas réplicas de um Pod devem existir e qual versão da aplicação rodar. Por baixo dos panos, o Deployment cria e gerencia um ReplicaSet, que é quem efetivamente mantém o número de Pods no ar. Quando você atualiza a imagem de um Deployment, ele cria um novo ReplicaSet e escala gradualmente o novo para cima enquanto escala o antigo para baixo — um rolling update sem downtime. Se a nova versão falhar, é possível reverter para a revisão anterior.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: exemplo-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: exemplo-nginx
  template:
    metadata:
      labels:
        app: exemplo-nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.27
          ports:
            - containerPort: 80

Service: como expor e conectar aplicações

Como cada Pod tem um IP próprio e efêmero, nada garante que o Pod que respondeu uma requisição agora ainda exista daqui a um minuto. Um Service resolve isso: é um endereço estável (um IP virtual fixo) que aponta automaticamente para o conjunto de Pods saudáveis que casam com um seletor de labels, mesmo quando esses Pods são recriados. Os tipos mais comuns são ClusterIP (padrão, só acessível dentro do cluster), NodePort (expõe uma porta fixa em cada node) e LoadBalancer (provisiona um balanceador de carga externo, normalmente via cloud-controller-manager).

apiVersion: v1
kind: Service
metadata:
  name: exemplo-nginx
spec:
  selector:
    app: exemplo-nginx
  type: ClusterIP
  ports:
    - port: 80
      targetPort: 80

kubectl: a ferramenta de linha de comando

kubectl é o cliente de linha de comando que fala com o kube-apiserver. Praticamente toda operação do dia a dia passa por ele: aplicar manifests, inspecionar o estado do cluster, ver logs e depurar problemas.

# aplica um manifest (cria ou atualiza os recursos nele descritos)
kubectl apply -f deployment.yaml

# lista os Pods em execução e seu status
kubectl get pods

# mostra os logs de um Pod específico
kubectl logs exemplo-nginx-7d8f9c6b5-abcde

# escala um Deployment na mão
kubectl scale deployment/exemplo-nginx --replicas=5

# descreve um recurso com detalhes e eventos recentes (essencial para depurar)
kubectl describe pod exemplo-nginx-7d8f9c6b5-abcde

De onde veio o Kubernetes

O projeto nasceu dentro do Google, inspirado no sistema interno Borg usado para orquestrar as cargas da empresa havia mais de uma década. O primeiro commit público foi em 6 de junho de 2014; a versão 1.0 saiu em julho de 2015, junto com a doação do projeto à recém-criada Cloud Native Computing Foundation (CNCF), ligada à Linux Foundation — o que tirou o Kubernetes do controle exclusivo de uma empresa e o tornou um projeto de governança aberta. Essa origem explica por que ele foi desenhado desde o início para múltiplos provedores de nuvem, e não só para a infraestrutura do Google.

O que o Kubernetes não faz

A própria documentação oficial é explícita sobre os limites da plataforma: Kubernetes não é uma PaaS completa. Ele não builda nem faz deploy do seu código-fonte (isso é trabalho de uma esteira de CI/CD separada), e não vem com banco de dados, fila de mensagens ou cache prontos — só orquestra os contêineres que você já empacotou. Entender essa fronteira evita a frustração de esperar do Kubernetes algo que ele nunca se propôs a entregar.

Quando o Kubernetes é complexidade demais

Kubernetes tem um custo operacional real: manter um control plane, cuidar de upgrades de versão, entender rede entre Pods e ajustar permissões (RBAC) exige uma curva de aprendizado que não é pequena. Para uma aplicação pequena, com um único serviço e sem necessidade de escalar horizontalmente, esse custo costuma superar o benefício — um único servidor bem configurado, um Docker Compose ou uma PaaS gerenciada resolvem o problema com muito menos peças móveis. Faz mais sentido adotar Kubernetes quando já existem múltiplos serviços, picos de tráfego reais que exigem escalonamento automático, ou a necessidade de portar a mesma infraestrutura entre nuvens diferentes sem reescrevê-la.

Boas práticas essenciais

• Defina requests e limits de CPU e memória em todo contêiner — sem isso, um único Pod mal comportado pode consumir recursos que outras aplicações do cluster precisam, e clusters com ResourceQuota chegam a recusar a criação do Pod.
• Configure liveness e readiness probes — a liveness probe deixa o kubelet reiniciar um contêiner travado; a readiness probe tira o Pod da lista de destinos de um Service até ele estar de fato pronto para receber tráfego.
• Nunca aponte para :latest em produção — fixe a versão da imagem para que um rollout seja prevísivel e reversível.
• Separe ambientes com Namespaces do próprio Kubernetes — um mecanismo de organização lógica de recursos dentro do cluster, diferente (e numa camada acima) dos namespaces do kernel Linux que isolam um contêiner individual.