Dépannage · Kubernetes

Un CronJob Kubernetes qui ne s’exécute pas ? Diagnostiquez vite

Pourquoi un CronJob Kubernetes ne tourne pas — suspendu, fuseau horaire, politique de concurrence, pods en échec, fenêtres manquées — et comment corriger chaque cas.

Un CronJob Kubernetes ajoute ses propres modes d’échec à ceux du cron simple. Parcourez-les dans l’ordre.

1. Est-il suspendu ?

Un CronJob suspendu ne crée aucun Job :

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

2. Vérifiez le planning et le fuseau horaire

Par défaut, le planning est évalué dans le fuseau du kube-controller-manager (historiquement UTC). Depuis Kubernetes 1.27, vous pouvez le définir explicitement :

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

3. Examinez les Jobs récents et les événements

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

« Cannot determine if job needs to be started … missed start window » pointe vers le problème 4.

4. startingDeadlineSeconds et plannings manqués

Si le contrôleur est brièvement indisponible et que plus de 100 plannings sont manqués, le CronJob arrête complètement de planifier jusqu’à ce que vous le corrigiez. Définissez une deadline pour qu’un créneau manqué soit proprement ignoré :

spec:
  startingDeadlineSeconds: 200
  concurrencyPolicy: Forbid     # ne pas empiler des exécutions qui se chevauchent

5. Le pod tourne mais échoue

Un Job créé dont le pod plante n’est pas toujours évident. Inspectez-le :

kubectl logs job/<job-name>
kubectl describe pod <pod>      # erreurs de pull d’image, OOMKilled, problèmes de config

Définissez backoffLimit et failedJobsHistoryLimit pour que les échecs soient conservés et visibles.

Le problème de fond : un CronJob « vert » peut ne rien faire

Le fait que kubectl get cronjob affiche votre tâche ne signifie pas que du travail a lieu — les pods peuvent échouer en silence, les deadlines être manquées, un mauvais déploiement le suspendre. Le bruit au niveau du cluster les enterre souvent.

Faites pinguer un heartbeat par le conteneur de la tâche en cas de succès. Si les Jobs cessent de se terminer — pour quelque raison que ce soit — le ping manque et vous êtes alerté, indépendamment de la surveillance propre au cluster :

# dernière étape de la commande de votre conteneur
curl -fsS https://ping.steadycron.com/<votre-jeton-ping>