Saltar a contenido

Deployments, DaemonSets, StatefulSets, Jobs y CronJobs

Jobs y CronJobs

1. Jobs (Trabajos de una sola vez)

Un Job crea uno o más Pods y se asegura de que terminen su ejecución con éxito (código de salida 0).

Parámetros Críticos (Lo que evalúan en el examen):

  • restartPolicy: A diferencia de un Deployment (que usa Always), en un Job solo puede ser Never o OnFailure. Si pones Always, el YAML dará error.
  • completions: ¿Cuántos Pods deben terminar la tarea con éxito para que el Job entero se considere completado? (Ej. Si pones 5, el Job lanzará Pods hasta lograr 5 éxitos).
  • parallelism: ¿Cuántos Pods pueden ejecutarse al mismo tiempo? (Ideal para procesar colas de trabajo en paralelo).
  • backoffLimit: El número de reintentos permitidos si el Pod falla antes de marcar todo el Job como Failed (Por defecto es 6).
apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl:5.34.0
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never

2. CronJobs (Trabajos programados)

Piensa en el CronJob como un "controlador de Jobs". Utiliza el formato estándar de cron de Linux para crear un Job de forma automática cada cierto tiempo.

Anatomía de un CronJob: Dentro del YAML de un CronJob, hay una plantilla de un Job (jobTemplate), y dentro de ese Job, hay una plantilla de un Pod (template). Es una "matrioska" de configuraciones.

Parámetros Críticos de Control:

  • schedule: El horario en formato cron: "Minuto Hora DíaMes Mes DíaSemana(0 es Domingo)" (Ej. "0 0 * * *" = Todos los días a medianoche).
  • concurrencyPolicy: ¿Qué pasa si el CronJob debe ejecutarse pero la ejecución anterior aún no ha terminado?
  • Allow (Por defecto): Deja que se ejecuten a la vez.
  • Forbid: No lanza el nuevo Job; se salta este turno.

  • Replace: Mata el Job anterior que está atascado y lanza el nuevo.

  • successfulJobsHistoryLimit / failedJobsHistoryLimit: Cuántos Jobs pasados guarda en el historial para que puedas revisar sus logs. Si lo pones en 0, limpia la basura automáticamente.

  • suspend: Si lo pones en true, pausa el CronJob temporalmente sin tener que borrarlo.

🚀 Tips de Velocidad y Troubleshooting (Modo Examen)

En el examen nunca debes escribir el YAML de un Job o CronJob desde cero. Usa la consola imperativa (y recuerda tu alias k=kubectl):

1. Crear un Job rápidamente:

# Crea un job que hace un 'echo' y termina
kubectl create job mi-job --image=busybox -- echo "Hola Instructor"

2. Crear un CronJob rápidamente:

# Crea un cronjob que corre cada minuto
kubectl create cronjob mi-cronjob --image=busybox --schedule="* * * * *" -- echo "Backup listo"

3. El truco para extraer el YAML (Dry-Run): Si el examen te pide que el Job tenga un backoffLimit de 3 (algo que no se puede hacer directo por comando), generas la base y luego editas:

kubectl create job mi-job --image=busybox --dry-run=client -o yaml -- echo "test" > job.yaml
vi job.yaml
# Agregas 'backoffLimit: 3' bajo la especificación del Job y aplicas.

4. ¿Cómo ver los logs de un CronJob? (Troubleshooting) Un error clásico de novatos es intentar hacer kubectl logs cronjob/mi-cronjob. Eso no funciona. El CronJob no hace el trabajo, lo hace el Pod que creó el Job. Paso correcto:

  1. kubectl get jobs (Para ver el nombre del Job que el CronJob acaba de crear).
  2. kubectl get pods (Para ver el Pod generado por ese Job).
  3. kubectl logs <nombre-del-pod>

Labels, Selectors y Annotations

1. Labels (Etiquetas): El Sistema de Identificación

