Architecture des Jobs Kubernetes : guide pratique avec exemples

Introduction

Les Jobs Kubernetes sont le pilier de l'exécution de charges de travail par lots et finies qui doivent se terminer avec succès. Que vous traitiez un ensemble de données, exécutiez des migrations de base de données ou envoyiez un lot d'e-mails, les Jobs garantissent que la tâche s'exécute jusqu'à son terme avec le nombre souhaité de terminaisons réussies. Cependant, comprendre l'architecture sous-jacente est crucial pour utiliser les Jobs efficacement, éviter les échecs silencieux et résoudre les problèmes lorsqu'ils surviennent.

Ce guide parcourt l'architecture des Jobs Kubernetes avec des exemples pratiques et des commandes que vous pouvez exécuter dès maintenant. Nous couvrons les composants essentiels, le cycle de vie d'un Job, la configuration des nouvelles tentatives, du parallélisme et des délais, ainsi que le débogage et l'exploitation des Jobs en production. L'objectif est la clarté opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés plutôt que des secrets, vérifier les résultats et documenter les procédures de récupération.

Inventaire de la version et de l'environnement

Avant de toucher à un cluster, établissez ce avec quoi vous travaillez. Cette section décrit l'inventaire de base que vous devez saisir pour les Jobs Kubernetes. Nommez les composants pertinents, les versions prises en charge, les prérequis, les observations en lecture seule, la plus petite modification justifiée et les commandes de vérification.

Composants essentiels

Un Job Kubernetes crée un ou plusieurs Pods et garantit qu'un nombre spécifié d'entre eux se terminent avec succès. Les composants clés incluent :

• Contrôleur de Job : surveille les objets Job et crée des Pods pour exécuter la charge de travail. Il suit les terminaisons et les échecs.
• Modèle de Pod : spécification des Pods exécutés par le Job. Il inclut l'image du conteneur, la commande, les ressources et la politique de redémarrage.
• Sélecteur : identifie les Pods appartenant au Job. Le contrôleur de Job l'utilise pour suivre et gérer ses Pods.
• Champs de terminaison et de parallélisme : définissent combien de Pods doivent réussir et combien peuvent s'exécuter simultanément.
• Limite de retour en arrière (backoffLimit) : nombre de nouvelles tentatives avant que le Job ne soit marqué comme échoué.
• Délai actif (activeDeadlineSeconds) : durée maximale pendant laquelle le Job peut s'exécuter avant d'être terminé.

Commandes de vérification de l'environnement

Commencez par confirmer la version de votre cluster et que l'API batch est disponible :

kubectl version --short
kubectl api-versions | grep batch

La sortie attendue inclut batch/v1 (ou batch/v1beta1 sur les anciens clusters). Assurez-vous que votre cluster est au moins en version Kubernetes 1.12 pour l'API stable des Jobs. Ensuite, vérifiez les Jobs existants dans votre espace de noms :

kubectl get jobs -n default

Si aucun Job n'existe, la sortie est vide. Ensuite, inspectez les Pods en cours d'exécution avec une sortie large pour voir l'affectation des nœuds et les adresses IP :

kubectl get pods -o wide -n default

Exemple de sortie :

NAME                     READY   STATUS      RESTARTS   AGE   IP            NODE
data-processor-abcde    0/1     Completed   0          5m    10.244.1.23   node-1

Pour examiner la configuration et les événements d'un Job spécifique :

kubectl describe job data-processor

Cela montre la spécification du Job, son statut et des événements comme la création et la terminaison des Pods. Pour un Pod qui a échoué, consultez ses journaux, y compris l'instance de conteneur précédente :

kubectl logs data-processor-abcde --previous

Avant de supposer qu'une publication a réussi, vérifiez le statut du déploiement pour les Deployments (si impliqués) avec kubectl rollout status deployment/<nom>.

Prérequis

• Un cluster Kubernetes en cours d'exécution (version 1.12+ recommandée).
• kubectl configuré avec les autorisations appropriées.
• Une image de conteneur à exécuter comme Job (par exemple, busybox pour des tests simples).
• Facultatif : un serveur de métriques ou une pile de surveillance pour observer les métriques des Jobs.

Plus petite modification justifiée

