Adapter la mise à jour au quota

Introduction

Aster Supply sert son catalogue habituel tandis qu’une mise à jour hivernale est bloquée. Son espace de noms dispose de suffisamment de CPU demandé pour le fonctionnement ordinaire, mais pas pour le Pod supplémentaire demandé lors d’une mise à jour progressive. Vous choisirez un budget de déploiement adapté à l’allocation fixe, garderez la boutique de référence en fonctionnement et livrerez le catalogue mis à jour.

Vous devez déjà connaître les chemins de base du terminal, les bases de YAML, les Pods, les Deployments, les Services et les labels. Ce lab explique les unités de demande CPU, ResourceQuota et le calcul du budget de mise à jour. Le véritable cluster à un seul nœud, l’application, les contrôles de santé et les données du catalogue sont préparés ; aucune installation de cluster, construction d’image ni programmation d’application n’est requise. Le temps estimé inclut la lecture et les erreurs courantes ; c’est une estimation de l’auteur.

Adapter la mise à jour au budget fixe

Dans cette étape, vous terminerez la mise à jour du catalogue d’hiver d’Aster Supply sans augmenter son allocation CPU ni arrêter la boutique de référence.

L’onglet Shop affiche un catalogue fonctionnel. Ouvrez Stoneware tray, notez son prix et utilisez Back to collection pour revenir. La collection actuelle Everyday essentials comporte trois produits ; la collection demandée The winter edit ajoute Amber cup et modifie les prix. Ouvrez l’onglet Reference : Fern Stationery est un service distinct et protégé qui doit conserver son catalogue existant. Gardez son Deployment, son Service et son Pod d’origine inchangés. Passez ensuite à l’onglet Workspace.

Le cluster préparé est un véritable Kubernetes à un seul nœud. Un espace de noms regroupe les ressources de ce cours. Une ResourceQuota limite le total des ressources admises dans cet espace de noms. Ici, elle suit uniquement les demandes CPU : le CPU réservé pour l’ordonnancement, pas un budget financier ni un plafond d’utilisation CPU mesurée. 1000m signifie un cœur CPU ; 40m signifie 0,04 cœur. La mémoire est préparée et n’est pas le facteur limitant du quota dans cette tâche.

Lisez d’abord le quota. --context=labex-v135 sélectionne le cluster préparé, -n shop-quota sélectionne l’espace de noms de ce cours et describe affiche les détails d’un objet :

kubectl --context=labex-v135 -n shop-quota describe resourcequota shop-budget

Vous devez trouver requests.cpu avec Used 140m et Hard 140m. C’est du CPU réservé, pas l’utilisation actuelle. La boutique d’origine reste disponible, mais sa tentative de mise à jour nécessite un autre Pod. Un réplica disponible a passé son contrôle de préparation et la période minimale de préparation de trois secondes configurée ; créer un Pod ne suffit pas à le rendre disponible. Lisez le Deployment et ses ReplicaSets. Un ReplicaSet maintient les Pods d’un modèle de Deployment ; rs est son nom de ressource abrégé :

kubectl --context=labex-v135 -n shop-quota get deployments,rs,pods

Il y a trois réplicas de boutique disponibles et un réplica de référence. Le nouveau ReplicaSet de la boutique ne peut pas créer son Pod. Décrivez les deux ReplicaSets de la boutique ; -l app=shop sélectionne leur label :

kubectl --context=labex-v135 -n shop-quota describe rs -l app=shop

Repérez FailedCreate ou ReplicaFailure avec exceeded quota: shop-budget, requested: requests.cpu=40m, used: requests.cpu=140m et limited: requests.cpu=140m. C’est un refus d’admission : ce nouveau Pod n’a pas été créé. Cela diffère d’un Pod Pending existant que l’ordonnanceur ne peut placer. Ne modifiez pas le quota et ne supprimez pas la charge de travail de référence.

Le nouveau catalogue approuvé et le manifeste candidat sont déjà fournis. Entrez explicitement dans l’espace de travail. pwd affiche votre répertoire courant ; ls liste ses entrées :

cd /home/labex/project/shop-update

pwd

ls

Vous devez voir approved, starter et tools. cat affiche le catalogue approuvé :

cat approved/catalogue.json

Lisez tout le candidat avec sed -n '1,180p' : -n supprime la sortie habituelle et p affiche les lignes 1 à 180. La plage entre apostrophes constitue un seul argument :

sed -n '1,180p' starter/shop.yaml

La boutique nécessite trois réplicas demandant chacun 40m. La référence protégée demande 20m. Seul spec.strategy.rollingUpdate peut changer ; le nouveau modèle d’application fourni, les réplicas, les ressources, les sélecteurs et les contrôles de santé doivent rester intacts.

