Sauvegarde et restauration des CronJobs Kubernetes : un guide pratique de mise en œuvre

Introduction

Les CronJobs Kubernetes automatisent les tâches planifiées, des nettoyages nocturnes de bases de données à la génération de rapports. Parce qu'ils vivent à l'intérieur du cluster, ils peuvent être accidentellement supprimés, mal configurés ou corrompus lors d'une mise à niveau ratée. Sauvegarder et restaurer des CronJobs n'est pas aussi simple que de copier un fichier YAML : vous devez tenir compte de leurs planifications, de l'historique des tâches et de dépendances telles que les ConfigMaps et les Secrets. Ce guide propose une approche pratique, basée sur des commandes, pour protéger vos CronJobs, les récupérer après un incident et valider que vos sauvegardes fonctionnent réellement.

L'accent est mis sur la sécurité opérationnelle. Vous apprendrez à observer l'état actuel de vos CronJobs, à effectuer des modifications minimales, à tester les procédures de récupération avant un incident et à éviter les erreurs courantes qui conduisent à des échecs de restauration. Chaque section inclut des commandes réelles et des sorties attendues, afin que vous puissiez suivre dans un cluster bac à sable ou adapter les étapes à la production.

Inventaire de la version et de l'environnement

Avant de toucher à un CronJob, vous devez savoir exactement ce qui s'exécute, quelle version de Kubernetes vous utilisez et quels outils sont disponibles. Commencez par des vérifications en lecture seule, car vous ne pouvez pas sauvegarder en toute sécurité ce que vous ne comprenez pas.

Tout d'abord, vérifiez la version de votre cluster et que le client kubectl fonctionne :

kubectl version --short

La sortie attendue ressemble à ceci :

Client Version: v1.27.3
Kustomize Version: v5.0.1
Server Version: v1.27.3

Ensuite, listez tous les CronJobs dans tous les espaces de noms, avec leurs planifications et leur statut de suspension :

kubectl get cronjobs --all-namespaces -o wide

Exemple de sortie :

NAMESPACE     NAME          SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
production    db-backup     0 2 * * *     False     0        3m              30d
staging       report-gen    */10 * * * *  False     1        2m              12d

Faites attention à la colonne SUSPEND : si un CronJob est suspendu, il ne créera pas de nouveaux Jobs, ce qui peut être intentionnel ou le signe d'un problème. La colonne LAST SCHEDULE indique quand le Job le plus récent a été créé. Si elle est vide, la planification peut être invalide ou le CronJob est nouveau.

Pour voir la définition complète d'un CronJob spécifique, y compris sa limite de backoff, sa politique de concurrence et son modèle de Job, exécutez :

kubectl get cronjob db-backup -n production -o yaml

Cette commande est la base d'une sauvegarde, mais n'enregistrez pas encore la sortie : vous devez d'abord vous assurer de capturer l'état en direct, pas une version mise en cache ou modifiée.

Une erreur courante à ce stade est de supposer que kubectl get cronjobs seul suffit pour la sauvegarde. Ce n'est pas le cas : les CronJobs peuvent dépendre de ConfigMaps, de Secrets et de ServiceAccounts vivant dans le même espace de noms. Sans eux, un CronJob restauré peut échouer. Dans la section suivante, vous collecterez toutes les ressources associées.

Chemin de configuration sûr

Une sauvegarde sûre capture non seulement l'objet CronJob lui-même, mais aussi tout ce dont il a besoin pour fonctionner correctement. Considérez-la comme un instantané de l'ensemble de la charge de travail planifiée, et pas seulement de la définition de planification.

Utilisez kubectl avec des sélecteurs d'étiquettes pour extraire les ressources associées. La plupart des CronJobs sont étiquetés avec quelque chose comme app=db-backup. Pour collecter un CronJob, ses ConfigMaps, Secrets et ServiceAccounts dans l'espace de noms production, exécutez :

kubectl get cronjob,configmap,secret,serviceaccount -n production -l app=db-backup -o yaml > backup-db-backup.yaml

Ce fichier unique contient maintenant tous les objets, mais attention : les Secrets sont stockés sous forme encodée en base64. Le fichier de sauvegarde contiendra ces valeurs encodées, ce qui est nécessaire pour une restauration complète, mais vous devez protéger le fichier avec des permissions strictes (par exemple, chmod 600 backup-db-backup.yaml) et éviter de le placer dans un contrôle de version non sécurisé.

Avant d'apporter des modifications à la configuration, observez l'état actuel avec un horodatage :

date && kubectl get cronjob db-backup -n production -o yaml

