Entendendo na Prática: o que e Kubernetes

O que e Kubernetes?

E a plataforma de orquestração de containers mais adotada no mundo.

Kubernetes, também chamado de K8s, e um sistema de código aberto criado pelo Google para automatizar o deploy, o scaling e a operação de aplicações em containers. Quando você tem dezenas ou centenas de containers rodando em produção, coordenar tudo manualmente e impraticável. Kubernetes assume esse papel: ele decide onde cada container roda, reinicia os que falham, distribui o tráfego e escala automaticamente conforme a demanda. Lancado como projeto open source em 2014, hoje e mantido pela Cloud Native Computing Foundation e adotado por praticamente todas as grandes empresas de tecnologia. Entender Kubernetes e entender como software moderno roda em produção em escala.

O problema que Kubernetes resolve

Orquestrar containers manualmente não escala para produção.

Docker resolve o problema de empacotar e rodar uma aplicação em um container. Mas quando você precisa de dez instâncias do mesmo serviço, distribuídas em cinco máquinas diferentes, com failover automático e atualizações sem downtime, o Docker sozinho não e suficiente. Antes do Kubernetes, equipes precisavam de scripts complexos e processos manuais para gerenciar isso. Kubernetes automatiza toda essa orquestração. Ele conhece o estado desejado do sistema e trabalha continuamente para manter esse estado, independentemente de falhas de hardware, picos de tráfego ou atualizações de versão. Isso transforma a operação de sistemas distribuídos de um problema manual em um processo declarativo e automatizado.

Arquitetura do Kubernetes

O cluster tem dois papeis principais: control plane e worker nodes.

Um cluster Kubernetes e composto por dois tipos de máquinas. O control plane e o cerebro do cluster: ele contem o API Server (ponto de entrada para todos os comandos), o etcd (banco de dados distribuído que armazena o estado do cluster), o Scheduler (decide em qual node cada Pod vai rodar) e o Controller Manager (monitora o estado atual e age para alcancar o estado desejado). Os worker nodes são as máquinas que de fato executam as cargas de trabalho. Cada node tem o kubelet (agente que se comunica com o control plane), o kube-proxy (gerência regras de rede) e o container runtime (Docker, containerd ou CRI-O). Essa separação permite que o cluster cresça adicionando nodes sem alterar o control plane.

Pods e Deployments

Pod e a menor unidade. Deployment gerência o ciclo de vida dos Pods.

No Kubernetes, a menor unidade deployável não e um container isolado, mas um Pod. Um Pod encapsula um ou mais containers que compartilham a mesma rede e o mesmo armazenamento local. Na prática, a maioria dos Pods tem um único container. Você raramente cria Pods diretamente, pois se o Pod falhar, ele não e recriado automaticamente. Para isso existe o Deployment: um recurso que declara quantas réplicas de um Pod devem estar rodando e como atualiza-las. Quando você faz um kubectl apply com um Deployment, o Kubernetes garante que o número certo de réplicas esteja sempre ativo, faz rolling updates sem downtime e permite rollback instantaneo para a versão anterior caso algo dê errado.

Services e Ingress

Services expõem Pods internamente. Ingress gerência o tráfego externo.

Pods tem IPs dinâmicos, quando um Pod morre e e recriado, o IP muda. Um Service resolve isso criando um endpoint estável para acessar um conjunto de Pods. Existem tres tipos principais: ClusterIP (acesso apenas dentro do cluster), NodePort (expõe uma porta em cada node) e LoadBalancer (cria um load balancer externo, tipicamente em cloud providers). Para gerenciar tráfego HTTP externo com regras de roteamento, TLS e virtual hosts, existe o Ingress. Um Ingress Controller (como NGINX ou Traefik) interpreta as regras definidas nos objetos Ingress e roteia requisições para os Services corretos. Juntos, Services e Ingress formam a camada de rede do Kubernetes.

ConfigMaps e Secrets

