Orquestração é o que acontece quando você para de gerenciar containers um por um e começa a declarar o estado que quer — e um sistema garante que esse estado seja mantido, automaticamente, mesmo quando as coisas falham.
O problema de escala que criou a categoria
Com 10 containers, você ainda consegue gerenciar na mão. Você sabe quais estão rodando, pode checar manualmente, restart quando necessário, e se um servidor cair, você migra os containers em alguns minutos.
Com 100 containers em 10 servidores, isso já é insustentável. Com 1.000 containers em 50 servidores — um cenário não incomum em empresas de médio porte com arquitetura de microserviços — a gestão manual é impossível.
Os problemas que aparecem nessa escala:
- Um container trava silenciosamente às 3h. Quem detecta? Quem reinicia?
- Um servidor físico falha. Os 40 containers que estavam nele precisam ser redistribuídos. Para onde? Com base em que critério?
- A demanda dobra em 5 minutos (Black Friday, lançamento de produto). Como subir mais réplicas automaticamente?
- Você precisa atualizar a versão de um serviço. Como fazer sem derrubar o serviço para os usuários?
- Um serviço A precisa chamar o serviço B. Como B sabe o IP de A, se IPs mudam quando containers são recriados?
Orquestração é o conjunto de respostas automáticas a todas essas perguntas.
O que um orquestrador faz
Scheduling: decide em qual servidor cada container vai rodar, com base na capacidade disponível, nas restrições declaradas (affinity, taints) e nas prioridades configuradas. Você não decide onde cada container roda — você declara os requisitos e o scheduler decide.
Health checks: verifica continuamente se cada container está funcionando. Quando um container falha no health check (não responde ao ping, retorna erro 500, fica sem memória), o orquestrador o mata e cria um novo automaticamente.
Escala automática: com base em métricas (CPU, memória, requisições por segundo), o orquestrador aumenta ou diminui o número de réplicas. O HPA (Horizontal Pod Autoscaler) do Kubernetes faz isso por padrão.
Rolling updates: quando você atualiza a versão de uma aplicação, o orquestrador substitui os containers antigos pelos novos de forma gradual — um por vez, ou em percentuais configuráveis — sem tirar o serviço do ar. Se a nova versão tiver problema, ele faz rollback automaticamente.
Service discovery: cada serviço tem um nome DNS interno que resolve para os IPs dos Pods ativos no momento. Quando um Pod é substituído, o DNS é atualizado automaticamente. O serviço A sempre chama B pelo nome, não pelo IP.
Gerenciamento de configuração e segredos: orquestradores injetam variáveis de ambiente, arquivos de configuração e secrets nos containers em runtime, sem que precisem estar hardcoded na imagem.
A batalha dos orquestradores: Docker Swarm, Mesos e Kubernetes
No início da era dos containers (2014–2017), três sistemas competiam:
Docker Swarm: o orquestrador nativo do Docker. Vantagem: configuração simples, curva de aprendizado baixa, integrado ao Docker CLI. Desvantagem: recursos limitados para cenários complexos, sem a extensibilidade do Kubernetes. O Docker descontinuou o Swarm como produto principal e ele perdeu tração rapidamente.
Apache Mesos: orquestrador mais antigo (2009), criado no Twitter para gerenciar dezenas de milhares de servidores. Potente e testado em escala extrema, mas extremamente complexo de operar. Requeria times dedicados só para manter o cluster. A curva de aprendizado afastou a maioria das empresas.
Kubernetes: lançado pelo Google em 2014, baseado no Borg interno. A combinação de patrocínio do Google, adoção rápida pelos principais provedores de cloud e um ecossistema open source vibrante criou uma vantagem competitiva que os outros não conseguiram acompanhar.
Por que Kubernetes venceu de forma definitiva
Adoção pelos provedores de cloud: quando AWS (EKS), Azure (AKS), Google (GKE) e todos os outros grandes provedores lançaram Kubernetes gerenciado, o sinal ficou claro: essa é a aposta do mercado. Empresas que adotaram Docker Swarm ficaram presas em um produto sem futuro.
A CNCF como guardiã neutra: o Google doou o Kubernetes para a Cloud Native Computing Foundation em 2016, tornando-o verdadeiramente independente de qualquer vendedor. Isso reduziu a resistência de empresas que não queriam depender de um único fornecedor.
Extensibilidade: a arquitetura de Kubernetes é aberta a extensões. CRDs (Custom Resource Definitions) permitem que qualquer projeto adicione novos tipos de objetos ao K8s. Isso criou um ecossistema de ferramentas (Istio, ArgoCD, Prometheus, Cert-Manager, etc.) que se tornou tão valioso quanto o K8s em si.
Portabilidade real: você aprende Kubernetes e o conhecimento funciona em EKS, AKS, GKE, Rancher, OpenShift, K3s e qualquer distribuição K8s. Nenhum outro orquestrador ofereceu esse nível de portabilidade.
Volume de contribuidores: Kubernetes é o segundo projeto com mais contribuidores no GitHub (atrás do Linux), o que garante velocidade de desenvolvimento e correção de bugs que nenhum projeto menor consegue acompanhar.
O custo de operar Kubernetes
Ser honesto sobre a complexidade operacional é importante. Kubernetes não é simples de operar em produção:
- O control plane (API Server, etcd, Scheduler, Controller Manager) precisa de alta disponibilidade própria
- Atualizações de versão do cluster são operações de risco que exigem planejamento
- Networking em K8s (CNI plugins, Network Policies, Ingress) tem curva de aprendizado significativa
- Storage persistente para aplicações stateful tem nuances
- Segurança em K8s (RBAC, Pod Security Standards, secrets encryption) exige configuração deliberada
Por isso, Kubernetes gerenciado (EKS, AKS, GKE, ou K8s gerenciado em cloud privada) é a escolha certa para a maioria das empresas — você usa o Kubernetes sem precisar operar o control plane.
Quer Kubernetes gerenciado sem a complexidade de operar o control plane? A Adentro oferece K8s como serviço em cloud privada no Brasil.