Cela vous permet de comparer avant et après. Si vous décidez de modifier un CronJob, faites un changement à la fois et vérifiez-le immédiatement. Par exemple, si vous devez changer la planification de 2 h du matin à 3 h du matin, modifiez uniquement le champ de planification :

kubectl patch cronjob db-backup -n production -p '{"spec":{"schedule":"0 3 * * *"}}'

Vérifiez ensuite que la nouvelle planification a pris effet :

kubectl get cronjob db-backup -n production -o jsonpath='{.spec.schedule}{"\n"}'

Sortie attendue :

0 3 * * *

Évitez d'utiliser kubectl apply avec un fichier YAML modifié directement depuis votre sauvegarde, car cela peut écraser par inadvertance d'autres champs ou réintroduire des valeurs obsolètes. Utilisez plutôt kubectl edit pour les modifications interactives ou kubectl patch pour des champs spécifiques. Après tout changement, enregistrez l'horodatage et la valeur précédente afin de pouvoir revenir en arrière si nécessaire.

Vérification et diagnostics

Après avoir créé ou modifié un CronJob, vous devez vérifier qu'il se comporte comme prévu. Le premier endroit à regarder est le statut du CronJob et les Jobs qu'il crée.

Exécutez la commande suivante pour voir les événements récents du CronJob :

kubectl describe cronjob db-backup -n production

Recherchez les événements qui indiquent une planification réussie ou des erreurs. Par exemple :

Events:
  Type    Reason            Age   From                Message
  ----    ------            ----  ----                -------
  Normal  SuccessfulCreate  4m    cronjob-controller  Created job db-backup-28494420

Si aucun Job n'est créé, vérifiez le statut SUSPEND et la validité de la planification. Vous pouvez déclencher manuellement un Job à partir d'un CronJob existant pour tester sans attendre la planification :

kubectl create job db-backup-manual-test -n production --from=cronjob/db-backup

Surveillez ensuite le Job et son Pod :

kubectl get jobs -n production db-backup-manual-test
kubectl get pods -n production -l job-name=db-backup-manual-test
kubectl logs -n production -l job-name=db-backup-manual-test --tail=20

Les journaux sont essentiels pour diagnostiquer les échecs. Si le Pod plante, consultez les journaux du conteneur précédent :

kubectl logs -n production -l job-name=db-backup-manual-test --previous

Et examinez les événements du Pod pour les problèmes de planification :

kubectl describe pod -n production -l job-name=db-backup-manual-test

Signaux d'erreur courants :

• ImagePullBackOff signifie que l'image du conteneur est erronée ou privée.
• CrashLoopBackOff signifie que l'application se termine après le démarrage.
• FailedScheduling signifie des ressources insuffisantes ou des contraintes de nœud.
• BackoffLimitExceeded signifie que le Job a essayé et échoué trop de fois.

Une fois que le Job manuel a réussi, supprimez-le pour nettoyer :

kubectl delete job db-backup-manual-test -n production

Ce processus de vérification prouve que la configuration de votre CronJob est valide et que son code s'exécute. Ne le sautez pas ; de nombreux échecs de restauration surviennent parce qu'un CronJob a été restauré mais jamais réellement testé.

Modes de défaillance et récupération

Même avec des sauvegardes, les restaurations peuvent échouer de manière non évidente. Comprendre les modes de défaillance courants vous aide à préparer des procédures de récupération.

1. Perte de ressources dépendantes

Si vous restaurez uniquement le CronJob mais pas son ConfigMap ou son Secret, le Job échouera car le pod ne pourra pas trouver sa configuration. Pour éviter cela, sauvegardez toujours l'ensemble complet des ressources comme indiqué dans la section Chemin de configuration sûr. Si vous réalisez qu'une dépendance manque, vous pouvez la recréer manuellement à partir de votre sauvegarde ou d'une autre source, puis la prochaine exécution planifiée réussira.

2. Suppression accidentelle d'un CronJob et de ses Jobs

Si un CronJob est supprimé, ses Jobs enfants sont également supprimés par défaut (en raison des références de propriétaire). Pour récupérer, appliquez votre sauvegarde :

kubectl apply -f backup-production-all.yaml

Mais soyez prudent : si la sauvegarde contient une planification dupliquée ou obsolète, vous risquez de restaurer la mauvaise configuration. Après l'application, vérifiez immédiatement la planification et le statut de suspension.

3. Mise à niveau ratée conduisant à une version d'API incompatible

Dans Kubernetes, les CronJobs sont passés de batch/v1beta1 à batch/v1 en v1.21. Si vous essayez de restaurer une sauvegarde faite avec l'ancienne API sur un cluster plus récent sans migration, vous obtiendrez une erreur :