Configurações e credenciais ficam fora da imagem do container.

Uma boa prática em containers e separar o código da configuração. No Kubernetes, ConfigMaps armazenam dados de configuração não sensíveis, como variáveis de ambiente, arquivos de configuração e parametros da aplicação. Secrets armazenam dados sensíveis, como senhas, tokens e certificados, codificados em base64 e com controle de acesso mais restrito. Tanto ConfigMaps quanto Secrets podem ser montados como variáveis de ambiente ou como volumes dentro dos Pods. Isso permite que a mesma imagem Docker seja usada em desenvolvimento, staging e produção, com configurações diferentes injetadas pelo Kubernetes em cada ambiente, sem a necessidade de rebuildar a imagem para cada mudanca de configuração.

Auto-scaling horizontal

Kubernetes escala réplicas automaticamente baseado em métricas.

O Horizontal Pod Autoscaler (HPA) monitora métricas como uso de CPU e memória e ajusta automaticamente o número de réplicas de um Deployment. Se o tráfego aumenta e a CPU passa de 70%, o HPA adiciona réplicas. Quando o tráfego cai, remove réplicas para economizar recursos. Além das métricas padrão, o HPA pode ser configurado para escalar baseado em métricas customizadas, como número de mensagens em uma fila ou latência de requisições. O Cluster Autoscaler complementa o HPA adicionando ou removendo nodes do cluster conforme necessário. Essa combinação permite que sistemas no Kubernetes se adaptem a váriações de carga sem intervenção manual, reduzindo custo em períodos de baixo tráfego e mantendo performance em picos.

Exemplo prático em produção

Como uma API com banco de dados roda em Kubernetes.

Imagine uma API REST com banco de dados PostgreSQL. No Kubernetes, a API vira um Deployment com tres réplicas, um Service do tipo ClusterIP para acesso interno e um Ingress que roteia requisições de api.empresa.com para esse Service. O PostgreSQL vira um StatefulSet (para workloads com estado persistente) com um PersistentVolumeClaim para armazenar os dados. As credenciais do banco ficam em um Secret injetado como variável de ambiente na API. Um HPA monitora a CPU da API e escala de tres para dez réplicas durante picos. Um ConfigMap define o nível de log e o timeout de conexão. Todo o estado desejado do sistema e declarado em arquivos YAML versionados no git, permitindo reprodução idêntica em qualquer cluster.

Quando Kubernetes e exagero

Para projetos pequenos, a complexidade do K8s não compensa.

Kubernetes resolve problemas de escala e resiliência em produção, mas traz uma curva de aprendizado e complexidade operacional significativas. Para um projeto com um ou dois serviços, poucos usuários e equipe pequena, o custo de manter um cluster Kubernetes raramente se justifica. Alternativas como Docker Compose, Railway, Render, Fly.io ou um simples servidor VPS com Docker são mais rápidas de configurar e mais baratas de operar. O ponto de inflexão geralmente ocorre quando a equipe tem múltiplos serviços interdependentes, precisa de zero-downtime deploys com frequência, ou quando o tráfego tem váriação significativa que exige scaling automático. Avalie a complexidade real do problema antes de adotar Kubernetes.

Resumo final

Kubernetes e a base da infraestrutura moderna em escala.

Kubernetes transformou como sistemas distribuídos são operados em produção. Com conceitos como Pods, Deployments, Services, ConfigMaps e HPA, ele automatiza tarefas que antes exigiam scripts complexos e operação manual. O modelo declarativo, onde você descreve o estado desejado e o Kubernetes trabalha para alcanca-lo, e uma das maiores inovações em operações de software. Não e a escolha certa para todo projeto, mas para sistemas que precisam de escala, resiliência e deploys continuos, e praticamente o padrão da industria. Ferramentas como Helm facilitam o empacotamento e a distribuição de aplicações Kubernetes. Aprender K8s e investir na habilidade mais demandada em engenhária de plataforma hoje.