CronJobs

Autopilot Estándar

---

CronJobs está disponible para el público general (GA) en las versiones 1.21 y posteriores de Google Kubernetes Engine (GKE). En este documento, se explica cómo ejecutar CronJobs en GKE. CronJobs es una característica integrada de Kubernetes. Para obtener más detalles, consulta la documentación de Kubernetes sobre CronJobs.

Descripción general

CronJobs crea trabajos de Kubernetes según un programa recurrente. CronJobs te permite automatizar tareas normales como crear copias de seguridad, crear informes, enviar correos electrónicos o tareas de limpieza.

Los CronJobs se crean, administran, escalan y borran de la misma manera que los trabajos. La cantidad exacta de objetos de trabajo creados depende de varios factores. Para obtener más información, consulta Limitaciones de CronJob.

Para obtener más información sobre estos objetos, consulta Ejecuta un trabajo.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

• Habilita la API de Kubernetes Engine de Google.
Habilitar la API de Kubernetes Engine de Google
• Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.
  Nota: Para las instalaciones de gcloud CLI existentes, asegúrate de configurar las propiedades compute/region y compute/zone. Cuando configuras las ubicaciones predeterminadas, puedes evitar errores en la CLI de gcloud como el siguiente: One of [--zone, --region] must be supplied: Please specify location.

Crea un CronJob

Puedes crear un CronJob mediante un archivo de manifiesto. Por ejemplo, en el siguiente manifiesto YAML, se imprime la hora actual y una string una vez por minuto, mientras se conservan los valores predeterminados de los parámetros de CronJob:

# cronjob.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  concurrencyPolicy: Allow
  startingDeadlineSeconds: 100
  suspend: false
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo "Hello, World!"
          restartPolicy: OnFailure

Nota: Si tu clúster ejecuta versiones de GKE anteriores a la versión 1.21, especifica batch/v1beta1 en el campo apiVersion.

Para crear este CronJob, guarda el manifiesto YAML en un archivo y aplícalo al clúster:

kubectl apply -f PATH_TO_FILE

Reemplaza PATH_TO_FILE por la ruta de acceso al manifiesto YAML.

Configura un CronJob

Puedes especificar los siguientes parámetros cuando creas un CronJob:

• Cuándo se ejecuta CronJob
• Qué hace CronJob
• La fecha límite para el inicio del CronJob
• Si se permiten trabajos simultáneos para el CronJob.
• Si se suspenden trabajos nuevos
• Cuántas ejecuciones guarda el CronJob en su Historial

Especifica cuándo se ejecuta CronJob

El campo spec.schedule define cuándo y con qué frecuencia se ejecuta CronJob, mediante el formato crontab estándar de Unix. Todos los horarios de CronJob están en UTC. Existen 5 campos, que están separados por espacios. Estos campos representan la siguiente información:

1. Minutos (entre 0 y 59)
2. Horas (entre 0 y 23)
3. Día del mes (entre 1 y 31)
4. Mes (entre 1 y 12)
5. Día de la semana (entre 0 y 6 a partir del domingo)

Puedes usar los siguientes caracteres especiales en cualquiera de los campos spec.schedule:

• ? es un valor comodín que coincide con un solo carácter.
• * es un valor comodín que coincide con cero o más caracteres.
• / te permite especificar un intervalo para un campo. Por ejemplo, si el primer campo (el campo minutos) tiene un valor de */5, significa “cada 5 minutos”. Si el quinto campo (el campo día de la semana) se establece en 0/5, significa “cada quinto domingo”.

Especifica qué ejecuta CronJob

spec.jobTemplate describe lo que hace CronJob, incluidas sus imágenes de contenedor, los comandos que ejecutan los contenedores y la política de reinicio de CronJob. Para obtener más detalles sobre qué incluir en spec.jobTemplate, consulta la documentación de CronJob de Kubernetes.

Especifica una fecha límite

El campo startingDeadlineSeconds opcional indica la cantidad máxima de segundos que CronJob puede tardar en iniciarse en caso de que no cumpla con su hora programada por alguna razón. Los CronJobs que no se cumplen se consideran errores.

Para especificar una fecha límite, debes agregar el valor startingDeadlineSeconds al campo spec de CronJob en el archivo de manifiesto. Por ejemplo, en el manifiesto siguiente, se especifica que el CronJob tiene 100 segundos para comenzar:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  startingDeadlineSeconds: 100
  jobTemplate:
    spec:
    ...

Nota: Si especificas un valor vacío para el campo startingDeadlineSeconds, CronJob nunca agotará el tiempo de espera. Esto podría generar que el mismo CronJob se ejecute varias veces de manera simultánea. Para evitar esto, especifica una política de simultaneidad.

Especifica una política de simultaneidad

