Jobs et CronJobs Kubernetes : exécuter des tâches ponctuelles et planifiées

Un Job exécute une tâche jusqu’à sa complétion : migration de base de données, traitement batch, génération de rapport. Un CronJob crée des objets Job selon un planning ; ce sont ensuite ces Jobs qui exécutent les Pods nécessaires.

Contrairement aux Pods gérés par un Deployment qui tournent en continu, les Jobs s’arrêtent une fois leur travail terminé. Kubernetes garantit que la tâche sera complétée, même en cas d’échec temporaire.

Pensez idempotence

Une tâche planifiée ou relancée doit idéalement pouvoir être rejouée sans produire d’effets indésirables. C’est particulièrement important pour les CronJobs et les Jobs avec tentatives multiples.

Prérequis : un cluster Kubernetes avec kubectl configuré.

Ce que vous allez apprendre

• Créer un Job pour une tâche ponctuelle
• Configurer le comportement en cas d’échec (backoffLimit, activeDeadlineSeconds)
• Paralléliser l’exécution avec completions et parallelism
• Planifier des tâches récurrentes avec CronJob
• Maîtriser les paramètres de production (concurrencyPolicy, suspend, timeZone)
• Appliquer les bonnes pratiques pour le nettoyage automatique

Job ou Deployment ?

Ressource	Comportement	Cas d’usage
Deployment	Maintient N Pods en continu	Applications web, API, services
Job	Exécute jusqu’à complétion, puis s’arrête	Migration, backup, traitement batch
CronJob	Crée un Job selon un planning	Tâches planifiées, maintenance

Glissez pour voir

Créer votre premier Job

Un Job crée un Pod, exécute la tâche, et se termine une fois le travail fait :

hello-job.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: hello-job
spec:
  template:
    spec:
      containers:
      - name: hello
        image: busybox
        command: ["echo", "Hello from Kubernetes Job"]
      restartPolicy: Never

kubectl apply -f hello-job.yaml

Attendez la fin de l’exécution :

kubectl wait --for=condition=complete job/hello-job --timeout=60s

Vérifiez le statut :

kubectl get jobs

Sortie

NAME        STATUS     COMPLETIONS   DURATION   AGE
hello-job   Complete   1/1           4s         10s

restartPolicy obligatoire

Pour un Job, restartPolicy doit être Never ou OnFailure. La valeur Always (par défaut des Pods) n’est pas autorisée car elle créerait une boucle infinie.

Observer et inspecter un Job

Voir les logs

kubectl logs job/hello-job

Sortie

Hello from Kubernetes Job

Détails du Job

kubectl describe job hello-job

Informations clés :

• Completions : nombre d’exécutions réussies requises
• Parallelism : nombre de Pods exécutés en parallèle
• Active / Succeeded / Failed : état des Pods

Lister les Pods créés par un Job

kubectl get pods -l job-name=hello-job

Anatomie d’un Job

job-complet.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: backup-database
spec:
  backoffLimit: 3              # Tentatives max en cas d'échec
  activeDeadlineSeconds: 300   # Timeout global (5 min)
  ttlSecondsAfterFinished: 3600  # Nettoyage auto après 1h
  template:
    spec:
      containers:
      - name: backup
        image: postgres:16
        command: ["pg_dump", "-h", "db-host", "-U", "admin", "mydb"]
      restartPolicy: Never

Champ	Description	Valeur par défaut
backoffLimit	Nombre de tentatives avant abandon	6 (sauf Indexed Jobs)
activeDeadlineSeconds	Durée max d’exécution du Job	Illimitée
ttlSecondsAfterFinished	Nettoyage automatique après N secondes	Non activé
completions	Nombre d’exécutions réussies requises	1
parallelism	Nombre de Pods simultanés	1

Glissez pour voir

Comportement en cas d’échec

backoffLimit : limiter les tentatives

Si un Pod échoue, Kubernetes le relance avec un délai exponentiel (10s, 20s, 40s…). backoffLimit stoppe les tentatives :

spec:
  backoffLimit: 3   # Abandon après 3 échecs

Le Job passe en statut Failed avec la raison BackoffLimitExceeded.

Pour la plupart des Jobs, backoffLimit vaut 6 par défaut. Les Indexed Jobs disposent aussi d’options avancées comme backoffLimitPerIndex.

activeDeadlineSeconds : timeout global

Empêche un Job de tourner indéfiniment :

spec:
  activeDeadlineSeconds: 300   # 5 minutes max

Si le temps est dépassé, tous les Pods sont arrêtés et le Job passe en Failed avec la raison DeadlineExceeded.

restartPolicy : comportement du Pod

