Introduction
Field Notes dispose d’une galerie partiellement préparée. Un groupe a reçu une réponse HTTP 503 temporaire de sa source, tandis que les autres groupes ont terminé. Vous conserverez les preuves de cet échec, exécuterez un nouveau Job avec un petit nombre de nouvelles tentatives autorisées et livrerez la collection complète sans réécrire les JPEG déjà corrects.
Cette VM indépendante comprend ses propres vingt photographies sources, son stockage partagé, son site, son Job en échec et ses sorties partielles. Vous n’avez pas besoin des fichiers de la VM précédente. Terminez d’abord Construire la galerie par lots, ou maîtrisez son Job indexé, la copie et la modification de YAML, l’examen des Pods et le déroulement des téléchargements. La durée de 40 minutes est une estimation de l’auteur.
Utilisez Workspace pour les commandes et Gallery pour le site. Préservez les fichiers fournis, les images sources et de référence, le processeur, le plan, les services, la PVC, le Job d’origine first-try, ainsi que ses Pods et ses journaux.
Récupérer le groupe de photos en échec
Dans cette étape, reliez la galerie incomplète à l’index natif en échec avant de choisir une politique de récupération.
Ouvrez Gallery, sélectionnez Open the gallery et confirmez 14 of 20 images available. Les premier, troisième et quatrième groupes ont terminé ; les six photographies du groupe 1 sont absentes. Ouvrez Reference dans la navigation de la page pour voir l’exemple normal fourni, puis passez à Workspace.
Le terminal démarre à /home/labex/project/photo-gallery. Utilisez pwd pour le confirmer ; si nécessaire, revenez avec cd /home/labex/project/photo-gallery. Lisez la répartition des groupes et les consignes du personnel :
cat inputs/groups.txt
cat inputs/brief.txt
Il y a quatre groupes numérotés à partir de zéro. L’index 1 contient de photo-07 à photo-12. Examinez la tentative conservée :
kubectl describe job first-try -n photo-workshop
Repérez Completion Mode: Indexed, Completed Indexes: 0,2,3, un Pod en échec dans Pods Statuses et l’avertissement FailedIndexes sous Events. Les index terminés et le tableau des Pods ci-dessous identifient le groupe manquant. Lisez sa politique dans la source fournie :
cat starter/first-try.yaml
backoffLimitPerIndex: 0 n’autorise aucun remplacement après un échec pour un index. backoffLimit: 6 est un budget global d’échecs distinct : il ne remplace pas une autorisation nulle par index. activeDeadlineSeconds: 180 limite la durée d’activité. Le Job reste en échec même si plusieurs index ont réussi.
Listez ses véritables Pods et leurs labels d’index :
kubectl get pods -n photo-workshop -l batch.kubernetes.io/job-name=first-try -L batch.kubernetes.io/job-completion-index
Lisez tous leurs journaux :
kubectl logs -n photo-workshop job/first-try --all-pods=true --prefix=true
Le Pod de l’index 1 signale Source returned HTTP 503 et se termine ; les autres groupes indiquent les photographies qu’ils ont terminées. HTTP 503 signifie que la source a répondu, mais était temporairement indisponible. Cela diffère d’un Pod absent, d’un échec de connexion ou d’un JPEG illisible.
Copiez le nom complet du Pod de l’index 1 depuis le tableau dans la commande suivante, en remplaçant POD_NAME au lieu de saisir littéralement cet espace réservé :
kubectl describe pod POD_NAME -n photo-workshop
Son conteneur terminé affiche Exit Code: 42. Il s’agit de la réponse délibérée du programme de traitement fourni à l’erreur HTTP de la source, pas d’un code d’erreur HTTP général de Kubernetes. Le scénario produit une véritable réponse 503 pour la première requête de l’index 1 de chaque nouveau Job. Le Pod de remplacement suivant pour ce même index peut lire la source avec succès. C’est un exercice contrôlé de panne temporaire ; cela ne signifie pas que toute réponse 503 en production permet une nouvelle tentative sans risque.
Conservez le Job en échec, ses Pods et ses journaux, ainsi que les quatorze JPEG existants corrects. Le processeur n’écrit un JPEG identique que lorsque c’est nécessaire ; les octets d’image qui correspondent déjà et les métadonnées de leurs fichiers sont conservés. Les reçus par Pod et les enregistrements de l’index des images peuvent être mis à jour pour identifier la nouvelle tentative réussie.
Autoriser un nombre fini de nouvelles tentatives par index
Créez maintenant un nouveau Job autorisant une nouvelle tentative par index. N’essayez pas de transformer le Job déjà en échec en une nouvelle exécution.
Dans Workspace, à /home/labex/project/photo-gallery, copiez le brouillon de récupération fourni :
cp starter/recovery-job.yaml gallery-job.yaml
Comme dans le lab précédent, cp conserve la source intacte. Si la source est introuvable, confirmez pwd, revenez dans l’espace de travail et répétez la copie exacte. Lisez le brouillon :
cat gallery-job.yaml
Il demande déjà les quatre index avec un parallélisme de 2, mais porte le nom provisoire gallery-draft et n’autorise aucune nouvelle tentative par index. Utilisez sed -i pour remplacer chaque valeur littérale dans votre fichier copié ; les apostrophes protègent les expressions de remplacement contre l’interprétation du shell :
sed -i 's/name: gallery-draft/name: gallery-retry/' gallery-job.yaml
sed -i 's/backoffLimitPerIndex: 0/backoffLimitPerIndex: 1/' gallery-job.yaml
Relisez le fichier :
cat gallery-job.yaml
Confirmez name: gallery-retry, completions: 4, parallelism: 2 et backoffLimitPerIndex: 1. Conservez backoffLimit: 6, activeDeadlineSeconds: 180 et tous les paramètres fournis du processeur, des montages, de l’identité et des ressources. Cette tâche accepte une ou deux nouvelles tentatives par index, mais une petite autorisation finie suffit. Supprimer le délai ou autoriser des tentatives illimitées masquerait un problème persistant.
Un nouveau Job a une nouvelle identité Kubernetes. Il peut traiter des groupes qui ont déjà réussi ; le programme fourni gère cette répétition sans réécrire les JPEG correspondants. Ne déduisez pas d’un Job réussi que chaque traitement a eu lieu exactement une fois. Conserver l’ancien Job en échec garde aussi visible la raison de cette récupération. Si une modification n’a trouvé aucune correspondance, recopiez et corrigez le brouillon avant de l’appliquer. Si vous avez déjà créé un Job final inadapté, gardez ses preuves et préparez un autre nouveau nom dans le fichier enregistré au lieu de modifier un modèle de Pod immuable ou de supprimer first-try.
Appliquez le nouveau Job enregistré :
kubectl apply -n photo-workshop -f gallery-job.yaml
Attendez sa réussite :
kubectl wait -n photo-workshop --for=condition=Complete job/gallery-retry --timeout=180s
Examinez ses index et sa politique :
kubectl describe job gallery-retry -n photo-workshop
Le résultat attendu est Completed Indexes: 0-3. La commande wait précédente a déjà confirmé la condition native Complete. Listez les véritables Pods :
kubectl get pods -n photo-workshop -l batch.kubernetes.io/job-name=gallery-retry -L batch.kubernetes.io/job-completion-index
L’index 1 possède maintenant un Pod en échec et un autre Pod de remplacement terminé pour le même index. Le Pod en échec est une preuve attendue de ce test contrôlé. Lisez leur sortie :
kubectl logs -n photo-workshop job/gallery-retry --all-pods=true --prefix=true
Vous devez voir la véritable réponse HTTP 503, puis le traitement réussi dans son remplacement. Les autres groupes signalent Kept pour les JPEG qui correspondaient déjà. Si le délai expire, examinez le nouveau Job et les journaux des Pods ; n’effacez pas l’ancien échec, ne réinitialisez pas la préparation et n’augmentez pas aveuglément les limites de nouvelles tentatives. Le parallélisme demandé est un réglage de concurrence souhaitée, pas une garantie absolue du nombre de processus lors du remplacement.
Livrer la collection récupérée
Dans cette étape, prouvez que la nouvelle tentative a produit la galerie complète utilisable et enregistrez ses téléchargements actuels.
Passez à Gallery, sélectionnez Gallery dans la navigation de la page et actualisez. Confirmez 20 of 20 images available. Ouvrez Black-and-white blossoms (photo-07), la première photographie du groupe récupéré, et comparez-la à sa propre source. Sélectionnez Download thumbnail et Back to gallery. Ouvrez aussi Blue and yellow flowers (photo-20), du dernier groupe plus court.
La collection récupérée comprend maintenant les six photographies manquantes et le dernier groupe plus court. La page renvoie toujours à la référence inchangée et aux sources sous licence.
Revenez à la galerie et utilisez Download source index CSV et Download gallery ZIP. Sélectionnez Reference pour confirmer que l’exemple fourni reste intact, puis Credits pour vérifier l’attribution des sources. Le site affiche uniquement les sorties réelles et lisibles du programme de traitement ; il ne complète pas les images manquantes à partir de la collection source.
Passez à Workspace, à /home/labex/project/photo-gallery. Enregistrez les véritables fichiers de livraison actuels avec les mêmes options que dans le premier lab :
curl --fail --silent --show-error http://127.0.0.1:8091/download/index.csv -o gallery-index.csv
curl --fail --silent --show-error http://127.0.0.1:8091/download/gallery.zip -o gallery.zip
Examinez l’en-tête du CSV et les premières lignes :
head -n 3 gallery-index.csv
Listez l’archive sans risque, sans l’extraire :
python3 -m zipfile -l gallery.zip
Elle contient index.csv et vingt véritables JPEG, y compris le groupe récupéré et photos/photo-20.jpg. Les empreintes de source et de miniature relient chaque photographie à son propre résultat ; les noms de fichiers seuls ne suffisent pas.
Enfin, confirmez que les deux tentatives restent disponibles :
kubectl get jobs -n photo-workshop
Le Job d’origine first-try est en échec et le nouveau gallery-retry est terminé. C’est l’état final attendu. Laissez disponibles le manifeste enregistré, les téléchargements, les Pods réussis et en échec, les quatorze JPEG d’origine, les sources et la référence. Si un téléchargement échoue ou est incomplet, corrigez la charge de travail ou le service et téléchargez à nouveau ; ne réparez pas les fichiers reçus à la main.
Résumé
Vous avez diagnostiqué l’échec partiel d’un Job indexé, préservé ses preuves natives et utilisé un nouveau Job avec un nombre fini de nouvelles tentatives par index pour terminer la véritable collection. Les fichiers dérivés des sources, les JPEG réussis d’origine, la galerie en cours d’exécution, le manifeste enregistré et la livraison concordent désormais.
