Ku­ber­netes surveille ac­ti­ve­ment l’exécution des CronJobs et exécute des actions pré­dé­fi­nies par l’uti­li­sa­teur en cas d’erreur. La con­fi­gu­ra­tion de Ku­ber­netes CronJobs s’effectue aisément à l’aide de fichiers YAML.

Un CronJob, c’est quoi au juste ?

Un CronJob est une méthode pour au­to­ma­ti­ser des tâches. En fait, c’est comme un réveil qui sonne à une heure précise. Selon le même principe, un CronJob peut être configuré pour qu’il exécute au­to­ma­ti­que­ment des tâches pré­dé­fi­nies à des heures précises. Un CronJob peut au­to­ma­ti­ser dif­fé­rents types de tâches telles que la mise à jour de bases de données, la sau­ve­garde de fichiers, l’exécution de scripts ou l’envoi d’emails à in­ter­valles réguliers. L’in­té­gra­tion de CronJobs dans la pla­te­forme Ku­ber­netes permet de sur­veil­ler les tâches et de les exécuter de manière isolée dans les con­te­neurs.

Conseil

Managed Ku­ber­netes de IONOS vous offre une pla­te­forme hautement per­for­mante dans laquelle vous pouvez con­fi­gu­rer des nœuds de travail selon vos besoins. La solution complète de gestion du Cloud IONOS assure un fonc­tion­ne­ment sans faille de votre cluster Ku­ber­netes.

Ku­ber­netes CronJob : con­fi­gu­ra­tion

La création d’un CronJob ressemble beaucoup à celle d’un Job (tâche) standard dans Ku­ber­netes. Pour ce faire, vous devez créer un fichier manifest.yaml. Il s’agit d’une des­crip­tion struc­tu­rée contenant tous les détails per­ti­nents pour le CronJob. Y sont définis des pa­ra­mètres im­por­tants tels que le pla­ni­fi­ca­teur d’exécution du job, les con­te­neurs ainsi que les commandes exactes qui doivent être exécutées dans ces con­te­neurs.

Création d’un fichier YAML

Ouvrez un éditeur de texte de votre choix pour créer le fichier de con­fi­gu­ra­tion YAML pour le CronJob. Veillez à définir la pla­ni­fi­ca­tion du CronJob en format Cron. Ajoutez la dé­fi­ni­tion du job, y compris la tâche à exécuter. En­re­gis­trez ensuite le fichier en lui donnant l’extension .yaml.

apiVersion: batch/v1
kind: CronJob
metadata:
    name: new_cronjob
spec:
    schedule: "0    **     ** "
    jobTemplate:
        spec:
            template:
                spec:
                    containers:
                    - name: container
                        image: image-name:latest
                        command:
                        - /bin/sh
yaml

Ajoutez, le cas échéant, des exigences en termes de res­sources et d’autres pa­ra­mètres à la spé­ci­fi­ca­tion du pod :

spec:
    containers:
    - name: container
        resources:
            requests:
                memory: "64Mi"
                cpu: "250m"
            limits:
                memory: "128Mi"
                cpu: "500m"
yaml

Ac­ti­va­tion du CronJob

Saisissez la commande suivante dans un terminal pour créer le CronJob dans le cluster Ku­ber­netes :

kubectl apply -f [filename].yaml
shell

Contrôle du CronJob

En exécutant la commande suivante, vous obtenez une liste des Ku­ber­netes CronJobs existants et le mode Watch (mode sur­veil­lance) veille à ce que la sortie soit au­to­ma­ti­que­ment ac­tua­li­sée lorsque le statut des CronJobs change.

kubectl get cronjob --watch
shell

Syntaxe du ca­len­drier CronJob

La Schedule-Syntax (syntaxe du pla­ni­fi­ca­teur) pour les Ku­ber­netes CronJobs est basée sur le format Cron classique com­pre­nant cinq champs dans l’ordre suivant : minute, heure, jour du mois, mois et jour de la semaine. Elle prend la forme suivante :

  • Minute (0–59)
  • Heure (0–23)
  • Jour du mois (1–31)
  • Mois (1–12 ou Jan–Déc.)
  • Jour de la semaine (0–7 ou Dim–Sam)

Ca­rac­tères spéciaux :

  • * : toute valeur valable pour le champ
  • , : in­di­ca­tion de plusieurs valeurs
  • / : in­di­ca­tion des étapes

Exemples :

0 ** ** : toutes les heures 15 2 ** * : tous les jours à 2h15 0 0 1 ** : le premier jour de chaque mois à minuit 0 0 *3* : tous les jours à minuit en mars 0 2 ** 1 : tous les lundis à 2 heures du matin

Règle de si­mul­ta­néité CronJob

La règle de si­mul­ta­néité peut être spécifiée dans la con­fi­gu­ra­tion d’un CronJob et a un impact sur la façon dont les tâches pa­ral­lèles sont traitées au sein du même Ku­ber­netes CronJob.

  • Allow (par défaut) : si la règle de si­mul­ta­néité est pa­ra­mé­trée sur Allow (autoriser) un nouveau job est lancé, même si le job précédent n’est pas encore terminé. Cela signifie que plusieurs instances d’un même job peuvent être exécutées en même temps.
  • Forbid : ce paramètre permet de ne pas lancer un nouveau job si un job précédent n’est pas encore terminé. Il permet aussi de s’assurer qu’une seule instance du job est exécutée à un moment donné.
  • Replace : les jobs non terminés sont in­ter­rom­pus afin que les nouveaux jobs puissent continuer. Aucune instance du même job ne peut être exécutée en même temps.