Une mise à jour progressive équilibre deux valeurs. maxSurge autorise des Pods supplémentaires au-delà du nombre de réplicas souhaité. maxUnavailable autorise l’indisponibilité de certains réplicas souhaités. L’exigence ici est au moins deux réplicas de boutique disponibles pendant la mise à jour observée. Avec trois réplicas souhaités, un peut être temporairement indisponible, mais aucun Pod supplémentaire ne tient dans le budget. Choisissez maxSurge: 0 et maxUnavailable: 1. Les deux valeurs ne peuvent pas être nulles. Recreate, supprimer le Deployment, réduire les demandes, diminuer le nombre souhaité ou augmenter le quota sortent du périmètre de cette tâche.

Créez un répertoire de publication modifiable et copiez le candidat fourni. mkdir crée un répertoire ; cp copie le fichier. Les originaux fournis sont en lecture seule. chmod u+w ajoute la permission d’écriture pour votre utilisateur sur la copie :

mkdir release

cp starter/shop.yaml release/shop.yaml

chmod u+w release/shop.yaml

Si release existe déjà après une tentative précédente, conservez-le et continuez avec la copie que vous modifiez. Pour une faute dans un chemin, utilisez les commandes pwd, ls et cd absolu ci-dessus avant de répéter la commande qui a échoué ; un chemin manquant ne nécessite pas de réinitialiser la VM.

sed -i modifie un fichier sur place. Chaque expression s/old/new/ remplace le texte indiqué. Les apostrophes gardent ensemble les espaces et la ponctuation. Modifiez uniquement les deux valeurs du déploiement progressif dans votre copie :

sed -i 's/maxSurge: 1/maxSurge: 0/' release/shop.yaml

sed -i 's/maxUnavailable: 0/maxUnavailable: 1/' release/shop.yaml

Lisez le début du manifeste enregistré avant de l’appliquer :

sed -n '1,35p' release/shop.yaml

Vous devez trouver replicas: 3, type: "RollingUpdate", maxSurge: 0 et maxUnavailable: 1. apply -f réconcilie ce fichier avec le Deployment existant ; il conserve l’identité du Deployment. rollout status attend les nouveaux réplicas, avec un --timeout fini :

kubectl --context=labex-v135 apply -f release/shop.yaml

kubectl --context=labex-v135 -n shop-quota rollout status deployment/shop --timeout=180s

Résultat attendu : deployment "shop" successfully rolled out. Le contrôleur peut supprimer un ancien réplica, en admettre un nouveau, attendre qu’il soit disponible, puis continuer. Les Pods en cours d’arrêt peuvent rester brièvement comptabilisés dans le quota ; un événement FailedCreate supplémentaire temporaire peut donc se résoudre naturellement, sans justifier une modification du quota. Le budget de déploiement n’est pas une limite absolue sur tous les processus en cours d’arrêt ni une garantie de disponibilité.

Si une modification incorrecte empêche la complétion, examinez le fichier enregistré et corrigez les deux valeurs de stratégie. Pour récupérer après une tentative infructueuse ou un échec de fenêtre d’observation, réappliquez l’état de référence approuvé d’origine et attendez avant de réessayer votre publication corrigée :

kubectl --context=labex-v135 apply -f approved/shop.yaml

kubectl --context=labex-v135 -n shop-quota rollout status deployment/shop --timeout=180s

L’option --wait-baseline de l’outil d’état fourni attend une observation récente et saine de l’ancien catalogue avant une nouvelle tentative. Elle lit uniquement les faits enregistrés :

./tools/update-status --wait-baseline

kubectl --context=labex-v135 apply -f release/shop.yaml

kubectl --context=labex-v135 -n shop-quota rollout status deployment/shop --timeout=180s

Ces commandes de récupération sont nécessaires uniquement après une tentative infructueuse. Gardez l’état de référence fourni inchangé. L’observateur en lecture seule conserve les tentatives et distingue une nouvelle tentative complète de l’état de référence à la mise à jour ; la récupération n’efface pas les preuves précédentes.

Enfin, relisez la charge de travail réelle et le quota :

kubectl --context=labex-v135 -n shop-quota get deployments

kubectl --context=labex-v135 -n shop-quota describe resourcequota shop-budget

Les deux Deployments doivent être disponibles : shop 3/3 et reference 1/1. Une fois les anciens Pods terminés, l’utilisation du quota revient à 140m avec la même valeur maximale. L’étape suivante vérifie le catalogue réellement reçu par les personnes.

Livrer le catalogue mis à jour

