## Introduction Les Jobs Kubernetes sont essentiels pour exécuter des charges de travail par lots, telles que le traitement de données, les sauvegardes ou les tâches de maintenance. Mettre à niveau ou migrer un Job implique de modifier sa spécification, son image ou son environnement, et peut introduire des échecs si cela n'est pas géré avec soin. Ce guide propose une approche pratique pour planifier et exécuter les mises à niveau et migrations de Jobs avec un risque minimal. Nous couvrirons l'inventaire de l'environnement, les stratégies de configuration, la vérification, la récupération en cas d'échec et une liste de contrôle opérationnelle. En suivant ces étapes, vous pouvez réduire les retouches et assurer une transition fluide pour vos charges de travail par lots. ## Inventaire des versions et de l'environnement Avant d'apporter des modifications, vous devez avoir une vision claire de votre environnement actuel. Cela inclut la version de Kubernetes, la spécification actuelle du Job et toutes les dépendances. Commencez par vérifier la version de votre cluster : kubectl version --short Sortie attendue : Client Version: v1.24.0 Server Version: v1.23.5 Ensuite, listez les Jobs existants dans votre espace de noms : kubectl get jobs -n Exemple de sortie : NAME COMPLETIONS DURATION AGE data-import-2023 1/1 2m 3d Inspectez le manifeste actuel du Job pour comprendre sa configuration : kubectl get job -n -o yaml Examinez les champs comme spec.template.spec.containers[].image , les variables d'environnement, les limites de ressources et la politique de redémarrage. Notez toutes les ConfigMaps, Secrets ou PersistentVolumeClaims utilisées par le Job. Vérifiez que vous disposez des autorisations nécessaires pour créer, mettre à jour et supprimer des Jobs dans l'espace de noms. Vérifiez également si le Job est géré par un CronJob ; si c'est le cas, vous devrez mettre à jour la spécification du CronJob plutôt que le Job directement. Documentez l'état actuel, y compris les paramètres de complétion et de parallélisme du Job, la limite de backoff et la durée limite active. Cet inventaire servira de base de référence pour un retour arrière si nécessaire. ### Exemple : manifeste de base d'un Job Voici un exemple de manifeste de Job que vous pourriez rencontrer : apiVersion: batch/v1 kind: Job metadata: name: data-import-2023 spec: completions: 1 parallelism: 1 backoffLimit: 4 activeDeadlineSeconds: 100 template: spec: containers: - name: importer image: myapp:v1 env: - name: DB_HOST valueFrom: configMapKeyRef: name: db-config key: host resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m" restartPolicy: Never Enregistrez ce manifeste de base à l'aide de la commande : kubectl get job data-import-2023 -n -o yaml > data-import-2023-backup.yaml Cette sauvegarde est cruciale pour un retour arrière si quelque chose tourne mal pendant la migration.

Question rapide 1 sur 2 Quelle est la méthode recommandée pour mettre à niveau ou migrer un Job Kubernetes afin de minimiser les risques ? - Modifier le Job existant sur place pour changer son image. - Créer un nouveau Job avec un nom différent et une spécification mise à jour, puis basculer les dépendances après validation. - Supprimer immédiatement le Job existant et le recréer avec le même nom. - Utiliser kubectl edit job pour mettre à jour le Job directement.

Le guide recommande d'éviter les modifications sur place et de créer plutôt un nouveau Job avec un nom différent pour des tests côte à côte et une restauration facile.

