O Kubernetes tem fama de montanha, e a fama tem fundamento: a documentação cobre dezenas de objetos. Mas quem opera K8s no dia a dia sabe o segredo: sete conceitos carregam 90% do trabalho, e os outros se aprendem quando aparecem. Este é o mapa desses sete, continuando a série de containers.

Antes de tudo, o modelo mental

Você não dá ordens ao Kubernetes; você declara o estado desejado num YAML, e os controladores trabalham sem parar para a realidade convergir (kubernetes.io). Morreu um container? Ele recria. Sobrou nó? Ele redistribui. É a reconciliação como filosofia de sistema, e explica tudo o que vem abaixo.

1. Pod: a unidade mínima

Um pod é um ou mais containers que vivem e morrem juntos, com rede e armazenamento compartilhados. Na prática do dia a dia: um pod ≈ uma instância da sua aplicação. Você quase nunca cria pods diretamente, e aqui entra o segundo conceito.

2. Deployment: as réplicas e o rollout

O objeto que você mais escreve. Declara qual imagem, quantas réplicas e como atualizar:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  selector: { matchLabels: { app: api } }
  template:
    metadata: { labels: { app: api } }
    spec:
      containers:
        - name: api
          image: registro/api:1.4.2
          resources:
            requests: { cpu: "250m", memory: "256Mi" }
            limits: { memory: "512Mi" }

Trocou a tag da imagem? O Deployment faz rolling update (sobe pods novos, drena os antigos, zero downtime) e guarda histórico para rollout undo. As resources não são burocracia: sem elas, o scheduler aloca às cegas e um pod guloso derruba os vizinhos.

3. Service: o endereço estável

Pods nascem e morrem com IPs novos. O Service dá um nome e IP estáveis que balanceiam para os pods vivos do rótulo: http://api funciona de qualquer pod do cluster, hoje e depois do deploy. É o service discovery resolvido por padrão.

4. Ingress: a porta de entrada

O Service resolve o tráfego interno; o Ingress expõe HTTP(S) para o mundo: roteia app.exemplo.com/api para o service certo, termina TLS, centraliza regras. Um controlador (nginx, traefik, ALB) faz o trabalho; o Ingress é a declaração.

5 e 6. ConfigMap e Secret: a configuração fora da imagem

A mesma imagem promovida entre ambientes exige config injetada: ConfigMap para o que é público (URLs, flags), Secret para credenciais, ambos montados como variáveis ou arquivos. Atenção honesta: Secrets nativos são base64, não criptografia mágica: em produção, some um cofre externo (External Secrets, Vault) como já pregamos.

7. Namespace: as divisórias

Separam times e ambientes dentro do cluster: staging e producao com quotas, permissões (RBAC) e nomes isolados. É a fronteira administrativa que evita o kubectl delete no lugar errado, o pesadelo clássico.

O kit de sobrevivência do kubectl

kubectl get pods -n producao              # o que está rodando?
kubectl describe pod api-7d9f...          # por que esse pod está estranho?
kubectl logs -f deploy/api                # logs em tempo real
kubectl rollout undo deploy/api           # o botão de arrependimento
kubectl exec -it deploy/api -- sh         # entrar para investigar

describe + logs resolvem a maioria das investigações. O resto é observabilidade de verdade, fora do kubectl.

Os erros de iniciante que custam caro

• Sem requests/limits: o cluster viera loteria de recursos.
• latest como tag: deploy irreproduzível e rollback impossível. Tag imutável por build, sempre.
• Configuração aplicada na mão: kubectl apply do laptop é o ClickOps do K8s. Manifests no git, agente aplicando.
• Ignorar probes: sem health checks, o K8s não sabe quem está vivo, e é exatamente o tema do próximo artigo da série.

Estruturar esses fundamentos (manifests, recursos, segredos e a esteira em volta) é o começo de toda adoção de K8s que conduzimos no serviço de DevOps e Deploy.

Travou em algum objeto do seu cluster? Cole o YAML (sem segredos!) na conversa com a IA da Rabelo Digital, aqui no canto da tela, e ela explica e corrige. Sem formulário, sem espera.

---

Leia também

• ECS vs EKS: containers na AWS sem dogma
• Health checks e auto-scaling: o cluster que se cura sozinho
• Docker, Swarm ou Kubernetes: níveis do mesmo jogo