Um cluster sem organização vira um condomínio sem regras: qualquer um ocupa o salão, ninguém sabe de quem é cada porta e, no dia da manutenção, ninguém consegue evacuar o prédio sem derrubar todo mundo.

Namespaces, labels, quotas e PDB são as regras do condomínio. Não são burocracia: são o que permite operar com previsibilidade.

Selo do curso: testado em Kubernetes 1.35.

Namespaces

Namespace é um escopo lógico. Ele separa nomes, RBAC, quotas e políticas de rede. Não é isolamento de segurança por si só — mas é a base para organizar.

Namespaces que você já tem:

• default: onde tudo cai se você não escolher.
• kube-system: componentes do cluster.
• kube-public, kube-node-lease: uso interno.
• monitoring, ingress-nginx, argocd, velero: operadores e plataforma.

Para uma aplicação, crie algo como:

kubectl create namespace portal
kubectl config set-context --current --namespace=portal

Cuidado: kubectl delete namespace apaga tudo dentro. Trate namespace como unidade de ciclo de vida.

Labels, annotations e selectors

Labels são para selecionar. Annotations são para metadados que não selecionam (dono, link, changelog, checksum).

Labels recomendados:

metadata:
  labels:
    app.kubernetes.io/name: portal
    app.kubernetes.io/instance: prod
    app.kubernetes.io/version: "1.4.2"
    app.kubernetes.io/component: backend
    app.kubernetes.io/part-of: itsm
    app.kubernetes.io/managed-by: helm

Selectors usam labels:

kubectl get pods -l app.kubernetes.io/name=portal
kubectl delete pods -l app.kubernetes.io/component=backend

O erro clássico: selector do Deployment não casa com template.metadata.labels. O Deployment não encontra os pods e o rollout fica estranho.

ResourceQuota: o teto do namespace

Sem quota, um time pode criar 200 pods e derrubar o cluster. Com quota:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: portal-quota
  namespace: portal
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    pods: "30"
    services: "10"
    persistentvolumeclaims: "10"

Verifique:

kubectl -n portal describe resourcequota portal-quota

Se a soma dos pods ultrapassar a quota, novos pods são rejeitados. Isso é bom: falha cedo, no namespace, em vez de derrubar o nó.

LimitRange: o padrão de cada pod

Quota é o teto do namespace. LimitRange define defaults e limites por pod:

apiVersion: v1
kind: LimitRange
metadata:
  name: portal-limits
  namespace: portal
spec:
  limits:
    - type: Container
      default:
        cpu: 200m
        memory: 256Mi
      defaultRequest:
        cpu: 50m
        memory: 64Mi
      max:
        cpu: "2"
        memory: 2Gi
      min:
        cpu: 10m
        memory: 32Mi

Sem requests/limits, o pod é BestEffort e é o primeiro a ser despejado sob pressão. Com requests/limits iguais, vira Guaranteed. O meio-termo é Burstable.

QoS	Quando acontece	Risco
Guaranteed	requests = limits para todos os containers	menor risco de eviction
Burstable	requests < limits	risco moderado
BestEffort	sem requests/limits	primeiro a cair

PDB: protegendo manutenções

PodDisruptionBudget limita desrupções voluntárias (drain, eviction), não falhas de nó.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: portal-backend-pdb
  namespace: portal
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: portal
      app.kubernetes.io/component: backend

Com 3 réplicas e minAvailable: 2, o drain pode remover 1 por vez. Com minAvailable: 3, o drain bloqueia para sempre — e você descobre isso no pior momento.

Alternativa:

spec:
  maxUnavailable: 1

maxUnavailable costuma ser mais fácil de raciocinar quando você escala.

O que o PDB não faz

• Não impede kubectl delete pod (não é eviction).
• Não impede falha de nó (não é desrupção voluntária).
• Não cria réplicas.
• Não salva uma aplicação com 1 réplica: minAvailable: 1 bloqueia qualquer drain.

Laboratório

kubectl create ns demo
kubectl -n demo create deployment web --image=nginx:1.27 --replicas=3
kubectl -n demo get pods -l app=web

Aplique quota/limitrange (acima) e tente criar 40 pods:

kubectl -n demo scale deployment/web --replicas=40
kubectl -n demo get pods
kubectl -n demo describe resourcequota

Crie o PDB e simule um drain em um nó de laboratório:

kubectl drain <worker> --ignore-daemonsets --delete-emptydir-data

Com minAvailable: 2 e 3 réplicas em nós diferentes, ele evacua uma por vez. Se as 3 estiverem no mesmo nó, o drain bloqueia — e a lição é: PDB sem anti-affinity é meia proteção.

Erros comuns

Sintoma	Causa
exceeded quota	soma de requests/limits passou do teto
Pod rejeitado por LimitRange	request abaixo do min ou acima do max
Drain travado	PDB minAvailable igual ao número de réplicas
Eviction inesperada	pod BestEffort sob pressão
Selector não encontra pods	labels diferentes entre selector e template

Checklist

• [ ] Namespace dedicado por aplicação/ambiente.
• [ ] Labels padronizados (app.kubernetes.io/*).
• [ ] ResourceQuota e LimitRange definidos.
• [ ] Requests/limits em todos os containers.
• [ ] PDB nas cargas críticas.
• [ ] Anti-affinity/topology spread para o PDB fazer sentido.
• [ ] Sei que PDB não protege contra falha de nó.

Glossário

• namespace: escopo lógico de nomes e políticas.
• label: par chave/valor usado por selectors.
• annotation: metadado não selecionável.
• ResourceQuota: teto agregado do namespace.
• LimitRange: defaults/limites por pod.
• PDB: orçamento de desrupções voluntárias.

Próximo

Agora que o cluster está organizado, vamos escolher o workload certo: Deployment, StatefulSet, DaemonSet, Job ou CronJob.

Próximo: Curso Kubernetes 08 — Deployments, StatefulSets, DaemonSets e Jobs