Valeur	Comportement
Never	Kubernetes crée un nouveau Pod à chaque tentative
OnFailure	Le même Pod redémarre (garde les volumes locaux)

Glissez pour voir

Jobs parallèles

Pour traiter plusieurs éléments simultanément :

parallel-job.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: parallel-job
spec:
  completions: 10      # 10 exécutions au total
  parallelism: 3       # 3 Pods en parallèle
  template:
    spec:
      containers:
      - name: worker
        image: busybox
        command: ["sh", "-c", "echo 'Processing...' && sleep 5"]
      restartPolicy: Never

Kubernetes lance 3 Pods en parallèle, puis en lance de nouveaux dès qu’un se termine, jusqu’à atteindre 10 complétions.

Jobs indexés

En mode Indexed, chaque Pod reçoit un index de complétion unique. Kubernetes l’expose via l’annotation batch.kubernetes.io/job-completion-index, et la variable d’environnement JOB_COMPLETION_INDEX est disponible dans le conteneur :

spec:
  completions: 5
  parallelism: 5
  completionMode: Indexed
  template:
    spec:
      containers:
      - name: worker
        image: busybox
        command: ["sh", "-c", "echo Processing chunk $JOB_COMPLETION_INDEX"]

Idéal pour traiter des partitions de données (chunk 0, chunk 1…).

Nettoyage automatique avec TTL

Sans nettoyage, les Jobs terminés s’accumulent. ttlSecondsAfterFinished les supprime automatiquement :

spec:
  ttlSecondsAfterFinished: 3600   # Supprimé 1h après complétion

Bonne pratique

Activez ttlSecondsAfterFinished sur tous vos Jobs pour éviter l’accumulation de ressources. Ce TTL s’applique aux Jobs réussis comme aux Jobs échoués — tous sont supprimés automatiquement avec leurs Pods dépendants.

CronJobs : planifier des tâches récurrentes

Un CronJob crée automatiquement des Jobs selon un planning :

daily-backup.yaml

apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-backup
spec:
  schedule: "0 2 * * *"           # Tous les jours à 2h du matin
  timeZone: "Europe/Paris"         # Fuseau horaire explicite
  successfulJobsHistoryLimit: 3    # Garde les 3 derniers Jobs réussis
  failedJobsHistoryLimit: 1        # Garde le dernier Job échoué
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: postgres:16
            command: ["pg_dump", "-h", "db-host", "-U", "admin", "mydb"]
          restartPolicy: Never

Syntaxe cron

┌───────────── minute (0-59)
│ ┌───────────── heure (0-23)
│ │ ┌───────────── jour du mois (1-31)
│ │ │ ┌───────────── mois (1-12)
│ │ │ │ ┌───────────── jour de la semaine (0-6, 0=dimanche)
│ │ │ │ │
* * * * *

Expression	Signification
0 * * * *	Chaque heure à :00
0 2 * * *	Tous les jours à 2h
0 0 * * 0	Chaque dimanche à minuit
*/15 * * * *	Toutes les 15 minutes
0 9-17 * * 1-5	Chaque heure de 9h à 17h, lundi à vendredi

Glissez pour voir

Observer les CronJobs

kubectl get cronjobs

Sortie

NAME             SCHEDULE      TIMEZONE       SUSPEND   ACTIVE   LAST SCHEDULE   AGE
daily-backup     0 2 * * *     Europe/Paris   False     0        12h             3d

Paramètres CronJob de production

concurrencyPolicy : gérer les chevauchements

Que faire si l’exécution précédente n’est pas terminée ?

Valeur	Comportement
Allow	Autorise plusieurs Jobs simultanés (par défaut)
Forbid	Skip l’exécution si un Job est en cours
Replace	Arrête l’ancien Job et en démarre un nouveau

Glissez pour voir

spec:
  concurrencyPolicy: Forbid   # Recommandé pour les backups

Attention avec Allow

Allow peut créer des problèmes si vos Jobs accèdent aux mêmes ressources (fichiers, base de données). Préférez Forbid pour les tâches critiques.

startingDeadlineSeconds : délai de démarrage

Si le cluster était indisponible à l’heure prévue, combien de temps après peut-on encore démarrer ?

spec:
  startingDeadlineSeconds: 3600   # 1h de délai max

Si startingDeadlineSeconds est défini, Kubernetes saute une exécution qui a dépassé ce délai. Si ce champ n’est pas défini, les occurrences n’ont pas de date limite de démarrage.

suspend : mettre en pause

Arrêter temporairement les exécutions sans supprimer le CronJob :

kubectl patch cronjob daily-backup -p '{"spec":{"suspend":true}}'

Réactiver :

