Jobs

Dans Kubernetes, les Pods sont conçus pour exécuter des applications en continu. Mais comment gérer des tâches ponctuelles comme un script de migration, un traitement de données ou une sauvegarde ?

Les Jobs résolvent ce problème en permettant d’exécuter des tâches une seule fois ou en parallèle, tout en assurant leur bon déroulement. Contrairement aux Pods classiques, un Job garantit que la tâche sera complétée, même en cas de redémarrage ou d’échec.

Quelle est la différence entre un Pod et un Job ?

Les Jobs sont une ressource Kubernetes conçue pour exécuter des tâches ponctuelles qui doivent s’exécuter jusqu’à leur complétion, contrairement aux Pods classiques, qui sont souvent conçus pour fonctionner en continu.

Un Job crée un ou plusieurs Pods et s’assure qu’ils terminent correctement leur exécution. Une fois terminé avec succès, il ne redémarre pas.

Cycle de vie d’un Job

Un Job passe par plusieurs étapes avant d’être complété :

1. Création du Job : Kubernetes crée un ou plusieurs Pods selon la configuration du Job.
2. Exécution du Pod : Le Pod exécute la tâche définie (ex : script de traitement de données).
3. Succès ou échec :

• Si la tâche réussit, le Job est marqué comme “Succeeded” ✅.
• Si le Pod échoue, Kubernetes peut le redémarrer en fonction des paramètres du Job.

4. Achèvement : Une fois que le Job a atteint le nombre d’exécutions requises, il est marqué comme Terminated.

Les différents Types d’exécution des Jobs

Un Job peut être configuré pour s’exécuter de différentes manières :

Exécution unique (par défaut)*

Un seul Pod est créé pour exécuter la tâche. Si le Pod échoue, Kubernetes le redémarre jusqu’à ce que la tâche réussisse ou que la limite d’échecs soit atteinte.

Cas d’usage :

• Migration de base de données
• Sauvegarde ponctuelle
• Envoi d’un e-mail

apiVersion: batch/v1
kind: Job
metadata:
  name: job-simple
spec:
  template:
    spec:
      containers:
      - name: job
        image: busybox
        command: ["echo", "Tâche 1"]
      restartPolicy: Never

Exécution parallèle

Un Job peut exécuter plusieurs instances de la même tâche simultanément.

Cas d’usage :

• Traitement de fichiers en parallèle
• Calculs massivement distribués

apiVersion: batch/v1
kind: Job
metadata:
  name: job-parallel
spec:
  completions: 5   # Nombre total d'exécutions
  parallelism: 2   # Nombre d'exécutions simultanées
  template:
    spec:
      containers:
      - name: job
        image: busybox
        command: ["echo", "Tâche en parallèle"]
      restartPolicy: Never

Explication :

• completions: 5 → Le Job s’exécutera 5 fois.
• parallelism: 2 → Kubernetes lancera 2 Pods en parallèle jusqu’à ce que les 5 exécutions soient terminées.

Exécution avec indexation des tâches (Job Indexed)

Utile pour exécuter plusieurs tâches distinctes où chaque Pod doit savoir quel fragment de travail lui est assigné.

Cas d’usage :

• Traitement de morceaux d’un gros fichier
• Traitement de lots de données différents

apiVersion: batch/v1
kind: Job
metadata:
  name: job-indexed
spec:
  completions: 3
  parallelism: 3
  completionMode: Indexed
  template:
    spec:
      containers:
      - name: job
        image: busybox
        command: ["sh", "-c", "echo Traitement de l’index $(JOB_COMPLETION_INDEX)"]
      restartPolicy: Never

Explication :

• completionMode: Indexed → Chaque exécution reçoit un numéro d’index unique (0, 1, 2).
• Permet à chaque Pod de savoir quel fragment de travail traiter.

Gestion de l’exécution des Jobs

Un Job Kubernetes garantit qu’une tâche sera exécutée avec succès, mais il est important de contrôler son comportement en cas d’échec, de limiter le temps d’exécution et de gérer les redémarrages. Kubernetes propose plusieurs paramètres pour cela :

• BackoffLimit : Limite le nombre de tentatives en cas d’échec
• ActiveDeadlineSeconds : Définit un temps maximal d’exécution
• RestartPolicy : Contrôle le redémarrage des Pods

Voyons comment les utiliser efficacement.

1. BackoffLimit : limiter les tentatives en cas d’échec

Par défaut, si un Pod échoue, Kubernetes le redémarre automatiquement. BackoffLimit permet de limiter le nombre de tentatives avant d’abandonner complètement le Job.

