Kubernetes: orquestração de containers em escala profissional

O que é Kubernetes e por que ele existe

O problema de gerenciar containers em escala e a solução da Google

Kubernetes (K8s) é um sistema de orquestração de containers open source, originalmente desenvolvido pela Google baseado em sua experiência interna com o sistema Borg, que gerenciava bilhões de containers por semana. Quando uma aplicação cresce além de alguns containers em um único host, surgem desafios complexos: como distribuir containers entre múltiplos servidores? Como reiniciar automaticamente containers que crasharam? Como atualizar a aplicação sem downtime? Como escalar horizontalmente quando a demanda aumenta? Kubernetes resolve todos esses problemas declarativamente — o operador descreve o estado desejado (quero 5 réplicas desta aplicação sempre rodando) e o Kubernetes reconcilia continuamente o estado atual para atingir o estado desejado, reagindo a falhas e mudanças de carga automaticamente.

Pods — a menor unidade do Kubernetes

Por que o Kubernetes não agenda containers individuais

Um Pod é o objeto básico de deploy no Kubernetes — um grupo de um ou mais containers que compartilham o mesmo namespace de rede e podem compartilhar volumes. A maioria dos pods contém um único container de aplicação, mas o padrão sidecar usa um container secundário no mesmo pod para funções auxiliares como coleta de logs (Fluentd), proxy de rede (Envoy) ou sincronização de configuração. Containers no mesmo pod se comunicam via localhost, sem overhead de rede, e iniciam e terminam juntos. Pods são efêmeros por design — eles são criados, reiniciados e destruídos pelo Kubernetes conforme necessário, e nunca devem ser gerenciados diretamente em produção. Deployments, StatefulSets e DaemonSets são os objetos de nível superior que gerenciam pods e garantem as propriedades desejadas de replicação e atualização.

Deployments — gerenciando réplicas e atualizações

Rolling updates, rollback automático e controle preciso de versões

Um Deployment descreve o estado desejado de uma aplicação stateless: qual imagem Docker usar, quantas réplicas manter, variáveis de ambiente, limites de CPU e memória, e estratégia de atualização. Quando a imagem é atualizada (novo deploy), o Deployment executa um rolling update por padrão — cria pods novos gradualmente enquanto termina os antigos, mantendo a aplicação disponível durante a transição. O campo maxUnavailable controla quantos pods podem ficar indisponíveis durante o update; maxSurge controla quantos pods extras podem existir temporariamente. Se os novos pods não passam nos health checks, o Kubernetes para o rollout automaticamente e kubectl rollout undo desfaz para a versão anterior em segundos — um mecanismo de rollback que torna deploys frequentes muito mais seguros.

Services — expondo pods para a rede

Abstração estável sobre pods efêmeros com endereços IP mutáveis

Pods têm endereços IP que mudam a cada reinicialização — um Service cria um endereço IP e nome DNS estáveis que roteiam para o conjunto de pods correspondentes via label selector. ClusterIP (padrão) expõe o serviço apenas dentro do cluster — adequado para comunicação interna entre microsserviços. NodePort expõe o serviço em uma porta de cada node do cluster — útil para debug mas raramente usado em produção. LoadBalancer provisiona um load balancer externo do cloud provider (AWS ELB, GCP Cloud Load Balancing) e é a forma padrão de expor serviços ao tráfego externo em clusters managed. Services implementam balanceamento de carga round-robin entre os pods selecionados, e kube-proxy atualiza as regras de iptables automaticamente quando pods são criados ou destruídos.

Ingress — roteamento de tráfego externo

Um único ponto de entrada para múltiplos serviços com roteamento por path e host

Ingress é um recurso Kubernetes que define regras de roteamento HTTP/HTTPS — qual caminho ou hostname deve ser roteado para qual Service. Sem Ingress, expor 10 microsserviços ao tráfego externo exigiria 10 LoadBalancers separados, com custo e complexidade proporcional. Com Ingress, um único load balancer (o Ingress Controller, como NGINX Ingress ou AWS ALB Ingress) recebe todo o tráfego e roteia para o serviço correto com base nas regras definidas. O Ingress também é o lugar onde TLS termination acontece — o certificado SSL é gerenciado pelo Ingress Controller, e os serviços internos comunicam em HTTP simples. Cert-manager integra com Let's Encrypt para provisionar e renovar certificados TLS automaticamente para todos os hosts definidos nos Ingress.

