SupportConsoleDéveloppeursCommencer un essaiContact

4.2. Exécuter des tâches dans des pods à l'aide de jobs

Un job exécute une tâche dans votre cluster OpenShift Container Platform.

Un job suit la progression globale d'une tâche et met à jour son statut avec des informations sur les pods actifs, réussis et échoués. La suppression d'un job nettoiera toutes les répliques de pods qu'il a créées. Les tâches font partie de l'API Kubernetes, qui peut être gérée avec des commandes oc comme d'autres types d'objets.

Exemple de cahier des charges

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  parallelism: 1    1
  completions: 1    2
  activeDeadlineSeconds: 1800 3
  backoffLimit: 6   4
  template:         5
    metadata:
      name: pi
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: OnFailure    6

1
Les répliques de pods qu'un travail doit exécuter en parallèle.
2
Pour qu'un travail soit considéré comme achevé, il faut que les pods soient terminés avec succès.
3
Durée maximale d'exécution du travail.
4
Nombre de tentatives pour un travail.
5
Le modèle du module créé par le contrôleur.
6
La politique de redémarrage du pod.

Voir la documentation de Kubernetes pour plus d'informations sur les travaux.

4.2.1. Comprendre les jobs et les cron jobs

Un travail permet de suivre la progression globale d'une tâche et de mettre à jour son état avec des informations sur les modules actifs, réussis et échoués. La suppression d'un job nettoie tous les pods qu'il a créés. Les tâches font partie de l'API Kubernetes, qui peut être gérée avec des commandes oc comme d'autres types d'objets.

Il existe deux types de ressources possibles qui permettent de créer des objets run-once dans OpenShift Container Platform :

Emploi
Un travail régulier est un objet à exécution unique qui crée une tâche et s'assure qu'elle se termine.

Il existe trois principaux types de tâches susceptibles d'être exécutées en tant que travaux :

  • Travaux non parallèles :

    • Un travail qui ne démarre qu'un seul module, à moins que le module n'échoue.
    • Le travail est terminé dès que le pod se termine avec succès.

  • Travaux parallèles avec un nombre fixe d'achèvements :

    • un travail qui démarre plusieurs pods.
    • Le travail représente la tâche globale et est terminé lorsqu'il y a un pod réussi pour chaque valeur comprise entre 1 et la valeur completions.

  • Travaux parallèles avec une file d'attente :

    • Un travail avec plusieurs processus de travail en parallèle dans un pod donné.
    • OpenShift Container Platform coordonne les pods pour déterminer ce sur quoi chacun doit travailler ou utiliser un service de file d'attente externe.
    • Chaque pod est capable de déterminer indépendamment si tous les pods pairs sont complets et si le travail est terminé.
    • Lorsqu'un pod de la tâche se termine avec succès, aucun nouveau pod n'est créé.
    • Lorsqu'au moins un pod s'est terminé avec succès et que tous les pods sont terminés, le travail est terminé avec succès.
    • Lorsqu'un module est sorti avec succès, aucun autre module ne doit être en train de travailler sur cette tâche ou d'écrire une sortie. Les modules doivent tous être en train de se terminer.

Pour plus d'informations sur l'utilisation des différents types de tâches, voir Job Patterns dans la documentation Kubernetes.

Travail Cron
Une tâche peut être programmée pour être exécutée plusieurs fois, à l'aide d'une tâche cron.

Un cron job s'appuie sur un travail normal en vous permettant de spécifier comment le travail doit être exécuté. Les tâches Cron font partie de l'API Kubernetes, qui peut être gérée avec des commandes oc comme d'autres types d'objets.

Les tâches Cron sont utiles pour créer des tâches périodiques et récurrentes, comme l'exécution de sauvegardes ou l'envoi d'e-mails. Les tâches cron peuvent également planifier des tâches individuelles à un moment précis, par exemple si vous souhaitez planifier une tâche pendant une période de faible activité. Un travail cron crée un objet Job basé sur le fuseau horaire configuré sur le nœud du plan de contrôle qui exécute le contrôleur de travail cron.

Avertissement

Un travail cron crée un objet Job environ une fois par heure d'exécution de sa programmation, mais il peut arriver qu'il ne crée pas de travail ou que deux travaux soient créés. Par conséquent, les tâches doivent être idempotentes et vous devez configurer des limites d'historique.

4.2.1.1. Comprendre comment créer des emplois

Les deux types de ressources nécessitent une configuration de travail qui se compose des éléments clés suivants :

  • Un modèle de pod, qui décrit le pod créé par OpenShift Container Platform.

  • Le paramètre parallelism, qui indique combien de pods fonctionnant en parallèle à un moment donné doivent exécuter un travail.

    • Pour les travaux non parallèles, laissez le paramètre non défini. Si la valeur n'est pas définie, la valeur par défaut est 1.

  • Le paramètre completions, qui spécifie le nombre d'achèvements de pods réussis nécessaires pour terminer un travail.

    • Pour les travaux non parallèles, laissez le paramètre non défini. Si la valeur n'est pas définie, la valeur par défaut est 1.
    • Pour les travaux parallèles avec un nombre d'achèvements fixe, indiquez une valeur.
    • Pour les travaux parallèles avec une file d'attente, laissez la valeur non définie. Lorsqu'il n'est pas défini, il prend par défaut la valeur parallelism.

