Anleitungen

Jobs und Cronjobs

Führen Sie einmalige Jobs und zeitgesteuerte Cronjobs auf nyxory aus, etwa für Batch-Arbeit, Migrationen und nächtliche Datenjobs. Ihr Agent rollt sie genauso aus wie eine App.

Nicht jede Aufgabe braucht einen dauerhaft laufenden Server. Eine Migration vor einer Umstellung oder ein nächtlicher Datenbank-Dump startet, erledigt seine Aufgabe, endet mit Exit-Code 0 und ist fertig. Ein Job läuft einmal, ein Cronjob nach Zeitplan. Ihr Agent rollt beides genauso aus wie eine App.

Job oder Cronjob ausrollen

Zwei Schritte, wie bei jeder App, nur ohne die Teile für den Server:

Image bauen. nyx_build_and_push_image aus Ihrem Repo, über denselben Build-Weg.
Manifest ausrollen. nyx_deploy_manifests mit der Spec des Jobs oder Cronjobs. Wie jedes Objekt, das zur App gehört, trägt sie die ownerReference der App und deren Label app.kubernetes.io/instance.

Ein Job oder Cronjob bekommt keinen Service, keine Domain und keine Probes. Es gibt keinen Traffic, der dorthin geleitet wird, und nichts, das ein Health-Check prüfen könnte. Entscheidend ist nur, ob der Lauf abgeschlossen wurde.

Wiederkehrende Arbeit planen

Ein Cronjob startet einen Container nach einem Zeitplan, den Sie festlegen. Damit ist er das Arbeitspferd für Routinearbeit im Betrieb, die ein Agent einmal einrichtet und dann laufen lässt:

Ein nächtliches Datenbank-Backup in Ihren Objektspeicher (auf der geteilten Plattform gibt es Backups sonst nur auf Anforderung, siehe Speicher und Backups).
Ein stündlicher Job, der Daten zusammenführt oder abgleicht: abrufen, umwandeln, schreiben, beenden.
Ein regelmäßiges Vorwärmen des Caches oder ein Aufräumlauf.

Ihr Agent schreibt den Zeitplan (spec.schedule in Standard-Cron-Syntax) und wendet ihn an. Ab dann startet der Container von selbst. Was im Container passiert, legen Sie fest. Der Cronjob garantiert nur, dass es pünktlich läuft.

Ist Auto-Deploy eingeschaltet, erreicht ein Push auch Cronjobs. nyxory übernimmt das neue Image in die Vorlage des Cronjobs, und der nächste geplante Lauf verwendet es. Ein einmaliger Job wird so nicht aktualisiert. Seine Pod-Vorlage lässt sich nicht ändern, starten Sie ihn deshalb selbst erneut.

Lauf prüfen

Warten Sie nicht auf einen Pod mit 1/1 Ready und rufen Sie nichts per curl auf, beides kommt nie. Prüfen Sie den Abschlussstatus und lesen Sie dann die Logs dieses Pods, um das eigentliche Ergebnis zu sehen.

Hinweis: Ein Job ist in Ordnung, wenn status.succeeded: 1 gilt. Ein Cronjob ist in Ordnung, wenn lastSuccessfulTime nach lastScheduleTime liegt. Ein noch laufender Pod bedeutet „in Arbeit“, nicht defekt. Ein verschwundener Pod bedeutet „schon fertig“, nicht fehlgeschlagen. Unterscheiden lassen sich beide Fälle nur am Abschlussstatus.

Wiederholte Läufe absichern

Die Plattform macht wiederholte Läufe nicht idempotent, das muss die Logik des Jobs selbst leisten. Denn ein erneutes Ausrollen oder ein verpasster Termin im Zeitplan kann die Arbeit doppelt ausführen. Sichern Sie sie ab: Schreibvorgänge, die nur anhängen, Prüfungen nach dem Muster „überspringen, wenn erledigt“, INSERT ... ON CONFLICT DO NOTHING oder ein Migrationswerkzeug, das festhält, welche Versionen schon gelaufen sind.

Zwei Einstellungen in der Spec verhindern, dass ein Zeitplan unter Last Schaden anrichtet. Ein startender Cronjob zehrt vom selben RAM- und CPU-Kontingent des Namespace wie jedes laufende Deployment. Setzen Sie deshalb auch hier echte Werte für requests/limits:

concurrencyPolicy: Forbid (oder Replace) verhindert, dass sich überlappende Läufe stapeln, wenn ein Lauf länger dauert als sein Intervall.
backoffLimit begrenzt die Wiederholungen, damit ein defekter Job nicht endlos Pods startet.

Zugehörige Tools: nyx_build_and_push_image, nyx_deploy_manifests, nyx_shell (für kubectl delete job/<name> sowie zum Lesen von Status und Logs).