Exemple : Limiter les tentatives à 3

apiVersion: batch/v1
kind: Job
metadata:
  name: job-backofflimit
spec:
  backoffLimit: 3   # Kubernetes arrêtera après 3 échecs
  template:
    spec:
      containers:
      - name: job
        image: busybox
        command: ["sh", "-c", "exit 1"]  # Simule un échec
      restartPolicy: Never

Explication :

• Si le Pod échoue, Kubernetes le redémarre.
• Après 3 tentatives (backoffLimit: 3), le Job est marqué comme “Failed” et ne sera plus relancé.

Utilisation : Éviter des boucles infinies de redémarrage lorsque le Job est défectueux.

2. ActiveDeadlineSeconds : empêcher les exécutions trop longues

Si un Job prend trop de temps, il peut surcharger le cluster. ActiveDeadlineSeconds définit un temps limite global pour l’exécution d’un Job.

Exemple : Annuler un Job après 60 secondes

apiVersion: batch/v1
kind: Job
metadata:
  name: job-timeout
spec:
  activeDeadlineSeconds: 60  # Temps max d’exécution
  template:
    spec:
      containers:
      - name: job
        image: busybox
        command: ["sh", "-c", "sleep 120"]  # La tâche dure 120s
      restartPolicy: Never

Explication :

• Si le Job dépasse 60 secondes, Kubernetes le stoppe automatiquement.
• Utile pour éviter que des Jobs ne consomment des ressources indéfiniment.

Utilisation : Forcer l’arrêt de Jobs trop longs pour éviter les blocages.

3. RestartPolicy : configurer le redémarrage des Pods du Job

Le paramètre restartPolicy contrôle comment Kubernetes redémarre un Pod après un échec.

Les valeurs possibles :

Valeur	Comportement
Never	Ne redémarre jamais le Pod (Kubernetes crée un nouveau Pod si nécessaire).
OnFailure	Redémarre le Pod uniquement s’il échoue.
Always (non supporté)	🚫 Ne fonctionne pas avec les Jobs, réservé aux Déployments.

Exemple : Redémarrer un Pod uniquement en cas d’échec :

apiVersion: batch/v1
kind: Job
metadata:
  name: job-restart
spec:
  template:
    spec:
      containers:
      - name: job
        image: busybox
        command: ["sh", "-c", "exit 1"]
      restartPolicy: OnFailure  # Redémarre le Pod s’il échoue

Explication :

• Si le Pod échoue, Kubernetes le redémarre immédiatement.
• Fonctionne en combinaison avec backoffLimit pour éviter les boucles infinies.

Utilisation : Assurer que les tâches critiques soient exécutées même en cas d’échec temporaire.

Utiliser un CronJob pour exécuter un Job récurrent

Les Jobs permettent d’exécuter des tâches ponctuelles, mais comment automatiser une tâche qui doit s’exécuter régulièrement (toutes les heures, chaque nuit, une fois par semaine) ?

C’est là qu’intervient le CronJob, une ressource Kubernetes qui permet de planifier l’exécution automatique des Jobs en fonction d’une expression cron.

Différence entre un Job et un CronJob

Caractéristique	Job	CronJob
Exécution	Une seule fois	Répétée selon un planning
Déclenchement	Manuel ou à la création	Automatique via une expression cron
Cas d’usage	Migration ponctuelle, traitement unique	Sauvegardes, nettoyage de logs, synchronisation de données
Expiration	Après exécution	Historique géré, possibilité de supprimer les anciens Jobs

En résumé : Un Job exécute une tâche une seule fois, alors qu’un CronJob permet de l’exécuter automatiquement à intervalles réguliers.

Définir un CronJob avec une expression cron

Un CronJob fonctionne comme une tâche cron traditionnelle, en utilisant une expression cron pour planifier son exécution.

Exemple : Exécuter un Job toutes les 5 minutes :

apiVersion: batch/v1
kind: CronJob
metadata:
  name: cronjob-exemple
spec:
  schedule: "*/5 * * * *"  # Exécution toutes les 5 minutes
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: cronjob
            image: busybox
            command: ["sh", "-c", "echo 'Tâche exécutée à $(date)'"]
          restartPolicy: Never

Explication :

• schedule: "*/5 * * * *" → Planifie l’exécution toutes les 5 minutes.
• jobTemplate → Décrit le Job qui sera exécuté à chaque cycle.
• restartPolicy: Never → Le Pod ne redémarre pas après l’exécution.

Comprendre les expressions cron

