Utiliser les CronJobs Kubernetes pour planifier des tâches batch fiables

Introduction

Les CronJobs sont le pendant Kubernetes des tâches cron classiques du système Unix. Ils permettent d’exécuter périodiquement des pods éphémères, idéaux pour les sauvegardes, le nettoyage de bases de données, ou le déclenchement de traitements batch. Cet article montre, pas à pas, comment déclarer un CronJob, gérer les erreurs et appliquer les meilleures pratiques pour garantir la fiabilité de vos tâches récurrentes.

Créer un CronJob simple

Un CronJob se définit via un manifest YAML. Voici un exemple minimal qui lance un script backup.sh chaque jour à 02:00 UTC.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-backup
spec:
  schedule: "0 2 * * *"   # minute hour day month day-of-week
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: alpine:3.18
            command: ["/bin/sh", "-c", "./backup.sh"]
            volumeMounts:
            - name: scripts
              mountPath: /backup
          restartPolicy: OnFailure
          volumes:
          - name: scripts
            configMap:
              name: backup-scripts

• schedule : expression cron respectant la syntaxe standard.
• restartPolicy : OnFailure indique que le pod doit être relancé uniquement en cas d’échec.
• jobTemplate : décrit le pod qui sera créé à chaque déclenchement.

Appliquez le manifeste avec kubectl apply -f cronjob.yaml. Le contrôleur cronjob-controller crée un objet Job à chaque exécution, puis supprime les anciens pods selon la politique de rétention.

Gestion des erreurs et des logs

Limiter le nombre d’échecs

Le champ spec.failedJobsHistoryLimit définit combien de jobs échoués sont conservés. Une valeur trop élevée peut remplir le etcd, alors qu’une valeur trop basse empêche l’analyse historique.

spec:
  failedJobsHistoryLimit: 3
  successfulJobsHistoryLimit: 5

Capture des logs

Les pods du CronJob utilisent la même mécanique de logs que n’importe quel pod Kubernetes. Vous pouvez les visualiser avec :

kubectl logs job/<job-name>

Pour centraliser les logs, intégrez un agrégateur (ex. Fluentd → Elasticsearch) via les annotations logging.io/* ou en configurant le DaemonSet fluent-bit.

Détection d’erreurs répétées

Kubernetes ne redémarre pas automatiquement un CronJob qui échoue systématiquement. Il faut surveiller les métriques cronjob_job_successful et cronjob_job_failed via Prometheus, puis créer une alerte :

- alert: CronJobFailure
  expr: increase(kube_cronjob_status_failed{job="daily-backup"}[15m]) > 0
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "Le CronJob daily-backup a échoué"
    description: "Vérifiez les logs du pod pour identifier la cause."

Bonnes pratiques et limites

Pratique	Pourquoi	Exemple
Utiliser des images légères	Réduit le temps de pull et la surface d’attaque.	alpine ou distroless plutôt que ubuntu.
Séparer le code et la configuration	Permet de modifier la fréquence sans toucher à l’image.	Utiliser des ConfigMaps ou des variables d’environnement pour la crontab.
Limiter les ressources	Empêche un job de monopoliser le cluster.	resources: {requests: {cpu: "100m", memory: "128Mi"}, limits: {cpu: "200m", memory: "256Mi"}}
Activer le startingDeadlineSeconds	Définit un délai maximal d’exécution lorsqu’une fenêtre est manquée (ex. pendant une mise à jour du cluster).	startingDeadlineSeconds: 300
Ne pas stocker de données persistantes dans le pod	Les pods sont éphémères ; utilisez des PVC ou des services externes.	Montage d’un PVC pour les backups ou écriture directe sur S3.

Limites à connaître

• Granularité du calendrier : La résolution est à la minute ; les intervalles inférieurs ne sont pas supportés.
• Concurrence : Si un job dure plus longtemps que son intervalle, Kubernetes crée un second pod, ce qui peut entraîner des chevauchements. Utilisez concurrencyPolicy: Forbid pour empêcher cela.
• Temps de démarrage : Un CronJob dépend du temps de pull d’image; pré-pulled images via imagePullPolicy: IfNotPresent accélèrent le démarrage.

Conclusion

Les CronJobs Kubernetes offrent une solution native pour automatiser des tâches récurrentes, avec la même visibilité et les mêmes garanties que les workloads standards. En combinant une définition claire du manifeste, une surveillance proactive via Prometheus et une gestion rigoureuse des ressources, vous obtenez des jobs batch fiables, traçables et faciles à maintenir. Intégrez ces bonnes pratiques dans votre pipeline CI/CD et vous gagnerez en stabilité sans ajouter de composants externes.