## Chemin de configuration sûr Lors de la mise à niveau ou de la migration d'un Job, évitez de modifier le Job existant sur place si possible. Créez plutôt un nouveau Job avec la spécification mise à jour et un nom différent, puis basculez le trafic ou les dépendances vers celui-ci après validation. Cela permet des tests côte à côte et un retour arrière facile. Par exemple, supposons que vous deviez mettre à jour l'image d'un Job de traitement de données de myapp:v1 à myapp:v2 . Créez un nouveau manifeste de Job, disons data-process-v2.yaml : apiVersion: batch/v1 kind: Job metadata: name: data-process-v2 labels: app: data-process version: v2 spec: template: spec: containers: - name: processor image: myapp:v2 # autres paramètres identiques à l'original restartPolicy: Never backoffLimit: 4 Appliquez le nouveau Job : kubectl apply -f data-process-v2.yaml -n Avant d'appliquer, envisagez d'utiliser kubectl diff pour voir les changements : kubectl diff -f data-process-v2.yaml Cette commande affiche les différences entre l'état actuel et le manifeste proposé, vous aidant à repérer les modifications non intentionnelles. Si le Job fait partie d'un flux de travail plus large (par exemple, déclenché par un système externe), vous devrez peut-être mettre à jour le déclencheur pour pointer vers le nouveau nom de Job. Pour les CronJobs, mettez à jour le spec.jobTemplate du CronJob avec la nouvelle image, et conservez éventuellement l'historique de l'ancien Job pour un retour arrière. Utilisez des étiquettes et des annotations pour suivre les versions. Par exemple : metadata: labels: app: data-process version: v2 Cela facilite le filtrage et la gestion des Jobs. Si vous devez modifier un Job existant sur place, sachez que certains champs sont immuables après la création (par exemple, spec.template ). Dans ce cas, vous devez supprimer et recréer, mais cela peut entraîner une interruption. L'approche côte à côte est plus sûre. ### Mise à jour d'un CronJob Si votre Job est géré par un CronJob, mettez à jour le manifeste du CronJob plutôt que le Job directement. Par exemple, pour mettre à jour l'image dans un CronJob : kubectl edit cronjob my-cronjob -n Dans l'éditeur, modifiez l'image dans spec.jobTemplate.spec.template.spec.containers[].image pour myapp:v2 . Enregistrez et quittez. Le contrôleur CronJob utilisera la nouvelle image pour les exécutions suivantes. Les Jobs existants créés par le CronJob ne seront pas affectés ; ils continueront jusqu'à leur achèvement avec l'ancienne spécification. Pour tester la nouvelle image sans attendre la prochaine planification, vous pouvez créer manuellement un Job à partir du CronJob : kubectl create job manual-test --from=cronjob/my-cronjob -n Cela crée un Job utilisant le modèle actuel du CronJob, vous permettant de vérifier les changements immédiatement. ## Vérification et diagnostics Après avoir déployé le nouveau Job, vous devez vérifier qu'il fonctionne correctement. Utilisez kubectl describe pour voir les événements : kubectl describe job data-process-v2 -n Vérifiez le statut du Job : kubectl get job data-process-v2 -n -o yaml Recherchez les compteurs status.succeeded et status.failed . Surveillez les journaux du Pod créé par le Job : kubectl logs job/data-process-v2 -n Sortie attendue (exemple) : Traitement du fichier 1 sur 100 Traitement du fichier 2 sur 100 ... Job terminé avec succès. Si le Job est toujours en cours d'exécution, vous pouvez surveiller sa progression : kubectl get pods -l job-name=data-process-v2 -n --watch Configurez des alertes ou des notifications pour l'achèvement/échec du Job si vous utilisez un système de surveillance. Pour une vérification rapide, vous pouvez exécuter une commande qui attend l'achèvement : kubectl wait --for=condition=complete job/data-process-v2 --timeout=300s -n Si le Job échoue, inspectez les journaux du Pod pour détecter les erreurs et ajustez. Vous pouvez également vérifier l'utilisation des ressources pour vous assurer que la nouvelle version ne dépasse pas les limites. ### Exemple : vérification d'un Job réussi Après avoir appliqué le nouveau Job, exécutez : kubectl get job data-process-v2 -n -o jsonpath='{.status.succeeded}' Si la sortie est 1 , le Job s'est terminé avec succès. Vous pouvez également vérifier l'heure d'achèvement : kubectl get job data-process-v2 -n -o jsonpath='{.status.completionTime}' Comparez cela avec les métriques du Job précédent pour vous assurer que les performances sont acceptables. ## Modes d'échec et récupération Les Jobs peuvent échouer pour diverses raisons : erreurs de tirage d'image, plantages d'application, épuisement des ressources, mauvaise configuration ou problèmes de dépendances externes. La politique de redémarrage du Job ( restartPolicy: Never ou OnFailure ) et la backoffLimit déterminent comment les échecs sont gérés. Modes d'échec courants : - Erreur de tirage d'image : Vérifiez le nom de l'image, l'étiquette, les identifiants du registre. - CrashLoopBackOff : Erreur d'application ou configuration manquante. - OOMKilled : Limites de ressources trop basses. - Délai dépassé : activeDeadlineSeconds réglé trop bas. Pour récupérer, diagnostiquez d'abord avec kubectl describe pod et kubectl logs . Par exemple : kubectl describe pod -n Recherchez des événements comme Failed to pull image ou Back-off restarting failed container . Si le nouveau Job échoue, vous pouvez revenir en arrière en rebasculant vers l'ancien Job (s'il est toujours disponible) ou en inversant le mécanisme de déclenchement. Si vous avez utilisé un déploiement côte à côte, l'ancien Job reste intact. Si vous avez modifié sur place, vous devrez peut-être recréer l'ancien Job à partir de votre manifeste de base. Pour un Job en échec, vous pouvez également ajuster le manifeste et le réappliquer, mais notez que les Jobs sont immuables dans certains champs. Il est souvent plus facile de supprimer et de créer un nouveau Job avec un nom différent. Exemple de commande de retour arrière : kubectl delete job data-process-v2 -n kubectl apply -f data-process-v1.yaml -n Conservez toujours des sauvegardes des manifestes de Jobs précédents et de toutes les ConfigMaps ou Secrets associés. ### Stratégie de retour arrière Une stratégie de retour arrière robuste implique d'avoir des manifestes versionnés. Stockez chaque manifeste de Job dans un contrôle de version. Par exemple, conservez data-process-v1.yaml et data-process-v2.yaml dans un dépôt Git. Si la nouvelle version échoue, exécutez : kubectl delete job data-process-v2 -n kubectl apply -f data-process-v1.yaml -n Cela recrée l'ancien Job. Cependant, notez que ce nouveau Job aura un UID différent et devra peut-être être traité comme une nouvelle exécution. Assurez-vous que tous les systèmes externes qui déclenchent le Job sont mis à jour pour faire référence au nom correct. ## Liste de contrôle opérationnelle Utilisez cette liste de contrôle pour garantir une mise à niveau ou une migration de Job fluide :