4.2.1.2. Comprendre comment fixer une durée maximale pour les travaux

Lors de la définition d'un travail, vous pouvez définir sa durée maximale en définissant le champ activeDeadlineSeconds. Ce champ est spécifié en secondes et n'est pas défini par défaut. S'il n'est pas défini, aucune durée maximale n'est imposée.

La durée maximale est calculée à partir du moment où un premier module est programmé dans le système et définit la durée pendant laquelle un travail peut être actif. Elle permet de suivre la durée totale d'une exécution. Après avoir atteint le délai spécifié, le travail est terminé par OpenShift Container Platform.

4.2.1.3. Comprendre comment mettre en place une politique de reprise des travaux en cas de défaillance d'un pod

Un travail peut être considéré comme échoué après un certain nombre de tentatives en raison d'une erreur logique dans la configuration ou d'autres raisons similaires. Les modules défaillants associés au travail sont recréés par le contrôleur avec un délai exponentiel (10s, 20s, 40s...) plafonné à six minutes. La limite est réinitialisée si aucun nouveau pod échoué n'apparaît entre les vérifications du contrôleur.

Le paramètre spec.backoffLimit permet de définir le nombre de tentatives pour un travail.

4.2.1.4. Comprendre comment configurer une tâche cron pour supprimer les artefacts

Les tâches Cron peuvent laisser des ressources artéfactuelles telles que des tâches ou des pods. En tant qu'utilisateur, il est important de configurer les limites de l'historique afin que les anciens travaux et leurs pods soient correctement nettoyés. Il y a deux champs dans la spécification du job cron qui sont responsables de cela :

  • .spec.successfulJobsHistoryLimit. Nombre de travaux terminés avec succès à conserver (3 par défaut).
  • .spec.failedJobsHistoryLimit. Nombre d'échecs de travaux terminés à conserver (1 par défaut).
Astuce

  • Supprimez les tâches cron dont vous n'avez plus besoin : 

    oc delete cronjob/<cron_job_name>

    Cela leur évite de générer des artefacts inutiles.

  • Vous pouvez suspendre les exécutions ultérieures en fixant la valeur de spec.suspend à true. Toutes les exécutions suivantes sont suspendues jusqu'à ce que vous réinitialisiez false.

4.2.1.5. Limites connues

La politique de redémarrage de la spécification des tâches ne s'applique qu'à pods, et non à job controller. Cependant, le contrôleur de tâches est codé en dur pour continuer à relancer les tâches jusqu'à ce qu'elles soient terminées.