kubectl patch cronjob daily-backup -p '{"spec":{"suspend":false}}'

timeZone : fuseau horaire explicite

Depuis Kubernetes 1.27, vous pouvez spécifier le fuseau horaire :

spec:
  timeZone: "Europe/Paris"

Sans timeZone, le planning utilise le fuseau horaire du kube-controller-manager, souvent UTC dans de nombreux clusters.

Déclencher manuellement un CronJob

Pour tester ou forcer une exécution :

kubectl create job --from=cronjob/daily-backup manual-backup

Suivez l’exécution :

kubectl wait --for=condition=complete job/manual-backup --timeout=300s
kubectl logs job/manual-backup

Cas réels

Migration de base de données

apiVersion: batch/v1
kind: Job
metadata:
  name: db-migration
spec:
  backoffLimit: 1              # Pas de retry sur migration
  activeDeadlineSeconds: 600   # 10 min max
  ttlSecondsAfterFinished: 86400
  template:
    spec:
      containers:
      - name: migrate
        image: myapp:latest
        command: ["./manage.py", "migrate", "--no-input"]
        envFrom:
        - secretRef:
            name: db-credentials
      restartPolicy: Never

Sauvegarde planifiée

apiVersion: batch/v1
kind: CronJob
metadata:
  name: postgres-backup
spec:
  schedule: "0 3 * * *"
  timeZone: "Europe/Paris"
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 7    # 1 semaine d'historique
  failedJobsHistoryLimit: 3
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: postgres:16
            command:
            - /bin/sh
            - -c
            - pg_dump -h $DB_HOST -U $DB_USER $DB_NAME | gzip > /backup/$(date +%Y%m%d).sql.gz
            envFrom:
            - secretRef:
                name: db-credentials
            volumeMounts:
            - name: backup-volume
              mountPath: /backup
          volumes:
          - name: backup-volume
            persistentVolumeClaim:
              claimName: backup-pvc
          restartPolicy: Never

Purge de données anciennes

apiVersion: batch/v1
kind: CronJob
metadata:
  name: data-cleanup
spec:
  schedule: "0 4 * * 0"           # Chaque dimanche à 4h
  timeZone: "Europe/Paris"
  jobTemplate:
    spec:
      ttlSecondsAfterFinished: 86400
      template:
        spec:
          containers:
          - name: cleanup
            image: myapp:latest
            command: ["./cleanup.sh", "--older-than", "90d"]
          restartPolicy: Never

Debug : problèmes courants

1. Le Job reste en “Running” indéfiniment

   Vérifiez les logs du Pod :

   kubectl logs job/my-job

   Solution : ajoutez activeDeadlineSeconds pour forcer un timeout.

2. Le Job échoue avec BackoffLimitExceeded

   Analysez les événements :

   kubectl describe job my-job

   Vérifiez les logs des Pods échoués :

   kubectl logs -l job-name=my-job --all-containers

3. Le CronJob ne s’exécute pas

   Vérifiez l’expression cron et le fuseau horaire :

   kubectl get cronjob my-cronjob
   kubectl describe cronjob my-cronjob | grep "Last Schedule"

4. CronJob suspendu accidentellement

   kubectl get cronjob my-cronjob -o jsonpath='{.spec.suspend}'

   Si true, réactivez avec kubectl patch.

Erreurs fréquentes

Erreur	Cause	Solution
BackoffLimitExceeded	Trop d’échecs	Analyser les logs, corriger le code
DeadlineExceeded	Job trop long	Augmenter activeDeadlineSeconds ou optimiser
Job ne démarre pas	Expression cron invalide	Vérifier la syntaxe et le timeZone
Jobs qui s’accumulent	Pas de TTL	Ajouter ttlSecondsAfterFinished

Glissez pour voir

Contrôle de connaissances

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

5 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

1. Un Job exécute une tâche jusqu’à complétion, un CronJob la planifie
2. backoffLimit limite les tentatives, activeDeadlineSeconds impose un timeout
3. ttlSecondsAfterFinished nettoie automatiquement les Jobs terminés
4. parallelism et completions permettent le traitement parallèle
5. concurrencyPolicy: Forbid évite les exécutions simultanées de CronJobs
6. timeZone garantit des exécutions à l’heure locale
7. suspend permet de mettre un CronJob en pause sans le supprimer
8. Testez avec kubectl create job --from=cronjob/... avant la mise en prod

Prochaines étapes

Deployments Gérer des applications qui tournent en continu

ConfigMaps Configurer vos Jobs avec des variables externes

Secrets Injecter des identifiants dans vos Jobs

RBAC Contrôler les permissions des Jobs

×

📖 Voir la documentation →