Generator Kubernetes CronJob

Generator manifestu Kubernetes CronJob

CronJob uruchamia zadania według harmonogramu — np. kopie zapasowe, raporty czy czyszczenie danych. Tworzy Joby, a te — pody.

Harmonogram w formacie cron

0 2 * * * oznacza codziennie o 2:00. Uwaga: CronJob używa strefy UTC klastra.

Polityka współbieżności

• Allow — pozwala na równoległe uruchomienia.
• Forbid — pomija nowe, jeśli poprzednie trwa (bezpieczne dla backupów).
• Replace — przerywa poprzednie i startuje nowe.

Jak działa generator manifestu CronJob

Generator zbiera wartości z formularza i mapuje je na strukturę obiektu CronJob w API Kubernetes. Pole harmonogramu trafia do spec.schedule, ustawienia obrazu, komendy i restartPolicy do spec.jobTemplate.spec.template.spec. Dane o współbieżności oraz limitach historii są zapisywane w spec.concurrencyPolicy, spec.successfulJobsHistoryLimit i spec.failedJobsHistoryLimit. Na końcu narzędzie serializuje całość do YAML, który można zapisać i zastosować w klastrze.

Kluczową częścią jest walidacja harmonogramu. Cron w CronJob ma pięć pól: minuta 0-59, godzina 0-23, dzień miesiąca 1-31, miesiąc 1-12, dzień tygodnia 0-6. Generator sprawdza, czy każda wartość mieści się w zakresie i czy liczba pól się zgadza. Nie interpretuje strefy czasowej użytkownika, manifest zachowuje wartości dosłownie, a klaster odczytuje je w UTC.

Narzędzie nie uruchamia zadania. Tworzy tylko deklarację, na podstawie której kontroler CronJob w Kubernetes będzie cyklicznie tworzył Joby, a te pody. Dzięki temu ten sam manifest można przejrzeć, wersjonować i zastosować w dowolnym klastrze, o ile spełnia wymagania API. Generator nie łączy się z klastrem, nie sprawdza uprawnień RBAC i nie testuje obrazu kontenera.

Przykład: dzienny backup o 02:00 UTC

1. Wpisz nazwę CronJoba: backup-dzienny. W polu harmonogramu ustaw 0 2 * * *. To pięć pól: minuta 0, godzina 2, dzień miesiąca *, miesiąc *, dzień tygodnia *. Wynik: jedno uruchomienie na dobę o 02:00 UTC.
2. W szablonie Joba ustaw obraz backup:1.2 oraz komendę /bin/sh -c backup.sh. Wybierz restartPolicy OnFailure, ponieważ zadanie ma się zakończyć, a po błędzie może spróbować ponownie. Nie ustawiaj Always, bo nie pasuje do Joba.
3. Ustaw concurrencyPolicy Forbid. Jeśli poprzedni Job będzie jeszcze działał o 02:00 następnego dnia, nowe uruchomienie zostanie pominięte. To bezpieczne dla kopii zapasowej, która nie powinna nakładać się na siebie.
4. Ustaw successfulJobsHistoryLimit 3 i failedJobsHistoryLimit 1. Po zakończeniu w klastrze pozostaną maksymalnie 3 udane i 1 nieudany Job. Starsze zakończone obiekty będą usuwane.
5. Wygeneruj YAML i sprawdź, czy spec.schedule ma wartość 0 2 * * *, a spec.jobTemplate.spec.template.spec.restartPolicy to OnFailure. Sprawdź też, czy concurrencyPolicy ma wartość Forbid.
6. Zapisz plik jako backup-dzienny.yaml i zastosuj go w klastrze. Przy założeniu braku pominięć przez Forbid CronJob utworzy 31 Jobów w miesiącu 31-dniowym, 30 w 30-dniowym, 28 w lutym zwykłym i 29 w lutym przestępnym. W skali tygodnia będzie to 7 uruchomień, a w roku zwykłym 365, w przestępnym 366.

Tabela referencyjna ustawień CronJoba

Praktyczne wskazówki

• Przelicz godzinę na UTC przed wpisaniem harmonogramu. CronJob nie czyta strefy czasowej z formularza, więc 2:00 czasu lokalnego to inna wartość w polu godzina, zależnie od przesunięcia względem UTC. Zapisz w manifeście już przeliczoną godzinę.
• Dla zadań wrażliwych na nakładanie wybierz Forbid. Backupy, migracje i raporty zwykle nie powinny uruchamiać się równolegle; Forbid pominie nowy start, jeśli poprzedni Job nadal działa.
• Ustaw limity historii realistycznie. Zbyt duże wartości zostawiają wiele zakończonych Jobów i utrudniają przegląd; zbyt małe mogą usunąć dane potrzebne do diagnostyki. Wybierz liczby odpowiadające częstotliwości uruchomień.
• Nie wybieraj restartPolicy Always. W Jobie i CronJobie dozwolone są OnFailure albo Never; Always jest sprzeczne z naturą zadania, które ma się zakończyć.
• Sprawdź manifest przed zastosowaniem. Upewnij się, że nazwa, obraz, komenda, limity historii i polityka współbieżności odpowiadają zadaniu; generator nie zna Twojego klastra ani uprawnień.

Ograniczenia narzędzia

• Nie sprawdza stanu klastra. Generator nie wie, czy obraz istnieje, czy ServiceAccount ma uprawnienia i czy wolumeny lub sekrety są dostępne. Manifest może być poprawny składniowo, ale nie wystartuje z powodu błędów środowiska.
• Nie konwertuje stref czasowych. Harmonogram jest wpisywany dosłownie; jeśli podasz godzinę lokalną, CronJob zinterpretuje ją jako UTC. Narzędzie nie ostrzeże o różnicy ani nie doda informacji o strefie.
• Nie gwarantuje wykonania w dokładnym momencie. Kontroler może uruchomić Job z opóźnieniem zależnym od obciążenia klastra; manifest nie steruje czasem startu poza harmonogramem.
• Nie rozwiązuje konfliktów współbieżności poza wybraną polityką. Forbid pomija nowy start, Replace przerywa poprzedni, Allow dopuszcza równoległość, ale żadna opcja nie skróci działania Joba ani nie zwiększy zasobów.

Najczęstsze pytania