En Kubernetes, los Workload Objects (objetos de carga de trabajo) son los recursos que se encargan de gestionar y ejecutar tus aplicaciones dentro del clúster. Estos objetos definen cómo se crean, escalan y mantienen los Pods — la unidad mínima de ejecución en Kubernetes.

En lugar de crear Pods directamente, lo recomendado es usar estos objetos de mayor nivel que proporcionan capacidades como auto-recuperación, escalado, actualizaciones progresivas y más.

Los principales Workload Objects

1. Pod

El Pod es la unidad más pequeña y básica en Kubernetes. Representa uno o más contenedores que comparten red y almacenamiento.

• Cada Pod tiene su propia dirección IP
• Los contenedores dentro de un Pod comparten el mismo espacio de red (localhost)
• Generalmente no se crean Pods directamente en producción, sino a través de otros Workload Objects

apiVersion: v1
kind: Pod
metadata:
  name: mi-app
spec:
  containers:
    - name: app
      image: nginx:latest
      ports:
        - containerPort: 80

2. Deployment

El Deployment es el objeto más utilizado. Gestiona un conjunto de Pods idénticos (réplicas) y permite actualizaciones declarativas.

¿Para qué sirve?

• Mantener un número deseado de réplicas de tu aplicación
• Realizar rolling updates (actualizaciones sin downtime)
• Hacer rollbacks a versiones anteriores
• Escalar horizontal y automáticamente

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mi-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: mi-app
  template:
    metadata:
      labels:
        app: mi-app
    spec:
      containers:
        - name: app
          image: mi-imagen:v1
          ports:
            - containerPort: 80

3. ReplicaSet

El ReplicaSet garantiza que un número específico de réplicas de un Pod esté corriendo en todo momento.

¿Para qué sirve?

• Mantener la cantidad deseada de Pods activos
• Si un Pod falla, el ReplicaSet crea uno nuevo automáticamente

Nota: En la práctica, no se suelen crear ReplicaSets directamente. Los Deployments los gestionan de forma automática.

4. StatefulSet

El StatefulSet es similar a un Deployment, pero está diseñado para aplicaciones con estado (stateful) que necesitan identidad persistente y almacenamiento estable.

¿Para qué sirve?

• Bases de datos (MySQL, PostgreSQL, MongoDB)
• Sistemas de mensajería (Kafka, RabbitMQ)
• Aplicaciones que necesitan nombres de red estables y predecibles
• Almacenamiento persistente vinculado a cada Pod

Características clave:

• Cada Pod tiene un nombre único y ordenado (pod-0, pod-1, pod-2)
• Se crean y eliminan en orden secuencial
• Cada Pod puede tener su propio PersistentVolumeClaim

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mi-db
spec:
  serviceName: "mi-db"
  replicas: 3
  selector:
    matchLabels:
      app: mi-db
  template:
    metadata:
      labels:
        app: mi-db
    spec:
      containers:
        - name: postgres
          image: postgres:15
          volumeMounts:
            - name: data
              mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 10Gi

5. DaemonSet

El DaemonSet asegura que una copia de un Pod se ejecute en todos (o algunos) nodos del clúster.

¿Para qué sirve?

• Agentes de monitoreo (Prometheus Node Exporter, Datadog)
• Agentes de logging (Fluentd, Filebeat)
• Herramientas de red (kube-proxy, CNI plugins)
• Agentes de seguridad

Cuando se agrega un nuevo nodo al clúster, el DaemonSet automáticamente despliega el Pod en ese nodo.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: agente-monitoreo
spec:
  selector:
    matchLabels:
      app: monitoreo
  template:
    metadata:
      labels:
        app: monitoreo
    spec:
      containers:
        - name: node-exporter
          image: prom/node-exporter:latest
          ports:
            - containerPort: 9100

6. Job

El Job ejecuta uno o más Pods hasta que se completen exitosamente. A diferencia de un Deployment, un Job no mantiene los Pods corriendo indefinidamente.

¿Para qué sirve?

• Migraciones de base de datos
• Procesamiento batch de datos
• Tareas de respaldo (backups)
• Cualquier tarea que deba ejecutarse una vez y terminar

apiVersion: batch/v1
kind: Job
metadata:
  name: migracion-db
spec:
  template:
    spec:
      containers:
        - name: migrar
          image: mi-app:latest
          command: ["python", "manage.py", "migrate"]
      restartPolicy: Never
  backoffLimit: 3

7. CronJob

El CronJob crea Jobs de forma programada, siguiendo la sintaxis cron de Linux.

¿Para qué sirve?

• Backups programados
• Envío de reportes periódicos
• Limpieza de datos temporales
• Tareas de mantenimiento recurrentes

apiVersion: batch/v1
kind: CronJob
metadata:
  name: backup-diario
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: backup
              image: mi-backup:latest
              command: ["./backup.sh"]
          restartPolicy: OnFailure

Resumen

Elegir el Workload Object correcto es clave para diseñar aplicaciones robustas y eficientes en Kubernetes. Cada uno tiene su propósito y entender cuándo usar cada tipo te ahorrará muchos dolores de cabeza en producción.