En el campo opcional spec.concurrencyPolicy, se especifica cómo tratar las ejecuciones simultáneas de un trabajo creado mediante el controlador de CronJob. Si no estableces un valor, se permiten múltiples trabajos simultáneos de forma predeterminada.

concurrencyPolicy acepta los siguientes valores:

Valor	Significado
Allow	Se permiten trabajos simultáneos. Esta es la opción predeterminada.
Forbid	No se permiten trabajos simultáneos, y los nuevos no pueden comenzar hasta que los anteriores se hayan completado o se haya agotado el tiempo de espera.
Replace	No se permiten trabajos simultáneos, y los anteriores se cancelan en favor de los nuevos.

Suspende las ejecuciones posteriores

En el campo opcional spec.suspend, cuando se establece en true, evita que se ejecuten trabajos nuevos, pero permite que finalicen las ejecuciones actuales.

Especifica los límites del historial

Un CronJob crea un pod cada vez que se ejecuta. Si deseas ver el estado de rescisión de las ejecuciones recientes de CronJob, así como los registros de un pod individual, puedes consultar la sección ver el historial de CronJob.

Puedes configurar la cantidad de ejecuciones de CronJob fallidas y correctas que se guardan si especificas los valores para spec.successfulJobsHistoryLimit y spec.failedJobsHistoryLimit. Según la configuración predeterminada, se establece successfulJobsHistoryLimit en 3 y failedJobsHistoryLimit en 1.

Por ejemplo, en el siguiente manifiesto, se indica a GKE que guarde un máximo de cinco ejecuciones correctas de CronJob y un máximo de 10 ejecuciones fallidas de CronJob:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  startingDeadlineSeconds: 100
  successfulJobsHistoryLimit: 5
  failedJobsHistoryLimit: 10
  jobTemplate:
    spec:
    ...

Puedes inhabilitar la retención de historial de ejecución de CronJob exitoso o con errores si configuras el valor respectivo en 0. Inhabilitar la retención del historial puede hacer que la depuración de errores sea más difícil. Por ejemplo, en el siguiente manifiesto se indica a GKE que guarde solo las ejecuciones de CronJob con errores:

kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  startingDeadlineSeconds: 100
  successfulJobsHistoryLimit: 0
  failedJobsHistoryLimit: 10
  jobTemplate:
    spec:
    ...

Inspecciona un CronJob

Para verificar la configuración de un CronJob, usa kubectl describe:

kubectl describe cronjob CRONJOB_NAME

Reemplaza CRONJOB_NAME por el nombre del CronJob que se inspeccionará.

Visualiza el historial de CronJob

Un CronJob se ejecuta dentro de un pod. Según la configuración predeterminada, Kubernetes conserva los registros de pods terminados que representan las últimas tres ejecuciones correctas de un CronJob y el último trabajo con errores. Puedes cambiar o inhabilitar estos valores predeterminados si cambias los límites del historial de CronJob.

Primero, debes enumerar todos los pods para ver el historial de un CronJob. Los CronJobs completados se muestran con un estado Completed y los trabajos con errores tienen un estado RunContainerError, CrashLoopBackOff o, además, otro estado que indica un error.

Nota: Es posible que veas más entradas de las que esperabas. El historial de CronJob está sujeto a la recolección periódica de elementos no utilizados. Por ejemplo, en el resultado siguiente, se muestran cuatro instancias de CronJob hello.

NAME                                READY   STATUS              RESTARTS   AGE
hello-1556555640-9bc5r              0/1     Completed           0          3m6s
hello-1556555700-cm6wk              0/1     Completed           0          2m6s
hello-1556555760-62wf5              0/1     Completed           0          66s
hello-1556555820-rl8kl              0/1     Completed           0          5s
hello-failed-1556555820-wrvt2       0/1     RunContainerError   1          5s

Puedes hacer que un trabajo falle a propósito si modificas el manifiesto de ejemplo en Crea un CronJob. Cambia el campo args en spec.containers a un comando o ruta de acceso no válidos que no existan y cambia el valor metadata.name a uno que indique que estás probando errores.

Para ver los registros de un CronJob específico, ejecuta el siguiente comando:

kubectl logs POD_NAME

Reemplaza POD_NAME con el nombre del pod que deseas inspeccionar.

El resultado es similar al siguiente:

container_linux.go:247: starting container process caused
"exec: \"/in/sh\": stat /in/sh: no such file or directory"

Borra un CronJob

Para borrar un CronJob, ejecuta el comando siguiente:

kubectl delete cronjob CRONJOB_NAME

Cuando borras un CronJob, el recolector de elementos no utilizados de Kubernetes borra los trabajos asociados y evita que se inicien nuevos.

¿Qué sigue?

• Lee la documentación de Kubernetes para obtener información sobre CronJobs.
• Obtén más información sobre cómo ejecutar un trabajo único.