Kubernetes na prática: do conceito ao cluster em produção

Kubernetes se tornou o padrão de orquestração de containers — mas a maioria dos times que "odeia K8s" nunca teve um engenheiro sênior para configurá-lo direito. Este guia cobre o que você precisa saber para operar Kubernetes em produção: arquitetura real, componentes críticos, escalabilidade e as diferenças práticas entre EKS, GKE e AKS.

O que é Kubernetes e por que ele importa

Desenvolvido pelo Google com base em décadas de operação interna (o projeto Borg), o Kubernetes é uma plataforma de orquestração de containers de código aberto. Ele automatiza o que antes era feito manualmente: deploy, escalonamento, reinício em falha, balanceamento de carga e gestão de configuração.

O diferencial estratégico é a portabilidade entre clouds. Um cluster K8s roda da mesma forma em AWS, Google Cloud, Azure ou on-premise — o que elimina o lock-in de infraestrutura e é um dos pilares de qualquer estratégia multicloud séria.

Arquitetura: Control Plane e Workers

O Kubernetes é composto por dois tipos de nós que trabalham em conjunto:

Control Plane (cérebro do cluster)

• etcd — banco de dados distribuído chave-valor que persiste todo o estado do cluster. Se o etcd cair sem backup, o cluster morre.
• API Server — ponto central de comunicação. Todo comando kubectl, todo agente interno e todo operador falam com o API Server.
• Controller Manager — garante que o estado desejado (o que você declarou) corresponda ao estado real (o que está rodando).
• Scheduler — decide em qual Worker Node cada Pod será executado, levando em conta recursos disponíveis, afinidades e restrições.

Worker Nodes (onde as aplicações rodam)

• Kubelet — agente que roda em cada Worker, recebe instruções da API e garante que os containers estejam saudáveis.
• Container Runtime — executa os containers (containerd é o padrão atual; Docker foi descontinuado como runtime direto desde o K8s 1.24).
• Kube-Proxy — implementa as regras de rede que permitem que os Services roteem tráfego para os Pods corretos.

Pods, Deployments e ReplicaSets: o ciclo de vida das aplicações

O Pod é a unidade mínima do K8s — um conjunto de containers que compartilham rede e storage. Na prática, você raramente cria Pods diretamente: usa um Deployment.

Um Deployment controla um ReplicaSet, que mantém N cópias do Pod sempre rodando. Se um Pod falha, o ReplicaSet cria outro. Se você faz um deploy de nova versão, o Deployment faz a troca gradual (rolling update) e guarda histórico para rollback imediato em caso de problema.

Escalabilidade automática com HPA

O Horizontal Pod Autoscaler (HPA) monitora métricas (CPU, memória ou métricas customizadas via Prometheus) e aumenta ou diminui o número de réplicas automaticamente. O resultado: a aplicação aguenta picos de tráfego sem intervenção manual — e sem manter servidores ociosos pagando à toa.

Para ambientes on-premise ou cloud, o Cluster Autoscaler vai além: adiciona ou remove Worker Nodes inteiros quando o HPA não consegue mais acomodar os Pods com os nodes existentes.

EKS vs GKE vs AKS: qual managed K8s escolher?

• Amazon EKS — melhor integração com ecossistema AWS (IAM, ALB, RDS, etc.). Control Plane gerenciado pela AWS. Boa escolha se você já tem workloads AWS consolidados.
• Google GKE — o mais maduro tecnicamente (Google criou o K8s). Autopilot mode abstrai totalmente os Worker Nodes. Excelente observabilidade nativa com Cloud Monitoring.
• Azure AKS — integração nativa com Active Directory e ambientes Windows híbridos. Preferível para empresas com legado Microsoft.

A escolha não é "qual o melhor" — é qual se encaixa melhor na sua stack atual. Em uma estratégia multicloud, é possível rodar workloads em EKS e GKE ao mesmo tempo usando GitOps para gerenciar ambos de forma unificada.

O que a LinuxPlace faz diferente

Somos certificados nas três clouds e operamos clusters em EKS, GKE e AKS desde 2018. Nossa equipe não subcontrata: o engenheiro que faz o diagnóstico é quem implementa e documenta. Cada cluster que entregamos inclui runbook, alertas calibrados e pelo menos uma simulação de falha de nó antes do go-live.