manifestos-kubernetes
Manifestos Kubernetes
Manifesto ruim quase nunca é YAML inválido. O kubectl apply aceita sem reclamar um Deployment sem recurso declarado, com as duas probes apontando para o mesmo endpoint, com a senha do banco em texto puro, rodando latest, exposto por um LoadBalancer que ninguém pediu. Tudo isso sobe, fica Running, e o problema aparece semanas depois — no nó que despejou o pod errado sob pressão, no restart em cascata quando o banco ficou lento, no rollback que não tinha para onde voltar.
As seis regras abaixo existem para tornar esses erros difíceis de cometer. Elas valem para qualquer aplicação e qualquer cluster.
As seis regras
| Regra | O que isso descarta na prática |
|---|---|
| 1. Requests e limits sempre declarados | container sem bloco resources, limits sem requests, QoS BestEffort por esquecimento |
| 2. Liveness e readiness separadas | as duas probes no mesmo endpoint, liveness checando banco, initialDelaySeconds inflado para disfarçar boot lento |
| 3. Env via ConfigMap ou Secret | env: [{name: DB_HOST, value: postgres}] no Deployment, senha em texto puro no YAML versionado |
| 4. Imagem com tag fixada | image: app:latest, app:prod, app:main, imagePullPolicy: Always para compensar tag móvel |
| 5. Service coerente com a exposição | LoadBalancer em serviço interno, NodePort fora de lab, targetPort numérico duplicando a porta |
| 6. Labels e namespace no padrão | objeto sem namespace explícito, label inventada por manifesto, selector com label demais |
Quando o pedido do usuário conflitar com uma delas (por exemplo: "deixa sem limit que é só dev" ou "usa latest mesmo"), não execute em silêncio nem recuse: diga em uma frase o que a regra manda e por quê, entregue seguindo a regra, e deixe claro o que foi feito diferente do pedido. Se o usuário reafirmar, é decisão dele — siga.