Déployer et mettre à jour un microservice NGINX

Introduction

Vous voici arrivé au dernier défi de ce cours pour débutants. Les laboratoires précédents vous ont familiarisé avec les Pods, les Deployments, les Services, la mise à l’échelle, le dépannage et le retour arrière. Vous allez maintenant réunir ces notions dans une courte tâche de mise en production, sans procédure détaillée commande par commande.

L’environnement contient une version initiale saine nommée web-app. Votre mission consiste à publier la prochaine image NGINX explicitement versionnée, tout en conservant trois réplicas disponibles et le Service stable. L’état final du cluster et le manifeste enregistré doivent correspondre afin que la mise en production reste reproductible après le défi.

Publier la prochaine version de NGINX

Démarrage de l’environnement : Ce lab démarre pour vous un cluster Kubernetes complet. La configuration du plan de contrôle, du nœud et des composants réseau prend généralement 2 à 3 minutes. Veuillez patienter jusqu’à la fin du chargement de l’environnement avant de commencer.

Situation actuelle

L’équipe plateforme a préparé une version initiale dans /home/labex/project/final-release/web-app.yaml. Elle exécute actuellement nginx:1.26-alpine avec trois réplicas derrière le Service web-app.

Périmètre

• Travaillez avec le Deployment web-app, le Service, le manifeste et le client release-check existants.
• Ne renommez aucune ressource, ne modifiez pas les sélecteurs et ne remplacez pas le budget approuvé pour la mise à jour progressive.
• Utilisez l’image cible explicitement versionnée ; les balises flottantes telles que latest ne sont pas acceptées pour cette mise en production.

Votre objectif

Publiez nginx:1.27-alpine via le Deployment existant et laissez le cluster actif, le chemin d’accès au Service et le manifeste enregistré dans un état sain et reproductible.

Critères d’acceptation

• Le Deployment web-app utilise exactement trois réplicas souhaités.
• Son conteneur nginx utilise précisément l’image versionnée nginx:1.27-alpine.
• Son budget de mise à jour progressive reste maxUnavailable: 0 et maxSurge: 1.
• L’annotation indiquant la cause de la modification décrit la mise en production de NGINX 1.27.
• Le Service web-app sélectionne toujours les Pods du Deployment et dispose de trois backends prêts.
• Les trois réplicas mis à jour sont prêts et disponibles, et une requête HTTP exécutée dans le cluster vers http://web-app aboutit.
• /home/labex/project/final-release/web-app.yaml contient l’image finale et les paramètres de mise à jour progressive ; une nouvelle application de ce fichier conserverait donc l’état accepté.

Utilisez les commandes d’inspection et de suivi du déploiement Kubernetes pour déterminer quand la mise en production est terminée. Si la mise à jour est encore en cours, attendez sa fin au lieu de vous fier uniquement au premier résultat de kubectl get.

Indices

Observez notamment les colonnes READY, UP-TO-DATE et AVAILABLE du Deployment, les images des Pods, l’historique des mises à jour et les adresses des EndpointSlices du Service.

Résumé

Vous avez terminé le cours en publiant de manière autonome une image NGINX explicitement versionnée via un Deployment Kubernetes. Vous avez conservé un budget de disponibilité explicite, attendu que tous les réplicas soient mis à jour, maintenu le Service connecté à trois backends prêts, vérifié une requête exécutée dans le cluster et enregistré l’état accepté dans un fichier YAML.

Ces vérifications constituent une procédure réutilisable pour débuter : déclarer l’état souhaité, l’appliquer, observer la progression du contrôleur, vérifier la charge de travail et son chemin d’accès, puis maintenir le manifeste synchronisé avec le cluster.