Dans cette étape, vous examinerez la nouvelle expérience client et conserverez un véritable téléchargement du catalogue avec le manifeste de publication enregistré.

Commencez dans Workspace, à /home/labex/project/shop-update. La commande fournie tools/update-status résume les véritables échantillons API et HTTP enregistrés par un observateur en lecture seule. Le préfixe ./ exécute un programme relativement au répertoire courant :

./tools/update-status

Elle indique le minimum requis, le nombre d’échantillons, le minimum de réplicas disponibles échantillonné et le dernier état de mise à jour. Vous devez obtenir un minimum d’au moins deux et trois réplicas mis à jour et disponibles à la complétion. L’observateur échantillonne environ toutes les demi-secondes, plus le temps API, vérifie le quota et la référence d’origine et enregistre les échecs. Laissez cet observateur fourni fonctionner. Il ne prouve pas ce qui s’est passé entre les échantillons, ne garantit pas la disponibilité en production et ne répare pas le cluster. Une vérification juste après la fin du déploiement peut nécessiter une brève attente de deux échantillons terminés. Si une tentative a enfreint le minimum requis ou présenté une longue interruption d’observation, utilisez la récupération de l’état de référence enseignée à l’étape précédente avant une tentative corrigée.

Passez à Shop et rechargez la page. Vous devez voir The winter edit, quatre produits, Stoneware tray $20.00, Linen cloth $14.00, Bud vase $24.00 et Amber cup $16.00. Ouvrez Amber cup et confirmez son prix et son état Available in store, puis revenez avec Back to collection. C’est un catalogue sans paiement en ligne.

La collection terminée comporte quatre véritables fiches produit. Comparez le titre de collection et les prix avec cet exemple en cours d’exécution :

Utilisez Download catalogue. Ouvrez le fichier catalogue.csv téléchargé par le navigateur ; ses quatre lignes doivent correspondre à la collection, aux noms, aux prix en centimes et à la disponibilité affichés sur le site. Le téléchargement du navigateur et l’espace de travail du terminal sont des emplacements distincts. Enregistrez ensuite le même véritable téléchargement du Service dans l’espace de travail pour le transmettre.

Revenez à Workspace. curl récupère une URL. --fail signale les erreurs HTTP, --silent --show-error masque l’indicateur de progression tout en conservant les erreurs et --output écrit les octets de la réponse dans le fichier nommé. 127.0.0.1:8081 est l’entrée locale préparée qui transmet au Service de boutique d’origine :

curl --fail --silent --show-error http://127.0.0.1:8081/catalogue.csv --output catalogue.csv

cat catalogue.csv

Résultat attendu :

id,name,price_cents,available,collection
stone-tray,Stoneware tray,2000,true,The winter edit
linen-cloth,Linen cloth,1400,true,The winter edit
bud-vase,Bud vase,2400,true,The winter edit
amber-cup,Amber cup,1600,true,The winter edit

Une erreur de connexion signifie que l’entrée locale n’a pas pu être jointe ; une erreur HTTP est une réponse d’un serveur. Revenez aux commandes de charge de travail et de déploiement enseignées pour examiner l’état courant ; ne remplacez pas le résultat par un fichier statique et ne modifiez pas le service de transfert préparé. Si un téléchargement est incomplet ou écrasé accidentellement, répétez la même commande curl une fois le bon catalogue disponible.

Ouvrez à nouveau Reference et rechargez. Fern Stationery doit toujours afficher Desk essentials, Field notebook $9.00 et Clay pencil cup $14.00. Ouvrez un produit et revenez pour confirmer que ses véritables liens fonctionnent toujours.

Votre livraison est release/shop.yaml accompagné du véritable catalogue.csv, avec la nouvelle publication complète, le quota inchangé, le service de référence d’origine et une tentative de mise à jour observée valide. Préservez les originaux fournis, l’application, les Services et l’observateur en lecture seule.

Résumé

Vous avez relié un véritable refus de quota d’un ReplicaSet aux besoins temporaires en ressources d’une mise à jour progressive, calculé un budget approprié de Pods supplémentaires et d’indisponibilité, puis publié le nouveau catalogue sans augmenter l’allocation. Vous avez aussi conservé le service de référence protégé et livré un véritable CSV avec un manifeste de publication réutilisable.

Les demandes CPU décrivent la comptabilisation des ressources, pas l’utilisation mesurée ni une promesse de performances. Les observations natives finies étayent la vérification de disponibilité de ce cours ; elles ne démontrent pas une disponibilité de production ininterrompue. Dans un autre espace de noms, recalculez à la fois l’allocation restante et le nombre minimal de réplicas disponibles avant de choisir la stratégie.