Commencez avec un Job simple qui affiche un message pour vérifier que le contrôleur fonctionne. Enregistrez ce YAML sous job-test.yaml :

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

Appliquez-le :

kubectl apply -f job-test.yaml

Observez immédiatement le Job et les Pods :

kubectl get jobs,pods -l batch.kubernetes.io/job-name=hello-job

La sortie attendue montre le Job avec COMPLETIONS 0/1 initialement, puis 1/1 après la terminaison du pod. Vérifiez le journal du pod :

kubectl logs -l job-name=hello-job

Sortie : Hello Kubernetes Job.

Chemin de configuration sécurisé

Configurer un Job en toute sécurité signifie définir son comportement explicitement pour éviter les pods incontrôlés, l'épuisement des ressources et les échecs silencieux. Cette section couvre les meilleures pratiques et les modèles de configuration avec des exemples.

Définir les nouvelles tentatives et le retour en arrière

Le champ backoffLimit spécifie le nombre de nouvelles tentatives avant que le Job ne soit considéré comme échoué. La valeur par défaut est 6. Par exemple :

spec:
  backoffLimit: 3
  template:
    spec:
      containers:
      - name: may-fail
        image: busybox
        command: ["sh", "-c", "exit 1"]
      restartPolicy: Never

Avec cette configuration, le Job crée un pod, celui-ci échoue et le contrôleur réessaie jusqu'à 3 fois (soit 4 tentatives au total). Après avoir dépassé le backoffLimit, le statut du Job affiche Failed et aucun autre pod n'est créé. Observez avec :

kubectl describe job may-fail

Vérifiez les événements pour les échecs de pod et les messages de retour en arrière.

Définir la terminaison et le parallélisme