ConfigMaps e Secrets — configuração externalizada

Separando configuração e credenciais do código da aplicação

ConfigMaps armazenam configuração não sensível em pares chave-valor ou arquivos de configuração — URLs de serviços externos, feature flags, parâmetros de comportamento. Secrets armazenam dados sensíveis como senhas, tokens e certificados, com encoding base64 e controles de acesso mais restritivos. Tanto ConfigMaps quanto Secrets podem ser injetados nos pods como variáveis de ambiente ou montados como arquivos no sistema de arquivos do container, permitindo que o mesmo artefato de imagem Docker rode em desenvolvimento, staging e produção com configurações diferentes sem rebuild. Um detalhe crítico de segurança: Secrets no Kubernetes são apenas base64-encoded por padrão, não criptografados — em produção, use encryption at rest no etcd e considere ferramentas como Sealed Secrets ou HashiCorp Vault para gestão de secrets com criptografia real.

Namespaces e RBAC — isolamento e permissões

Organizando recursos e controlando quem pode fazer o quê no cluster

Namespaces são partições virtuais dentro do cluster Kubernetes — permitem separar recursos de diferentes equipes, ambientes (dev, staging, prod) ou aplicações no mesmo cluster físico, com cotas de recursos e políticas de rede distintas. RBAC (Role-Based Access Control) define quais usuários e service accounts podem executar quais operações em quais recursos: um desenvolvedor pode ter permissão de list e get em pods do namespace de staging mas apenas get no namespace de produção, sem acesso a Secrets. Roles definem permissões dentro de um namespace; ClusterRoles definem permissões em todo o cluster. O princípio do menor privilégio se aplica com total força no Kubernetes — service accounts de aplicações devem ter apenas as permissões mínimas necessárias para suas funções, nunca acesso de cluster-admin.

Probes — liveness, readiness e startup

Como o Kubernetes sabe que seu container está saudável e pronto

Probes são verificações periódicas que o Kubernetes executa em cada container para determinar seu estado de saúde. Liveness probe verifica se o container ainda está funcionando — se falhar repetidamente, o Kubernetes reinicia o container. Readiness probe verifica se o container está pronto para receber tráfego — se falhar, o pod é removido do balanceamento de carga do Service mas não é reiniciado, o que é correto quando uma dependência externa (banco, outro serviço) está temporariamente indisponível. Startup probe é usada para containers que demoram para inicializar — desabilita liveness e readiness temporariamente para dar tempo ao container de completar a inicialização sem ser reiniciado prematuramente. Probes mal configuradas (timeouts muito curtos, thresholds muito baixos) causam reinicializações desnecessárias em produção e devem ser calibradas com dados reais de tempo de inicialização.

Kubernetes em produção — boas práticas e armadilhas

O que separa um cluster funcional de um cluster confiável

Clusters Kubernetes em produção exigem atenção a vários aspectos frequentemente ignorados em ambientes de desenvolvimento. Requests e limits de CPU e memória devem ser definidos para todos os containers — sem limits, um container pode consumir todos os recursos do node e derrubar outros pods. PodDisruptionBudgets garantem que operações de manutenção (upgrade do node, reschedule) não derrubem todos os pods de um deployment simultaneamente. Network Policies restringem a comunicação entre pods e namespaces, implementando microsegmentação de rede. Versionar manifestos YAML com GitOps (ArgoCD, Flux) garante que o estado do cluster é auditável e reproduzível. Monitorar o cluster com kube-state-metrics expõe métricas de estado dos objetos Kubernetes para Prometheus — número de pods pendentes, deployments com réplicas indisponíveis, jobs falhados.

Conclusão — Kubernetes como infraestrutura programável

O padrão da indústria para sistemas que precisam escalar e sobreviver

Kubernetes é complexo, mas essa complexidade é justificada pela riqueza de problemas que ele resolve — scheduling, service discovery, self-healing, rolling updates, escalonamento e gestão de configuração em um sistema coeso e extensível. A curva de aprendizado é íngreme, mas times que dominam Kubernetes ganham capacidade de operar sistemas de qualquer escala com processos repetíveis e auditáveis. Comece com um cluster managed (EKS, GKE, AKS) para eliminar a complexidade de operar o control plane, aprenda os objetos fundamentais progressivamente, e use GitOps para manter o estado do cluster controlado por versionamento. Continue em: Fundamentos obrigatórios antes de produção.