Warum in Kubernetes Cron Job zwei Jobs erstellt werden, oder kein Job erstellt werden könnte?

Question

In K8S Cron Job Limitations erwähnt, dass es keine Garantie dafür gibt, dass ein Auftrag genau einmal ausgeführt wird:

Ein Cron-Job über ein Job-Objekt erstellt einmal pro Ausführungszeit seines Zeitplan. Wir sagen "about", weil unter bestimmten Umständen zwei Jobs erstellt werden können oder kein Job erstellt wurde. Wir versuchen diese selten zu machen, aber verhindern sie nicht vollständig. Daher sollten Jobs

idempotent sein Könnte jemand erklären:

• , warum dies passieren könnte?
• Was sind die Wahrscheinlichkeiten/Statistik das könnte passieren?
• wird es in einigen vernünftigen Zukunft in k8s behoben werden?
• Gibt es Workarounds, um ein solches Verhalten zu verhindern (wenn der laufende Job nicht als idempotent implementiert werden kann)?
• andere tun Cron verwandte Dienste leiden mit dem gleichen Problem? Vielleicht ist es ein Kernproblem Cron?

Answer 1

Der Controller:

https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/cronjob/cronjob_controller.go

beginnt mit einem Kommentar, der den Grundstein für eine Erklärung legt:

I did not use watch or expectations. Those add a lot of corner cases, and we aren't expecting a large volume of jobs or scheduledJobs. (We are favoring correctness over scalability.) 

If we find a single controller thread is too slow because there are a lot of Jobs or CronJobs, we we can parallelize by Namespace. If we find the load on the API server is too high, we can use a watch and UndeltaStore.) 

Just periodically list jobs and SJs, and then reconcile them. 

Regelmäßig bedeutet alle 10 Sekunden:

https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/cronjob/cronjob_controller.go#L105

Die Dokumentation im Anschluss an den genannten Einschränkungen hat auch einige nützliche Farbe auf einige der Umstände, unter denen zwei Arbeitsplätze oder keine Aufträge können auf einem bestimmten Zeitplan gestartet werden:

If startingDeadlineSeconds is set to a large value or left unset (the default) and if concurrentPolicy is set to AllowConcurrent, the jobs will always run at least once. 

Jobs may fail to run if the CronJob controller is not running or broken for a span of time from before the start time of the CronJob to start time plus startingDeadlineSeconds, or if the span covers multiple start times and concurrencyPolicy does not allow concurrency. For example, suppose a cron job is set to start at exactly 08:30:00 and its startingDeadlineSeconds is set to 10, if the CronJob controller happens to be down from 08:29:00 to 08:42:00, the job will not start. Set a longer startingDeadlineSeconds if starting later is better than not starting at all. 

Higher Level, denn in einem nur einmal beschreibbaren Lösung verteiltes System ist schwer:

https://bravenewgeek.com/you-cannot-have-exactly-once-delivery/

Uhren und Zeitsynchronisation in einem verteilten System ist auch schwer:

https://8thlight.com/blog/rylan-dirksen/2013/10/04/synchronization-in-a-distributed-system.html

Zu den Fragen:

• , warum dies passieren könnte?

  Zum Beispiel - der Knoten, der den CronJobController hostet, schlägt zu dem Zeitpunkt fehl, zu dem ein Job ausgeführt werden soll.

• Was sind die Wahrscheinlichkeiten/Statistik das könnte passieren?

  Sehr unwahrscheinlich für einen bestimmten Lauf.Bei einer ausreichend großen Anzahl von Läufen ist es sehr unwahrscheinlich, dass Sie sich diesem Problem stellen müssen.

• wird es in einigen vernünftigen Zukunft in k8s behoben werden?

  Es gibt keine Probleme im Zusammenhang mit der idemopotenz unter dem Bereich/Batch-Label in der k8s Repo, so würde man nicht raten.

  https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Aarea%2Fbatch

• gibt es irgendwelche Workarounds ein solches Verhalten zu verhindern (wenn die laufenden Job nicht als idempotent umgesetzt werden können)?

  Denken Sie mehr über die spezifische Definition von idempotent und die speziellen Punkte in dem Job nach, wo es Commits gibt. Zum Beispiel können Jobs so erstellt werden, dass sie mehr als einmal Ausführung unterstützen, wenn sie den Status in den Staging-Bereichen speichern, und dann gibt es einen Wahlprozess, um zu bestimmen, wessen Arbeit gewinnt.

• leiden andere Cron-bezogene Dienste mit dem gleichen Problem? Vielleicht ist es ein Kernproblem Cron?

  Ja, es ist ein Kernproblem verteilter Systeme.

  Für die meisten Benutzer gibt die k8s-Dokumentation vielleicht eine präzisere und differenziertere Antwort als nötig. Wenn Ihr geplanter Job einige kritische medizinische Prozeduren steuert, ist es wirklich wichtig, Fehlerfälle zu planen. Wenn nur eine Systembereinigung durchgeführt wird, ist es nicht so wichtig, einen geplanten Lauf zu verpassen. Per Definition fallen fast alle Nutzer von k8s CronJobs in die letztere Kategorie.