Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

5.2. Exécution de tâches dans des pods à l’aide d’emplois

Le travail exécute une tâche dans votre cluster dédié OpenShift.

Le travail suit l’avancement global 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 travail nettoie toutes les répliques de gousses 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 spécification d’emploi

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 

#...
Copy to Clipboard Toggle word wrap

1
Les répliques de la gousse doivent être exécutées en parallèle.
2
Des achèvements réussis de la pod sont nécessaires pour marquer un travail accompli.
3
La durée maximale du travail peut être exécutée.
4
Le nombre de retries pour un emploi.
5
Le modèle pour le pod créé par le contrôleur.
6
La politique de redémarrage du pod.

Ressources supplémentaires

  • Emplois dans la documentation Kubernetes

5.2.1. Comprendre les emplois et les emplois cron
Copier lien

Le travail suit l’avancement global 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 travail nettoie toutes les gousses 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.

Il existe deux types de ressources possibles qui permettent de créer des objets en cours d’exécution dans OpenShift Dedicated:

Emploi

Le travail régulier est un objet qui crée une tâche et assure la fin du travail.

Il existe trois principaux types de tâches appropriées à exécuter en tant que travail:

  • Emplois non parallèles:

    • C’est un travail qui ne commence qu’un seul pod, à moins que la gousse échoue.
    • Le travail est terminé dès que son pod se termine avec succès.

  • Emplois parallèles avec un nombre d’achèvements fixes:

    • C’est un travail qui commence plusieurs pods.
    • Le travail représente la tâche globale et est terminé lorsqu’il y a un pod réussi pour chaque valeur de la gamme 1 à la valeur d’achèvement.

  • Emplois parallèles avec une file d’attente de travail:

    • Emploi avec plusieurs processus parallèles d’ouvrier dans une gousse donnée.
    • Des pods de coordonnées dédiées pour déterminer sur quoi chacun devrait fonctionner ou utiliser un service de file d’attente externe.
    • Chaque gousse est indépendamment capable de déterminer si toutes les gousses de pairs sont complètes et que l’ensemble du travail est fait.
    • Lorsque n’importe quelle gousse du travail se termine avec succès, aucune nouvelle gousse n’est créée.
    • Lorsqu’au moins une gousse a pris fin avec succès et que toutes les gousses sont terminées, le travail est terminé avec succès.

    • Lorsqu’une gousse est sortie avec succès, aucune autre gousse ne devrait faire de travail pour cette tâche ou écrire une sortie. Les gousses devraient tous être en train de sortir.

      En savoir plus sur la façon d’utiliser les différents types d’emploi, consultez Job Patterns dans la documentation Kubernetes.

Cron job

Le travail peut être programmé pour fonctionner plusieurs fois, en utilisant un travail cron.

Le travail cron s’appuie sur un travail régulier 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 emplois Cron peuvent également planifier des tâches individuelles pour une période spécifique, par exemple si vous souhaitez planifier un emploi pour une période d’activité faible. Le travail cron crée un objet Job basé sur le fuseau horaire configuré sur le nœud de plan de contrôle qui exécute le contrôleur cronjob.

Avertissement

Le travail cron crée un objet Job environ une fois par heure d’exécution de son calendrier, mais il y a des circonstances dans lesquelles il ne crée pas un emploi ou deux emplois pourraient être créés. Les emplois doivent donc être idempotents et vous devez configurer des limites d’historique.

5.2.1.1. Comprendre comment créer des emplois
Copier lien

Les deux types de ressources nécessitent une configuration de travail qui se compose des parties clés suivantes:

  • Le modèle de pod, qui décrit le pod qu’OpenShift Dedicated crée.

  • Le paramètre parallélisme, qui spécifie combien de pods fonctionnant en parallèle à n’importe quel moment dans le temps doit exécuter une tâche.

    • Dans le cas d’emplois non parallèles, laissez tomber. Lorsqu’il n’est pas défini, la valeur par défaut est 1.

  • Le paramètre d’achèvement, spécifiant le nombre d’achèvements réussis de la pod sont nécessaires pour terminer un travail.

    • Dans le cas d’emplois non parallèles, laissez tomber. Lorsqu’il n’est pas défini, la valeur par défaut est 1.
    • Dans le cas des tâches parallèles avec un nombre d’achèvements fixes, spécifiez une valeur.
    • Dans le cas des tâches parallèles avec une file d’attente de travail, laissez tomber. Lorsque l’unset est par défaut à la valeur par parallélisme.

