O que é Kubernetes? Orquestração de containers

Rodar um container é fácil. Rodar centenas deles em produção, mantendo tudo no ar mesmo quando máquinas falham, já é outra história. O Kubernetes nasceu exatamente para resolver esse desafio. Neste artigo você vai entender o que ele é, quais problemas resolve, como seus principais componentes trabalham juntos e quando faz sentido (ou não) adotá-lo.

Por que precisamos de orquestração

Containers resolveram o empacotamento de aplicações, como vimos em O que é Docker? Containers explicados de forma simples. Mas quando uma aplicação cresce e passa a rodar dezenas ou centenas de containers espalhados por várias máquinas, surgem perguntas difíceis:

Fazer isso na mão é inviável. É aí que entra um orquestrador de containers: um sistema que automatiza a distribuição, o monitoramento e a escala dos containers.

Imagine o cenário sem orquestração: um servidor reinicia de madrugada e três containers críticos somem. Alguém precisa acordar, perceber a falha, escolher outro servidor com capacidade, subir os containers de novo e reconfigurar o balanceamento para apontar para os novos endereços. Multiplique isso por dezenas de serviços e por máquinas que falham em horários imprevisíveis, e fica claro por que operar containers em escala manualmente é insustentável. O orquestrador faz tudo isso sozinho, em segundos, sem ninguém acordar.

O que é Kubernetes

O Kubernetes (frequentemente abreviado como K8s) é uma plataforma de código aberto para orquestrar containers. Ele cuida de implantar, escalar e gerenciar aplicações conteinerizadas de forma automática, em um conjunto de máquinas tratado como um recurso único.

Originalmente criado pelo Google e depois doado à comunidade, o Kubernetes carrega mais de uma década de aprendizado em operar sistemas em escala massiva. Suas ideias derivam diretamente da experiência do Google com seus sistemas internos de gerenciamento de containers (Burns et al., 2016).

O nome curioso "K8s" é só uma abreviação: a letra K, seguida das 8 letras entre o "K" e o "s" de Kubernetes, e o "s" final. A própria palavra vem do grego e significa "timoneiro" ou "piloto" — quem conduz o navio. É uma boa metáfora: o Kubernetes não é a carga, é quem pilota a frota de containers.

A filosofia declarativa

O ponto-chave para entender o Kubernetes é seu modelo declarativo. Em vez de você dar uma lista de passos ("inicie este container, depois aquele"), você descreve o estado desejado: "quero 3 cópias desta aplicação rodando, sempre".

O Kubernetes então trabalha incansavelmente para fazer a realidade bater com essa declaração. Se um container cai e sobram apenas 2 cópias, ele sobe uma nova automaticamente. Esse mecanismo de reconciliação contínua é o que dá ao Kubernetes sua famosa capacidade de autocura.

A diferença entre imperativo e declarativo é o coração da coisa. No mundo imperativo, você dá ordens: "suba um container aqui". Se ele cair, o sistema não faz nada — você não mandou subir de novo. No mundo declarativo, você define um fato que deve ser verdadeiro: "devem existir 3 réplicas". O Kubernetes compara constantemente o que deveria existir com o que realmente existe e age para fechar a diferença. Esse laço de comparação e correção é executado por componentes chamados controllers, e é ele que faz o sistema parecer "vivo".

Você descreve o estado desejado em arquivos, geralmente em YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: minha-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: minha-app
  template:
    metadata:
      labels:
        app: minha-app
    spec:
      containers:
        - name: minha-app
          image: minha-empresa/minha-app:1.0
          ports:
            - containerPort: 3000

Conceitos fundamentais

O Kubernetes tem vocabulário próprio. Conhecer os principais blocos já ajuda muito:

A relação é hierárquica: containers vivem dentro de pods, pods rodam em nodes, e os nodes formam o cluster.

Vale acrescentar alguns objetos que aparecem cedo no dia a dia:

Por que os pods, e não os containers, são a menor unidade? Porque às vezes dois containers precisam viver tão juntos que faz sentido tratá-los como uma coisa só — por exemplo, uma aplicação e um pequeno container "ajudante" (sidecar) que coleta logs. Eles compartilham o mesmo endereço de rede e podem trocar arquivos por um volume comum. Ainda assim, o caso mais frequente é um pod com um único container.

Como o cluster é organizado

Um cluster Kubernetes tem dois tipos de componentes:

O control plane expõe uma O que é uma API? Definição clara para iniciantes central, com a qual todos os componentes e ferramentas conversam. É por meio dessa API que você aplica seus arquivos YAML, geralmente com a ferramenta de linha de comando kubectl:

kubectl apply -f minha-app.yaml   # aplica a configuração
kubectl get pods                  # lista os pods
kubectl scale deployment minha-app --replicas=5

Os componentes por dentro

Aprofundando um pouco, vale conhecer as peças principais de cada lado, porque elas aparecem em qualquer diagnóstico de problema:

No control plane:

Em cada worker node:

Não é preciso decorar tudo de início, mas saber que o etcd guarda o estado e que o kube-scheduler decide onde colocar pods já te dá um mapa mental para entender o que acontece quando algo dá errado.

Escalabilidade e autocura

Dois superpoderes fazem o Kubernetes brilhar em produção:

Esse comportamento elimina boa parte do trabalho manual de manter sistemas no ar e é justamente o que tornou a operação de containers em escala viável para tantas empresas.

