← Arquitectura interna
KUBERNETES · WORKLOADS

Primitivas de
Aplicación

Pods · Deployments · StatefulSets · Jobs/CronJobs · Estrategias de despliegue

K8S · WORKLOADS
📦 Pod 🚀 Deployment 🗃️ StatefulSet ⏱️ Job/CronJob
01 Jerarquía de objetos — quién gestiona a quién
Cadena de ownership — Deployment → ReplicaSet → Pod → Container
🚀 Deployment
→ gestiona →
📋 ReplicaSet (v1, v2...)
→ gestiona →
📦 Pod × N
→ contiene →
🐳 Container(s)
DEPLOYMENT
Define estrategia de update, historial de versiones y rollback. Tú lo gestionas.
REPLICASET
Mantiene N réplicas del Pod. Lo crea el Deployment automáticamente — no lo edites directo.
POD
Unidad mínima desplegable. Uno o más contenedores que comparten red y volúmenes. Efímero por diseño.
CONTAINER
El proceso Docker real. Los sidecars (Istio, Fluentd) son contenedores adicionales en el mismo Pod.
02 Tipos de workload — cuándo usar cada uno
🚀
WORKLOAD · 01
Deployment — apps stateless
Stateless Self-healing Rolling Update Rollback
El objeto más usado. Para APIs, frontends y microservicios sin estado persistente. Gestiona el historial de ReplicaSets — permite rollback a cualquier versión anterior con un comando.
Úsalo para: APIs REST, GraphQL, frontends, workers sin estado. Cualquier cosa donde los Pods son intercambiables y el estado vive en una DB externa.
No lo uses para: bases de datos, caches persistentes o cualquier app que necesite identidad de Pod estable.
🗃️
WORKLOAD · 02
StatefulSet — apps con estado
Stable identity Ordered deploy PVC per Pod
Como un Deployment pero cada Pod tiene identidad estable: nombre predecible (mysql-0, mysql-1), DNS propio y PVC propio. Los Pods se crean y borran en orden.
Úsalo para: PostgreSQL, MySQL, MongoDB, Redis con persistencia, Elasticsearch, Kafka, ZooKeeper. Cualquier sistema de clustering que necesite saber quién es quién.
Por qué importa el orden: en un cluster de BD, el nodo 0 es el master — debe existir antes que los replicas.
🔲
WORKLOAD · 03
DaemonSet — uno por nodo
Node-level System agent kube-proxy
Garantiza que exactamente un Pod corre en cada Node (o en los Nodes seleccionados). Cuando se añade un Node nuevo, el DaemonSet crea el Pod automáticamente.
Úsalo para: agentes de logging (Fluentd, Filebeat), agentes de monitoreo (Datadog, Prometheus Node Exporter), CNI plugins y kube-proxy mismo. Cualquier cosa que deba vivir en cada máquina del cluster.
⏱️
WORKLOAD · 04
Job / CronJob — tareas finitas
Completions Parallelism Schedule Backoff limit
Job ejecuta Pods hasta que completan con éxito. CronJob crea Jobs según un schedule cron. A diferencia de Deployment, un Job termina — no reinicia los Pods indefinidamente.
Úsalo para: migraciones de DB, reportes nocturnos, backups, procesamiento batch, envío de emails masivos, tareas de limpieza. Configura backoffLimit para controlar reintentos.
03 Estrategias de despliegue — RollingUpdate vs Recreate
● ESTRATEGIA RECOMENDADA
🔄 RollingUpdate (por defecto)
Sustituye los Pods antiguos gradualmente por los nuevos. En ningún momento el servicio está completamente down. Controlas el ritmo con maxSurge y maxUnavailable.
PROGRESIÓN DEL UPDATE → (3 réplicas, maxSurge=1, maxUnavailable=1)
ANTES
v1
v1
v1
PASO 1
v1
v1
💀
v2
PASO 2
v1
💀
v2
v2
FINAL
v2
v2
v2
✅ VENTAJAS
Zero downtime
Rollback inmediato
Tráfico continuo
⚠️ CUIDADO
2 versiones coexisten
DB debe ser compatible
v1 y v2 a la vez
● ESTRATEGIA CON DOWNTIME
💥 Recreate
Borra todos los Pods viejos y luego crea los nuevos. Hay un período de downtime entre ambas fases. Simple pero disruptivo.
PROGRESIÓN DEL UPDATE → (downtime garantizado)
ANTES
v1
v1
v1
DOWN
💀
💀
💀
⚠️ 0 Pods activos
FINAL
v2
v2
v2
✅ CUÁNDO USARLO
Cambios de schema DB
Migraciones disruptivas
Dev/QA sin SLA
❌ EVITAR EN
Producción con SLA
Apps de cara al usuario
Cualquier 24/7
04 Rollback — cómo deshacer un deploy fallido
kubectl — rollout, rollback y gestión de versiones 
# Ver el estado del rollout en curso
kubectl rollout status deployment/my-app

# Ver historial de revisiones (ReplicaSets anteriores)
kubectl rollout history deployment/my-app

# Output esperado:
REVISION  CHANGE-CAUSE
1         kubectl apply --image=nginx:1.23 (initial)
2         kubectl set image deployment/my-app app=nginx:1.24
3         kubectl set image deployment/my-app app=nginx:1.25-broken

# Rollback a la versión anterior (revision 2)
kubectl rollout undo deployment/my-app

# Rollback a una revisión específica
kubectl rollout undo deployment/my-app --to-revision=2

# Escalar réplicas manualmente
kubectl scale deployment/my-app --replicas=5

# Forzar restart de todos los Pods (sin cambiar imagen)
kubectl rollout restart deployment/my-app

# Pausar un rollout para inspeccionarlo
kubectl rollout pause deployment/my-app
kubectl rollout resume deployment/my-app
🔑
Pod — la unidad mínima
Un Pod es efímero. Nunca edites un Pod directamente en producción — edita el Deployment. Los Pods son reemplazables; el Deployment es la fuente de verdad.
🗃️
StatefulSet — identidad estable
El Pod mysql-0 siempre se llama igual, siempre monta el mismo PVC y tiene el mismo DNS. Eso es lo que necesita una BD para funcionar en cluster.
⚠️
RollingUpdate y BD — precaución
Con RollingUpdate, durante el update v1 y v2 corren en paralelo. La DB debe soportar ambos schemas simultáneamente. Usa migraciones backward-compatible (Expand/Contract pattern).
KUBERNETES · WORKLOADS
4 tipos de workload · 2 estrategias · rollback Networking →