Kubernetes tiene pocos tipos de workload, pero elegir el equivocado cuesta caro. Una base de datos en Deployment incluso se levanta — y luego te enseña, de la manera difícil, por qué StatefulSet existe.

Sello del curso: probado en Kubernetes 1.35.

El mapa

Tipo	Para qué	¿Identidad estable?	¿Storage estable?
Pod	pruebas puntuales	no	no
Deployment	aplicaciones stateless	no	no
StatefulSet	bases de datos, colas, clusters	sí	sí
DaemonSet	un agente por nodo	por nodo	depende
Job	tarea hasta concluir	no	no
CronJob	tarea programada	no	no

Deployment: el estándar para stateless

Un Deployment garantiza réplicas, rollout y rollback. Los pods son descartables e intercambiables.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  revisionHistoryLimit: 5
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: ghcr.io/exemplo/api:1.4.2
          ports:
            - containerPort: 8080

Rollout:

kubectl rollout status deployment/api
kubectl rollout history deployment/api
kubectl rollout undo deployment/api

Precauciones:

• maxSurge/maxUnavailable deben caber en la capacidad de los nodos.
• Probes mal configuradas convierten el rollout en CrashLoopBackOff.
• revisionHistoryLimit evita la acumulación infinita de ReplicaSets.

StatefulSet: la identidad importa

StatefulSet da a cada pod:

• Nombre ordinal (db-0, db-1, db-2).
• Red estable mediante headless Service.
• PVC propio mediante volumeClaimTemplates.
• Orden de creación/eliminación (normalmente secuencial).

apiVersion: v1
kind: Service
metadata:
  name: db-headless
spec:
  clusterIP: None
  selector:
    app: db
  ports:
    - port: 5432
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db-headless
  replicas: 3
  selector:
    matchLabels:
      app: db
  template:
    metadata:
      labels:
        app: db
    spec:
      containers:
        - name: db
          image: postgres:16
          ports:
            - containerPort: 5432
          volumeMounts:
            - name: data
              mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 5Gi

Si eliminas db-1, vuelve con el mismo nombre y el mismo PVC. Es eso lo que permite que una base de datos o un clúster de colas sobreviva.

Precauciones:

• PVC huérfano tras eliminar el StatefulSet (por defecto, el PVC permanece).
• El orden de inicialización puede hacer que el clúster sea lento; algunas bases de datos necesitan un init propio.
• Las actualizaciones requieren una estrategia (RollingUpdate o OnDelete).

DaemonSet: uno por nodo

DaemonSet ejecuta un pod en cada nodo (o en un subconjunto). Es el patrón para:

• CNI (flannel, Cilium).
• Recolección de logs (Fluent Bit).
• Métricas de nodo (node-exporter).
• Agentes de backup (Velero node-agent).

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
spec:
  selector:
    matchLabels:
      app: node-exporter
  template:
    metadata:
      labels:
        app: node-exporter
    spec:
      tolerations:
        - operator: Exists
      containers:
        - name: node-exporter
          image: prom/node-exporter:v1.8.2
          ports:
            - containerPort: 9100

Precaución: taints. Si el nodo tiene taint y el DaemonSet no lo tolera, el pod no se ejecuta — y descubres que el agente de monitoreo no cubre precisamente el nodo problemático.

Job y CronJob: tareas

Job se ejecuta hasta concluir:

apiVersion: batch/v1
kind: Job
metadata:
  name: backup
spec:
  backoffLimit: 3
  completions: 1
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: backup
          image: ghcr.io/exemplo/backup:1.0

CronJob programa:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: backup-diario
spec:
  schedule: "0 2 * * *"
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 3
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: backup
              image: ghcr.io/exemplo/backup:1.0

Precauciones:

• concurrencyPolicy: Forbid evita dos ejecuciones superpuestas.
• backoffLimit alto puede generar reintentos infinitos y ruido.
• Un Job que nunca termina necesita activeDeadlineSeconds.
• CronJob en zona horaria: el clúster se ejecuta en UTC por defecto; ajústalo si la hora importa.

Laboratorio

1. StatefulSet con PVC:

kubectl create ns workloads
kubectl -n workloads apply -f statefulset.yaml
kubectl -n workloads get pods,pvc
kubectl -n workloads delete pod db-1
kubectl -n workloads get pods -w

Observa db-1 volver con el mismo nombre y el mismo PVC.

2. DaemonSet:

kubectl -n workloads apply -f daemonset.yaml
kubectl -n workloads get pods -o wide

3. Job y CronJob:

kubectl -n workloads create job hello --image=busybox:1.36 -- echo hello
kubectl -n workloads logs job/hello
kubectl -n workloads create cronjob hello-cron --image=busybox:1.36 --schedule="*/1 * * * *" -- date

Errores comunes

Síntoma	Causa
StatefulSet Pending	PVC sin storageClass o sin PV
Pods del DaemonSet ausentes en un nodo	taint sin toleration
Job en bucle	backoffLimit alto + error permanente
CronJob superpuesto	concurrencyPolicy: Allow
Deployment no se actualiza	imagen/tag igual o selector incorrecto
PVC no reutilizado	StatefulSet recreado con otro nombre

Lista de verificación

• [ ] Sé si la carga es stateless o stateful.
• [ ] Deployment tiene strategy y probes.
• [ ] StatefulSet tiene headless Service y volumeClaimTemplates.
• [ ] DaemonSet tolera los taints de los nodos.
• [ ] Jobs tienen límite de reintentos y deadline.
• [ ] CronJobs tienen concurrencyPolicy definida.

Glosario

• headless Service: Service sin ClusterIP, usado para DNS estable por pod.
• volumeClaimTemplates: plantilla de PVC por réplica del StatefulSet.
• taint/toleration: regla que aleja/permite pods en los nodos.
• backoffLimit: número de intentos de un Job.
• concurrencyPolicy: si el CronJob puede ejecutarse en paralelo.

Siguiente

Ahora que sabes elegir el workload, vamos a exponer todo con Services, Ingress, DNS y TLS.

Siguiente: Curso Kubernetes 09 — Services, Ingress, DNS y TLS