Infraestrutura & DevOps

Kubernetes na prática: deploy, escalonamento e self-healing para aplicações em produção

Kubernetes na prática: deploy, escalonamento e self-healing para aplicações em produção

Kubernetes (K8s) saiu da categoria “infraestrutura para big techs” e entrou no dia a dia de times de 5-50 pessoas. Serviços managed como GKE, EKS e AKS removeram a complexidade de operar o control plane. O que resta é entender os conceitos fundamentais para fazer deploy, escalar e manter aplicações de forma resiliente — e parar de tratar K8s como incubadora de complexidade desnecessária.

Abstrações fundamentais: Pod, Deployment, Service

Pod é a menor unidade deployável no Kubernetes — um ou mais containers que compartilham rede e storage. Na prática, você raramente cria Pods diretamente. Deployment gerencia um conjunto de Pods idênticos: define a imagem, replicas, recursos, e política de atualização. Se um Pod morrer, o Deployment cria um substituto automaticamente (self-healing). Se você atualizar a imagem, o Deployment faz rolling update — substitui Pods um por um para zero downtime. kubectl rollout undo deployment/app reverte para a versão anterior instantaneamente.

Service expõe um conjunto de Pods como um endpoint estável de rede. Pods têm IPs efêmeros que mudam a cada restart — o Service usa um selector de labels para descobrir dinamicamente quais Pods pertencem a ele e fazer load balancing entre eles. ClusterIP (interno ao cluster), NodePort (expõe em porta fixa de cada node), e LoadBalancer (provisiona um load balancer na cloud) são os tipos principais. Para HTTP, Ingress é preferível ao LoadBalancer direto: um único Ingress controller (nginx, traefik) roteia para múltiplos Services baseado em host/path, e certifica TLS automaticamente via cert-manager + Let’s Encrypt.

Configuração e segredos

ConfigMaps armazenam configuração não-sensível (URLs, feature flags, parâmetros de comportamento) como pares chave-valor ou arquivos. Secrets armazenam dados sensíveis codificados em base64 — note que base64 não é criptografia, é encoding. Secrets em K8s vanilla não são criptografados em repouso por padrão; habilite encryption at rest no etcd ou use soluções externas como HashiCorp Vault com operator/sidecar injection para secrets realmente seguros. External Secrets Operator sincroniza segredos de AWS Secrets Manager, GCP Secret Manager ou Vault para Kubernetes Secrets nativos — a fonte da verdade fica fora do cluster, com audit log e rotação automática.

Environment variables via ConfigMap e Secret são a forma mais comum de injetar configuração nos containers. Para configuração hierárquica complexa (arquivos de configuração YAML/JSON), monte o ConfigMap como volume no pod — o arquivo fica disponível no filesystem do container como qualquer outro arquivo. Quando o ConfigMap é atualizado, o arquivo montado é atualizado automaticamente (com delay de segundos) sem restart do Pod, útil para feature flags que mudam frequentemente.

Recursos, limites e Horizontal Pod Autoscaler

Sem requests e limits configurados, um Pod pode consumir todos os recursos do nodo e afetar outros workloads. Requests define o que o scheduler garante ao Pod (CPU e memória mínimos), Limits define o máximo permitido. Pod que excede o Memory Limit é killed (OOMKilled) — size os limits com 20-30% de headroom acima do uso típico observado. Requests sub-dimensionados fazem o scheduler colocar mais Pods do que o nodo suporta com segurança — oversub intencional é estratégia válida para workloads com picos não correlacionados.

Horizontal Pod Autoscaler (HPA) escala o número de réplicas de um Deployment baseado em métricas: CPU e memória por padrão, mas Prometheus Adapter permite escalar por qualquer métrica de aplicação (requests por segundo, tamanho de fila, latência). kubectl autoscale deployment app --min=2 --max=20 --cpu-percent=70 configura HPA básico em uma linha. KEDA (Kubernetes Event-Driven Autoscaling) extends isso para qualquer fonte de eventos: escala a zero quando não há demanda, sobe automaticamente em resposta a mensagens em fila, crescimento de tópico Kafka, ou cron schedules.

Observabilidade e debugging

kubectl logs deployment/app --follow acompanha logs em tempo real. Para logs agregados de múltiplas réplicas, você precisa de um stack de logging: Fluent Bit coleta e encaminha logs de todos os containers para Elasticsearch/OpenSearch, Loki, ou serviços managed como Datadog ou CloudWatch. Loki + Grafana é a solução mais leve — Loki indexa apenas metadados dos logs (labels), não o conteúdo, tornando o armazenamento 10x mais barato que Elasticsearch para volumes altos.

kubectl describe pod nome-pod é o melhor amigo na hora de debugar problemas: Events ao final mostram CrashLoopBackOff, ImagePullBackoff, OOMKilled, e Pending (recursos insuficientes). kubectl exec -it pod -- /bin/sh abre um terminal dentro do container para debugging interativo. Para containers que não têm shell, ephemeral containers (kubectl debug) adicionam um container de debug temporário ao Pod sem restart. Distributed tracing com OpenTelemetry instrumentado na aplicação e coletado pelo Jaeger ou Tempo torna visível a latência entre serviços em arquiteturas de microsserviços — indispensável quando um request passa por 5 serviços e você precisa saber qual está lento.

Tem um projeto em mente?

Somos especialistas em transformar ideias em produtos digitais. Apps, sites, automações e IA — vamos construir juntos.

Resposta rápida Orçamento sem compromisso +100 projetos entregues
Compartilhar: