Aller au contenu
CronExplain

Explicateur de planification Kubernetes CronJob

Un CronJob Kubernetes crée des Jobs selon une planification récurrente écrite en syntaxe cron standard. Collez la valeur de spec.schedule pour voir ce qu’elle signifie et quand les prochains Jobs seront créés.

Signification

Kubernetes CronJob : cinq champs standard plus macros. Définissez spec.timeZone pour utiliser un autre fuseau que celui du contrôleur.

✓ Valide · Signification

À l'heure pile, toutes les 6 heures

Préréglages

10 prochaines exécutions

#En UTCVotre heure locale
1——
2——
3——
4——
5——
6——
7——
8——
9——
10——

La même planification dans d’autres dialectes

  • crontab standard0 */6 * * *
  • Quartz0 0 */6 * * ?
  • AWS EventBridgecron(0 */6 * * ? *)Les règles EventBridge utilisent l’UTC.
  • Spring0 0 */6 * * *

Générateur visuel

Choisissez des valeurs pour chaque champ. Le générateur produit une expression standard à cinq champs, convertie dans le dialecte choisi lorsque vous l’utilisez.

Minute
Heure
Jour du mois
Mois
Jour de la semaine
0 9 * * 1-5

Le champ schedule

spec.schedule accepte une expression cron à cinq champs, par exemple "0 */6 * * *" pour toutes les six heures. Kubernetes accepte aussi des macros comme @hourly, @daily, @weekly, @monthly et @yearly. Mettez la valeur entre guillemets en YAML pour que les astérisques ne soient pas mal interprétés.

Fuseaux horaires avec spec.timeZone

Sans fuseau, les planifications sont interprétées dans le fuseau du kube-controller-manager, généralement l’UTC. Depuis Kubernetes 1.27, vous pouvez définir spec.timeZone avec un nom IANA comme Europe/Paris. Choisissez le même fuseau dans l’outil pour prévisualiser les heures exactes de création, changements d’heure compris.

Exécutions manquées et concurrence

Si le contrôleur manque une heure planifiée, startingDeadlineSeconds détermine jusqu’à quel point un Job peut encore démarrer en retard. concurrencyPolicy règle ce qui se passe quand une exécution est encore active : Allow, Forbid ou Replace. Gardez ces réglages en tête avec des planifications fréquentes comme chaque minute.

Utilisez kubectl create job --from=cronjob/<nom> <nom-du-job> pour lancer une exécution immédiate pendant vos tests, et kubectl get cronjob pour consulter les colonnes LAST SCHEDULE et ACTIVE. Les événements de l’objet CronJob expliquent pourquoi une heure planifiée a été sautée ou pourquoi un Job n’a pas pu démarrer.

Un manifeste minimal

Un CronJob utilise apiVersion batch/v1 et kind CronJob, avec spec.schedule, un spec.timeZone facultatif et un jobTemplate qui décrit le Pod à lancer. Mettez suspend: true pour suspendre la planification sans la supprimer, et réglez successfulJobsHistoryLimit et failedJobsHistoryLimit pour conserver plus ou moins de Jobs terminés à des fins de débogage.

Questions fréquentes

Un CronJob Kubernetes prend-il en charge les secondes ?
Non. La planification compte cinq champs : l’intervalle minimal est donc d’une minute.
Puis-je utiliser CRON_TZ dans la planification ?
Non. Les préfixes TZ et CRON_TZ ne sont pas pris en charge ; utilisez plutôt le champ spec.timeZone.
Que signifie 0 */6 * * * ?
Toutes les six heures, à l’heure pile : 00:00, 06:00, 12:00 et 18:00.
Pourquoi mon CronJob s’est-il exécuté deux fois, ou pas du tout ?
Vérifiez startingDeadlineSeconds et concurrencyPolicy, et si le contrôleur était indisponible. Les CronJobs visent environ un Job par heure planifiée, sans le garantir.