Pour le traitement par lots, définissez completions (nombre total de pods réussis nécessaires) et parallelism (combien de pods peuvent s'exécuter simultanément). Exemple : traiter 10 éléments avec 3 travailleurs à la fois :

spec:
  completions: 10
  parallelism: 3
  template:
    spec:
      containers:
      - name: worker
        image: busybox
        command: ["sh", "-c", "echo Processing item $ITEM && sleep 5"]
        env:
        - name: ITEM
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
      restartPolicy: Never

Cela crée jusqu'à 3 pods simultanément, chacun traitant un « élément » (simulé ici par le nom du pod). Une fois que 10 pods se terminent avec succès, le Job est marqué comme terminé. Surveillez la progression :

kubectl get jobs worker-job --watch

Observez la colonne COMPLETIONS augmenter.

Délai actif

Empêchez les Jobs de rester bloqués indéfiniment avec activeDeadlineSeconds. Pour les tâches limitées dans le temps :

spec:
  activeDeadlineSeconds: 60
  template:
    spec:
      containers:
      - name: timeout
        image: busybox
        command: ["sh", "-c", "sleep 120"]
      restartPolicy: Never

Si le Job s'exécute plus de 60 secondes, Kubernetes termine tous les pods et marque le Job comme échoué avec la raison DeadlineExceeded.

Politique de redémarrage

Les pods d'un Job doivent avoir restartPolicy défini sur Never ou OnFailure. Always n'est pas autorisé car les Jobs sont finis. Never signifie que le conteneur ne sera pas redémarré par le kubelet ; OnFailure redémarre dans le même pod. Choisissez selon que vous voulez un nouveau pod (Never) ou une nouvelle tentative dans le même pod (OnFailure).

Liste de contrôle de configuration sécurisée

• [x] Définir explicitement restartPolicy: Never (ou OnFailure).
• [x] Définir backoffLimit pour éviter des tentatives infinies.
• [x] Définir activeDeadlineSeconds pour les tâches sensibles au temps.
• [x] Utiliser completions et parallelism avec précaution pour éviter de surcharger le cluster.
• [x] Appliquer des limites de ressources aux conteneurs pour éviter les pics de mémoire/CPU.
• [x] Éviter de coder en dur des secrets dans la spécification du Job ; utiliser des variables d'environnement provenant de Secrets ou de ConfigMaps.

Exemple de limites de ressources :

resources:
  requests:
    cpu: "100m"
    memory: "64Mi"
  limits:
    cpu: "200m"
    memory: "128Mi"

Vérification et diagnostics

Une fois qu'un Job est en cours d'exécution, vous devez vérifier sa progression, détecter les échecs tôt et diagnostiquer les problèmes. Cette section fournit des commandes et des techniques pour surveiller et déboguer les Jobs.

Surveiller le statut du Job

Utilisez kubectl describe job pour voir les détails :

kubectl describe job votre-job

Recherchez :

• Conditions : JobComplete, JobFailed avec les raisons.
• Événements : création de pod, terminaison réussie, échecs.
• Statut : nombre de pods actifs, réussis et échoués.

Pour un aperçu rapide, utilisez kubectl get job avec des colonnes personnalisées :

kubectl get job votre-job -o custom-columns=NAME:.metadata.name,ACTIVE:.status.active,SUCCEEDED:.status.succeeded,FAILED:.status.failed,COMPLETIONS:.spec.completions,PARALLELISM:.spec.parallelism

Vérifier les journaux des pods

Chaque pod créé par un Job a des journaux. Utilisez un sélecteur d'étiquettes pour obtenir les journaux de tous les pods d'un Job :

kubectl logs -l job-name=votre-job --all-containers --prefix

Le drapeau --prefix ajoute le nom du pod aux lignes de journal pour plus de clarté.

Si un pod a planté et redémarré, obtenez les journaux précédents :

kubectl logs <nom-du-pod> --previous

Déboguer les modes de défaillance courants

1. Pod bloqué en attente (Pending) : vérifiez les événements avec kubectl describe pod <nom-du-pod>. Probablement des ressources insuffisantes ou un nœud non programmable.
2. Le conteneur se termine avec un code non nul : inspectez les journaux ; peut-être une variable d'environnement manquante ou une commande incorrecte.
3. Le Job dépasse la limite de retour en arrière : tous les pods ont échoué ; vérifiez les statuts des pods et les journaux pour identifier la cause première.
4. Le Job ne se termine pas : peut-être completions est trop élevé, ou les pods sont bloqués. Vérifiez les pods actifs et les journaux.

Utilisez kubectl get events --sort-by=.metadata.creationTimestamp pour voir les événements récents dans l'espace de noms.

Vérifier le succès

Un Job réussi a le statut :

conditions:
- type: Complete
  status: "True"

Confirmez avec :

kubectl get job votre-job -o jsonpath='{.status.conditions[?(@.type=="Complete")].status}'

Sortie : True.

Modes de défaillance et récupération

Comprendre les modes de défaillance est essentiel pour construire des Jobs résilients. Cette section couvre les scénarios de défaillance courants, comment les détecter et les stratégies de récupération.

Modes de défaillance typiques

Exemples détaillés

Exemple 1 : Limite de retour en arrière atteinte

Créez un Job qui échoue toujours :

apiVersion: batch/v1
kind: Job
metadata:
  name: fail-job
spec:
  backoffLimit: 3
  template:
    spec:
      containers:
      - name: fail
        image: busybox
        command: ["sh", "-c", "exit 1"]
      restartPolicy: Never

Appliquez et surveillez :

kubectl apply -f fail-job.yaml
kubectl get jobs fail-job --watch

Après 4 tentatives (initiale + 3 nouvelles tentatives), le statut du Job affiche Failed. Décrivez pour voir les événements :

kubectl describe job fail-job

Les événements montrent les échecs de pod et le dépassement de la limite de retour en arrière.

Récupération : corrigez la commande ou l'image, supprimez le Job échoué et recréez-le.

Exemple 2 : Délai dépassé

apiVersion: batch/v1
kind: Job
metadata:
  name: deadline-job
spec:
  activeDeadlineSeconds: 5
  template:
    spec:
      containers:
      - name: slow
        image: busybox
        command: ["sh", "-c", "sleep 30"]
      restartPolicy: Never

Après 5 secondes, le pod est terminé et le Job marqué comme échoué. Vérifiez :

kubectl get job deadline-job -o jsonpath='{.status.conditions[?(@.type=="Failed")].reason}'

Sortie : DeadlineExceeded.

Récupération : augmentez le délai si la tâche prend légitimement plus de temps, ou optimisez le code.

Nettoyage et réinitialisation

Pour récupérer d'un Job échoué, vous devrez peut-être le supprimer et repartir de zéro. Utilisez kubectl delete job <nom> pour supprimer le Job et ses pods (par défaut, les pods ne sont pas supprimés mais le Job est supprimé). Définissez propagationPolicy: Background pour supprimer également les pods :

kubectl delete job fail-job --cascade=background

Puis réappliquez le manifeste corrigé.

Liste de contrôle des opérations

Pour les opérations quotidiennes, utilisez cette liste de contrôle pour garantir que les Jobs sont sains et gérables.

Avant le déploiement

• [ ] L'image du conteneur est testée et versionnée.
• [ ] Les limites de ressources sont définies.
• [ ] restartPolicy est défini sur Never ou OnFailure.
• [ ] backoffLimit est correctement défini (pas trop élevé).
• [ ] activeDeadlineSeconds est pris en compte pour les tâches longues.
• [ ] Les Secrets et ConfigMaps sont référencés via des variables d'environnement ou des volumes, pas codés en dur.
• [ ] La spécification du Job est revue par un pair.

Pendant le déploiement

• [ ] Appliquer le manifeste du Job : kubectl apply -f job.yaml.
• [ ] Vérifier immédiatement le statut : kubectl get jobs <nom>.
• [ ] Surveiller les pods : kubectl get pods -l job-name=<nom> --watch.
• [ ] Examiner les journaux pour les erreurs précoces : kubectl logs -l job-name=<nom> --tail=50.

Vérification post-déploiement

• [ ] Le Job se termine dans le temps prévu : kubectl get job <nom> affiche COMPLETIONS: 1/1 (ou souhaité).
• [ ] Aucun redémarrage de pod inattendu : vérifiez que la colonne RESTARTS est inférieure ou égale à ce qui est attendu.
• [ ] Les artefacts de sortie sont produits correctement (le cas échéant).
• [ ] Nettoyer les Jobs terminés s'ils ne sont pas nécessaires : kubectl delete job <nom> (ou utilisez le contrôleur TTL).

Surveillance et alertes

• [ ] Mettre en place une surveillance sur les métriques des Jobs : temps de terminaison, taux d'échec.
• [ ] Alerter sur la condition JobFailed en utilisant des outils comme Prometheus et Alertmanager.
• [ ] Examiner régulièrement les Jobs dans le cluster : kubectl get jobs --all-namespaces.

Exemple de manuel opérationnel

Scénario : Un Job de traitement de données nommé nightly-etl échoue par intermittence.

1. Vérifiez le statut du Job :

   kubectl get job nightly-etl -n data

1. Inspectez les événements récents :

   kubectl describe job nightly-etl -n data | tail -30

1. Obtenez les journaux des pods échoués :

   for pod in $(kubectl get pods -l job-name=nightly-etl -n data --field-selector=status.phase=Failed -o name); do
     kubectl logs $pod -n data --previous
   done

1. Si la cause première est l'épuisement des ressources, ajustez les limites ou mettez à l'échelle le cluster.
2. Après correction, supprimez l'ancien Job et recréez-le :

   kubectl delete job nightly-etl -n data --cascade=background
   kubectl apply -f nightly-etl.yaml

Conclusion

Comprendre l'architecture des Jobs Kubernetes est essentiel pour exécuter des charges de travail par lots fiables. En maîtrisant les composants, les options de configuration et les techniques de dépannage, vous pouvez vous assurer que vos Jobs se terminent avec succès et récupèrent gracieusement des échecs. Rappelez-vous les principes opérationnels : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés plutôt que des secrets, vérifier les résultats et documenter la récupération.

Comme prochaine étape, choisissez un Job à faible risque de votre environnement et suivez la liste de vérification : enregistrez l'état actuel, exécutez les vérifications documentées, comparez les résultats avec les signaux attendus et examinez les dépendances telles que CronJob (qui crée des Jobs selon un calendrier) ou les modèles de Pod. Un flux de travail fiable rend les échecs visibles, protège les valeurs sensibles et définit la vérification de la récupération avant qu'un incident ne survienne.

Avec les exemples et les commandes de ce guide, vous êtes équipé pour concevoir, déployer et exploiter les Jobs Kubernetes en toute confiance en production.