L’expression cron est composée de 5 champs représentant la fréquence d’exécution :

Position	Valeur	Signification
1. Minute	0-59	Minute d’exécution
2. Heure	0-23	Heure d’exécution
3. Jour du mois	1-31	Jour d’exécution
4️. Mois	1-12	Mois d’exécution
5️. Jour de la semaine	0-6 (0 = Dimanche)	Jour spécifique

Quelques Exemples :

Expression	Exécution
"0 * * * *"	Chaque heure, à la minute 0
"0 12 * * *"	Tous les jours à midi
"0 0 * * 1"	Chaque lundi à minuit
"*/15 * * * *"	Toutes les 15 minutes

Gestion des historiques et expiration des anciens Jobs

Un CronJob crée un nouveau Job à chaque exécution. Sans gestion des historiques, cela peut rapidement accumuler des ressources inutiles dans le cluster.

Limiter le nombre de Jobs conservés :

spec:
  successfulJobsHistoryLimit: 3  # Garde uniquement les 3 derniers Jobs réussis
  failedJobsHistoryLimit: 1       # Garde uniquement le dernier Job échoué

Explication :

• successfulJobsHistoryLimit: 3 → Kubernetes supprimera les anciens Jobs réussis au-delà de 3.
• failedJobsHistoryLimit: 1 → Conserve uniquement le dernier Job ayant échoué.

Bonne pratique : Toujours configurer ces paramètres pour éviter une accumulation excessive de Jobs terminés.

Débogage et gestion des erreurs des Jobs et CronJobs

Même avec une bonne configuration, les Jobs et CronJobs peuvent rencontrer des erreurs :

• Échecs répétés d’un Job
• Un Job qui ne se termine jamais
• Un CronJob qui ne s’exécute pas comme prévu

Voyons comment identifier et résoudre ces problèmes efficacement.

1. Vérifier l’état des Jobs et CronJobs

La première étape en cas de problème est de vérifier l’état des Jobs en cours d’exécution.

• Lister tous les Jobs et voir leur statut :

kubectl get jobs

NAME              COMPLETIONS   DURATION   AGE
backup-job        0/1           10s        5m
cleanup-job       1/1           30s        15m

• Lister les CronJobs et voir leur prochaine exécution :

kubectl get cronjobs

NAME             SCHEDULE    LAST SCHEDULE   AGE
daily-backup     0 2 * * *   12h ago        3d
log-cleanup      */15 * * * * 10m ago        7d

2. Identifier les erreurs courantes

• Job qui échoue constamment (BackoffLimitExceeded) :

  Si un Job échoue trop de fois, Kubernetes l’arrête définitivement avec BackoffLimitExceeded.

  Solution : Vérifier les logs du Pod défaillant

  kubectl logs job-name

  Si le Pod n’existe plus, récupérer les événements liés au Job :

  kubectl describe job job-name

• Un Job qui ne se termine jamais

  Si un Job prend trop de temps, il peut bloquer des ressources.

  Solution : Définir une durée maximale avec activeDeadlineSeconds.

  spec:
    activeDeadlineSeconds: 300  # Stopper le Job après 5 minutes

• Un CronJob qui ne s’exécute pas

  Si un CronJob ne crée pas de nouveaux Jobs, il peut y avoir une erreur dans la configuration de l’expression cron.

  Solution : Vérifier s’il y a des erreurs d’exécution

  kubectl describe cronjob cronjob-name

  Vérifier l’historique des Jobs générés :

  kubectl get jobs --selector=job-name=cronjob-name

Bonnes pratiques pour éviter les erreurs

1. Limiter les tentatives en cas d’échec : Utiliser backoffLimit pour éviter les redémarrages infinis :

spec:
  backoffLimit: 3  # Kubernetes stoppe le Job après 3 échecs

2. Ne pas accumuler d’anciens Jobs : Gérer l’historique avec successfulJobsHistoryLimit et failedJobsHistoryLimit :

spec:
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1

3. Contrôler l’exécution des CronJobs : Simuler une exécution pour tester l’expression cron :

kubectl create job --from=cronjob/cronjob-name test-job

Conclusion

Les Jobs et CronJobs sont des outils puissants pour automatiser l’exécution de tâches dans Kubernetes. En maîtrisant leur configuration, leur gestion des erreurs et leurs optimisations, vous pouvez assurer une exécution fiable et efficace de vos traitements.

Mais rien ne vaut la pratique ! 🚀 Des TP sont en cours d’écriture ↗ pour vous permettre d’expérimenter ces concepts directement sur un cluster Kubernetes.