A escala automática tem duas dimensões que vale distinguir. A escala horizontal (Horizontal Pod Autoscaler) cria mais réplicas de pods quando a carga sobe — é a mais comum. A escala de cluster (Cluster Autoscaler) vai além e adiciona ou remove nós inteiros quando não há mais espaço para novos pods. Juntas, elas permitem que um sistema cresça de 3 para 300 réplicas em um pico de tráfego e volte a encolher depois, pagando só pelo que usou.

Para a autocura funcionar bem, o Kubernetes precisa saber se um container está realmente saudável — e aí entram as probes. Uma liveness probe verifica se a aplicação está viva (e a reinicia se travou); uma readiness probe verifica se ela está pronta para receber tráfego (e a tira do balanceamento enquanto não estiver). Configurar essas sondas corretamente é o que separa um cluster que se cura de verdade de um que só finge estar saudável.

Atualizações sem downtime

Atualizar uma aplicação em produção sempre foi delicado. O Kubernetes facilita com estratégias de implantação embutidas, como o rolling update: ele substitui as réplicas antigas pelas novas aos poucos, garantindo que sempre haja instâncias atendendo aos usuários.

Se a nova versão apresentar problemas, é possível fazer rollback para a versão anterior com um único comando. Esse encaixe entre orquestração e automação é o que fecha o ciclo com o O que é CI/CD? Integração e entrega contínua: o pipeline constrói e testa a imagem, e o Kubernetes a coloca em produção de forma controlada e reversível.

Além do rolling update, existem outras estratégias que dão ainda mais segurança a lançamentos arriscados. No blue-green, você mantém duas versões completas no ar e troca o tráfego de uma para outra de uma vez, com rollback instantâneo. No canary, você envia só uma fração do tráfego (digamos, 5%) para a versão nova, observa as métricas e aumenta gradualmente se tudo correr bem. Essas técnicas não são exclusivas do Kubernetes, mas ele oferece os blocos de construção que as tornam práticas.

Kubernetes e microsserviços

A orquestração se encaixa especialmente bem em arquiteturas divididas em vários serviços pequenos e independentes. Cada serviço pode ter seu próprio Deployment, escalar de forma independente e ser atualizado sem afetar os demais. Esse modelo é detalhado em O que são microsserviços? Vantagens, desafios e quando usar.

O Kubernetes também resolve a comunicação interna entre esses serviços: por meio dos Services, um microsserviço encontra o outro por um nome estável, sem se preocupar com os endereços efêmeros dos pods. Para entregar conteúdo estático aos usuários finais com baixa latência, esses sistemas costumam se apoiar ainda em uma O que é uma CDN e como ela acelera seu site, que aproxima os arquivos do visitante enquanto o Kubernetes cuida da parte dinâmica.

Essa descoberta de serviços por nome funciona graças ao DNS interno do cluster: um Service chamado pagamentos fica acessível pelo endereço pagamentos dentro do mesmo namespace, sem que ninguém precise saber em qual nó os pods de pagamento estão rodando naquele momento. É uma abstração poderosa, porque desacopla totalmente "quem eu quero chamar" de "onde isso está agora".

Quando usar (e quando não)

O Kubernetes é poderoso, mas não é a solução para todo problema. Vale a pena quando você tem:

Por outro lado, para um projeto pequeno, com um ou dois containers, o Kubernetes pode ser complexidade demais. A curva de aprendizado é íngreme e operar um cluster exige conhecimento. Nesses casos, soluções mais simples (como rodar containers diretamente ou usar plataformas gerenciadas) costumam ser melhores.

Um caminho intermediário muito comum hoje é usar um Kubernetes gerenciado oferecido por provedores de nuvem, em que o control plane fica sob responsabilidade do provedor e você cuida apenas das suas aplicações. Isso elimina boa parte do fardo operacional sem abrir mão do modelo declarativo. Mesmo assim, a regra de ouro permanece: adote Kubernetes quando a complexidade do seu sistema já justificar a complexidade da ferramenta — e não antes, só por modismo.

Perguntas frequentes

Kubernetes substitui o Docker? Não. Eles resolvem problemas diferentes. O Docker (ou outro runtime) empacota e executa containers; o Kubernetes orquestra muitos containers em muitas máquinas. Na prática, eles se complementam.

Preciso de Kubernetes para colocar um app no ar? Não. Para projetos pequenos, rodar containers diretamente ou usar uma plataforma gerenciada simples costuma ser mais rápido e barato. Kubernetes compensa quando há escala, muitos serviços ou exigência de alta disponibilidade.

O que é kubectl? É a ferramenta de linha de comando para conversar com a API do cluster: aplicar configurações, listar pods, escalar deployments e diagnosticar problemas.

Qual a diferença entre Deployment e Pod? O Pod é a unidade que roda os containers. O Deployment é uma camada acima que gerencia quantos pods devem existir e como atualizá-los com segurança. Você quase sempre cria Deployments, não Pods soltos.

Conclusão

O Kubernetes é o maestro que rege a orquestra de containers em produção. Com seu modelo declarativo e seu laço de reconciliação contínua, ele mantém suas aplicações no ar, as escala conforme a demanda e as atualiza sem derrubar o serviço. Entendendo os conceitos de pod, node, cluster, deployment e service — e sabendo que o control plane decide e os worker nodes executam — você já tem o mapa para navegar nesse ecossistema. Lembre-se, porém, de que poder vem com complexidade: adote o Kubernetes quando a escala justificar, considere uma versão gerenciada para reduzir o fardo operacional e comece descrevendo um pequeno deployment para sentir na prática como o estado desejado vira realidade.

Referências