Monitoring Kubernetes CronJob

Surveillez efficacement vos jobs planifiés dans Kubernetes

Les CronJobs Kubernetes permettent d'exécuter des pods selon un schedule défini, exactement comme le cron Unix classique. Dans les environnements cloud-native modernes, ils sont utilisés pour des tâches de maintenance, de backup, de synchronisation et de traitement batch. Leur surveillance est critique car dans un cluster actif avec des centaines de pods, les échecs de CronJobs passent facilement inaperçus.

La complexité de Kubernetes introduit de nombreux points de défaillance potentiels : image de conteneur non trouvée, ressources insuffisantes pour scheduler le pod, CrashLoopBackOff sur le conteneur, timeout dépassé, ou simplement un CronJob suspendu par erreur. Ces problèmes sont souvent silencieux car Kubernetes ne dispose pas d'alerting natif pour les CronJobs.

MoniTao complète parfaitement l'écosystème Kubernetes en ajoutant une couche de monitoring heartbeat externe. En intégrant un simple appel curl dans vos conteneurs, vous êtes alerté instantanément si un CronJob ne s'exécute pas correctement, indépendamment de la cause sous-jacente.

Concepts Kubernetes essentiels

Comprendre l'architecture des CronJobs K8s est essentiel pour configurer un monitoring efficace.

CronJob : ressource qui définit le schedule (format cron) et le template du Job à créer. Le CronJob lui-même ne fait qu'orchestrer la création périodique de Jobs.
Job : instance d'exécution créée par le CronJob à chaque déclenchement. Un Job peut créer un ou plusieurs Pods et assure qu'ils se terminent avec succès.
Pod : unité d'exécution contenant un ou plusieurs conteneurs. C'est dans le Pod que votre script s'exécute réellement.
Completion : état indiquant qu'un Job a terminé avec succès (exit code 0). C'est le signal que Kubernetes utilise pour marquer un Job comme réussi.

Défis spécifiques à Kubernetes

Les CronJobs Kubernetes présentent des défis uniques par rapport aux crons traditionnels.

CrashLoopBackOff : le conteneur redémarre en boucle après des échecs répétés. Le Job peut sembler actif mais ne progresse jamais.
Image non trouvée : erreur ImagePullBackOff si le registry est inaccessible ou l'image n'existe pas. Le pod reste bloqué.
Pending indéfini : ressources insuffisantes dans le cluster pour scheduler le pod. Peut durer indéfiniment sans alerte.
Concurrency policy : avec concurrencyPolicy: Forbid, un nouveau Job n'est pas créé si le précédent est encore en cours. Peut masquer des problèmes de performance.

Stratégies de monitoring

Plusieurs approches permettent d'intégrer le monitoring heartbeat dans vos CronJobs Kubernetes.

Curl en fin de script : ajoutez curl en dernière commande du conteneur. Simple et efficace, le ping n'est envoyé que si tout le script a réussi.
Init container : pour les cas complexes, un init container peut envoyer un ping de démarrage avant l'exécution principale.
Sidecar pattern : un conteneur sidecar peut monitorer l'état du conteneur principal et envoyer des pings en conséquence.
Operator personnalisé : pour les environnements avancés, un Kubernetes Operator peut automatiser le monitoring de tous les CronJobs.

Exemple de CronJob avec heartbeat

Voici un exemple de manifeste CronJob Kubernetes avec monitoring heartbeat intégré :

apiVersion: batch/v1
kind: CronJob
metadata:
  name: backup-daily
spec:
  schedule: "0 2 * * *"  # 2h00 chaque jour
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
          - name: backup
            image: my-backup-image:latest
            command:
            - /bin/sh
            - -c
            - |
              /scripts/backup.sh && \
              curl -fsS "https://api.monitao.com/ping/YOUR_TOKEN"
            resources:
              requests:
                memory: "256Mi"
                cpu: "100m"
              limits:
                memory: "512Mi"
                cpu: "500m"

Le && assure que le curl n'est exécuté que si le backup réussit. Avec restartPolicy: OnFailure, K8s réessaiera automatiquement si le conteneur échoue, mais MoniTao vous alertera du retard.

Configuration des alertes

Configurez vos alertes MoniTao pour couvrir les différents scénarios d'échec Kubernetes.

Job non créé : aucun Job n'a été créé à l'heure prévue. Vérifiez que le CronJob n'est pas suspendu et que le schedule est correct.
Pod en erreur : le pod est en état Failed ou CrashLoopBackOff. Consultez les logs avec kubectl logs.
Timeout dépassé : le Job n'a pas terminé dans le délai attendu. Peut indiquer un problème de performance ou un blocage.
Heartbeat absent : aucun ping reçu dans le délai configuré. Cause la plus fréquente : échec silencieux du script.

Checklist CronJob Kubernetes

CronJob déployé et non suspendu (suspend: false)
Schedule vérifié avec timezone correct
Resources requests/limits définies
Heartbeat MoniTao intégré au conteneur
Test manuel avec kubectl create job --from=cronjob/
Monitoring des événements K8s en place

Questions fréquentes sur Kubernetes CronJob

Mon CronJob ne crée pas de Job à l'heure prévue. Pourquoi ?

Vérifiez plusieurs points : suspend n'est pas à true, le schedule est valide, le CronJob n'a pas atteint failedJobsHistoryLimit. Utilisez kubectl describe cronjob pour voir l'historique.

Comment tester un CronJob sans attendre le schedule ?

Créez un Job manuel à partir du CronJob : kubectl create job test-run --from=cronjob/my-cronjob. Cela exécute immédiatement le Job avec la même configuration.

Mon pod reste en état Pending indéfiniment. Que faire ?

Le cluster n'a pas assez de ressources pour scheduler le pod. Vérifiez avec kubectl describe pod le-pod-name pour voir les événements. Réduisez les requests ou ajoutez des nodes.

Comment gérer les fuseaux horaires dans les CronJobs K8s ?

Depuis K8s 1.27+, utilisez spec.timeZone: "Europe/Paris". Pour les versions antérieures, le schedule utilise le timezone du kube-controller-manager (souvent UTC).

Comment éviter les exécutions concurrentes de mon CronJob ?

Définissez concurrencyPolicy: Forbid dans le spec. Cela empêche la création d'un nouveau Job si le précédent est encore en cours. Attention : cela peut masquer des problèmes de performance.

Comment voir les logs d'un Job K8s qui a échoué ?

Listez les pods du Job avec kubectl get pods -l job-name=mon-job, puis kubectl logs nom-du-pod. Pour les pods terminés, ajoutez --previous si le conteneur a redémarré.

Conclusion

Les CronJobs Kubernetes sont puissants mais leur monitoring natif reste limité. Dans un cluster actif, les échecs silencieux peuvent passer inaperçus pendant des jours, affectant vos backups, synchronisations et traitements batch.

En combinant les bonnes pratiques Kubernetes avec le monitoring heartbeat de MoniTao, vous obtenez une visibilité complète sur vos jobs planifiés. Commencez par vos CronJobs critiques et étendez progressivement la couverture à l'ensemble de votre cluster.

Liens utiles

Prêt à dormir sur vos deux oreilles ?

Commencez gratuitement, sans carte bancaire.

Créer mon compte Voir les tarifs