Lors de la définition d’une tâche, vous pouvez définir sa durée maximale en définissant le champ ActiveDeadlineSeconds. Il est spécifié en secondes et n’est pas défini par défaut. Lorsqu’il n’est pas défini, il n’y a pas de durée maximale appliquée.

La durée maximale est comptée à partir du moment où un premier pod est programmé dans le système, et définit combien de temps un travail peut être actif. Il suit le temps global d’une exécution. Après avoir atteint le délai spécifié, le travail est résilié par OpenShift Dedicated.

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

Le paramètre spec.backoffLimit permet de définir le nombre de retries pour une tâche.

Les emplois cron peuvent laisser derrière eux des ressources d’artefacts telles que des emplois ou des pods. En tant qu’utilisateur, il est important de configurer les limites de l’historique afin que les anciens travaux et leurs gousses soient correctement nettoyés. Il y a deux domaines dans la spécification de cron qui en est responsable:

  • .spec.successfulJobsHistoryLimit. Le nombre d’emplois terminés réussis à conserver (par défaut à 3).
  • .spec.failedJobsHistoryLimit. Le nombre d’emplois terminés à conserver (par défaut à 1).

5.2.1.5. Limites connues
Copier lien

La politique de redémarrage de la spécification des tâches ne s’applique qu’aux pods, et non au contrôleur d’emploi. Cependant, le contrôleur d’emploi est codé dur pour continuer à réessayer les tâches jusqu’à l’achèvement.

En tant que tel, redémarrerPolicy: Ne jamais ou --restart=N’entraîne jamais le même comportement que redémarrerPolicy: OnFailure ou --restart=OnFailure. Autrement dit, lorsqu’un travail échoue, il est redémarré automatiquement jusqu’à ce qu’il réussisse (ou qu’il soit abandonné manuellement). La stratégie définit uniquement quel sous-système effectue le redémarrage.

Avec la politique Never, le contrôleur de travail effectue le redémarrage. À chaque tentative, le contrôleur de travail augmente le nombre d’échecs dans le statut de l’emploi et crée de nouveaux pods. Cela signifie qu’à chaque tentative ratée, le nombre de gousses augmente.

Avec la politique OnFailure, kubelet effectue le redémarrage. Chaque tentative n’augmente pas le nombre d’échecs dans le statut de l’emploi. En outre, kubelet réessaiera les tâches échouées en commençant des pods sur les mêmes nœuds.

5.2.2. Créer des emplois
Copier lien

Créer un job dans OpenShift Dédié en créant un objet de travail.

Procédure

Créer un emploi:

  1. Créez un fichier YAML similaire à ce qui suit: 

    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 
    
#...
    Copy to Clipboard Toggle word wrap
    1
    Facultatif : Spécifiez le nombre de répliques de pod qu’une tâche devrait exécuter en parallèle; par défaut à 1.
    • Dans le cas d’emplois non parallèles, laissez tomber. Lorsqu’il n’est pas défini, la valeur par défaut est 1.
    2
    Facultatif: Spécifiez combien de réussites de la pod sont nécessaires pour marquer un travail terminé.
    • Dans le cas d’emplois non parallèles, laissez tomber. Lorsqu’il n’est pas défini, la valeur par défaut est 1.
    • Dans le cas des travaux parallèles avec un nombre d’achèvements fixes, spécifiez le nombre d’achèvements.
    • Dans le cas des tâches parallèles avec une file d’attente de travail, laissez tomber. Lorsque l’unset est par défaut à la valeur par parallélisme.
    3
    Facultatif: Spécifiez la durée maximale que le travail peut exécuter.
    4
    Facultatif: Spécifiez le nombre de retries pour un travail. Ce champ est par défaut à six.
    5
    Indiquez le modèle pour le pod que le contrôleur crée.
    6
    Indiquez la politique de redémarrage du pod:
    • Jamais. « ne redémarrez pas le travail.
    • À l’échec. Redémarrez le travail seulement s’il échoue.

    • C’est toujours ça. Redémarrez toujours le travail.

      En savoir plus sur la façon dont OpenShift Dedicated utilise une politique de redémarrage avec des conteneurs défaillants, voir l’exemple des États dans la documentation de Kubernetes.

  2. Créer le job: 

    $ oc create -f <file-name>.yaml
    Copy to Clipboard Toggle word wrap