Fixation d’un délai pour l’exécution

Le champ startingDeadlineSeconds dans un Ku­ber­netes CronJob indique le nombre maximal de secondes au­to­ri­sées après l’heure d’exécution planifiée, pour lancer un job. Si le job ne s’exécute pas dans ce laps de temps, il est considéré comme échoué.

apiVersion: batch/v1
kind: CronJob
metadata:
    name: new_cronjob
spec:
    schedule: "0    **     ** "
    startingDeadlineSeconds: 300 
    jobTemplate:
        spec:
            template:
                spec:
                    containers:
                    - name: container
                        image: image-name:latest
                        command:
                     - /bin/sh
yaml

Dans cet exemple, le job défini par le CronJob doit être lancé dans les 300 secondes (5 minutes) après l’heure fixée, sans quoi il sera considéré comme un échec.

Limiter l’his­to­rique des jobs

Dans Ku­ber­netes CronJobs, les pa­ra­mètres spec.successfulJobsHistoryLimit (limite de l’his­to­rique des jobs réussis) et spec.failedJobsHistoryLimit (limite de l’his­to­rique des jobs échoués) offrent la pos­si­bi­lité de limiter le nombre de jobs conservés dans l’his­to­rique du CronJob. spec.successfulJobsHistoryLimit est un champ fa­cul­ta­tif qui fixe le nombre de tâches terminées avec succès qui doivent être sau­ve­gar­dées dans l’his­to­rique. Cela est utile pour gérer l’uti­li­sa­tion des res­sources et s’assurer que l’his­to­rique n’est pas surchargé par un nombre excessif de tâches terminées avec succès. De la même façon, spec.failedJobsHistoryLimit permet de limiter le nombre de jobs ayant échoué présents dans l’his­to­rique.

apiVersion: batch/v1
kind: CronJob
metadata:
    name: new_cronjob
spec:
    schedule: "0    **     ** "
    successfulJobsHistoryLimit: 3    # Keep only the last 3 successfully completed jobs in history.
    failedJobsHistoryLimit: 1                    # Keep only the last failed job in history.
    jobTemplate:
        spec:
            template:
                spec:
                    containers:
                    - name: container
                        image: image-name:latest
                        command:
                     - /bin/sh
yaml

Dans l’exemple ci-dessus, nous indiquons de ne conserver dans l’his­to­rique du CronJob Ku­ber­netes new_cronjob uni­que­ment les trois derniers jobs terminés avec succès et le dernier job ayant échoué.

Ku­ber­netes CronJob : erreurs et dépannage

Dif­fé­rentes erreurs peuvent survenir dans les CronJobs Ku­ber­netes. Il est donc important de connaître les tech­niques de dépannage efficaces. Voici quelques sources d’erreurs courantes et des méthodes pour y remédier :

Le job ne s’exécute pas

Si un CronJob ne s’exécute pas dans Ku­ber­netes, cela peut avoir plusieurs causes. Une image de conteneur erronée ou non dis­po­nible, voire des au­to­ri­sa­tions man­quantes pour le compte de service du pod, peuvent en être la cause. Pour cerner le problème, examinez les logs du conteneur avec kubectl logs <pod-name>, les évé­ne­ments du CronJob avec kubectl describe cronjob <cronjob-name>, et les évé­ne­ments du pod avec kubectl describe pod <pod-name>. Assurez-vous que le compte de service dispose des au­to­ri­sa­tions requises en vérifiant le rôle et la liaison des rôles (Ro­le­Bin­ding).

Con­fi­gu­ra­tion CronJob erronée

Des erreurs de syntaxe dans le fichier YAML ou des pa­ra­mètres invalides pour Schedule et Res­tart­Po­licy peuvent être à l’origine d’une mauvaise con­fi­gu­ra­tion de CronJob. Afin d’iden­ti­fier ce type de problèmes, vérifiez la syntaxe et les pa­ra­mètres du fichier YAML. Avec kubectl describe cronjob <cronjob-name>, vous pouvez obtenir des in­for­ma­tions dé­tail­lées sur la con­fi­gu­ra­tion et détecter d’éven­tuelles erreurs ou in­co­hé­rences.

Dé­pas­se­ment des limites de res­sources

Le dé­pas­se­ment des limites de res­sources peut entraîner une exécution in­cor­recte des CronJobs. Pour résoudre le problème, vérifiez les limites de res­sources dans le CronJob et les pods associés avec kubectl describe cronjob <cronjob-name> et kubectl describe pod <pod-name>. Par ailleurs, la sur­veil­lance de l’uti­li­sa­tion des res­sources du cluster avec kubectl top nodes et kubectl top pods peut fournir des in­di­ca­tions pré­cieuses. Le cas échéant, modifiez les limites de res­sources dans le fichier YAML.

Pour vous initier à la gestion de clusters dans Ku­ber­netes, nous vous re­com­man­dons le tutoriel Ku­ber­netes de notre Digital Guide.

Managed Ku­ber­netes de IONOS Cloud
Or­ches­trez vos charges de travail en toute sécurité

Managed Ku­ber­netes est la pla­te­forme idéale pour des ap­pli­ca­tions de con­te­neurs per­for­mantes et hautement évo­lu­tives.

Aller au menu principal