Error from server (NotFound): the server could not find the requested resource

Vous pouvez migrer la version d'API dans votre fichier de sauvegarde en utilisant kubectl convert (si activé) ou en modifiant manuellement le champ apiVersion de batch/v1beta1 à batch/v1 et en vous assurant que les champs sont compatibles (par exemple, startingDeadlineSeconds est obsolète mais fonctionne toujours). Testez toujours ces conversions dans un cluster de préproduction.

4. Dérive de planification ou exécutions manquées

Parfois, un CronJob ne crée pas de Jobs parce que le contrôleur était en panne ou que la planification était invalide. Pour récupérer les exécutions manquées, vous pouvez créer manuellement un Job à partir du CronJob comme décrit précédemment. Dans la spécification du CronJob, startingDeadlineSeconds contrôle le retard maximal autorisé pour démarrer un Job ; définissez une valeur raisonnable (par exemple, 200 secondes) pour permettre un certain délai.

5. Restauration vers un cluster différent

Si vous devez restaurer vers un nouveau cluster, assurez-vous que le cluster cible dispose des mêmes classes de stockage, secrets et dépendances externes (par exemple, les points de terminaison de base de données). Utilisez kubectl apply --prune avec un sélecteur d'étiquettes pour supprimer les objets superflus, mais procédez avec prudence.

Pour pratiquer la récupération, effectuez régulièrement un exercice de restauration : supprimez un CronJob de test et ses dépendances, puis restaurez à partir de la sauvegarde et vérifiez que la prochaine exécution planifiée fonctionne. Cela transforme votre sauvegarde d'un filet de sécurité théorique en une procédure éprouvée.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle pour maintenir des sauvegardes et des restaurations de CronJobs saines. Attribuez un propriétaire unique à chaque élément (avec des exemples de rôles) et révisez la liste mensuellement ou après toute mise à niveau du cluster.

1. Fréquence et stockage des sauvegardes - Propriétaire : Ingénieur DevOps (par exemple, Priya Shah). Assurez une sauvegarde nocturne complète de tous les CronJobs et de leurs dépendances en utilisant kubectl get cronjob,configmap,secret,serviceaccount -o yaml --all-namespaces > cluster-backup-$(date +%Y%m%d).yaml. Stockez les sauvegardes dans un magasin d'objets sécurisé et versionné (par exemple, S3 avec chiffrement). Vérifiez que le fichier de sauvegarde n'est pas vide et peut être téléchargé.

1. Test de restauration - Propriétaire : Ingénieur de fiabilité des sites (par exemple, Marcus Lee). Mensuellement, choisissez un CronJob critique et restaurez sa sauvegarde dans un espace de noms de préproduction. Exécutez un Job manuel à partir de celui-ci et vérifiez les journaux pour le succès. Documentez le temps nécessaire et tout problème.

1. Politique pour les modifications manuelles - Propriétaire : Administrateur Kubernetes (par exemple, Elena Rossi). Toutes les modifications des CronJobs doivent passer par un dépôt git en utilisant un flux de travail GitOps (par exemple, Argo CD ou Flux). L'édition directe avec kubectl edit n'est autorisée qu'en cas d'urgence et doit être suivie d'un commit dans le dépôt.

1. Surveillance des CronJobs suspendus - Propriétaire : Ingénieur de surveillance (par exemple, David Kim). Créez une alerte pour notifier si un CronJob a spec.suspend défini sur true. Examinez les CronJobs suspendus chaque semaine ; chacun doit avoir une date d'expiration pour la réactivation ou la suppression.

1. Rotation des secrets - Propriétaire : Ingénieur sécurité (par exemple, Grace Chen). Faites tourner les Secrets utilisés par les CronJobs tous les 90 jours. Après la rotation, vérifiez que le CronJob peut toujours s'authentifier en exécutant un Job de test manuel.

1. Rétention des journaux et audit - Propriétaire : Ingénieur plateforme (par exemple, Tom Novak). Conservez les journaux des Jobs pendant au moins 30 jours à l'aide d'un système de journalisation centralisé. Examinez les journaux des Jobs échoués mensuellement pour repérer les problèmes récurrents.

Chaque élément de la liste de contrôle comprend une action concrète, un rôle responsable unique et une étape de vérification. Cela évite le problème de « responsabilité de groupe » où personne ne fait réellement le travail.

Pièges courants et comment les éviter

Les erreurs suivantes provoquent régulièrement des échecs de sauvegarde et de restauration de CronJobs. Apprenez à les reconnaître et appliquez les conseils de prévention.