Note

Il est également possible de créer et de lancer une tâche à partir d’une seule commande à l’aide d’oc create job. La commande suivante crée et lance une tâche similaire à celle spécifiée dans l’exemple précédent: 

$ oc create job pi --image=perl -- perl -Mbignum=bpi -wle 'print bpi(2000)'
Copy to Clipboard Toggle word wrap

5.2.3. Créer des emplois cron
Copier lien

Créer une tâche cron dans OpenShift Dédié en créant un objet de travail.

Procédure

Créer un travail cron:

  1. Créez un fichier YAML similaire à ce qui suit: 

    apiVersion: batch/v1
kind: CronJob
metadata:
  name: pi
spec:
  schedule: "*/1 * * * *"
    1 
    
  concurrencyPolicy: "Replace"
    2 
    
  startingDeadlineSeconds: 200
    3 
    
  suspend: true
    4 
    
  successfulJobsHistoryLimit: 3
    5 
    
  failedJobsHistoryLimit: 1
    6 
    
  jobTemplate:
    7 
    
    spec:
      template:
        metadata:
          labels:
    8 
    
            parent: "cronjobpi"
        spec:
          containers:
          - name: pi
            image: perl
            command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
          restartPolicy: OnFailure
    9
    Copy to Clipboard Toggle word wrap
    1
    Calendrier de la tâche spécifiée au format cron. Dans cet exemple, le travail fonctionnera chaque minute.
    2
    C’est une politique facultative de concurrence qui spécifie comment traiter les emplois simultanés au sein d’un emploi cron. Il n’est possible de spécifier qu’une seule des politiques concurrentes suivantes. Dans le cas contraire, cela par défaut permet d’autoriser des exécutions simultanées.
    • Autoriser les travaux cron à fonctionner simultanément.
    • Interdit les courses simultanées, en sautant la prochaine course si la précédente n’est pas encore terminée.
    • Le remplacement annule le travail en cours d’exécution et le remplace par un nouveau.
    3
    Date limite facultative (en secondes) pour commencer le travail s’il manque l’heure prévue pour quelque raison que ce soit. Les exécutions d’emplois manquées seront comptabilisées comme ayant échoué. Dans le cas contraire, il n’y a pas de délai.
    4
    Drapeau optionnel permettant la suspension d’un travail cron. En cas de définition de true, toutes les exécutions ultérieures seront suspendues.
    5
    Le nombre d’emplois terminés réussis à conserver (par défaut à 3).
    6
    Le nombre d’emplois terminés à conserver (par défaut à 1).
    7
    Le modèle de travail. Ceci est similaire à l’exemple de travail.
    8
    Définit une étiquette pour les emplois engendrés par ce travail cron.
    9
    La politique de redémarrage du pod. Cela ne s’applique pas au contrôleur d’emploi.
    Note

    Les champs .spec.successfulJobsHistoryLimit et .spec.failedJobsHistoryLimit sont facultatifs. Ces champs spécifient combien d’emplois terminés et échoués doivent être conservés. Ils sont définis par défaut sur 3 et 1 respectivement. Fixer une limite à 0 correspond à ne garder aucun du type de travail correspondant après avoir terminé.

  2. Créer le travail cron: 

    $ oc create -f <file-name>.yaml
    Copy to Clipboard Toggle word wrap
Note

Il est également possible de créer et de lancer une tâche cron à partir d’une seule commande en utilisant oc create cronjob. La commande suivante crée et lance un travail cron similaire à celui spécifié dans l’exemple précédent: 

$ oc create cronjob pi --image=perl --schedule='*/1 * * * *' -- perl -Mbignum=bpi -wle 'print bpi(2000)'
Copy to Clipboard Toggle word wrap

Avec oc créer cronjob, l’option --schedule accepte les horaires au format cron.

Retour au début
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. Découvrez nos récentes mises à jour.

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 le Blog 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.

Theme

© 2025 Red Hat