web-dev-qa-db-fra.com

Que signifie exactement Kubernetes cronjobs `startingDeadlineSeconds`?

Dans Kubernetes cronjobs , il est indiqué dans la section limitations que

Les travaux peuvent ne pas s'exécuter si le contrôleur CronJob n'est pas en cours d'exécution ou interrompu pendant une période antérieure à l'heure de début du CronJob à l'heure de démarrage plus StartingDeadlineSeconds, ou si la plage couvre plusieurs heures de démarrage et concurrencyPolicy n'autorise pas la concurrence.

Ce que je comprends de ceci est que, si le startingDeadlineSeconds est réglé sur 10 et le cronjob n'a pas pu démarrer pour une raison quelconque à l'heure prévue, alors il peut toujours être tenté de recommencer tant que ces 10 les secondes ne se sont pas écoulées, cependant, après le 10 secondes, il ne sera certainement pas démarré, est-ce correct?

De plus, si j'ai concurrencyPolicy réglé sur Forbid, les K8 le comptent-ils comme un échec si un cronjob essaie d'être planifié, alors qu'il y en a déjà un en cours d'exécution?

kuberneteskubernetes-cronjob
10
Hesham Massoud

Après avoir étudié la base de code de la repo Kubernetes , voici comment fonctionne le contrôleur CronJob:

  1. Le contrôleur CronJob vérifiera toutes les 10 secondes la liste des tâches cron dans le client Kubernetes donné.

  2. Pour chaque CronJob, il vérifie le nombre de planifications manquées dans la durée du lastScheduleTime à maintenant. S'il y a plus de 100 horaires manqués , il ne démarre pas le travail et enregistre l'événement:

    "FailedNeedsStart", "Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew."

Il est important de noter que si le champ startingDeadlineSeconds est défini (pas nil), il comptera comment de nombreux travaux manqués se sont produits depuis la valeur de startingDeadlineSeconds jusqu'à maintenant. Par exemple, si startingDeadlineSeconds = 200, Il comptera le nombre de travaux manqués au cours de la dernière 200 secondes. L'implémentation exacte du comptage du nombre d'horaires manqués peut être trouvée ici .

  1. Dans le cas où il n'y a pas plus de 100 planifications manquées de l'étape précédente, le contrôleur CronJob vérifiera si l'heure now n'est pas après l'heure de son scheduledTime + startingDeadlineSeconds, c'est-à-dire qu'il n'est pas trop tard pour commencer le travail (dépassé le délai). S'il n'était pas trop tard, le travail continuera d'être tenté par le contrôleur CronJob. Cependant, s'il est déjà trop tard, il ne démarre pas le travail et enregistre l'événement:

    "Missed starting window for {cronjob name}. Missed scheduled time to start a job {scheduledTime}"

Il est également important de noter que si le champ startingDeadlineSeconds est défini (pas nil), cela signifie il n'y a pas de délai du tout défini, ce qui signifie que le travail sera tenté d'en démarrer un par le contrôleur CronJob sans vérifier s'il est plus tard ou non.

Par conséquent, pour répondre aux questions ci-dessus:

1. Si le StartingDeadlineSeconds est défini sur 10 et que le cronjob n'a pas pu démarrer pour une raison quelconque à son heure planifiée, alors il peut toujours être tenté de recommencer tant que ces 10 secondes ne se sont pas écoulées, cependant, après les 10 secondes, il ne sera certainement pas démarré, est-ce correct?

Le contrôleur CronJob tentera de démarrer le travail et il sera correctement planifié si les 10 secondes après l'heure de planification ne se sont pas encore écoulées. Cependant, si le délai est dépassé, il ne sera pas démarré cette exécution, et il sera compté comme un calendrier manqué dans les exécutions ultérieures.

2. Si j'ai concurrencyPolicy défini sur Forbid, les K8 le comptent-ils comme un échec si un cronjob essaie d'être planifié, alors qu'il y en a déjà un en cours d'exécution

Oui, cela sera considéré comme un horaire manqué. Étant donné que les horaires manqués sont calculés comme je l'ai indiqué ci-dessus au point 2.

18
Hesham Massoud