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>