Introduction
Field Notes possède vingt photographies de jardins sous licence et a besoin d’une petite galerie que le personnel puisse télécharger. Vous commencerez par essayer un groupe, puis exécuterez les quatre groupes avec un Job Kubernetes. Le dernier groupe ne contient que deux photographies ; il a tout de même besoin de son propre index de complétion réussi.
Vous devez déjà connaître les Pods, les Deployments, les Services, les labels, les bases de YAML et les chemins de base dans un terminal. Les Jobs, les index de complétion, ce volume partagé et les commandes de modification utilisées ici sont présentés ci-dessous. Le cluster, l’image du processeur, les photographies originales, le site et le stockage sont prêts. Vous n’avez pas besoin d’écrire du Python, de construire une image ni de disposer d’un compte cloud.
Utilisez Workspace pour les commandes et Gallery pour le site. Ces deux entrées utilisent une même VM de formation. Ne modifiez pas les fichiers fournis sous starter/ et inputs/, les photographies sources, la référence, le processeur, les services ni le stockage. Les 45 minutes estimées par l’auteur incluent la lecture et les erreurs courantes.
Essayer d’abord un groupe
Dans cette étape, comparez un exemple terminé normal avec sa source, puis utilisez un Job à un seul index pour traiter un échantillon distinct.
Ouvrez Gallery. Sur la page d’accueil, la grande photographie porte la mention Source collection · licensed garden photographs : c’est une donnée d’entrée, pas un travail que vous avez terminé. Sélectionnez See the reference. Thumbnail est un JPEG de 320 × 220 fourni ; Licensed source copy conserve les proportions d’origine. Le recadrage explique pourquoi leurs bords diffèrent. Sélectionnez Gallery dans la navigation de la page. Elle affiche initialement 0 of 20 images available.
Passez à Workspace. Ce terminal démarre dans /home/labex/project/photo-gallery. pwd affiche ce répertoire de travail :
pwd
Si vous vous êtes déplacé ailleurs, revenez avec cd /home/labex/project/photo-gallery. Tous les noms de fichiers relatifs ci-dessous partent de cet emplacement. Les fichiers persistent dans cette VM, mais chaque autre lab démarre avec ses propres fichiers et ressources de cluster indépendants.
Un Deployment maintient un service en cours d’exécution. Un Job, lui, exécute des Pods jusqu’à ce qu’un travail fini soit terminé. Le programme de traitement fourni traite un groupe de photographies, puis se termine. Dans un Job indexé, Kubernetes attribue à chaque complétion requise un numéro commençant à zéro. Le programme lit sa valeur native JOB_COMPLETION_INDEX et choisit le groupe correspondant. Vous configurez le Job au lieu d’écrire le programme de traitement.
Lisez le manifeste d’échantillon fourni. cat affiche un fichier sans le modifier :
cat starter/sample-job.yaml
Ses champs importants sont completionMode: Indexed, completions: 1 et parallelism: 1. Ils demandent uniquement l’index 0, avec un seul programme de traitement simultané souhaité. restartPolicy: Never signifie qu’un conteneur en échec reste en échec dans son Pod ; la politique du Job décide si un autre Pod est nécessaire. backoffLimit: 0 signifie qu’il n’y a aucune nouvelle tentative dans cet exercice où la source fonctionne normalement, et activeDeadlineSeconds: 180 limite la durée d’activité du Job. Les autres champs relient l’image préparée, le plan d’entrée et le volume de sortie ; laissez-les inchangés.
Une PersistentVolumeClaim, ou PVC, demande du stockage persistant. La PVC gallery-output préparée conserve les fichiers après la fin d’un programme de traitement. Ici, son volume ReadWriteOnce peut être monté par plusieurs Pods sur le même nœud. Cela ne garantit pas une écriture partagée sur plusieurs nœuds. L’échantillon écrit dans un répertoire distinct sample ; il ne peut donc pas remplir silencieusement la galerie finale.
Appliquez l’échantillon. apply -f lit le fichier YAML nommé ; -n sélectionne l’espace de noms, qui regroupe les ressources Kubernetes de ce projet :
kubectl apply -n photo-workshop -f starter/sample-job.yaml
Attendez la condition native Complete du Job. --timeout=180s limite la durée d’attente de cette commande ; il ne modifie pas le délai du Job :
kubectl wait -n photo-workshop --for=condition=Complete job/gallery-sample --timeout=180s
Fin attendue : job.batch/gallery-sample condition met. Une expiration du délai ne prouve pas à elle seule un échec : examinez le Job et ses journaux avec les commandes enseignées à l’étape 3 avant de décider quoi modifier. Ne relancez pas la préparation et ne supprimez pas les ressources fournies.
Passez à Gallery, sélectionnez Sample et confirmez 6 of 6 images available. Ouvrez Windmill garden, comparez sa miniature à sa source, puis sélectionnez Back to sample. Sélectionnez Gallery dans la navigation de la page : la collection finale est toujours vide. Cette distinction évite de confondre un essai réussi avec la livraison complète.
Planifier chaque index de complétion
Dans cette étape, transformez la répartition des entrées en un manifeste de Job enregistré. Rien dans cette étape ne lance encore le travail final.
Passez à Workspace, dans /home/labex/project/photo-gallery. Lisez la répartition complète des entrées :
cat inputs/groups.txt
Il y a quatre lignes, de Index 0 à Index 3. Les trois premières contiennent chacune six photographies ; l’index 3 contient photo-19 et photo-20. completions compte les groupes, pas les photographies : cette livraison nécessite 4 index réussis, ni 20 ni 3.
Lisez les consignes du personnel :
cat inputs/brief.txt
Elles autorisent un parallélisme demandé de 1 à 2. Nous demanderons 2 pour que deux groupes puissent progresser ensemble. Kubernetes peut exécuter moins de Pods lorsque les ressources sont indisponibles ; le parallélisme demandé n’est pas une limite absolue sur tous les processus lors des nouvelles tentatives ou de leur arrêt. Ce projet utilise un petit nœud préparé, plutôt qu’une plateforme de traitement distribuée.
Copiez le modèle préparé du Job final dans votre fichier modifiable. cp copie un fichier ; il laisse intacte la source sous starter/ :
cp starter/gallery-job.yaml gallery-job.yaml
Si cp signale No such file or directory, vérifiez pwd, revenez au répertoire ci-dessus et répétez la même copie avec le nom de fichier exact. Ne créez pas de modèle de remplacement vide.
Utilisez sed pour modifier deux valeurs littérales de champs dans le fichier copié. -i modifie ce fichier sur place. Chaque expression a la forme s/old/new/ : remplacer l’ancien texte par le nouveau. Les apostrophes font transmettre l’expression littéralement par le shell. Chacun de ces champs exacts apparaît une seule fois dans ce modèle fourni :
sed -i 's/completions: 1/completions: 4/' gallery-job.yaml
sed -i 's/parallelism: 1/parallelism: 2/' gallery-job.yaml
Lisez le résultat enregistré avant de l’appliquer :
cat gallery-job.yaml
Confirmez metadata.name: gallery-batch, completionMode: Indexed, completions: 4 et parallelism: 2. Conservez l’image du processeur préparée, la commande, l’environnement, les montages, les paramètres de ressources, la politique sans nouvelle tentative et le délai de 180 secondes. Un formatage YAML équivalent ou un autre nom de nouveau Job final est acceptable ; le fichier enregistré doit décrire le Job que vous exécutez réellement.
Un remplacement mal saisi peut se terminer sans erreur sans avoir trouvé de correspondance ; il est donc important de lire le résultat. Si vous n’avez pas encore appliqué le fichier, corrigez la situation en recopiant le modèle d’origine et en répétant les deux modifications. Après avoir appliqué un Job, évitez de recopier un nom qui entrerait en conflit : les modèles de tâches des Jobs sont généralement immuables ; préparez donc un nouveau nom de Job pour une autre tentative.
Exécuter le lot complet
Dans cette étape, appliquez votre Job enregistré et reliez ses preuves natives de complétion aux véritables Pods de traitement.
Dans Workspace, à /home/labex/project/photo-gallery, appliquez le fichier enregistré :
kubectl apply -n photo-workshop -f gallery-job.yaml
Attendez tous les index requis :
kubectl wait -n photo-workshop --for=condition=Complete job/gallery-batch --timeout=180s
Lisez le résumé natif du Job :
kubectl get job gallery-batch -n photo-workshop
Le Job terminé doit afficher 4/4 complétions. describe ajoute des détails et des événements :
kubectl describe job gallery-batch -n photo-workshop
Repérez Completion Mode: Indexed et Completed Indexes: 0-3. Une plage inclut ses deux extrémités ; elle couvre donc les quatre groupes, y compris le dernier groupe plus court. La preuve de complétion ne démontre pas à elle seule que le contenu des images est correct ; vous allez ensuite les examiner et les télécharger.
Listez uniquement les Pods appartenant à ce Job. -l sélectionne selon un label. -L ajoute une colonne affichant un autre label, ici l’index de complétion :
kubectl get pods -n photo-workshop -l batch.kubernetes.io/job-name=gallery-batch -L batch.kubernetes.io/job-completion-index
Vous devez trouver des Pods terminés pour les index 0, 1, 2 et 3. Completed dans ce tableau correspond à la phase de réussite du Pod. Lisez la sortie réelle de leurs programmes de traitement. --all-pods=true inclut les Pods du Job et --prefix=true identifie le Pod qui a produit chaque ligne :
kubectl logs -n photo-workshop job/gallery-batch --all-pods=true --prefix=true
Chaque programme nomme les photographies qui lui sont affectées et signale des sorties 320 x 220. L’index 3 doit terminer deux photographies. Ces journaux aident à expliquer ce qui s’est passé ; les fichiers réels, leurs relations avec les sources et les Pods réussis appartenant au Job sont également vérifiés.
Si le délai expire, utilisez describe et les mêmes commandes de Pods et de journaux pour distinguer une charge de travail inachevée d’une charge en échec. Un nom de Job inconnu signifie généralement que le fichier n’a pas été appliqué ou que son nom diffère : lisez gallery-job.yaml et utilisez ce nom réel. N’effacez pas les Pods terminés ni l’échantillon. Le prochain lab guidé enseigne la récupération après une panne temporaire délibérée de la source.
Transmettre de vraies images
Dans cette étape, examinez le site complet et enregistrez les deux fichiers de livraison utilisables.
Passez à Gallery, sélectionnez Gallery dans la navigation de la page et actualisez. Confirmez 20 of 20 images available. Ouvrez Blue and yellow flowers (photo-20), du dernier groupe plus court. Comparez la miniature à sa propre source ; elle ne doit pas être une copie répétée d’une autre fleur. Sélectionnez Download thumbnail, puis Back to gallery.
La galerie finale contient vingt photographies distinctes préparées, dont les deux images du dernier groupe plus court. Les actions de téléchargement se trouvent sous la collection.
Sous Take the collection with you, sélectionnez Download source index CSV et Download gallery ZIP. Le CSV associe chaque sortie à son empreinte de source, son empreinte de miniature, son créateur et sa page source. Le ZIP contient index.csv et les véritables JPEG sous photos/. La page indique les fichiers réellement disponibles ; elle ne régénère pas le travail manquant à partir des originaux. Une collection incomplète peut tout de même être téléchargée ; vérifiez donc le résultat complet avant de le transmettre.
Sélectionnez Reference dans la navigation de la page et confirmez que l’exemple d’origine fourni fonctionne toujours. Sélectionnez Credits pour voir les créateurs et les liens sources Wikimedia Commons. Les photographies sont des ressources d’exercice sous licence CC0, pas des photographies prises par LabEx.
Passez à Workspace, à /home/labex/project/photo-gallery. Enregistrez ici les mêmes véritables téléchargements. curl demande une URL ; --fail renvoie une erreur en cas d’échec HTTP, --silent --show-error masque l’indicateur de progression tout en conservant les erreurs et -o nomme le fichier de sortie. Le port 8091 permet d’accéder au Service de galerie préparé depuis cette VM :
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
Les téléchargements du navigateur sont enregistrés par le navigateur ; ces deux commandes enregistrent les copies requises dans l’espace de travail de la VM. Si une requête échoue, examinez le site et répétez la requête après avoir résolu le problème. Ne modifiez pas un index reçu pour masquer des images manquantes.
Affichez l’en-tête et les deux premières lignes de données. head -n 3 lit les trois premières lignes :
head -n 3 gallery-index.csv
L’en-tête commence par id,title,source_file,thumbnail,width,height. Chaque ligne associe une photographie à son propre photos/photo-NN.jpg, avec les dimensions 320,220 et sa véritable attribution de source.
Listez l’archive sans l’extraire. python3 -m zipfile exécute l’utilitaire ZIP standard de Python ; -l liste les membres :
python3 -m zipfile -l gallery.zip
Repérez index.csv et les vingt chemins de JPEG, dont photos/photo-20.jpg. Les noms ou les nombres seuls ne prouvent pas que les images sont correctes ; les vérifications fonctionnelles décodent donc aussi les véritables JPEG et comparent chacun à son propre résultat dérivé de la source. Gardez disponibles gallery-job.yaml, les deux téléchargements, l’échantillon, les Pods terminés, les fichiers sources, la référence et les services préparés.
Résumé
Vous avez livré une véritable galerie photo avec un Job indexé. Vous avez associé les photographies aux index de complétion, limité le parallélisme demandé, vérifié les éléments natifs des Pods et du Job, puis transmis de vraies images avec un index des sources. L’échantillon et la référence sont restés distincts du travail final.