Étape	Action	Commande/Notes
1	Vérifier les versions du cluster et du Job	`kubectl version`, `kubectl get job <name> -o yaml`
2	Sauvegarder les manifestes actuels	`kubectl get job <name> -o yaml > job-backup.yaml`
3	Créer un nouveau manifeste de Job avec les changements	Modifier le YAML avec la nouvelle image/config
4	Diffuser avant d'appliquer	`kubectl diff -f new-job.yaml`
5	Appliquer le nouveau Job	`kubectl apply -f new-job.yaml`
6	Surveiller le statut du Job	`kubectl get jobs -w`
7	Vérifier les journaux pour les erreurs	`kubectl logs job/<name>`
8	Vérifier l'achèvement	`kubectl wait --for=condition=complete job/<name> --timeout=300s`
9	Mettre à jour les dépendances/déclencheurs	Mettre à jour le CronJob ou les systèmes externes
10	Nettoyer l'ancien Job s'il n'est plus nécessaire	`kubectl delete job <old-name>` (après validation)

Examinez chaque étape avant de procéder. Automatisez lorsque c'est possible à l'aide de scripts ou de CI/CD, mais assurez des vérifications manuelles pour les changements critiques. ### Exemple de liste de contrôle pré-migration Avant d'exécuter la migration, passez en revue cette liste de contrôle : - [ ] La version du cluster répond à l'exigence minimale pour la nouvelle image (par exemple, Kubernetes v1.20+). - [ ] Le manifeste actuel du Job est sauvegardé dans le contrôle de version. - [ ] La nouvelle image a été testée dans un environnement de préproduction. - [ ] Les quotas de ressources dans l'espace de noms permettent le nouveau Job. - [ ] Le plan de retour arrière est documenté et testé. - [ ] Les membres de l'équipe sont informés de la fenêtre de migration. ## Conclusion La mise à niveau et la migration des Jobs Kubernetes nécessitent une planification et une exécution minutieuses. En inventoriant votre environnement, en utilisant des déploiements côte à côte, en vérifiant avec des contrôles observables et en ayant un plan de retour arrière, vous pouvez minimiser les risques et les temps d'arrêt. Suivez la liste de contrôle opérationnelle pour garantir la cohérence. Un processus de migration clair réduit les retouches et aide votre équipe à gérer les charges de travail par lots en toute confiance. Commencez par un pilote étroit pour valider les changements avant un déploiement plus large, et gardez toujours des options de retour arrière disponibles.