Un cluster sin organización se convierte en un condominio sin reglas: cualquiera ocupa el salón, nadie sabe de quién es cada puerta y, en el día del mantenimiento, nadie consigue evacuar el edificio sin derribar a todo el mundo.

Namespaces, labels, quotas y PDB son las reglas del condominio. No son burocracia: son lo que permite operar con previsibilidad.

Sello del curso: probado en Kubernetes 1.35.

Namespaces

Namespace es un alcance lógico. Separa nombres, RBAC, quotas y políticas de red. No es aislamiento de seguridad por sí solo — pero es la base para organizar.

Namespaces que ya tienes:

• default: donde todo cae si no eliges.
• kube-system: componentes del cluster.
• kube-public, kube-node-lease: uso interno.
• monitoring, ingress-nginx, argocd, velero: operadores y plataforma.

Para una aplicación, crea algo como:

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

Cuidado: kubectl delete namespace borra todo lo que hay dentro. Trata el namespace como unidad de ciclo de vida.

Labels, annotations y selectors

Labels son para seleccionar. Annotations son para metadatos que no seleccionan (dueño, enlace, 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

Los selectors usan labels:

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

El error clásico: el selector del Deployment no coincide con template.metadata.labels. El Deployment no encuentra los pods y el rollout se comporta de forma extraña.

ResourceQuota: el techo del namespace

Sin quota, un equipo puede crear 200 pods y derribar el cluster. Con 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"

Verifica:

kubectl -n portal describe resourcequota portal-quota

Si la suma de los pods supera la quota, los nuevos pods son rechazados. Eso es bueno: falla temprano, en el namespace, en lugar de derribar el nodo.

LimitRange: el patrón de cada pod

La quota es el techo del namespace. LimitRange define defaults y límites 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

Sin requests/limits, el pod es BestEffort y es el primero en ser desalojado bajo presión. Con requests/limits iguales, se convierte en Guaranteed. El término medio es Burstable.

QoS	Cuándo ocurre	Riesgo
Guaranteed	requests = limits para todos los containers	menor riesgo de eviction
Burstable	requests < limits	riesgo moderado
BestEffort	sin requests/limits	primero en caer

PDB: protegiendo mantenimientos

PodDisruptionBudget limita las disrupciones voluntarias (drain, eviction), no fallos de nodo.

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

Con 3 réplicas y minAvailable: 2, el drain puede eliminar 1 a la vez. Con minAvailable: 3, el drain se bloquea para siempre — y descubres esto en el peor momento.

Alternativa:

spec:
  maxUnavailable: 1

maxUnavailable suele ser más fácil de razonar cuando escalas.

Lo que el PDB no hace

• No impide kubectl delete pod (no es eviction).
• No impide fallo de nodo (no es disrupción voluntaria).
• No crea réplicas.
• No salva una aplicación con 1 réplica: minAvailable: 1 bloquea cualquier drain.

Laboratorio

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

Aplica quota/limitrange (arriba) e intenta crear 40 pods:

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

Crea el PDB y simula un drain en un nodo de laboratorio:

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

Con minAvailable: 2 y 3 réplicas en nodos diferentes, evacua una a la vez. Si las 3 están en el mismo nodo, el drain se bloquea — y la lección es: PDB sin anti-affinity es media protección.

Errores comunes

Síntoma	Causa
exceeded quota	la suma de requests/limits superó el techo
Pod rechazado por LimitRange	request por debajo del min o por encima del max
Drain bloqueado	PDB minAvailable igual al número de réplicas
Eviction inesperada	pod BestEffort bajo presión
Selector no encuentra pods	labels diferentes entre selector y template

Checklist

• [ ] Namespace dedicado por aplicación/entorno.
• [ ] Labels estandarizados (app.kubernetes.io/*).
• [ ] ResourceQuota y LimitRange definidos.
• [ ] Requests/limits en todos los containers.
• [ ] PDB en las cargas críticas.
• [ ] Anti-affinity/topology spread para que el PDB tenga sentido.
• [ ] Sé que PDB no protege contra fallo de nodo.

Glosario

• namespace: alcance lógico de nombres y políticas.
• label: par clave/valor usado por selectors.
• annotation: metadato no seleccionable.
• ResourceQuota: techo agregado del namespace.
• LimitRange: defaults/límites por pod.
• PDB: presupuesto de disrupciones voluntarias.

Próximo

Ahora que el cluster está organizado, vamos a elegir el workload correcto: Deployment, StatefulSet, DaemonSet, Job o CronJob.

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