Generator Kubernetes Job i CronJob

Generator Kubernetes Job

Kubernetes Job uruchamia zadanie, które kończy się po wykonaniu pracy: migrację bazy, backup, import albo przetwarzanie wsadowe. W odróżnieniu od Deployment pody Joba nie działają w nieskończoność. Generator tworzy manifest batch/v1 typu Job albo CronJob (zadanie według harmonogramu), a pod wynikiem podaje gotowe polecenia kubectl dla wpisanej nazwy i namespace.

Najważniejsze pola

Przykład: migracja bazy

Preset „Migracje” ustawia nazwę db-migrate i polecenie php artisan migrate --force. Domyślny manifest zawiera apiVersion: batch/v1, kind: Job, namespace default, backoffLimit: 3, completions: 1, parallelism: 1, ttlSecondsAfterFinished: 3600 i restartPolicy: OnFailure. Polecenie trafia do kontenera jako /bin/sh -c "php artisan migrate --force", a obraz musi mieć przypięty tag lub digest, np. registry.example.com/myapp:1.0.0. Tag :latest jest odrzucany, bo przy ponowieniu węzeł mógłby pobrać inną wersję obrazu niż przy pierwszej próbie.

Pozostałe presety to „Backup” (pg_dump $DATABASE_URL > /backup/db.sql) i „Czyszczenie” (php artisan cleanup:old-records).

Uruchomienie

kubectl apply -f job.yaml, status: kubectl get job db-migrate -n default, logi: kubectl logs job/db-migrate -n default. W skryptach CI przydaje się kubectl wait --for=condition=complete job/db-migrate -n default --timeout=300s, które czeka na zakończenie zadania. CronJob uruchomisz ręcznie poza harmonogramem poleceniem kubectl create job --from=cronjob/nazwa nazwa-reczny.

Jak działa kontroler Job i co generuje narzędzie

Job nie uruchamia podów sam z siebie, robi to kontroler Joba działający w pętli sterowania. Czyta z manifestu liczbę wymaganych ukończeń (completions) i porównuje ją z liczbą podów zakończonych sukcesem. Dopóki udanych ukończeń jest mniej, kontroler tworzy kolejne pody na podstawie spec.template, ale nigdy więcej niż parallelism podów jednocześnie. Gdy liczba udanych ukończeń osiągnie completions, Job przechodzi w stan Complete i kontroler przestaje tworzyć nowe pody.

Drugim mechanizmem jest backoffLimit, czyli licznik niepowodzeń, a nie limit czasu. Każde nieudane podejście zwiększa ten licznik, a kolejne ponowienia startują z rosnącym opóźnieniem (10 s, 20 s, 40 s… do 6 minut). Gdy licznik zostanie przekroczony, Job dostaje stan Failed. Przy restartPolicy: Never każda porażka to nowy pod, a przy OnFailure kontener wstaje ponownie w tym samym podzie, przy czym te restarty też liczą się do backoffLimit. Limit czasu ustawia osobne pole activeDeadlineSeconds: po jego upływie Kubernetes przerywa wszystkie pody i oznacza Job jako nieudany, nawet jeśli ponowienia się nie wyczerpały.

Pole ttlSecondsAfterFinished jest znacznikiem dla kontrolera TTL: po zakończeniu Joba (sukces albo porażka) kontroler odczekuje zadany czas i usuwa obiekt razem z podami. Bez tego pola zakończone Joby zostają w klastrze. Generator składa pola w jeden manifest YAML. Nie łączy się z API Kubernetes, nie uruchamia podów i nie waliduje manifestu względem konkretnego klastra, sprawdza tylko poprawność nazw, obrazu, polecenia i zakresy liczb.

Przykład krok po kroku: import 10 paczek danych

1. Cel zadania: chcesz przetworzyć 10 paczek danych, każda ma być osobnym, udanym ukończeniem. Ustawiasz completions: 10.
2. Równoległość: parallelism: 3, więc kontroler trzyma w pracy najwyżej 3 pody naraz. Generator liczy minimalną liczbę rund jako ⌈10 / 3⌉ = 4: trzy pełne partie po 3 pody i ostatnia z 1 podem.
3. Ponowienia: backoffLimit: 3 oznacza 3 ponowienia po błędach. Czwarta porażka przekracza limit i cały Job przechodzi w stan Failed, nawet jeśli część paczek już się udała.
4. Restart kontenera: wybierasz restartPolicy: Never, bo przy imporcie chcesz zachować pody z błędem i ich logi do analizy.
5. Limit czasu: jeśli jedna paczka trwa około 5 minut, 4 rundy to co najmniej 20 minut (1200 s). Ustawiasz activeDeadlineSeconds: 1800, żeby zostawić zapas na ponowienia i ich opóźnienia. Wartość mniejsza niż 1200 s przerwie poprawnie działający import.
6. Sprzątanie: zostawiasz ttlSecondsAfterFinished: 3600, więc godzinę po zakończeniu kontroler TTL usunie Job wraz z podami. Logi zbierz wcześniej, bo znikną razem z podami.

Co jeszcze generator dodaje do manifestu

Praktyczne wskazówki przed wdrożeniem manifestu

• Zacznij od restartPolicy. Jeśli kontener ma sam wracać do pracy po chwilowym błędzie, wybierz OnFailure. Jeśli każda próba ma być osobnym podem z własnymi logami, wybierz Never.
• Nie ustawiaj parallelism wyżej, niż potrzebujesz. Przy completions: 10 i parallelism: 3 zadanie idzie w 4 rundach; parallelism równe completions uruchomi wszystkie pody naraz i obciąży klaster oraz współdzielone zasoby, na przykład bazę danych.
• Nie traktuj backoffLimit jako limitu czasu. Zadanie, które wisi bez błędu, przerwie dopiero activeDeadlineSeconds.
• Sprawdź readOnlyRootFilesystem. Opcja jest domyślnie włączona i blokuje zapis na dysk kontenera, więc preset „Backup” zapisujący /backup/db.sql wymaga dopisania wolumenu albo wyłączenia tej opcji.
• Zadbaj o idempotencję. Ponowienie uruchamia polecenie od początku, więc migracja czy import muszą znieść ponowne wykonanie.
• Nazwij Joba od zadania. metadata.name trafia do nazw podów, więc db-migrate jest czytelniejsze niż job-1, a przy ręcznym usuwaniu łatwiej trafić we właściwy obiekt.

Czego generator nie uwzględnia

• Brak walidacji względem klastra. Narzędzie nie sprawdza, czy obraz istnieje, czy namespace i Secret są utworzone ani czy kwoty klastra pozwolą uruchomić tyle podów, ile ustawisz w parallelism.
• Bez wolumenów i ConfigMap. Manifest nie zawiera wolumenów, montowań, ConfigMap ani serviceAccountName; przy backupie czy imporcie plików trzeba je dopisać ręcznie.
• Bez reguł schedulowania. Generator nie ustawia nodeSelector, tolerations ani affinity, a limity zasobów mają stałe wartości, które możesz zmienić w gotowym YAML.
• Tylko zwykły Job lub CronJob. Narzędzie nie tworzy Joba indeksowanego ani kolejki pracy z przypisaniem elementu do poda. Odrzuca też polecenia wieloliniowe oraz zawierające curl … | sh i rm -rf.