Cuando trabajas con Kubernetes, no todas las aplicaciones necesitan correr 24/7. A veces solo necesitas ejecutar una tarea puntual, como un backup, o programarla para que corra cada cierto tiempo sin consumir recursos en reposo. Para eso existen los Jobs y CronJobs en Kubernetes, dos objetos que extienden las capacidades de tus despliegues con tareas únicas o repetitivas.

Qué son los Jobs y los CronJobs en Kubernetes

Un Job es un objeto pensado para ejecutar una tarea hasta completarla. Un CronJob, en cambio, programa esa tarea para que corra de forma periódica usando una sintaxis tipo cron.

¿Qué es un Job en Kubernetes? Es un objeto que ejecuta uno o varios pods hasta que la tarea se completa con éxito. Sirve para acciones puntuales como migraciones, backups o scripts de mantenimiento.

¿Qué diferencia hay entre un Job y un CronJob? El Job se ejecuta cuando tú lo lanzas. El CronJob lleva un campo schedule que define la periodicidad de ejecución (cada minuto, cada día, lunes y miércoles, etc.).

La jerarquía es importante: un CronJob genera Jobs, y cada Job gestiona los pods que ejecutan la tarea real [01:54].

Cómo preparar la base de datos antes del backup

El ejemplo gira alrededor de un MySQL desplegado como StatefulSet, conectado a un Secret con las credenciales sensibles. Antes de crear el Job, necesitas tres piezas:

• Un Secret (mysql-secret) con root-password, password, user y database codificados en base 64.
• Un StatefulSet con la imagen mysql:8.0, una réplica y variables de entorno apuntando al Secret.
• Un Service headless que expone el puerto 3306 para conectarse desde otros pods.

Una vez aplicado el kubectl apply -f mysql-sts.yaml, puedes entrar al contenedor con kubectl exec -it mysql-0 -- mysql -u root -p usando el root password y crear una tabla simple con un ID entero y un nombre tipo string para tener datos que respaldar [09:30].

Por qué importan los Secrets y los typos en los nombres

Un detalle nada menor: si el Secret se llama mysql-secret pero tu StatefulSet referencia mysql-secrets, el pod queda en CreateContainerConfigError. Lo mismo pasa con el nombre del Service: si tu Job intenta conectarse a mysql-service pero el real es mysql-service-sts, vas a ver un error de host no encontrado en los logs. Por eso conviene trabajar de forma declarativa con YAML antes que con comandos imperativos.

Cómo crear un Job para hacer un backup de MySQL

El archivo backup-job.yaml define un objeto de tipo Job cuyo contenedor ejecuta un mysqldump apuntando al servicio de MySQL. La salida estándar se redirige a un archivo .sql con fecha en el nombre, almacenado en un Persistent Volume montado en el pod.

Los elementos clave del YAML son:

• El comando de inicio: mysqldump -h mysql-service-sts -u $USER -p$PASSWORD $DATABASE > /backup/mysql-backup-$(date).sql.
• La referencia al Secret con las variables de entorno sensibles.
• El PersistentVolumeClaim que separa el almacenamiento del backup del volumen de la base de datos.

Al aplicar kubectl apply -f backup-job.yaml, Kubernetes crea el Job y este genera el pod que ejecuta el mysqldump. El status pasa de Running a Completed cuando termina, marcando completions: 1/1 en pocos segundos [16:40].

¿Cómo verifico que el backup se generó? Entra al nodo con minikube ssh y revisa la carpeta /mnt/mysql-backup. Ahí debe aparecer el archivo .sql con la fecha de ejecución.

Qué hacer cuando un Job no se puede recrear

Kubernetes no permite editar en caliente un Job ya creado. Si necesitas cambiar el template, primero ejecuta kubectl delete job mysql-backup y luego vuelve a aplicar el YAML. Al borrar el Job, el pod asociado también desaparece automáticamente.

Cómo programar tareas repetitivas con un CronJob

El archivo backup-cronjob.yaml introduce el campo schedule, que sigue la sintaxis cron clásica de cinco posiciones: minuto, hora, día del mes, mes, día de la semana.

Con */1 * * * * el CronJob se ejecuta cada minuto. Dentro del CronJob hay un jobTemplate que es prácticamente idéntico al Job anterior: mismo contenedor, mismo mysqldump, mismo PersistentVolumeClaim.

Al aplicar el CronJob y revisar con kubectl get cronjobs, vas a ver columnas como schedule, suspend, active y last schedule, que no existen en los Jobs normales. Cada minuto se crea un nuevo pod, ejecuta el backup y queda en Completed [22:50].

¿Cuál es la sintaxis del schedule en un CronJob? Son cinco campos separados por espacios: minuto, hora, día del mes, mes, día de la semana. Por ejemplo 0 2 * * 1,3,5 ejecuta a las 2 AM los lunes, miércoles y viernes.

En entornos productivos, una frecuencia de cada minuto no tiene sentido. Lo realista sería programar backups diarios o varias veces por semana, según el volumen de cambios de la base.

Para qué casos de uso sirven los Jobs y CronJobs

Más allá de los backups, hay tareas donde estos objetos son la herramienta natural. Algunos ejemplos prácticos:

• Respaldos diarios de bases de datos relacionales o NoSQL.
• Migraciones que deben correr antes o después de un deploy.
• Limpieza de logs acumulados que consumen almacenamiento.
• Reportes automáticos enviados por correo con cierta periodicidad.
• Sincronización de datos entre sistemas externos en horarios de baja carga.

La ventaja es que estos pods son efímeros: nacen, ejecutan la tarea y se destruyen, liberando recursos del clúster.

¿Qué otro caso de uso se te ocurre para los Jobs y los CronJobs en tu propio stack? Déjalo en los comentarios.