GUIDE TECHNIQUE · KUBERNETES
Mettre à jour puis restaurer un Deployment Kubernetes
Démontrer une montée de version Kubernetes puis un rollback avec un changement d'image reproductible, un historique de révisions et la vérification de l'image finalement exécutée.
L’ESSENTIEL EN BREF
Comment procéder ?
Démontrer une montée de version Kubernetes puis un rollback avec un changement d'image reproductible, un historique de révisions et la vérification de l'image finalement exécutée.
Résultat à atteindre : Image et état initiaux relevés.
Avant de commencer : Cluster de test autorisé et contexte kubectl vérifié.
01 · CADRAGE
Ce que vous allez mettre en place
Démontrer une montée de version Kubernetes puis un rollback avec un changement d'image reproductible, un historique de révisions et la vérification de l'image finalement exécutée.
Pour qui : Administrateurs Kubernetes, équipes DevOps et SRE
Kubernetes stable avec kubectl compatible ; les images de laboratoire sont illustratives et doivent être validées avant usage réel.
Vérifiez la compatibilité avec votre environnement réel. Les versions ne sont jamais présumées identiques d’un tenant à l’autre.
02 · AVANT DE COMMENCER
Prérequis et points de contrôle
- Cluster de test autorisé et contexte kubectl vérifié.
- Droits de créer/supprimer un namespace de recette ; aucun workload client dans ce namespace.
- Capacité à lire Pods, événements et logs après déploiement.
03 · VUE D’ENSEMBLE
Comprendre l’architecture et les flux
04 · TUTORIEL
Procédure complète, étape par étape
Chaque étape explique l’action, sa raison, le contrôle attendu et les erreurs habituelles. Adaptez les exemples aux paramètres de votre propre environnement.
ÉTAPE 1 / 5
Préparer un Deployment isolé
Un rollback est crédible si on connaît le contexte et la version de départ.
- Créer un namespace isolé.
- Vérifier les permissions.
- Documenter l'image de base avant mutation.
kubectl config current-context
kubectl create namespace adn-rollout-labÀ vérifier : Namespace de test créé.
Point de vigilance ADN : Ne pas lancer rollout undo sans connaître les effets sur la version précédente.
ÉTAPE 2 / 5
Créer la révision initiale
Une image de départ stable permet de comparer les révisions.
- Créer un Deployment nginx avec une version choisie après validation du registre.
- Attendre l'état disponible.
- Relever la valeur image sur le Deployment.
kubectl -n adn-rollout-lab create deployment web --image=nginx:1.26-alpine
kubectl -n adn-rollout-lab rollout status deployment/web
kubectl -n adn-rollout-lab get deployment web -o jsonpath='{.spec.template.spec.containers[0].image}'À vérifier : Le Deployment est Ready et l'image initiale est affichée.
Point de vigilance ADN : Les tags utilisés sont des exemples : vérifier leur disponibilité et idéalement épingler un digest en production.
ÉTAPE 3 / 5
Déclencher une mise à jour contrôlée
Modifier l'image du template crée une nouvelle révision du Deployment.
- Changer l'image vers une seconde version validée.
- Attendre le rollout.
- Contrôler que les Pods sont disponibles.
kubectl -n adn-rollout-lab set image deployment/web nginx=nginx:1.27-alpine
kubectl -n adn-rollout-lab rollout status deployment/webÀ vérifier : Une deuxième révision a été créée si le tag représente un changement du template.
Point de vigilance ADN : Un Pod qui ne peut pas tirer une image rend le rollout indisponible ; inspecter les événements et ne pas attendre indéfiniment.
ÉTAPE 4 / 5
Contrôler rollout et historique
Une commande réussie de mise à jour n'est pas une preuve de révision correcte.
- Lire l'historique des révisions.
- Vérifier l'image du template courant.
- Consigner le numéro de révision retourné.
kubectl -n adn-rollout-lab rollout history deployment/web
kubectl -n adn-rollout-lab get deployment web -o jsonpath='{.spec.template.spec.containers[0].image}'À vérifier : L'historique présente au moins deux révisions et le template indique l'image mise à jour.
Point de vigilance ADN : Les révisions sans annotations de changement ne donnent pas nécessairement une explication lisible dans CHANGE-CAUSE.
ÉTAPE 5 / 5
Revenir à la révision précédente puis nettoyer
Le rollback doit être validé sur le Deployment et pas seulement confirmé par la CLI.
- Revenir à la révision précédente.
- Attendre la disponibilité puis relire l'image effective.
- Nettoyer après constat et seulement sur la recette.
kubectl -n adn-rollout-lab rollout undo deployment/web
kubectl -n adn-rollout-lab rollout status deployment/web
kubectl -n adn-rollout-lab get deployment web -o jsonpath='{.spec.template.spec.containers[0].image}'
kubectl delete namespace adn-rollout-labÀ vérifier : L'image affichée redevient nginx:1.26-alpine, puis le namespace est supprimé.
Point de vigilance ADN : Le rollback de Deployment ne rétablit pas automatiquement données, ConfigMaps ou schémas de base.
SOURCES ET FIABILITÉ
Statut de validation du guide
Rédaction : ADN Consulting. Statut : procédure documentée, exécution en laboratoire non attestée.
Les exemples et versions indiqués doivent être vérifiés sur un environnement autorisé. Aucune validation individuelle par un consultant n’est revendiquée sans preuve.
05 · RECETTE
Comment vérifier que tout fonctionne ?
Image et état initiaux relevés.
Nouvelle image réellement appliquée et révision observée.
rollout undo restaure l'ancienne image.
Limites du rollback applicatif et des données signalées.
06 · DIAGNOSTIC
Problèmes fréquents et résolution
ImagePullBackOff
Cause probable : Image absente, accès registre ou tag incorrect
Que faire : Lire kubectl describe pod et les événements avant changement d'image.
CrashLoopBackOff
Cause probable : Conteneur instable ou configuration invalide
Que faire : Lire les logs --previous et livenessProbe ; corriger à la source.
Rollout bloqué
Cause probable : Pods non prêts ou capacité du cluster insuffisante
Que faire : Examiner rollout status, describe et quota du namespace.
Le conseil de l’expert ADN
Avant de généraliser cette configuration, validez-la sur un périmètre représentatif, documentez les critères de réussite et conservez une procédure de retour arrière. Une automatisation fiable se juge sur l’état final observé, les permissions maîtrisées et un retour arrière testé.
07 · QUESTIONS PRATIQUES
Questions fréquentes
Puis-je reprendre ces commandes en production ?
Non sans adaptation, revue de sécurité, approbation de changement et tests sur un environnement identique.
Pourquoi ne suffit-il pas d'appliquer le manifeste ?
Le contrôleur peut accepter l'objet alors que les Pods ne sont pas prêts ou que le service ne répond pas.
AUTRES TECHNOLOGIES
Guides complémentaires
Ce tutoriel s’inscrit dans une chaîne technique plus large. Retrouvez les méthodes associées aux technologies voisines.