Ainsi, restartPolicy: Never ou --restart=Never a le même comportement que restartPolicy: OnFailure ou --restart=OnFailure, c'est-à-dire que lorsqu'un travail échoue, il est redémarré automatiquement jusqu'à ce qu'il réussisse (ou qu'il soit écarté manuellement). La politique définit uniquement le sous-système qui effectue le redémarrage.

Avec la politique Never, c'est job controller qui effectue le redémarrage. À chaque tentative, le contrôleur de tâches incrémente le nombre d'échecs dans l'état de la tâche et crée de nouveaux modules. Cela signifie qu'à chaque tentative échouée, le nombre de pods augmente.

Avec la politique OnFailure, kubelet effectue le redémarrage. Chaque tentative n'incrémente pas le nombre d'échecs dans le statut du travail. De plus, kubelet réessayera les tâches qui ont échoué en démarrant des pods sur les mêmes nœuds.

4.2.2. Créer des emplois

Vous créez un job dans OpenShift Container Platform en créant un objet job.

Procédure

Créer un emploi :

  1. Créez un fichier YAML similaire au suivant : 

    apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  parallelism: 1    1
  completions: 1    2
  activeDeadlineSeconds: 1800 3
  backoffLimit: 6   4
  template:         5
    metadata:
      name: pi
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: OnFailure    6
    1
    Facultatif : Spécifiez le nombre de répliques de pods qu'un travail doit exécuter en parallèle ; la valeur par défaut est 1.
    • Pour les travaux non parallèles, laissez le paramètre non défini. Si la valeur n'est pas définie, la valeur par défaut est 1.
    2
    Facultatif : Indiquez le nombre de pods terminés avec succès pour qu'un travail soit considéré comme terminé.
    • Pour les travaux non parallèles, laissez le paramètre non défini. Si la valeur n'est pas définie, la valeur par défaut est 1.
    • Pour les travaux parallèles avec un nombre d'achèvements fixe, indiquez le nombre d'achèvements.
    • Pour les travaux parallèles avec une file d'attente, laissez la valeur non définie. Lorsqu'il n'est pas défini, il prend par défaut la valeur parallelism.
    3
    Facultatif : Indiquez la durée maximale d'exécution du travail.
    4
    Facultatif : Indiquez le nombre de tentatives pour un travail. La valeur par défaut de ce champ est de six.
    5
    Spécifiez le modèle du module créé par le contrôleur.
    6
    Spécifiez la politique de redémarrage du module :
    • Never. Ne pas relancer le travail.
    • OnFailure. Ne redémarrez le travail qu'en cas d'échec.

    • Always. Il faut toujours redémarrer le travail.

      Pour plus de détails sur la façon dont OpenShift Container Platform utilise la politique de redémarrage avec les conteneurs en panne, voir les États d'exemple dans la documentation Kubernetes.

  2. Créer l'emploi : 

    oc create -f <nom-de-fichier>.yaml
Note

Vous pouvez également créer et lancer un travail à partir d'une seule commande en utilisant oc create job. La commande suivante crée et lance un travail similaire à celui spécifié dans l'exemple précédent : 

$ oc create job pi --image=perl -- perl -Mbignum=bpi -wle 'print bpi(2000)'

4.2.3. Création de tâches cron

Vous créez un job cron dans OpenShift Container Platform en créant un objet job.

Procédure

Pour créer une tâche cron :

  1. Créez un fichier YAML similaire au suivant : 

    apiVersion: batch/v1
kind: CronJob
metadata:
  name: pi
spec:
  schedule: "*/1 * * * *"          1
  timeZone: Etc/UTC                2
  concurrencyPolicy: "Replace"     3
  startingDeadlineSeconds: 200     4
  suspend: true                    5
  successfulJobsHistoryLimit: 3    6
  failedJobsHistoryLimit: 1        7
  jobTemplate:                     8
    spec:
      template:
        metadata:
          labels:                  9
            parent: "cronjobpi"
        spec:
          containers:
          - name: pi
            image: perl
            command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
          restartPolicy: OnFailure 10
    1
    Planification de la tâche spécifiée au format cron. Dans cet exemple, le travail sera exécuté toutes les minutes.
    2
    Un fuseau horaire facultatif pour la programmation. Voir Liste des fuseaux horaires de la base de données tz pour les options valides. S'il n'est pas spécifié, le gestionnaire de contrôleur Kubernetes interprète la planification par rapport à son fuseau horaire local. Ce paramètre est proposé en tant qu'aperçu technologique.
    3
    Une politique de concurrence optionnelle, spécifiant comment traiter les tâches concurrentes au sein d'une tâche cron. Seule l'une des politiques de concurrence suivantes peut être spécifiée. Si elle n'est pas spécifiée, elle autorise par défaut les exécutions simultanées.
    • Allow permet aux tâches cron de s'exécuter simultanément.
    • Forbid interdit les exécutions simultanées, en sautant l'exécution suivante si la précédente n'est pas encore terminée.
    • Replace annule le travail en cours et le remplace par un nouveau.
    4
    Délai facultatif (en secondes) pour lancer le travail s'il dépasse l'heure prévue pour une raison quelconque. Les exécutions manquées seront considérées comme des échecs. Si ce délai n'est pas spécifié, il n'y a pas de date limite.
    5
    Un drapeau optionnel permettant de suspendre une tâche cron. S'il vaut true, toutes les exécutions suivantes seront suspendues.
    6
    Nombre de travaux terminés avec succès à conserver (3 par défaut).
    7
    Nombre d'échecs de travaux terminés à conserver (valeur par défaut : 1).
    8
    Modèle d'emploi. Ce modèle est similaire à l'exemple d'emploi.
    9
    Définit une étiquette pour les travaux créés par ce travail cron.
    10
    La politique de redémarrage du module. Elle ne s'applique pas au contrôleur de tâches.
    Note

    Les champs .spec.successfulJobsHistoryLimit et .spec.failedJobsHistoryLimit sont facultatifs. Ils indiquent le nombre de tâches terminées et échouées à conserver. Par défaut, ils sont respectivement fixés à 3 et 1. Définir une limite à 0 correspond à ne conserver aucun des travaux du type correspondant une fois qu'ils sont terminés.

  2. Créez la tâche cron : 

    oc create -f <nom-de-fichier>.yaml
Note

Vous pouvez également créer et lancer une tâche cron à partir d'une seule commande en utilisant oc create cronjob. La commande suivante crée et lance une tâche cron similaire à celle spécifiée dans l'exemple précédent : 

$ oc create cronjob pi --image=perl --schedule='*/1 * * * *' -- perl -Mbignum=bpi -wle 'print bpi(2000)'

Avec oc create cronjob, l'option --schedule accepte les programmes au format cron.

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.