Lab 03 : Contrôleurs, Déploiements, Résilience & Rollback¶

Objectifs Pédagogiques :¶

Comprendre le rôle du contrôleur Deployment et de la boucle de réconciliation du ReplicaSet.
Expérimenter la résilience automatique (Self-Healing) de Kubernetes lors de la perte brutale d'un pod.
Déployer l'API campus-backend en haute disponibilité (plusieurs réplicas).
Configurer finement la stratégie de mise à jour progressive (Rolling Update) avec maxSurge et maxUnavailable.
Geler et inspecter un déploiement en cours (rollout pause / rollout resume).
Détecter un déploiement défectueux (ErrImagePull) et déclencher un retour arrière instantané (Rollback ciblé sur une révision).

📌 Note Compatibilité OS :
Toutes les commandes de cet atelier (kubectl create deployment, kubectl scale, kubectl set image, kubectl rollout) sont rigoureusement identiques sous Windows (PowerShell), Linux (Ubuntu) et macOS (Terminal).

💡 Modalités d'exécution (Au choix) :
Option A (Recommandée - Confort DevOps Local) : Exécutez les commandes directement depuis votre machine locale avec votre kubectl et votre kubeconfig.
Option B (Secours - PC d'entreprise verrouillé) : Connectez-vous en SSH sur k8s-control : l'outillage et les manifests sont pré-installés dans ~/labs/.

Contexte Métier¶

L'API métier du campus (campus-backend) traite les offres de stages et les candidatures pour 25 000 étudiants. Elle ne peut souffrir d'aucune interruption de service. Vous devez la déployer sous forme d'un Deployment avec au moins 2 réplicas, vérifier sa résistance aux pannes, tester une montée de version applicative, ajuster les garde-fous de disponibilité et maîtriser la procédure d'urgence de retour en arrière.

Image Backend v1 : regaieg/campus:backend-1.0.0
Port d'écoute : 8080

Exercice 1 : Créer le Deployment `campus-backend`¶

Générez un manifest de type Deployment nommé deployment-backend.yaml à l'aide de la commande kubectl create deployment en mode --dry-run=client -o yaml :
Nom du déploiement : campus-backend
Image : regaieg/campus:backend-1.0.0
Réplicas souhaités : 2
Port : 8080

kubectl create deployment campus-backend --image=regaieg/campus:backend-1.0.0 --replicas=2 --port=8080 --dry-run=client -o yaml > deployment-backend.yaml

Ouvrez le fichier généré deployment-backend.yaml. Repérez les 3 sections majeures :
spec.replicas : Le nombre d'instances désirées.
spec.selector.matchLabels : Le sélecteur qui relie le contrôleur à ses pods.
spec.template : Le modèle de pod cloné par le contrôleur.

Complétez la section env sous containers pour fournir les paramètres de connexion à PostgreSQL :

href="#__codelineno-1-1">spec: replicas: 2 selector: matchLabels: app: campus-backend template: metadata: labels: app: campus-backend spec: containers: - name: campus-backend image: regaieg/campus:backend-1.0.0 ports: - containerPort: 8080 env: - name: SPRING_DATASOURCE_URL value: "jdbc:postgresql://campus-postgres:5432/campus" - name: SPRING_DATASOURCE_USERNAME value: "campus" - name: SPRING_DATASOURCE_PASSWORD value: "campus"

💡 Précision d'architecture : L'API Spring Boot initialise son contexte Hibernate/JPA dès le boot. Les variables SPRING_DATASOURCE_* permettent de joindre la base PostgreSQL du cluster via le service campus-postgres. Au Lab 05, nous apprendrons à découpler ces paramètres dans des ConfigMaps et Secrets dédiés.

Appliquez le manifest :

kubectl apply -f deployment-backend.yaml

Listez les déploiements, les ReplicaSets et les pods créés :

kubectl get deployments
kubectl get rs
kubectl get pods -l app=campus-backend -o wide

Exercice 2 : Test de Résilience (Self-Healing)¶

Identifiez le nom de l'un des deux pods campus-backend-xxxx-yyyy.
Supprimez ce pod manuellement :
```
kubectl delete pod <nom-du-pod>
```
Exécutez immédiatement kubectl get pods -l app=campus-backend :
Que constatez-vous ?
Pourquoi un nouveau pod a-t-il été créé avec un âge de quelques secondes ?

💡 Indice 1 : La boucle de réconciliation (Control Loop)

Le contrôleur `ReplicaSet` surveille en continu l'état réel du cluster par rapport à l'état désiré (`replicas: 2`). Dès qu'un pod disparaît, il en instancie immédiatement un nouveau pour combler l'écart. C'est le principe fondamental du **Self-Healing**.

Exercice 3 : Montée et Descente en Charge (Scaling)¶

Augmentez le nombre de réplicas à 4 de manière impérative :
```
kubectl scale deployment campus-backend --replicas=4
```
Observez la création instantanée des 2 pods supplémentaires :
```
kubectl get pods -l app=campus-backend
```
Modifiez maintenant votre fichier deployment-backend.yaml pour fixer replicas: 3, puis appliquez-le :
```
kubectl apply -f deployment-backend.yaml
```
Vérifiez que Kubernetes a proprement détruit l'instance excédentaire :
```
kubectl get pods -l app=campus-backend
```

Exercice 4 : Paramétrage de la Stratégie de Rolling Update¶

Par défaut, Kubernetes utilise la stratégie RollingUpdate avec un remplacement progressif. En production, vous devez contrôler précisément le rythme de mise à jour pour ne jamais saturer le cluster ni dégrader la qualité de service.

maxUnavailable : Nombre (ou pourcentage) maximal de pods pouvant être indisponibles pendant la mise à jour (ex: 1 ou 25%).
maxSurge : Nombre (ou pourcentage) maximal de pods supplémentaires pouvant être créés au-delà du nombre de réplicas souhaité (ex: 1 ou 25%).
Modifiez votre fichier deployment-backend.yaml pour expliciter la stratégie sous spec :
```
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
```
(Avec maxUnavailable: 0, Kubernetes garantit qu'il y aura TOUJOURS au minimum 3 pods en service pendant toute la durée de la mise à jour !)

Appliquez le manifest :

kubectl apply -f deployment-backend.yaml

Mettez à jour l'image du conteneur en simulant une version applicative v1.0.0 patchée :

kubectl set image deployment/campus-backend campus-backend=regaieg/campus:backend-1.0.0

Suivez en temps réel la progression :

kubectl rollout status deployment/campus-backend

Exercice 5 : Gestion d'un Incident en Production & Rollback Ciblé¶

Imaginons qu'une erreur de saisie ou un bug critique survienne lors d'un déploiement : l'équipe déploie par erreur une image taguée regaieg/campus:backend-invalid-tag.

Déclenchez ce déploiement erroné :

kubectl set image deployment/campus-backend campus-backend=regaieg/campus:backend-invalid-tag

Observez l'état des pods avec kubectl get pods -l app=campus-backend -w :
Quel statut d'erreur apparaît sur les nouveaux pods ? (ImagePullBackOff / ErrImagePull).
Les 3 anciens pods v1.0.0 continuent-ils de servir les utilisateurs ?
Explication : Comme nous avons configuré maxUnavailable: 0, Kubernetes refuse de tuer les anciens pods tant que le nouveau pod n'est pas devenu opérationnel. Le service ne subit aucune coupure !
Affichez l'historique complet des révisions du déploiement :
```
kubectl rollout history deployment/campus-backend
```

Inspectez le détail d'une révision spécifique (ex: révision 1) :

kubectl rollout history deployment/campus-backend --revision=1

Déclenchez immédiatement le retour arrière (Rollback) vers la version saine précédente :
```
kubectl rollout undo deployment/campus-backend
```
Ou pour cibler précisément une révision : kubectl rollout undo deployment/campus-backend --to-revision=1.

Vérifiez la résolution immédiate de l'incident :

kubectl rollout status deployment/campus-backend
kubectl get pods -l app=campus-backend

Exercice 6 : Pause, Inspection & Nettoyage d'Historique¶

Pour les mises à jour complexes comprenant plusieurs modifications successives (changement d'image + variables d'environnement + ressources), on peut geler le déploiement pour éviter de déclencher plusieurs rolling updates inutiles.

Mettez le déploiement en pause :

kubectl rollout pause deployment/campus-backend

Appliquez une modification (par exemple changer une variable d'environnement ou une ressource).
Constatez qu'aucun nouveau pod n'est encore instancié.
Reprenez le déploiement :
```
kubectl rollout resume deployment/campus-backend
```
Toutes les modifications sont appliquées en une seule transition propre !

Critères de Validation (Checklist)¶

campus-backend est déployé avec un fichier deployment-backend.yaml versionné.
Vous avez vérifié le self-healing en détruisant un pod en direct.
Vous maîtrisez le dimensionnement dynamique (scale).
Vous comprenez le rôle de maxSurge et maxUnavailable pour garantir zéro coupure.
Vous maîtrisez les commandes d'urgence SRE : kubectl rollout status, kubectl rollout history et kubectl rollout undo.
Vous savez geler et reprendre un déploiement avec rollout pause et rollout resume.