Piège 1 : Sauvegarder uniquement l'objet CronJob

Pourquoi cela arrive : Les gens supposent qu'un CronJob est autonome, mais il repose souvent sur des ConfigMaps, des Secrets et même des PersistentVolumeClaims. Si ceux-ci ne sont pas sauvegardés, la restauration est inutile.

Comment éviter : Utilisez des sélecteurs d'étiquettes ou un outil comme Velero pour capturer toutes les ressources associées. Testez votre sauvegarde en restaurant dans un espace de noms propre et en exécutant le Job.

Piège 2 : Coder en dur des valeurs dans la spécification du CronJob

Pourquoi cela arrive : Il est pratique de mettre des mots de passe de base de données ou des URL spécifiques à l'environnement directement dans le modèle de Job. Mais vous ne pouvez pas restaurer vers un autre environnement sans modifier le fichier, et vous risquez d'exposer des secrets.

Comment éviter : Utilisez des Secrets Kubernetes et des ConfigMaps référencés via envFrom ou valueFrom. Ainsi, le YAML du CronJob reste générique, et seules les ressources de dépendance doivent changer entre les environnements.

Piège 3 : Ne pas définir startingDeadlineSeconds

Pourquoi cela arrive : Les nouveaux utilisateurs ne réalisent pas que si le contrôleur est en panne lorsqu'une planification est manquée, le Job peut ne jamais s'exécuter.

Comment éviter : Définissez startingDeadlineSeconds à une valeur qui tolère de courtes pannes (par exemple, 300 secondes). Sachez que si le délai est trop long, vous pourriez obtenir de nombreux Jobs manqués lorsque le contrôleur reprend.

Piège 4 : Ignorer le concurrencyPolicy

Pourquoi cela arrive : Par défaut, Kubernetes autorise des Jobs chevauchants du même CronJob. Si un Job dure plus longtemps que l'intervalle de planification, vous pouvez obtenir plusieurs exécutions simultanées, provoquant une contention des ressources ou une corruption des données.

Comment éviter : Définissez concurrencyPolicy sur Forbid si votre Job ne peut pas tolérer de chevauchement, ou Replace si vous voulez que le nouveau Job remplace l'ancien. N'utilisez Allow que lorsque vous êtes sûr que les chevauchements sont sûrs.

Piège 5 : Restaurer avec kubectl apply sans vérifier les différences

Pourquoi cela arrive : kubectl apply fusionne le YAML fourni avec l'objet en direct, ce qui peut entraîner des changements de champs inattendus. Si votre sauvegarde est ancienne, vous pourriez annuler un changement valide récent.

Comment éviter : Avant d'appliquer une sauvegarde, utilisez kubectl diff -f backup.yaml pour voir ce qui changerait. Si la différence est trop importante, restaurez d'abord dans un espace de noms temporaire et comparez.

Piège 6 : Ne pas nettoyer les anciens Jobs

Pourquoi cela arrive : Les CronJobs accumulent des Jobs terminés et échoués à moins que vous ne fixiez des limites. Avec le temps, cela peut remplir la base de données etcd et ralentir le cluster.

Comment éviter : Définissez successfulJobsHistoryLimit et failedJobsHistoryLimit à de petites valeurs (par exemple, 3 et 1). Si vous avez déjà un arriéré, supprimez manuellement les anciens Jobs avec kubectl delete jobs -n <namespace> -l <job-label> --field-selector status.successful=1.

Conclusion

Les CronJobs Kubernetes sont essentiels pour les opérations planifiées, mais leur sauvegarde et leur restauration sont souvent négligées jusqu'à ce que quelque chose se casse. Ce guide vous a montré comment inventorier vos CronJobs, sauvegarder l'ensemble complet des ressources, vérifier qu'une sauvegarde fonctionne, récupérer des modes de défaillance courants et maintenir une liste de contrôle opérationnelle avec une propriété claire. La clé est de traiter la sauvegarde non pas comme une copie de fichier occasionnelle, mais comme un processus testé et documenté.

Commencez dès aujourd'hui : choisissez un CronJob à faible risque, exécutez la commande de sauvegarde, restaurez-le dans un espace de noms séparé et vérifiez qu'un Job déclenché manuellement réussit. Notez le temps nécessaire et les surprises éventuelles. Ce petit investissement portera ses fruits la prochaine fois qu'une suppression ou une mauvaise mise à jour menacera vos tâches planifiées.

En suivant les étapes pratiques et en évitant les pièges décrits ici, vous pouvez vous assurer que vos CronJobs Kubernetes survivent aux perturbations et continuent de s'exécuter selon le calendrier prévu.