Fehlerbehebung · Kubernetes

Kubernetes-CronJob läuft nicht? Schnell diagnostizieren

Warum ein Kubernetes-CronJob nicht läuft — suspendiert, Zeitzone, Concurrency-Policy, fehlgeschlagene Pods, verpasste Deadlines — und wie Sie es beheben.

Ein Kubernetes-CronJob bringt zusätzlich zum einfachen Cron eigene Fehlerquellen mit. Arbeiten Sie diese der Reihe nach ab.

1. Ist er suspendiert?

Ein suspendierter CronJob erstellt überhaupt keine Jobs:

kubectl get cronjob my-job -o jsonpath='{.spec.suspend}'   # true = suspendiert
kubectl patch cronjob my-job -p '{"spec":{"suspend":false}}'

2. Prüfen Sie Zeitplan und Zeitzone

Standardmäßig wird der Zeitplan in der Zeitzone des kube-controller-manager ausgewertet (historisch UTC). Seit Kubernetes 1.27 können Sie sie explizit setzen:

spec:
  schedule: "0 2 * * *"
  timeZone: "Europe/Berlin"

3. Sehen Sie sich aktuelle Jobs und Events an

kubectl get jobs --selector=job-name --sort-by=.metadata.creationTimestamp
kubectl describe cronjob my-job        # Events: "Created job", "Missed schedule"

„Cannot determine if job needs to be started … missed start window“ deutet auf Problem 4 hin.

4. startingDeadlineSeconds und verpasste Zeitpläne

Ist der Controller kurz down und werden mehr als 100 Zeitpläne verpasst, stoppt der CronJob die Planung vollständig, bis Sie es beheben. Setzen Sie eine Deadline, damit ein verpasster Slot sauber übersprungen wird:

spec:
  startingDeadlineSeconds: 200
  concurrencyPolicy: Forbid     # keine überlappenden Läufe stauen

5. Der Pod läuft, scheitert aber

Ein erstellter Job, dessen Pod fehlerhaft ist, ist nicht immer offensichtlich. Untersuchen Sie ihn:

kubectl logs job/<job-name>
kubectl describe pod <pod>      # Image-Pull-Fehler, OOMKilled, Konfigurationsprobleme

Setzen Sie backoffLimit und failedJobsHistoryLimit, damit Fehler erhalten und sichtbar bleiben.

Das tiefere Problem: Ein grüner CronJob kann trotzdem nichts tun

Dass kubectl get cronjob Ihren Job anzeigt, heißt nicht, dass Arbeit passiert — Pods können still scheitern, Deadlines verpasst werden, ein fehlerhafter Deploy ihn suspendieren. Cluster-weiter Lärm verschüttet diese oft.

Lassen Sie den Job-Container bei Erfolg einen Heartbeat anpingen. Hören Jobs auf, abzuschließen — aus welchem Grund auch immer —, bleibt der Ping aus und Sie werden alarmiert, unabhängig vom Monitoring des Clusters selbst:

# letzter Schritt Ihres Container-Befehls
curl -fsS https://ping.steadycron.com/<ihr-ping-token>