Las etiquetas son simples pares clave-valor (key: value) que se adjuntan a los objetos (como Pods, Nodos, Deployments).

  • Propósito principal: Identificar, clasificar y agrupar recursos de forma significativa para los usuarios. (Ej. entorno: produccion, capa: frontend).
  • Regla de oro: Los Labels SÍ se utilizan para buscar y filtrar objetos. Tienen impacto directo en el comportamiento de la arquitectura de tu clúster.
  • Restricciones: Tienen reglas de sintaxis estrictas (máximo 63 caracteres, no permiten caracteres especiales complejos).
metadata:
  name: mi-pod-web
  labels:
    app: nginx
    env: produccion
    tier: frontend

2. Selectors (Selectores): El Motor de Búsqueda

Si los Labels son las etiquetas que le pones a las cajas, los Selectors son tu orden al almacén: "Tráeme todas las cajas que digan 'produccion'". Es el mecanismo mediante el cual un objeto de Kubernetes encuentra a otro.

  • El caso clásico: Un Service utiliza un Selector para saber a qué Pods debe enviarle el tráfico web. Un Deployment utiliza un Selector para saber cuántas réplicas de Pods está controlando.

Existen dos tipos de Selectores:

  1. Basados en Igualdad (matchLabels): La etiqueta debe coincidir exactamente.
  2. Basados en Conjuntos (matchExpressions): Permiten lógica avanzada (Ej. Tráeme los pods donde 'env' sea 'prod' O 'dev', pero NO 'test'). Usa operadores como In, NotIn, Exists y DoesNotExist.
# Ejemplo dentro de un Service buscando Pods
spec:
  selector:
    app: nginx  # (Selector de igualdad simple)

3. Annotations (Anotaciones): Las Notas al Margen

Son idénticas a los Labels (pares clave-valor), pero con una diferencia abismal en su propósito: NO se utilizan para identificar ni seleccionar objetos.

  • Propósito principal: Almacenar metadatos informativos o configuraciones especiales para que herramientas externas (o controladores específicos) las lean.
  • Capacidad masiva: Mientras los Labels son cortitos, una Anotación puede almacenar cadenas inmensas de texto (hasta 256 KB), como un bloque JSON entero.
  • Ejemplos de uso diario: Decirle a tu Ingress Controller qué algoritmo de balanceo usar (ej. nginx.ingress.kubernetes.io/rewrite-target: /).
  • Guardar la información de quién actualizó un Deployment (Helm las usa muchísimo).
  • Registrar números de tickets de Jira o correos de los responsables del Pod.

📊 Tabla de Batalla (Memoriza esto para el examen)

Característica Labels (Etiquetas) Annotations (Anotaciones)
¿Para qué sirven? Identificar, agrupar y relacionar objetos. Almacenar metadatos para herramientas de terceros.
¿Se pueden usar para filtrar? SÍ (Con Selectors). NO (Kubernetes las ignora en las búsquedas).
Formato y Capacidad Estricto, corto (max 63 caracteres). Flexible, enorme (hasta 256 KB de datos).
¿Quién las lee? Componentes core (Services, Deployments, NetworkPolicies). Humanos, Helm, Ingress Controllers, Prometehus.

🚀 Tips de Velocidad y Troubleshooting en Terminal (Modo Examen)

En el examen no tienes tiempo de editar YAMLs para tareas simples. Usa estos comandos imperativos:

1. Filtrar recursos (El uso más común del Selector en consola):

kubectl get pods -l env=produccion
kubectl get pods -l "env in (produccion, qa)"

2. Ver las etiquetas de todo rápidamente:

kubectl get pods --show-labels

3. Añadir o cambiar un Label a un Pod que ya está corriendo:

# Añadir etiqueta
kubectl label pods mi-pod-web equipo=ventas

# Sobrescribir una etiqueta existente (¡Clave para troubleshooting!)
kubectl label pods mi-pod-web equipo=marketing --overwrite

4. Añadir una Anotación:

kubectl annotate pods mi-pod-web descripcion="Pod parcheado urgente por vulnerabilidad"

[!TIP] Si alguna vez creas un Service y no logra enviar tráfico a tus Pods (los Endpoints salen vacíos), el 99% de las veces es porque escribiste mal el Selector en el Service o te olvidaste de ponerle el Label correspondiente al Pod. ¡Revisar la ortografía de los Labels es tu primer paso!