Do180 4.14 Student Guide FR

Student Workbook (ROLE)
OCP 4.14 DO180

Red Hat OpenShift Administration I:
Operating a Production Cluster
Édition 2
DO180-OCP4.14-fr-2-20240530 Copyright ©2024 Red Hat, Inc.

DO180-OCP4.14-fr-2-20240530 Copyright ©2024 Red Hat, Inc.
Red Hat OpenShift
Administration
I: Operating a
Production Cluster
OCP 4.14 DO180
Red Hat OpenShift Administration I: Operating a Production
Cluster
Édition 2 20240530
Date de publication 20240530
Auteurs: Guy Bianco IV, Christopher Caillouet, Alex Corcoles, Natalie Lind,
Maria Ordonez, Randy Thomas, Hervé Quatremain, Manna Kong
Architecte du cours: Fernando Lozano
Ingénieurs DevOps: Benjamin Marco, Zach Gutterman
Éditeur: Julian Cable
© 2024 Red Hat, Inc.
The contents of this course and all its modules and related materials, including handouts to audience members, are ©
2024 Red Hat, Inc.
No part of this publication may be stored in a retrieval system, transmitted or reproduced in any way, including, but
not limited to, photocopy, photograph, magnetic, electronic or other record, without the prior written permission of
Red Hat, Inc.
This instructional program, including all material provided herein, is supplied without any guarantees from Red Hat,
Inc. Red Hat, Inc. assumes no liability for damages or legal action arising from the use or misuse of contents or details
contained herein.
If you believe Red Hat training materials are being used, copied, or otherwise improperly distributed, please send
email to training@redhat.com [mailto:training@redhat.com] or phone toll-free (USA) +1 (866) 626-2994 or +1 (919)
754-3700.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, JBoss, OpenShift, Fedora, Hibernate, Ansible, RHCA, RHCE,
RHCSA, Ceph, and Gluster are trademarks or registered trademarks of Red Hat, Inc. or its subsidiaries in the United
States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle American, Inc. and/or its affiliates.
XFS® is a registered trademark of Hewlett Packard Enterprise Development LP or its subsidiaries in the United
States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is a trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open
source or commercial project.
The OpenStack word mark and the Square O Design, together or apart, are trademarks or registered trademarks
of OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's
permission. Red Hat, Inc. is not affiliated with, endorsed by, or sponsored by the OpenStack Foundation or the
OpenStack community.
All other trademarks are the property of their respective owners.
Contributeurs:Sourabh Mishra, Ted Singdahlsen

Conventions de la documentation ix
Avertissements ........................................................................................................ ix
Langage inclusif ........................................................................................................ x
Introduction xi
Red Hat OpenShift Administration I: Operating a Production Cluster ................................ xi
Organisation de l’environnement de la classe .............................................................. xiii
Exécution des exercices pratiques ............................................................................. xix
1. Présentation de Kubernetes et d’OpenShift 1

Les conteneurs et Kubernetes ................................................................................... 2
Quiz: Les conteneurs et Kubernetes ............................................................................ 7
Composants et éditions de Red Hat OpenShift ............................................................ 9
Quiz: Composants et éditions de Red Hat OpenShift .................................................... 13
Exploration de la console Web OpenShift .................................................................. 16
Exercice guidé: Exploration de la console Web OpenShift ............................................. 22
Surveillance d’un cluster OpenShift .......................................................................... 36
Exercice guidé: Surveillance d’un cluster OpenShift ..................................................... 42
Open Lab: Présentation de Kubernetes et d’OpenShift ................................................ 53
Quiz: Présentation de Kubernetes et d’OpenShift ....................................................... 60
Résumé ................................................................................................................ 64
2. API et interfaces de ligne de commande Kubernetes et OpenShift 65

Interfaces de ligne de commande Kubernetes et OpenShift ........................................ 66
Exercice guidé: Interfaces de ligne de commande Kubernetes et OpenShift .................... 77
Examen des ressources Kubernetes ......................................................................... 85
Exercice guidé: Examen des ressources Kubernetes .................................................... 96
Évaluation de l’intégrité d’un cluster OpenShift ......................................................... 107
Exercice guidé: Évaluation de l’intégrité d’un cluster OpenShift ..................................... 122
Open Lab: API et interfaces de ligne de commande Kubernetes et OpenShift ................ 132
Quiz: API et interfaces de ligne de commande Kubernetes et OpenShift ........................ 142
Résumé ............................................................................................................... 146
3. Exécuter des applications en tant que conteneurs et pods 147

Créer des conteneurs Linux et des pods Kubernetes ................................................. 148
Exercice guidé: Créer des conteneurs Linux et des pods Kubernetes ............................ 160
Rechercher et inspecter des images de conteneur .................................................... 169
Exercice guidé: Rechercher et inspecter des images de conteneur ................................ 183
Résoudre les problèmes liés aux conteneurs et aux pods ............................................ 195
Exercice guidé: Résoudre les problèmes liés aux conteneurs et aux pods ...................... 204
Open Lab: Exécuter des applications en tant que conteneurs et pods ............................ 211
Quiz: Exécuter des applications en tant que conteneurs et pods ................................... 219
Résumé .............................................................................................................. 223
4. Déployer des applications gérées et en réseau sur Kubernetes 225

Déploiement d’applications à partir d’images et de modèles ....................................... 226
Exercice guidé: Déploiement d’applications à partir d’images et de modèles .................. 239
Gestion des applications de longue durée et de courte durée à l’aide de l’API
Kubernetes Workload ............................................................................................ 245
Exercice guidé: Gestion des applications de longue durée et de courte durée à l’aide de
l’API Kubernetes Workload ..................................................................................... 249
Réseaux de pods et de services Kubernetes ............................................................ 254
Exercice guidé: Réseaux de pods et de services Kubernetes ....................................... 264
Mise à l’échelle et exposition d’applications pour un accès externe ............................... 272
Exercice guidé: Mise à l’échelle et exposition d’applications pour un accès externe .......... 279
Open Lab: Déployer des applications gérées et en réseau sur Kubernetes ..................... 286
Résumé .............................................................................................................. 295
DO180-OCP4.14-fr-2-20240530 vii
5. Gestion du stockage pour les données et la configuration de l’application 297
Externalisation de la configuration des applications ................................................... 298
Exercice guidé: Externalisation de la configuration des applications ............................... 310
Approvisionnement de volumes de données persistants ............................................. 317
Exercice guidé: Approvisionnement de volumes de données persistants ....................... 327
Sélection d’une classe de stockage pour une application ........................................... 334
Exercice guidé: Sélection d’une classe de stockage pour une application ...................... 340
Gestion du stockage non partagé avec des ensembles avec état ................................ 348
Exercice guidé: Gestion du stockage non partagé avec des ensembles avec état ............ 355
Open Lab: Gestion du stockage pour les données et la configuration de l’application ...... 363
Résumé .............................................................................................................. 377
6. Configuration des applications sur le plan de la fiabilité 379
Haute disponibilité des applications avec Kubernetes ................................................ 380
Exercice guidé: Haute disponibilité des applications avec Kubernetes ........................... 382
Sondes d’intégrité des applications ........................................................................ 388
Exercice guidé: Sondes d’intégrité des applications ................................................... 393
Réservation de capacité de calcul pour les applications ............................................. 399
Exercice guidé: Réservation de capacité de calcul pour les applications ........................ 403
Limitation de la capacité de calcul pour les applications ............................................ 408
Exercice guidé: Limitation de la capacité de calcul pour les applications ......................... 415
Mise à l’échelle automatique des applications ........................................................... 419
Exercice guidé: Mise à l’échelle automatique des applications ...................................... 422
Open Lab: Configuration des applications sur le plan de la fiabilité ............................... 429
Quiz: Configuration des applications sur le plan de la fiabilité ....................................... 438
Résumé .............................................................................................................. 440
7. Gestion des mises à jour des applications 441
Identité et balises d’images de conteneur ................................................................ 442
Exercice guidé: Identité et balises d’images de conteneur .......................................... 449
Mise à jour des paramètres et de l’image de l’application ........................................... 459
Exercice guidé: Mise à jour des paramètres et de l’image de l’application ...................... 468
Déploiements reproductibles avec des flux d’images OpenShift ................................. 475
Exercice guidé: Déploiements reproductibles avec des flux d’images OpenShift ............ 484
Mises à jour automatiques des images avec les déclencheurs de changement d’image
OpenShift ............................................................................................................ 488
Exercice guidé: Mises à jour automatiques des images avec les déclencheurs de
changement d’image OpenShift ............................................................................. 493
Open Lab: Gestion des mises à jour des applications ................................................. 498
Résumé .............................................................................................................. 503
8. Révision complète 505
Révision complète ............................................................................................... 506
Open Lab: Déploiement d’applications Web ............................................................. 509
Open Lab: Résolution des problèmes et mise à l’échelle des applications ....................... 518
viii DO180-OCP4.14-fr-2-20240530
Conventions de la documentation
Cette section décrit les différentes conventions et pratiques utilisées dans

tous les cours de la formation Red Hat.
Avertissements
Les cours de la formation Red Hat font appel aux avertissements suivants :
Références
Consignes indiquant où trouver de la documentation externe se
rapportant à un sujet.
Note
Une « remarque » est un conseil, un raccourci ou une approche
alternative pour la tâche en cours. Ignorer une remarque ne devrait pas
entraîner de conséquences négatives, mais vous pourriez passer à côté
d’une astuce qui vous faciliterait la vie.
Important
Les sections importantes détaillent des éléments qui pourraient
aisément être négligés : des changements de configuration qui ne
s'appliquent qu’à la session en cours ou des services qui doivent
être redémarrés pour qu’une mise à jour soit appliquée. Ignorer ces
avertissements ne vous fera perdre aucune donnée, mais cela pourrait
être source de frustration et d’irritation.
Mise en garde
N’ignorez pas les avertissements. Ignorer ces avertissements entraînera
très probablement une perte de données.
DO180-OCP4.14-fr-2-20240530 ix
Langage inclusif
Red Hat Training examine actuellement son langage dans divers domaines pour aider à supprimer
tout terme potentiellement offensant. Il s’agit d’un processus continu qui doit être appliqué aux
produits et services couverts dans les cours de la formation Red Hat. Red Hat vous remercie pour
votre patience tout au long du processus.
x DO180-OCP4.14-fr-2-20240530
Introduction
Red Hat OpenShift Administration I: Operating a

Production Cluster
Ce cours prépare les administrateurs de clusters OpenShift à effectuer la
gestion quotidienne des charges de travail Kubernetes et à collaborer avec
les développeurs, les ingénieurs DevOps, les administrateurs système et les
SRE afin de garantir la disponibilité des charges de travail des applications.
Le cours DO180 se concentre sur la gestion des applications standard des
utilisateurs finaux. Ces applications sont accessibles à partir d’une interface
utilisateur Web ou mobile et représentent la majorité des charges de travail
natives cloud et en conteneur. La gestion des applications comprend
également le déploiement de leurs dépendances, telles que les bases de
données, la messagerie et les systèmes d’authentification. Ce cours est basé
sur Red Hat® OpenShift® Container Platform 4.14.
Objectifs du cours
• Gestion de clusters OpenShift à partir de l’interface de ligne de

commande et de la console Web.
• Déploiement d’applications sur OpenShift à partir d’images de conteneur,
de modèles et de manifestes Kubernetes.
• Résolution des problèmes de connectivité réseau entre les applications à
l’intérieur et à l’extérieur d’un cluster OpenShift.
• Connexion des charges de travail Kubernetes au stockage pour les
données d’application.
• Configuration des charges de travail Kubernetes pour une haute
disponibilité et une fiabilité élevée.
• Gestion des mises à jour des images de conteneur, des paramètres et des
manifestes Kubernetes d’une application.
Public
• Administrateurs système intéressés par la gestion continue des clusters

OpenShift et des applications en conteneur.
• Ingénieurs en fiabilité des sites (SRE) intéressés par la maintenance
continue et la résolution des problèmes des applications en conteneur
dans Kubernetes.
• Architectes système et logiciels désireux de comprendre les fonctions et
les fonctionnalités d’un cluster OpenShift.
Conditions préalables
• Conteneurs, Kubernetes et Red Hat OpenShift Technical Overview

(DO080) sur https://www.redhat.com/en/services/training/do080-
DO180-OCP4.14-fr-2-20240530 xi
Introduction
deploying-containerized-applications-technical-overview ou
connaissance équivalente des conteneurs Linux.
• Pour ce cours, il n'est pas nécessaire de posséder une connaissance
approfondie de Linux. Des compétences de base en matière
d’exploitation d’un shell Bash sont suffisantes.
xii DO180-OCP4.14-fr-2-20240530
Introduction
Organisation de l’environnement de la
classe
Dans ce cours, le système informatique principal qui est utilisé pour les travaux pratiques est
workstation. Les systèmes appelés bastion et classroom doivent toujours être en cours
d’exécution pour une utilisation correcte de l’environnement d’atelier.
Ces trois systèmes se trouvent dans le domaine DNS lab.example.com.
Une installation d’UPI sur système nu Red Hat OpenShift Container Platform (RHOCP) 4.14 à
nœud unique (SNO) est utilisée dans ce cours. Les systèmes d’infrastructure du cluster RHOCP
se trouvent dans le domaine DNS ocp4.example.com.
Tous les systèmes informatiques des stagiaires possèdent un compte utilisateur standard,
student, protégé par le mot de passe student. Le mot de passe root est redhat sur tous les
systèmes des stagiaires.
Figure 0.1: Environnement de formation :
Machines de la salle de classe
Nom de la machine Adresses IP Rôle
bastion.lab.example.com 172.25.250.254 Routeur reliant les machines

virtuelles aux serveurs
centraux
classroom.lab.example.com 172.25.252.254 Serveur qui héberge les

supports de formation requis
idm.ocp4.example.com 192.168.50.40 Serveur de gestion des

identités pour la prise en
charge de l’authentification
et de l’autorisation
master01.ocp4.example.com 192.168.50.10 Un cluster RHOCP à nœud

unique (SNO)
DO180-OCP4.14-fr-2-20240530 xiii
Introduction
Nom de la machine Adresses IP Rôle
registry.ocp4.example.com 192.168.50.50 Serveur de registre pour

fournir un registre privé
et des services GitLab au
cluster
utility.lab.example.com 192.168.50.254 Serveur qui fournit les

services de prise en charge
dont le cluster RHOCP a
besoin, y compris DHCP, NFS
et le routage vers le réseau
de clusters
workstation.lab.example.com 172.25.250.9 Poste de travail graphique

mis à la disposition des
stagiaires
La fonction principale de bastion est de servir de routeur entre le réseau sur lequel sont
connectées les machines des stagiaires et le réseau de la salle de classe. Si le système bastion
est arrêté, alors les autres machines des stagiaires ne fonctionnent pas correctement, ou peuvent
même se bloquer lors du lancement.
Le système utility agit comme un routeur entre le réseau qui relie les machines de cluster
RHOCP et le réseau des stagiaires. Si utility est arrêté, le cluster RHOCP ne fonctionnera pas
correctement ou risque de se bloquer lors du lancement.
Plusieurs systèmes dans la salle de classe proposent des services d’assistance. Le serveur
classroom héberge les logiciels et les supports d’atelier utilisés pour les activités pratiques.
Le serveur registry est un registre de conteneurs Red Hat Quay privé qui héberge les images
de conteneur pour les activités pratiques. Les informations sur l’utilisation de ces serveurs sont
fournies dans les instructions de ces activités.
Le système master01 fait office de plan de contrôle et de nœud de calcul pour le cluster RHOCP.
Le cluster utilise le système registry comme son propre serveur GitLab et registre d’images
de conteneur privé. Le système idm fournit des services LDAP au cluster RHOCP pour la prise en
charge de l’authentification et de l’autorisation.
Les stagiaires utilisent la machine workstation pour accéder à un cluster RHOCP dédié, pour
lequel ils disposent de privilèges d’administrateur de cluster.
Méthodes d’accès RHOCP
Méthode Point d’accès

d’accès
Console Web https://console-openshift-console.apps.ocp4.example.com
API https://api.ocp4.example.com:6443
Le cluster RHOCP a un compte d’utilisateur standard, developer, dont le mot de passe est
developer. Le compte administratif, admin, a le mot de passe redhatocp.
xiv DO180-OCP4.14-fr-2-20240530
Introduction
Registre de la salle de classe

Le cours DO180 utilise un registre d’images de conteneur Red Hat Quay privé, accessible
uniquement dans l’environnement de formation. Ce registre héberge les images de conteneur
que les stagiaires utilisent dans le cadre des activités pratiques. Grâce à un registre d’images
de conteneur privé, l’environnement de formation est autonome et ne nécessite pas d’accès à
Internet.
Le serveur registry fournit le registre d’images de conteneur https://

registry.ocp4.example.com:8443/ à l’environnement de formation. Le registre est
configuré avec un compte utilisateur, developer, dont le mot de passe est developer.
Le tableau ci-dessous répertorie les référentiels d’images de conteneur utilisés dans ce cours et
leurs référentiels publics.
Référentiels d’images de conteneur de la salle de classe et sources publiques
Référentiels de registres de la salle de Référentiel source public

classe
redhattraining/docker-nginx docker.io/library/nginx
quay.io/redhattraining/docker-
nginx
redhattraining/bitnami-mysql docker.io/bitnami/mysql
quay.io/redhattraining/bitnami-
mysql
redhattraining/do180-dbinit quay.io/redhattraining/do180-
dbinit
redhattraining/do180-httpd-app quay.io/redhattraining/do180-
httpd-app
redhattraining/do180-roster quay.io/redhattraining/do180-
roster
redhattraining/famous-quotes quay.io/redhattraining/famous-
quotes
redhattraining/hello-world-nginx quay.io/redhattraining/hello-
world-nginx
redhattraining/httpd-noimage quay.io/redhattraining/httpd-
noimage
redhattraining/long-load quay.io/redhattraining/long-load
redhattraining/loadtest quay.io/redhattraining/loadtest
redhattraining/mysql-app quay.io/redhattraining/mysql-app
redhattraining/php-ssl quay.io/redhattraining/php-ssl
redhattraining/php-webapp quay.io/redhattraining/php-webapp
DO180-OCP4.14-fr-2-20240530 xv
Introduction
Référentiels de registres de la salle de Référentiel source public

classe
redhattraining/php-webapp-mysql quay.io/redhattraining/php-webapp-
mysql
redhattraining/versioned-hello quay.io/redhattraining/versioned-
hello
redhattraining/webphp quay.io/redhattraining/webphp
rhel8/mysql-80 registry.redhat.io/rhel8/mysql-80
rhel9/mysql-80 registry.redhat.io/rhel9/mysql-80
ubi8/httpd-24 registry.access.redhat.com/ubi8/
httpd-24
ubi8/ubi registry.access.redhat.com/ubi8/
ubi
ubi9/ubi registry.access.redhat.com/ubi9/
ubi
Contrôle de vos systèmes

Des ordinateurs distants vous sont attribués au sein d’une salle de classe Red Hat Online Learning
(ROLE). Vous avez accès à des cours d’autoformation par le biais d’une application web hébergée
à l’adresse suivante : rol.redhat.com [http://rol.redhat.com]. Vous devez vous connecter à ce site à
l’aide de vos informations d’identification du Portail Client Red Hat.
Contrôle des machines virtuelles

Les machines virtuelles de votre environnement de formation sont contrôlées au moyen de
commandes d’interface de page web. L’état de chaque machine virtuelle est affiché sur l’onglet
Lab Environment.
xvi DO180-OCP4.14-fr-2-20240530
Introduction
Figure 0.2: Exemple de page de gestion Lab Environment d’un cours
États de la machine
État de la machine Description

virtuelle
building La machine virtuelle est en cours de création.
active La machine virtuelle est en cours d’exécution et disponible. Si elle

vient de démarrer, il se peut qu’elle soit encore en train de démarrer
des services.
stopped La machine virtuelle est arrêtée. Au démarrage, la machine virtuelle

démarre dans le même état qu'avant l'arrêt. L’état du disque est
préservé.
Actions de la salle de classe
Bouton ou action Description
CREATE Permet de créer la salle de classe ROLE. Crée et démarre toutes les
machines virtuelles nécessaires pour cette salle de classe.
CREATING Les machines virtuelles de la salle de classe ROLE sont en cours de

création. Cette procédure peut prendre plusieurs minutes.
DELETE Permet de supprimer la salle de classe ROLE. Détruit toutes les

machines virtuelles dans la salle de classe. Tout le travail enregistré
sur les disques de ces systèmes est perdu.
START Permet de démarrer toutes les machines virtuelles de la salle de

classe.
STARTING Toutes les machines virtuelles de la salle de classe démarrent.
STOP Permet d’arrêter toutes les machines virtuelles de la salle de classe.
DO180-OCP4.14-fr-2-20240530 xvii
Introduction
Actions de la machine
Bouton ou action Description
OPEN CONSOLE Permet de se connecter à la console système de la machine virtuelle

dans un nouvel onglet du navigateur. Vous pouvez vous connecter
directement à la machine et exécuter des commandes, si nécessaire.
Généralement, vous vous connectez uniquement à la machine
virtuelle workstation, et à partir de là, vous utilisez ssh pour vous
connecter aux autres machines virtuelles.
ACTION > Start Démarrer (mettre sous tension) la machine virtuelle.
ACTION > Arrêtez correctement la machine virtuelle, en préservant le contenu

Shutdown du disque.
ACTION > Power Arrêter de force la machine virtuelle, tout en préservant le contenu du
Off disque. Cela équivaut à couper l’alimentation d’une machine physique.
ACTION > Reset Force l’arrêt de la machine virtuelle et réinitialise le stockage associé
à son état initial. Tout le travail enregistré sur les disques de ce
système est perdu.
Au début d’un exercice, si vous êtes invité à réinitialiser un seul nœud de machine virtuelle, cliquez
sur ACTION > Reset pour la machine virtuelle concernée.
Au début d’un exercice, si vous êtes invité à réinitialiser l’ensemble des machines virtuelles, cliquez
sur ACTION > Reset sur chaque machine virtuelle figurant dans la liste.
Si vous souhaitez que l’environnement de formation retourne à son état d’origine du début du
cours, cliquez sur DELETE pour supprimer l’ensemble de l’environnement de formation. Une fois
l’atelier supprimé, cliquez sur CREATE pour déployer un nouvel ensemble de systèmes de salle de
classe.
Mise en garde
L’opération DELETE ne peut pas être annulée. Tous les travaux que vous aurez
terminés dans l’environnement de formation seront perdus.
Les compteurs d’arrêt automatique et de destruction

automatique
L’inscription à la formation en ligne Red Hat vous alloue un temps de traitement fixe. Pour vous
aider à préserver le temps qui vous est alloué, la salle de classe ROLE utilise des compteurs qui
arrêtent ou suppriment l’environnement de formation à l’expiration du compteur approprié.
Pour régler ces compteurs, localisez les deux boutons + en bas de la page de gestion du cours.
Cliquez sur le bouton d’arrêt automatique + pour ajouter une nouvelle heure au compteur d’arrêt
automatique. Cliquez sur le bouton de destruction automatique + pour ajouter un nouveau jour au
compteur de destruction automatique. Le maximum autorisé pour le bouton d’arrêt automatique
est 11 heures, et 14 jours pour la destruction automatique. Veillez à ce que les compteurs restent
définis pendant que vous travaillez, afin d’éviter que votre environnement ne s’arrête de manière
inattendue. Veillez à ne pas régler les compteurs de façon inutilement élevée, ce qui pourrait
gaspiller le temps d’abonnement qui vous a été alloué.
xviii DO180-OCP4.14-fr-2-20240530
Introduction
Exécution des exercices pratiques

Vous verrez peut-être les types d’activités pratiques suivants dans ce cours :
• Un exercice guidé est un exercice pratique qui suit une section de présentation. Il vous guide à
travers une procédure à exécuter, étape par étape.
• Un quiz est généralement utilisé lors de la vérification de l’apprentissage axé sur les
connaissances ou si, pour une quelconque raison, une activité pratique n’est pas appropriée.
• Un atelier de fin de chapitre est une activité pratique notée dont le but est de vous aider à
vérifier les connaissances que vous avez acquises. Vous effectuez un ensemble d’étapes de haut
niveau en fonction des exercices guidés de ce chapitre. Cependant, les étapes ne décrivent pas
chacune des commandes. Une solution est fournie avec une procédure étape par étape.
• Un atelier de révision complète est utilisé à la fin du cours. Il s’agit également d’une activité
pratique notée qui peut porter sur l’ensemble du contenu du cours. Vous allez examiner une
spécification qui détaille les procédures à accomplir dans le cadre de l’activité, sans connaître
les étapes spécifiques pour y parvenir. Ici encore, vous recevez une solution qui fournit une
procédure étape par étape qui répond à la spécification.
Pour préparer votre environnement d’atelier au début de chaque activité pratique, exécutez la
commande lab start avec un nom d’activité issu des instructions de l’activité. De même, à la fin
de chaque activité pratique, exécutez la commande lab finish avec ce même nom d’activité
pour effectuer un nettoyage après l’activité. Chaque activité pratique porte un nom unique au sein
d’un cours.
La syntaxe d’exécution d’un script d’exercice est la suivante :
[student@workstation ~]$ lab action exercise
L’action est à choisir entre start, grade ou finish. Tous les exercices prennent en charge
start et finish. Seuls les ateliers de fin de chapitre et de révision complète prennent en charge
grade.
start
L’action start vérifie les ressources requises pour commencer un exercice. Il peut s’agir
notamment de configurer des paramètres, de créer des ressources, de valider les services
prérequis et de vérifier les résultats nécessaires des exercices précédents. Vous pouvez
effectuer un exercice à tout moment, même sans avoir réalisé les exercices précédents.
grade
Pour les activités notées, l’action grade indique à la commande lab d’évaluer votre travail.
Elle affiche également une liste de critères de notation, avec un statut PASS ou FAIL pour
chacun d’eux. Pour obtenir le statut PASS pour tous les critères, corrigez les erreurs et
exécutez à nouveau l’action grade.
finish
L’action finish réinitialise les ressources configurées pendant l’exercice. Vous pouvez
effectuer un exercice autant de fois que vous le souhaitez.
DO180-OCP4.14-fr-2-20240530 xix
Introduction
La commande lab prend en charge la saisie semi-automatique via la touche de tabulation. Par
exemple, pour lister tous les exercices que vous pouvez commencer, saisissez lab start, puis
appuyez deux fois sur la touche Tab.
Affichage du guide du stagiaire

Les commandes et les blocs de code du guide du stagiaire sont optimisés lorsque votre
visionneuse par défaut affiche au moins 80 caractères. Si vous réglez votre visionneuse de sorte
qu’elle affiche moins de 80 caractères, les commandes et les blocs de code peuvent être renvoyés
à des emplacements singuliers.
Pour bénéficier d'une expérience d'affichage optimale, réglez votre visionneuse de manière à
éviter le retour à la ligne. Si vous utilisez un navigateur Web, vous pouvez ajuster le pourcentage de
zoom. Pour une visionneuse EPUB, vous pouvez ajuster l’orientation et la taille de la police.
================================================================================
Considérations relatives au répertoire de l’atelier

Le cours DO180 utilise un script Python lab qui configure la structure de répertoire pour chaque
exercice guidé et activité de l’atelier. Le répertoire workspace de ce cours est /home/student/
DO180.
Le script lab copie les fichiers nécessaires pour chaque activité du cours dans le répertoire de
l’espace de travail.
Par exemple, la commande lab start updates-rollout effectue les tâches suivantes :
• Elle crée un répertoire updates-rollout dans l’espace de travail : espace de travail /home/
student/DO180/labs/updates-rollout.
• Elle copie les fichiers de l’activité dans le répertoire /home/student/DO180/labs/

updates-rollout.
Résolution des problèmes liés aux scripts de travaux

pratiques
Si une erreur se produit lors de l’exécution de la commande lab, vous pouvez consulter les fichiers
suivants :
• /tmp/log/labs : ce répertoire contient des fichiers journaux. Le script lab crée un fichier
journal unique pour chaque activité. Par exemple, le fichier journal de la commande lab start
updates-rollout est /tmp/log/labs/updates-rollout.
• /home/student/.grading/config.yaml : ce fichier contient la configuration spécifique au

cours. Ne modifiez pas ce fichier.
Les commandes lab start vérifient généralement si le cluster Red Hat OpenShift Container
Platform (RHOCP) est prêt et accessible. Si vous exécutez la commande lab start juste après
avoir créé l’environnement de formation, des erreurs peuvent être générées lorsque la commande
vérifie l’API du cluster ou les informations d’identification. Ces erreurs se produisent, car il peut
s’écouler jusqu’à 15 minutes avant que le cluster RHOCP ne soit disponible. Une solution pratique
consiste à exécuter la commande lab finish pour nettoyer le scénario, à attendre quelques
minutes, puis à exécuter à nouveau la commande lab start.
xx DO180-OCP4.14-fr-2-20240530
Introduction
Important
Dans le cadre de ce cours, les scripts lab start créent normalement un projet
RHOCP spécifique pour chaque exercice. Les scripts lab finish suppriment le
projet RHOCP spécifique à l’exercice.
Si vous effectuez à nouveau un exercice, vous devrez peut-être attendre avant de

réexécuter la commande lab start. Le processus de suppression du projet peut
prendre jusqu’à 10 minutes pour être pleinement efficace.
DO180-OCP4.14-fr-2-20240530 xxi
xxii DO180-OCP4.14-fr-2-20240530
chapitre 1
Présentation de Kubernetes et
d’OpenShift
Objectif Identifier les principaux services de cluster
Kubernetes et de plateforme OpenShift, et les
surveiller à l’aide de la console Web.
Résultats • Décrire les principales caractéristiques des

conteneurs et de Kubernetes.
• Décrire la relation entre OpenShift, Kubernetes
et d’autres projets Open Source, et lister les
principales fonctions des produits et éditions
de Red Hat OpenShift.
• Naviguer dans la console Web OpenShift pour
identifier les applications et les services de
cluster en cours d’exécution.
• Parcourir les panneaux Events, Compute et
Observe de la console Web OpenShift pour
évaluer l’état général d’un cluster.
Sections • Les conteneurs et Kubernetes (et quiz

correspondant)
• Composants et éditions de Red Hat
OpenShift (et quiz correspondant)
• Exploration de la console Web OpenShift (et
exercice guidé)
• Surveillance d’un cluster OpenShift (et exercice
guidé)
Atelier • Présentation de Kubernetes et d’OpenShift
DO180-OCP4.14-fr-2-20240530 1
chapitre 1 | Présentation de Kubernetes et d’OpenShift
Les conteneurs et Kubernetes
Résultats
• Décrire les principales caractéristiques des conteneurs et de Kubernetes.
Présentation des conteneurs et de Kubernetes

Red Hat OpenShift Container Platform (RHOCP) est une plateforme complète permettant
d’exécuter des applications dans des clusters de serveurs. OpenShift est basé sur des
technologies existantes telles que les conteneurs et Kubernetes. Les conteneurs permettent
d’empaqueter des applications et leurs dépendances qui peuvent être exécutées sur n’importe
quel système avec un environnement d’exécution de conteneur.
Kubernetes fournit de nombreuses fonctionnalités pour créer des clusters de serveurs qui
exécutent des applications en conteneur. Cependant, Kubernetes n’a pas l’intention de fournir une
solution complète, mais fournit plutôt des points d’extension afin que les administrateurs système
puissent compléter Kubernetes. OpenShift s’appuie sur les points d’extension de Kubernetes pour
fournir une plateforme complète.
Présentation des conteneurs

Un conteneur est un processus qui exécute une application indépendamment des autres
conteneurs sur l’hôte. Les conteneurs sont créés à partir d’une image de conteneur, qui inclut
toutes les dépendances d’exécution de l’application. Les conteneurs peuvent ensuite être
exécutés sur n’importe quel hôte, sans nécessiter l’installation de dépendances sur l’hôte et sans
conflits entre les dépendances des différents conteneurs.
Figure 1.1: Applications dans des conteneurs et sur le système d’exploitation hôte
Les conteneurs utilisent des fonctionnalités du noyau Linux, telles que les espaces de noms et les
groupes de contrôle (cGroups). Par exemple, les conteneurs utilisent des cGroups pour la gestion
de ressources, comme l’allocation de temps processeur et la mémoire système. Les espaces de
noms isolent les processus et les ressources d’un conteneur des autres conteneurs et du système
hôte.
2 DO180-OCP4.14-fr-2-20240530
L’OCI (Open Container Initiative) maintient des normes sur les conteneurs, les images de
conteneur et les environnements d’exécution de conteneur. Étant donné que la plupart des
implémentations de moteur de conteneur sont conçues pour se conformer aux spécifications OCI,
les applications qui sont empaquetées conformément à la spécification peuvent s’exécuter sur
n’importe quelle plateforme conforme.
Vue d’ensemble de Kubernetes

Kubernetes est une plateforme qui simplifie le déploiement, la gestion et la mise à l’échelle des
applications en conteneur.
Vous pouvez exécuter des conteneurs sur n’importe quel système Linux à l’aide d’outils tels que
Podman. Des travaux supplémentaires sont nécessaires pour créer des services conteneurisés qui,
par exemple, peuvent s’exécuter sur un cluster à des fins de redondance.
Kubernetes crée un cluster qui exécute des applications sur plusieurs nœuds. En cas de défaillance
d’un nœud, Kubernetes peut redémarrer une application sur un autre nœud.
Kubernetes utilise un modèle de configuration déclaratif. Les administrateurs Kubernetes

écrivent une définition des charges de travail à exécuter dans le cluster, et Kubernetes s’assure
que les charges de travail en cours d’exécution correspondent à la définition. Par exemple, un
administrateur définit plusieurs charges de travail. Chaque charge de travail définit la quantité de
mémoire requise. Kubernetes crée ensuite les conteneurs nécessaires dans différents nœuds, pour
répondre aux besoins en mémoire.
Kubernetes définit les charges de travail en termes de pods. Un pod est un ou plusieurs
conteneurs qui s’exécutent dans le même nœud de cluster. Les pods avec plusieurs conteneurs
sont utiles dans certaines situations, lorsque deux conteneurs doivent s’exécuter dans le même
nœud de cluster pour partager une ressource. Par exemple, une tâche est une charge de travail qui
exécute une tâche dans un pod jusqu’à ce qu’elle soit terminée.
Fonctions de Kubernetes
Kubernetes offre les fonctions suivantes en plus d’une infrastructure de conteneur :
Découverte de service et équilibrage de charge

La distribution d’applications sur plusieurs nœuds peut compliquer la communication entre les
applications.
Kubernetes configure automatiquement la mise en réseau et fournit un service DNS pour les
pods. Grâce à ces fonctionnalités, les pods peuvent communiquer avec les services d’autres
pods de manière transparente sur les nœuds en utilisant uniquement des noms d’hôte au lieu
d’adresses IP. Plusieurs pods peuvent soutenir un service pour les performances et la fiabilité.
Par exemple, Kubernetes peut répartir uniformément les requêtes entrantes vers un serveur
Web NGINX en tenant compte de la disponibilité des pods NGINX.
Mise à l’échelle horizontale

Kubernetes peut surveiller la charge sur un service et créer ou supprimer des pods
pour s’adapter à la charge. Avec certaines configurations, Kubernetes peut également
approvisionner des nœuds de manière dynamique pour s’adapter à la charge du cluster.
Autoréparation
Si les applications déclarent des procédures de vérification de l’état, Kubernetes
peut surveiller, redémarrer et replanifier les applications défaillantes ou indisponibles.
L’autoréparation protège les applications contre les défaillances internes (l’application s’arrête
de manière inattendue) ou externes (le nœud qui exécute l’application devient indisponible).
DO180-OCP4.14-fr-2-20240530 3
Déploiement automatisé
Kubernetes peut progressivement appliquer des mises à jour aux conteneurs de votre
application. En cas de problème lors du déploiement, Kubernetes peut revenir à la version
précédente du déploiement. Kubernetes achemine les demandes vers la version déployée de
l’application et supprime les pods de la version précédente une fois le déploiement terminé.
Secrets et gestion de la configuration

Vous pouvez gérer les paramètres de configuration et les secrets de vos applications sans
nécessiter l’apport de modification aux conteneurs. Les secrets d’application peuvent être
des noms d’utilisateur, des mots de passe et des points d’accès de service, ou tout autre
paramètre de configuration devant rester confidentiel.
Note
Kubernetes ne chiffre pas les secrets.
Opérateurs
Les opérateurs sont des applications Kubernetes empaquetées qui peuvent gérer les charges
de travail Kubernetes de manière déclarative. Par exemple, un opérateur peut définir une
ressource de serveur de base de données. Si l’utilisateur crée une ressource de base de
données, l’opérateur crée les charges de travail nécessaires pour déployer la base de données,
configurer la réplication et effectuer une sauvegarde automatique.
Concepts architecturaux de Kubernetes

Kubernetes utilise plusieurs serveurs (également appelés noeuds) pour garantir la résilience et
l’évolutivité des applications qu’il gère. Ces nœuds peuvent être des machines physiques ou
virtuelles. Il existe deux types de nœuds, chacun fournissant un aspect différent des opérations de
cluster.
Les nœuds du plan de contrôle assurent la coordination globale du cluster pour la planification des
charges de travail déployées. Ces nœuds gèrent également l’état de la configuration du cluster en
réponse aux événements et aux demandes du cluster.
Les nœuds du plan de calcul exécutent les charges de travail utilisateur.
Figure 1.2: Composants Kubernetes
4 DO180-OCP4.14-fr-2-20240530
Bien qu’un serveur puisse agir à la fois comme nœud de plan de contrôle et comme nœud de
calcul, les deux rôles sont généralement séparés pour une stabilité, une sécurité et une gérabilité
accrues. Les clusters Kubernetes peuvent aller des petits clusters à nœud unique aux grands
clusters comportant jusqu’à 5 000 nœuds.
L’API Kubernetes et le modèle de configuration

Kubernetes fournit un modèle permettant de définir les charges de travail à exécuter sur un
cluster.
Les administrateurs définissent les charges de travail en termes de ressources.
Tous les types de ressources fonctionnent de la même manière, avec une API uniforme. Des outils
tels que la commande kubectl peuvent gérer des ressources de tous types, même des types de
ressources personnalisés.
Kubernetes peut importer et exporter des ressources sous forme de fichiers texte. En travaillant
avec des définitions de ressources au format texte, les administrateurs peuvent décrire leurs
charges de travail au lieu d’effectuer la séquence d’opérations appropriée pour les créer. Cette
approche est appelée gestion déclarative des ressources.
Figure 1.3: Gestion déclarative des ressources
La gestion déclarative des ressources peut réduire le travail de création de charges de travail
et améliorer la maintenabilité. En outre, lorsqu’ils utilisent des fichiers texte pour décrire des
ressources, les administrateurs peuvent utiliser des outils génériques tels que des systèmes de
contrôle de version pour obtenir d’autres avantages, comme le suivi des modifications.
Pour prendre en charge la gestion déclarative des ressources, Kubernetes utilise des contrôleurs
qui suivent en permanence l’état du cluster et effectuent les étapes nécessaires pour maintenir
le cluster dans l’état prévu. Ce processus signifie que les modifications apportées aux ressources
nécessitent souvent un certain temps pour être efficaces. Cependant, Kubernetes peut appliquer
automatiquement des modifications complexes. Par exemple, si vous augmentez les besoins en
RAM d’une application qui ne peuvent pas être satisfaits sur le nœud actuel, Kubernetes peut
déplacer l’application vers un nœud disposant de suffisamment de RAM. Kubernetes redirige le
trafic vers la nouvelle instance uniquement lorsque le déplacement est terminé.
Kubernetes prend également en charge les espaces de noms. Les administrateurs peuvent créer
des espaces de noms, et la plupart des ressources doivent être créées à l’intérieur d’un espace
de noms. En plus d’aider à organiser de grandes quantités de ressources, les espaces de noms
DO180-OCP4.14-fr-2-20240530 5
fournissent les bases de fonctionnalités telles que l’accès aux ressources. Les administrateurs
peuvent définir des autorisations pour les espaces de noms, afin de permettre à des utilisateurs
spécifiques d’afficher ou de modifier des ressources.
Références
Containers
https://kubernetes.io/docs/concepts/containers/
(Conteneurs)
Kubernetes Concepts Overview
https://kubernetes.io/docs/concepts/overview/
(Vue d’ensemble des concepts de Kubernetes)
What Kubernetes Is Not
https://kubernetes.io/docs/concepts/overview/#what-kubernetes-is-not
(Ce que Kubernetes n’est pas)
Considerations for Large Clusters
https://kubernetes.io/docs/setup/best-practices/cluster-large/
(Considérations relatives aux clusters de grande taille)
6 DO180-OCP4.14-fr-2-20240530
Quiz

Reliez les éléments suivants aux éléments correspondants dans le tableau.
Configuration d’applications en externe à partir de leurs images de conteneur
Configuration réseau automatique pour une communication de cluster transparente
Format d’empaquetage d’application compatible avec les environnements

d’exécution de conteneur
Gestion des instances de différentes versions d’une application
Modification automatique du nombre de répliques d’une application pour répondre

au chargement
Rapprochement d’une description de l’état prévu d’un cluster
Redémarrage automatique des applications défaillantes ou indisponibles
Concept Description
Découverte de service et
équilibrage de charge
Mise à l’échelle
horizontale
Autoréparation
Déploiement automatisé
Secrets et gestion de la
configuration
Gestion déclarative des

ressources
Images de conteneur
DO180-OCP4.14-fr-2-20240530 7
Solution

Concept Description
Découverte de service et Configuration réseau automatique pour une

équilibrage de charge communication de cluster transparente
Mise à l’échelle Modification automatique du nombre de répliques d’une

horizontale application pour répondre au chargement
Autoréparation Redémarrage automatique des applications défaillantes

ou indisponibles
Déploiement automatisé Gestion des instances de différentes versions d’une

application
Secrets et gestion de la Configuration d’applications en externe à partir de leurs

configuration images de conteneur
Gestion déclarative des Rapprochement d’une description de l’état prévu d’un

ressources cluster
Images de conteneur Format d’empaquetage d’application compatible avec les

environnements d’exécution de conteneur
8 DO180-OCP4.14-fr-2-20240530
Composants et éditions de Red Hat

OpenShift
Résultats
• Décrire la relation entre OpenShift, Kubernetes et d’autres projets Open Source, et lister les
principales fonctions des produits et éditions de Red Hat OpenShift.
Présentation de Red Hat OpenShift

Kubernetes fournit de nombreuses fonctionnalités pour exécuter des charges de travail de
conteneur sur des clusters. Cependant, pour certaines fonctionnalités, Kubernetes ne fournit que
les blocs de construction pour les implémenter, car différents environnements peuvent nécessiter
des solutions différentes. Les administrateurs Kubernetes peuvent sélectionner une solution
existante ou mettre en œuvre leur propre solution pour répondre à leurs besoins spécifiques.
OpenShift utilise l’extensibilité de Kubernetes pour créer une solution complète en ajoutant les
fonctionnalités suivantes à un cluster Kubernetes :
Workflow de développement intégré

Lorsque vous exécutez des applications sur Kubernetes, vous devez créer et stocker des
images de conteneur pour les applications. OpenShift intègre un registre de conteneurs, des
pipelines CI/CD et S2I , un outil permettant de construire des artefacts à partir de référentiels
sources en images de conteneur.
Observabilité
Pour atteindre la fiabilité, les performances et la disponibilité attendues des applications, les
administrateurs de cluster peuvent avoir besoin d’outils supplémentaires pour prévenir et
résoudre les problèmes. OpenShift inclut des services de surveillance et de journalisation pour
vos applications et le cluster.
Gestion des serveurs

Kubernetes nécessite l’exécution d’un système d’exploitation qui doit être installé, configuré
et géré.
OpenShift fournit des procédures d’installation et de mise à jour pour de nombreux scénarios.
En outre, les hôtes d’un cluster RHOCP utilisent Red Hat Enterprise Linux CoreOS
(RHEL CoreOS) comme système d’exploitation sous-jacent. RHEL CoreOS est un système
d’exploitation immuable, optimisé pour l’exécution d’applications en conteneur. RHEL CoreOS
utilise le même noyau et les mêmes paquetages que Red Hat Enterprise Linux. OpenShift
fournit également des fonctionnalités pour gérer RHEL CoreOS selon le modèle de
configuration Kubernetes.
OpenShift apporte également des outils unifiés et une console Web graphique pour gérer toutes
les différentes fonctionnalités, ainsi que des améliorations supplémentaires telles que des mesures
de sécurité améliorées.
Ce diagramme présente un grand nombre des projets qui fournissent les différentes fonctions au
sein de chaque cluster OpenShift :
DO180-OCP4.14-fr-2-20240530 9
Figure 1.4: Projets Open Source dans une version OpenShift
Étant donné que les fonctionnalités OpenShift reposent sur l’extensibilité de Kubernetes, les
administrateurs peuvent souvent exploiter ces fonctionnalités en utilisant leurs connaissances
Kubernetes existantes. Outre leurs connaissances sur Kubernetes, les administrateurs OpenShift
peuvent utiliser la plupart des produits existants conçus pour Kubernetes.
Éditions de Red Hat OpenShift

Lors de l’exploration initiale d’OpenShift, l’utilisation de Red Hat OpenShift Local constitue
une méthode pratique qui déploie un cluster sur un ordinateur local à des fins de test et
d’exploration. Red Hat propose également une solution Developer Sandbox dans laquelle vous
bénéficiez de 30 jours d’accès gratuit à un cluster OpenShift partagé. Ces options permettent
d’accéder à un cluster, et prennent en charge les tests et l’exploration lorsque vous envisagez
d’adopter OpenShift. Cependant, il ne s’agit pas d’environnements adaptés aux déploiements de
production.
Lorsque vous êtes prêt à adopter Red Hat OpenShift pour des charges de travail de production,
diverses éditions sont disponibles pour répondre à toutes les exigences de l’entreprise en matière
de déploiement de clusters.
Figure 1.5: Éditions de produits
Les partenaires de cloud public, comme Amazon Web Services, Microsoft Azure, IBM Cloud et
Google Cloud, offrent tous un accès rapide à un déploiement Red Hat OpenShift à la demande.
Ces déploiements gérés permettent un accès rapide à un cluster sur une infrastructure fiable à
partir d’un fournisseur de cloud Red Hat approuvé.
10 DO180-OCP4.14-fr-2-20240530
Vous pouvez également déployer un cluster Red Hat OpenShift en utilisant les programmes
d’installation disponibles sur une infrastructure physique ou virtuelle, sur site ou dans un cloud
public. Ces offres autogérées sont disponibles sous plusieurs formes.
Le choix des méthodes de déploiement dépend de nombreux facteurs. Lorsque vous utilisez les
services gérés, davantage de responsabilités sont déléguées à Red Hat et au fournisseur de cloud.
Étant donné que le processus d’installation s’intègre au fournisseur de cloud, le service géré crée
et gère toutes les ressources cloud nécessaires.
Lorsque vous utilisez les programmes d’installation, vous pouvez toujours déléguer la gestion
du matériel à un fournisseur de cloud ou utiliser le vôtre. Cependant, vous gérez le reste de la
solution. Avec les éditions autogérées, vous bénéficiez d’un contrôle et d’une flexibilité accrus,
mais vous assumez également de plus grandes responsabilités sur le service.
Par exemple, avec les services gérés, les équipes d’ingénierie de fiabilité des sites Red Hat
mettent à jour les clusters et résolvent les problèmes de mise à jour (même si vous participez
toujours à la planification des mises à jour). Sur les éditions autogérées, vous mettez à jour les
clusters et résolvez les problèmes de mise à jour. En revanche, sur les éditions autogérées, vous
disposez d’un contrôle total sur des aspects tels que l’authentification, lorsque les éditions gérées
peuvent restreindre certaines options.
Chaque édition gérée documente les responsabilités des clients, de Red Hat et du fournisseur de
cloud.
En outre, pour vous aider à gérer des clusters, Red Hat Insights Advisor est disponible sur la
console Red Hat Hybrid Cloud. Insights Advisor aide les administrateurs à identifier et à résoudre
les problèmes de cluster en analysant les données fournies par Insights Operator. Les données
de l’opérateur sont téléchargées vers la console Red Hat Hybrid Cloud, où vous examinez plus en
détail les recommandations et leur impact sur le cluster.
Le contenu de ce cours s’applique à la fois aux services gérés et aux éditions autogérées.
Red Hat OpenShift Kubernetes Engine inclut la dernière version de la plate-forme Kubernetes
avec le renforcement supplémentaire de la sécurité et la stabilité d’entreprise que Red Hat est
célèbre pour. Ce déploiement s’exécute sur le système d’exploitation de conteneur immuable
Red Hat Enterprise Linux CoreOS, en utilisant Red Hat OpenShift Virtualization pour la gestion
des machines virtuelles, et fournit une console d’administration pour faciliter le support
opérationnel.
Red Hat OpenShift Container Platform s’appuie sur les fonctions d’OpenShift Kubernetes Engine
pour améliorer la gestion, la sécurité et la stabilité des clusters, ainsi que le développement
d’applications pour les entreprises. Les fonctions supplémentaires de ce niveau incluent une
console de développement, ainsi que des informations de mesure, de gestion des journaux
et de gestion des coûts. Cette offre ajoute Red Hat OpenShift Serverless (Knative), Red Hat
OpenShift Service Mesh (Istio), Red Hat OpenShift Pipelines (Tekton) et Red Hat OpenShift
GitOps (Argo CD) au déploiement.
Red Hat OpenShift Platform Plus élargit davantage encore l’offre, de manière à proposer les
fonctionnalités les plus performantes et les plus robustes du marché. Cette offre comprend
Red Hat Advanced Cluster Management for Kubernetes, Red Hat Advanced Cluster Security for
Kubernetes et la plateforme de registre privé Red Hat Quay. Pour bénéficier de l’expérience la plus
complète dans le domaine des conteneurs, optez pour Red Hat OpenShift Platform Plus. Cette
solution regroupe tous les outils nécessaires sur le plan du développement et de l’administration
pour la gestion des plateformes d’applications en conteneur.
Toutes les éditions d’OpenShift utilisent le même code. La plupart des contenus de ce cours
s’appliquent à toutes les éditions d’OpenShift.
DO180-OCP4.14-fr-2-20240530 11
Références
What Kubernetes Is Not
https://kubernetes.io/docs/concepts/overview/#what-kubernetes-is-not
(Ce que Kubernetes n’est pas)
Pour plus d’informations, reportez-vous à la section Aperçu de la plateforme

OpenShift Container dans le chapitre Architecture de la plateforme de conteneurs
OpenShift de la documentation Architecture de Red Hat OpenShift Container
Platform 4.14, disponible à l’adresse
https://access.redhat.com/documentation/en-us/
openshift_container_platform/4.14/html-single/architecture/index#architecture-
platform-benefits_architecture
Pour plus d’informations, reportez-vous à la section About Red Hat OpenShift Local
dans le chapitre Introducing Red Hat OpenShift Local de la documentation Red Hat
Red Hat OpenShift Local 2.30 Getting Started Guide, disponible à l’adresse
https://access.redhat.com/documentation/en-us/red_hat_openshift_local/2.30/
html-single/getting_started_guide/index#about_gsg
Pour plus d’informations, reportez-vous à la section Plateformes prises en charge

pour les clusters OpenShift Container Platform dans le chapitre Installation et
mise à jour de la documentation Architecture de Red Hat OpenShift Container
openshift_container_platform/4.14/html-single/architecture/index#supported-
platforms-for-openshift-clusters_architecture-installation
Services cloud Red Hat OpenShift

https://www.redhat.com/en/technologies/cloud-computing/openshift/openshift-
cloud-services
Vue d’ensemble des responsabilités du service Red Hat OpenShift sur AWS
https://docs.aws.amazon.com/ROSA/latest/userguide/rosa-responsibilities.html
Red Hat OpenShift Kubernetes Engine

https://www.redhat.com/en/technologies/cloud-computing/openshift/
kubernetes-engine
Red Hat OpenShift Platform Plus

https://www.redhat.com/en/technologies/cloud-computing/openshift/platform-
plus
12 DO180-OCP4.14-fr-2-20240530
Quiz

OpenShift
Des offres OpenShift qui vous offrent davantage de contrôle, de flexibilité et de

responsabilités
Offres OpenShift dans lesquelles Red Hat et les fournisseurs de cloud assument des
responsabilités
Un système d’exploitation immuable, optimisé pour l’exécution d’applications en

conteneur
Un système pour déployer OpenShift sur un ordinateur local à des fins de test et
d’exploration
Une offre étendue qui inclut un registre de conteneurs
Une plateforme d’applications basée sur des conteneurs qui ne fournit pas de
fonctionnalités telles que la création d’applications
Une plateforme d’applications complète qui s’appuie sur l’extensibilité de

Kubernetes
DO180-OCP4.14-fr-2-20240530 13
Concept Description
Kubernetes
Red Hat
OpenShift Container Platform
Red Hat OpenShift

Platform Plus
Red Hat OpenShift Local
Services gérés
OpenShift
Offres OpenShift
autogérées
Red Hat Enterprise Linux

CoreOS
14 DO180-OCP4.14-fr-2-20240530
Solution

OpenShift
Concept Description
Kubernetes Une plateforme d’applications basée sur des conteneurs

qui ne fournit pas de fonctionnalités telles que la création
d’applications
Red Hat Une plateforme d’applications complète qui s’appuie sur

OpenShift Container Platform l’extensibilité de Kubernetes
Red Hat OpenShift Une offre étendue qui inclut un registre de conteneurs
Platform Plus
Red Hat OpenShift Local Un système pour déployer OpenShift sur un ordinateur
local à des fins de test et d’exploration
Services gérés Offres OpenShift dans lesquelles Red Hat et les

OpenShift fournisseurs de cloud assument des responsabilités
Offres OpenShift Des offres OpenShift qui vous offrent davantage de

autogérées contrôle, de flexibilité et de responsabilités
Red Hat Enterprise Linux Un système d’exploitation immuable, optimisé pour

CoreOS l’exécution d’applications en conteneur
DO180-OCP4.14-fr-2-20240530 15
Exploration de la console Web OpenShift
Résultats
• Naviguer dans la console Web OpenShift pour identifier les applications et les services de
Présentation de la console Web Red Hat OpenShift

La console Web Red Hat OpenShift offre une interface utilisateur graphique qui permet
d’effectuer de nombreuses tâches d’administration pour gérer un cluster. La console Web utilise
les API Kubernetes et les API d’extension OpenShift pour offrir un environnement graphique
efficace. Les menus, tâches et fonctions de la console Web sont toujours disponibles à l’aide de
l’interface de ligne de commande. La console Web facilite l’accès aux tâches complexes requises
dans le cadre de l’administration du cluster, ainsi que leur gestion.
Kubernetes fournit un tableau de bord Web qui n’est pas déployé par défaut dans un cluster.
Le tableau de bord Kubernetes fournit des autorisations de sécurité minimales et accepte
uniquement l’authentification basée sur des tokens. Ce tableau de bord nécessite également une
configuration de proxy qui ne permet d’accéder à la console Web qu’à partir du terminal système
qui crée le proxy. Contrairement aux limitations indiquées pour la console Web Kubernetes,
OpenShift inclut une console Web plus complète.
La console Web OpenShift n’est pas liée au tableau de bord Kubernetes, mais constitue un outil
distinct pour la gestion des clusters OpenShift. De plus, les opérateurs peuvent étendre les
fonctions de la console Web pour inclure davantage de menus, de vues et de formulaires afin de
faciliter l’administration du cluster.
Accès à la console Web OpenShift

Pour accéder à la console Web, vous pouvez utiliser n’importe quel navigateur Web moderne.
L’URL de la console Web est généralement configurable et vous pouvez obtenir l’adresse
de la console Web de votre cluster à l’aide de l’interface de ligne de commande oc. À partir
d’un terminal, vous devez d’abord vous authentifier auprès du cluster via l’interface de ligne
de commande à l’aide de la commande oc login -u <USERNAME> -p <PASSWORD>
<API_ENDPOINT>:<PORT> :
[user@host ~]$ oc login -u developer -p developer https://

api.ocp4.example.com:6443
Login successful.
...output omitted...
Ensuite, vous exécutez la commande oc whoami --show-console pour récupérer l’URL de la

console Web :
[user@host ~]$ oc whoami --show-console

https://console-openshift-console.apps.ocp4.example.com
16 DO180-OCP4.14-fr-2-20240530
Pour terminer, utilisez un navigateur Web pour accéder à l’URL qui affiche la page
d’authentification :
Figure 1.6: Page d’authentification d’OpenShift
L’utilisation des informations d’identification pour l’accès au cluster ouvre la page d’accueil de la
console Web.
Figure 1.7: Page d’accueil d’OpenShift
Perspectives de la console Web

La console Web OpenShift fournit les perspectives de console Administrator et Developer.
La disposition du menu de la barre latérale et les fonctions proposées diffèrent selon la
perspective qui est utilisée. Le premier élément du menu de la barre latérale de la console est
le sélecteur de perspective, qui permet de basculer entre les perspectives Administrator et
Developer.
DO180-OCP4.14-fr-2-20240530 17
Figure 1.8: Sélecteur de perspective de la console Web d’OpenShift
Chaque perspective présente à l’utilisateur des pages et des catégories de menus qui répondent
aux besoins spécifiques de ces deux personas. La perspective Administrator se concentre sur
la configuration du cluster, les déploiements, et les opérations du cluster et des charges de travail
en cours d’exécution. Les pages de la perspective Developer se concentrent sur la création et
l’exécution d’applications.
Disposition de la console Web OpenShift

À partir de la page d’accueil de la console Web, la méthode de navigation principale consiste
à utiliser la barre latérale. La barre latérale classe les fonctions et l’administration du cluster
dans plusieurs catégories principales. Lorsque vous sélectionnez une catégorie dans la barre
latérale, elle se développe pour faire apparaître les différentes zones qui fournissent chacune des
informations, une configuration ou des fonctionnalités spécifiques du cluster.
Note
Lors de la connexion initiale à la console Web, une option vous propose d’effectuer
une courte visite informative. Cliquez sur Skip Tour si vous préférez ignorer l’option
de visite à ce stade.
Par défaut, la console affiche la page Home > Overview qui fournit un aperçu rapide des
configurations initiales du cluster, de la documentation et de l’état général du cluster. Accédez à
18 DO180-OCP4.14-fr-2-20240530
Home > Projects pour lister tous les projets du cluster qui sont disponibles pour les informations
d’identification en cours d’utilisation.
Vous pouvez d’abord parcourir la page Operators > OperatorHub qui permet d’accéder à la
collection d’opérateurs disponibles pour votre cluster.
Figure 1.10: OpenShift OperatorHub
En ajoutant des opérateurs au cluster, vous pouvez étendre les fonctions fournies par votre cluster
OpenShift. Utilisez le filtre de recherche pour trouver les opérateurs disponibles afin d’améliorer le
cluster et de fournir les aspects OpenShift dont vous avez besoin.
En cliquant sur le lien sur la page Operator Hub, vous pouvez parcourir le catalogue des
développeurs (Developer Catalog).
Sélectionnez un projet, ou utilisez le filtre de recherche pour trouver un projet spécifique, afin de
consulter le catalogue des développeurs de ce projet. C’est là que se trouvent les applications
partagées, les services, les sources d’événements ou les compilateurs Source-to-image.
DO180-OCP4.14-fr-2-20240530 19
Figure 1.12: Developer Catalog
Après avoir trouvé les ajouts préférés pour un projet, un administrateur de cluster peut
personnaliser davantage encore le contenu fourni par le catalogue. En adoptant cette approche
pour ajouter les fonctions nécessaires à un projet, les développeurs peuvent les personnaliser afin
de fournir un déploiement d’application idéal.
Concepts clés de Red Hat OpenShift

Lorsque vous parcourez la console Web OpenShift, il est utile de connaître la terminologie de base
relative à OpenShift, Kubernetes et aux conteneurs. La liste suivante comprend certains concepts
de base qui peuvent vous aider à explorer la console Web OpenShift.
• Pod : plus petite unité d’une application en conteneur gérée par Kubernetes. Un pod est
constitué d’un ou de plusieurs conteneurs.
• Déploiement : unité opérationnelle qui permet une gestion précise d’une application en cours
d’exécution.
• Projet : espace de noms Kubernetes avec des annotations supplémentaires qui fournissent une
étendue multisite pour les applications.
• Route : configuration réseau permettant d’exposer vos applications et services à des ressources
situées en dehors du cluster.
• Opérateurs : applications Kubernetes empaquetées qui étendent les fonctionnalités du cluster.
Ces concepts sont abordés plus en détail tout au long du cours. Vous trouverez ces concepts
dans la console Web en explorant les fonctions d’un cluster OpenShift à partir de l’environnement
graphique.
Références
Pour plus d’informations sur la console Web OpenShift, reportez-vous à la
documentation Web console (Console Web) de Red Hat OpenShift Container
Platform, disponible à l’adresse
openshift_container_platform/4.14/html-single/web_console/index
20 DO180-OCP4.14-fr-2-20240530
DO180-OCP4.14-fr-2-20240530 21
Exercice guidé
Exploration de la console Web OpenShift

Accédez à un cluster OpenShift à l’aide de sa console Web et examinez les pages afin
d’identifier ses services clés.
Résultats
• Découvrir les fonctions et les composants de Red Hat OpenShift à l’aide de la console
Web.
• Créer un exemple d’application à l’aide de la perspective Developer dans la console Web.
• Basculer vers la perspective Administrator et examiner les ressources créées pour

l’exemple d’application.
• Utiliser la console Web pour décrire les nœuds du cluster, la mise en réseau, le stockage et
l’authentification.
• Afficher les opérateurs de cluster, les pods, les déploiements et les services par défaut.
Avant De Commencer
En tant qu’utilisateur student sur la machine workstation, utilisez la commande lab
pour préparer votre système pour cet exercice.
Cette commande s’assure que le cluster est validé pour l’exercice.
[student@workstation ~]$ lab start intro-navigate
Instructions
1. En tant qu’utilisateur developer, localisez la console Web Red Hat OpenShift et accédez-
y.
1.1. Utilisez le terminal pour vous connecter au cluster OpenShift en tant qu’utilisateur
developer avec le mot de passe developer.
[student@workstation ~]$ oc login -u developer -p developer \

https://api.ocp4.example.com:6443
1.2. Identifiez l’URL de la console Web OpenShift.
[student@workstation ~]$ oc whoami --show-console

1.3. Ouvrez un navigateur Web et accédez à https://console-openshift-

console.apps.ocp4.example.com. Saisissez l’URL dans un navigateur Web ou cliquez
avec le bouton droit de la souris et sélectionnez Open Link dans le terminal.
22 DO180-OCP4.14-fr-2-20240530
2. Connectez-vous à la console Web OpenShift en tant qu’utilisateur developer.
2.1. Cliquez sur Red Hat Identity Management et connectez-vous en tant qu’utilisateur
DO180-OCP4.14-fr-2-20240530 23
Note
Cliquez sur Skip Tour pour ignorer l’option permettant d’effectuer une courte visite
lors de la première consultation.
3. Utilisez la perspective Developer de la console Web pour créer votre premier projet.
3.1. Dans la section Getting Started de la page +Add, cliquez sur Create a new
project pour ouvrir l’assistant Create Project.
3.2. Créez un projet nommé intro-navigate à l’aide de l’assistant. Utilisez intro-

navigate comme nom d’affichage et ajoutez une brève description du projet.
24 DO180-OCP4.14-fr-2-20240530
3.3. Cliquez sur Create pour créer le projet.
3.4. Cliquez sur Topology pour afficher le projet.
4. Déployez un exemple d’application dans le projet.
4.1. Sélectionnez le lien Start building your application pour parcourir les exemples
d’applications disponibles.
DO180-OCP4.14-fr-2-20240530 25
4.2. Saisissez Apache dans la barre de recherche pour afficher les exemples
d’applications disponibles pour le déploiement.
4.3. Sélectionnez l’option Samples à partir de Apache HTTP Server (httpd) dans la liste
des applications disponibles, puis cliquez sur Create dans le panneau latéral.
4.4. Utilisez application-test pour le nom de l’application et le nom du déploiement,

GitLab pour le type Git et https://git.ocp4.example.com/developer/
httpd-ex.git pour l’URL du référentiel Git. Conservez le reste des valeurs par
défaut et sélectionnez Create en bas de la page pour créer l’application.
26 DO180-OCP4.14-fr-2-20240530
La page Topology s’ouvre et affiche le déploiement de l’application application-

test.
5. Affichez les détails du déploiement pour l’application application-test.
5.1. Sélectionnez le déploiement application-test pour afficher les détails de

l’application.
DO180-OCP4.14-fr-2-20240530 27
5.2. Sélectionnez la liste Actions pour afficher les contrôles disponibles pour le
déploiement de application-test.
6. Basculez vers la perspective Administrator et examinez le déploiement.
6.1. À partir de la console Web OpenShift, localisez le panneau gauche. Si le panneau

de gauche n’est pas visible, cliquez sur l’icône du menu principal en haut à gauche
de la console Web. Cliquez sur Developer, puis sur Administrator pour passer à la
perspective Administrator. La console Web bascule vers la nouvelle perspective
et affiche des informations supplémentaires via la barre latérale.
28 DO180-OCP4.14-fr-2-20240530
6.2. Sélectionnez le projet intro-navigate pour ouvrir la page Project details. Cette page
comprend une présentation générale du projet, telle que l’état du projet et des détails
sur l’utilisation des ressources.
7. Affichez le déploiement et les pods de application-test.
7.1. À partir du menu de la console Web OpenShift, accédez à Workloads > Pods pour
afficher les pods application-test.
DO180-OCP4.14-fr-2-20240530 29
7.2. Accédez à Workloads > Deployments pour afficher la liste des déploiements du
projet.
7.3. Cliquez sur application-test pour afficher les détails du déploiement.
8. Affichez le service et la route application-test.
8.1. Accédez à Networking > Services, puis cliquez sur application-test pour afficher les
détails du service application-test.
30 DO180-OCP4.14-fr-2-20240530
8.2. Accédez à Networking > Route, puis cliquez sur application-test pour afficher les
détails de la route application-test.
9. Supprimez le projet et déconnectez-vous de la console Web.
9.1. À partir du menu de la console Web OpenShift, accédez à Home > Projects.
Sélectionnez Delete Project dans le menu contextuel du projet intro-navigate.
9.2. Saisissez le nom du projet dans la zone de texte, puis sélectionnez Delete.
DO180-OCP4.14-fr-2-20240530 31
9.3. Déconnectez-vous de la console Web. Dans le panneau de droite de la console Web

OpenShift, cliquez sur developer et sélectionnez ensuite Log out dans le menu du
compte.
10. Connectez-vous à la console Web OpenShift en tant qu’utilisateur admin pour examiner
les détails supplémentaires du cluster.
Note
Lorsque vous utilisez un compte d’administrateur de cluster, vous pouvez parcourir
les composants du cluster. Cependant, ne modifiez et ne supprimez aucun des
composants.
10.1. Connectez-vous à la console Web. Sélectionnez Red Hat Identity Management, puis
saisissez le nom d’utilisateur admin et le mot de passe redhatocp.
32 DO180-OCP4.14-fr-2-20240530
10.2. À partir du menu de la console Web OpenShift, accédez à Operators > Installed
Operators. Chaque opérateur fournit une fonction spécifique pour le cluster.
Sélectionnez un opérateur pour en afficher les détails.
10.3. Accédez à Workloads > Pods pour afficher la liste de tous les pods du cluster. La
barre de recherche située dans la partie supérieure permet de réduire la liste des
pods. Sélectionnez un pod pour en afficher les détails.
10.4. Accédez à Workloads > Deployments pour afficher la liste de tous les déploiements
du cluster. Sélectionnez un déploiement pour en afficher les détails.
DO180-OCP4.14-fr-2-20240530 33
10.5. Accédez à Networking > Services pour afficher la liste de tous les services du cluster.
Sélectionnez un service pour en afficher les détails.
11. Déconnectez-vous de la console Web.
11.1. Déconnectez-vous de la console Web. Dans le panneau de droite de la console Web

OpenShift, cliquez sur Administrator et sélectionnez ensuite Log out dans le menu
du compte.
Fin
Sur la machine workstation , utilisez la commande lab pour mettre fin à l’exercice. Il s’agit
d’une étape importante pour vous assurer que les ressources des exercices précédents n’ont pas
d’impact sur les exercices à venir.
34 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ lab finish intro-navigate
DO180-OCP4.14-fr-2-20240530 35
Surveillance d’un cluster OpenShift
Résultats
• Parcourir les panneaux Events, Compute et Observe de la console Web OpenShift pour évaluer
l’état général d’un cluster.
Présentation des nœuds, des machines et des

configurations de machine
Dans Kubernetes, un nœud est un système unique du cluster dans lequel des pods peuvent
s’exécuter. Ces systèmes sont des ordinateurs sans système d’exploitation, des ordinateurs
virtuels ou des ordinateurs cloud qui sont membres du cluster. Les nœuds exécutent les services
nécessaires pour communiquer au sein du cluster et reçoivent les demandes opérationnelles du
plan de contrôle. Lorsque vous déployez un pod, un nœud disponible est chargé de satisfaire la
demande.
En règle générale, les termes nœud et machine sont interchangeables. Cependant, Red Hat
OpenShift Container Platform (RHOCP) utilise le terme machine de manière plus spécifique.
Dans OpenShift, une machine est la ressource qui décrit un nœud de cluster. L’utilisation d’une
ressource machine est particulièrement utile lorsque vous utilisez des fournisseurs de cloud public
pour mettre en service l’infrastructure.
Une ressource MachineConfig définit l’état initial et toute modification apportée aux fichiers,
aux services, aux mises à jour du système d’exploitation et aux versions critiques du service
OpenShift pour les services kubelet et cri-o. OpenShift s’appuie sur l’opérateur MCO
(Machine Config Operator) pour gérer les systèmes d’exploitation et la configuration des
machines du cluster. L’opérateur MCO est un opérateur au niveau du cluster qui garantit la
configuration correcte de chaque machine. Cet opérateur effectue également des tâches
d’administration périodiques telles que des mises à jour du système. Il utilise les définitions de
machine d’une ressource MachineConfig pour valider et corriger en continu l’état des machines
du cluster sur l’état prévu. Après une modification MachineConfig, l’opérateur MCO orchestre
l’exécution des modifications pour tous les nœuds affectés.
Note
L’orchestration des modifications de MachineConfig via l’opérateur MCO est
priorisée par ordre alphabétique et par zone, en utilisant l’étiquette de nœud
topology.kubernetes.io/zone.
Identification des erreurs à partir des nœuds

Les administrateurs affichent régulièrement les journaux et se connectent aux nœuds du cluster
à l’aide d’un terminal. Cette technique est nécessaire pour gérer un cluster et résoudre les
problèmes qui se produisent. À partir de la console Web, accédez à Compute > Nodes pour
afficher la liste de tous les nœuds du cluster.
36 DO180-OCP4.14-fr-2-20240530
Figure 1.41: Liste des nœuds dans la console Web
Cliquez sur le nom d’un nœud pour accéder à la page de présentation du nœud. Sur la page de
présentation du nœud, vous pouvez consulter les journaux du nœud ou vous connecter au nœud à
l’aide du terminal.
Figure 1.42: Page Logs de la console Web
Sur la page précédente de la console Web, affichez les journaux du nœud et examinez les
informations système pour faciliter la résolution des problèmes affectant le nœud.
DO180-OCP4.14-fr-2-20240530 37
Figure 1.43: Shell de terminal dans la console Web
La page précédente présente le terminal de console Web qui est connecté au nœud du cluster.
À partir de cet onglet, vous pouvez accéder au pod de débogage et utiliser les commandes des
fichiers binaires de l’hôte pour afficher l’état des services du nœud. Un pod de débogage de nœud
OpenShift est une interface vers un conteneur qui s’exécute sur le nœud.
Bien qu’il soit déconseillé d’effectuer directement des modifications sur le nœud de cluster à
partir du terminal, il est d’usage de se connecter au nœud du cluster pour l’enquête diagnostique
et la correction des erreurs. À partir de ce terminal, vous pouvez utiliser les mêmes binaires que
ceux qui sont disponibles dans le nœud de cluster proprement dit.
De plus, les onglets de la page de présentation du nœud affichent les métriques, les événements
et le fichier de définition YAML du nœud.
Accès aux journaux du pod

Les administrateurs parcourent souvent les journaux de pod pour évaluer l’intégrité d’un pod
déployé ou pour résoudre les problèmes de déploiement d’un pod. Accédez à la page Workloads >
Pods pour afficher la liste de tous les pods du cluster.
Figure 1.44: Page Pods de la console Web
38 DO180-OCP4.14-fr-2-20240530
Vous pouvez filtrer et trier les pods par projet et par d’autres champs. Pour afficher la page des
détails d’un pod, cliquez sur le nom d’un pod dans la liste.
Figure 1.45: Page des détails du pod
La page des détails du pod contient des liens vers des métriques de pod, des variables
d’environnement, des journaux, des événements, un terminal et la définition YAML du pod. Les
journaux du pod sont disponibles sur la page Pods > Logs et fournissent des informations sur
l’état du pod. La page Pods > Terminal ouvre une connexion shell au pod à des fins d’inspection et
de résolution des problèmes. Bien qu’il soit déconseillé de modifier un pod en cours d’exécution,
le terminal est utile pour diagnostiquer les problèmes du pod et les résoudre. Pour corriger un
pod, mettez à jour sa configuration afin de prendre en compte les modifications nécessaires, puis
redéployez le pod.
Métriques et alertes de Red Hat OpenShift Container Platform

Dans un cluster RHOCP, les points d’accès du service HTTP fournissent des métriques de
données qui sont collectées dans le but de fournir des informations pour la surveillance des
performances du cluster et des applications. Ces métriques sont créées au niveau de l’application
pour chaque service, en utilisant les bibliothèques clientes fournies par Prometheus (une boîte
à outils de surveillance et d’alerte Open Source). Les données sont disponibles à partir du point
d’accès du service /metrics. Vous pouvez utiliser ces données pour créer des moniteurs afin
d’envoyer des alertes en fonction de la dégradation du service. Les moniteurs sont des processus
qui évaluent en continu la valeur d’une métrique spécifique et fournissent des alertes qui sont
basées sur une condition prédéfinie, dans le but de signaler une dégradation du service ou un
problème de performances. La création d’une ressource ServiceMonitor définit la manière
dont un service spécifique utilise les métriques pour définir un moniteur et les valeurs d’alerte. La
même approche est disponible pour la surveillance des pods. Pour cela, définissez une ressource
PodMonitor qui utilise les métriques collectées à partir du pod.
En fonction des définitions du moniteur, les alertes sont alors disponibles sur la base de la
métrique interrogée et des critères de réussite définis. Le moniteur compare en permanence la
métrique collectée et crée une alerte lorsque les conditions de réussite ne sont plus remplies. Par
exemple, un moniteur de service Web interroge le port d’écoute (port 80) et émet des alertes
uniquement si la réponse provenant de ce port n’est plus valide.
Dans la console Web, accédez à Observe > Metrics pour visualiser les métriques collectées à l’aide
d’un utilitaire de requête de données basé sur Grafana. Sur cette page, les utilisateurs peuvent
DO180-OCP4.14-fr-2-20240530 39
soumettre des requêtes pour créer des graphiques de données et des tableaux de bord, que les
administrateurs peuvent consulter afin de collecter des statistiques utiles pour le cluster et les
applications.
Pour les moniteurs configurés, accédez à Observe > Alerting pour afficher les alertes
de déclenchement, et effectuez un filtrage sur la gravité des alertes pour afficher celles
qui nécessitent une correction. Les données d’alerte sont un élément clé pour aider les
administrateurs à fournir l’accès aux clusters et aux applications, ainsi que les fonctions
respectives.
Événements Kubernetes
En règle générale, les administrateurs connaissent bien le contenu des fichiers journaux pour les
services, alors que ces journaux ont tendance à être très détaillés et très précis. Les événements
fournissent une abstraction de haut niveau pour les fichiers journaux et pour présenter des
informations sur les modifications les plus importantes. Les événements sont utiles pour
comprendre rapidement les performances et le comportement du cluster, des nœuds, des
projets ou des pods. Les événements fournissent des détails permettant de comprendre les
performances générales et de mettre en évidence les problèmes importants. Les journaux
fournissent un niveau de détail plus approfondi pour résoudre des problèmes spécifiques.
La page Home > Events affiche les événements de tous les projets ou d’un projet spécifique. Ils
peuvent être filtrés et faire l’objet de recherches.
Figure 1.46: Console d’événements de RHOCP
Red Hat OpenShift Container Platform API Explorer

Depuis la version 4, RHOCP inclut la fonction API Explorer qui permet aux utilisateurs d’afficher
le catalogue des types de ressources Kubernetes disponibles dans le cluster. En accédant à Home
> API Explorer, vous pouvez afficher et explorer les détails des ressources. Ces détails sont
notamment la description, le schéma et d’autres métadonnées de la ressource. Cette fonction est
utile pour tous les utilisateurs, et en particulier pour les nouveaux administrateurs.
Figure 1.47: RHOCP API Explorer
40 DO180-OCP4.14-fr-2-20240530
Références
Pour plus d’informations sur les machines Red Hat OpenShift Container Platform,
reportez-vous au chapitre Overview of Machine Management (Présentation de la
gestion des machines) de la documentation Machine Management (Gestion des
machines) de Red Hat OpenShift Container Platform, disponible à l’adresse
openshift_container_platform/4.14/html-single/machine_management/
index#overview-of-machine-management
The API Explorer

https://cloud.redhat.com/blog/openshift-4-2-the-api-explorer
Well-known Labels, Annotations and Taints, topology.kubernetes.io/zone

https://kubernetes.io/docs/reference/labels-annotations-taints/
#topologykubernetesiozone
DO180-OCP4.14-fr-2-20240530 41
Exercice guidé
Surveillance d’un cluster OpenShift

Évaluez l’état global d’un cluster OpenShift à l’aide de la console Web, et identifiez les
projets et les pods des composants d’architecture de base de Kubernetes et d’OpenShift.
Résultats
• Explorer et afficher les fonctions et composants de surveillance.
• Explorer la page Overview pour examiner l’état du cluster.
• Utiliser une connexion de terminal au nœud master01 pour afficher les services crio et
kubelet.
• Explorer la page Monitoring, les configurations de règles d’alerte et le tableau de bord du

service etcd.
• Explorer la page Events et filtrer les événements par nom de ressource, type et message.
Avant De Commencer
Cette commande s’assure que le cluster a été préparé pour l’exercice.
[student@workstation ~]$ lab start intro-monitor
Instructions
1. En tant qu’utilisateur developer, localisez la console Web Red Hat OpenShift et accédez-
y.
1.1. Utilisez le terminal pour vous connecter au cluster OpenShift en tant qu’utilisateur

1.2. Identifiez l’URL de la console Web OpenShift.
[student@workstation ~]$ oc whoami --show-console


console.apps.ocp4.example.com. Saisissez l’URL dans un navigateur Web ou cliquez
avec le bouton droit de la souris et sélectionnez Open Link dans le terminal.
42 DO180-OCP4.14-fr-2-20240530
2. Connectez-vous à la console Web OpenShift en tant qu’utilisateur admin.
admin avec le mot de passe redhatocp.
3. Affichez l’intégrité et l’état général du cluster.
3.1. Examinez la page Cluster Overview.

Si cette page ne s’affiche pas après une connexion réussie, localisez le panneau de
gauche à partir de la console Web OpenShift. Si le panneau de gauche n’est pas
visible, cliquez sur l’icône du menu principal en haut à gauche de la console Web.
Accédez à Home > Overview pour afficher des informations générales sur le cluster.
DO180-OCP4.14-fr-2-20240530 43
La section Overview contient des liens vers une documentation utile et une
procédure détaillée de configuration initiale du cluster.
3.2. Faites défiler vers le bas pour afficher la section Status, qui contient un résumé des
performances et de l’intégrité du cluster.
Nombre des en-têtes sont des liens vers des sections avec des informations plus
détaillées sur le cluster.
3.3. Continuez à faire défiler la page pour afficher la section Cluster utilization, qui
contient des métriques et des graphiques illustrant la consommation des ressources.
44 DO180-OCP4.14-fr-2-20240530
3.4. Continuez à faire défiler la page pour afficher la section Details, qui contient des
informations telles que l’adresse de l’API de cluster, l’ID du cluster et la version de
Red Hat OpenShift.
3.5. Faites défiler la page jusqu’à la section Cluster Inventory, qui contient des liens vers
les pages Nodes, Pods, StorageClasses et PersistentVolumeClaim.
3.6. La dernière partie de la page contient la section Activity, qui liste les activités en
cours et les événements récents pour le cluster.
4. Utilisez la console Web OpenShift pour accéder au terminal d’un nœud de cluster. À
partir du terminal, déterminez l’état du service d’agent du nœud kubelet et du service
d’interface d’exécution du conteneur CRI-O.
4.1. Accédez à Compute > Nodes pour afficher la machine qui fournit les ressources du
cluster.
DO180-OCP4.14-fr-2-20240530 45
Note
Le cluster de la salle de classe s’exécute sur un seul nœud nommé master01, qui
sert de plan de contrôle et plan de données pour le cluster. Il est conçu à des fins de
formation. Un cluster de production utilise plusieurs nœuds pour garantir la stabilité
et fournir une architecture à haute disponibilité.
4.2. Cliquez sur le lien master01 pour afficher les détails du nœud de cluster.
4.3. Cliquez sur l’onglet Terminal pour vous connecter à un shell sur le nœud master01.
Avec le shell interactif sur cette page, vous pouvez exécuter des commandes
directement sur le nœud du cluster.
4.4. Exécutez la commande chroot /host pour activer les binaires hôtes sur le nœud.
46 DO180-OCP4.14-fr-2-20240530
4.5. Affichez l’état du service d’agent du nœud kubelet en exécutant la commande

systemctl status kubelet.
Appuyez sur q pour quitter la commande et revenir à l’invite du terminal.
4.6. Affichez l’état du service d’interface d’exécution du conteneur CRI-O en exécutant la

commande systemctl status crio.
Appuyez sur q pour quitter la commande et revenir à l’invite du terminal.
5. Examinez les configurations des règles d’alerte et de surveillance du cluster.
5.1. À partir du menu de la console Web OpenShift, accédez à Observe > Alerting pour
afficher les informations d’alerte du cluster.
5.2. Sélectionnez l’onglet Alerting rules pour afficher les différentes définitions d’alerte.
DO180-OCP4.14-fr-2-20240530 47
5.3. Filtrez les règles d’alerte par nom et recherchez le terme storageClasses.
5.4. Sélectionnez l’alerte Warning intitulée MultipleDefaultStorageClasses

pour afficher les détails de la règle d’alerte. Examinez les définitions Description et
Expression de la règle.
48 DO180-OCP4.14-fr-2-20240530
6. Examinez les métriques de cluster et exécutez un exemple de requête.
6.1. Accédez à Observe > Metrics pour ouvrir l’utilitaire des métriques du cluster.
6.2. Cliquez sur Insert example query pour compléter le graphique des métriques avec
des exemples de données.
6.3. Dans le graphique, survolez n’importe quel point de la chronologie pour afficher les
points de données détaillés.
DO180-OCP4.14-fr-2-20240530 49
7. Affichez le journal des événements du cluster à partir de la console Web.
7.1. Accédez à Home > Events pour ouvrir le journal des événements du cluster.
Note
Le journal des événements est mis à jour toutes les 15 minutes et un délai
supplémentaire peut être nécessaire pour renseigner les entrées.
7.2. Faites défiler vers le bas pour afficher un flux classé par ordre chronologique
contenant les événements du cluster.
50 DO180-OCP4.14-fr-2-20240530
Note
Sélectionnez un événement pour ouvrir la page Details de la ressource associée.
8. Filtrez les événements par nom de ressource, par type ou par message.
8.1. Dans la liste déroulante Resources, utilisez la barre de recherche pour effectuer un
filtrage sur le terme pod et cochez la case intitulée Pod pour afficher les événements
associés à cette ressource.
8.2. Continuez à préciser le filtre en sélectionnant Normal dans la liste déroulante des
types.
8.3. Filtrez les résultats à l’aide de la zone de texte Message. Saisissez le texte started
container pour récupérer les événements correspondants.
DO180-OCP4.14-fr-2-20240530 51
Fin
[student@workstation ~]$ lab finish intro-monitor
52 DO180-OCP4.14-fr-2-20240530
Open Lab
d’OpenShift
Recherchez des informations essentielles sur votre cluster OpenShift en parcourant sa
console Web.
Résultats
Accédez à la console Web Red Hat OpenShift Container Platform pour trouver divers
éléments d’information et détails de configuration.
Avant De Commencer
Cette commande permet de s’assurer que Red Hat OpenShift Container Platform est
déployé et prêt pour l’atelier.
[student@workstation ~]$ lab start intro-review
Instructions
1. Connectez-vous à la console Web Red Hat OpenShift Container Platform, en utilisant
Red Hat Identity Management comme utilisateur admin avec le mot de passe redhatocp,
et examinez les réponses du quiz précédent.
2. Affichez la version du cluster sur la page Overview du cluster.
3. Affichez les types de gravité d’alerte disponibles dans les filtres de la page Alerting.
4. Affichez les étiquettes de la route thanos-querier.
5. Affichez les classes de stockage disponibles dans le cluster.
6. Affichez les opérateurs installés pour le cluster.
Fin
En tant qu'utilisateur student sur la machine workstation, utilisez la commande lab pour
effectuer cet exercice. Il s’agit d’une étape importante pour vous assurer que les ressources des
exercices précédents n’ont pas d’incidence sur les exercices à venir.
[student@workstation ~]$ lab finish intro-review
DO180-OCP4.14-fr-2-20240530 53
Solution
d’OpenShift
Recherchez des informations essentielles sur votre cluster OpenShift en parcourant sa
console Web.
Résultats
Accédez à la console Web Red Hat OpenShift Container Platform pour trouver divers
éléments d’information et détails de configuration.
Avant De Commencer
Cette commande permet de s’assurer que Red Hat OpenShift Container Platform est
déployé et prêt pour l’atelier.
[student@workstation ~]$ lab start intro-review
Instructions
1. Connectez-vous à la console Web Red Hat OpenShift Container Platform, en utilisant
Red Hat Identity Management comme utilisateur admin avec le mot de passe redhatocp,
et examinez les réponses du quiz précédent.
1.1. Utilisez un navigateur pour afficher la page de connexion à l’adresse https://

console-openshift-console.apps.ocp4.example.com.
1.2. Cliquez sur Red Hat Identity Management, saisissez le nom d’utilisateur admin et le
mot de passe redhatocp, puis cliquez sur Log in pour accéder à la page d’accueil.
54 DO180-OCP4.14-fr-2-20240530
2. Affichez la version du cluster sur la page Overview du cluster.
2.1. Faites défiler la page Home > Overview vers le bas pour afficher les détails du cluster.
2.2. Recherchez la version OpenShift dans la section Details.
DO180-OCP4.14-fr-2-20240530 55
3. Affichez les types de gravité d’alerte disponibles dans les filtres de la page Alerting.
3.1. Accédez à la page Observe > Alerting.
3.2. Cliquez sur la liste déroulante Filter pour afficher les options de gravité disponibles.
56 DO180-OCP4.14-fr-2-20240530
4. Affichez les étiquettes de la route thanos-querier.
4.1. Accédez à la page Networking > Routes.
4.2. Saisissez le mot-clé thanos dans le champ de recherche de texte.
4.3. Sélectionnez la route thanos-querier dans la colonne Name.
DO180-OCP4.14-fr-2-20240530 57
4.4. Faites défiler la page des détails de route thanos-querier vers le bas pour afficher
les étiquettes.
5. Affichez les classes de stockage disponibles dans le cluster.
5.1. Accédez à la page Storage > StorageClasses.
5.2. Affichez les classes de stockage disponibles dans le cluster.
6. Affichez les opérateurs installés pour le cluster.
58 DO180-OCP4.14-fr-2-20240530
6.1. Accédez à la page Operators > Installed Operators.
6.2. Affichez la liste des opérateurs installés dans le cluster.
Fin
[student@workstation ~]$ lab finish intro-review
DO180-OCP4.14-fr-2-20240530 59
Quiz
d’OpenShift
Répondez aux questions suivantes en sélectionnant un ou plusieurs éléments :
1. Quelle est la version installée du cluster OpenShift ?

a. 3.9.1
b. 4.3.2
c. 4.14.0
d. 5.4.3
2. Quels sont les trois types de gravité disponibles pour les alertes dans le cluster ?
(Choisissez-en trois.)
a. Avertissement
b. Déclenchement
c. Info
d. Urgent
e. Critique
f. Oups !
3. Quelles sont les trois étiquettes appliquées à la route thanos-querier dans l’espace
de noms openshift-monitoring ? (Choisissez-en trois.)
a. app.kubernetes.io/component=query-layer
b. app.kubernetes.io/instance=thanos-querier
c. app.kubernetes.io/part-of=openshift-storage
d. app.kubernetes.io/version=0.30.2
4. Quels sont les deux objets répertoriés en tant qu’objets StorageClasses pour le
cluster ? (Choisissez-en deux.)
a. ceph-storage
b. nfs-storage
c. k8s-lvm-vg1
d. local-volume
e. lvms-vg1
60 DO180-OCP4.14-fr-2-20240530
5. Lorsque All Projects est sélectionné en haut, quels sont les trois opérateurs installés
dans le cluster ? (Choisissez-en trois.)
a. MongoDB Operator
b. MetalLB Operator
c. Red Hat Fuse
d. Stockage LVM
e. Serveur de paquetages
DO180-OCP4.14-fr-2-20240530 61
Solution
d’OpenShift
1. Quelle est la version installée du cluster OpenShift ?

a. 3.9.1
b. 4.3.2
c. 4.14.0
d. 5.4.3
2. Quels sont les trois types de gravité disponibles pour les alertes dans le cluster ?
a. Avertissement
b. Déclenchement
c. Info
d. Urgent
e. Critique
f. Oups !
3. Quelles sont les trois étiquettes appliquées à la route thanos-querier dans l’espace
de noms openshift-monitoring ? (Choisissez-en trois.)
a. app.kubernetes.io/component=query-layer
b. app.kubernetes.io/instance=thanos-querier
c. app.kubernetes.io/part-of=openshift-storage
d. app.kubernetes.io/version=0.30.2
4. Quels sont les deux objets répertoriés en tant qu’objets StorageClasses pour le
cluster ? (Choisissez-en deux.)
a. ceph-storage
b. nfs-storage
c. k8s-lvm-vg1
d. local-volume
e. lvms-vg1
62 DO180-OCP4.14-fr-2-20240530
5. Lorsque All Projects est sélectionné en haut, quels sont les trois opérateurs installés
dans le cluster ? (Choisissez-en trois.)
a. MongoDB Operator
b. MetalLB Operator
c. Red Hat Fuse
d. Stockage LVM
e. Serveur de paquetages
DO180-OCP4.14-fr-2-20240530 63
Résumé
• Un conteneur est un processus encapsulé qui inclut les dépendances d’exécution requises pour
l’exécution d’une application.
• La mise en conteneur répond aux défis du développement d’applications en matière de

portabilité du code, afin de faciliter l’exécution cohérente d’une application à partir de divers
environnements.
• La mise en conteneur vise également à modulariser les applications afin d’améliorer le

développement et la maintenance des différents composants de l’application.
• Lors de l’exécution de conteneurs à grande échelle, il devient difficile de configurer et de fournir

des applications à haute disponibilité, et de configurer la mise en réseau, sans une plateforme de
conteneurs, telle que Kubernetes.
• Le pod est la plus petite unité organisationnelle pour une application en conteneur dans un
cluster Kubernetes.
• Red Hat OpenShift Container Platform (RHOCP) ajoute des fonctions adaptées aux entreprises
à la plateforme de conteneurs Kubernetes pour répondre aux besoins métier plus étendus.
• La plupart des tâches administratives effectuées par les développeurs et les administrateurs de
cluster sont disponibles via la console Web RHOCP.
• Les journaux, les métriques, les alertes, les connexions de terminal aux nœuds et aux pods du
cluster, ainsi que de nombreuses autres fonctions sont disponibles via la console Web RHOCP.
64 DO180-OCP4.14-fr-2-20240530
chapitre 2
API et interfaces de ligne de

commande Kubernetes et
OpenShift
Objectif Accéder à un cluster OpenShift à l’aide de la ligne
de commande et interroger ses ressources d’API
Kubernetes pour évaluer l’intégrité d’un cluster.
Résultats • Accéder à un cluster OpenShift à l’aide des

interfaces de ligne de commande Kubernetes
et OpenShift.
• Interroger, formater et filtrer les attributs des
ressources Kubernetes.
• Exécuter une requête pour connaître l’intégrité
des services et composants de cluster
essentiels.
Sections • Interfaces de ligne de commande Kubernetes

et OpenShift (et exercice guidé)
• Examen des ressources Kubernetes (et exercice
guidé)
• Évaluation de l’intégrité d’un cluster
OpenShift (et exercice guidé)
Atelier • API et interfaces de ligne de commande

Kubernetes et OpenShift
DO180-OCP4.14-fr-2-20240530 65
chapitre 2 | API et interfaces de ligne de commande Kubernetes et OpenShift
Interfaces de ligne de commande

Résultats
• Accéder à un cluster OpenShift à l’aide des interfaces de ligne de commande Kubernetes et
OpenShift.
Interfaces de ligne de commande Kubernetes et

OpenShift
Vous pouvez gérer un cluster OpenShift à partir de la console Web ou en utilisant les interfaces de
ligne de commande (CLI) kubectl ou oc. Les commandes kubectl sont natives à Kubernetes
et constituent une mince enveloppe autour de l’API Kubernetes. Les commandes OpenShift oc
représentent un sur-ensemble des commandes kubectl et ajoutent des commandes pour les
fonctions spécifiques à OpenShift. Des exemples de commandes kubectl et oc sont présentés
dans ce cours pour mettre en évidence ce qui les différencie.
La commande oc vous permet de créer des applications et de gérer des projets Red Hat
OpenShift Container Platform (RHOCP) à partir d’un terminal. L’interface de ligne de commande
OpenShift est idéale dans les situations suivantes :
• Utilisation directe du code source du projet.
• Scriptage des opérations OpenShift Container Platform.
• Gestion des projets limités par la bande passante.
• Indisponibilité de la console Web.
• Utilisation de ressources OpenShift, telles que routes et deployment configs.
Outil de ligne de commande Kubernetes

L’installation de l’interface de ligne de commande oc comprend également une installation
de l’interface de ligne de commande kubectl. Il s’agit de la méthode recommandée pour
l’installation de l’interface de ligne de commande kubectl pour les utilisateurs d’OpenShift.
Vous pouvez également installer la CLI kubectl indépendamment de la CLI oc. Vous devez
utiliser une version de la CLI kubectl qui n’est pas éloignée de plus d’une version mineure de
celle de votre cluster. Par exemple, un client v1.26 peut communiquer avec les plans de contrôle
v1.25, v1.26 et v1.27. L’utilisation de la dernière version compatible de l’interface de ligne de
commande kubectl permet d’éviter les problèmes imprévus.
Avant d’effectuer une installation manuelle du binaire kubectl pour une installation Linux, vous
devez télécharger la dernière version à l’aide de la commande curl.
[user@host ~]$ curl -LO "https://dl.k8s.io/release/$(curl -L \

-s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
Ensuite, vous devez télécharger le fichier de somme de contrôle kubectl, puis valider le binaire
kubectl par rapport au fichier de somme de contrôle.
66 DO180-OCP4.14-fr-2-20240530
[user@host ~]$ curl -LO "https://dl.k8s.io/$(curl -L \

-s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256"
[user@host ~]$ echo "$(cat kubectl.sha256) kubectl" | sha256sum --check

kubectl: OK
Si la vérification échoue, la commande sha256sum se ferme avec un état non nul et imprime un
message kubectl: FAILED.
Vous pouvez alors installer l’interface de ligne de commande kubectl.
[user@host ~]$ sudo install -o root -g root -m 0755 kubectl \

/usr/local/bin/kubectl
Note
Si vous ne disposez pas de l’accès root sur le système cible, vous pouvez toujours
installer l’interface de ligne de commande kubectl dans le répertoire ~/.local/
bin. Pour plus d’informations, consultez https://kubernetes.io/docs/tasks/tools/
install-kubectl-linux/.
Enfin, exécutez la commande kubectl version pour vérifier la version installée. Cette
commande imprime les versions client et serveur. Utilisez l’option --client pour afficher
uniquement la version client.
[user@host ~]$ kubectl version --client
Une distribution basée sur Red Hat Enterprise Linux (RHEL) peut également installer l’interface
de ligne de commande kubectl à l’aide de la commande suivante :
[user@host ~]$ cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo

[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
enabled=1
gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
[user@host ~]$ sudo yum install -y kubectl
Pour afficher la liste des commandes kubectl disponibles, exécutez la commande kubectl --
help.
[user@host ~]$ kubectl --help

kubectl controls the Kubernetes cluster manager.
Find more information at:

https://kubernetes.io/docs/reference/kubectl/
Basic Commands (Beginner):
DO180-OCP4.14-fr-2-20240530 67
create Create a resource from a file or from stdin

expose Take a replication controller, service, deployment or pod and
expose it as a new Kubernetes Service
run Run a particular image on the cluster
set Set specific features on objects
Basic Commands (Intermediate):

Vous pouvez également utiliser l’option --help sur n’importe quelle commande pour afficher
des informations détaillées à son sujet, y compris sa finalité, des exemples, les sous-commandes
disponibles et les options. Par exemple, la commande suivante fournit des informations sur la
commande kubectl create et son utilisation.
[user@host ~]$ kubectl create --help

Create a resource from a file or from stdin.
JSON and YAML formats are accepted.
Examples:
# Create a pod using the data in pod.json
kubectl create -f ./pod.json
# Create a pod based on the JSON passed into stdin

cat pod.json | kubectl create -f -
# Edit the data in registry.yaml in JSON then create the resource using the
edited data
kubectl create -f registry.yaml --edit -o json
Available Commands:
clusterrole Create a cluster role
clusterrolebinfing Create a cluster role binding for a particular cluster
role
Kubernetes utilise de nombreux composants de ressource pour la prise en charge des applications.
La commande kubectl explain fournit des informations détaillées sur les attributs d’une
ressource donnée. Par exemple, utilisez la commande suivante pour en savoir plus sur les attributs
d’une ressource pod.
[user@host ~]$ kubectl explain pod

KIND: Pod
VERSION: v1
DESCRIPTION:
Pod is a collection of containers that can run on a host. This resource is
created by clients and scheduled onto hosts.
FIELDS:
apiVersion <string>
APIVersion defines the versioned schema of this representation of an
object.
68 DO180-OCP4.14-fr-2-20240530
Reportez-vous à la section Getting Started de la documentation Kubernetes [https://

kubernetes.io/docs/reference/generated/kubectl/kubectl-commands/] pour plus d’informations
sur les commandes kubectl.
Outil de ligne de commande OpenShift

La principale méthode d’interaction avec un cluster RHOCP consiste à utiliser la commande oc.
Vous pouvez télécharger l’interface de ligne de commande oc à partir de la console Web

OpenShift pour vous assurer que les outils CLI sont compatibles avec le cluster RHOCP. À
partir de la console Web OpenShift, accédez à Help > Command line tools. Le menu Help est
représenté par une icône ?. La console Web fournit plusieurs options d’installation pour le client
oc, telles que des téléchargements pour les systèmes d’exploitation suivants :
• Systèmes Mac, Linux et Windows x86_64

• Systèmes Mac et Linux ARM 64
• Linux pour IBM Z, IBM Power et Little Endian
L’utilisation de base de la commande oc s’effectue par le biais de ses sous-commandes avec la

syntaxe suivante :
[user@host ~]$ oc command
Étant donné que la CLI oc est un sur-ensemble de la CLI kubectl, les commandes version, --
help et explain sont les mêmes pour les deux CLI. Cependant, la CLI oc inclut des commandes
supplémentaires qui ne figurent pas dans la CLI kubectl, telles que oc login et oc new-
project.
Gestion de ressources au niveau de la ligne de commande

Les développeurs habitués à Kubernetes peuvent utiliser l’utilitaire kubectl pour gérer un cluster
RHOCP. Ce cours utilise l’utilitaire de ligne de commande oc pour tirer parti de fonctions RHOCP
supplémentaires. Les commandes oc gèrent les ressources exclusives à RHOCP, telles que les
projets, les configurations de déploiement, les routes et les flux d’images.
DO180-OCP4.14-fr-2-20240530 69
Avant de pouvoir interagir avec votre cluster RHOCP, vous devez authentifier vos requêtes.
Utilisez la commande oc login pour authentifier vos requêtes. La commande oc login fournit
une authentification et une autorisation basées sur les rôles qui protègent le cluster RHOCP
contre tout accès non autorisé. La syntaxe pour se connecter est la suivante :
[user@host ~]$ oc login cluster-url
Par exemple, dans ce cours, vous pouvez utiliser la commande suivante :
[user@host ~]$ oc login https://api.ocp4.example.com:6443

Username: developer
Password: developer
Login successful.
You don't have any projects. You can try to create a new project, by running
$ oc new-project <projectname>
Welcome to OpenShift! See 'oc help' to get started.
Après vous être authentifié auprès du cluster RHOCP, vous pouvez créer un projet à l’aide de la
commande oc new-project. Les projets permettent d’isoler les ressources de votre application.
Les projets sont des espaces de noms Kubernetes avec des annotations supplémentaires qui
fournissent une étendue multisite pour les applications.
[user@host ~]$ oc new-project myapp
Plusieurs commandes essentielles permettent de gérer les ressources RHOCP et Kubernetes,

comme décrit ici. Sauf indication contraire, les commandes suivantes sont compatibles avec les
interfaces de ligne de commande (CLI) oc et kubectl.
Certaines commandes exigent que l’utilisateur dispose d’un accès administrateur de cluster. La
liste suivante contient plusieurs commandes oc utiles pour les administrateurs de cluster.
oc cluster-info
La commande cluster-info imprime l’adresse du plan de contrôle et d’autres services de
cluster. La commande oc cluster-info dump développe la sortie pour inclure des détails
utiles pour le débogage des problèmes de cluster.
[user@host ~]$ oc cluster-info

Kubernetes control plane is running at https://api.ocp4.example.com:6443
oc api-versions
La structure des ressources de cluster a une version d’API correspondante, affichée par la
commande oc api-versions. La commande imprime les versions d’API prises en charge
sur le serveur, sous la forme « groupe/version ».
Dans l’exemple suivant, le groupe est admissionregistration.k8s.io et la version est

v1 :
70 DO180-OCP4.14-fr-2-20240530
[user@host ~]$ oc api-versions

admissionregistration.k8s.io/v1
oc get clusteroperator
Les opérateurs de cluster fournis par Red Hat servent de base architecturale pour RHOCP.
RHOCP les installe par défaut. Utilisez la commande oc get clusteroperator pour
afficher la liste des opérateurs de cluster :
[user@host ~]$ oc get clusteroperator

NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE ...
authentication 4.14.0 True False False 18d
baremetal 4.14.0 True False False 18d
D’autres commandes utiles sont disponibles pour les utilisateurs standard et les administrateurs :
oc get
Utilisez la commande get pour récupérer des informations sur les ressources dans le projet
sélectionné. En général, cette commande affiche uniquement les principales caractéristiques
des ressources et n’indique pas de détails.
La commande oc get RESOURCE_TYPE affiche un résumé de toutes les ressources du type

spécifié.
Par exemple, la commande suivante renvoie la liste des ressources pod dans le projet en
cours :
[user@host ~]$ oc get pod

NAME READY STATUS RESTARTS AGE
quotes-api-6c9f758574-nk8kd 1/1 Running 0 39m
quotes-ui-d7d457674-rbkl7 1/1 Running 0 67s
Vous pouvez utiliser la commande oc get RESOURCE_TYPE RESOURCE_NAME pour

exporter une définition de ressource. Elle est généralement utilisée pour créer une
sauvegarde ou modifier une définition. L’option -o yaml imprime la représentation de l’objet
au format YAML. Vous pouvez passer au format JSON en fournissant une option -o json.
oc get all
Utilisez la commande oc get all pour récupérer un résumé des composants les plus
importants d’un cluster. Cette commande parcourt les principaux types de ressources pour le
projet en cours et imprime un récapitulatif de leurs informations :
[user@host ~]$ oc get all

NAME DOCKER REPO TAGS UPDATED
is/nginx 172.30.1.1:5000/basic-kubernetes/nginx latest About an hour ago
NAME REVISION DESIRED CURRENT TRIGGERED BY

dc/nginx 1 1 1 config,image(nginx:latest)
NAME DESIRED CURRENT READY AGE

rc/nginx-1 1 1 1 1h
DO180-OCP4.14-fr-2-20240530 71
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE

svc/nginx 172.30.72.75 <none> 80/TCP,443/TCP 1h

po/nginx-1-ypp8t 1/1 Running 0 1h
oc describe
Si les récapitulatifs obtenus à partir de la commande get ne suffisent pas, vous pouvez
utiliser oc describe RESOURCE_TYPE RESOURCE_NAME pour extraire des informations
supplémentaires. Contrairement à la commande get, describe vous permet de parcourir
les différentes ressources par type. Même si la plupart des ressources principales peuvent
être décrites, cette fonction n’est pas disponible pour l’ensemble des ressources. L’exemple
suivant illustre la description d’une ressource de pod :
[user@host ~]$ oc describe mysql-openshift-1-glgrp

Name: mysql-openshift-1-glqrp
Namespace: mysql-openshift
Priority: 0
Node: cluster-worker-1/172.25.250.52
Start Time: Fri, 15 Feb 2019 02:14:34 +0000
Labels: app=mysql-openshift
deployment=mysql-openshift-1
Status: Running
IP: 10.129.0.85
oc explain
Pour en savoir plus sur les champs d’un objet de ressource d’API, utilisez la commande oc
explain. Cette commande décrit la finalité de chaque ressource d’API prise en charge et les
champs qui y sont associés. Vous pouvez également utiliser cette commande pour imprimer la
documentation d’un champ spécifique d’une ressource. Les champs sont identifiés au moyen
d’un identifiant JSONPath. L’exemple suivant imprime la documentation pour le champ
.spec.containers.resources du type de ressource pod :
[user@host ~]$ oc explain pods.spec.containers.resources

KIND: Pod
VERSION: v1
FIELD: resources <ResourceRequiremnts>
DESCRIPTION:
Compute Resources required by this container. Cannot be updated. More info:
https://kubernetes.io/docs/concepts/configuration/manage-resources-
containers/
ResourceRequirements describes the compute resource requirements.
FIELDS:
claims <[]ResourceClaim>
Claims lists the names of resources, defined in spec.resourceClaims, that
are used by this container.
This is an alpha field nd requires enabling the DynamicResourceAllocation

feature gate.
72 DO180-OCP4.14-fr-2-20240530
This field is immutable. It can only be set for containers.
limits <map[string]Quantity>
Limits describes the maximum amount of compute resources allowed. More
info:
containers/
requests <map[string]Quantity>
Requests describes the minimum amount of compute resources required. If
Requests is omitted for a container, it defaults to Limits if that is
explicitly specified, otherwise to an implementation-defined value. Requests
cannot exceed Limits. More info:
containers/
Ajoutez l’indicateur --recursive pour afficher tous les champs d’une ressource sans
description. Les informations relatives à chaque champ sont extraites du serveur au
format OpenAPI.
oc create
Utilisez la commande create pour créer une ressource RHOCP dans le projet en cours.
Cette commande crée des ressources à partir d’une définition de ressource. Cette commande
s’utilise généralement avec la commande oc get RESOURCE_TYPE RESOURCE_NAME -o
yaml pour modifier des définitions. Les développeurs utilisent généralement l’indicateur -f
pour signaler le fichier qui contient la représentation JSON ou YAML d’une ressource RHOCP.
Par exemple, pour créer des ressources à partir du fichier pod.yaml, utilisez la commande
suivante :
[user@host ~]$ oc create -f pod.yaml

pod/quotes-pod created
Les ressources RHOCP au format YAML seront traitées ultérieurement.
oc status
La commande oc status fournit une présentation générale du projet actuel. La commande
affiche les services, les déploiements, les configurations de compilation et les déploiements
actifs. Des informations sur les composants mal configurés sont également affichées. L’option
--suggest affiche des informations supplémentaires sur les problèmes identifiés, le cas
échéant.
oc delete
Utilisez la commande delete pour supprimer une ressource RHOCP existante du projet en
cours. Vous devez spécifier le type et le nom de la ressource.
Par exemple, pour supprimer le pod quotes-ui, utilisez la commande suivante :
[user@host ~]$ oc delete pod quotes-ui

pod/quotes-ui deleted
Une connaissance de base de l’architecture OpenShift est nécessaire ici, car la suppression
de ressources gérées, telles que des pods, entraîne la création automatique de nouvelles
DO180-OCP4.14-fr-2-20240530 73
instances de ces ressources. Quand un projet est supprimé, cela élimine l’intégralité des
ressources et des applications qu’il contient.
Chacune de ces commandes est exécutée dans le projet sélectionné. Pour exécuter des
commandes dans un autre projet, vous devez inclure les options --namespace ou -n.
[user@host ~]$ oc get pods -n openshift-apiserver

apiserver-68c9485699-ndqlc 2/2 Running 2 18d
Consultez les références pour obtenir la liste complète des commandes oc.
Authentification avec OAuth

Pour que les utilisateurs puissent interagir avec RHOCP, ils doivent d’abord s’authentifier auprès
du cluster. La couche d’authentification identifie l’utilisateur associé aux demandes adressées à
l’API RHOCP. Après l’authentification, la couche d’autorisation utilise les informations concernant
l’utilisateur qui émet la demande pour déterminer si elle est autorisée ou non.
Dans OpenShift, un utilisateur est une entité qui peut adresser des demandes à l’API RHOCP. Un
objet RHOCP User représente un acteur auquel des autorisations peuvent être accordées dans le
système en ajoutant des rôles à l’utilisateur ou au groupe de l’utilisateur. Il s’agit généralement du
compte d’un développeur ou d’un administrateur.
Il peut y avoir plusieurs types d’utilisateurs.
Utilisateurs standard
La plupart des utilisateurs RHOCP interactifs sont représentés par ce type d’utilisateur. Un
objet RHOCP User représente un utilisateur standard.
Utilisateurs système
L’infrastructure utilise des utilisateurs système pour interagir avec l’API de manière sécurisée.
Certains utilisateurs système sont créés automatiquement, y compris l’administrateur du
cluster, avec un accès complet. Par défaut, un utilisateur système anonyme est utilisé pour les
demandes non authentifiées.
Comptes de service
Les objets ServiceAccount représentent des comptes de service. RHOCP crée
automatiquement des comptes de service lors de la création d’un projet. Les administrateurs
de projet peuvent créer des comptes de service supplémentaires pour définir l’accès au
contenu de chaque projet.
Chaque utilisateur doit s’authentifier pour accéder à un cluster. Après l’authentification, la

politique détermine ce que l’utilisateur est autorisé à faire.
Note
L’authentification et l’autorisation sont traitées plus en détail dans le cours
« DO280 : Administration de Red Hat OpenShift II : exploitation d’un cluster
Kubernetes de production ».
Le plan de contrôle RHOCP comprend un serveur OAuth intégré. Pour s’authentifier auprès de
l’API, les utilisateurs obtiennent des tokens d’accès OAuth. L’authentification par token est la
seule méthode dont le fonctionnement est garanti avec un cluster OpenShift, étant donné que
74 DO180-OCP4.14-fr-2-20240530
l’authentification unique (SSO) d’entreprise peut remplacer le formulaire de connexion de la

console Web.
Lorsqu’une personne demande un nouveau token OAuth, le serveur OAuth utilise le fournisseur
d’identité configuré pour déterminer l’identité du demandeur. Le serveur OAuth détermine ensuite
l’utilisateur auquel correspond l’identité, crée un token d’accès pour cet utilisateur, puis renvoie le
token à utiliser.
Pour récupérer un token OAuth à l’aide de la console Web OpenShift, accédez à Help > Command
line tools. Le menu Help est représenté par une icône ?.
Sur la page Command Line Tools, accédez à Copy login Command. La page suivante nécessite
que vous vous connectiez avec vos informations d’identification d’utilisateur OpenShift. Accédez
ensuite à Display token. Utilisez la commande sous l’étiquette Log in with this token pour
vous connecter à l’API OpenShift.
Copiez la commande à partir de la console Web et collez-la dans la ligne de commande. La

commande copiée utilise les options --token et --server, comme dans l’exemple suivant.
[user@host ~]$ oc login --token=sha256-BW...rA8 \

--server=https://api.ocp4.example.com:6443
DO180-OCP4.14-fr-2-20240530 75
Références
Pour plus d’informations, reportez-vous au chapitre Getting Started with the
OpenShift CLI (Prise en main de l’interface de ligne de commande OpenShift)
de la documentation CLI Tools (Outils CLI) de Red Hat OpenShift Container
Platform 4.14, à l’adresse
openshift_container_platform/4.14/html-single/cli_tools/index#cli-getting-started
Pour plus d’informations, reportez-vous au chapitre CLI Developer Commands

(Commandes développeur de l’interface de ligne de commande) de la
documentation CLI Tools (Outils CLI) de Red Hat OpenShift Container
Platform 4.14, à l’adresse Reportez-vous à la section
OpenShift CLI Developer Command Reference
openshift_container_platform/4.14/html-single/cli_tools/index#cli-developer-
commands
Kubernetes Documentation - Install and Set Up kubectl on Linux

https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/
(Documentation Kubernetes – Installation et configuration de kubectl sous Linux)
openshift_container_platform/4.14/html-single/authentication_and_authorization/
index#understanding-authentication
76 DO180-OCP4.14-fr-2-20240530
Exercice guidé
Interfaces de ligne de commande

Accédez à un cluster OpenShift à l’aide de la ligne de commande pour obtenir des
informations sur les nœuds et les services du cluster.
Résultats
• Utiliser la console Web OpenShift pour rechercher le fichier d’installation de l’interface de
ligne de commande OpenShift oc.
• Obtenir et utiliser un token à partir de la console Web pour accéder au cluster à partir de la
ligne de commande.
• Identifier les principales différences entre les outils de ligne de commande kubectl et
oc.
• Identifier les principaux composants d’OpenShift et de Kubernetes.
Avant De Commencer
Cette commande permet de s’assurer que toutes les ressources sont disponibles pour cet
exercice.
[student@workstation ~]$ lab start cli-interfaces
Instructions
1. Connectez-vous à la console Web OpenShift en tant qu’utilisateur developer.
Recherchez le fichier d’installation de l’interface de ligne de commande OpenShift oc.

console.apps.ocp4.example.com.
DO180-OCP4.14-fr-2-20240530 77
1.3. Recherchez le fichier d’installation de l’interface de ligne de commande oc. À partir

de la console Web OpenShift, sélectionnez Help > Command line tools. Le menu
Help est représenté par une icône ?.
Le binaire oc est disponible pour plusieurs systèmes d’exploitation et architectures.

Pour chaque système d’exploitation et architecture, le binaire oc contient également
le binaire kubectl.
Note
Il n’est pas nécessaire de télécharger ni d’installer les binaires oc et kubectl, qui
sont déjà installés sur la machine workstation.
2. Téléchargez un token d’autorisation à partir de la console Web. Ensuite, utilisez le token et

la commande oc pour vous connecter au cluster OpenShift.
2.1. Sur la page Command Line Tools, cliquez sur le lien Copy login command.
2.2. Le lien ouvre une page de connexion. Cliquez sur Red Hat Identity Management et
connectez-vous en tant qu’utilisateur developer avec le mot de passe developer.
78 DO180-OCP4.14-fr-2-20240530
2.3. Une page Web est affichée. Cliquez sur le lien Display token pour afficher votre token
API et la commande de connexion (login).
2.4. Copiez la commande oc login dans votre presse-papiers. Ouvrez une fenêtre de
terminal, puis utilisez la commande copiée pour vous connecter au cluster à l’aide de
votre token.
[student@workstation ~]$ oc login --token=sha256-fypX...Ot6A \

--server=https://api.ocp4.example.com:6443
Logged into "https://api.ocp4.example.com:6443" as "developer" using the token
provided.
3. Comparez les commandes disponibles pour kubectl et oc.
3.1. Utilisez la commande help pour lister et passer en revue les commandes disponibles
pour kubectl.
[student@workstation ~]$ kubectl help

kubectl controls the Kubernetes cluster manager.
Find more information at: https://kubernetes.io/docs/reference/kubectl/
Basic Commands (Beginner):

create Create a resource from a file or from stdin
expose Take a replication controller, service, deployment or pod and
expose it as a new Kubernetes service
run Run a particular image on the cluster
set Set specific features on objects
Basic Commands (Intermediate):

explain Get documentation for a resource
get Display one or many resources
DO180-OCP4.14-fr-2-20240530 79
edit Edit a resource on the server

delete Delete resources by file names, stdin, resources and names, or
by resources and label selector
...output omitted....
Notez que la commande kubectl ne fournit pas de commande login.
3.2. Examinez les sous-commandes et options disponibles pour la commande kubectl

create à l’aide de l’option --help.
[student@workstation ~]$ kubectl create --help

Examples:
kubectl create -f ./pod.json
Available Commands:
clusterrolebinding Create a cluster role binding for a particular cluster
role
configmap Create a config map from a local file, directory or
literal value
cronjob Create a cron job with the specified name
deployment Create a deployment with the specified name
Options:
--allow-missing-template-keys=true:
If true, ignore any errors in templates when a field or map key is missing in the
template. Only applies to
golang and jsonpath output formats.
--dry-run='none':
Must be "none", "server", or "client". If client strategy, only print the object
that would be sent, without
sending it. If server strategy, submit server-side request without persisting the
resource.
Usage:
kubectl create -f FILENAME [options]
Use "kubectl create <command> --help" for more information about a given command.
Use "kubectl options" for a list of global command-line options (applies to all
commands).
Vous pouvez utiliser l’option --help avec n’importe quelle commande kubectl.
L’option --help fournit des informations sur une commande, y compris les sous-
commandes et options disponibles, ainsi que sa syntaxe.
3.3. Listez et passez en revue les commandes disponibles pour le binaire oc à l’aide de la
commande help.
80 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ oc help

OpenShift Client
This client helps you develop, build, deploy, and run your applications on any
OpenShift or Kubernetes cluster. It also includes the administrative
commands for managing a cluster under the 'adm' subcommand.
Basic Commands:
login Log in to a server
new-project Request a new project
new-app Create a new application
status Show an overview of the current project
project Switch to another project
projects Display existing projects
explain Get documentation for a resource
La commande oc prend en charge les mêmes fonctionnalités que la commande

kubectl. La commande oc fournit des commandes supplémentaires pour la prise
en charge native d’un cluster OpenShift. La commande new-project, par exemple,
crée dans le cluster OpenShift un projet qui est un espace de noms Kubernetes. La
commande new-app est spécifique à la commande oc. Elle crée des applications en
utilisant le code source existant ou des images prédéfinies.
3.4. Utilisez l’option --help avec la commande oc create pour afficher les sous-
commandes et options disponibles.
[student@workstation ~]$ oc create --help

Examples:
oc create -f ./pod.json
Available Commands:
build Create a new build
clusterresourcequota Create a cluster resource quota
clusterrolebinding Create a cluster role binding for a particular cluster
role
configmap Create a config map from a local file, directory or
literal value
cronjob Create a cron job with the specified name
deployment Create a deployment with the specified name
deploymentconfig Create a deployment config with default options that uses
a given image
Options:
--allow-missing-template-keys=true:
DO180-OCP4.14-fr-2-20240530 81
If true, ignore any errors in templates when a field or map key is missing in the
template. Only applies to
golang and jsonpath output formats.
--dry-run='none':
Must be "none", "server", or "client". If client strategy, only print the object
that would be sent, without
sending it. If server strategy, submit server-side request without persisting the
resource.
Usage:
oc create -f FILENAME [options]
....output omitted....
La commande oc create inclut les mêmes sous-commandes et options que

kubectl create, et fournit des sous-commandes supplémentaires pour les
ressources OpenShift. Par exemple, vous pouvez utiliser la commande oc create
pour créer des ressources OpenShift telles qu’une configuration de déploiement, une
route et un flux d’images.
4. Utilisez le terminal pour identifier les composants et les ressources Kubernetes d’un cluster
OpenShift. Sauf indication contraire, toutes les commandes sont disponibles pour oc et
kubectl.
4.1. Dans un terminal, utilisez la commande oc login pour vous connecter au cluster
en tant qu’utilisateur admin avec le mot de passe redhatocp. Les utilisateurs
de cluster standard, tels que l’utilisateur developer, ne peuvent pas lister les
ressources au niveau d’une étendue de cluster.
[student@workstation ~]$ oc login -u admin -p redhatocp

Login successful
4.2. Identifiez la version du cluster à l’aide de la commande version.
[student@workstation ~]$ oc version

Client Version: 4.14.0
Kustomize Version: v5.0.1
Server Version: 4.14.0
Kubernetes Version: v1.27.6+f67aeb3
4.3. Utilisez la commande cluster-info pour identifier l’URL du plan de contrôle

Kubernetes.
[student@workstation ~]$ oc cluster-info

Kubernetes control plane is running at https://api.ocp4.example.com:6443
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
4.4. Identifiez les versions d’API prises en charge à l’aide de la commande api-
versions.
82 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ oc api-versions

apiextensions.k8s.io/v1
apiregistration.k8s.io/v1
apiserver.openshift.io/v1
apps.openshift.io/v1
apps/v1
4.5. Listez les opérateurs de cluster à l’aide de la commande get clusteroperator.
[student@workstation ~]$ oc get clusteroperator

NAME VERSION AVAILABLE PROGRESSING DEGRADED
SINCE ...
authentication 4.14.0 True False False 18d
cloud-controller-manager 4.14.0 True False False 18d
cloud-credential 4.14.0 True False False 18d
cluster-autoscaler 4.14.0 True False False 18d
config-operator 4.14.0 True False False 18d
console 4.14.0 True False False 18d
control-plane-machine-set 4.14.0 True False False 18d
csi-snapshot-controller 4.14.0 True False False 18d
dns 4.14.0 True False False 5h24m
etcd 4.14.0 True False False 18d
image-registry 4.14.0 True False False 18d
ingress 4.14.0 True False False 18d
4.6. Utilisez la commande get pour lister les pods dans le projet openshift-api.
Spécifiez le projet avec l’option -n.
[student@workstation ~]$ oc get pods -n openshift-apiserver

apiserver-68c9485699-ndqlc 2/2 Running 6 18d
4.7. Utilisez la commande oc status pour récupérer l’état des ressources dans le projet
openshift-authentication.
[student@workstation ~]$ oc status -n openshift-authentication

Warning: apps.openshift.io/v1 DeploymentConfig is deprecated in v4.14+,
unavailable in v4.10000+
In project openshift-authentication on server https://api.ocp4.example.com:6443
https://oauth-openshift.apps.ocp4.example.com (passthrough) to pod port 6443 (svc/

oauth-openshift)
deployment/oauth-openshift deploys quay.io/openshift-release-dev/ocp-v4.0-art-
dev@sha256:64e6...de42
deployment #7 running for 2 weeks - 1 pod
deployment #6 deployed 2 weeks ago
DO180-OCP4.14-fr-2-20240530 83

4.8. Utilisez la commande explain pour lister la description et les champs disponibles
pour les ressources services.
[student@workstation ~]$ oc explain services

KIND: Service
VERSION: v1
DESCRIPTION:
Service is a named abstraction of software service (for example, mysql)
consisting of local port (for example 3306) that the proxy listens on, and
the selector that determines which pods will answer requests sent through
the proxy.
FIELDS:
apiVersion <string>
object. Servers should convert recognized schemas to the latest internal
value, and may reject unrecognized values.
4.9. Utilisez la commande get pour lister les nœuds de cluster.
[student@workstation ~]$ oc get nodes

NAME STATUS ROLES AGE VERSION
master01 Ready control-plane,master,worker 18d v1.27.6+f67aeb3
Il existe un seul nœud dans le cluster.
Fin
[student@workstation ~]$ lab finish cli-interfaces
84 DO180-OCP4.14-fr-2-20240530
Examen des ressources Kubernetes
Résultats
• Interroger, formater et filtrer les attributs des ressources Kubernetes.
Ressources Kubernetes et OpenShift

Kubernetes utilise des objets de ressource d’API pour représenter l’état prévu de tous les éléments
du cluster. Toutes les tâches d’administration nécessitent la création, l’affichage et la modification
des ressources d’API. Utilisez la commande oc api-resources pour afficher les ressources
Kubernetes.
Note
Les commandes oc présentées dans les exemples sont identiques aux commandes
kubectl équivalentes.
[user@host ~]$ oc api-resources

NAME SHORTNAMES APIVERSION NAMESPACED KIND
bindings v1 true Binding
componentstatuses cs v1 false ComponentStatus
configmaps cm v1 true ConfigMap
endpoints ep v1 true Endpoints
daemonsets ds apps/v1 true DaemonSet
deployments deploy apps/v1 true Deployment
replicasets rs apps/v1 true ReplicaSet
statefulsets sts apps/v1 true StatefulSet
L’utilisation du SHORTNAME d’un composant permet de simplifier la saisie de longues commandes

CLI. Par exemple, vous pouvez utiliser oc get cm au lieu de oc get configmaps.
La colonne APIVERSION divise les objets en groupes d’API. La colonne utilise le format <API-
Group>/<API-Version>. L’objet API-Group est vide pour les objets de ressources principales
Kubernetes.
Il existe de nombreuses ressources Kubernetes dans le contexte d’un espace de noms Kubernetes.
Les espaces de noms Kubernetes et les projets OpenShift sont en grande partie similaires. Il existe
toujours une relation 1:1 entre un espace de noms et un projet OpenShift.
KIND est le type de schéma de ressource Kubernetes formel.
La commande oc api-resources peut effectuer un filtrage plus poussé de la sortie avec des
options qui agissent sur les données.
DO180-OCP4.14-fr-2-20240530 85
Options de la commande api-resources
Exemple d’option Description
--namespaced=true Si l’option est définie sur « false », elle renvoie des ressources
sans espace de noms. Sinon, elle renvoie des ressources avec
espace de noms.
--api-group apps Se limiter aux ressources du groupe d’API spécifié. Utilisez --

api-group='' pour afficher les ressources principales.
--sort-by name Si elle n’est pas vide, cette commande trie la liste des
ressources à l’aide du champ spécifié. Le champ peut être
« name » ou « kind ».
Par exemple, utilisez la commande oc api-resources suivante pour afficher toutes les
ressources namespaced du groupe d’API apps, triées par name.
[user@host ~]$ oc api-resources --namespaced=true --api-group apps --sort-by name

controllerrevisions apps/v1 true ControllerRevision
Chaque ressource contient des champs qui l’identifient ou qui décrivent sa configuration prévue.
Utilisez la commande oc explain pour obtenir des informations sur les champs valides pour un
objet. Par exemple, exécutez la commande oc explain pod pour obtenir des informations sur
les champs possibles de l’objet pod.
[user@host ~]$ oc explain pod

KIND: Pod
VERSION: v1
DESCRIPTION:
FIELDS:
apiVersion <string>
...
kind <string>
Kind is a string value representing the REST resource this object
...
metadata <ObjectMeta>
Standard object's metadata. More info:
...
86 DO180-OCP4.14-fr-2-20240530
spec <PodSpec>
Specification of the desired behavior of the pod. More info:
Chaque ressource Kubernetes contient les champs kind, apiVersion, spec et status.
Cependant, lorsque vous créez une définition d’objet, il n’est pas nécessaire de fournir le champ
status. À la place, Kubernetes génère le champ status, et liste des informations telles que l’état
d’exécution et l’état de préparation. Le champ status est utile pour résoudre une erreur ou pour
vérifier l’état actuel d’une ressource.
Vous pouvez utiliser le chemin d’accès YAML à un champ et la notation par points pour obtenir
des informations sur un champ en particulier. Par exemple, la commande oc explain suivante
affiche des informations détaillées pour les champs pod.spec.
[user@host ~]$ oc explain pod.spec

KIND: Pod
VERSION: v1
FIELD: spec <PodSpec>
DESCRIPTION:
Specification of the desired behavior of the pod. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-
conventions.md#spec-and-status
PodSpec is a description of a pod.
FIELDS:
activeDeadlineSeconds <integer>
Optional duration in seconds the pod may be active on the node relative to
Les principaux types de ressources Kubernetes ci-dessous peuvent être créés et configurés à
l’aide d’un fichier manifeste YAML ou JSON, ou en utilisant des outils de gestion OpenShift :
Pods (pod)
Les pods représentent un ensemble de conteneurs qui partagent des ressources, telles que
des adresses IP et des volumes de stockage persistants. Il s’agit de la principale unité de
travail pour Kubernetes.
Services (svc)
Ils définissent une combinaison IP/port unique qui fournit l’accès à un pool de pods. Par
défaut, les services connectent des clients à des pods à tour de rôle.
ReplicaSet (rs)
Assurez-vous qu’un nombre spécifié de réplicas de pod est en cours d’exécution à un moment
donné.
Volumes persistants (pv)

Définissent les zones de stockage que les pods Kubernetes doivent utiliser.
Revendications de volume persistant (pvc)

Représentent une demande de stockage adressée par un pod. Les PVC relient un PV à un pod
afin que ses conteneurs puissent utiliser le stockage provisionné, généralement en montant le
stockage dans le système de fichiers du conteneur.
DO180-OCP4.14-fr-2-20240530 87
ConfigMaps (cm) et Secrets

Contiennent un ensemble de clés et de valeurs pouvant être utilisées par d’autres ressources.
Les ConfigMaps et Secrets centralisent les valeurs de configuration utilisées par plusieurs
ressources. Les Secrets diffèrent des ConfigMaps en ce sens que les valeurs des Secrets sont
toujours codées (et non pas chiffrées) et que leur accès est limité à un nombre moins élevé
d’utilisateurs autorisés.
Deployment (deploy)
Représentation d’un ensemble de conteneurs inclus dans un pod et des stratégies de
déploiement à utiliser. Un objet deployment contient la configuration à appliquer à
tous les conteneurs de chaque réplica de pod, tels que l’image de base, les balises, les
définitions de stockage et les commandes à exécuter au démarrage des conteneurs. Bien
que les réplicas Kubernetes puissent être créés de manière autonome dans OpenShift, ils
le sont généralement par des ressources de niveau supérieur, telles que des contrôleurs de
déploiement.
Red Hat OpenShift Container Platform (RHOCP) ajoute les principaux types de ressources ci-
dessous à Kubernetes :
BuildConfig (bc)
Définit un processus à exécuter dans le projet OpenShift. La fonction Source-to-Image (S2I)
d’OpenShift utilise une BuildConfig pour compiler une image de conteneur à partir d’un code
source d’application stocké dans un référentiel Git. Une bc collabore avec une dc pour fournir
des workflows CI/CD extensibles.
DeploymentConfig (dc)
OpenShift 4.5 a introduit le concept de ressource Deployment pour remplacer la
configuration par défaut DeploymentConfig pour les pods. Les deux concepts représentent
un ensemble de conteneurs inclus dans un pod, ainsi que les stratégies de déploiement à
utiliser.
L’objet Deployment fait office de version améliorée de l’objet DeploymentConfig. Voici

quelques remplacements fonctionnels entre les deux objets :
• Les objets Deployment ne prennent plus en charge la restauration automatique ni les

scripts automatiques de cycle de vie.
• Chaque modification du modèle de pod utilisé par les objets Deployment déclenche
automatiquement un nouveau déploiement.
• Le processus de déploiement d’un objet Deployment peut être mis en pause à tout
moment sans affecter le processus du programme de déploiement.
• Un objet Deployment peut avoir autant de jeux de réplicas actifs que l’utilisateur
le souhaite et réduire (scale-down) les réplicas précédents. En revanche, l’objet
DeploymentConfig ne peut avoir que deux jeux de réplication actifs en même temps.
Bien que les objets Deployment remplacent par défaut les objets DeploymentConfig
obsolètes dans OpenShift 4.12 et versions ultérieures, vous pouvez toujours utiliser des
objets DeploymentConfig si vous avez besoin d’une de leurs fonctions spécifiques,
mais ils ne sont pas recommandés pour les nouvelles installations. Dans ce cas, vous devez
spécifier le type d’objet lors de la création d’une application en incluant l’indicateur --as-
deployment-config.
Routes
Représentent un nom d’hôte DNS reconnu par le routeur OpenShift comme un point d’entrée
pour les applications et les microservices.
88 DO180-OCP4.14-fr-2-20240530
Structure des ressources

Presque tous les objets Kubernetes contiennent deux champs d’objets imbriqués qui régissent
la configuration de l’objet : l’objet spec et l’objet status. L’objet spec décrit l’état prévu de la
ressource, tandis que l’objet status décrit l’état actuel. Vous spécifiez la section spec de la
ressource lors de la création de l’objet. Les contrôleurs Kubernetes mettent à jour en continu
le status de l’objet pendant toute sa durée de vie. Le plan de contrôle Kubernetes gère
continuellement et activement l’état réel de chaque objet pour qu’il corresponde à l’état souhaité
que vous avez indiqué.
Le champ status utilise une collection d’objets de ressource condition avec les champs
suivants.
Champs de ressource de condition
Champ Exemple Description
Type ContainersReady Type de la condition
Status Faux État de la condition
Reason RequirementsNotMet Champ facultatif permettant de fournir

des informations supplémentaires
Message 2/3 des conteneurs sont Description textuelle facultative de la

en cours d’exécution condition
LastTransitionTime 2023-03-07T18:05:28Z Date et heure de la dernière modification

des conditions
Par exemple, dans Kubernetes, un objet Deployment peut représenter une application qui
s’exécute sur votre cluster. Lorsque vous créez un objet Deployment, vous pouvez configurer
l’objet spec du déploiement pour indiquer que vous souhaitez que trois réplicas de l’application
soient en cours d’exécution. Kubernetes lit l’objet spec du déploiement et démarre trois instances
de l’application que vous avez choisie, puis met à jour le champ status pour qu’il corresponde
à votre objet spec. Si l’une de ces instances échoue, Kubernetes effectue une correction en
réponse à la différence entre les objets spec et status ; dans ce cas, pour démarrer une instance
de remplacement.
D’autres champs courants fournissent des informations de base en plus des champs spec et
status d’un objet Kubernetes.
Champs de ressources d’API
Champ Description
apiVersion Identificateur de la version du schéma d’objet.
kind Identificateur de schéma.
metadata.name Crée une étiquette avec une clé name que d’autres ressources
dans Kubernetes peuvent utiliser à des fins de recherche.
metadata.namespace Espace de noms ou projet RHOCP dans lequel se trouve la

ressource.
DO180-OCP4.14-fr-2-20240530 89
Champ Description
metadata.labels Paires clé-valeur permettant de connecter des métadonnées

d’identification à des objets Kubernetes.
Dans Kubernetes, les ressources sont constituées de plusieurs objets. Ces objets définissent l’état
prévu d’une ressource. Lorsque vous créez ou modifiez un objet, vous créez un enregistrement
persistant de l’état prévu. Kubernetes lit l’objet et modifie l’état actuel en conséquence.
Tous les objets RHOCP et Kubernetes peuvent être représentés sous la forme d’une
structure JSON ou YAML. Prenons l’exemple de l’objet pod suivant au format YAML :
apiVersion: v1
kind: Pod
metadata:
name: wildfly
namespace: my_app
labels:
name: wildfly
spec:
containers:
- resources:
limits:
cpu: 0.5
image: quay.io/example/todojee:v1
name: wildfly
ports:
- containerPort: 8080
name: wildfly
env:
- name: MYSQL_DATABASE
value: items
- name: MYSQL_USER
value: user1
- name: MYSQL_PASSWORD
value: mypa55
...object omitted...
status:
conditions:
- lastProbeTime: null
lastTransitionTime: "2023-08-19T12:59:22Z"
status: "True"
type: PodScheduled
Identificateur de la version du schéma d’objet.
Identificateur de schéma. Dans cet exemple, l’objet est conforme au schéma du pod.
Métadonnées d’une ressource donnée, telles que des annotations, des étiquettes, un nom et
un espace de noms.
Nom unique pour un pod dans Kubernetes qui permet aux administrateurs d’exécuter des
commandes sur celui-ci.
90 DO180-OCP4.14-fr-2-20240530
Espace de noms ou projet RHOCP dans lequel réside la ressource.
Crée une étiquette avec une clé name que d’autres ressources dans Kubernetes
(généralement un service) peuvent utiliser à des fins de recherche.
Définit la configuration de l’objet pod ou l’état prévu de la ressource.
Définit le nom de l’image du conteneur.
Nom du conteneur à l’intérieur d’un pod. Les noms des conteneurs sont importants pour les
commandes oc lorsqu’un pod comporte plusieurs conteneurs.
Attribut dépendant du conteneur permettant d’identifier le port utilisé par ce dernier.
Définit une collection de variables d’environnement.
État actuel de l’objet. Kubernetes fournit ce champ où sont listées des informations telles que
l’état d’exécution, l’état de préparation et des images de conteneur.
Les étiquettes sont des paires clé-valeur que vous définissez dans le chemin de l’objet
.metadata.labels, par exemple :
kind: Pod
apiVersion: v1
metadata:
name: example-pod
labels:
app: example-pod
group: developers
L’exemple précédent contient les étiquettes app=example-pod et group=developers. Les

développeurs utilisent souvent des étiquettes pour cibler un ensemble d’objets à l’aide de l’option
-l ou --selector. Par exemple, la commande oc get suivante liste les pods qui contiennent
l’étiquette group=developers :
[user@host ~]$ oc get pod --selector group=developers

example-pod-6c9f758574-7fhg 1/1 Running 5 11d
Sorties des commandes

Les commandes CLI kubectl et oc fournissent de nombreuses options de formatage de la
sortie. Par défaut, de nombreuses commandes affichent un petit sous-ensemble des champs
les plus utiles pour le type de ressource donné sous forme de tableau. Beaucoup de commandes
prennent en charge une option -o wide qui affiche des champs supplémentaires.
Champs tabulaires
oc get pods oc get pods -o wide Exemple de valeur
NAME NAME example-pod
READY READY 1/1
DO180-OCP4.14-fr-2-20240530 91
oc get pods oc get pods -o wide Exemple de valeur
STATUS STATUS Running
RESTARTS RESTARTS 5
ÂGE ÂGE 11d
IP 10.8.0.60
NODE master01
NOMINATED NODE <none>
READINESS GATES <none>
Pour présenter tous les champs associés à une ressource, la sous-commande describe affiche
une description détaillée de la ressource sélectionnée et des ressources associées. Vous pouvez
sélectionner un seul objet par son nom, ou tous les objets de ce type, ou fournir un préfixe de nom
ou un sélecteur d’étiquettes.
Par exemple, la commande suivante recherche d’abord une correspondance exacte sur l’objet
TYPE et l’objet NAME-PREFIX. Si une telle ressource n’existe pas, la commande génère des détails
pour chaque ressource de ce type avec un nom et un préfixe NAME_PREFIX.
[user@host ~]$ oc describe TYPE NAME-PREFIX
La sous-commande describe génère une sortie lisible et détaillée. Cependant, le format

de la sortie describe peut changer entre les versions et n’est donc pas recommandé pour
le développement de scripts. Tous les scripts qui reposent sur la sortie de la sous-commande
describe risquent de s’arrêter après la mise à jour d’une version.
Kubernetes fournit des options de sortie aux formats YAML et JSON qui sont adaptées à l’analyse
et à l’écriture de scripts.
Sortie YAML
L’option -o yaml fournit une sortie au format YAML qui peut être analysée et qui est toujours
lisible par l’utilisateur.
[user@host ~]$ oc get pods -o yaml

apiVersion: v1
items:
- apiVersion: v1
kind: Pod
metadata:
annotations:
Note
La documentation de référence fournit une présentation plus détaillée du
format YAML.
92 DO180-OCP4.14-fr-2-20240530
Vous pouvez utiliser n’importe quel outil capable de traiter des documents YAML pour filtrer la
sortie YAML sur le champ que vous avez choisi. Par exemple, vous pouvez utiliser l’outil yq dans
https://mikefarah.gitbook.io/yq/ pour traiter les fichiers YAML et JSON.
Le processeur yq utilise une notation avec des points pour séparer les noms des champs dans
une requête. L’exemple suivant dirige la sortie YAML vers la commande yq pour analyser le champ
podIP.
[user@host ~]$ oc get pods -o yaml | yq r - 'items[0].status.podIP'

10.8.0.60
Le [0] indiqué dans cet exemple spécifie le premier index dans le tableau items.
Note
L’environnement de l’atelier inclut la version 3.3.0 de la commande yq, que ces
exemples utilisent. Les versions ultérieures de la commande yq présentent des
incompatibilités avec les versions antérieures. Le contenu de ce cours peut ne pas
fonctionner avec d’autres versions.
Note
Un autre outil nommé yq est accessible à l’adresse https://kislyuk.github.io/yq/. Les
deux outils yq ne sont pas compatibles ; les commandes conçues pour l’un d’entre
eux ne fonctionnent pas avec l’autre.
Sortie JSON
Kubernetes utilise le format JSON en interne pour traiter les objets de ressource. Utilisez l’option
-o json pour afficher une ressource au format JSON.
[user@host ~]$ oc get pods -o json

{
"apiVersion": "v1",
"items": [
{
"apiVersion": "v1",
"kind": "Pod",
"metadata": {
"annotations": {
Vous pouvez utiliser d’autres outils pour traiter les documents JSON, tels que l’outil jq à l’adresse
https://jqlang.github.io/jq/. Comme pour le processeur yq, utilisez le processeur jq et la
notation par points sur les champs pour interroger des informations spécifiques de la sortie au
format JSON.
[user@host ~]$ oc get pods -o json | jq '.items[0].status.podIP'

"10.8.0.60"
.items[].status.podIP aurait également pu être utilisé dans cet exemple pour la chaîne de
requête. Les crochets vides indiquent à l’outil jq d’exécuter la requête sur tous les éléments.
DO180-OCP4.14-fr-2-20240530 93
Sortie personnalisée
Kubernetes fournit un format de sortie personnalisé qui allie la facilité d’extraction des données via
des requêtes de style jq à un format de sortie tabulaire. Utilisez l’option -o custom-columns
avec des paires <column name> : <jq query string> séparées par des virgules.
[user@host ~]$ oc get pods \

-o custom-columns=PodName:".metadata.name",\
ContainerName:"spec.containers[].name",\
Phase:"status.phase",\
IP:"status.podIP",\
Ports:"spec.containers[].ports[].containerPort"
PodName ContainerName Phase IP Ports
myapp-77fb5cd997-xplhz myapp Running 10.8.0.60 <none>
Kubernetes prend également en charge l’utilisation d’expressions JSONPath. JSONPath est un

langage de requête pour JSON. Les expressions JSONPath font référence à une structure de
données JSON ; elles filtrent et extraient les champs formatés des objets JSON.
Dans l’exemple suivant, l’expression JSONPath utilise l’opérateur range pour parcourir la liste des
pods afin d’extraire le nom du pod, son adresse IP et les ports affectés.

-o jsonpath='{range .items[]}{"Pod Name: "}{.metadata.name}
{"IP: "}{.status.podIP}
{"Ports: "}{.spec.containers[].ports[].containerPort}{"\n"}{end}'
Pod Name: myapp-77fb5cd997-xplhz
IP: 10.8.0.60
Ports:
Vous pouvez personnaliser le format de la sortie avec des modèles Go, que le langage de
programmation Go utilise. Utilisez l’option -o go-template suivie d’un modèle Go, où les
expressions Go sont placées entre des accolades doubles, {{ }}.

-o go-template='{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}'
myapp-77fb5cd997-xplhz
94 DO180-OCP4.14-fr-2-20240530
Références
Pour plus d’informations, reportez-vous au chapitre OpenShift CLI (oc) (CLI
OpenShift (oc)) de la documentation CLI Tools (Outils CLI) de Red Hat OpenShift
Container Platform 4.14, disponible à l’adresse
openshift_container_platform/4.14/html-single/cli_tools/index#cli-using-cli_cli-
developer-commands
Pour plus d’informations sur les colonnes personnalisées, reportez-vous à la section

oc get de la documentation CLI Tools (Outils CLI) de Red Hat OpenShift Container
openshift_container_platform/4.14/html-single/cli_tools/index#cli-using-cli_cli-
developer-commands
Pour une introduction plus détaillée sur le format YAML, consultez le chapitre YAML
in a Nutshell dans la documentation Red Hat Enterprise Linux Atomic Host 7 Getting
Started with Kubernetes, disponible à l’adresse
red_hat_enterprise_linux_atomic_host/7/html-single/
getting_started_with_kubernetes/index#yaml_in_a_nutshell
Les détails des étiquettes et des sélecteurs sont disponibles dans la section
Working with Kubernetes Objects (Utilisation d’objets Kubernetes) de la
documentation Kubernetes – Labels and Selectors
https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
Les détails des objets Kubernetes sont disponibles dans la section Understanding
Kubernetes Objects (Présentation des objets Kubernetes) de la
documentation Kubernetes – Understanding Kubernetes Objects
https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-
objects/
Les détails de la sortie de la commande sont disponibles dans la section Get de la

documentation Kubernetes – Getting Started
https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands
Pour plus d’informations sur les opérateurs et la syntaxe JSONPath, consultez la

documentation Kubernetes – JSONPath Support
https://kubernetes.io/docs/reference/kubectl/jsonpath/
Pour plus d’informations sur les modèles et la syntaxe Go, consultez la

documentation sur les
modèles Go
https://pkg.go.dev/text/template
.
DO180-OCP4.14-fr-2-20240530 95
Exercice guidé
Examen des ressources Kubernetes

Vérifiez l’état d’un cluster OpenShift en interrogeant ses types de ressources reconnus et
leurs schémas, et en extrayant des informations des ressources Kubernetes qui sont liées à
des services de cluster OpenShift.
Résultats
• Lister et expliquer les ressources d’API prises en charge pour un cluster.
• Identifier les ressources de groupes d’API spécifiques.
• Formater les sorties de commande en YAML et JSON.
• Utiliser des filtres pour analyser les sorties de commande.
• Utiliser JSONPath et des colonnes personnalisées pour extraire des informations des
ressources.
Avant De Commencer
pour préparer votre système pour cet exercice. Cette commande permet de s’assurer que
le cluster est accessible et que toutes les ressources sont disponibles pour cet exercice. Elle
crée également une application myapp dans le projet cli-resources.
[student@workstation ~]$ lab start cli-resources
Instructions
1. Connectez-vous au cluster OpenShift en tant qu’utilisateur developer avec le mot de
passe developer. Sélectionnez le projet cli-resources.
1.1. Connectez-vous au cluster OpenShift.

Login successful.
1.2. Définissez le projet cli-resources comme projet actif.
[student@workstation ~]$ oc project cli-resources

2. Affichez la liste des types de ressources de cluster disponibles à l’aide de la commande

api-resources. Utilisez ensuite des filtres pour lister les ressources avec et sans espace
de noms.
96 DO180-OCP4.14-fr-2-20240530
2.1. Affichez la liste des types de ressources disponibles à l’aide de la commande api-
resources.
[student@workstation ~]$ oc api-resources

events ev v1 true Event
limitranges limits v1 true LimitRange
namespaces ns v1 false Namespace
nodes no v1 false Node
persistentvolumeclaims pvc v1 true
PersistentVolumeClaim
persistentvolumes pv v1 false PersistentVolume
pods po v1 true Pod
cronjobs cj batch/v1 true CronJob
jobs batch/v1 true Job
La commande api-resources imprime les ressources d’API prises en charge, y

compris les noms de ressources, les noms courts disponibles et les versions d’API.
Vous pouvez utiliser le champ APIVERSIONS pour déterminer le groupe d’API
qui fournit la ressource. Le champ affiche le groupe, suivi de la version d’API de la
ressource. Par exemple, le type de ressource jobs est fourni par le groupe d’API
batch et v1 est la version d’API de la ressource.
2.2. Utilisez l’option --namespaced pour limiter la sortie de la commande api-

resources aux ressources avec espace de noms.
Déterminez ensuite le nombre de ressources avec espace de noms disponibles.
Utilisez l’option -o name pour lister les noms de ressources, puis dirigez la sortie vers
la commande wc -l.
[student@workstation ~]$ oc api-resources --namespaced

pods po v1 true Pod
podtemplates v1 true PodTemplate
replicationcontrollers rc v1 true
ReplicationController
resourcequotas quota v1 true ResourceQuota
secrets v1 true Secret
DO180-OCP4.14-fr-2-20240530 97
[student@workstation ~]$ oc api-resources --namespaced -o name | wc -l
113
Le cluster comporte 113 types de ressources de cluster avec espace de noms, telles
que pods, deployments et services.
2.3. Limitez la sortie de la commande api-resources aux ressources sans espace de

noms.
Déterminez ensuite le nombre de ressources sans espace de noms disponibles. Pour
lister les noms de ressources, utilisez l’option -o name, puis dirigez la sortie vers la
commande wc -l.
[student@workstation ~]$ oc api-resources --namespaced=false

NAME SHORTNAMES APIVERSION ...
componentstatuses cs v1 ...
namespaces ns v1 ...
nodes no v1 ...
persistentvolumes pv v1 ...
mutatingwebhookconfigurations admissionregistration.k8s.io/v1 ...
validatingwebhookconfigurations admissionregistration.k8s.io/v1 ...
customresourcedefinitions crd,crds apiextensions.k8s.io/v1 ...
[student@workstation ~]$ oc api-resources --namespaced=false -o name | wc -l
118
Le cluster comporte 118 types de ressources de cluster sans espace de noms, telles
que nodes, images et project.
3. Identifiez et expliquez les types de ressources de cluster disponibles fournis par le groupe
d’API principal. Ensuite, décrivez une ressource du groupe d’API principal dans le projet
cli-resources.
3.1. Filtrez la sortie de la commande api-resources pour afficher uniquement les

ressources du groupe d’API principal. Utilisez l’option --api-group et définissez ''
comme valeur.
[student@workstation ~]$ oc api-resources --api-group ''

persistentvolumes pv v1 false PersistentVolume
pods po v1 true Pod
podtemplates v1 true PodTemplate
replicationcontrollers rc v1 true
ReplicationController
resourcequotas quota v1 true ResourceQuota
98 DO180-OCP4.14-fr-2-20240530
secrets v1 true Secret

serviceaccounts sa v1 true ServiceAccount
services svc v1 true Service
Le groupe d’API principal fournit plusieurs types de ressources, tels que des nœuds,
des événements et des pods.
3.2. Utilisez la commande explain pour afficher une description et les champs
disponibles pour le type de ressource pods.
[student@workstation ~]$ oc explain pods

KIND: Pod
VERSION: v1
DESCRIPTION:
FIELDS:
apiVersion <string>
value, and may reject unrecognized values. More info:
3.3. Listez tous les pods du projet cli-resources.
[student@workstation ~]$ oc get pods

myapp-54fcdcd9d7-2h5vx 1/1 Running 0 4m25s
Il existe un seul pod dans le projet cli-resources. Le nom du pod peut être
différent dans votre sortie.
3.4. Utilisez la commande describe pour afficher la configuration et les événements du

pod. Spécifiez le nom du pod de l’étape précédente.
[student@workstation ~]$ oc describe pod myapp-54fcdcd9d7-2h5vx

Name: myapp-54fcdcd9d7-2h5vx
Namespace: cli-resources
Status: Running
IP: 10.8.0.127
IPs:
IP: 10.8.0.127
Controlled By: ReplicaSet/myapp-54fcdcd9d7
Containers:
myapp:
Container ID: cri-o://e0da...669d
Image: registry.ocp4.example.com:8443/ubi8/httpd-24:1-215
Image ID: registry.ocp4.example.com:8443/ubi8/
httpd-24@sha256:91ad...fd83
Limits:
DO180-OCP4.14-fr-2-20240530 99
cpu: 500m
memory: 128Mi
Requests:
cpu: 500m
memory: 128Mi
Environment: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 10m default-scheduler Successfully assigned cli-
resources/myapp-54fcdcd9d7-2h5vx to master01
....output omitted...
3.5. Récupérez les détails du pod dans un format structuré. Utilisez la commande get
et spécifiez la sortie au format YAML. Comparez les résultats de la commande
describe à ceux de la commande get.
[student@workstation ~]$ oc get pod myapp-54fcdcd9d7-2h5vx -o yaml

apiVersion: v1
kind: Pod
metadata:
annotations:
labels:
app: myapp
pod-template-hash: 54fcdcd9d7
name: myapp-54fcdcd9d7-2h5vx
namespace: cli-resources
spec:
containers:
- image: registry.ocp4.example.com:8443/ubi8/httpd-24:1-215
imagePullPolicy: Always
name: myapp
resources:
limits:
cpu: 500m
memory: 128Mi
requests:
cpu: 500m
memory: 128Mi
L’utilisation d’un format structuré avec la commande get permet d’obtenir plus de
détails sur une ressource qu’avec la commande describe.
d’API Kubernetes apps. Ensuite, décrivez une ressource du groupe d’API apps dans le
projet cli-resources.
4.1. Listez les types de ressources fournis par le groupe d’API apps.
100 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ oc api-resources --api-group apps

4.2. Utilisez la commande explain pour afficher une description et les champs du type
de ressource deployments.
[student@workstation ~]$ oc explain deployments

GROUP: apps
KIND: Deployment
VERSION: apps/v1
DESCRIPTION:
Deployment enables declarative updates for Pods and ReplicaSets.
FIELDS:
apiVersion <string>
value, and may reject unrecognized values. More info:
4.3. Utilisez la commande get pour identifier toutes les ressources deployment du
projet cli-resources, le cas échéant.
[student@workstation ~]$ oc get deploy

NAME READY UP-TO-DATE AVAILABLE AGE
myapp 1/1 1 1 25m
4.4. Le déploiement myapp existe dans le projet cli-resources. Utilisez la commande

get et l’option -o wide pour identifier le nom et l’image du conteneur dans le
déploiement.
[student@workstation ~]$ oc get deploy myapp -o wide

NAME ... CONTAINERS IMAGES SELECTOR
myapp ... myapp registry.ocp4.example.com:8443/ubi8/httpd-24:1-215 app=myapp
Le déploiement myapp utilise l’image registry.ocp4.example.com:8443/

ubi8/httpd-24:1-215 pour le conteneur myapp.
4.5. Décrivez le déploiement myapp pour afficher plus d’informations sur la ressource.
[student@workstation ~]$ oc describe deployment myapp

Name: myapp
Namespace: cli-resources
CreationTimestamp: Wed, 01 Mar 2023 18:41:39 -0500
Labels: my-app
Annotations: deployment.kubernetes.io/revision: 1
DO180-OCP4.14-fr-2-20240530 101
Selector: app=myapp
Replicas: 1 desired | 1 updated | 1 total | 1 available | 0
unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=myapp
Containers:
myapp:
Image: registry.ocp4.example.com:8443/ubi8/httpd-24:1-215
Port: 8080
Host Port: 8080
Limits:
cpu: 500m
memory: 128Mi
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: myapp-54fcdcd9d7 (1/1 replicas created)
Events:
---- ------ ---- ---- -------
Normal ScalingReplicaSet 30m deployment-controller Scaled up replica set
myapp-54fcdcd9d7 to 1
d’API de configuration OpenShift. Ensuite, décrivez une ressource du groupe d’API de
configuration OpenShift.
5.1. Lister les types de ressources fournis par le groupe d’API de configuration OpenShift.
[student@workstation ~]$ oc api-resources --api-group config.openshift.io

apiservers config.openshift.io/v1 false APIServer
authentications config.openshift.io/v1 false
Authentication
builds config.openshift.io/v1 false Build
clusteroperators co config.openshift.io/v1 false
ClusterOperator
clusterversions config.openshift.io/v1 false
ClusterVersion
consoles config.openshift.io/v1 false Console
dnses config.openshift.io/v1 false DNS
featuregates config.openshift.io/v1 false FeatureGate
imagecontentpolicies config.openshift.io/v1 false
ImageContentPolicy
102 DO180-OCP4.14-fr-2-20240530
imagedigestmirrorsets idms config.openshift.io/v1 false

ImageDigestMirrorSet
images config.openshift.io/v1 false Image
imagetagmirrorsets itms config.openshift.io/v1 false
ImageTagMirrorSet
infrastructures config.openshift.io/v1 false
Infrastructure
ingresses config.openshift.io/v1 false Ingress
networks config.openshift.io/v1 false Network
nodes config.openshift.io/v1 false Node
oauths config.openshift.io/v1 false OAuth
operatorhubs config.openshift.io/v1 false OperatorHub
projects config.openshift.io/v1 false Project
proxies config.openshift.io/v1 false Proxy
schedulers config.openshift.io/v1 false Scheduler
Le groupe d’API config.openshift.io fournit plusieurs types de ressources sans

espace de noms.
5.2. Utilisez la commande explain pour afficher une description et les champs du type
de ressource projects.
[student@workstation ~]$ oc explain projects

GROUP: project.openshift.io
KIND: Project
VERSION: v1
DESCRIPTION:
Projects are the unit of isolation and collaboration in OpenShift. A
project has one or more members, a quota on the resources that the project
may consume, and the security controls on the resources in the project.
Within a project, members may have different roles - project administrators
can set membership, editors can create and manage the resources, and
viewers can see but not access running containers. In a normal cluster
project administrators are not able to alter their quotas - that is
restricted to cluster administrators.
Listing or watching projects will return only projects the user has the
reader role on.
5.3. Décrivez le projet cli-resources.
[student@workstation ~]$ oc describe project cli-resources

Name: cli-resources
Created: 10 minutes ago
Labels: kubernetes.io/metadata.name=cli-resources
pod-security.kubernetes.io/audit=restricted
pod-security.kubernetes.io/audit-version=v1.24
pod-security.kubernetes.io/warn=restricted
pod-security.kubernetes.io/warn-version=v1.24
Annotations: openshift.io/description=
openshift.io/display-name=
openshift.io/requester=system:admin
DO180-OCP4.14-fr-2-20240530 103
openshift.io/sa.scc.mcs=s0:c26,c25
openshift.io/sa.scc.supplemental-groups=1000710000/10000
openshift.io/sa.scc.uid-range=1000710000/10000
Display Name: <none>
Description: <none>
Status: Active
Node Selector: <none>
Quota: <none>
Resource limits: <none>
5.4. Récupérez plus d’informations sur le projet cli-resources. Utilisez la commande

get et formatez la sortie pour utiliser JSON.
[student@workstation ~]$ oc get project cli-resources -o json

{
"apiVersion": "project.openshift.io/v1",
"kind": "Project",
"metadata": {
"labels": {
"kubernetes.io/metadata.name": "cli-resources",
"pod-security.kubernetes.io/audit": "restricted",
"pod-security.kubernetes.io/audit-version": "v1.24",
"pod-security.kubernetes.io/warn": "restricted",
"pod-security.kubernetes.io/warn-version": "v1.24"
},
"name": "cli-resources",
"resourceVersion": "705313",
"uid": "53cbbe45-31ea-4b41-93a9-4ba5c2c4c1f3"
},
"status": {
"phase": "Active"
}
}
La commande get fournit des informations supplémentaires, tels que les attributs
kind et apiVersion, sur la ressource de projet.
6. Vérifiez l’état du cluster en examinant ses services. Formatez les sorties de commande en
utilisant des filtres.
6.1. Récupérez la liste des pods pour l’opérateur Etcd. L’opérateur Etcd est disponible
dans l’espace de noms openshift-etcd. Spécifiez l’espace de noms avec l’option
--namespace ou -n.
[student@workstation ~]$ oc get pods -n openshift-etcd

Error from server (Forbidden): pods is forbidden: User "developer" cannot list
resource "pods" in API group "" in the namespace "openshift-etcd"
L’utilisateur developer ne peut pas accéder aux ressources de l’espace de noms

openshift-etcd. Les utilisateurs de cluster standard, tels que developer, ne
peuvent pas interroger les ressources des espaces de noms openshift-.
104 DO180-OCP4.14-fr-2-20240530
Connectez-vous en tant qu’utilisateur admin avec le mot de passe redhatocp.

Ensuite, récupérez la liste des pods dans l’espace de noms openshift-etcd.

Login successful
[student@workstation ~]$ oc get pods -n openshift-etcd
etcd-master01 4/4 Running 36 25d
installer-3-master01 0/1 Completed 0 25d
6.2. Récupérez l’image du pod etcd-master01 dans l’espace de noms openshift-

etcd. Utilisez des filtres pour limiter la sortie à l’attribut .spec.containers du pod
pour obtenir le premier élément. Comparez les sorties de JSONPath, les filtres jq et
le format du modèle Go.
[student@workstation ~]$ oc get pods etcd-master01 -n openshift-etcd \

-o=jsonpath='{.spec.containers[0].image}{"\n"}'
quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:24d9...2020
[student@workstation ~]$ oc get pods -n openshift-etcd etcd-master01 \

-o json | jq .spec.containers[0].image
"quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:24d9...2020"
[student@workstation ~]$ oc get pods -n openshift-etcd etcd-master01 \

-o go-template='{{(index .spec.containers 0).image}}'
quay.io/openshift-release-dev/ocp-v4.0-art-
dev@sha256:24d9b9d9d7fadacbc505c849a1e4b390b2f0fcd452ad851b7cce21e8cf
6.3. Récupérez l’état condition du pod prometheus-k8s-0 dans l’espace de noms

openshift-monitoring. Configurez la sortie de manière à utiliser le format YAML,
puis filtrez la sortie à l’aide de yq.
[student@workstation ~]$ oc get pods -n openshift-monitoring prometheus-k8s-0 \

-o yaml | yq r - 'status.conditions'
status: "True"
type: Initialized
status: "True"
type: Ready
status: "True"
type: ContainersReady
status: "True"
type: PodScheduled
DO180-OCP4.14-fr-2-20240530 105
L’option r - indique à la commande yq de lire l’entrée standard (STDIN) pour la

sortie YAML de la commande get.
6.4. Utilisez la commande get afin de récupérer des informations détaillées sur les
pods dans l’espace de noms openshift-storage. Utilisez le format YAML et des
colonnes personnalisées pour filtrer la sortie conformément au tableau suivant :
Titre de la colonne Objet
PodName metadata.name
ContainerName spec.containers[].name
Phase status.phase
IP status.podIP
Ports spec.containers[].ports[].containerPort
[student@workstation ~]$ oc get pods -n openshift-storage \

-o custom-columns=PodName:".metadata.name",\
ContainerName:"spec.containers[].name",\
Phase:"status.phase",\
IP:"status.podIP",\
Ports:"spec.containers[].ports[].containerPort"
PodName ContainerName Phase IP Ports
lvms-operator-7fcd897cb-... manager Running 10.8.0.97 9443
topolvm-controller-.... topolvm-controller Running 10.8.0.98 9808
topolvm-node-9spzf lvmd Running 10.8.0.100 <none>
vg-manager-z8g5k vg-manager Running 10.8.0.101 <none>
Fin
[student@workstation ~]$ lab finish cli-resources
106 DO180-OCP4.14-fr-2-20240530
Évaluation de l’intégrité d’un cluster

OpenShift
Résultats
• Exécuter une requête pour connaître l’intégrité des services et composants de cluster
essentiels.
Conditions de l’opérateur de requête

Les opérateurs sont des composants importants de Red Hat OpenShift Container Platform
(RHOCP). Ils automatisent les tâches requises pour maintenir l’intégrité d’un cluster RHOCP,
opération qui nécessiterait autrement une intervention humaine. Les opérateurs constituent la
méthode privilégiée pour empaqueter, déployer et gérer des services sur le plan de contrôle.
Les opérateurs s’intègrent aux API Kubernetes et aux outils CLI tels que les commandes kubectl
et oc. Les opérateurs permettent de surveiller les applications, d’effectuer des bilans de santé, de
gérer les mises à jour OTA (Over-the-Air) et de s’assurer que les applications restent dans l’état
que vous avez spécifié.
Étant donné que CRI-O et le Kubelet s’exécutent sur chaque nœud, presque toutes les autres
fonctions de cluster peuvent être gérées sur le plan de contrôle à l’aide d’opérateurs. Les
composants qui sont ajoutés au plan de contrôle à l’aide d’opérateurs sont notamment les services
d’informations d’identification et de mise en réseau critiques.
Dans RHOCP, les opérateurs sont gérés par deux systèmes différents, en fonction de leur finalité.
Opérateur de version de cluster (CVO)

Les opérateurs de cluster exécutent des fonctions de cluster. Ces opérateurs sont installés
par défaut et gérés par l’opérateur de version de cluster (CVO).
Les opérateurs de cluster utilisent la valeur kind Kubernetes clusteroperators et

peuvent donc être interrogés via les commandes oc ou kubectl. En tant qu’utilisateur avec
le rôle cluster-admin, utilisez la commande oc get clusteroperators pour lister tous
les opérateurs de cluster.
[user@host ~]$ oc get clusteroperators

NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE
MESSAGE
authentication 4.14.0 True False False 3d1h
Pour plus d’informations sur un opérateur de cluster, utilisez la commande describe

clusteroperators operator-name pour afficher les valeurs de champ qui sont
associées à l’opérateur, y compris son état actuel. La commande describe fournit un format
DO180-OCP4.14-fr-2-20240530 107
de sortie lisible par l’utilisateur pour une ressource. Ainsi, le format de sortie peut changer
avec une mise à jour de la version RHOCP.
Pour disposer d’un format de sortie moins susceptible d’être affecté par une mise à jour de
version, utilisez l’une des options de sortie -o de la commande get. Par exemple, utilisez la
commande oc get clusteroperators suivante pour les détails de sortie au format YAML
pour l’opérateur dns.
[user@host ~]$ oc get clusteroperators dns -o yaml

apiVersion: config.openshift.io/v1
kind: ClusterOperator
metadata:
annotations:
status:
conditions:
- lastTransitionTime: "2023-03-20T13:55:21Z"
message: DNS "default" is available.
reason: AsExpected
status: "True"
type: Available
relatedObjects:
- group: ""
name: openshift-dns-operator
resource: namespaces
versions:
- name: operator
version: 4.14.0
Opérateurs OLM
Il s’agit d’opérateurs complémentaires facultatifs gérés par OLM qui peuvent être mis à la
disposition des utilisateurs pour qu’ils les exécutent dans leurs applications.
En tant qu’utilisateur avec le rôle cluster-admin, utilisez la commande get operators

pour lister tous les opérateurs complémentaires.
[user@host~]$ oc get operators

NAME AGE
lvms-operator.openshift-storage 34d
metallb-operator.metallb-system 34d
Vous pouvez également utiliser les commandes describe et get pour demander des détails
sur les champs associés aux opérateurs complémentaires.
Les opérateurs utilisent un ou plusieurs pods pour fournir des services de cluster. Vous trouverez
les espaces de noms de ces pods dans la section relatedObjects de la sortie détaillée de
l’opérateur. En tant qu’utilisateur avec un rôle cluster-admin, utilisez l’option -n namespace
sur la commande get pod pour afficher les pods. Par exemple, utilisez la commande get pods
suivante pour récupérer la liste des pods dans l’espace de noms openshift-dns-operator.
108 DO180-OCP4.14-fr-2-20240530
[user@host~]$ oc get pods -n openshift-dns-operator

dns-operator-64688bfdd4-8zklh 2/2 Running 38 38d
Utilisez les formats de sortie -o yaml ou -o json pour afficher ou analyser plus d’informations
sur les pods. Les conditions de ressource, qui se trouvent dans le statut de la ressource, effectuent
le suivi de l’état actuel de l’objet de ressource. Dans l’exemple suivant, le processeur jq est utilisé
pour extraire les valeurs status des détails de sortie JSON pour le pod dns.
[user@host~]$ oc get pod -n openshift-dns-operator \

dns-operator-64688bfdd4-8zklh -o json | jq .status
{
"conditions": [
{
"lastProbeTime": null,
"lastTransitionTime": "2023-02-09T21:24:50Z",
"status": "True",
"type": "Initialized"
},
Outre l’affichage de la liste des pods d’un espace de noms, vous pouvez utiliser l’option --show-
labels de la commande get pour imprimer les étiquettes utilisées par les pods. L’exemple
suivant récupère les pods et leurs étiquettes dans l’espace de noms openshift-etcd.
[user@host~]$ oc get pods -n openshift-etcd --show-labels

NAME READY STATUS RESTARTS AGE LABELS
app=etcd,etcd=true,k8s-app=etcd,revision=3
installer-3-master01 0/1 Completed 0 35d app=installer
Examen des mesures du cluster

Un autre moyen d’évaluer l’intégrité d’un cluster RHOCP consiste à examiner l’utilisation des
ressources de calcul des pods et des nœuds du cluster. La commande oc adm top fournit ces
informations. Par exemple, pour afficher l’utilisation totale de la mémoire et du processeur de
tous les pods du cluster, vous pouvez utiliser l’option --sum avec la commande afin d’imprimer la
somme de l’utilisation des ressources.
[user@host~]$ oc adm top pods -A --sum

NAMESPACE NAME CPU(cores) MEMORY(bytes)
metallb-system controller-...-ddr8v 0m 57Mi
metallb-system metallb-...-n2zsv 0m 48Mi
openshift-storage topolvm-node-9spzf 0m 68Mi
openshift-storage vg-manager-z8g5k 0m 23Mi
------ --------
428m 10933Mi
L’option -A affiche les pods de tous les espaces de noms. Utilisez l’option -n namespace
pour filtrer les résultats afin d’afficher les pods d’un seul espace de noms. Utilisez l’option --
containers pour afficher l’utilisation des ressources des conteneurs dans un pod. Par exemple,
DO180-OCP4.14-fr-2-20240530 109
utilisez la commande suivante pour afficher l’utilisation des ressources des conteneurs dans le pod
etcd-master01 de l’espace de noms openshift-etcd.
[user@host~]$ oc adm top pods etcd-master01 -n openshift-etcd --containers

POD NAME CPU(cores) MEMORY(bytes)
etcd-master01 POD 0m 0Mi
etcd-master01 etcd 71m 933Mi
etcd-master01 etcd-metrics 6m 32Mi
etcd-master01 etcd-readyz 4m 66Mi
etcd-master01 etcdctl 0m 0Mi
Affichage des mesures de cluster

La console Web OpenShift intègre des graphiques permettant de visualiser les analyses des
ressources et des clusters. Les administrateurs de cluster et les utilisateurs qui possèdent le rôle
de cluster view ou cluster-monitoring-view peuvent accéder à la page Home > Overview.
La page Overview affiche une série de métriques à l’échelle du cluster et fournit une vue de haut
niveau de l’intégrité globale du cluster.
La page Overview affiche les métriques suivantes :
• Capacité du cluster actuelle en fonction de l’utilisation du processeur, de la mémoire, du

stockage et du réseau
• Graphique de série chronologique de l’utilisation totale du processeur, de la mémoire et du
disque
• La possibilité d’afficher les meilleurs consommateurs de processeur, de mémoire et de stockage
Pour chacune des ressources listées dans la section Cluster Utilization, les administrateurs
peuvent cliquer sur le lien pour l’utilisation des ressources actuelles. Le lien affiche une fenêtre
avec une décomposition des principaux consommateurs de cette ressource. Les principaux
consommateurs peuvent être triés par projet, par pod ou par nœud. La liste des plus grands
consommateurs peut être utile pour identifier les pods ou nœuds problématiques. Par exemple, un
pod avec une fuite de mémoire inattendue peut apparaître en haut de la liste.
110 DO180-OCP4.14-fr-2-20240530
Affichage des mesures des projets

La page Project Details affiche des métriques qui donnent une vue d’ensemble des ressources
utilisées dans le cadre d’un projet spécifique. La section Utilization affiche des informations sur
l’utilisation des ressources telles que le processeur et la mémoire, ainsi que la possibilité d’afficher
les principaux consommateurs pour chaque ressource.
Toutes les mesures sont extraites de Prometheus. Cliquez sur n’importe quel graphique pour
accéder à la page Metrics. Affichez la requête exécutée et inspectez les données en détail.
Si un quota de ressources est créé pour le projet, la demande et les limites du projet actuel sont
affichées sur la page Project Details.
Affichage des mesures des ressources

Lors de la résolution des problèmes, il est souvent utile d’afficher les métriques à un niveau de
granularité inférieur à celui de l’ensemble du cluster ou du projet. La page Pod Details affiche les
graphiques de séries chronologiques de l’utilisation du processeur, de la mémoire et du système
de fichiers pour un pod donné. Une modification soudaine de ces métriques critiques, telle qu’un
pic processeur causé par une charge élevée, est visible sur cette page.
DO180-OCP4.14-fr-2-20240530 111
Figure 2.9: Graphiques de séries chronologiques montrant différentes mesures pour un pod
Exécution de requêtes Prometheus dans la console Web

L’interface utilisateur Prometheus est un outil riche en fonctionnalités permettant de visualiser les
mesures et de configurer les alertes. La console Web OpenShift fournit une interface permettant
d’exécuter des requêtes Prometheus directement depuis celle-ci.
Pour effectuer une requête, accédez à Observe > Metrics, saisissez une expression Prometheus
Query Language dans le champ de texte, puis cliquez sur Run Queries. Les résultats de la requête
sont affichés sous la forme d’un graphique de série chronologique :
Figure 2.10: Utilisation d’une requête Prometheus pour afficher un graphique de séries chronologiques
112 DO180-OCP4.14-fr-2-20240530
Note
Prometheus Query Language n’est pas abordé en détail dans ce cours. Vous
trouverez, dans la section des références, un lien vers la documentation officielle.
Interrogation des événements et alertes du cluster

Certains développeurs considèrent que les journaux OpenShift sont d’un niveau trop bas, ce
qui complique la résolution des problèmes. Heureusement, RHOCP fournit une fonction de
journalisation et d’audit de haut niveau, connue sous le nom d’événements. Kubernetes génère
des objets event en réponse aux changements d’état des objets de cluster, tels que les nœuds,
les pods et les conteneurs. Les événements signalent les opérations importantes, comme le
démarrage d’un conteneur ou l’élimination d’un pod.
Pour lire les événements, utilisez la commande get events. La commande liste les événements
du projet RHOCP en cours (espace de noms). Vous pouvez afficher les événements d’un autre
projet en ajoutant l’option -n namespace à la commande. Pour lister les événements de tous les
projets, utilisez l’option -A (ou --all-namespaces).
Note
Pour trier les événements par heure, ajoutez l’option --sort-
by .metadata.creationTimestamp à la commande oc get events.
La commande get events suivante imprime les événements de l’espace de noms openshift-
kube-controller-manager.
[user@host~]$ oc get events -n openshift-kube-controller-manager

LAST SEEN TYPE REASON OBJECT
MESSAGE
12m Normal CreatedSCCRanges pod/kube-controller-manager-master01
created SCC...
Vous pouvez utiliser la commande describe pod pod-name pour restreindre les résultats à un
seul pod. Par exemple, pour ne récupérer que les événements liés à un pod mysql, vous pouvez
vous reporter au champ Events dans la sortie de la commande oc describe pod mysql :
[user@host~]$ oc describe pod mysql

Events:
FirstSeen LastSeen Count From Reason Message
Wed, 10 ... Wed, 10 ... 1 {scheduler } scheduled Successfully as...
Alertes Kubernetes
RHOCP comprend une pile de surveillance basée sur le projet Open Source Prometheus. Par
défaut, cette pile est configurée pour surveiller les principaux composants du cluster RHOCP.
Vous pouvez également configurer la pile pour la surveillance de projets utilisateur.
Les composants de la pile de surveillance sont installés dans l’espace de noms openshift-
monitoring. L’opérateur Prometheus de l’espace de nomsòpenshift-monitoring` crée,
DO180-OCP4.14-fr-2-20240530 113
configure et gère les instances Prometheus et Alertmanager de la plateforme. Un pod

Alertmanager dans l’espace de noms openshift-monitoring reçoit des alertes de
Prometheus. Alertmanager peut également envoyer des alertes à des systèmes de notification
externes.
Utilisez la commande get all suivante pour afficher la liste de toutes les ressources, de leur état
et de leurs types dans l’espace de noms openshift-monitoring.
[user@host~]$ oc get all -n openshift-monitoring --show-kind

pod/alertmanager-main-0 6/6 Running 85 34d
pod/cluster-monitoring-operator-56b769b58f-dtmqj 2/2 Running 34 35d
pod/kube-state-metrics-75455b796c-8q28d 3/3 Running 51 35d
Le pod alertmanager-main-0 est l’instance Alertmanager pour le cluster. La commande logs

suivante affiche les journaux du pod alertmanager-main-0, lequel présente les messages
reçus de Prometheus.
[user@host~]$ oc logs alertmanager-main-0 -n openshift-monitoring

ts=2023-03-16T14:21:50.479Z caller=main.go:231 level=info msg="Starting
Alertmanager" version="(version=0.24.0, branch=rhaos-4.14-rhel-8,
revision=519cbb87494d2830821a0da0a657af69d852c93b)"
ts=2023-03-16T14:21:50.479Z caller=main.go:232 level=info
build_context="(go=go1.19.4, user=root@232132c11c68, date=20230105-00:26:49)"
ts=2023-03-16T14:21:50.527Z caller=coordinator.go:113 level=info
component=configuration msg="Loading configuration file" file=/etc/alertmanager/
config_out/alertmanager.env.yaml
Vérification de l’état du nœud

Les clusters RHOCP peuvent comporter plusieurs composants, dont au moins un plan de
contrôle et au moins un nœud de calcul. Les deux composants peuvent occuper un seul nœud.
La commande oc suivante, ou la commande kubectl correspondante, peut afficher l’intégrité
globale de tous les nœuds du cluster.
[user@host~]$ oc cluster-info
La sortie oc cluster-info est une sortie de haut niveau qui permet de vérifier que les nœuds
du cluster sont en cours d’exécution. Pour obtenir une vue plus détaillée des nœuds du cluster,
utilisez la commande get nodes.
[user@host~]$ oc get nodes

L’exemple illustre un seul nœud master01 avec plusieurs rôles. La valeur STATUS de Ready
signifie que ce nœud est sain et qu’il peut accepter de nouveaux pods. Une valeur STATUS de
NotReady signifie qu’une condition a déclenché l’état NotReady et que le nœud n’accepte pas
de nouveaux pods.
114 DO180-OCP4.14-fr-2-20240530
Comme pour toute autre ressource RHOCP, vous pouvez explorer plus en détail la ressource de
nœud à l’aide de la commande describe node node-name. Pour obtenir une sortie analysable
des mêmes informations, utilisez les options de sortie -o json ou -o yaml avec la commande
get node node-name. Pour plus d’informations sur l’utilisation et l’analyse de ces formats de
sortie, consultez la section Examen des ressources Kubernetes .
La sortie de la commande get nodes node-name avec l’option -o json ou -o yaml est
longue. Dans les exemples suivants, l’option -jsonpath ou le processeur jq est utilisé pour
analyser la sortie de la commande get node node-name.
[user@host~]$ oc get node master01 -o jsonpath=\

*'{"Allocatable:\n"}{.status.allocatable}{"\n\n"}
{"Capacity:\n"}{.status.capacity}{"\n"}'
Allocatable:
{"cpu":"7500m","ephemeral-storage":"114396791822","hugepages-1Gi":"0",
"hugepages-2Mi":"0","memory":"19380692Ki","pods":"250"}
Capacity:
{"cpu":"8","ephemeral-storage":"125293548Ki","hugepages-1Gi":"0",
"hugepages-2Mi":"0","memory":"20531668Ki","pods":"250"}
L’expression JSONPath dans la commande précédente extrait les mesures allouables et de

capacité pour le nœud master01. Ces mesures permettent de mieux comprendre les ressources
disponibles sur un nœud.
Affichez l’objet status d’un nœud pour comprendre son intégrité actuelle.
[user@host~]$ oc get node master01 -o json | jq '.status.conditions'

[
{
"lastHeartbeatTime": "2023-03-22T16:34:57Z",
"message": "kubelet has sufficient memory available",
"reason": "KubeletHasSufficientMemory",
"status": "False",
"type": "MemoryPressure"
},
{
"message": "kubelet has no disk pressure",
"reason": "KubeletHasNoDiskPressure",
"status": "False",
"type": "DiskPressure"
},
{
"message": "kubelet has sufficient PID available",
"reason": "KubeletHasSufficientPID",
"status": "False",
"type": "PIDPressure"
},
{
DO180-OCP4.14-fr-2-20240530 115
"message": "kubelet is posting ready status",
"reason": "KubeletReady",
"status": "True",
"type": "Ready"
}
]
Si le statut de la condition MemoryPressure est « true », le nœud manque de mémoire.
Si le statut de la condition DiskPressure est « true », la capacité du disque du nœud est

faible.
Si le statut de la condition PIDPressure est « true », trop de processus sont en cours

d’exécution sur le nœud.
Si le statut de la condition Ready est « false », le nœud n’est pas sain et n’accepte pas de
pods.
D’autres conditions indiquent d’autres problèmes potentiels avec un nœud.
Conditions de nœud possibles
Condition Description
OutOfDisk Si la valeur est « true », le nœud ne dispose pas de

suffisamment d’espace libre pour l’ajout de nouveaux pods.
NetworkUnavailable Si la valeur est « true », le réseau du nœud n’est pas

correctement configuré.
NotReady Si la valeur est « true », l’un des composants sous-jacents, tels

que le réseau ou l’environnement d’exécution du conteneur,
rencontre des problèmes ou n’est pas encore configuré.
SchedulingDisabled Il est impossible de planifier le placement des pods sur le

nœud.
Pour mieux comprendre un nœud donné, vous pouvez afficher les journaux des processus qui
s’exécutent sur ce nœud. Un administrateur de cluster peut utiliser la commande oc adm node-
logs pour afficher les journaux du nœud. Les journaux de nœud peuvent contenir des données
sensibles et sont donc réservés aux administrateurs de nœuds disposant de privilèges. Utilisez oc
adm node-logs node-name pour filtrer les journaux sur un seul nœud.
La commande oc adm node-logs propose d’autres options pour un filtrage approfondi des
résultats.
Filtres pour oc adm node-logs
--role master Utilisez l’option --role pour filtrer la sortie sur les nœuds
ayant un rôle spécifié.
116 DO180-OCP4.14-fr-2-20240530
-u kubelet L’option -u filtre la sortie sur une unité spécifiée.
--path=cron L’option --path filtre la sortie sur un processus spécifique

dans le répertoire /var/logs.
--tail 1 Utilisez --tail x pour limiter la sortie aux x dernières

entrées du journal.
Utilisez oc adm node-logs --help pour obtenir la liste complète des options de commande.
Par exemple, pour récupérer l’entrée de journal la plus récente pour le service crio sur le nœud
master01, vous pouvez utiliser la commande suivante.
[user@host~]$ oc adm node-logs master01 -u crio --tail 1

-- Logs begin at Thu 2023-02-09 21:19:09 UTC, end at Fri 2023-03-17 15:11:43 UTC.
--
Mar 17 06:16:09.519642 master01 crio[2987]: time="2023-03-17 06:16:09.519474755Z"
level=info msg="Image status:
&ImageStatusResponse{Image:&Image{Id:6ef8...79ce,RepoTags:[],RepoDigests:
Lorsque vous créez un pod avec l’interface de ligne de commande, la commande oc ou kubectl
est envoyée au service apiserver, qui valide ensuite la commande. Le service scheduler
lit la définition de pod YAML ou JSON, puis attribue des pods aux nœuds de calcul. Chaque
nœud de calcul exécute un service kubelet qui convertit le manifeste de pod en un ou plusieurs
conteneurs dans l’environnement d’exécution du conteneur CRI-O.
Pour chaque nœud de calcul, il doit y avoir un service kubelet actif et un service crio actif. Pour
vérifier l’intégrité de ces services, démarrez d’abord une session de débogage sur le nœud à l’aide
de la commande debug.
[user@host~]$ oc debug node/node-name
Remplacez la valeur node-name par le nom de votre nœud.
Note
La commande debug est abordée plus en détail dans une section ultérieure.
Dans la session de débogage, accédez au répertoire racine /host afin de pouvoir exécuter des
binaires dans le chemin d’accès de l’exécutable de l’hôte.
sh-4.4# chroot /host
Utilisez ensuite les appels systemctl is-active pour vérifier que les services sont bien actifs.
DO180-OCP4.14-fr-2-20240530 117
sh-4.4# for SERVICES in kubelet crio; do echo ---- $SERVICES ---- ;

systemctl is-active $SERVICES ; echo ""; done
---- kubelet ----
active
---- crio ----

active
Pour plus d’informations sur l’état d’un service, utilisez la commande systemctl status.
sh-4.4# systemctl status kubelet

● kubelet.service - Kubernetes Kubelet
Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset:
disabled)
Drop-In: /etc/systemd/system/kubelet.service.d
└─01-kubens.conf, 10-mco-default-madv.conf, 20-logging.conf, 20-
nodenet.conf
Active: active (running) since Thu 2023-03-23 14:39:11 UTC; 1h 26min ago
Main PID: 3215 (kubelet)
Tasks: 28 (limit: 127707)
Memory: 391.7M
CPU: 14min 34.568s
Vérification de l’état du pod

RHOCP vous permet d’afficher les journaux dans les pods et les conteneurs en cours d’exécution
afin de faciliter la résolution des problèmes. Au démarrage d’un conteneur, RHOCP redirige
l’erreur et la sortie standard vers un disque dans le stockage éphémère du conteneur. Cette
redirection vous permet de consulter les journaux du conteneur à l’aide de commandes logs,
même après l’arrêt du conteneur. Cependant, le pod qui héberge le conteneur doit toujours
exister.
Dans RHOCP, la commande suivante renvoie la sortie d’un conteneur à l’intérieur d’un pod :
[user@host~]$ oc logs pod-name -c container-name
Remplacez pod-name par le nom du pod cible et container-name par le nom du conteneur
cible. L’argument -c container-name est facultatif si le pod n’a qu’un seul conteneur. Vous
devez utiliser l’argument -c container-name pour vous connecter à un conteneur spécifique
dans un pod à plusieurs conteneurs. Sinon, la commande utilise par défaut le seul conteneur en
cours d’exécution et renvoie la sortie.
Lors du débogage d’images et de la résolution des problèmes de configuration, il est utile

d’obtenir une copie exacte d’une configuration de pod en cours d’exécution, puis d’effectuer la
résolution des problèmes avec un shell. Si un pod échoue ou n’inclut pas de shell, il se peut que les
commandes rsh et exec ne fonctionnent pas. Pour résoudre ce problème, la commande debug
crée une copie du pod spécifié et démarre un shell dans ce pod.
Par défaut, la commande debug démarre un shell à l’intérieur du premier conteneur du pod
référencé. Le pod de débogage est une copie de votre pod source, avec toutefois quelques
modifications supplémentaires. Par exemple, les étiquettes du pod sont supprimées. La
commande exécutée est également remplacée par la commande « /bin/sh » pour les conteneurs
118 DO180-OCP4.14-fr-2-20240530
Linux ou par l’exécutable « cmd.exe » pour les conteneurs Windows. De plus, les sondes readiness
et liveness sont désactivées.
Les politiques de sécurité qui interdisent à un conteneur de s’exécuter en tant qu’utilisateur

root constituent un problème courant pour les conteneurs dans des pods. Vous pouvez utiliser
la commande debug pour tester l’exécution d’un pod en tant qu’utilisateur non root à l’aide de
l’option --as-user. Vous pouvez également exécuter un pod non root en tant qu’utilisateur root
avec l’option --as-root.
La commande debug vous permet d’appeler des types d’objets autres que des pods. Par
exemple, vous pouvez utiliser n’importe quelle ressource de contrôleur qui crée un pod, comme
un déploiement, une compilation ou une tâche. La commande debug fonctionne également avec
des nœuds, ainsi qu’avec les ressources qui peuvent créer des pods, telles que les balises de flux
d’images. Vous pouvez également utiliser l’option --image=IMAGE de la commande debug pour
démarrer une session shell à l’aide d’une image spécifiée.
Si vous n’incluez ni le type ni le nom de la ressource, la commande debug démarre une session
shell dans un pod à l’aide de l’image des outils OpenShift.
[user@host~]$ oc debug
L’exemple suivant teste l’exécution d’un pod de tâche (job) en tant qu’utilisateur non root.
[user@host~]$ oc debug job/test --as-user=1000000
L’exemple suivant crée une session de débogage pour un nœud.
[user@host~]$ oc debug node/master01

Starting pod/master01-debug-wtn9r ...
To use host binaries, run chroot /host
Pod IP: 192.168.50.10
If you don't see a command prompt, try pressing enter.
sh-5.1#
Le pod de débogage est supprimé lorsque la commande distante se termine ou lorsque

l’utilisateur interrompt le shell.
Collecte d’informations pour les demandes

d’assistance
Lors de l’ouverture d’un dossier d’assistance, il est utile de fournir à l’assistance Red Hat des
informations de débogage relatives à votre cluster. Il est recommandé de fournir les informations
suivantes :
• Données collectées en utilisant la commande oc adm must-gather en tant qu’administrateur

de cluster
• ID de cluster unique
La commande oc adm must-gather collecte sur votre cluster les définitions de ressources
et les journaux de service qui sont généralement nécessaires dans le cadre de la résolution
des problèmes. Cette commande crée un pod dans un espace de noms temporaire sur votre
cluster. Ensuite, ce pod rassemble et télécharge les informations de débogage. Par défaut, la
DO180-OCP4.14-fr-2-20240530 119
commande oc adm must-gather utilise l’image de plug-in par défaut et écrit des données dans
le répertoire ./must-gather.local. sur votre système local. Pour écrire dans un répertoire
local spécifique, vous pouvez également utiliser l’option --dest-dir, comme dans l’exemple
suivant :
[user@host~]$ oc adm must-gather --dest-dir /home/student/must-gather
Créez ensuite un fichier d’archive compressé à partir du répertoire must-gather. Par exemple,
sur un système Linux, vous pouvez exécuter la commande suivante :
[user@host~]$ tar cvaf mustgather.tar must-gather/
Remplacez must-gather/ par le chemin d’accès du répertoire réel.
Ensuite, joignez le fichier d’archive compressé à votre dossier d’assistance sur le Portail Client
Red Hat.
À l’instar de la commande oc adm must-gather, la commande oc adm inspect collecte

des informations sur une ressource spécifiée. Par exemple, la commande ci-dessous collecte
des données de débogage pour les opérateurs de cluster openshift-apiserver et kube-
apiserver.
[user@host~]$ oc adm inspect clusteroperator/openshift-apiserver \

clusteroperator/kube-apiserver
La commande oc adm inspect peut également utiliser l’option --dest-dir pour spécifier
un répertoire local où écrire les informations collectées. Par défaut, la commande affiche tous les
journaux. Utilisez l’option --since pour filtrer les résultats sur les journaux ultérieurs à une durée
relative, comme 5s, 2m ou 3h.
[user@host~]$ oc adm inspect clusteroperator/openshift-apiserver --since 10m
120 DO180-OCP4.14-fr-2-20240530
Références
Pour plus d’informations, reportez-vous au chapitre Control Plane Architecture
(Architecture du plan de contrôle) de la documentation Architecture de Red Hat
OpenShift Container Platform 4.14, disponible à l’adresse
openshift_container_platform/4.14/html-single/architecture/index#control-plane
Pour plus d’informations, reportez-vous à la documentation Monitoring de Red Hat

openshift_container_platform/4.14/html-single/monitoring/index
Pour plus d’informations, reportez-vous à la documentation Nodes (Nœuds) de

Red Hat OpenShift Container Platform 4.14, disponible à l’adresse
openshift_container_platform/4.14/html-single/nodes/index#working-with-nodes
Interrogation de Prometheus
https://prometheus.io/docs/prometheus/latest/querying/basics/
Pour plus d’informations, reportez-vous au chapitre Troubleshooting Kubernetes

dans la documentation Red Hat Enterprise Linux Atomic Host 7 Getting Started with
Kubernetes disponible, disponible à l’adresse
red_hat_enterprise_linux_atomic_host/7/html-single/
getting_started_with_kubernetes/index#troubleshooting_kubernetes
Pour plus d’informations sur la collecte de données de diagnostic sur votre cluster,
reportez-vous au chapitre Gathering data about your cluster (Collecte de données
sur votre cluster) de la documentation Support (Assistance) de Red Hat OpenShift
openshift_container_platform/4.14/html-single/support/index#gathering-cluster-
data
DO180-OCP4.14-fr-2-20240530 121
Exercice guidé
Évaluation de l’intégrité d’un cluster

OpenShift
Vérifiez l’intégrité d’un cluster OpenShift en interrogeant l’état de ses opérateurs, nœuds,
pods et services systemd. Vérifiez également les événements et alertes du cluster.
Résultats
• Afficher l’état et obtenir des informations sur les opérateurs de cluster.
• Récupérer des informations sur les nœuds et les pods du cluster.
• Récupérer l’état des services systemd d’un nœud.
• Afficher les événements et alertes d’un cluster.
• Récupérez des informations de débogage pour le cluster.
Avant De Commencer
pour préparer votre système pour cet exercice. Cette commande permet de s’assurer que
toutes les ressources sont disponibles pour cet exercice.
[student@workstation ~]$ lab start cli-health
Instructions
1. Récupérez l’état et affichez des informations sur les opérateurs de cluster.
1.1. Connectez-vous au cluster OpenShift en tant qu’utilisateur admin avec le mot de

passe redhatocp.
[student@workstation ~]$ oc login -u admin -p redhatocp \

Login successful
1.2. Listez les opérateurs que les utilisateurs ont installés dans le cluster OpenShift.
[student@workstation ~]$ oc get operators

NAME AGE
lvms-operator.openshift-storage 27d
metallb-operator.metallb-system 27d
1.3. Listez les opérateurs de cluster installés par défaut dans le cluster OpenShift.
122 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ oc get clusteroperators

NAME VERSION AVAILABLE PROGRESSING DEGRADED ...
authentication 4.14.0 True False False ...
baremetal 4.14.0 True False False ...
cloud-controller-manager 4.14.0 True False False ...
cloud-credential 4.14.0 True False False ...
cluster-autoscaler 4.14.0 True False False ...
config-operator 4.14.0 True False False ...
console 4.14.0 True False False ...
control-plane-machine-set 4.14.0 True False False ...
csi-snapshot-controller 4.14.0 True False False ...
dns 4.14.0 True False False ...
etcd 4.14.0 True False False ...
1.4. Utilisez la commande describe pour afficher des informations détaillées sur
l’opérateur de cluster openshift-apiserver, telles que les événements, la version
et les objets associés.
[student@workstation ~]$ oc describe clusteroperators openshift-apiserver

Name: openshift-apiserver
Namespace:
Labels: <none>
Annotations: exclude.release.openshift.io/internal-openshift-hosted: true
include.release.openshift.io/self-managed-high-availability: true
include.release.openshift.io/single-node-developer: true
API Version: config.openshift.io/v1
Kind: ClusterOperator
Metadata:
Spec:
Status:
Conditions:
Last Transition Time: 2023-02-09T22:41:08Z
Message: All is well
Reason: AsExpected
Status: False
Type: Degraded
Extension: <nil>
Related Objects:
Group: operator.openshift.io
Name: cluster
Resource: openshiftapiservers
Group:
Name: openshift-config
Resource: namespaces
Group:
Name: openshift-config-managed
Group:
Name: openshift-apiserver-operator
DO180-OCP4.14-fr-2-20240530 123
Group:
Versions:
Name: operator
Version: 4.14.0
Version: 4.14.0
Events: <none>
L’attribut Related Objects inclut des informations sur le nom, le type de ressource
et les groupes des objets liés à l’opérateur.
1.5. Listez les pods de l’espace de noms openshift-apiserver-operator. Ensuite,

affichez l’état détaillé d’un pod openshift-apiserver-operator à l’aide du
format JSON et de la commande jq. Les noms de vos pods peuvent être différents.
[student@workstation ~]$ oc get pods -n openshift-apiserver-operator

openshift-apiserver-operator-7ddc8958fb-7m2kr 1/1 Running 11 27d
[student@workstation ~]$ oc get pod -n openshift-apiserver-operator \

openshift-apiserver-operator-7ddc8958fb-7m2kr \
-o json | jq .status
{
"conditions": [
{
"status": "True",
"type": "Ready"
},
],
"containerStatuses": [
{
"name": "openshift-apiserver-operator",
"ready": true,
"restartCount": 11,
"started": true,
"state": {
"running": {
"startedAt": "2023-03-08T15:41:34Z"
}
}
}
],
"hostIP": "192.168.50.10",
"phase": "Running",
124 DO180-OCP4.14-fr-2-20240530
"podIP": "10.8.0.5",
}
2. Récupérez l’état, la consommation de ressources et les événements des pods du cluster.
2.1. Afficher l’utilisation de la mémoire et du processeur de tous les pods du cluster.

Utilisez l’option --sum pour imprimer la somme de l’utilisation des ressources.
L’utilisation des ressources sur votre système diffère probablement.
[student@workstation ~]$ oc adm top pods -A --sum

NAMESPACE NAME CPU(cores)
MEMORY(bytes)metallb-system controller-5f6dfd8c4f-ddr8v 0m
39Mi
metallb-system metallb-operator-controller-manager-... 1m 38Mi
metallb-system metallb-operator-webhook-server-... 1m 18Mi
metallb-system speaker-2dds4 10m 94Mi
505m 8982Mi
2.2. Listez les pods et leurs étiquettes dans l’espace de noms openshift-etcd.
[student@workstation ~]$ oc get pods -n openshift-etcd --show-labels

app=etcd,etcd=true,k8s-app=etcd,revision=3
installer-3-master01 0/1 Completed 0 27d app=installer
2.3. Affichez l’utilisation des ressources des conteneurs dans le pod etcd-master01 de
l’espace de noms openshift-etcd. L’utilisation des ressources sur votre système
diffère probablement.
[student@workstation ~]$ oc adm top pods etcd-master01 \

-n openshift-etcd --containers
2.4. Affichez la liste de toutes les ressources, de leur état et de leurs types dans l’espace
de noms openshift-monitoring.
[student@workstation ~]$ oc get all -n openshift-monitoring --show-kind

NAME READY STATUS ...
pod/alertmanager-main-0 6/6 Running ...
pod/cluster-monitoring-operator-56b769b58f-dtmqj 2/2 Running ...
pod/kube-state-metrics-75455b796c-8q28d 3/3 Running ...
NAME TYPE CLUSTER-IP ...
service/alertmanager-main ClusterIP 172.30.85.183 ...
DO180-OCP4.14-fr-2-20240530 125
service/alertmanager-operated ClusterIP None ...

service/cluster-monitoring-operator ClusterIP None ...
service/kube-state-metrics ClusterIP None ...
2.5. Affichez les journaux du pod alertmanager-main-0 dans l’espace de noms

openshift-monitoring. Les journaux peuvent être différents sur votre système.
[student@workstation ~]$ oc logs alertmanager-main-0 -n openshift-monitoring

component=configuration msg="Loading configuration file" file=/etc/alertmanager/
config_out/alertmanager.env.yaml
component=configuration msg="Completed loading of configuration file" file=/etc/
alertmanager/config_out/alertmanager.env.yaml
2.6. Récupérez les événements pour l’espace de noms openshift-kube-controller-

manager.
[student@workstation ~]$ oc get events -n openshift-kube-controller-manager

LAST SEEN TYPE REASON OBJECT ...
175m Normal CreatedSCCRanges pod/kube-controller-manager-master01...
11m Normal CreatedSCCRanges pod/kube-controller-manager-master01...
3. Récupérez des informations sur les nœuds du cluster.
3.1. Affichez l’état des nœuds dans le cluster.
[student@workstation ~]$ oc get nodes

3.2. Récupérez la consommation de ressources du nœud master01. L’utilisation des

ressources sur votre système diffère probablement.
[student@workstation ~]$ oc adm top node

NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
master01 781m 10% 11455Mi 60%
3.3. Utilisez un filtre JSONPath pour déterminer la capacité et le processeur pouvant

être alloué pour le nœud master01. Les valeurs peuvent être différentes sur votre
système.
[student@workstation ~]$ oc get node master01 -o jsonpath=\

'Allocatable: {.status.allocatable.cpu}{"\n"}'\
'Capacity: {.status.capacity.cpu}{"\n"}'
Allocatable: 7500m
Capacity: 8
3.4. Déterminez le nombre de pods allouables pour le nœud.
126 DO180-OCP4.14-fr-2-20240530

'{.status.allocatable.pods}{"\n"}'
250
3.5. Utilisez la commande describe pour afficher les événements, les demandes de
ressources ainsi que les limites de ressources pour le nœud. La sortie peut être
différente sur votre système.
[student@workstation ~]$ oc describe node master01

Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 3158m (42%) 980m (13%)
memory 12667Mi (66%) 1250Mi (6%)
ephemeral-storage 0 (0%) 0 (0%)
hugepages-1Gi 0 (0%) 0 (0%)
hugepages-2Mi 0 (0%) 0 (0%)
Events:
---- ------ ---- ---- -------
Normal Starting 106m kubelet Starting
kubelet.
Normal NodeHasSufficientMemory 106m (x9 over 106m) kubelet Node master01
status is now: NodeHasSufficientMemory
Normal NodeHasNoDiskPressure 106m (x7 over 106m) kubelet Node master01
status is now: NodeHasNoDiskPressure
Normal NodeHasSufficientPID 106m (x7 over 106m) kubelet Node master01
status is now: NodeHasSufficientPID
4. Récupérez les journaux et l’état des services systemd sur le nœud master01.
4.1. Affichez les journaux du nœud. Filtrez les journaux afin d’afficher le journal le plus
récent pour le service crio. Les journaux peuvent être différents sur votre système.
[student@workstation ~]$ oc adm node-logs master01 -u crio --tail 1

-- Logs begin at Thu 2023-02-09 21:19:09 UTC, end at Thu 2023-03-09 16:57:00 UTC.
--
Mar 09 02:39:29.158989 master01 crio[3201]: time="2023-03-09 02:39:29.158737393Z"
level=info msg="Image status: &ImageStatusResponse
4.2. Affichez les deux journaux les plus récents du service kubelet sur le nœud. Les
journaux peuvent être différents sur votre système.
DO180-OCP4.14-fr-2-20240530 127
[student@workstation ~]$ oc adm node-logs master01 -u kubelet --tail 2

--
Mar 09 02:40:57.466711 master01 systemd[1]: Stopped Kubernetes Kubelet.
Mar 09 02:40:57.466835 master01 systemd[1]: kubelet.service: Consumed 1h 27min
8.069s CPU time
--
Mar 09 16:58:52.133046 master01 kubenswrapper[3195]: I0309 16:58:52.132866 3195
kubelet_getters.go:182] "Pod status updated" pod="openshift-etcd/etcd-master01"
status=Running
kubelet_getters.go:182] "Pod status updated" pod="openshift-kube-apiserver/kube-
apiserver-master01" status=Running
4.3. Créez une session de débogage pour le nœud. Utilisez ensuite la commande
chroot /host pour accéder aux binaires de l’hôte.
[student@workstation ~]$ oc debug node/master01

Starting pod/master01-debug-khltm ...
To use host binaries, run `chroot /host`
Pod IP: 192.168.50.10
sh-5.1#
4.4. Vérifiez le statut du service kubelet.
sh-5.1# systemctl status kubelet

● kubelet.service - Kubernetes Kubelet
Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; preset: disabled)
Drop-In: /etc/systemd/system/kubelet.service.d
└─01-kubens.conf, 10-mco-default-madv.conf, 20-logging.conf, 20-
nodenet.conf
Active: active (running) since Thu 2023-03-09 14:54:51 UTC; 2h 8min ago
Main PID: 3195 (kubelet)
Tasks: 28 (limit: 127707)
Memory: 540.7M
CPU: 18min 32.117s
Appuyez sur Ctrl+C pour quitter la commande.
4.5. Vérifiez que le service crio est actif.
sh-5.1# systemctl is-active crio

active
4.6. Quittez le pod de débogage.
128 DO180-OCP4.14-fr-2-20240530
sh-5.1# exit
exit
sh-4.4# exit
exit
Removing debug pod ...
5. Récupérez des informations de débogage pour le cluster.
5.1. Récupérez les informations de débogage du cluster à l’aide de la commande oc adm

must-gather. Spécifiez le répertoire /home/student/must-gather comme
répertoire de destination. L’exécution de cette commande peut prendre plusieurs
minutes.
[student@workstation ~]$ oc adm must-gather --dest-dir /home/student/must-gather

[must-gather ] OUT Using must-gather plug-in image: quay.io/openshift-
release-dev/ocp-v4.0-art-dev@sha256:07d3...e94c
Reprinting Cluster State:
When opening a support case, bugzilla, or issue please include the following
summary data along with any other requested information:
ClusterID: 94ff22c1-88a0-44cf-90f6-0b7b8b545434
ClusterVersion: Stable at "4.14.0"
ClusterOperators:
All healthy and stable
5.2. Vérifiez que les informations de débogage sont présentes dans le répertoire
de destination. Répertoriez les cinq derniers journaux du service kubelet, et
vérifiez qu’une erreur s’est produite lors de la mise en proxy des données de
l’adresse IP 192.168.50.10. Remplacez quay-io… par le nom du répertoire généré.
[student@workstation ~]$ ls ~/must-gather

event-filter.html
quay-io-openshift-release-dev-ocp-v4-0-art-dev-sha256-07d3...e94c
timestamp
[student@workstation ~]$ tail -5 \
~/must-gather/quay-io.../host_service_logs/masters/kubelet_service.log
logs.go:323] "Finished parsing log file" path="/var/log/pods/openshift-service-
ca_service-ca-5d96446959-69jq8_c9800778-c955-4b89-9bce-9f043237c986/service-ca-
controller/9.log"
Mar 09 01:12:12.771111 master01 kubenswrapper[3275]: E1206 01:12:12.770971
3275 upgradeaware.go:426] Error proxying data from client to backend: readfrom
tcp 192.168.50.10:44410->192.168.50.10:10010: write tcp 192.168.50.10:44410-
>192.168.50.10:10010: write: broken pipe
5.3. Générez des informations de débogage pour l’opérateur de cluster openshift-

apiserver. Spécifiez le répertoire /home/student/inspect comme répertoire
de destination. Limitez les informations de débogage aux cinq dernières minutes.
DO180-OCP4.14-fr-2-20240530 129
[student@workstation ~]$ oc adm inspect clusteroperator/openshift-apiserver \

--dest-dir /home/student/inspect --since 5m
Gathering data for ns/openshift-config...
Gathering data for ns/openshift-config-managed...
Gathering data for ns/openshift-kube-apiserver-operator...
Gathering data for ns/openshift-kube-apiserver...
Gathering data for ns/openshift-etcd-operator...
Wrote inspect data to /home/student/inspect.
5.4. Vérifiez que les informations de débogage sont présentes dans le répertoire
de destination et examinez le fichier cluster.yaml du répertoire ~/
inspect/cluster-scoped-resources/operator.openshift.io/
openshiftapiservers.
[student@workstation ~]$ ls inspect/

cluster-scoped-resources
event-filter.html
namespaces
timestamp
[student@workstation ~]$ cat \
~/inspect/cluster-scoped-resources/operator.openshift.io/\
openshiftapiservers/cluster.yaml
apiVersion: operator.openshift.io/v1
kind: OpenShiftAPIServer
metadata:
annotations:
include.release.openshift.io/ibm-cloud-managed: "true"
include.release.openshift.io/self-managed-high-availability: "true"
include.release.openshift.io/single-node-developer: "true"
release.openshift.io/create-only: "true"
creationTimestamp: "2023-12-12T16:03:42Z"
generation: 3
managedFields:
- apiVersion: operator.openshift.io/v1
fieldsType: FieldsV1
fieldsV1:
f:metadata:
f:annotations:
.: {}
5.5. Supprimez les informations de débogage de votre système.
[student@workstation ~]$ rm -rf must-gather inspect
Fin
130 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ lab finish cli-health
DO180-OCP4.14-fr-2-20240530 131
Open Lab
API et interfaces de ligne de commande

Recherchez des informations détaillées sur votre cluster OpenShift et évaluez son intégrité
en interrogeant ses ressources Kubernetes.
Résultats
• Utiliser la ligne de commande pour récupérer des informations sur les ressources du
cluster.
• Identifier les opérateurs de cluster et les ressources d’API.
• Listez les ressources avec espace de noms disponibles.
• Identifiez les ressources qui appartiennent au groupe d’API principal.
• Listez les types de ressources fournis par le groupe d’API oauth.openshift.io.
• Afficher l’utilisation des ressources des conteneurs dans un pod.
• Utiliser le filtre JSONPath pour obtenir le nombre de ressources de calcul et de pods

allouables pour un nœud.
• Afficher l’utilisation de la mémoire et du processeur de tous les pods du cluster.
• Utiliser des filtres jq pour récupérer l’état conditions d’un pod.
Avant De Commencer
[student@workstation ~]$ lab start cli-review
Instructions
L’URL de l’API de votre cluster OpenShift est https://api.ocp4.example.com:6443, et la
commande oc est déjà installée sur votre machine workstation.
Connectez-vous au cluster OpenShift en tant qu’utilisateur developer avec le mot de passe

developer. Utilisez le projet cli-review pour votre travail.
1. Connectez-vous au cluster OpenShift et créez le projet cli-review.
2. Utilisez la commande oc pour lister les informations suivantes pour le cluster :
• Récupérez la version du cluster.
• Identifiez les versions d’API prises en charge.
132 DO180-OCP4.14-fr-2-20240530
• Identifiez les champs de l’objet pod.spec.securityContext.

3. À partir du terminal, connectez-vous au cluster OpenShift en tant qu’utilisateur admin
avec le mot de passe redhatocp. Utilisez ensuite la ligne de commande pour identifier les
ressources de cluster suivantes :
• Listez les opérateurs de cluster.
• Identifiez les ressources avec espace de noms disponibles.
• Listez les événements dans l’espace de noms openshift-kube-controller-

manager.
4. Identifiez les informations suivantes sur les services de cluster et ses nœuds :
• Récupérer l’état conditions du pod etcd-master01 dans l’espace de noms

openshift-etcd en utilisant des filtres jq pour limiter la sortie.
• Afficher l’utilisation des ressources de calcul des conteneurs dans le pod etcd-master01
de l’espace de noms openshift-etcd.
• Obtenir le nombre de pods allouables pour le nœud master01 à l’aide d’un filtre
JSONPath.
• Récupérer la consommation de ressources de calcul du nœud master01.
• Récupérer la capacité et le processeur pouvant être alloué pour le nœud master01 en

utilisant un filtre JSONPath.
5. Récupérez des informations de débogage pour le cluster. Spécifiez le répertoire /home/
student/DO180/labs/cli-review/debugging comme répertoire de destination.
Ensuite, générez des informations de débogage pour l’opérateur de cluster kube-
apiserver. Spécifiez le répertoire /home/student/DO180/labs/cli-review/
inspect comme répertoire de destination. Limitez les informations de débogage aux cinq
dernières minutes.
Évaluation
En tant qu’utilisateur student sur la machine workstation, utilisez la commande lab pour
évaluer votre travail. Corrigez toute erreur signalée et répétez la commande tant que des erreurs
persistent.
[student@workstation ~]$ lab grade cli-review
Fin
DO180-OCP4.14-fr-2-20240530 133
[student@workstation ~]$ lab finish cli-review
134 DO180-OCP4.14-fr-2-20240530
Solution

Recherchez des informations détaillées sur votre cluster OpenShift et évaluez son intégrité
en interrogeant ses ressources Kubernetes.
Résultats
• Utiliser la ligne de commande pour récupérer des informations sur les ressources du
cluster.
• Identifier les opérateurs de cluster et les ressources d’API.
• Listez les ressources avec espace de noms disponibles.
• Afficher l’utilisation des ressources des conteneurs dans un pod.
• Utiliser le filtre JSONPath pour obtenir le nombre de ressources de calcul et de pods

allouables pour un nœud.
• Utiliser des filtres jq pour récupérer l’état conditions d’un pod.
Avant De Commencer
[student@workstation ~]$ lab start cli-review
Instructions

developer. Utilisez le projet cli-review pour votre travail.
1. Connectez-vous au cluster OpenShift et créez le projet cli-review.
DO180-OCP4.14-fr-2-20240530 135

1.2. Créez le projet cli-review.
[student@workstation ~]$ oc new-project cli-review

Now using project "cli-review" on server "https://api.ocp4.example.com:6443".
2. Utilisez la commande oc pour lister les informations suivantes pour le cluster :
• Récupérez la version du cluster.
• Identifiez les versions d’API prises en charge.
• Identifiez les champs de l’objet pod.spec.securityContext.
2.1. Identifiez la version du cluster.
[student@workstation ~]$ oc version

Client Version: 4.14.0
Kustomize Version: v5.0.1
Kubernetes Version: v1.27.6+f67aeb3
2.2. Identifiez les versions d’API prises en charge.
[student@workstation ~]$ oc api-versions

apiextensions.k8s.io/v1
apiregistration.k8s.io/v1
apiserver.openshift.io/v1
apps.openshift.io/v1
apps/v1
2.3. Identifiez les champs de l’objet pod.spec.securityContext.
[student@workstation ~]$ oc explain pod.spec.securityContext

KIND: Pod
VERSION: v1
FIELD: securityContext <PodSecurityContext>
DESCRIPTION:
3. À partir du terminal, connectez-vous au cluster OpenShift en tant qu’utilisateur admin

avec le mot de passe redhatocp. Utilisez ensuite la ligne de commande pour identifier les
ressources de cluster suivantes :
• Listez les opérateurs de cluster.
136 DO180-OCP4.14-fr-2-20240530
• Identifiez les ressources avec espace de noms disponibles.
• Listez les événements dans l’espace de noms openshift-kube-controller-

manager.

3.2. Listez les opérateurs de cluster.
[student@workstation ~]$ oc get clusteroperators

NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE
authentication 4.14.0 True False False 12h
3.3. Listez les ressources avec espace de noms disponibles.
[student@workstation ~]$ oc api-resources --namespaced

persistentvolumeclaims pvc v1 true PersistentVolumeClaim
pods po v1 true Pod
3.4. Identifiez les ressources qui appartiennent au groupe d’API principal.
[student@workstation ~]$ oc api-resources --api-group ''

DO180-OCP4.14-fr-2-20240530 137

3.5. Listez les types de ressources fournis par le groupe d’API oauth.openshift.io.
[student@workstation ~]$ oc api-resources --api-group oauth.openshift.io

oauthaccesstokens oauth.openshift.io/v1 false OAuthAccessToken
oauthauthorizationtokens oauth.openshift.io/v1 false
OAutheAuthorizationToken
3.6. Récupérez les événements pour l’espace de noms openshift-kube-controller-

manager.
[student@workstation ~]$ oc get events -n openshift-kube-controller-manager

LAST SEEN TYPE REASON OBJECT ...
48m Normal CreatedSCCRanges pod/kube-controller-manager-master ...
4. Identifiez les informations suivantes sur les services de cluster et ses nœuds :
• Récupérer l’état conditions du pod etcd-master01 dans l’espace de noms

openshift-etcd en utilisant des filtres jq pour limiter la sortie.
• Afficher l’utilisation des ressources de calcul des conteneurs dans le pod etcd-master01
de l’espace de noms openshift-etcd.
• Obtenir le nombre de pods allouables pour le nœud master01 à l’aide d’un filtre
JSONPath.
• Récupérer la consommation de ressources de calcul du nœud master01.
• Récupérer la capacité et le processeur pouvant être alloué pour le nœud master01 en

utilisant un filtre JSONPath.
4.1. Récupérez l’état conditions du pod etcd-master01 dans l’espace de

noms openshift-etcd. Utilisez des filtres jq pour limiter la sortie à l’attribut
.status.conditions du pod.
[student@workstation ~]$ oc get pods etcd-master01 -n openshift-etcd \

-o json | jq .status.conditions
[
{
"status": "True",
"type": "Initialized"
},
{
138 DO180-OCP4.14-fr-2-20240530
"status": "True",
"type": "Ready"
},
{
"status": "True",
"type": "ContainersReady"
},
{
"status": "True",
"type": "PodScheduled"
}
]
4.2. Affichez l’utilisation des ressources des conteneurs dans le pod etcd-master01 de
l’espace de noms openshift-etcd.
[student@workstation ~]$ oc adm top pods etcd-master01 \

-n openshift-etcd --containers
4.3. Utilisez un filtre JSONPath pour déterminer le nombre de pods allouables pour le
nœud master01.
[student@workstation ~]$ oc get node master01 \

-o jsonpath='{.status.allocatable.pods}{"\n"}'
250
4.4. Afficher l’utilisation de la mémoire et du processeur de tous les pods du cluster. Utilisez
l’option --sum pour imprimer la somme de l’utilisation des ressources. L’utilisation des
ressources sur votre système diffère probablement.
[student@workstation ~]$ oc adm top pods -A --sum

NAMESPACE NAME CPU(cores) MEMORY(bytes)
metallb-system controller-5f6dfd8c4f-ddr8v 0m 56Mi
metallb-system metallb-operator-controller-manager-... 0m 50Mi
metallb-system metallb-operator-webhook-server-... 0m 26Mi
metallb-system speaker-2dds4 9m 210Mi
-------- --------
505m 8982Mi
4.5. Récupérez la consommation de ressources du nœud master01.
DO180-OCP4.14-fr-2-20240530 139
[student@workstation ~]$ oc adm top node

master01 1199m 15% 12555Mi 66%
4.6. Utilisez un filtre JSONPath pour déterminer la capacité et le processeur pouvant être
alloué pour le nœud master01.

'Allocatable: {.status.allocatable.cpu}{"\n"}'\
'Capacity: {.status.capacity.cpu}{"\n"}'
Allocatable: 7500m
Capacity: 8
5. Récupérez des informations de débogage pour le cluster. Spécifiez le répertoire /home/

student/DO180/labs/cli-review/debugging comme répertoire de destination.
Ensuite, générez des informations de débogage pour l’opérateur de cluster kube-
apiserver. Spécifiez le répertoire /home/student/DO180/labs/cli-review/
inspect comme répertoire de destination. Limitez les informations de débogage aux cinq
dernières minutes.
5.1. Récupérez des informations de débogage pour le cluster. Enregistrez la sortie dans le
répertoire /home/student/DO180/labs/cli-review/debugging.
[student@workstation ~]$ oc adm must-gather \

--dest-dir /home/student/DO180/labs/cli-review/debugging
[must-gather ] OUT Using must-gather plug-in image: quay.io/openshift-
release-dev/ocp-v4.0-art-dev@sha256:07d3...e94c
Reprinting Cluster State:
When opening a support case, bugzilla, or issue please include the following
summary data along with any other requested information:
ClusterID: 94ff22c1-88a0-44cf-90f6-0b7b8b545434
ClusterVersion: Stable at "4.14.0"
ClusterOperators:
All healthy and stable
5.2. Générez des informations de débogage pour l’opérateur de cluster kube-apiserver.

Enregistrez la sortie dans le répertoire /home/student/DO180/labs/cli-review/
inspect et limitez les informations de débogage aux cinq dernières minutes.
[student@workstation ~]$ oc adm inspect clusteroperator kube-apiserver \

--dest-dir /home/student/DO180/labs/cli-review/inspect --since 5m
Gathering data for ns/metallb-system...
Wrote inspect data to /home/student/DO180/labs/cli-review/inspect.
Évaluation
persistent.
140 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ lab grade cli-review
Fin
[student@workstation ~]$ lab finish cli-review
DO180-OCP4.14-fr-2-20240530 141
Quiz

En tant qu’utilisateur student sur la machine workstation, connectez-vous au cluster

OpenShift en tant qu’utilisateur admin avec le mot de passe redhatocp.

Utilisez ensuite les commandes oc pour répondre aux questions suivantes :
1. Quelle ressource d’API prise en charge est membre de l’api-group

oauth.openshift.io ?
a. groupoauthaccesstokens
b. tokenreviews
c. cloudcredentials
d. networkpolicies
2. Quels sont les deux champs qui sont membres de l’objet

pod.spec.securityContext ? (Choisissez-en deux.)
a. readinessGates
b. runAsUser
c. sysctls
d. priorityClassName
3. Quelles sont les trois commandes qui affichent les conditions du nœud master01 ?
a. oc get node/master01 -o json | jq '.status.conditions'
b. oc get node/master01 -o wide
c. oc get node/master01 -o yaml
d. oc get node/master01 -o json
4. Sélectionnez les deux types de condition valides pour un nœud du plan de contrôle.
(Choisissez-en deux.)
a. PIDPressure
b. DiskIOPressure
c. OutOfMemory
d. Ready
142 DO180-OCP4.14-fr-2-20240530
5. Sélectionnez trois options valides pour la commande oc adm top pods. (Choisissez-
en trois.)
a. -A
b. --sum
c. --pod-selector
d. --containers
6. Quelle commande détermine l’adresse IP interne attribuée sur le nœud master01 ?

a. oc get nodes master01 -o=jsonpath='{.status.addresses}{"\n"}'
b. oc get nodes master01 -o json | jq .status.nodeInfo
c. oc get nodes master01 -o=jsonpath='{.status.conditions}{"\n"}'
7. Quelle commande affiche uniquement les conditions pour l’opérateur de cluster

authentication ?
a. oc get clusteroperators.config.openshift.io authentication -o json
| jq .status.versions
b. oc get clusteroperators.config.openshift.io authentication -o json
| jq .status
c. oc get clusteroperators.config.openshift.io authentication -o json
| jq .status.conditions
DO180-OCP4.14-fr-2-20240530 143
Solution

En tant qu’utilisateur student sur la machine workstation, connectez-vous au cluster

OpenShift en tant qu’utilisateur admin avec le mot de passe redhatocp.

Utilisez ensuite les commandes oc pour répondre aux questions suivantes :
1. Quelle ressource d’API prise en charge est membre de l’api-group

oauth.openshift.io ?
a. groupoauthaccesstokens
b. tokenreviews
c. cloudcredentials
d. networkpolicies
2. Quels sont les deux champs qui sont membres de l’objet

pod.spec.securityContext ? (Choisissez-en deux.)
a. readinessGates
b. runAsUser
c. sysctls
d. priorityClassName
3. Quelles sont les trois commandes qui affichent les conditions du nœud master01 ?
a. oc get node/master01 -o json | jq '.status.conditions'
b. oc get node/master01 -o wide
c. oc get node/master01 -o yaml
d. oc get node/master01 -o json
4. Sélectionnez les deux types de condition valides pour un nœud du plan de contrôle.
(Choisissez-en deux.)
a. PIDPressure
b. DiskIOPressure
c. OutOfMemory
d. Ready
144 DO180-OCP4.14-fr-2-20240530
5. Sélectionnez trois options valides pour la commande oc adm top pods. (Choisissez-
en trois.)
a. -A
b. --sum
c. --pod-selector
d. --containers
6. Quelle commande détermine l’adresse IP interne attribuée sur le nœud master01 ?

a. oc get nodes master01 -o=jsonpath='{.status.addresses}{"\n"}'
b. oc get nodes master01 -o json | jq .status.nodeInfo
c. oc get nodes master01 -o=jsonpath='{.status.conditions}{"\n"}'
7. Quelle commande affiche uniquement les conditions pour l’opérateur de cluster

authentication ?
a. oc get clusteroperators.config.openshift.io authentication -o json
| jq .status.versions
b. oc get clusteroperators.config.openshift.io authentication -o json
| jq .status
c. oc get clusteroperators.config.openshift.io authentication -o json
| jq .status.conditions
DO180-OCP4.14-fr-2-20240530 145
Résumé
• Un cluster RHOCP peut être géré à partir de la console Web ou en utilisant les interfaces de
ligne de commande (CLI) kubectl ou oc.
• Utilisez l’option --help sur une commande pour afficher des informations détaillées sur cette
dernière.
• Les projets permettent d’isoler les ressources de votre application.
• L’authentification par token est la seule méthode dont le fonctionnement est garanti avec un
cluster RHOCP, étant donné que le SSO d’entreprise peut remplacer le formulaire de connexion
de la console Web.
• Toutes les tâches d’administration nécessitent la création, l’affichage et la modification des

ressources d’API.
• Kubernetes fournit des options de sortie au format YAML et JSON qui sont idéales pour
l’analyse et l’écriture de scripts.
• Les opérateurs permettent de surveiller les applications, d’effectuer des bilans de santé, de
gérer les mises à jour OTA (Over-the-Air) et de s’assurer que les applications restent dans l’état
que vous avez spécifié.
• La console Web RHOCP intègre des graphiques utiles pour visualiser les analyses des
ressources et des clusters.
• La console Web RHOCP fournit une interface permettant d’exécuter des requêtes Prometheus,
de visualiser des métriques et de configurer des alertes.
• La pile de surveillance est basée sur le projet Prometheus et configurée pour surveiller les
principaux composants du cluster RHOCP (par défaut).
• RHOCP offre la possibilité d’afficher des journaux dans les pods et les conteneurs en cours
d’exécution afin de faciliter la résolution des problèmes.
• Vous pouvez collecter des définitions de ressources et des journaux de service à partir de votre
cluster à l’aide de la commande oc adm must-gather.
146 DO180-OCP4.14-fr-2-20240530
chapitre 3
Exécuter des applications en

tant que conteneurs et pods
Objectif Exécuter et résoudre les problèmes des
applications en conteneur en tant que pods
Kubernetes non gérés.
Résultats • Exécuter des conteneurs dans des pods, et

identifier les espaces de noms et processus
de système d’exploitation hôtes utilisés par les
conteneurs.
• Rechercher des applications en conteneur dans
des registres de conteneurs et obtenir des
informations sur les paramètres d’exécution
des images de conteneur de la communauté et
prises en charge.
• Résoudre les problèmes liés à un pod en
démarrant des processus supplémentaires sur
ses conteneurs, en modifiant les systèmes de
fichiers éphémères et en ouvrant des tunnels
réseau à courte durée de vie.
Sections • Créer des conteneurs Linux et des pods

Kubernetes (et exercice guidé)
• Rechercher et inspecter des images de
conteneur (et exercice guidé)
• Résoudre les problèmes liés aux conteneurs et
aux pods (et exercice guidé)
Atelier • Exécuter des applications en tant que

conteneurs et pods
DO180-OCP4.14-fr-2-20240530 147
chapitre 3 | Exécuter des applications en tant que conteneurs et pods
Créer des conteneurs Linux et des pods

Kubernetes
Résultats
• Exécuter des conteneurs dans des pods, et identifier les espaces de noms et processus de
système d’exploitation hôtes utilisés par les conteneurs.
Création de conteneurs et de pods

Kubernetes et OpenShift offrent de nombreuses façons de créer des conteneurs dans des
pods. Vous pouvez utiliser l’une de ces méthodes, la commande run, avec l’interface de ligne de
commande kubectl ou oc pour créer et déployer une application dans un pod à partir d’une
image de conteneur. Une image de conteneur contient des données immuables qui définissent une
application et ses bibliothèques.
Note
Les images de conteneur sont abordées plus en détail dans une autre section de ce
cours.
La commande run utilise la syntaxe suivante :
oc run RESOURCE/NAME --image IMAGE [options]
Par exemple, la commande suivante déploie une application HTTPD Apache dans un pod nommé
web-server qui utilise l’image de conteneur registry.access.redhat.com/ubi8/
httpd-24.
[user@host ~]$ kubectl run web-server --image

registry.access.redhat.com/ubi8/httpd-24
Vous pouvez utiliser plusieurs options et indicateurs avec la commande run. L’option --command
exécute une commande personnalisée et ses arguments dans un conteneur, plutôt que la
commande par défaut définie dans l’image de conteneur. Vous devez faire suivre l’option --
command d’un double tiret (--) pour séparer la commande personnalisée et ses arguments des
options de commande run. La syntaxe suivante est utilisée avec l’option --command :
oc run RESOURCE/NAME --image IMAGE --command -- cmd arg1 ... argN
Vous pouvez également utiliser l’option de double tiret pour fournir des arguments personnalisés à
une commande par défaut dans l’image de conteneur.
kubectl run RESOURCE/NAME --image IMAGE -- arg1 arg2 ... argN
Pour démarrer une session interactive avec un conteneur dans un pod, incluez les options -
it avant le nom du pod. L’option -i indique à Kubernetes de garder ouverte la saisie standard
(stdin) sur le conteneur dans le pod. L’option -t indique à Kubernetes d’ouvrir une session
148 DO180-OCP4.14-fr-2-20240530
TTY pour le conteneur dans le pod. Vous pouvez utiliser les options -it pour démarrer un shell
distant et interactif dans un conteneur. À partir du shell distant, vous pouvez ensuite exécuter des
commandes supplémentaires dans le conteneur.
L’exemple suivant démarre un shell distant interactif, /bin/bash, dans le conteneur par défaut du
pod my-app.
[user@host ~]$ oc run -it my-app --image registry.access.redhat.com/ubi9/ubi \

--command -- /bin/bash
bash-5.1$
Note
À moins que vous n’ayez inclus les options --namespace ou -n, la commande run
crée des conteneurs dans les pods du projet sélectionné.
Vous pouvez également définir une politique de redémarrage pour les conteneurs d’un pod en
incluant l’option --restart. Une politique de redémarrage de pod détermine la façon dont le
cluster doit réagir lorsque les conteneurs de ce pod se ferment. L’option --restart a les valeurs
acceptées suivantes : Always, OnFailure et Never.
Always
Si la stratégie de redémarrage est définie sur Always, le cluster essaie en continu de
redémarrer un conteneur correctement fermé, pendant cinq minutes maximum. La politique
de redémarrage du pod par défaut est Always. Si l’option --restart est omise, le pod est
configuré avec la politique Always.
OnFailure
La définition de la politique de redémarrage du pod sur OnFailure indique au cluster
de redémarrer uniquement les conteneurs en échec dans le pod, pendant cinq minutes
maximum.
Never
Si la politique de redémarrage est définie sur Never, le cluster n’essaie pas de redémarrer les
conteneurs fermés ou en échec dans un pod. Au lieu de cela, les pods échouent et se ferment
immédiatement.
L’exemple de commande suivant exécute la commande date dans le conteneur du pod nommé
my-app, redirige la sortie de la commande date vers le terminal et définit Never comme politique
de redémarrage du pod.
[user@host ~]$ oc run -it my-app \

--image registry.access.redhat.com/ubi9/ubi \
--restart Never --command -- date
Mon Feb 20 22:36:55 UTC 2023
Pour supprimer automatiquement un pod après sa fermeture, incluez l’option --rm avec la
commande run.
DO180-OCP4.14-fr-2-20240530 149
[user@host ~]$ kubectl run -it my-app --rm \

--restart Never --command -- date
Mon Feb 20 22:38:50 UTC 2023
pod "date" deleted
Pour certaines applications en conteneur, vous devrez peut-être spécifier des variables
d’environnement pour que l’application fonctionne. Pour spécifier une variable d’environnement et
sa valeur, incluez l’option --env= avec la commande run.
[user@host ~]$ oc run mysql \

--image registry.redhat.io/rhel9/mysql-80 \
--env MYSQL_ROOT_PASSWORD=myP@$$123
pod/mysql created
Attribution d’ID d’utilisateur et de groupe

Lorsqu’un projet est créé, OpenShift ajoute au projet des annotations qui déterminent la plage
d’ID utilisateur (UID) et l’ID de groupe supplémentaire (GID) pour les pods et leurs conteneurs
dans le projet. Vous pouvez récupérer les annotations avec la commande oc describe
project project-name.
[user@host ~]$ oc describe project my-app

Name: my-app
openshift.io/requester=developer
Avec les politiques de sécurité par défaut d’OpenShift, les utilisateurs de cluster standard ne
peuvent pas choisir USER ou UID pour leurs conteneurs. Lorsqu’un utilisateur de cluster standard
crée un pod, OpenShift ignore l’instruction USER dans l’image de conteneur. Au lieu de cela,
OpenShift attribue à l’utilisateur du conteneur un UID et un GID supplémentaire à partir de la
plage identifiée dans les annotations du projet. Le GID de l’utilisateur est toujours 0, ce qui signifie
que l’utilisateur appartient au groupe root. Tous les fichiers et répertoires dans lesquels les
processus de conteneur peuvent écrire doivent avoir des autorisations en lecture et en écriture
de GID=0 et avoir le groupe root comme propriétaire. Bien que l’utilisateur dans le conteneur
appartienne au groupe root, l’utilisateur est un compte sans privilèges.
En revanche, lorsqu’un administrateur de cluster crée un pod, l’instruction USER dans l’image
de conteneur est traitée. Par exemple, si l’instruction USER de l’image de conteneur est définie
sur 0, l’utilisateur dans le conteneur est le compte avec privilèges root, avec une valeur 0 pour
l’UID. L’exécution d’un conteneur en tant que compte avec privilèges représente un risque pour
la sécurité. Un compte avec privilèges dans un conteneur dispose d’un accès illimité au système
hôte du conteneur. Un accès illimité signifie que le conteneur peut modifier ou supprimer des
fichiers système, installer des logiciels ou compromettre son hôte. Par conséquent, Red Hat vous
recommande d’exécuter les conteneurs en tant que rootless, ou en tant qu’utilisateur sans
privilèges disposant uniquement des privilèges nécessaires à l’exécution du conteneur.
150 DO180-OCP4.14-fr-2-20240530
Red Hat vous recommande également d’exécuter des conteneurs à partir de différentes
applications avec des ID utilisateur uniques. L’exécution de conteneurs à partir d’applications
différentes avec le même UID, même sans privilèges, représente un risque pour la sécurité. Si l’UID
de deux conteneurs est le même, les processus d’un conteneur peuvent accéder aux ressources
et aux fichiers de l’autre conteneur. En attribuant une plage distincte d’UID et de GID à chaque
projet, OpenShift garantit que les applications de différents projets ne s’exécutent pas avec le
même UID ou GID.
Sécurité des pods

Le contrôleur d’admission Pod Security de Kubernetes émet un avertissement lorsqu’un pod
est créé sans contexte de sécurité défini. Les contextes de sécurité accordent ou refusent
des privilèges au niveau du système d’exploitation aux pods. OpenShift utilise le contrôleur
Contraintes du contexte de sécurité pour fournir des valeurs par défaut sécurisées pour la sécurité
des pods. Vous pouvez ignorer les avertissements de sécurité des pods dans ces exercices. Les
contraintes du contexte de sécurité (SCC) sont abordés plus en détail dans le cours DO280 :
Administration de Red Hat OpenShift II : exploitation d’un cluster Kubernetes de production.
Exécuter des commandes dans des conteneurs en

cours d’exécution
Pour exécuter une commande dans un conteneur en cours d’exécution dans un pod, vous pouvez
utiliser la commande exec avec la CLI kubectl ou oc. La commande exec utilise la syntaxe
suivante :
oc exec RESOURCE/NAME -- COMMAND [args...] [options]
La sortie de la commande exécutée est envoyée à votre terminal. Dans l’exemple suivant, la
commande exec exécute la commande date dans le pod my-app.
[user@host ~]$ oc exec my-app -- date

Tue Feb 21 20:43:53 UTC 2023
La commande spécifiée est exécutée dans le premier conteneur d’un pod. Pour les pods à
plusieurs conteneurs, incluez les options -c ou --container= pour spécifier le conteneur
utilisé pour exécuter la commande. Dans l’exemple suivant, la commande date s’exécute dans un
conteneur nommé ruby-container dans le pod my-app.
[user@host ~]$ kubectl exec my-app -c ruby-container -- date

Tue Feb 21 20:46:50 UTC 2023
La commande exec accepte également les options -i et -t pour créer une session interactive
avec un conteneur dans un pod. Dans l’exemple suivant, Kubernetes envoie stdin au shell bash
dans le conteneur ruby-container à partir du pod my-app, et renvoie stdout et stderr du
shell bash au terminal.
[user@host ~]$ oc exec my-app -c ruby-container -it -- bash -il

[1000780000@ruby-container /]$
Dans l’exemple précédent, un terminal brut est ouvert dans le conteneur ruby-container. À
partir de cette session interactive vous pouvez ensuite exécuter des commandes supplémentaires
DO180-OCP4.14-fr-2-20240530 151
dans le conteneur. Pour mettre fin à la session interactive, vous devez exécuter la commande
exit dans le terminal brut.
[user@host ~]$ kubectl exec my-app -c ruby-container -it -- bash -il

[1000780000@ruby-container /]$ date
Tue Feb 21 21:16:00 UTC 2023
[1000780000@ruby-container] exit
Journaux de conteneur
Les journaux de conteneur sont la sortie standard (stdout) et la sortie d’erreur standard
(stderr) d’un conteneur. Vous pouvez récupérer les journaux à l’aide de la commande logs pod
pod-name fournie par les CLI kubectl et oc. La commande inclut les options suivantes :
-l or --selector=''
Filtrer les objets en fonction de la contrainte d’étiquette key:value spécifiée.
--tail=
Spécifier le nombre de lignes des fichiers journaux récents à afficher ; la valeur par défaut est
-1 sans sélecteurs, ce qui affiche toutes les lignes de journal.
-c or --container=
Imprimer les journaux d’un conteneur en particulier dans un pod qui en comporte plusieurs.
-f or --follow
Suivre, ou diffuser en continu, les journaux d’un conteneur.
-p or --previous=true
Imprimer les journaux d’une instance de conteneur précédente dans le pod, si elle existe.
Cette option est utile pour résoudre les problèmes liés au démarrage d’un pod, car elle
imprime les journaux de la dernière tentative.
L’exemple suivant limite la sortie de la commande oc logs aux dix fichiers journaux les plus
récents :
[user@host ~]$ oc logs postgresql-1-jw89j --tail=10

done
server stopped
Starting server...
2023-01-04 22:00:16.945 UTC [1] LOG: starting PostgreSQL 12.11 on x86_64-redhat-
linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-10), 64-bit
2023-01-04 22:00:16.946 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port
5432
2023-01-04 22:00:16.946 UTC [1] LOG: listening on IPv6 address "::", port 5432
2023-01-04 22:00:16.953 UTC [1] LOG: listening on Unix socket "/var/run/
postgresql/.s.PGSQL.5432"
2023-01-04 22:00:16.960 UTC [1] LOG: listening on Unix socket "/
tmp/.s.PGSQL.5432"
2023-01-04 22:00:16.968 UTC [1] LOG: redirecting log output to logging collector
process
2023-01-04 22:00:16.968 UTC [1] HINT: Future log output will appear in directory
"log".
Vous pouvez également utiliser la commande attach pod-name -c container-name -it

pour vous connecter et démarrer une session interactive sur un conteneur en cours d’exécution
152 DO180-OCP4.14-fr-2-20240530
dans un pod. L’option -c container-name est requise pour les pods à plusieurs conteneurs.
Si le nom du conteneur est omis, Kubernetes utilise l’annotation kubectl.kubernetes.io/
default-container sur le pod pour sélectionner le conteneur. Sinon, le premier conteneur du
pod est choisi. Vous pouvez utiliser la session interactive pour récupérer les fichiers journaux de
l’application et pour résoudre les problèmes d’application.
[user@host ~]$ oc attach my-app -it

bash-4.4$
Vous pouvez également récupérer des journaux à partir de la console Web en cliquant sur l’onglet
Logs de n’importe quel pod.
Si vous disposez de plusieurs conteneurs, vous pouvez passer de l’un à l’autre pour lister les
journaux de chacun.
DO180-OCP4.14-fr-2-20240530 153
Suppression de ressources
Vous pouvez supprimer des ressources Kubernetes, telles que des ressources de pod, avec la
commande delete. La commande delete peut supprimer des ressources par type et nom de
ressource, par type et étiquette de ressource, par saisie standard (stdin) et avec des fichiers au
format JSON ou YAML. La commande n’accepte qu’un seul type d’argument à la fois.
Par exemple, vous pouvez fournir le type et le nom de la ressource en tant qu’argument de
commande.
[user@host ~]$ oc delete pod php-app
Vous pouvez également supprimer des pods de la console Web en cliquant sur Actions, puis sur
Delete Pod dans le menu principal du pod.
Pour sélectionner des ressources en fonction de libellés, vous pouvez inclure l’option -l et le
libellé key:value en tant qu’argument de commande.
[user@host ~]$ kubectl delete pod -l app=my-app

pod "php-app" deleted
pod "mysql-db" deleted
Vous pouvez également fournir le type de ressource et un fichier au format JSON ou YAML qui
spécifie le nom de la ressource. Pour utiliser un fichier, vous devez inclure l’option -f et fournir le
chemin d’accès complet au fichier au format JSON ou YAML.
[user@host ~]$ oc delete pod -f ~/php-app.json

Vous pouvez également utiliser stdin et un fichier au format JSON ou YAML qui inclut le type et
le nom de la ressource avec la commande delete.
[user@host ~]$ cat ~/php-app.json | kubectl delete -f -

154 DO180-OCP4.14-fr-2-20240530
Les pods prennent en charge l’arrêt approprié, ce qui signifie qu’ils tentent d’arrêter leurs
processus avant que Kubernetes ne procède à leur arrêt forcé. Pour modifier le délai avant l’arrêt
forcé d’un pod, vous pouvez inclure l’indicateur --grace-period et une période en secondes
dans votre commande delete. Par exemple, pour définir le délai de grâce sur dix secondes,
utilisez la commande suivante :
[user@host ~]$ oc delete pod php-app --grace-period=10
Pour arrêter le pod immédiatement, définissez le délai de grâce sur 1 seconde. Vous pouvez
également utiliser l’indicateur --now pour définir le délai de grâce sur 1 seconde.
[user@host ~]$ oc delete pod php-app --now
Vous pouvez également forcer la suppression d’un pod avec l’option --force. Si vous forcez
la suppression d’un pod, Kubernetes n’attend pas la confirmation que les processus du pod se
sont terminés, ce qui peut laisser les processus du pod en cours d’exécution jusqu’à ce que son
nœud détecte la suppression. Par conséquent, la suppression forcée d’un pod peut entraîner
une incohérence ou une perte de données. Ne forcez la suppression des pods que si vous avez
l’assurance que les processus du pod sont terminés.
[user@host ~]$ kubectl delete pod php-app --force
Pour supprimer tous les pods d’un projet, vous pouvez inclure l’option --all.
[user@host ~]$ kubectl delete pods --all

pod "mysql-db" deleted
De même, vous pouvez supprimer un projet et ses ressources avec la commande oc delete
project project-name.
[user@host ~]$ oc delete project my-app

project.project.openshift.io "my-app" deleted
Le moteur de conteneur CRI-O

Un moteur de conteneur est nécessaire pour exécuter des conteneurs. Les nœuds de travail et de
plan de contrôle d’un cluster OpenShift Container Platform utilisent le moteur de conteneur CRI-
O pour exécuter des conteneurs. Contrairement à des outils tels que Podman ou Docker, le moteur
de conteneur CRI-O est un environnement d’exécution spécialement conçu et optimisé pour
l’exécution de conteneurs dans un cluster Kubernetes. Étant donné que CRI-O est conforme aux
normes CRI (Container Runtime Interface) de Kubernetes, le moteur de conteneur peut s’intégrer
à d’autres outils Kubernetes et OpenShift, tels que les plug-ins de mise en réseau et de stockage.
Note
Pour plus d’informations sur les normes CRI (Container Runtime Interface) de
Kubernetes, reportez-vous au référentiel CRI-API à l’adresse https://github.com/
kubernetes/cri-api.
DO180-OCP4.14-fr-2-20240530 155
CRI-O fournit une interface de ligne de commande pour gérer les conteneurs avec la commande
crictl. La commande crictl comprend plusieurs sous-commandes pour vous aider à gérer
les conteneurs. Les sous-commandes suivantes sont couramment utilisées avec la commande
crictl :
crictl pods
Affiche la liste de tous les pods sur un nœud.
crictl image
Affiche la liste de toutes les images sur un nœud.
crictl inspect
Récupère l’état d’un ou de plusieurs conteneurs.
crictl exec
Exécute une commande dans un conteneur en cours d’exécution.
crictl logs
Récupère les journaux d’un conteneur.
crictl ps
Affiche la liste des conteneurs en cours d’exécution sur un nœud.
Pour gérer des conteneurs avec la commande crictl, vous devez d’abord identifier le nœud qui
héberge vos conteneurs.
[user@host ~]$ kubectl get pods -o wide

NAME READY STATUS RESTARTS AGE IP NODE
postgresql-1-8lzf2 1/1 Running 0 20m 10.8.0.64 master01
postgresql-1-deploy 0/1 Completed 0 21m 10.8.0.63 master01
[user@host ~]$ oc get pod postgresql-1-8lzf2 -o jsonpath='{.spec.nodeName}{"\n"}'

master01
Ensuite, vous devez vous connecter au nœud identifié en tant qu’administrateur de cluster. Les
administrateurs de cluster peuvent utiliser SSH pour se connecter à un nœud ou créer un pod de
débogage pour le nœud. Les utilisateurs standard ne peuvent pas se connecter à des pods de
débogage ou en créer pour les nœuds de cluster.
En tant qu’administrateur de cluster, vous pouvez créer un pod de débogage pour un nœud à
l’aide de la commande oc debug node/node-name. OpenShift crée le pod pod/node-name-
debug dans le projet actuellement sélectionné et vous connecte automatiquement au pod.
Vous devez ensuite activer les binaires de l’hôte d’accès, tels que la commande crictl, avec la
commande chroot /host. Cette commande monte le système de fichiers root de l’hôte dans
le répertoire /host à l’intérieur du shell du pod de débogage. En remplaçant le répertoire root
par le répertoire /host, vous pouvez exécuter les binaires contenus dans le chemin d’accès de
l’exécutable de l’hôte.
[user@host ~]$ oc debug node/master01

Starting pod/master01-debug ...
To use host binaries, run chroot /host
Pod IP: 192.168.50.10
156 DO180-OCP4.14-fr-2-20240530
Après avoir activé les binaires de l’hôte, vous pouvez utiliser la commande crictl pour gérer les
conteneurs sur le nœud. Par exemple, vous pouvez utiliser les commandes crictl ps et crictl
inspect pour récupérer l’ID de processus (PID) d’un conteneur en cours d’exécution. Vous
pouvez ensuite utiliser le PID pour récupérer ou saisir les espaces de noms dans un conteneur, ce
qui est utile pour résoudre les problèmes liés aux applications.
Pour trouver le PID d’un conteneur en cours d’exécution, vous devez d’abord déterminer l’ID du
conteneur. Vous pouvez utiliser la commande crictl ps avec l’option --name pour filtrer la
sortie de la commande dans un conteneur spécifique.
sh-5.1# crictl ps --name postgresql

CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID POD
27943ae4f3024 image...7104 5...ago Running postgresql 0 5768...f015
postgresql-1...
La sortie par défaut de la commande crictl ps est une table. Vous trouverez l’ID de conteneur
court dans la colonne CONTAINER. Vous pouvez également utiliser les options -o ou --output
pour spécifier le format de la commande crictl ps en tant que JSON ou YAML, puis analyser la
sortie. La sortie analysée affiche l’ID de conteneur complet.
sh-5.1# crictl ps --name postgresql -o json | jq .containers[0].id

"2794...29a4"
Après avoir identifié l’ID de conteneur, vous pouvez utiliser la commande crictl inspect et l’ID
de conteneur pour récupérer le PID du conteneur en cours d’exécution. Par défaut, la commande
crictl inspect affiche une sortie détaillée. Vous pouvez utiliser les options -o ou --output
pour formater la sortie de la commande en JSON, en YAML, sous forme de table ou en tant
que modèle Go. Si vous spécifiez le format JSON, vous pouvez ensuite analyser la sortie avec
la commande jq. De même, vous pouvez utiliser la commande grep pour limiter la sortie de la
commande.
sh-5.1# crictl inspect -o json 27943ae4f3024 | jq .info.pid

43453
sh-5.1# crictl inspect 27943ae4f3024 | grep pid
"pid": 43453,
Après avoir déterminé le PID d’un conteneur en cours d’exécution, vous pouvez utiliser la
commande lsns -p PID pour lister les espaces de noms système d’un conteneur.
sh-5.1# lsns -p 43453

NS TYPE NPROCS PID USER COMMAND
4026531835 cgroup 530 1 root /usr/lib/systemd/systemd --switched-root
--system --deserialize 17
4026531837 user 530 1 root /usr/lib/systemd/systemd --switched-root
--system --deserialize 17
4026537853 uts 8 43453 1000690000 postgres
4026537854 ipc 8 43453 1000690000 postgres
4026537856 net 8 43453 1000690000 postgres
4026538013 mnt 8 43453 1000690000 postgres
4026538014 pid 8 43453 1000690000 postgres
DO180-OCP4.14-fr-2-20240530 157
Vous pouvez également utiliser le PID d’un conteneur en cours d’exécution avec la commande
nsenter pour entrer un espace de noms spécifique d’un conteneur en cours d’exécution. Par
exemple, vous pouvez utiliser la commande nsenter pour exécuter une commande dans un
espace de noms spécifié sur un conteneur en cours d’exécution. L’exemple suivant exécute la
commande ps -ef dans l’espace de noms de processus d’un conteneur en cours d’exécution.
sh-5.1# nsenter -t 43453 -p -r ps -ef

UID PID PPID C STIME TTY TIME CMD
1000690+ 1 0 0 18:49 ? 00:00:00 postgres
1000690+ 58 1 0 18:49 ? 00:00:00 postgres: logger
1000690+ 60 1 0 18:49 ? 00:00:00 postgres: checkpointer
1000690+ 61 1 0 18:49 ? 00:00:00 postgres: background writer
1000690+ 62 1 0 18:49 ? 00:00:00 postgres: walwriter
1000690+ 63 1 0 18:49 ? 00:00:00 postgres: autovacuum launcher
1000690+ 64 1 0 18:49 ? 00:00:00 postgres: stats collector
1000690+ 65 1 0 18:49 ? 00:00:00 postgres: logical replication
launcher
root 7414 0 0 20:14 ? 00:00:00 ps -ef
L’option -t spécifie le PID du conteneur en cours d’exécution comme PID cible pour la commande
nsenter. L’option -p indique à la commande nsenter d’entrer le processus ou l’espace de noms
pid. L’option -r définit le répertoire de niveau supérieur de l’espace de noms de processus en
tant que répertoire root, permettant ainsi aux commandes de s’exécuter dans le contexte de
l’espace de noms.
Vous pouvez également utiliser l’option -a pour exécuter une commande dans tous les espaces de
noms du conteneur.
sh-5.1# nsenter -t 43453 -a ps -ef

UID PID PPID C STIME TTY TIME CMD
1000690+ 1 0 0 18:49 ? 00:00:00 postgres
1000690+ 58 1 0 18:49 ? 00:00:00 postgres: logger
1000690+ 60 1 0 18:49 ? 00:00:00 postgres: checkpointer
1000690+ 61 1 0 18:49 ? 00:00:00 postgres: background writer
1000690+ 62 1 0 18:49 ? 00:00:00 postgres: walwriter
1000690+ 63 1 0 18:49 ? 00:00:00 postgres: autovacuum launcher
1000690+ 64 1 0 18:49 ? 00:00:00 postgres: stats collector
1000690+ 65 1 0 18:49 ? 00:00:00 postgres: logical replication
launcher
root 10058 0 0 20:45 ? 00:00:00 ps -ef
158 DO180-OCP4.14-fr-2-20240530
Références
Container Runtime Interface (CRI) CLI
https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md
A Guide to OpenShift and UIDs

https://cloud.redhat.com/blog/a-guide-to-openshift-and-uids
Pour plus d’informations sur les fichiers journaux de ressources, reportez-

vous au chapitre Viewing Logs for a Resource (Consultation des journaux
d’une ressource) de la documentation Logging (Journalisation) de Red Hat
openshift_container_platform/4.14/html-single/logging/index
Manage Containers in Namespaces by Using nsenter

https://www.redhat.com/sysadmin/container-namespaces-nsenter
DO180-OCP4.14-fr-2-20240530 159
Exercice guidé
Créer des conteneurs Linux et des pods

Kubernetes
Exécuter un conteneur de système d’exploitation de base dans un pod et comparer
l’environnement à l’intérieur du conteneur avec son nœud hôte.
Résultats
• Créer un pod avec un seul conteneur, et identifier le pod et son conteneur dans le moteur
de conteneur d’un nœud OpenShift.
• Afficher les journaux d’un conteneur en cours d’exécution.
• Récupérer des informations à l’intérieur d’un conteneur, telles que la version du système
d’exploitation (SE) et les processus en cours d’exécution.
• Identifier l’ID de processus (PID) et les espaces de noms d’un conteneur.
• Identifier les plages d’ID d’utilisateur (UID) et d’ID de groupe supplémentaire (GID) d’un
projet.
• Comparer les espaces de noms des conteneurs dans un pod et dans un autre pod.
• Examiner un pod avec plusieurs conteneurs et identifier la fonction de chaque conteneur.
Avant De Commencer
exercice.
[student@workstation ~]$ lab start pods-containers
Instructions
1. Connectez-vous au cluster OpenShift et créez le projet pods-containers. Déterminez
les plages UID et GID des pods dans le projet pods-containers.
1.1. Connectez-vous au cluster OpenShift en tant qu’utilisateur developer avec la

commande oc.

Login successful
1.2. Créez le projet pods-containers.
160 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ oc new-project pods-containers

Now using project "pods-containers" on server "https://api.ocp4.example.com:6443".
1.3. Identifiez les plages UID et GID des pods dans le projet pods-containers.
[student@workstation ~]$ oc describe project pods-containers

Name: pods-containers
Created: 28 seconds ago
Labels: kubernetes.io/metadata.name=pods-containers
pod-security.kubernetes.io/audit=restricted
pod-security.kubernetes.io/audit-version=v1.24
pod-security.kubernetes.io/warn=restricted
pod-security.kubernetes.io/warn-version=v1.24
openshift.io/requester=developer
Display Name: <none>
Description: <none>
Status: Active
Node Selector: <none>
Quota: <none>
Resource limits: <none>
Vos valeurs de plage UID et GID peuvent différer de la sortie précédente.
2. En tant qu’utilisateur developer, créez un pod appelé ubi9-user à partir d’une

image de conteneur de base UBI9. L’image est disponible dans le registre de conteneurs
registry.ocp4.example.com:8443/ubi9/ubi. Définissez la politique de
redémarrage sur Never et démarrez une session interactive. Configurez le pod pour
exécuter les commandes whoami et id afin de déterminer les UID, les groupes
supplémentaires et les GID de l’utilisateur de conteneur dans le pod. Supprimez le pod par
la suite.
Une fois le pod ubi-user supprimé, connectez-vous en tant qu’utilisateur admin,
puis recréez le pod ubi9-user. Récupérez les UID et GID de l’utilisateur de conteneur.
Comparez les valeurs à celles du pod ubi9-user que l’utilisateur developer a créé.
Supprimez le pod ubi9-user par la suite.
2.1. Utilisez la commande oc run pour créer le pod ubi9-user. Configurez le pod pour
exécuter les commandes whoami et id via une session shell bash interactive.
[student@workstation ~]$ oc run -it ubi9-user --restart 'Never' \

--image registry.ocp4.example.com:8443/ubi9/ubi \
-- /bin/bash -c "whoami && id"
1000800000
uid=1000800000(1000800000) gid=0(root) groups=0(root),1000800000
Vos valeurs peuvent différer de la sortie précédente.
DO180-OCP4.14-fr-2-20240530 161
Notez que l’utilisateur dans le conteneur a le même UID que celui identifié dans le
projet pods-containers. Cependant, le GID de l’utilisateur dans le conteneur est
toujours 0, ce qui signifie que l’utilisateur appartient au groupe root. Tous les fichiers
et répertoires dans lesquels les processus de conteneur peuvent écrire doivent avoir
des autorisations en lecture et en écriture de GID=0 et avoir le groupe root comme
propriétaire.
Bien que l’utilisateur dans le conteneur appartienne au groupe root, une valeur
d’UID supérieure à 1000 signifie que l’utilisateur est un compte sans privilèges.
Lorsqu’un utilisateur OpenShift standard, tel que l’utilisateur developer, crée un
pod, les conteneurs du pod s’exécutent en tant que comptes sans privilèges.
2.2. Supprimez le pod.
[student@workstation ~]$ oc delete pod ubi9-user

pod "ubi9-user" deleted
2.3. Connectez-vous en tant qu’utilisateur admin avec le mot de passe redhatocp.

Login successful.
You have access to 71 projects, the list has been suppressed. You can list all
projects with 'oc projects'
Using project "pods-containers".
2.4. Recréez le pod ubi9-user en tant qu’utilisateur admin. Configurez le pod pour
exécuter les commandes whoami et id via une session shell bash interactive.
Comparez les valeurs d’UID et de GID de l’utilisateur de conteneur à celles du pod
ubi9-user que l’utilisateur developer a créé.
Note
Vous pouvez ignorer les avertissements de sécurité des pods en toute sécurité
lors de l'utilisation d'un utilisateur cluster-admin qui crée des pods non gérés.
L’utilisateur admin peut créer des pods avec privilèges que le contrôleur Security
Context Constraints ne gère pas.
[student@workstation ~]$ oc run -it ubi9-user --restart 'Never' \

-- /bin/bash -c "whoami && id"
Warning: would violate PodSecurity "restricted:v1.24":
allowPrivilegeEscalation != false (container "ubi9-user" must set
securityContext.allowPrivilegeEscalation=false), unrestricted capabilities
(container "ubi9-user" must set securityContext.capabilities.drop=["ALL"]),
runAsNonRoot != true (pod or container "ubi9-user" must set
securityContext.runAsNonRoot=true), seccompProfile (pod or container "ubi9-user"
must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
root
uid=0(root) gid=0(root) groups=0(root)
162 DO180-OCP4.14-fr-2-20240530
Notez que la valeur de l’UID est 0, qui diffère de la valeur de la plage d’UID du projet
pod-containers. L’utilisateur dans le conteneur est l’utilisateur root du compte
avec privilèges et appartient au groupe root. Lorsqu’un administrateur de cluster
crée un pod, les conteneurs du pod s’exécutent par défaut en tant que compte avec
privilèges.
2.5. Supprimez le pod ubi9-user.
[student@workstation ~]$ oc delete pod ubi9-user

pod "ubi9-user" deleted
3. En tant qu’utilisateur developer, utilisez la commande oc run pour créer un pod ubi9-
date à partir d’une image de conteneur de base UBI9. L’image est disponible dans le
registre de conteneurs registry.ocp4.example.com:8443/ubi9/ubi. Définissez
la politique de redémarrage sur Never et configurez le pod pour exécuter la commande
date. Récupérez les journaux du pod ubi9-date pour vérifier que la commande date a
été exécutée. Supprimez le pod par la suite.
3.1. Connectez-vous en tant qu’utilisateur developer avec le mot de passe developer.
[student@workstation ~]$ oc login -u developer -p developer

Login successful.
You have one project on this server: "pods-containers"
Using project "pods-containers".
3.2. Créez un pod appelé ubi9-date qui exécute la commande date.
[student@workstation ~]$ oc run ubi9-date --restart 'Never' \

--image registry.ocp4.example.com:8443/ubi9/ubi -- date
pod/ubi9-date created
3.3. Attendez quelques instants que le pod soit créé. Ensuite, récupérez les journaux du
pod ubi9-date.
[student@workstation ~]$ oc logs ubi9-date

Mon Nov 28 15:02:55 UTC 2022
3.4. Supprimez le pod ubi9-date.
[student@workstation ~]$ oc delete pod ubi9-date

pod "ubi9-date" deleted
4. Utilisez la commande oc run ubi9-command -it pour créer un pod ubi9-command

avec l’image de conteneur registry.ocp4.example.com:8443/ubi9/ubi. Ajoutez /
bin/bash dans la commande oc run pour démarrer un shell interactif. Quittez les pods
et affichez les journaux du pod ubi9-command à l’aide de la commande oc logs. Ensuite,
connectez-vous au pod ubi9-command avec la commande oc attach, et exécutez la
commande suivante :
DO180-OCP4.14-fr-2-20240530 163
while true; do echo $(date); sleep 2; done
Cette commande exécute les commandes date et sleep pour générer une sortie sur
la console toutes les deux secondes. Utilisez la commande oc logs pour récupérer les
journaux du pod ubi9, et vérifiez que les journaux affichent les commandes exécutées
date et sleep.
4.1. Créez un pod appelé ubi9-command et démarrez un shell interactif.
[student@workstation ~]$ oc run ubi9-command -it \

--image registry.ocp4.example.com:8443/ubi9/ubi -- /bin/bash
bash-5.1$
4.2. Quittez la session shell.
bash-5.1$ exit
exit
Session ended, resume using 'oc attach ubi9-command -c ubi9-command -i -t' command
when the pod is running
4.3. Utilisez la commande oc logs pour afficher les journaux du pod ubi9-command.
[student@workstation ~]$ oc logs ubi9-command

bash-5.1$ [student@workstation ~]$
L’invite de commande du pod est renvoyée. La commande oc logs affiche les

sorties stdout et stderr actuelles du pod dans la console. Étant donné que
vous vous êtes déconnecté de la session interactive, la sortie stdout actuelle du
pod est l’invite de commande, et non les commandes que vous avez exécutées
précédemment.
4.4. Utilisez la commande oc attach pour vous connecter à nouveau au pod ubi9-
command. Dans le shell, exécutez la commande while true; do echo $(date);
sleep 2; done pour générer en continu la sortie stdout.
[student@workstation ~]$ oc attach ubi9-command -it

bash-5.1$ while true; do echo $(date); sleep 2; done

Mon Nov 28 15:15:16 UTC 2022
Mon Nov 28 15:15:18 UTC 2022
Mon Nov 28 15:15:20 UTC 2022
Mon Nov 28 15:15:22 UTC 2022
4.5. Ouvrez une autre fenêtre de terminal et affichez les journaux du pod ubi9-
command avec la commande oc logs. Limitez la sortie du journal aux dix dernières
entrées avec l’option --tail. Vérifiez que les journaux affichent les résultats de la
commande que vous avez exécutée dans le conteneur.
164 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ oc logs ubi9-command --tail=10

Mon Nov 28 15:15:16 UTC 2022
Mon Nov 28 15:15:18 UTC 2022
Mon Nov 28 15:15:20 UTC 2022
Mon Nov 28 15:15:22 UTC 2022
Mon Nov 28 15:15:24 UTC 2022
Mon Nov 28 15:15:26 UTC 2022
Mon Nov 28 15:15:28 UTC 2022
Mon Nov 28 15:15:30 UTC 2022
Mon Nov 28 15:15:32 UTC 2022
Mon Nov 28 15:15:34 UTC 2022
5. Identifiez le nom du conteneur dans le pod ubi9-command. Identifiez l’ID de processus

(PID) du conteneur dans le pod ubi9-command en utilisant un pod de débogage pour le
nœud hôte du pod. Utilisez la commande crictl pour identifier le PID du conteneur dans
le pod ubi9-command. Ensuite, récupérez le PID du conteneur dans le pod de débogage.
5.1. Identifiez le nom du conteneur dans le pod ubi9-command à l’aide de la

commande oc get. Spécifiez le format JSON pour la sortie de la commande.
Analysez la sortie JSON avec la commande jq pour récupérer la valeur de l’objet
.status.containerStatuses[].name.
[student@workstation ~]$ oc get pod ubi9-command -o json | \

jq .status.containerStatuses[].name
"ubi9-command"
Le pod ubi9-command a un seul conteneur du même nom.
5.2. Recherchez le nœud hôte pour le pod ubi9-command. Démarrez un pod de

débogage pour l’hôte avec la commande oc debug.
[student@workstation ~]$ oc get pods ubi9-command -o wide

NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
READINESS GATES
ubi9-command 1/1 Running 2 (16m ago) 27m 10.8.0.26 master01 <none>
<none>

Error from server (Forbidden): nodes "master01" is forbidden: User "developer"
cannot get resource "nodes" in API group "" at the cluster scope
Le pod de débogage échoue, car l’utilisateur developer ne dispose pas de

l’autorisation requise pour déboguer un nœud hôte.

Démarrez un pod de débogage pour l’hôte avec la commande oc debug. Après vous
être connecté au pod de débogage, exécutez la commande chroot /host pour
utiliser les binaires de l’hôte, tels que l’outil de ligne de commande crictl.

Login successful.
DO180-OCP4.14-fr-2-20240530 165

Pod IP: 192.168.50.10
If you don't see a command prompt, try pressing enter
5.4. Utilisez la commande crictl ps pour récupérer l’ID de conteneur ubi9-command.

Spécifiez le conteneur ubi9-command avec l’option --name et utilisez le format
de sortie JSON. Analysez la sortie JSON avec la commande jq -r pour obtenir la
sortie JSON RAW. Exportez l’ID de conteneur en tant que variable d’environnement
$CID.
Note
Lorsque vous utilisez jq sans l’indicateur -r, l’ID de conteneur est placé entre
guillemets doubles, ce qui ne fonctionne pas avec les commandes crictl. Si
l’indicateur -r n’est pas utilisé, vous pouvez ajouter | tr -d '"' à la fin de la
commande pour supprimer les guillemets doubles.
sh-5.1# crictl ps --name ubi9-command -o json | jq -r .containers[0].id

81adbc6222d79ed9ba195af4e9d36309c18bb71bc04b2e8b5612be632220e0d6
sh-5.1# CID=$(crictl ps --name ubi9-command -o json | jq -r .containers[0].id)
sh-5.1# echo $CID

81adbc6222d79ed9ba195af4e9d36309c18bb71bc04b2e8b5612be632220e0d6
Votre valeur d’ID de conteneur peut différer de la sortie précédente.
5.5. Utilisez la commande crictl inspect pour rechercher le PID du conteneur ubi9-
command. La valeur de PID se trouve dans l’objet .info.pid de la sortie crictl
inspect. Exportez le PID de conteneur ubi9-command en tant que variable
d’environnement $PID.
sh-5.1# crictl inspect $CID | grep pid

"pid": 365297,
"pids": {
"type": "pid"
}
sh-5.1# PID=365297
Vos valeurs de PID peuvent différer de la sortie précédente.
166 DO180-OCP4.14-fr-2-20240530
6. Utilisez la commande lsns pour lister les espaces de noms système du conteneur ubi9-
command. Vérifiez que les processus en cours d’exécution dans le conteneur sont isolés
dans des espaces de noms système différents.
6.1. Affichez les espaces de noms système du conteneur ubi9-command à l’aide

de la commande lsns. Spécifiez le PID avec l’option -p et utilisez la variable
d’environnement $PID. Dans la table résultante, la colonne NS contient les valeurs
d’espace de noms pour le conteneur.
sh-5.1# lsns -p $PID

NS TYPE NPROCS PID USER COMMAND
4026531835 cgroup 540 1 root /usr/lib/systemd/systemd --switched-
root --system --deserialize 16
4026531837 user 540 1 root /usr/lib/systemd/systemd --switched-
root --system --deserialize 16
4026536117 uts 1 153168 1000800000 /bin/bash
4026536118 ipc 1 153168 1000800000 /bin/bash
4026536120 net 1 153168 1000800000 /bin/bash
4026537680 mnt 1 153168 1000800000 /bin/bash
4026537823 pid 1 153168 1000800000 /bin/bash
Vos valeurs d’espace de noms peuvent différer de la sortie précédente.
7. Utilisez le pod de débogage de l’hôte pour récupérer et comparer la version du système

d’exploitation (SE) et la version du paquetage de la bibliothèque C GNU (glibc) du
conteneur ubi9-command et du nœud hôte.
7.1. Récupérez le système d’exploitation du nœud hôte à l’aide de la commande cat /

etc/redhat-release.
sh-5.1# cat /etc/redhat-release

Red Hat Enterprise Linux CoreOS release 4.14
7.2. Utilisez la commande crictl exec et la variable d’ID du conteneur $CID pour
récupérer le système d’exploitation du conteneur ubi9-command. Utilisez les options
-it pour créer un terminal interactif afin d’exécuter la commande cat /etc/
redhat-release.
sh-5.1# crictl exec -it $CID cat /etc/redhat-release

Red Hat Enterprise Linux release 9.1 (Plow)
Le conteneur ubi9-command a un système d’exploitation différent du nœud hôte.
7.3. Utilisez la commande ldd --version pour récupérer la version du paquetage

glibc du nœud hôte.
sh-5.1$ ldd --version

ldd (GNU libc) 2.28
Copyright (C) 2018 Free Software Foundation, Inc.
7.4. Utilisez la commande crictl exec et la variable d’ID du conteneur $CID pour
récupérer la version du paquetage glibc du conteneur ubi9-command. Utilisez les
DO180-OCP4.14-fr-2-20240530 167
options -it pour créer un terminal interactif afin d’exécuter la commande ldd --
version.
sh-5.1# crictl exec -it $CID ldd --version

ldd (GNU libc) 2.34
Copyright (C) 2021 Free Software Foundation, Inc.
Le conteneur ubi9-command possède une version différente du paquetage glibc

de celle de son hôte.
8. Quittez le pod master01-debug et le pod ubi9-command.
8.1. Quittez le pod master01-debug. Vous devez exécuter la commande exit pour
mettre fin à l’accès du binaire de l’hôte. Exécutez à nouveau la commande exit pour
quitter et supprimer le pod master01-debug.
sh-5.1# exit
exit
sh-4.4# exit
exit

Temporary namespace openshift-debug-bg7kn was removed.
8.2. Revenez à la fenêtre de terminal qui est connectée au pod ubi9-command. Appuyez
sur Ctrl+C, puis exécutez la commande exit. Vérifiez que le pod est encore en
cours d’exécution.
^C
bash-5.1$ exit
exit
Session ended, resume using 'oc attach ubi9-command -c ubi9-command -i -t' command
when the pod is running

ubi9-command 1/1 Running 2 (6s ago) 35m
Fin
[student@workstation ~]$ lab finish pods-containers
168 DO180-OCP4.14-fr-2-20240530
Rechercher et inspecter des images de

conteneur
Résultats
• Rechercher des applications en conteneur dans des registres de conteneurs et obtenir des
informations sur les paramètres d’exécution des images de conteneur de la communauté et
prises en charge.
Présentation d’une image de conteneur

Un conteneur est un environnement d’exécution isolé dans lequel les applications sont exécutées
en tant que processus isolés. L’isolement de l’environnement d’exécution garantit que les
applications n’interfèrent pas avec les autres conteneurs ou processus système.
Une image de conteneur contient une version empaquetée de votre application, avec toutes
les dépendances nécessaires à l’exécution de cette dernière. Les images peuvent exister sans
conteneurs. Cependant, les conteneurs dépendent des images, car ils utilisent des images de
conteneur pour compiler un environnement d’exécution afin d’exécuter des applications.
Les conteneurs peuvent être divisés en deux concepts similaires, mais distincts : les images de
conteneur et les instances de conteneur. Une image de conteneur contient des données immuables
qui définissent une application et ses bibliothèques. Vous pouvez utiliser des images de conteneur
pour créer des instances de conteneur qui exécutent des processus isolés par un ensemble
d’espaces de noms de noyau.
Vous pouvez utiliser chaque image de conteneur à plusieurs reprises pour créer de nombreuses
instances de conteneur distinctes. Ces réplicas peuvent être répartis sur plusieurs hôtes.
L’application dans un conteneur est indépendante de l’environnement hôte.
Registres d’images de conteneur

Les registres d’images sont des services proposant des images de conteneur à télécharger. Les
créateurs et les gestionnaires d’images peuvent stocker des images de conteneur et les distribuer
de manière contrôlée à des utilisateurs publics ou privés. Voici quelques exemples de registres
d’images : Quay.io, Registre Red Hat, Docker Hub et Amazon ECR.
Registre Red Hat

Red Hat distribue les images de conteneur à l’aide de deux registres :
registry.access.redhat.com (où aucune authentification n’est requise) et
registry.redhat.io (où une authentification est requise). Red Hat Ecosystem Catalog,
https://catalog.redhat.com/, fournit un utilitaire de recherche centralisée pour les deux registres.
Vous pouvez rechercher des détails techniques sur des images de conteneur dans Red Hat
Ecosystem Catalog. Ce catalogue héberge un grand nombre d’images de conteneur, y compris
celles fournies par de grands projets Open Source, comme Apache, MySQL et Jenkins.
Dans la mesure où Red Hat Ecosystem Catalog est également utilisé pour rechercher d’autres
produits logiciels que les images de conteneur, vous devez accéder à l’adresse https://
catalog.redhat.com/software/containers/explore pour rechercher spécifiquement
des images de conteneur.
DO180-OCP4.14-fr-2-20240530 169
Figure 3.4: Red Hat Ecosystem Catalog
La page de détails d’une image de conteneur vous donne des informations pertinentes à son sujet,
telles que des données techniques, les paquetages installés dans l’image ou encore une analyse
de sécurité. Vous pouvez parcourir ces options en utilisant les onglets disponibles sur le site Web.
Vous pouvez également modifier la version de l’image en sélectionnant une balise spécifique.
Figure 3.5: Red Hat Universal Base Image 9
L’équipe de sécurité interne de Red Hat examine toutes les images du catalogue de conteneurs.
Red Hat recompile tous les composants pour éviter les vulnérabilités de sécurité connues.
Les images de conteneur Red Hat offrent les avantages suivants :
• Source approuvée : toutes les images de conteneur utilisent des sources connues et approuvées
par Red Hat.
170 DO180-OCP4.14-fr-2-20240530
• Dépendances originales : aucun des paquetages de conteneurs n’est falsifié, seules des
bibliothèques connues sont incluses.
• Sans vulnérabilité : les images de conteneur sont exemptes des vulnérabilités critiques connues
dans les composants ou les couches de la plateforme.
• Protection d’exécution : toutes les applications dans les images de conteneur s’exécutent en
tant qu’utilisateurs non root afin de réduire la surface d’exposition aux applications malveillantes
ou défectueuses.
• Compatibilité avec Red Hat Enterprise Linux (RHEL) : les images de conteneur sont
compatibles avec toutes les plateformes RHEL, des systèmes nus au cloud.
• Services d’assistance Red Hat : Red Hat prend commercialement en charge la pile complète.
Note
Vous devez vous connecter au registre registry.redhat.io avec un compte de
portail client ou un compte Red Hat Developer pour utiliser les images de conteneur
stockées dans le registre.
Quay.io
Bien que le registre Red Hat ne stocke que des images provenant de Red Hat et de fournisseurs
certifiés, vous pouvez stocker vos propres images avec Quay.io, un autre registre d’images public
qui est parrainé par Red Hat. Bien que le stockage d’images publiques dans Quay soit gratuit,
certaines options ne sont disponibles que pour les clients payants. Quay propose également une
version sur site du produit, que vous pouvez utiliser pour configurer un registre d’images sur vos
propres serveurs.
Quay.io introduit des fonctions, telles que la génération d’images côté serveur, des contrôles
d’accès précis et l’analyse automatique des images pour détecter les vulnérabilités connues.
Quay.io propose des images en direct que les créateurs mettent régulièrement à jour. Les
utilisateurs de Quay.io peuvent créer leurs espaces de noms, avec un contrôle d’accès précis,
et publier les images qu’ils ont créées dans cet espace de noms. Les utilisateurs de Container
Catalog envoient (push) rarement (voire jamais) de nouvelles images, mais utilisent des images
approuvées de l’équipe Red Hat.
Figure 3.6: Page d’accueil de Quay.io
DO180-OCP4.14-fr-2-20240530 171
Registres privés
Les créateurs ou gestionnaires d’images peuvent, s’ils le souhaitent, rendre leurs images
publiques. Cependant, d’autres créateurs d’images peuvent préférer garder leurs images privées,
pour les raisons suivantes :
• Politique de confidentialité de l’entreprise et protection des secrets
• Restrictions légales et lois
• Refus de publier des images en cours de développement
Dans certains cas, les images privées sont privilégiées. Les registres privés permettent aux
créateurs d’images de contrôler leur placement, leur distribution et leur utilisation. Les images
privées sont davantage sécurisées que les images des registres publics.
Registres publics
D’autres registres publics, tels que Docker Hub et Amazon ECR, sont également disponibles
pour le stockage, le partage et la consommation d’images de conteneur. Ces registres peuvent
inclure des images officielles que les propriétaires du registre ou les utilisateurs de la communauté
du registre créent et gèrent. Par exemple, Docker Hub héberge une image officielle Docker
d’une image de conteneur WordPress. Bien que l’image de conteneur docker.io/library/
wordpress soit une image officielle Docker, elle n’est pas prise en charge par WordPress, Docker
ou Red Hat. À la place, la communauté Docker, un groupe mondial d’utilisateurs de Docker Hub,
prend en charge et gère l’image de conteneur. La prise en charge de cette image de conteneur
dépend de la disponibilité et des compétences des utilisateurs de la communauté Docker.
La consommation d’images de conteneur à partir de registres publics comporte des risques.

Par exemple, une image de conteneur peut inclure du code malveillant ou des vulnérabilités, qui
peuvent compromettre le système hôte qui exécute l’image de conteneur. Un système hôte peut
également être compromis par des images de conteneur publiques, car les images sont souvent
configurées avec l’utilisateur root avec privilèges. De plus, il se peut que le logiciel d’une image
de conteneur ne dispose pas de la licence appropriée ou enfreigne les conditions d’utilisation de la
licence.
Avant d’utiliser une image de conteneur à partir d’un registre public, examinez et vérifiez l’image
de conteneur. Assurez-vous également que vous disposez des autorisations correctes pour utiliser
le logiciel dans l’image de conteneur.
Identificateurs d’image de conteneur

Plusieurs objets fournissent des informations d’identification sur une image de conteneur.
Registry
Il s’agit d’un serveur de contenu, tel que registry.access.redhat.com, qui est utilisé
pour stocker et partager des images de conteneur. Un registre se compose d’un ou de
plusieurs référentiels qui contiennent des images de conteneur balisées.
Name
Il identifie le référentiel d’images de conteneur. Il s’agit d’une chaîne composée de lettres, de
chiffres et de certains caractères spéciaux. Ce composant fait référence au nom du répertoire,
ou du référentiel de conteneurs, dans le registre de conteneurs où se trouve l’image de
conteneur.
Prenons l’exemple du nom de domaine complet (FQDN) de l’image de conteneur

registry.access.redhat.com/ubi9/httpd-24:1-233. L’image de
172 DO180-OCP4.14-fr-2-20240530
conteneur se trouve dans le référentiel ubi9/httpd-24 du registre de conteneurs

registry.access.redhat.com.
ID/Hash
Il s’agit du code SHA (Secure Hash Algorithm) permettant d’extraire ou de
vérifier une image. L’ID d’image SHA ne peut pas changer et fait toujours
référence au même contenu d’image de conteneur. Le code ID/hash est
l’identificateur unique véritable d’une image. Par exemple, l’ID d’image
sha256:4186a1ead13fc30796f951694c494e7630b82c320b81e20c020b3b07c88898
5b fait toujours référence à l’image de conteneur registry.access.redhat.com/ubi9/
httpd-24:1-233.
Tag
Il s’agit d’une étiquette pour une image de conteneur dans un référentiel, qui permet de la
distinguer des autres images, aux fins du contrôle de version. L’étiquette (tag) vient après le
nom du référentiel de l’image et est délimitée par le signe deux-points (:).
Lorsqu’une balise d’image est omise, la balise flottante, latest, est utilisée par
défaut. Une balise flottante est un alias d’une autre balise. En revanche, une balise
fixe pointe vers une version de conteneur spécifique. Pour l’image de conteneur
registry.access.redhat.com/ubi9/httpd-24:1-233.1669634588,
1-233.1669634588 est la balise fixe de l’image et, au moment de la rédaction de ce
document, elle correspond à l’indicateur latest flottant.
Composants d’image de conteneur

Une image de conteneur est composée de plusieurs composants.
Layers
Les images de conteneur sont créées à partir d’instructions. Chaque instruction ajoute une
couche à l’image de conteneur. Chaque couche comprend les différences entre elle et la
couche suivante. Les couches sont ensuite empilées pour créer une image de conteneur en
lecture seule.
Metadata
Les métadonnées incluent les instructions et la documentation d’une image de conteneur.
Instructions et métadonnées relatives aux images de

conteneur
Les couches d’image de conteneur sont constituées d’instructions, ou d’étapes, et de
métadonnées permettant de créer l’image. Vous pouvez remplacer les instructions lors de la
création du conteneur pour ajuster l’image du conteneur en fonction de vos besoins. Certaines
instructions peuvent affecter le conteneur en cours d’exécution, tandis que d’autres sont fournies
à titre informatif uniquement.
Les instructions suivantes affectent l’état d’un conteneur en cours d’exécution :
ENV
Définit des variables d’environnement qui sont disponibles dans le conteneur. Une image
de conteneur peut inclure plusieurs instructions ENV. Tout conteneur peut reconnaître des
variables d’environnement supplémentaires qui ne sont pas listées dans ses métadonnées.
ARG
Définit des variables au moment de la compilation, généralement pour rendre une compilation
de conteneur personnalisable. Les développeurs configurent généralement les instructions
DO180-OCP4.14-fr-2-20240530 173
ENV à l’aide de l’instruction ARG. Cela s’avère utile pour préserver les variables de compilation
en vue de l’exécution.
USER
Définit l’utilisateur actif dans le conteneur. Les instructions ultérieures sont exécutées en tant
que cet utilisateur. Il est recommandé de définir un autre utilisateur que root pour des raisons
de sécurité. OpenShift ne reconnaît pas l’utilisateur dans une image de conteneur, pour les
utilisateurs de cluster standard. Seuls les administrateurs de cluster peuvent exécuter des
conteneurs (pods) avec les ID utilisateur (UID) et ID de groupe (GID) qu’ils ont choisis.
ENTRYPOINT
Définit l’exécutable à lancer au démarrage du conteneur.
CMD
Définit la commande à exécuter au démarrage du conteneur. Cette commande est transmise
à l’exécutable défini par l’instruction ENTRYPOINT. Les images de base définissent un
exécutable ENTRYPOINT par défaut qui est généralement un exécutable shell, tel que Bash.
WORKDIR
Définit le répertoire de travail actuel à l’intérieur du conteneur. Les instructions ultérieures
s’exécutent dans ce répertoire.
Les métadonnées sont utilisées à des fins de documentation et n’ont pas d’impact sur l’état d’un
conteneur en cours d’exécution. Vous pouvez également remplacer les valeurs de métadonnées
lors de la création du conteneur.
Les métadonnées suivantes sont fournies à titre indicatif uniquement et n’ont pas d’impact sur
l’état du conteneur en cours d’exécution :
EXPOSE
Indique le port réseau auquel l’application se lie dans le conteneur. Ces métadonnées ne
lient pas automatiquement le port sur l’hôte et sont utilisées uniquement à des fins de
documentation.
VOLUME
Définit l’emplacement de stockage des données en dehors du conteneur. La valeur
correspond à l’emplacement où l’environnement d’exécution de votre conteneur monte le
répertoire à l’intérieur du conteneur. Il est possible de définir plusieurs chemins pour créer
plusieurs volumes.
LABEL
Ajoute une paire clé-valeur aux métadonnées de l’image pour l’organisation et la sélection de
l’image.
Les moteurs de conteneur ne sont pas tenus de reconnaître les métadonnées d’une image de
conteneur, telles que USER ou EXPOSE. Un moteur de conteneur peut également reconnaître des
variables d’environnement supplémentaires qui ne sont pas listées dans les métadonnées d’image
de conteneur.
Images de base
Une image de base est l’image qui sert à générer l’image de conteneur qui en résulte. L’image de
base choisie détermine la distribution Linux et n’importe lequel des composants suivants :
• Gestionnaire de paquetages
• Init System
• Disposition du système de fichiers
174 DO180-OCP4.14-fr-2-20240530
• Dépendances et environnements d’exécution préinstallés
L’image de base peut également influencer des facteurs tels que la taille de l’image, la prise en
charge des fournisseurs et la compatibilité des processeurs.
Red Hat fournit des images de conteneur de niveau entreprise conçues pour constituer la couche
de système d’exploitation de base de vos applications en conteneur. Ces images de conteneur
sont conçues comme un point de départ commun pour les conteneurs, et sont connues sous le
nom d’images de base universelles (UBI, Universal Base Images). Les images de conteneur UBI
Red Hat sont des images conformes à l’Open Container Initiative (OCI) qui contiennent des parties
de Red Hat Enterprise Linux (RHEL). Les images de conteneur UBI incluent un sous-ensemble de
contenu RHEL. Elles fournissent un ensemble de langages d’exécution prédéfinis, tels que Python
et Node.js, et de référentiels DNF associés que vous pouvez utiliser pour ajouter des dépendances
d’application. Les images basées sur UBI peuvent être distribuées sans coût ni restriction. Vous
pouvez les déployer sur des plateformes Red Hat et non Red Hat, et les envoyer (push) vers le
registre de conteneurs que vous avez choisi.
Aucun abonnement Red Hat n’est requis pour utiliser ou distribuer des images basées sur UBI.
Cependant, Red Hat ne fournit une prise en charge complète des conteneurs basés sur UBI
que si les conteneurs sont déployés sur une plateforme Red Hat, telle qu’un cluster Red Hat
OpenShift Container Platform (RHOCP) ou RHEL.
Red Hat propose quatre variantes d’UBI : standard, init, minimal et micro. Toutes les
variantes UBI et les images basées sur UBI sont articulées autour de Red Hat Enterprise Linux
(RHEL) et sont disponibles dans Red Hat Container Catalog. Les principales différences sont les
suivantes :
Standard
Il s’agit de l’image UBI principale, qui comprend DNF, systemd, et des utilitaires tels que gzip
et tar.
Init
Cette image simplifie l’exécution de plusieurs applications dans un même conteneur en les
gérant avec systemd.
Minimal
Cette image est plus petite que l’image init et fournit des fonctions intéressantes. Elle
utilise le gestionnaire de paquetages minimal microdnf au lieu de la version complète de
DNF.
Micro
Cette image est la plus petite image UBI disponible, et n’inclut que le nombre minimal de
paquetages. Ainsi, cette image n’inclut pas de gestionnaire de paquetages.
Inspection et gestion d’images de conteneur

Divers outils peuvent inspecter et gérer les images de conteneur, notamment la commande oc
image et Skopeo.
Skopeo
Skopeo est un autre outil permettant d’inspecter et de gérer les images de conteneur distants.
Avec Skopeo, vous pouvez copier et synchroniser des images de conteneur à partir de différents
référentiels et registres de conteneurs. Vous pouvez également copier une image à partir d’un
référentiel distant et l’enregistrer sur un disque local. Si vous disposez des autorisations de
référentiel appropriées, vous pouvez également supprimer une image du registre de conteneurs.
Vous pouvez également utiliser Skopeo pour inspecter la configuration et le contenu d’une image
DO180-OCP4.14-fr-2-20240530 175
de conteneur, et pour lister les balises disponibles pour une image de conteneur. Contrairement à
d’autres outils d’image de conteneur, Skopeo peut s’exécuter sans compte avec privilèges, tel que
root. Skopeo n’a pas besoin d’un démon en cours d’exécution pour exécuter diverses opérations.
Skopeo est exécuté à l’aide de l’utilitaire de ligne de commande skopeo, que vous pouvez
installer avec divers gestionnaires de paquetages, tels que DNF, Brew et APT. L’utilitaire skopeo
est peut-être déjà installé sur certaines distributions basées sur Linux. Vous pouvez installer
l’utilitaire skopeo sur les systèmes Fedora, CentOS Stream 8 et versions ultérieures, et Red Hat
Enterprise Linux 8 et versions ultérieures à l’aide du gestionnaire de paquetages DNF.
[user@host ~]$ sudo dnf -y install skopeo
L’utilitaire skopeo n’est actuellement pas disponible en tant que binaire empaqueté pour les
systèmes Windows. Cependant, l’utilitaire skopeo est disponible en tant qu’image de conteneur
à partir du référentiel de conteneurs quay.io/skopeo/stable. Pour plus d’informations sur
l’image de conteneur Skopeo, reportez-vous au guide de présentation skopeoimage dans le
référentiel Skopeo (https://github.com/containers/skopeo/blob/main/contrib/
skopeoimage/README.md).
Vous pouvez également compiler skopeo à partir du code source dans un conteneur, ou
le compiler localement sans utiliser de conteneur. Reportez-vous au guide d’installation
dans le référentiel Skopeo (https://github.com/containers/skopeo/blob/main/
install.md#container-images) pour plus d’informations sur l’installation ou la compilation
de Skopeo à partir du code source.
L’utilitaire skopeo fournit des commandes pour vous aider à gérer et à inspecter les images de
conteneur et les registres d’images de conteneur. Pour les registres de conteneurs qui nécessitent
une authentification, vous devez d’abord vous connecter au registre avant de pouvoir exécuter des
commandes skopeo supplémentaires.
[user@host ~]$ skopeo login quay.io
Note
Les clusters OpenShift sont généralement configurés avec des informations
d’identification de registre. Lorsqu’un pod est créé à partir d’une image de
conteneur dans un référentiel distant, OpenShift s’authentifie auprès du registre
de conteneurs avec les informations d’identification de registre configurées, puis
extrait ou copie l’image. Étant donné qu’OpenShift utilise automatiquement les
informations d’identification du registre, vous n’avez généralement pas besoin
de vous authentifier manuellement auprès d’un registre de conteneurs lorsque
vous créez un pod. En revanche, la commande oc image et l’utilitaire skopeo
nécessitent que vous vous connectiez d’abord à un registre de conteneurs.
Après vous être connecté à un registre de conteneurs (si nécessaire), vous pouvez exécuter des
commandes skopeo supplémentaires sur des images de conteneur dans un référentiel. Lorsque
vous exécutez une commande skopeo, vous devez spécifier le transport et le nom du référentiel.
Un transport est le mécanisme permettant de transférer ou de déplacer des images de conteneur
entre des emplacements. docker et dir sont deux transports courants. Le transport docker est
utilisé pour les registres de conteneurs et le transport dir est utilisé pour les répertoires locaux.
La commande oc image et d’autres outils utilisent par défaut le transport docker. Vous
n’avez donc pas besoin de spécifier le transport lors de l’exécution des commandes. Cependant,
176 DO180-OCP4.14-fr-2-20240530
l’utilitaire skopeo ne définit pas de transport par défaut ; vous devez spécifier le transport
avec le nom de l’image de conteneur. La plupart des commandes skopeo utilisent le format
skopeo command [command options] transport://IMAGE-NAME. Par exemple, la
commande skopeo list-tags suivante liste toutes les balises disponibles dans un référentiel
de conteneurs registry.access.redhat.com/ubi9/httpd-24 à l’aide du transport
docker :
[user@host ~]$ skopeo list-tags docker://registry.access.redhat.com/ubi9/httpd-24

{
"Repository": "registry.access.redhat.com/ubi9/httpd-24",
"Tags": [
"1-229",
"1-217.1666632462",
"1-201",
"1-194.1655192191-source",
"1-229-source",
"1-194-source",
"1-201-source",
"1-217.1664813224",
"1-217.1664813224-source",
"1-210-source",
"1-233.1669634588",
"1",
"1-217.1666632462-source",
"1-233",
"1-194.1655192191",
"1-217.1665076049-source",
"1-217",
"1-233.1669634588-source",
"1-210",
"1-217.1665076049",
"1-217-source",
"1-233-source",
"1-194",
"latest"
]
}
L’utilitaire skopeo inclut d’autres commandes utiles pour la gestion des images de conteneur.
skopeo inspect
Cette commande affiche des informations de bas niveau pour un nom d’image, telles que
les variables d’environnement et les balises disponibles. Utilisez le format de commande
skopeo inspect [command options] transport://IMAGE-NAME. Vous pouvez
inclure l’indicateur --config pour afficher la configuration, les métadonnées et l’historique
d’un référentiel de conteneurs. L’exemple suivant récupère les informations de configuration
pour le référentiel de conteneurs registry.access.redhat.com/ubi9/httpd-24 :
[user@host ~]$ skopeo inspect --config

docker://registry.access.redhat.com/ubi9/httpd-24
"config": {
"User": "1001",
"ExposedPorts": {
DO180-OCP4.14-fr-2-20240530 177
"8080/tcp": {},
"8443/tcp": {}
},
"Env": [
"HTTPD_MAIN_CONF_PATH=/etc/httpd/conf",
"HTTPD_MAIN_CONF_MODULES_D_PATH=/etc/httpd/conf.modules.d",
"HTTPD_MAIN_CONF_D_PATH=/etc/httpd/conf.d",
"HTTPD_TLS_CERT_PATH=/etc/httpd/tls",
"HTTPD_VAR_RUN=/var/run/httpd",
"HTTPD_DATA_PATH=/var/www",
"HTTPD_DATA_ORIG_PATH=/var/www",
"HTTPD_LOG_PATH=/var/log/httpd"
],
"Entrypoint": [
"container-entrypoint"
],
"Cmd": [
"/usr/bin/run-httpd"
],
"WorkingDir": "/opt/app-root/src",
}
skopeo copy
Cette commande copie une image d’un emplacement ou d’un référentiel vers
un autre. Utilisez le format skopeo copy transport://SOURCE-IMAGE
transport://DESTINATION-IMAGE. Par exemple, la commande suivante copie l’image de
conteneur quay.io/skopeo/stable:latest dans le référentiel skopeo du registre de
conteneurs registry.example.com :
[user@host ~]$ skopeo copy docker://quay.io/skopeo/stable:latest \

docker://registry.example.com/skopeo:latest
skopeo delete
Cette commande supprime une image de conteneur d’un référentiel. Vous devez utiliser
le format skopeo delete [command options] transport://IMAGE-NAME.
La commande suivante supprime l’image skopeo:latest du registre de conteneurs
registry.example.com :
[user@host ~]$ skopeo delete docker://registry.example.com/skopeo:latest
skopeo sync
Cette commande synchronise une ou plusieurs images d’un emplacement avec un autre.
Utilisez-la pour copier toutes les images de conteneur d’une source vers une destination. Elle
respecte le format skopeo sync [command options] --src transport --dest
transport SOURCE DESTINATION. La commande suivante synchronise le référentiel
de conteneurs registry.access.redhat.com/ubi8/httpd-24 avec le référentiel de
conteneurs registry.example.com/httpd-24 :
[user@host ~]$ skopeo sync --src docker --dest docker \

registry.access.redhat.com/ubi8/httpd-24 registry.example.com/httpd-24
178 DO180-OCP4.14-fr-2-20240530
Informations d’identification du registre

Certains registres exigent que les utilisateurs s’authentifient. Par exemple, les conteneurs Red Hat
basés sur RHEL n’autorisent généralement pas les accès authentifiés :
[user@host ~]$ skopeo inspect docker://registry.redhat.io/rhel8/httpd-24

FATA[0000] Error parsing image name "docker://registry.redhat.io/rhel8/
httpd-24": unable to retrieve auth token: invalid username/password:
unauthorized: Please login to the Red Hat Registry using your Customer Portal
credentials. Further instructions can be found here: https://access.redhat.com/
RegistryAuthentication
Vous pouvez choisir une autre image qui ne nécessite pas d’authentification, telle que l’image
UBI 8 :
[user@host ~]$ skopeo inspect docker://registry.access.redhat.com/ubi8:latest

{
"Name": "registry.access.redhat.com/ubi8",
"Digest": "sha256:70fc...1173",
"RepoTags": [
"8.7-1054-source",
"8.6-990-source",
"8.6-754",
"8.4-203.1622660121-source",
Vous devez également exécuter la commande skopeo login pour le registre avant de pouvoir
accéder à l’image RHEL 8.
[user@host ~]$ skopeo login registry.redhat.io

Username: YOUR_USER
Password: YOUR_PASSWORD
Login Succeeded!
[user@host ~]$ skopeo list-tags docker://registry.redhat.io/rhel8/httpd-24
{
"Repository": "registry.redhat.io/rhel8/httpd-24",
"Tags": [
"1-166.1645816922",
"1-209",
"1-160-source",
"1-112",
Skopeo stocke les informations d’identification dans le fichier ${XDG_RUNTIME_DIR}/

containers/auth.json, où ${XDG_RUNTIME_DIR} fait référence à un répertoire spécifique à
l’utilisateur actuel. Les informations d’identification sont codées au format base64 :
[user@host ~]$ cat ${XDG_RUNTIME_DIR}/containers/auth.json

{
"auths": {
"registry.redhat.io": {
"auth": "dXNlcjpodW50ZXIy"
}
DO180-OCP4.14-fr-2-20240530 179
}
}
[user@host ~]$ echo -n dXNlcjpodW50ZXIy | base64 -d
user:hunter2
Note
Pour des raisons de sécurité, la commande skopeo login n’affiche pas votre mot
de passe dans la session interactive. Bien que vous ne voyiez pas ce que vous tapez,
sachez que Skopeo enregistre chaque frappe. Après avoir saisi votre mot de passe
complet dans la session interactive, appuyez sur Enter pour démarrer la connexion.
La commande oc image
L’interface de ligne de commande OpenShift fournit la commande oc image. Vous pouvez
utiliser cette commande pour inspecter, configurer et récupérer des informations sur les images
de conteneur.
La commande oc image info inspecte et récupère des informations sur une image de
conteneur. Vous pouvez utiliser la commande oc image info pour identifier le code SHA ID/
hash SHA et pour lister les couches d’image d’une image de conteneur. Vous pouvez également
consulter les métadonnées d’image de conteneur, telles que les variables d’environnement,
les ports réseau et les commandes. Si un référentiel d’images de conteneur fournit une image
de conteneur dans plusieurs architectures, telles que amd64 ou arm64, vous devez inclure la
balise --filter-by-os. Par exemple, vous pouvez exécuter la commande suivante pour
récupérer des informations sur l’image de conteneur registry.access.redhat.com/ubi9/
httpd-24:1-233 basée sur l’architecture amd64 :
[user@host ~]$ oc image info registry.access.redhat.com/ubi9/httpd-24:1-233 \

--filter-by-os amd64
Name: registry.access.redhat.com/ubi9/httpd-24:1-233
Digest: sha256:4186...985b
Image Size: 130.8MB in 3 layers
Layers: 79.12MB sha256:d74e...1cad
17.32MB sha256:dac0...a283
34.39MB sha256:47d8...5550
OS: linux
Arch: amd64
Entrypoint: container-entrypoint
Command: /usr/bin/run-httpd
Working Dir: /opt/app-root/src
User: 1001
Exposes Ports: 8080/tcp, 8443/tcp
Environment: container=oci
HTTPD_CONTAINER_SCRIPTS_PATH=/usr/share/container-scripts/httpd/
HTTPD_APP_ROOT=/opt/app-root
HTTPD_CONFIGURATION_PATH=/opt/app-root/etc/httpd.d
HTTPD_MAIN_CONF_PATH=/etc/httpd/conf
HTTPD_MAIN_CONF_MODULES_D_PATH=/etc/httpd/conf.modules.d
HTTPD_MAIN_CONF_D_PATH=/etc/httpd/conf.d
HTTPD_TLS_CERT_PATH=/etc/httpd/tls
HTTPD_VAR_RUN=/var/run/httpd
180 DO180-OCP4.14-fr-2-20240530
HTTPD_DATA_PATH=/var/www
HTTPD_DATA_ORIG_PATH=/var/www
HTTPD_LOG_PATH=/var/log/httpd
La commande oc image fournit davantage d’options pour gérer les images de conteneur.
oc image append
Utilisez cette commande pour ajouter des couches aux images de conteneur, puis envoyez
(push) l’image de conteneur à un registre.
oc image extract
Vous pouvez utiliser cette commande pour extraire ou copier des fichiers d’une image de
conteneur vers un disque local. Utilisez cette commande pour accéder au contenu d’une
image de conteneur sans exécuter au préalable l’image en tant que conteneur. Un moteur de
conteneur en cours d’exécution n’est pas requis.
oc image mirror
Cette commande copie ou mettre en miroir des images de conteneur d’un registre de
conteneurs ou d’un référentiel vers un autre. Par exemple, vous pouvez utiliser cette
commande pour mettre en miroir des images de conteneur entre des registres public et
privé. Vous pouvez également l’utiliser pour copier une image de conteneur d’un registre
vers un disque. La commande met en miroir la structure HTTP d’un registre de conteneurs
sur un répertoire sur un disque. Le répertoire sur le disque peut ensuite servir de registre de
conteneurs.
Exécution de conteneurs en tant que root

L’exécution de conteneurs en tant qu’utilisateur root constitue un risque pour la sécurité, car
une personne malintentionnée pourrait exploiter l’application, accéder au conteneur et exploiter
d’autres vulnérabilités pour s’échapper de l’environnement en conteneur dans le système hôte.
Ces personnes pourraient s’échapper de l’environnement en conteneur en exploitant des bogues
et des vulnérabilités qui sont généralement présents dans le noyau ou l’environnement d’exécution
du conteneur.
Traditionnellement, lorsqu’un attaquant accède au système de fichiers du conteneur à l’aide

d’un exploit, l’utilisateur root à l’intérieur du conteneur correspond à celui situé à l’extérieur du
conteneur. Cela signifie que si un attaquant échappe à l’isolement du conteneur, il dispose de
privilèges élevés sur le système hôte, ce qui peut causer davantage de dommages.
Les conteneurs qui ne sont pas exécutés en tant qu’utilisateur root présentent des limitations qui
peuvent les rendre inadaptés à une utilisation dans votre application. En voici quelques-unes :
Mise en conteneur non triviale

Certaines applications peuvent nécessiter l’utilisateur root. En fonction de leur architecture, il
se peut que certaines applications ne soient pas adaptées aux conteneurs en mode non root
ou qu’une meilleure compréhension soit nécessaire pour les mettre en conteneur.
Par exemple, des applications telles que HTTPd et Nginx démarrent un processus d’amorçage,
puis créent un processus avec un utilisateur sans privilèges, qui interagit avec des utilisateurs
externes. De telles applications ne sont pas faciles à mettre en conteneur en vue d’une
utilisation en mode rootless.
Red Hat fournit des versions en conteneur de HTTPd et de Nginx qui ne nécessitent pas
de privilèges root pour une utilisation en production. Vous trouverez les conteneurs dans le
registre de conteneurs Red Hat (https://catalog.redhat.com/software/containers/explore)).
DO180-OCP4.14-fr-2-20240530 181
Utilisation requise d’utilitaires avec privilèges

Les conteneurs en mode non root ne peuvent pas être liés à des ports avec privilèges, tels
que les ports 80 ou 443. Red Hat déconseille d’utiliser des ports avec privilèges, mais plutôt la
redirection de port.
De même, les conteneurs non root ne peuvent pas utiliser l’utilitaire ping par défaut, car il
nécessite des privilèges élevés pour établir des sockets bruts.
Références
Référentiel GitHub Skopeo
https://github.com/containers/skopeo
Page man skopeo(1)
182 DO180-OCP4.14-fr-2-20240530
Exercice guidé
Rechercher et inspecter des images de

conteneur
Utilisez une image de conteneur MySQL prise en charge pour exécuter des pods serveur et
client dans Kubernetes ; testez également deux images de la communauté et comparez leurs
exigences d’exécution.
Résultats
• Localiser et exécuter des images de conteneur à partir d’un registre de conteneurs.
• Inspecter les images de conteneur distant et les journaux de conteneur.
• Définir des variables d’environnement et remplacer les points d’entrée d’un conteneur.
• Accéder aux fichiers et aux répertoires d’un conteneur.
Avant De Commencer
exercice.
[student@workstation ~]$ lab start pods-images
Instructions
1. Connectez-vous au cluster OpenShift et créez le projet pods-images.

commande oc.

1.2. Créez le projet pods-images.
[student@workstation ~]$ oc new-project pods-images

2. Authentifiez-vous auprès de registry.ocp4.example.com:8443, qui est le registre

de conteneurs de la salle de classe. Ce registre privé héberge certaines copies et balises
d’images de la communauté de Docker et Bitnami, ainsi que certaines images prises en
charge de Red Hat. Utilisez skopeo pour vous connecter en tant qu’utilisateur developer,
DO180-OCP4.14-fr-2-20240530 183
puis récupérez une liste des balises disponibles pour le référentiel de conteneurs
registry.ocp4.example.com:8443/redhattraining/docker-nginx.
2.1. Utilisez la commande skopeo login pour vous connecter en tant qu’utilisateur
[student@workstation ~]$ skopeo login registry.ocp4.example.com:8443

Username: developer
Password: developer
Login Succeeded!
2.2. Le registre de la salle de classe contient une copie et des balises spécifiques
du référentiel de conteneurs docker.io/library/nginx. Utilisez la
commande skopeo list-tags pour récupérer une liste des balises disponibles
pour le référentiel de conteneurs registry.ocp4.example.com:8443/
redhattraining/docker-nginx.
[student@workstation ~]$ skopeo list-tags \

docker://registry.ocp4.example.com:8443/redhattraining/docker-nginx
{
"Repository": "registry.ocp4.example.com:8443/redhattraining/docker-nginx",
"Tags": [
"1.23",
"1.23-alpine",
"1.23-perl",
"1.23-alpine-perl"
"latest"
]
}
3. Créez un pod docker-nginx à partir de l’image de conteneur

registry.ocp4.example.com:8443/redhattraining/docker-nginx:1.23.
Examinez tout échec du pod.
3.1. Utilisez la commande oc run pour créer le pod docker-nginx.
[student@workstation ~]$ oc run docker-nginx \

--image registry.ocp4.example.com:8443/redhattraining/docker-nginx:1.23
pod/docker-nginx created
3.2. Après quelques instants, vérifiez l’état du pod docker-nginx.

docker-nginx 0/1 Error 0 4s

docker-nginx 0/1 CrashLoopBackOff 2 (17s ago) 38s
Le démarrage du pod docker-nginx a échoué.
184 DO180-OCP4.14-fr-2-20240530
3.3. Examinez l’échec du pod. Récupérez les journaux du pod docker-nginx pour
identifier une cause possible de l’échec du pod.
[student@workstation ~]$ oc logs docker-nginx

/docker-entrypoint.sh: Configuration complete; ready for start up
2022/12/02 18:51:45 [warn] 1#1: the "user" directive makes sense only if
the master process runs with super-user privileges, ignored in /etc/nginx/
nginx.conf:2
nginx: [warn] the "user" directive makes sense only if the master process runs
with super-user privileges, ignored in /etc/nginx/nginx.conf:2
2022/12/02 18:51:45 [emerg] 1#1: mkdir() "/var/cache/nginx/client_temp" failed
(13: Permission denied)
nginx: [emerg] mkdir() "/var/cache/nginx/client_temp" failed (13: Permission
denied)
Le pod n’a pas pu démarrer en raison de problèmes d’autorisation pour les répertoires
nginx.
3.4. Créez un pod de débogage pour le pod docker-nginx.
[student@workstation ~]$ oc debug pod/docker-nginx

Starting pod/docker-nginx-debug ...
Pod IP: 10.8.0.72
3.5. À partir du pod de débogage, vérifiez les autorisations des répertoires /etc/nginx
et /var/cache/nginx.
$ ls -la /etc/ | grep nginx

drwxr-xr-x. 3 root root 132 Nov 15 13:14 nginx
$ ls -la /var/cache | grep nginx

drwxr-xr-x. 2 root root 6 Oct 19 09:32 nginx
Seul l’utilisateur root est autorisé à accéder aux répertoires nginx. Le pod doit donc
s’exécuter en tant qu’utilisateur avec privilèges root pour fonctionner.
3.6. Récupérez l’ID utilisateur (UID) de l’utilisateur docker-nginx pour déterminer s’il
s’agit d’un compte avec ou sans privilèges. Quittez ensuite le pod de débogage.
$ whoami
1000820000
$ exit
Votre valeur d’UID peut différer de la sortie précédente.
DO180-OCP4.14-fr-2-20240530 185
Un UID supérieur à 0 signifie que l’utilisateur du conteneur est un compte non-root.

N’oubliez pas que les politiques de sécurité par défaut d’OpenShift empêchent les
comptes d’utilisateurs normaux, tels que l’utilisateur developer, d’exécuter des
pods et leurs conteneurs en tant que comptes avec privilèges.
3.7. Vérifiez que l’image docker-nginx:1.23 nécessite le compte avec privilèges root.
Utilisez la commande skopeo inspect --config pour afficher la configuration
de l’image.
[student@workstation ~]$ skopeo inspect --config \

docker://registry.ocp4.example.com:8443/redhattraining/docker-nginx:1.23
"config": {
"ExposedPorts": {
"80/tcp": {}
},
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"NGINX_VERSION=1.23.3",
"NJS_VERSION=0.7.9",
"PKG_RELEASE=1~bullseye"
],
"Entrypoint": [
"/docker-entrypoint.sh"
],
"Cmd": [
"nginx",
"-g",
"daemon off;"
],
"Labels": {
"maintainer": "NGINX Docker Maintainers \u003cdocker-maint@nginx.com
\u003e"
},
"StopSignal": "SIGQUIT"
},
La configuration de l’image ne définit pas les métadonnées USER, ce qui confirme

que l’image doit s’exécuter en tant qu’utilisateur avec privilèges root.
3.8. L’image de conteneur docker-nginx:1-23 doit s’exécuter en tant qu’utilisateur

disposant de privilèges root. En raison des politiques de sécurité OpenShift,
les utilisateurs de cluster standard, tels que l’utilisateur developer, ne sont pas
autorisés à exécuter des conteneurs en tant que root. Supprimez le pod docker-
nginix.
[student@workstation ~]$ oc delete pod docker-nginx

pod "docker-nginx" deleted
4. Créez un pod bitnami-mysql qui utilise une copie de l’image MySQL de la

communauté Bitnami. L’image est disponible dans le référentiel de conteneurs
registry.ocp4.example.com:8443/redhattraining/bitnami-mysql.
186 DO180-OCP4.14-fr-2-20240530
4.1. Une copie et des balises spécifiques du référentiel de conteneurs docker.io/

bitnami/mysql sont hébergées dans le registre de la salle de classe. Utilisez
la commande skopeo list-tags pour identifier les balises disponibles pour
l’image de la communauté Bitnami MySQL dans le référentiel de conteneurs
registry.ocp4.example.com:8443/redhattraining/bitnami-mysql.

docker://registry.ocp4.example.com:8443/redhattraining/bitnami-mysql
{
"Repository": "registry.ocp4.example.com:8443/redhattraining/bitnami-mysql",
"Tags": [
"8.0.31",
"8.0.30",
"8.0.29",
"8.0.28",
"latest"
]
}
4.2. Récupérez la configuration de l’image de conteneur bitnami-mysql:8.0.31.

Déterminez si l’image nécessite un compte avec privilèges en inspectant la
configuration de l’image pour les métadonnées USER.
[student@workstation ~]$ skopeo inspect --config \

docker://registry.ocp4.example.com:8443/redhattraining/bitnami-mysql:8.0.31
"config":
"User": "1001",
"ExposedPorts": {
"3306/tcp": {}
},
....output omitted...
L’image définit l’UID 1001, ce qui signifie que l’image ne nécessite pas de compte
avec privilèges.
4.3. Créez le pod bitnami-mysql avec la commande oc run. Utilisez l’image de

conteneur registry.ocp4.example.com:8443/redhattraining/bitnami-
mysql:8.0.31. Attendez quelques instants, puis récupérez l’état du pod à l’aide de
la commande oc get.
[student@workstation ~]$ oc run bitnami-mysql \

--image registry.ocp4.example.com:8443/redhattraining/bitnami-mysql:8.0.31
pod/bitnami-mysql created

bitnami-mysql 0/1 CrashLoopBackoff 2 (19s ago) 23s
Le démarrage du pod a échoué.
4.4. Examinez les journaux du pod bitnami-mysql pour déterminer la cause de l’échec.
DO180-OCP4.14-fr-2-20240530 187
[student@workstation ~]$ oc logs bitnami-mysql

mysql 16:18:00.40
mysql 16:18:00.40 Welcome to the Bitnami mysql container
mysql 16:18:00.40 Subscribe to project updates by watching https://github.com/
bitnami/containers
mysql 16:18:00.40 Submit issues and feature requests at https://github.com/
bitnami/containers/issues
mysql 16:18:00.40
mysql 16:18:00.41 INFO ==> ** Starting MySQL setup **
mysql 16:18:00.42 INFO ==> Validating settings in MYSQL_*/MARIADB_* env vars
mysql 16:18:00.42 ERROR ==> The MYSQL_ROOT_PASSWORD environment variable is empty
or not set. Set the environment variable ALLOW_EMPTY_PASSWORD=yes to allow
the container to be started with blank passwords. This is recommended only for
development.
La variable d’environnement MYSQL_ROOT_PASSWORD doit être définie pour que le

pod puisse démarrer.
4.5. Supprimez, puis recréez le pod bitnami-mysql. Spécifiez redhat123 comme

valeur pour la variable d’environnement MYSQL_ROOT_PASSWORD. Après quelques
instants, vérifiez l’état du pod.
[student@workstation ~]$ oc delete pod bitnami-mysql

pod "bitnami-mysql" deleted
[student@workstation ~]$ oc run bitnami-mysql \

--image registry.ocp4.example.com:8443/redhattraining/bitnami-mysql:8.0.31 \
--env MYSQL_ROOT_PASSWORD=redhat123
pod/bitnami-mysql created

bitnami-mysql 1/1 Running 0 20s
Le pod bitnami-mysql a démarré correctement.
4.6. Déterminez l’UID de l’utilisateur de conteneur dans le pod bitnami-mysql.

Comparez cette valeur à l’UID de l’image de conteneur et à la plage d’UID du projet
pods-images.
[student@workstation ~]$ oc exec -it bitnami-mysql -- /bin/bash -c "whoami && id"

1000820000
188 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ oc describe project pods-images

Name: pods-images
Vos valeurs pour l’UID du conteneur et la plage d’UID du projet peuvent différer de la
sortie précédente.
L’UID de l’utilisateur de conteneur est identique à la plage d’UID spécifiée dans
l’espace de noms. Notez que l’UID de l’utilisateur de conteneur ne correspond pas
à l’UID 1001 de l’image de conteneur. Pour qu’un conteneur puisse utiliser l’UID
spécifié d’une image de conteneur, le pod doit être créé avec un compte d’utilisateur
OpenShift avec privilèges, tel que l’utilisateur admin.
5. Le registre de la salle de classe privé héberge une copie d’une image MySQL prise
en charge de Red Hat. Récupérez la liste des balises disponibles pour le référentiel de
conteneurs registry.ocp4.example.com:8443/rhel9/mysql-80. Comparez la
version de l’image de conteneur rhel9/mysql-80 associée à chaque balise.
5.1. Utilisez la commande skopeo list-tags pour lister les balises disponibles pour
l’image de conteneur rhel9/mysql-80.

docker://registry.ocp4.example.com:8443/rhel9/mysql-80
{
"Repository": "registry.ocp4.example.com:8443/rhel9/mysql-80",
"Tags": [
"1-237",
"1-228",
"1-228-source",
"1-224",
"1-224-source",
"latest",
"1"
]
}
Plusieurs balises sont disponibles :
• Les balises latest et 1 sont des balises flottantes, qui sont des alias d’autres
balises, telles que la balise 1-237.
• Les balises 1-228 et 1-224 sont des balises fixes, qui pointent vers une
compilation d’un conteneur.
• Les balises 1-228-source et 1-224-source sont des conteneurs sources qui

fournissent les sources et les conditions d’utilisation de la licence nécessaires pour
recompiler et distribuer les images.
5.2. Utilisez la commande skopeo inspect pour comparer la version de l’image de

conteneur rhel9/mysql-80 et les ID SHA associés aux balises identifiées.
DO180-OCP4.14-fr-2-20240530 189
Note
Pour améliorer la lisibilité, les instructions tronquent les chaînes SHA-256.
Sur votre système, les commandes renvoient les chaînes SHA-256 complètes.
[student@workstation ~]$ skopeo inspect \

docker://registry.ocp4.example.com:8443/rhel9/mysql-80:latest
"Name": "registry.ocp4.example.com:8443/rhel9/mysql-80",
"Digest": "sha256:d282...f38f",
"Labels":
"name": "rhel9/mysql-80",
"release": "237",
Vous pouvez également formater la sortie de la commande skopeo inspect avec

un modèle Go. Ajoutez les objets du modèle avec \n pour ajouter de nouvelles lignes
entre les résultats.
[student@workstation ~]$ skopeo inspect --format \

"Name: {{.Name}}\n Digest: {{.Digest}}\n Release: {{.Labels.release}}" \
docker://registry.ocp4.example.com:8443/rhel9/mysql-80:latest
Name: registry.ocp4.example.com:8443/rhel9/mysql-80
Digest: sha256:d282...f38f
Release: 237

docker://registry.ocp4.example.com:8443/rhel9/mysql-80:1
Release: 237

docker://registry.ocp4.example.com:8443/rhel9/mysql-80:1-237
Release: 237
Les balises latest, 1 et 1-237 renvoient aux mêmes versions et ID SHA. Les balises
latest et 1 sont des balises flottantes pour la balise fixe 1-237.
6. Le registre de la salle de classe héberge une copie et certaines balises du référentiel

de conteneurs registry.redhat.io/rhel9/mysql-80. Utilisez la commande
oc run pour créer un pod rhel9-mysql à partir de l’image de conteneur
registry.ocp4.example.com:8443/rhel9/mysql-80:1-228. Vérifiez l’état du pod,
puis examinez les journaux du conteneur pour détecter d’éventuelles erreurs.
190 DO180-OCP4.14-fr-2-20240530
6.1. Créez un pod rhel9-mysql avec l’image de conteneur

registry.ocp4.example.com:8443/rhel9/mysql-80:1-237.
[student@workstation ~]$ oc run rhel9-mysql \

--image registry.ocp4.example.com:8443/rhel9/mysql-80:1-237
pod/rhel9-mysql created
6.2. Après quelques instants, récupérez l’état du pod à l’aide de la commande oc get.

bitnami-mysql 1/1 Running 0 5m16s
rhel9-mysql 0/1 CrashLoopBackoff 2 (29s ago) 49s
6.3. Récupérez les journaux du pod rhel9-mysql pour déterminer les raisons de l’échec
du pod.
[student@workstation ~]$ oc logs rhel9-mysql

=> sourcing 20-validate-variables.sh ...
You must either specify the following environment variables:
MYSQL_USER (regex: '^[a-zA-Z0-9_]+$')
MYSQL_PASSWORD (regex: '^[a-zA-Z0-9_~!@#$%^&*()-=<>,.?;:|]+$')
MYSQL_DATABASE (regex: '^[a-zA-Z0-9_]+$')
Or the following environment variable:
MYSQL_ROOT_PASSWORD (regex: '^[a-zA-Z0-9_~!@\#$%^&*()-=<>,.?;:|]+$')
Or both.
Optional Settings:
MYSQL_LOWER_CASE_TABLE_NAMES (default: 0)
Le pod a échoué, car les variables d’environnement requises n’ont pas été définies
pour le conteneur.
7. Supprimez le pod rhel9-mysql. Créez un autre pod rhel9-mysql et spécifiez les

variables d’environnement nécessaires. Récupérez l’état du pod et examinez les journaux du
conteneur pour vérifier que le nouveau pod fonctionne.
7.1. Supprimez le pod rhel9-mysql à l’aide de la commande oc delete. Attendez que

le pod soit supprimé avant de passer à l’étape suivante.
[student@workstation ~]$ oc delete pod rhel9-mysql

pod "rhel9-mysql" deleted
7.2. Créez un autre pod rhel9-mysql à partir de l’image de conteneur

registry.ocp4.example.com:8443/rhel9/mysql-80:1-237. Utilisez la
commande oc run avec l’option --env pour spécifier les variables d’environnement
suivantes et leurs valeurs :
DO180-OCP4.14-fr-2-20240530 191
Variable Valeur
MYSQL_USER redhat
MYSQL_PASSWORD redhat123
MYSQL_DATABASE worldx
[student@workstation ~]$ oc run rhel9-mysql \

--image registry.ocp4.example.com:8443/rhel9/mysql-80:1-237 \
--env MYSQL_USER=redhat \
--env MYSQL_PASSWORD=redhat123 \
--env MYSQL_DATABASE=worldx
pod/rhel9-mysql created
7.3. Après quelques instants, récupérez l’état du pod rhel9-mysql à l’aide de la

commande oc get. Affichez les journaux du conteneur pour vérifier que la base de
données sur le pod rhel9-mysql est prête à accepter des connexions.

bitnami-mysql 1/1 Running 0 10m
rhel9-mysql 1/1 Running 0 20s
[student@workstation ~]$ oc logs rhel9-mysql

2022-11-02T20:14:14.333599Z 0 [System] [MY-011323] [Server] X Plugin ready for
connections. Bind-address: '::' port: 33060, socket: /var/lib/mysql/mysqlx.sock
2022-11-02T20:14:14.333641Z 0 [System] [MY-010931] [Server] /usr/libexec/
mysqld: ready for connections. Version: '8.0.30' socket: '/var/lib/mysql/
mysql.sock' port: 3306 Source distribution.
Le pod rhel9-mysql est prêt à accepter des connexions.
8. Déterminez l’emplacement des fichiers de base de données MySQL pour le pod rhel9-
mysql. Vérifiez que le répertoire contient la base de données worldx.
8.1. Utilisez la commande oc image pour examiner l’image rhel9/mysql-80:1-228

dans le registre de la salle de classe registry.ocp4.example.com:8443.
[student@workstation ~]$ oc image info \

registry.ocp4.example.com:8443/rhel9/mysql-80:1-237
Name: registry.ocp4.example.com:8443/rhel9/mysql-80:1-237
Command: run-mysqld
Working Dir: /opt/app-root/src
User: 27
Exposes Ports: 3306/tcp
Environment: container=oci
STI_SCRIPTS_URL=image:///usr/libexec/s2i
STI_SCRIPTS_PATH=/usr/libexec/s2i
APP_ROOT=/opt/app-root
192 DO180-OCP4.14-fr-2-20240530
PATH=/opt/app-root/src/bin:/opt/app-root/bin:/usr/local/sbin:/usr/
local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PLATFORM=el9
MYSQL_VERSION=8.0
APP_DATA=/opt/app-root/src
HOME=/var/lib/mysql
Le manifeste de conteneur définit la variable d’environnement HOME de l’utilisateur de

conteneur sur le répertoire /var/lib/mysql.
8.2. Utilisez la commande oc exec pour lister le contenu du répertoire /var/lib/

mysql.
[student@workstation ~]$ oc exec -it rhel9-mysql -- ls -la /var/lib/mysql

total 12
drwxrwxr-x. 1 mysql root 102 Nov 2 20:41 .
drwxr-xr-x. 1 root root 19 Oct 24 18:47 ..
drwxrwxr-x. 1 mysql root 4096 Nov 2 20:54 data
srwxrwxrwx. 1 mysql 1000820000 0 Nov 2 20:41 mysql.sock
-rw-------. 1 mysql 1000820000 2 Nov 2 20:41 mysql.sock.lock
srwxrwxrwx. 1 mysql 1000820000 0 Nov 2 20:41 mysqlx.sock
-rw-------. 1 mysql 1000820000 2 Nov 2 20:41 mysqlx.sock.lock
Un répertoire data existe dans le répertoire /var/lib/mysql.
8.3. Utilisez à nouveau la commande oc exec pour lister le contenu du répertoire /var/
lib/mysql/data.
[student@workstation ~]$ oc exec -it rhel9-mysql \

-- ls -la /var/lib/mysql/data | grep worldx
drwxr-x---. 2 1000820000 root 6 Nov 2 20:41 worldx
Le répertoire /var/lib/mysql/data contient la base de données worldx avec le

répertoire worldx.
9. Déterminez l’adresse IP du pod rhel9-mysql. Ensuite, créez un autre pod MySQL,

nommé mysqlclient, pour accéder au pod rhel9-mysql. Vérifiez que le pod
mysqlclient peut afficher les bases de données disponibles sur le pod rhel9-mysql à
l’aide de la commande mysqlshow.
9.1. Identifiez l’adresse IP du pod rhel9-mysql.
[student@workstation ~]$ oc get pods rhel9-mysql -o json | jq .status.podIP

"10.8.0.109"
Notez l’adresse IP. Votre adresse IP peut différer de la sortie précédente.
9.2. Utilisez la commande oc run pour créer un pod mysqlclient avec l’image de
conteneur registry.ocp4.example.com:8443/rhel9/mysql-80:1-237.
Définissez la valeur de la variable d’environnement MYSQL_ROOT_PASSWORD sur
redhat123, puis vérifiez que le pod est en cours d’exécution.
DO180-OCP4.14-fr-2-20240530 193
[student@workstation ~]$ oc run mysqlclient \

--image registry.ocp4.example.com:8443/rhel9/mysql-80:1-237 \
--env MYSQL_ROOT_PASSWORD=redhat123
pod/mysqlclient created

bitnami-mysql 1/1 Running 0 15m
mysqlclient 1/1 Running 0 19s
rhel9-mysql 1/1 Running 0 5m
9.3. Utilisez la commande oc exec avec les options -it pour exécuter la commande
mysqlshow sur le pod mysqlclient. Connectez-vous en tant qu’utilisateur redhat
et spécifiez l’hôte en tant qu’adresse IP du pod rhel9-mysql. Lorsqu’un message
vous y invite, saisissez redhat123 comme mot de passe.
[student@workstation ~]$ oc exec -it mysqlclient \

-- mysqlshow -u redhat -p -h 10.8.0.109
Enter password: redhat123
+--------------------+
| Databases |
+--------------------+
| information_schema |
| performance_schema |
| worldx |
+--------------------+
La base de données worldx sur le pod rhel9-mysql est accessible au pod mysql-
client.
Fin
[student@workstation ~]$ lab finish pods-images
194 DO180-OCP4.14-fr-2-20240530
Résoudre les problèmes liés aux

conteneurs et aux pods
Résultats
• Résoudre les problèmes liés à un pod en démarrant des processus supplémentaires sur ses
conteneurs, en modifiant les systèmes de fichiers éphémères et en ouvrant des tunnels réseau à
courte durée de vie.
Présentation de la résolution des problèmes liés aux

conteneurs
Les conteneurs sont conçus pour être immuables et éphémères. Un conteneur en cours
d’exécution doit être redéployé lorsque des modifications sont nécessaires ou lorsqu’une nouvelle
image de conteneur est disponible. Cependant, vous pouvez modifier un conteneur en cours
d’exécution sans redéploiement.
Il est préférable de réserver la mise à jour d’un conteneur en cours d’exécution à la résolution des
problèmes liés aux conteneurs. Red Hat déconseille généralement de modifier un conteneur en
cours d’exécution pour corriger des erreurs dans un déploiement. Les modifications apportées
à un conteneur en cours d’exécution ne sont pas capturées dans le contrôle de source, mais
elles permettent d’identifier les corrections nécessaires au code source pour les fonctions du
conteneur. Capturez ces mises à jour de conteneur dans le contrôle de version après avoir identifié
les modifications nécessaires. Créez ensuite une image de conteneur et redéployez l’application.
Les modifications personnalisées d’un conteneur en cours d’exécution sont incompatibles avec
une architecture élégante, la fiabilité et la résilience de l’environnement.
Outils de résolution des problèmes liés à l’interface de

ligne de commande
Les administrateurs utilisent divers outils pour interagir avec les conteneurs en cours d’exécution,
les inspecter et les modifier. Les administrateurs peuvent utiliser des commandes telles que oc
get pour collecter les détails initiaux d’un type de ressource spécifié. D’autres commandes sont
disponibles pour l’inspection détaillée d’une ressource ou pour mettre à jour une ressource en
temps réel.
Note
Lorsque vous interagissez avec les conteneurs de cluster, prenez les précautions
nécessaires avec les composants, services et applications en cours d’exécution.
Utilisez ces outils pour valider les fonctions et l’environnement d’un conteneur en cours
d’exécution :
• L’interface de ligne de commande (CLI) kubectl fournit les commandes suivantes :
– kubectl describe : affiche les détails d’une ressource.
– kubectl edit : modifie une configuration de ressource à l’aide de l’éditeur système.
DO180-OCP4.14-fr-2-20240530 195
– kubectl patch : met à jour un attribut ou un champ spécifique pour une ressource.
– kubectl replace : déploie une nouvelle instance de la ressource.
– kubectl cp : copie des fichiers et des répertoires vers et depuis des conteneurs.
– kubectl exec : exécute une commande dans un conteneur spécifié.
– kubectl explain : affiche la documentation d’une ressource spécifiée.
– kubectl port-forward : configure un redirecteur de port pour un conteneur spécifié.
– kubectl logs : récupère les journaux pour un conteneur spécifié.
Outre la prise en charge des commandes kubectl précédentes, l’interface de ligne de

commande oc ajoute les commandes suivantes pour inspecter et résoudre les problèmes liés aux
conteneurs en cours d’exécution :
• L’interface de ligne de commande (CLI) oc fournit les commandes suivantes :
– oc status : affiche l’état des conteneurs dans l’espace de noms sélectionné.
– oc rsync : synchronise des fichiers et des répertoires vers et depuis des conteneurs.
– oc rsh : démarre un shell distant dans un conteneur spécifié.
Modification de ressources
La résolution des problèmes et la correction commencent souvent par une phase d’inspection et
de collecte de données. Lors de la résolution de problèmes, la commande describe peut fournir
des détails utiles sur la ressource en cours d’exécution, telles que la définition d’un conteneur et
son objectif.
L’exemple suivant illustre l’utilisation de la commande oc describe RESOURCE NAME pour

récupérer des informations sur un pod dans l’espace de noms openshift-dns :
[user@host ~]$ oc describe pod dns-default-lt13h

Name: dns-default-lt13h
Namespace: openshift-dns
Priority: 2000001000
Priority Class Name: system-node-critical
Divers outils de l’interface de ligne de commande peuvent appliquer une modification que vous
jugez nécessaire à un conteneur en cours d’exécution. La commande edit ouvre la ressource
spécifiée dans l’éditeur par défaut de votre environnement. Cet éditeur est spécifié en définissant
la variable d’environnement KUBE_EDITOR ou EDITOR, ou avec l’éditeur vi sous Linux, ou encore
avec l’application Notepad sous Windows.
L’exemple suivant montre l’utilisation de la commande oc edit RESOURCE NAME pour modifier
un conteneur en cours d’exécution :
[user@host ~]$ oc edit pod mongo-app-sw88b
# Please edit the object below. Lines beginning with a '#' will be ignored,
196 DO180-OCP4.14-fr-2-20240530
# and an empty file will abort the edit. If an error occurs while saving this file
will be
# reopened with the relevant failures.
#
apiVersion: v1
kind: Pod
metadata:
annotations:
Vous pouvez également utiliser la commande patch pour mettre à jour les champs d’une
ressource.
Dans l’exemple suivant, la commande patch est utilisée pour mettre à jour l’image de conteneur
utilisée par un pod :
[user@host ~]$ oc patch pod valid-pod --type='json' \

-p='[{"op": "replace", "path": "/spec/containers/0/image", \
"value":"http://registry.access.redhat.com/ubi8/httpd-24"}]'
Note
Pour plus d’informations sur l’application de correctifs aux ressources et sur les
différentes méthodes de fusion, consultez la page Update API Objects in Place
Using kubectl patch [https://kubernetes.io/docs/tasks/manage-kubernetes-
objects/update-api-object-kubectl-patch/].
Copier des fichiers vers et depuis des conteneurs

Les administrateurs peuvent copier des fichiers et des répertoires vers ou depuis un conteneur
pour inspecter, mettre à jour ou corriger des fonctionnalités. L’ajout d’un fichier de configuration
ou la récupération d’un journal d’application sont des cas d’utilisation courants.
Note
Pour utiliser la commande cp avec l’interface de ligne de commande kubectl
ou l’interface de ligne de commande oc, le binaire tar doit être présent dans le
conteneur. Si le binaire est absent, un message d’erreur s’affiche et l’opération
échoue.
L’exemple suivant illustre la copie d’un fichier à partir d’un conteneur en cours d’exécution vers un
répertoire local à l’aide de la commande oc cp SOURCE DEST :
[user@host ~]$ oc cp apache-app-kc82c:/var/www/html/index.html /tmp/index.bak
[user@host ~]$ ls /tmp

index.bak
L’exemple suivant illustre l’utilisation de la commande oc cp SOURCE DEST pour copier un

fichier à partir d’un répertoire local vers un répertoire dans un conteneur en cours d’exécution :
DO180-OCP4.14-fr-2-20240530 197
[user@host ~]$ oc cp /tmp/index.html apache-app-kc82c:/var/www/html/
[user@host ~]$ oc exec -it apache-app-kc82c -- ls /var/www/html

index.bak
Note
Le ciblage d’un chemin d’accès à un fichier dans un pod pour l’argument
SOURCE ou DEST utilise le format pod_name:path et peut inclure l’option -
c container_name pour spécifier un conteneur dans le pod. Si vous omettez
l’option -c container_name, la commande cible le premier conteneur du pod.
De plus, lorsque vous utilisez l’interface de ligne de commande oc, la synchronisation des fichiers
et des répertoires est disponible à l’aide de la commande oc rsync.
L’exemple suivant illustre l’utilisation de la commande oc rsync SOURCE_NAME DEST pour

synchroniser des fichiers à partir d’un conteneur en cours d’exécution vers un répertoire local :
[user@host ~]$ oc rsync apache-app-kc82c:/var/www/ /tmp/web_files
[user@host ~]$ ls /tmp/web_files

cgi-bin
html
La commande oc rsync utilise le client rsync sur votre système local pour copier les fichiers
modifiés vers et depuis un conteneur de pod. Le binaire rsync doit être disponible localement et
dans le conteneur pour cette méthode. Si le binaire rsync est introuvable, une archive tar est
créée sur le système local et envoyée au conteneur. Le conteneur utilise alors l’utilitaire tar pour
extraire les fichiers de l’archive. Sans les binaires rsync et tar, un message d’erreur s’affiche et la
commande oc rsync échoue.
Note
Pour les systèmes Linux, vous pouvez installer le client rsync et l’utilitaire tar
sur un système local à l’aide d’un gestionnaire de paquetages, tel que DNF.
Pour les systèmes Windows, vous pouvez installer le client cwRsync. Pour
plus d’informations sur le client cwRysnc, reportez-vous à l’adresse https://
www.itefix.net/cwrsync.
Accès aux conteneurs distants

L’exposition d’un port réseau pour un conteneur est une routine, en particulier pour les conteneurs
qui fournissent un service. Dans un cluster, les connexions de redirection de port sont établies
via le kubelet, qui mappe un port local de votre système à un port d’un pod. La configuration
de la redirection de port crée une demande via l’API Kubernetes et crée un flux multiplexé, tel
que HTTP/2, avec un en-tête port qui spécifie le port cible dans le pod. Le kubelet fournit les
données de flux au pod et au port cibles, et vice versa pour les données de sortie du pod.
Lorsque vous résolvez des problèmes liés à une application dont l’exécution classique ne nécessite
pas de connexion locale, vous pouvez utiliser la fonction de redirection de port pour exposer
la connectivité au pod à des fins d’enquête. Avec cette fonction, un administrateur peut se
198 DO180-OCP4.14-fr-2-20240530
connecter au nouveau port et inspecter l’application qui pose problème. Une fois le problème
résolu, l’application peut être redéployée sans la connexion de redirection de port.
L’exemple suivant illustre l’utilisation de la commande oc port-forward RESOURCE

EXTERNAL_PORT:CONTAINER_PORT pour écouter localement sur le port 8080 et pour transférer
les connexions vers le port 80 sur le pod :
[user@host ~]$ oc port-forward nginx-app-cc78k 8080:80

Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80
Se connecter à des conteneurs

Les administrateurs utilisent des outils de l’interface de ligne de commande pour se connecter à
un conteneur via un shell à des fins d’inspections approfondies. Avec cette méthode, vous pouvez
vous connecter, inspecter et exécuter toutes les commandes disponibles dans le conteneur
spécifié.
L’exemple suivant montre l’utilisation de la commande oc rsh POD_NAME pour se connecter à un

conteneur via un shell :
[user@host ~]$ oc rsh tomcat-app-jw53r

sh-4.4#
Si vous devez vous connecter à un conteneur spécifique dans un pod, utilisez l’option -
c container_name pour spécifier le nom du conteneur. Si vous omettez cette option, la
commande se connecte au premier conteneur du pod.
Vous pouvez également vous connecter à des conteneurs en cours d’exécution de la console Web
en cliquant sur l’onglet Terminal dans le menu principal du pod.
Si vous disposez de plusieurs conteneurs, vous pouvez passer de l’un à l’autre pour vous connecter
au CLI.
DO180-OCP4.14-fr-2-20240530 199
Exécuter des commandes dans un conteneur

La transmission de commandes à exécuter dans un conteneur à partir de l’interface de ligne de
commande est une autre méthode de résolution des problèmes liés à un conteneur en cours
d’exécution. Utilisez cette méthode pour envoyer une commande à exécuter dans le conteneur ou
pour vous connecter au conteneur, lorsqu’une enquête plus approfondie est nécessaire.
Utilisez la commande suivante pour transmettre et exécuter des commandes dans un conteneur :
oc exec POD | TYPE/NAME [-c container_name] -- COMMAND [arg1 ... argN]
Si vous omettez l’option -c container_name, la commande cible le premier conteneur du pod.
Les exemples suivants illustrent l’utilisation de la commande oc exec pour exécuter la

commande ls dans un conteneur afin de lister le contenu du répertoire root du conteneur :
[user@host ~]$ oc exec -it mariadb-lc78h -- ls /

bin boot dev etc help.1 home lib lib64 ...
[user@host ~]$ oc exec mariadb-lc78h -- ls /

bin
boot
dev
etc
Note
Il est courant d’ajouter les indicateurs -it aux commandes kubectl exec ou oc
exec. Ces indicateurs indiquent à la commande d’envoyer STDIN au conteneur
et STDOUT/STDERR au terminal. L’inclusion des indicateurs -it a un impact sur le
format de la sortie de la commande.
200 DO180-OCP4.14-fr-2-20240530
Événements et journaux de conteneur

L’examen des actions historiques d’un conteneur peut fournir des informations sur le cycle de
vie et l’intégrité du déploiement. La récupération des journaux de cluster fournit les détails
chronologiques des actions du conteneur. Les administrateurs examinent cette sortie de journal
à la recherche d’informations et de problèmes qui se produisent dans le conteneur en cours
d’exécution.
Pour les commandes suivantes, utilisez -c container_name pour spécifier un conteneur dans le
pod. Si vous omettez cette option, la commande cible le premier conteneur du pod.
L’exemple suivant illustre l’utilisation de la commande oc logs POD_NAME pour récupérer des
informations pour un pod :
[user@host ~]$ oc logs BIND9-app-rw43j

Defaulted container "dns" out of: dns
.:5353
[INFO] plugin/reload: Running configuration SHA512 = 7c3d...3587
CoreDNS-1.9.2
Dans Kubernetes, une ressource event est un rapport d’un événement situé quelque part dans
le cluster. Vous pouvez utiliser les commandes kubectl get events et oc get events pour
afficher les événements de pod dans un espace de noms :
[user@host ~]$ oc get events

LAST SEEN TYPE REASON OBJECT MESSAGE
21m Normal AddedInterface pod/php-app-5d9b84b588-kzfxd Add eth0
[10.8.0.93/23] from ovn-kubernetes
21m Normal Pulled pod/php-app-5d9b84b588-kzfxd Container
image "registry.ocp4.example.com:8443/redhattraining/php-webapp:v4" already
present on machine
21m Normal Created pod/php-app-5d9b84b588-kzfxd Created
container php-webapp
21m Normal Started pod/php-app-5d9b84b588-kzfxd Started
container php-webapp
Commandes Linux disponibles dans les conteneurs

L’utilisation de commandes Linux pour la résolution des problèmes liés aux applications
peut également faciliter la résolution des problèmes liés aux conteneurs. Cependant, lors de
la connexion à un conteneur, seuls les outils et applications définis dans le conteneur sont
disponibles. Vous pouvez étendre l’environnement à l’intérieur du conteneur en ajoutant les outils
de cette section ou tout autre outil de correction à l’image de conteneur.
Avant d’ajouter des outils à une image de conteneur, examinez la manière dont les outils ont un
impact sur votre image de conteneur.
• Des outils supplémentaires augmentent la taille de l’image, ce qui peut avoir des répercussions
sur les performances du conteneur.
• Les outils peuvent nécessiter des paquetages de mise à jour et des conditions d’utilisation de
la licence supplémentaires, ce qui peut avoir une incidence sur la facilité de mise à jour et de
distribution de l’image de conteneur.
DO180-OCP4.14-fr-2-20240530 201
• Les pirates informatiques peuvent exploiter des outils dans l’image.
Résolution de problèmes depuis l’intérieur du cluster

Il est courant de résoudre les problèmes liés à un cluster, à ses composants ou aux applications
en cours d’exécution en se connectant à distance. Cette approche suppose que l’ordinateur
de l’administrateur contient les outils nécessaires pour cette tâche. Lorsque des problèmes
imprévus surviennent, les outils nécessaires peuvent ne pas être disponibles sur l’ordinateur d’un
administrateur ou une autre machine.
Les administrateurs peuvent également créer et déployer un conteneur dans le cluster à des
fins d’investigation et de correction. En créant une image de conteneur qui inclut les outils de
résolution des problèmes liés au cluster, vous disposez d’un environnement fiable pour effectuer
ces tâches à partir de n’importe quel ordinateur ayant accès au cluster. Cette approche garantit
qu’un administrateur a toujours accès aux outils pour résoudre et corriger les problèmes de façon
fiable.
En outre, les administrateurs doivent prévoir de créer une image de conteneur qui fournit les
outils de résolution de problèmes les plus utiles pour les applications en conteneur. De cette
façon, vous déployez ce conteneur « toolbox » pour compléter le processus d’analyse et fournir
un environnement avec les commandes et les outils requis pour résoudre les problèmes liés aux
conteneurs. Par exemple, le conteneur « toolbox » peut tester le fonctionnement des ressources
à l’intérieur d’un cluster, par exemple pour confirmer si un pod peut se connecter à des ressources
en dehors du cluster. Les utilisateurs de cluster standard peuvent également créer un conteneur
« toolbox » pour faciliter la résolution des problèmes liés aux applications. Par exemple, un
utilisateur standard peut exécuter un pod avec un client MySQL pour se connecter à un autre pod
qui exécute un serveur MySQL.
Bien que cette approche n’entre pas dans le cadre de ce cours, car il s’agit davantage d’une
correction au niveau de l’application que d’une résolution de problèmes au niveau du conteneur, il
est important de comprendre que les conteneurs présentent cette capacité.
202 DO180-OCP4.14-fr-2-20240530
Références
Documentation de Kubernetes – kubectl edit
https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/
#kubectl-edit
Update API Objects in Place Using kubectl patch

https://kubernetes.io/docs/tasks/manage-kubernetes-objects/update-api-object-
kubectl-patch/
Pour plus d’informations sur la résolution des problèmes liés aux pods, reportez-
vous à la section Investigating Pod Issues du chapitre Troubleshooting de la
documentation Support de Red Hat OpenShift Container Platform 4.14, disponible à
l’adresse
openshift_container_platform/4.14/html-single/support/index#investigating-pod-
issues
Pour plus d’informations sur la manière de copier des fichiers vers des pods et
à partir de ces derniers, reportez-vous à la section Copying Files to or from an
OpenShift Container Platform Container du chapitre Working with Containers de la
documentation Nodes de Red Hat OpenShift Container Platform 4.14, disponible à
l’adresse
openshift_container_platform/4.14/html-single/nodes/index#nodes-containers-
copying-files
Pour plus d’informations sur la redirection de ports, reportez-vous à la section

Using Port Forwarding to Access Applications in a Container du chapitre Working
with Containers de la documentation Nodes de Red Hat OpenShift Container
port-forwarding
Documentation Kubernetes – Use Port Forwarding to Access Applications in a

Cluster
https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-
application-cluster/
Pour plus d’informations sur l’exécution de commandes distantes dans des

conteneurs, reportez-vous à la section Executing Remote Commands in an
OpenShift Container Platform Container du chapitre Working with Containers de la
documentation Nodes de Red Hat OpenShift Container Platform 4.14, disponible à
l’adresse
remote-commands
DO180-OCP4.14-fr-2-20240530 203
Exercice guidé
Résoudre les problèmes liés aux

conteneurs et aux pods
Résoudre les problèmes et corriger un pod MySQL défaillant et initialiser manuellement une
base de données avec des données de test.
Résultats
• Examiner les erreurs lors de la création d’un pod.
• Afficher l’état, les journaux et les événements d’un pod.
• Copier des fichiers dans un pod en cours d’exécution.
• Se connecter à un pod en cours d’exécution à l’aide de la redirection de port.
Avant De Commencer
Cette commande permet de s’assurer que le cluster et toutes les ressources de l’exercice
sont disponibles.
[student@workstation ~]$ lab start pods-troubleshooting
Instructions
1. Connectez-vous au cluster OpenShift et créez le projet pods-troubleshooting.

commande oc.

1.2. Créez le projet pods-troubleshooting.
[student@workstation ~]$ oc new-project pods-troubleshooting

2. Créez un pod MySQL appelé mysql-server avec la commande oc run. Utilisez l’image
de conteneur registry.ocp4.example.com:8443/rhel9/mysql-80:1228 pour le
pod. Spécifiez les variables d’environnement avec les valeurs suivantes :
204 DO180-OCP4.14-fr-2-20240530
Variable Valeur
MYSQL_USER redhat
MYSQL_DATABASE world
Affichez ensuite l’état du pod à l’aide de la commande oc get.
2.1. Créez le pod mysql-server avec la commande oc run. Spécifiez les variables
d’environnement avec l’option --env.
[student@workstation ~]$ oc run mysql-server \

--image registry.ocp4.example.com:8443/rhel9/mysql-80:1228 \
--env MYSQL_USER=redhat \
--env MYSQL_PASSWORD=redhat123 \
--env MYSQL_DATABASE=world
pod/mysql created
2.2. Après quelques instants, récupérez l’état du pod. Exécutez la commande oc get
pods plusieurs fois pour afficher les mises à jour de l’état du pod.

mysql-server 0/1 ErrImagePull 0 30s
[studet@workstation ~]$ oc get pods

mysql-server 0/1 ImagePullBackoff 0 45s
3. Identifiez la cause principale de l’échec du pod.
3.1. Récupérez les journaux du pod avec la commande oc logs.
[student@workstation ~]$ oc logs mysql-server

Error from server (BadRequest): container "mysql-server" in pod "mysql-server" is
waiting to start: trying and failing to pull image
Les journaux indiquent que le pod ne peut pas extraire l’image de conteneur.
3.2. Récupérez le journal des événements avec la commande oc get events.
student@workstation ~]$ oc get events

33s Normal Scheduled pod/mysql-server Successfully assigned
pods-troubleshooting/mysql-server to master01 by master01
31s Normal AddedInterface pod/mysql-server Add eth0 [10.8.0.68/23]
from ovn-kubernetes
DO180-OCP4.14-fr-2-20240530 205
16s Normal Pulling pod/mysql-server Pulling image

"registry.ocp4.example.com:8443/rhel9/mysql-80:1228"
16s Warning Failed pod/mysql-server Failed to pull image
"registry.ocp4.example.com:8443/rhel9/mysql-80:1228": rpc error: code = Unknown
desc = reading manifest 1228 in registry.ocp4.example.com:8443/rhel9/mysql-80:
manifest unknown: manifest unknown
16s Warning Failed pod/mysql-server Error: ErrImagePull
4s Normal BackOff pod/mysql-server Back-off pulling image
"registry.ocp4.example.com:8443/rhel9/mysql-80:1228"
4s Warning Failed pod/mysql-server Error: ImagePullBackOff
La sortie indique que l’extraction de l’image a échoué, car le manifeste 1228 est
inconnu. Cet échec peut signifier que le manifeste, ou la balise d’image, n’existe pas
dans le référentiel.
3.3. Examinez le manifeste disponible dans le référentiel de conteneurs

registry.ocp4.example.com:8443/rhel9/mysql-80. Authentifiez-vous
auprès du référentiel de conteneurs à l’aide de la commande skopeo login en
tant qu’utilisateur developer avec le mot de passe developer. Utilisez ensuite
la commande skopeo inspect pour récupérer les manifestes disponibles dans le
référentiel registry.ocp4.example.com:8443/rhel9/mysql-80.
[student@workstation ~]$ skopeo login registry.ocp4.example.com:8443

Username: developer
Password: developer
Login Succeeded!

docker://registry.ocp4.example.com:8443/rhel9/mysql-80
"Name": "registry.ocp4.example.com:8443/rhel9/mysql-80",
"Digest": "sha256:d282...f38f",
"RepoTags": [
"1-237",
"1-228",
"1-228-source",
"1-224",
"1-224-source",
"latest",
"1"
],
Le manifeste 1228, ou la balise, n’est pas disponible dans le référentiel, ce qui signifie
que l’image registry.ocp4.example.com:8443/rhel9/mysql-80:1228
n’existe pas. Cependant, la balise 1-228 existe.
4. Le pod n’a pas pu démarrer en raison d’une erreur de frappe dans la balise
d’image. Mettez à jour la configuration du pod pour utiliser l’image de conteneur
registry.ocp4.example.com:8443/rhel9/mysql-80:1-228. Vérifiez que le pod
est recréé après avoir modifié la ressource.
4.1. Modifiez la configuration du pod avec la commande oc edit. Localisez l’objet

.spec.containers.image. Mettez à jour la valeur dans l’image de conteneur
206 DO180-OCP4.14-fr-2-20240530
registry.ocp4.example.com:8443/rhel9/mysql-80:1-228 et enregistrez la
modification.
[student@workstation ~]$ oc edit pod/mysql-server
apiVersion: v1
kind: Pod
metadata:
spec:
containers:
- image: registry.ocp4.example.com:8443/rhel9/mysql-80:1-228
4.2. Vérifiez l’état du pod mysql-server à l’aide de la commande oc get. La mise à jour
de l’état du pod peut prendre quelques instants après la modification de la ressource.
Répétez la commande oc get jusqu’à ce que l’état du pod change.

mysql-server 1/1 Running 0 10m
Le pod mysql-server a réussi à extraire l’image et à créer le conteneur. Le pod

affiche maintenant un état Running.
5. Préparez la base de données sur le pod mysql-server. Copiez le fichier ~/DO180/

labs/pods-troubleshooting/world_x.sql vers le pod mysql-server. Ensuite,
connectez-vous au pod et exécutez le fichier world_x.sql pour remplir la base de
données world.
5.1. Utilisez la commande oc cp pour copier le fichier world_x.sql dans le répertoire

~/DO180/labs/pods-troubleshooting vers le répertoire /tmp/ sur le pod
mysql-server.
[student@workstation ~]$ oc cp ~/DO180/labs/pods-troubleshooting/world_x.sql \

mysql-server:/tmp/
5.2. Vérifiez que le fichier world_x.sql est accessible dans le pod mysql-server à
l’aide de la commande oc exec.
[student@workstation ~]$ oc exec -it pod/mysql-server -- ls -la /tmp/

total 0
drwxrwxrwx. 1 root root 22 Nov 4 14:45 .
dr-xr-xr-x. 1 root root 50 Nov 4 14:34 ..
-rw-rw-r--. 1 1000680000 root 558791 Nov 4 14:45 world_x.sql
5.3. Connectez-vous au pod mysql-server à l’aide de la commande oc rsh. Ensuite,

connectez-vous à MySQL en tant qu’utilisateur redhat avec le mot de passe
redhat123.
[student@workstation ~]$ oc rsh mysql-server
DO180-OCP4.14-fr-2-20240530 207
sh-5.1$ mysql -u redhat -p

Welcome to the MySQL monitor. Commands end with ; or \g.
mysql>
5.4. À l’invite MySQL, sélectionnez la base de données world. Sourcez le script

world_x.sql dans le pod pour initialiser et remplir la base de données world.
mysql> USE world;

Database changed
mysql> SOURCE /tmp/world_x.sql;

5.5. Exécutez la commande SHOW TABLES; pour vérifier que la base de données
contient désormais des tables. Ensuite, quittez la base de données et le pod.
mysql> SHOW TABLES;

-----------------
| Tables_in_test |
-----------------
| city |
| country |
| countryinfo |
| countrylanguage |
-----------------
4 rows in set (0.00 sec)
mysql> exit;
Bye
sh-5.1$ exit
exit
[student@workstation ~]$
6. Configurez la redirection de port, puis utilisez le client MySQL sur la machine

workstation pour vous connecter à la base de données world sur le pod mysql-
server. Vérifiez que vous pouvez accéder aux données de la base de données world à
partir de la machine workstation.
6.1. À partir de la machine workstation, utilisez la commande oc port-forward pour

rediriger le port local 3306 vers le port 3306 sur le pod mysql-server.
[student@workstation ~]$ oc port-forward mysql-server 3306:3306

Forwarding from 127.0.0.1:3306 -> 3306
6.2. Ouvrez une autre fenêtre de terminal sur la machine workstation. Connectez-
vous à la base de données world avec le client MySQL local sur la machine
workstation. Connectez-vous en tant qu’utilisateur redhat avec le mot de passe
208 DO180-OCP4.14-fr-2-20240530
redhat123. Spécifiez l’hôte comme adresse IP 127.0.0.1 localhost et utilisez

3306 comme port.
[student@workstation ~]$ mysql -u redhat -p -h 127.0.0.1 -P 3306

Welcome to the MySQL monitor. Commands end with ; or \g.
mysql>
6.3. Sélectionnez la base de données world et exécutez la commande SHOW TABLES;.
mysql> USE world;

Database changed
mysql> SHOW TABLES;

-----------------
| Tables_in_test |
-----------------
| city |
| country |
| countryinfo |
| countrylanguage |
-----------------
4 rows in set (0.01 sec)
6.4. Vérifiez que vous pouvez récupérer les données de la table country. Exécutez la
commande SELECT COUNT(*) FROM country pour récupérer le nombre de pays
dans la table country.
mysql> SELECT COUNT(*) FROM country;

----------
| COUNT(*) |
----------
| 239 |
----------
1 row in set (0.01 sec)
6.5. Quittez la base de données.
mysql> exit;
Bye
6.6. Revenez au terminal qui exécute la commande oc port-forward. Appuyez sur

Ctrl+C pour mettre fin à la connexion.
DO180-OCP4.14-fr-2-20240530 209
[student@workstation ~]$ oc port-forward mysql-server 3306:3306

Forwarding from 127.0.0.1:3306 -> 3306
Handling connection for 3306
^C[student@workstation ~]$
Fin
[student@workstation ~]$ lab finish pods-troubleshooting
210 DO180-OCP4.14-fr-2-20240530
Open Lab
Exécuter des applications en tant que

conteneurs et pods
Exécutez un serveur Web en tant que pod et insérez une page de débogage qui affiche des
informations de diagnostic.
Résultats
• Déployer un pod à partir d’une image de conteneur.
• Récupérer l’état et les événements d’un pod.
• Résoudre les problèmes liés à l’échec d’un pod.
• Modifier les ressources du pod.
• Copier les fichiers dans un pod en cours d’exécution à des fins de diagnostic.
• Utiliser la redirection de port pour se connecter à un pod en cours d’exécution.
Avant De Commencer
Cette commande permet de s’assurer que les ressources de l’exercice sont disponibles.
[student@workstation ~]$ lab start pods-review
Instructions

developer.
Utilisez le projet pods-review pour votre travail.

1. Connectez-vous au cluster OpenShift et accédez au projet pods-review.
2. Déployez un pod nommé webphp qui utilise l’image de conteneur
registry.ocp4.example.com:8443/redhattraining/webphp:v1. Déterminez les
raisons de l’échec du pod.
3. Résolvez le problème du pod webphp en échec en créant un pod de débogage.
4. Le développeur de l’application a résolu le problème identifié dans l’image de conteneur
registry.ocp4.example.com:8443/redhattraining/webphp:v2. Dans une fenêtre
de terminal, modifiez la ressource de pod webphp pour qu’elle utilise la balise d’image v2.
Récupérez l’état du pod webphp. Vérifiez ensuite que l’utilisateur dans le conteneur est un
DO180-OCP4.14-fr-2-20240530 211
utilisateur sans privilèges et qu’il appartient au groupe root. Vérifiez que les autorisations du
groupe root sont correctes pour le répertoire /run/httpd.
5. Connectez le port 8080 sur la machine Workstation au port 8080 sur le pod webphp. Dans
une nouvelle fenêtre de terminal, récupérez le contenu de la page Web 127.0.0.1:8080/
index.php du pod pour vérifier que le pod est opérationnel.
Note
La fenêtre de terminal que vous connectez au pod webphp doit rester ouverte
pour le reste de l’atelier. Cette connexion est nécessaire pour la dernière étape de
l’atelier et pour la commande lab grade.
6. Un problème se produit avec l’application PHP qui s’exécute sur le pod webphp. Pour
déboguer le problème, le développeur de l’application a besoin d’informations de diagnostic
et de configuration pour l’instance PHP qui s’exécute sur le pod webphp.
Le répertoire ~/DO180/labs/pods-review contient un fichier phpinfo.php
pour générer des informations de débogage pour une instance PHP. Copiez le fichier
phpinfo.php vers le répertoire /var/www/html/ sur le pod webphp.
Vérifiez ensuite que les informations de débogage PHP s’affichent lorsque vous accédez à
127.0.0.1:8080/phpinfo.php à partir d’un navigateur Web.
Après avoir exécuté la commande lab grade, revenez au terminal qui exécute la
commande oc port-forward et appuyez sur Ctrl+C pour mettre fin à la connexion.
[student@workstation ~]$ oc port-forward pod/webphp 8080:8080

Forwarding from 127.0.0.1:8080 -> 8080
Évaluation
persistent.
[student@workstation ~]$ lab grade pods-review
Fin
[student@workstation ~]$ lab finish pods-review
212 DO180-OCP4.14-fr-2-20240530
Solution

conteneurs et pods
Exécutez un serveur Web en tant que pod et insérez une page de débogage qui affiche des
informations de diagnostic.
Résultats
• Déployer un pod à partir d’une image de conteneur.
• Récupérer l’état et les événements d’un pod.
• Résoudre les problèmes liés à l’échec d’un pod.
• Modifier les ressources du pod.
• Copier les fichiers dans un pod en cours d’exécution à des fins de diagnostic.
• Utiliser la redirection de port pour se connecter à un pod en cours d’exécution.
Avant De Commencer
Cette commande permet de s’assurer que les ressources de l’exercice sont disponibles.
[student@workstation ~]$ lab start pods-review
Instructions

developer.
Utilisez le projet pods-review pour votre travail.

1. Connectez-vous au cluster OpenShift et accédez au projet pods-review.

1.2. Sélectionnez le projet pods-review.
DO180-OCP4.14-fr-2-20240530 213
[student@workstation ~]$ oc project pods-review

Now using project "pods-review" on server "https://api.ocp4.example.com:6443".
2. Déployez un pod nommé webphp qui utilise l’image de conteneur

registry.ocp4.example.com:8443/redhattraining/webphp:v1. Déterminez les
raisons de l’échec du pod.
2.1. Déployez un pod nommé webphp qui utilise l’image de conteneur

registry.ocp4.example.com:8443/redhattraining/webphp:v1.
[student@workstation ~]$ oc run webphp \

--image=registry.ocp4.example.com:8443/redhattraining/webphp:v1
pod/webphp created
2.2. Après quelques instants, observez l’état du pod webphp.

webphp 0/1 CrashLoopBackOff 1 (4s ago) 7s
webphp 0/1 Error 2 (24s ago) 7s
2.3. Récupérez les événements du cluster.
[student@workstation ~]$ oc get events

3m25s Normal Scheduled pod/webphp Successfully assigned pods-
review/webphp to master01 by master01
3m23s Normal AddedInterface pod/webphp Add eth0 [10.8.0.73/23] from
ovn-kubernetes
3m23s Normal Pulling pod/webphp Pulling image
"registry.ocp4.example.com:8443/redhattraining/webphp:v1"
3m15s Normal Pulled pod/webphp Successfully pulled image
"registry.ocp4.example.com:8443/redhattraining/webphp:v1" in 7.894992669s
104s Normal Created pod/webphp Created container webphp
104s Normal Started pod/webphp Started container webphp
104s Normal Pulled pod/webphp Container image
"registry.ocp4.example.com:8443/redhattraining/webphp:v1" already present on
machine
103s Warning BackOff pod/webphp Back-off restarting failed
container
2.4. Récupérez les journaux du pod webphp.
214 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ oc logs webphp

[20-Dec-2022 18:46:56] NOTICE: [pool www] 'user' directive is ignored when FPM is
not running as root
[20-Dec-2022 18:46:56] NOTICE: [pool www] 'group' directive is ignored when FPM is
not running as root
[20-Dec-2022 18:46:56] ERROR: unable to bind listening socket for address '/run/
php-fpm/www.sock': Permission denied (13)
[20-Dec-2022 18:46:56] ERROR: FPM initialization failed
AH00558: httpd: Could not reliably determine the server's fully qualified domain
name, using 10.8.0.62. Set the 'ServerName' directive globally to suppress this
message
(13)Permission denied: AH00058: Error retrieving pid file run/httpd.pid
AH00059: Remove it before continuing if it is corrupted.
Les journaux indiquent des problèmes d’autorisation avec le répertoire /run dans le
pod.
3. Résolvez le problème du pod webphp en échec en créant un pod de débogage.
3.1. Créez un pod de débogage pour dépanner le pod webphp en échec.
[student@workstation ~]$ oc debug pod/webphp

Starting pod/webphp-debug ...
Pod IP: 10.8.0.63
sh-4.4$
3.2. Listez le contenu du répertoire /run pour récupérer les autorisations, les propriétaires
et les groupes.
sh-4.4$ ls -la /run

total 0
drwxr-xr-x. 1 root root 42 Dec 20 18:47 .
dr-xr-xr-x. 1 root root 17 Dec 20 18:47 ..
-rw-r--r--. 1 root root 0 Dec 20 18:47 .containerenv
drwx--x---. 3 root apache 26 Dec 20 18:42 httpd
drwxr-xr-x. 2 root root 6 Oct 26 11:10 lock
drwxr-xr-x. 2 root root 6 Dec 20 18:42 php-fpm
drwxr-xr-x. 4 root root 80 Dec 20 18:47 secrets
Le répertoire /run/httpd accorde des autorisations de lecture, d’écriture et

d’exécution à l’utilisateur root, mais ne fournit pas d’autorisations pour le groupe
root.
3.3. Récupérez l’UID et le GID de l’utilisateur dans le conteneur. Déterminez si l’utilisateur

est un utilisateur avec privilèges et s’il appartient au groupe root.
sh-4.4$ id
Vos valeurs UID et GID peuvent différer de la sortie précédente.

L’utilisateur est un utilisateur non-root sans privilèges et appartient au groupe root,
qui n’a pas accès au répertoire /run. Par conséquent, l’utilisateur dans le conteneur ne
DO180-OCP4.14-fr-2-20240530 215
peut pas accéder aux fichiers et aux répertoires utilisés par les processus du conteneur,
ce qui est requis pour les UID attribués de manière arbitraire.
3.4. Quittez le pod de débogage.
sh-4.4$ exit
exit
4. Le développeur de l’application a résolu le problème identifié dans l’image de conteneur

registry.ocp4.example.com:8443/redhattraining/webphp:v2. Dans une fenêtre
de terminal, modifiez la ressource de pod webphp pour qu’elle utilise la balise d’image v2.
Récupérez l’état du pod webphp. Vérifiez ensuite que l’utilisateur dans le conteneur est un
utilisateur sans privilèges et qu’il appartient au groupe root. Vérifiez que les autorisations du
groupe root sont correctes pour le répertoire /run/httpd.
4.1. Utilisez le terminal pour modifier la ressource de pod webphp.
[student@workstation ~]$ oc edit pod/webphp
4.2. Mettez à jour la valeur de l’objet .spec.containers.image de manière à utiliser la

balise d’image :v2.
spec:
containers:
- image: registry.ocp4.example.com:8443/redhattraining/webphp:v2
imagePullPolicy: IfNotPresent
4.3. Vérifiez l’état du pod webphp.

webphp 1/1 Running 9 (2m9s ago) 18m
4.4. Récupérez l’UID et le GID de l’utilisateur dans le conteneur pour vérifier que l’utilisateur
est un utilisateur sans privilèges.
[student@workstation ~]$ oc exec -it webphp -- id

Vos valeurs UID et GID peuvent différer de la sortie précédente.
4.5. Vérifiez que les autorisations du répertoire /run/httpd sont correctes.
[student@workstation ~]$ oc exec -it webphp -- ls -la /run/

total 0
drwxr-xr-x. 1 root root 70 Dec 20 19:01 .
dr-xr-xr-x. 1 root root 39 Dec 20 19:01 ..
-rw-r--r--. 1 root root 0 Dec 20 18:45 .containerenv
216 DO180-OCP4.14-fr-2-20240530
drwxrwx---. 1 root root 41 Dec 20 19:01 httpd

drwxr-xr-x. 2 root root 6 Oct 26 11:10 lock
drwxrwxr-x. 1 root root 41 Dec 20 19:01 php-fpm
drwxr-xr-x. 4 root root 80 Dec 20 19:01 secrets
5. Connectez le port 8080 sur la machine Workstation au port 8080 sur le pod webphp. Dans
une nouvelle fenêtre de terminal, récupérez le contenu de la page Web 127.0.0.1:8080/
index.php du pod pour vérifier que le pod est opérationnel.
Note
La fenêtre de terminal que vous connectez au pod webphp doit rester ouverte
pour le reste de l’atelier. Cette connexion est nécessaire pour la dernière étape de
l’atelier et pour la commande lab grade.
5.1. Connectez-vous au port 8080 sur le pod webphp.

Forwarding from 127.0.0.1:8080 -> 8080
5.2. Ouvrez une deuxième fenêtre de terminal, puis récupérez la page Web
127.0.0.1:8080/index.php sur le pod webphp.
[student@workstation ~]$ curl 127.0.0.1:8080/index.php

<html>
<body>
Hello, World!
</body>
</html>
6. Un problème se produit avec l’application PHP qui s’exécute sur le pod webphp. Pour
déboguer le problème, le développeur de l’application a besoin d’informations de diagnostic
et de configuration pour l’instance PHP qui s’exécute sur le pod webphp.
Le répertoire ~/DO180/labs/pods-review contient un fichier phpinfo.php
pour générer des informations de débogage pour une instance PHP. Copiez le fichier
phpinfo.php vers le répertoire /var/www/html/ sur le pod webphp.
Vérifiez ensuite que les informations de débogage PHP s’affichent lorsque vous accédez à
127.0.0.1:8080/phpinfo.php à partir d’un navigateur Web.
6.1. Dans le deuxième terminal, copiez le fichier ~/DO180/labs/pods-review/

phpinfo.php vers le pod webphp en tant que fichier /var/www/html/
phpinfo.php.
[student@workstation ~]$ oc cp ~/DO180/labs/pods-review/phpinfo.php \

webphp:/var/www/html/phpinfo.php
6.2. Ouvrez un navigateur Web et accédez à la page Web 127.0.0.1:8080/

phpinfo.php. Vérifiez que les informations de débogage PHP sont affichées.
DO180-OCP4.14-fr-2-20240530 217
Figure 3.9: Informations de débogage PHP
Après avoir exécuté la commande lab grade, revenez au terminal qui exécute la
commande oc port-forward et appuyez sur Ctrl+C pour mettre fin à la connexion.

Forwarding from 127.0.0.1:8080 -> 8080
Évaluation
persistent.
[student@workstation ~]$ lab grade pods-review
Fin
[student@workstation ~]$ lab finish pods-review
218 DO180-OCP4.14-fr-2-20240530
Quiz

conteneurs et pods
En tant qu’utilisateur student sur la machine workstation, utilisez

Skopeo pour vous connecter au registre de conteneurs de la salle de classe
registry.ocp4.example.com:8443 en tant qu’utilisateur developer avec le mot de
passe developer. Utilisez ensuite les commandes skopeo et oc image pour répondre aux
questions ci-dessous.
1. Quelle commande est exécutée dans l’image de conteneur

registry.ocp4.example.com:8443/ubi8/php-74:latest ?
a. httpd -D FOREGROUND
b. run-mysqld
c. php-fpm -D, httpd -D FOREGROUND
d. /bin/sh -c $STI_SCRIPTS_PATH/usage
e. /bin/sh -c php-fpm -D
2. À l’aide de la valeur UID de l’image de conteneur

registry.ocp4.example.com:8443/ubi8/php-74:latest, identifiez les deux
scénarios de déploiement corrects. (Choisissez-en deux.)
a. Le conteneur s’exécute en tant qu’utilisateur avec privilèges root lorsqu’un compte
d’utilisateur OpenShift standard le déploie dans un pod.
b. La valeur UID de l’utilisateur du conteneur est 1001 lorsqu’un compte d’utilisateur
OpenShift standard la déploie dans un pod.
c. Le conteneur s’exécute en tant qu’utilisateur sans privilèges lorsqu’il est déployé dans un
pod.
d. Le conteneur s’exécute en tant qu’utilisateur avec privilèges root lorsqu’un
administrateur de cluster OpenShift standard le déploie dans un pod.
e. La valeur UID de l’utilisateur du conteneur est 1001 lorsqu’un administrateur de cluster
OpenShift la déploie dans un pod.
3. Quel est le code ID/hash de l’image de conteneur

registry.ocp4.example.com:8443/rhel9/mysql-80:1-237 ?
a. sha256:90b4…a3a4
b. sha256:4243…71a6
c. sha256:3843…7caf
d. sha256:d282…f38f
e. sha256:0027…8c72
DO180-OCP4.14-fr-2-20240530 219
4. Quelles sont les deux variables d’environnement et leurs valeurs spécifiées

dans l’image de conteneur registry.ocp4.example.com:8443/rhel8/
postgresql-13:latest ? (Choisissez-en deux.)
a. NAME=PHP 7.4
b. APP_DATA=/opt/app-root/src/bin
c. HOME=/var/lib/pgsql
d. PHP_SYSCONF_FILE=/etc/
e. PGUSER=postgres
5. Quelles sont les trois balises disponibles pour l’image de conteneur

registry.ocp4.example.com:8443/ubi8/ubi ? (Choisissez-en trois.)
a. v1
b. 1
c. latest
d. 8.1
e. 8.4
f. 1.8
g. 8.0
6. Quelles sont les deux images de conteneur qui sont exécutées en tant qu’utilisateur
avec privilèges lorsqu’un administrateur de cluster OpenShift déploie un pod à partir
d’une image ? (Choisissez-en deux.)
a. registry.ocp4.example.com:8443/rhel8/postgresql-13:latest
b. registry.ocp4.example.com:8443/ubi8/php-74:latest
c. registry.ocp4.example.com:8443/ubi8/nodejs-16:latest
d. registry.ocp4.example.com:8443/rhel8/mysql-80:latest
e. registry.ocp4.example.com:8443/ubi8/python-39
7. Quels ports sont exposés dans l’image de conteneur

registry.ocp4.example.com:8443/rhel8/mysql-80 ?
a. 8080/tcp
b. 3363/tcp
c. 8443/tcp
d. 3306/tcp
e. 3360/tcp
220 DO180-OCP4.14-fr-2-20240530
Solution

conteneurs et pods
En tant qu’utilisateur student sur la machine workstation, utilisez

Skopeo pour vous connecter au registre de conteneurs de la salle de classe
registry.ocp4.example.com:8443 en tant qu’utilisateur developer avec le mot de
passe developer. Utilisez ensuite les commandes skopeo et oc image pour répondre aux
questions ci-dessous.
1. Quelle commande est exécutée dans l’image de conteneur

registry.ocp4.example.com:8443/ubi8/php-74:latest ?
a. httpd -D FOREGROUND
b. run-mysqld
c. php-fpm -D, httpd -D FOREGROUND
d. /bin/sh -c $STI_SCRIPTS_PATH/usage
e. /bin/sh -c php-fpm -D
2. À l’aide de la valeur UID de l’image de conteneur

registry.ocp4.example.com:8443/ubi8/php-74:latest, identifiez les deux
scénarios de déploiement corrects. (Choisissez-en deux.)
a. Le conteneur s’exécute en tant qu’utilisateur avec privilèges root lorsqu’un compte
d’utilisateur OpenShift standard le déploie dans un pod.
b. La valeur UID de l’utilisateur du conteneur est 1001 lorsqu’un compte d’utilisateur
OpenShift standard la déploie dans un pod.
c. Le conteneur s’exécute en tant qu’utilisateur sans privilèges lorsqu’il est déployé dans un
pod.
d. Le conteneur s’exécute en tant qu’utilisateur avec privilèges root lorsqu’un
administrateur de cluster OpenShift standard le déploie dans un pod.
e. La valeur UID de l’utilisateur du conteneur est 1001 lorsqu’un administrateur de cluster
OpenShift la déploie dans un pod.
3. Quel est le code ID/hash de l’image de conteneur

registry.ocp4.example.com:8443/rhel9/mysql-80:1-237 ?
a. sha256:90b4…a3a4
b. sha256:4243…71a6
c. sha256:3843…7caf
d. sha256:d282…f38f
e. sha256:0027…8c72
DO180-OCP4.14-fr-2-20240530 221
4. Quelles sont les deux variables d’environnement et leurs valeurs spécifiées

dans l’image de conteneur registry.ocp4.example.com:8443/rhel8/
postgresql-13:latest ? (Choisissez-en deux.)
a. NAME=PHP 7.4
b. APP_DATA=/opt/app-root/src/bin
c. HOME=/var/lib/pgsql
d. PHP_SYSCONF_FILE=/etc/
e. PGUSER=postgres
5. Quelles sont les trois balises disponibles pour l’image de conteneur

registry.ocp4.example.com:8443/ubi8/ubi ? (Choisissez-en trois.)
a. v1
b. 1
c. latest
d. 8.1
e. 8.4
f. 1.8
g. 8.0
6. Quelles sont les deux images de conteneur qui sont exécutées en tant qu’utilisateur
avec privilèges lorsqu’un administrateur de cluster OpenShift déploie un pod à partir
d’une image ? (Choisissez-en deux.)
a. registry.ocp4.example.com:8443/rhel8/postgresql-13:latest
b. registry.ocp4.example.com:8443/ubi8/php-74:latest
c. registry.ocp4.example.com:8443/ubi8/nodejs-16:latest
d. registry.ocp4.example.com:8443/rhel8/mysql-80:latest
e. registry.ocp4.example.com:8443/ubi8/python-39
7. Quels ports sont exposés dans l’image de conteneur

registry.ocp4.example.com:8443/rhel8/mysql-80 ?
a. 8080/tcp
b. 3363/tcp
c. 8443/tcp
d. 3306/tcp
e. 3360/tcp
222 DO180-OCP4.14-fr-2-20240530
Résumé
• Un conteneur est un processus encapsulé qui inclut les dépendances d’exécution requises pour
l’exécution d’une application.
• OpenShift utilise Kubernetes pour gérer les pods. Les pods sont constitués d’un ou de plusieurs
conteneurs qui partagent des ressources, telles que des espaces de noms sélectionnés et la
mise en réseau, et représentent une seule application.
• Les images de conteneur peuvent créer des instances de conteneur, qui sont des versions
exécutables de l’image, et contiennent des références à la mise en réseau, aux disques, ainsi
qu’à d’autres éléments nécessaires à l’exécution.
• Les registres d’images de conteneur, tels que Quay.io et Red Hat Container Catalog, constituent
la méthode privilégiée pour distribuer des images de conteneur à de nombreux utilisateurs et
hôtes.
• La commande oc image et Skopeo, parmi d’autres outils, peuvent examiner et gérer les
images de conteneur.
• Les conteneurs sont immuables et éphémères. Il est donc préférable de réserver la mise à jour
d’un conteneur en cours d’exécution à la résolution des problèmes liés aux conteneurs.
DO180-OCP4.14-fr-2-20240530 223
224 DO180-OCP4.14-fr-2-20240530
chapitre 4
Déployer des applications

gérées et en réseau sur
Kubernetes
Objectif Déployer des applications et permettre un
accès depuis l’intérieur et l’extérieur d’un cluster
Kubernetes.
Résultats • Identifier les principaux paramètres et

ressources utilisés par Kubernetes pour gérer
les applications de longue durée, et montrer
comment OpenShift simplifie les workflows de
déploiement d’applications courants.
• Déployer des applications en conteneur en tant
que pods gérés par des ressources de charge
de travail Kubernetes.
• Interconnecter les pods d’applications au
sein du même cluster à l’aide des services
Kubernetes.
• Exposer des applications aux clients situés
à l’extérieur du cluster à l’aide d’une entrée
Kubernetes et de routes OpenShift.
Sections • Déploiement d’applications à partir d’images et

de modèles (et exercice guidé)
• Gestion des applications de longue durée et
de courte durée à l’aide de l’API Kubernetes
Workload (et exercice guidé)
• Réseaux de pods et de services Kubernetes (et
exercice guidé)
• Mise à l’échelle et exposition d’applications
pour un accès externe (et exercice guidé)
Atelier • Déployer des applications gérées et en réseau

sur Kubernetes
DO180-OCP4.14-fr-2-20240530 225
chapitre 4 | Déployer des applications gérées et en réseau sur Kubernetes
Déploiement d’applications à partir

d’images et de modèles
Résultats
• Identifier les principaux paramètres et ressources utilisés par Kubernetes pour gérer les
applications de longue durée, et montrer comment OpenShift simplifie les workflows de
Déploiement d’applications
La tendance actuelle est à l’adoption des microservices et du DevOps dans les logiciels
d’entreprise. Parallèlement à cette tendance, les conteneurs et Kubernetes ont gagné en
popularité, mais sont devenus des catégories à part entière. Les infrastructures basées sur des
conteneurs prennent en charge la plupart des types d’applications traditionnelles et modernes.
Le terme application peut désigner votre système logiciel ou un service qu’il contient. Compte
tenu de cette ambiguïté, il est plus clair de faire référence directement aux ressources, services et
autres composants.
Ressources et définitions de ressources

Kubernetes gère les applications, ou services, comme une collection éparse de ressources. Les
ressources sont des éléments de configuration pour les composants du cluster. Lorsque vous
créez une ressource, le composant correspondant n’est pas créé immédiatement. C’est le cluster
qui est responsable de la création finale du composant.
Un type de ressource représente un type de composant spécifique, tel qu’un pod. Kubernetes est
fourni avec de nombreux types de ressources par défaut, dont certains se chevauchent sur le plan
des fonctionnalités. Outre les types de ressources Kubernetes par défaut, Red Hat OpenShift
Container Platform (RHOCP) fournit ses propres types. Pour ajouter des types de ressources,
vous pouvez créer ou importer des définitions de ressources personnalisées.
Gestion des ressources

Vous pouvez ajouter, afficher et modifier des ressources dans différents formats, dont YAML et
JSON. Traditionnellement, YAML est le format le plus courant.
Vous pouvez supprimer des ressources par lots en utilisant des sélecteurs d’étiquettes, ou en
supprimant l’intégralité du projet ou de l’espace de noms. Par exemple, la commande suivante ne
supprime que les déploiements avec l’étiquette app=my-app.
[user@host ~]$ oc delete deployment -l app=my-app

Comme pour la création, la suppression d’une ressource n’est pas immédiate. Il s’agit plutôt d’une
demande pour une suppression à terme.
226 DO180-OCP4.14-fr-2-20240530
Note
Les commandes exécutées sans spécifier d’espace de noms le sont dans l’espace
de noms actuel de l’utilisateur.
Types de ressources courants et utilisations associées

Sauf indication contraire, les ressources suivantes sont des ressources Kubernetes standard.
Modèles
Tout comme les projets, les modèles constituent un ajout RHOCP à Kubernetes. Un modèle est
un manifeste YAML qui contient des définitions paramétrées d’une ou de plusieurs ressources.
RHOCP fournit des modèles prédéfinis dans l’espace de noms openshift.
Traitez un modèle dans une liste de ressources à l’aide de la commande oc process, qui
remplace les valeurs et génère des définitions de ressources. Les définitions de ressources
obtenues créent ou mettent à jour des ressources dans le cluster en les fournissant à la commande
oc apply.
Par exemple, la commande suivante traite un fichier de modèle mysql-template.yaml et

génère quatre définitions de ressources.
[user@host ~]$ oc process -f mysql-template.yaml -o yaml

apiVersion: v1
items:
- apiVersion: v1
kind: Secret
- apiVersion: v1
kind: Service
- apiVersion: v1
kind: PersistentVolumeClaim
- apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
L’option --parameters affiche à la place les paramètres d’un modèle. La commande suivante,
par exemple, liste les paramètres du fichier mysql-template.yaml.
[user@host ~]$ oc process -f mysql-template.yaml --parameters

NAME DESCRIPTION ...output omitted...
MYSQL_USER Username for MySQL user ...output omitted...
MYSQL_PASSWORD Password for the MySQL connection ...output omitted...
MYSQL_ROOT_PASSWORD Password for the MySQL root user. ...output omitted...
MYSQL_DATABASE Name of the MySQL database accessed. ...output omitted...
VOLUME_CAPACITY Volume space available for data, ...output omitted...
DO180-OCP4.14-fr-2-20240530 227
Vous pouvez utiliser des modèles avec la commande new-app à partir de RHOCP. Dans l’exemple
suivant, la commande new-app utilise le modèle mysql-persistent pour créer une application
MySQL et les ressources associées.
[user@host ~]$ oc new-app --template mysql-persistent

--> Deploying template "db-app/mysql-persistent" to project db-app
The following service(s) have been created in your project: mysql.
Username: userQSL
Password: pyf0yElPvFWYQQou
Database Name: sampledb
Connection URL: mysql://mysql:3306/
* With parameters:
* Memory Limit=512Mi
* Namespace=openshift
* Database Service Name=mysql
* MySQL Connection Username=userQSL # generated
* MySQL Connection Password=pyf0yElPvFWYQQou # generated
* MySQL root user Password=HHbdurqWO5gAog2m # generated
* MySQL Database Name=sampledb
* Volume Capacity=1Gi
* Version of MySQL Image=8.0-el8
--> Creating resources ...

secret "mysql" created
service "mysql" created
persistentvolumeclaim "mysql" created
deploymentconfig.apps.openshift.io "mysql" created
--> Success
Notez que plusieurs ressources sont créées pour répondre aux exigences du déploiement. Il
s’agit notamment d’un secret, d’un service et d’une revendication de volume persistant.
Note
Vous pouvez spécifier des variables d’environnement à configurer lors de la création
de votre application.
Vous pouvez également utiliser des modèles lors de la création d’applications à partir de la console
Web à l’aide du catalogue des développeurs (Developer Catalog). À partir de la perspective
Developer, accédez au menu +Add et cliquez sur All Services dans la section Developer Catalog
pour ouvrir le catalogue. Saisissez ensuite le nom de l’application dans le filtre pour rechercher
un modèle pour votre application. Vous pouvez instancier le modèle et modifier les valeurs par
défaut, telles que le référentiel Git, les limites de mémoire, la version de l’application, etc.
228 DO180-OCP4.14-fr-2-20240530
Vous pouvez ajouter une application basée sur un modèle en passant à la perspective Developer,
puis en passant au menu Topology et en cliquant sur Start building application ou sur l’icône de
livre.
Pod
Dans la documentation RHOCP, un pod est défini comme « la plus petite unité de calcul pouvant
être définie, déployée et gérée ». Un pod exécute un ou plusieurs conteneurs représentant une
seule application. Les conteneurs du pod partagent des ressources, telles que le réseau et le
stockage.
L’exemple suivant montre la définition d’un pod :
apiVersion: v1
kind: Pod
metadata:
annotations: { ... }
labels:
deployment: docker-registry-1
deploymentconfig: docker-registry
DO180-OCP4.14-fr-2-20240530 229
name: registry
namespace: pod-registries
spec:
containers:
- env:
- name: OPENSHIFT_CA_DATA
value: ...
image: openshift/origin-docker-registry:v0.6.2
name: registry
ports:
protocol: TCP
resources: {}
securityContext: { ... }
volumeMounts:
- mountPath: /registry
name: registry-storage
dnsPolicy: ClusterFirst
imagePullSecrets:
- name: default-dockercfg-at06w
restartPolicy: Always
serviceAccount: default
volumes:
- emptyDir: {}
name: registry-storage
status:
conditions: { ... }
Type de ressource défini sur Pod.
Informations décrivant votre application, telles que le nom, le projet, les étiquettes associées
et les annotations.
Section dans laquelle les exigences de l’application sont spécifiées, telles que le nom du
conteneur, l’image du conteneur, les variables d’environnement, les montages de volumes, la
configuration réseau et les volumes.
Indique la dernière condition du pod, telle que l’heure de la dernière sonde, l’heure de la
dernière transition, le paramètre d’état comme true ou false, etc.
Déploiement
À l’instar des configurations de déploiement, les déploiements définissent l’état prévu d’un jeu
de réplicas. Les jeux de réplicas gèrent un nombre configurable de pods correspondant à une
spécification.
En règle générale, les jeux de réplicas sont semblables aux contrôleurs de réplication, auxquels ils
succèdent. Cette différence au niveau des ressources intermédiaires est la principale différence
entre les déploiements et les configurations de déploiement.
Les déploiements et les jeux de réplicas remplacent, respectivement, les configurations de

déploiement et les contrôleurs de réplication selon la norme Kubernetes. Utilisez un déploiement,
sauf si vous avez besoin d’une fonction spécifique à des configurations de déploiement.
L’exemple suivant montre la définition d’un déploiement :
230 DO180-OCP4.14-fr-2-20240530
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-openshift
spec:
replicas: 1
selector:
matchLabels:
app: hello-openshift
template:
metadata:
labels:
app: hello-openshift
spec:
containers:
- name: hello-openshift
image: openshift/hello-openshift:latest
ports:
- containerPort: 80
Type de ressource défini sur Deployment.
Nom de la ressource de déploiement.
Nombre d’instances en cours d’exécution.
Section permettant de définir les métadonnées, les étiquettes et les informations de

conteneur de la ressource de déploiement.
Nom du conteneur.
Ressource de l’image à utiliser pour créer la ressource de déploiement.
Configuration du port, telle que son numéro, son nom et le protocole.
Configurations de déploiement
Les configurations de déploiement définissent la spécification d’un pod. Elles gèrent les pods
en créant des contrôleurs de réplication, lesquels gèrent le nombre de réplicas d’un pod. Les
configurations de déploiement et les contrôleurs de réplication constituent un ajout RHOCP à
Kubernetes.
Note
Depuis OpenShift Container Platform 4.14, les objets de configuration de
déploiement sont obsolètes. Ils sont toujours pris en charge, mais ne sont pas
recommandés pour les nouvelles installations.
Utilisez plutôt des objets Deployment ou une autre solution pour fournir des mises à
jour déclaratives pour les pods.
Projets
RHOCP ajoute des projets pour améliorer la fonction des espaces de noms Kubernetes. Un
projet est un espace de noms Kubernetes avec des annotations supplémentaires. Il s’agit de la
DO180-OCP4.14-fr-2-20240530 231
principale méthode de gestion de l’accès aux ressources pour les utilisateurs standard. Les projets
peuvent être créés à partir de modèles et doivent utiliser le contrôle d’accès basé sur les rôles
pour la gestion de l’organisation et des autorisations. Les administrateurs doivent accorder aux
utilisateurs du cluster l’accès à un projet. Si l’utilisateur d’un cluster est autorisé à créer des projets,
il a directement accès aux projets qui ont été créés.
Les projets séparent les ressources de vos composants d’application de manière logique et
organisationnelle. Les ressources d’un projet peuvent accéder aux ressources d’autres projets,
mais pas par défaut.
L’exemple suivant montre la définition d’un projet :
apiVersion: project.openshift.io/v1
kind: Project
metadata:
name: test
spec:
finalizers:
- kubernetes
Type de ressource défini sur Project.
Nom du projet.
Un finaliseur est une clé de métadonnées spéciale qui indique à Kubernetes d’attendre
qu’une condition spécifique soit remplie avant de supprimer complètement une ressource.
Services
Vous pouvez configurer une communication réseau interne de pod à pod dans RHOCP à l’aide
de l’objet Service. Les applications envoient des requêtes au port et au nom du service. RHOCP
fournit un réseau virtuel qui redirige ces requêtes vers les pods ciblés par le service en utilisant des
étiquettes.
L’exemple suivant montre la définition d’un service :
apiVersion: v1
kind: Service
metadata:
name: docker-registry
namespace: test
spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
Type de ressource défini sur Service.
Nom du service.
Nom du projet dans lequel se trouve la ressource de service.
232 DO180-OCP4.14-fr-2-20240530
Le sélecteur d’étiquette identifie tous les pods auxquels est associée l’étiquette app=MyApp
et les ajoute aux points d’accès du service.
Protocole Internet défini sur TCP.
Port sur lequel le service écoute.
Port sur les pods de sauvegarde vers lequel le service redirige les connexions.
Réclamations de volume persistantes

RHOCP utilise la structure de volume persistant (PV) Kubernetes pour permettre aux
administrateurs du cluster d’approvisionner un stockage persistant pour un cluster. Les
développeurs peuvent utiliser des revendications de volume persistant (PVC) pour demander
des ressources PV sans connaître spécifiquement l’infrastructure de stockage sous-jacente. Une
fois qu’un PV est lié à une PVC, il ne peut pas être lié à d’autres. Étant donné que les PVC sont
des objets avec espace de noms et que les PV sont des objets ayant une étendue globale, cette
liaison étend efficacement un PV lié à un seul espace de noms jusqu’à ce que la PVC de liaison soit
supprimée.
L’exemple suivant montre la définition d’une revendication de volume persistant :
apiVersion: v1
metadata:
name: mysql-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
storageClassName: nfs-storage
status:
...
Type de ressource défini sur PersistentVolumeClaim.
Nom du service.
Mode d’accès, pour définir les autorisations de lecture/écriture et de montage.
Quantité de stockage disponible pour la PVC.
Nom de la classe StorageClass requise par la revendication.
Secrets
Les secrets fournissent un mécanisme permettant de conserver des informations sensibles, telles
que des mots de passe, les informations d’identification du référentiel source privé, des fichiers de
configuration sensibles et les informations d’identification d’une ressource externe, comme une
clé SSH ou un token OAuth. Vous pouvez monter des secrets dans des conteneurs à l’aide d’un
plug-in de volume. Kubernetes peut également utiliser des secrets pour effectuer des actions sur
un pod, comme déclarer des variables d’environnement. Les secrets peuvent stocker n’importe
quel type de données. Kubernetes et OpenShift prennent en charge différents types de secrets,
tels que les tokens de compte de service, les clés SSH et les certificats TLS.
DO180-OCP4.14-fr-2-20240530 233
L’exemple suivant montre la définition d’un secret :
apiVersion: v1
kind: Secret
metadata:
name: example-secret
namespace: my-app
type: Opaque
data:
username: bXl1c2VyCg==
password: bXlQQDU1Cg==
stringData:
hostname: myapp.mydomain.com
secret.properties: |
property1=valueA
property2=valueB
Type de ressource défini sur Secret.
Nom du service.
Nom du projet dans lequel se trouve la ressource de service.
Spécifie le type de secret.
Spécifie la chaîne et les données encodées.
Spécifie la chaîne et les données décodées.
Gestion de ressources à partir de la ligne de

commande
Kubernetes et RHOCP proposent de nombreuses commandes pour créer et modifier des
ressources de cluster. Certaines d’entre elles font partie du noyau Kubernetes, tandis que d’autres
sont des ajouts exclusifs à RHOCP.
Les commandes de gestion des ressources appartiennent généralement à l’une des deux
catégories suivantes : déclarative ou impérative. Une commande impérative indique ce que doit
faire le cluster. Une commande déclarative définit l’état avec lequel le cluster tente d’établir une
correspondance.
Gestion impérative des ressources

La commande create est une méthode « impérative » pour créer des ressources. Elle est incluse
dans les commandes oc et kubectl. Par exemple, la commande suivante crée un déploiement
appelé my-app qui crée des pods en fonction de l’image spécifiée.
[user@host ~]$ oc create deployment my-app --image example.com/my-image:dev

deployment.apps/my-app created
Utilisez la commande set pour définir des attributs sur une ressource, tels que des variables
d’environnement. Par exemple, la commande suivante ajoute la variable d’environnement
TEAM=red au déploiement précédent.
234 DO180-OCP4.14-fr-2-20240530
[user@host ~]$ oc set env deployment/my-app TEAM=red

deployment.apps/my-app updated
La commande run est une autre approche impérative de création d’une ressource. Dans l’exemple
suivant, la commande run crée le pod example-pod.
[user@host ~]$ oc run example-pod \

--image=registry.access.redhat.com/ubi8/httpd-24 \
--env GREETING='Hello from the awesome container' \
--port 8080
pod/example-pod created
Définition du pod .metadata.name.
Image utilisée pour le seul conteneur de ce pod.
Variable d’environnement utilisée pour le seul conteneur de ce pod.
Définition des métadonnées du port.
Les commandes impératives permettent de créer des pods plus rapidement, car elles ne
nécessitent pas de définition d’objet pod. Cependant, les développeurs ne peuvent pas gérer le
contrôle de version ni modifier la définition du pod de manière incrémentielle.
En règle générale, les développeurs testent un déploiement à l’aide de commandes impératives,

puis utilisent ces commandes pour générer la définition de l’objet pod. Utilisez l’option --dry-
run=client pour éviter de créer l’objet dans RHOCP. En outre, utilisez l’option -o yaml ou -o
json pour configurer le format de définition.
La commande suivante est un exemple de génération de la définition YAML pour le pod

example-pod :
[user@host ~]$ oc run example-pod \

--image=registry.access.redhat.com/ubi8/httpd-24 \
--env GREETING='Hello from the awesome container' \
--port 8080 \
--dry-run=client -o yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: example-pod
name: example-pod
spec:
containers:
Cette méthode de gestion des ressources est impérative, car vous indiquez au cluster ce qu’il doit
faire plutôt que de déclarer les résultats attendus.
DO180-OCP4.14-fr-2-20240530 235
Gestion déclarative des ressources

L’utilisation de la commande create ne garantit pas que vous créez des ressources de manière
impérative. Par exemple, la fourniture d’un manifeste de manière déclarative crée les ressources
qui sont définies dans le fichier YAML, comme dans la commande suivante.
[user@host ~]$ oc create -f my-app-deployment.yaml

deployment.apps/my-app created
RHOCP ajoute la commande new-app, qui fournit une autre méthode déclarative pour
créer des ressources. Cette commande utilise des méthodes heuristiques pour déterminer
automatiquement les types de ressources à créer en fonction des paramètres spécifiés. Par
exemple, la commande suivante déploie l’application my-app en créant plusieurs ressources, y
compris une ressource de déploiement, à partir d’un fichier manifeste YAML.
[user@host ~]$ oc new-app --file=./example/my-app.yaml

imagestream.image.openshift.io "my-app" created
deployment.apps "my-app" created
services "my-app" created
Dans les exemples create et new-app précédents, vous déclarez l’état prévu des ressources ;
elles sont donc déclaratives.
Vous pouvez également utiliser la commande new-app avec des modèles dans le cadre de la
gestion des ressources. Un modèle décrit l’état prévu des ressources qui doivent être créées
pour qu’une application s’exécute, telles que des configurations de déploiement et des services.
La fourniture d’un modèle à la commande new-app est une forme de gestion déclarative des
ressources.
La commande new-app inclut également des options, telles que --param, qui personnalisent un
déploiement d’application de manière déclarative. Par exemple, lorsque la commande new-app
est utilisée avec un modèle, vous pouvez inclure l’option --param pour remplacer une valeur de
paramètre dans le modèle.
[user@host ~]$ oc new-app --template mysql-persistent \

--param MYSQL_USER=operator --param MYSQL_PASSWORD=myP@55 \
--param MYSQL_DATABASE=mydata \
--param DATABASE_SERVICE_NAME=db
--> Deploying template "db-app/mysql-persistent" to project db-app
The following service(s) have been created in your project: db.
Username: operator
Password: myP@55
Database Name: mydata
Connection URL: mysql://db:3306/
* With parameters:
* Memory Limit=512Mi
* Namespace=openshift
* Database Service Name=db
236 DO180-OCP4.14-fr-2-20240530
* MySQL Connection Username=operator

* MySQL Connection Password=myP@55
* MySQL root user Password=tlH8BThuVgnIrCon # generated
* MySQL Database Name=mydata
* Volume Capacity=1Gi
* Version of MySQL Image=8.0-el8

secret "db" created
service "db" created
persistentvolumeclaim "db" created
deploymentconfig.apps.openshift.io "db" created
--> Success
Comme pour la commande create, vous pouvez utiliser new-app de manière impérative.
Lorsque vous utilisez une image de conteneur avec new-app, vous indiquez au cluster ce qu’il doit
faire, plutôt que de déclarer les résultats attendus. Par exemple, la commande suivante déploie
l’image example.com/my-app:dev en créant plusieurs ressources, y compris une ressource de
déploiement.
[user@host ~]$ oc new-app --image example.com/my-app:dev

imagestream.image.openshift.io "my-app" created
deployment.apps "my-app" created
Vous pouvez également fournir un référentiel Git à la commande new-app. La commande

suivante crée une application nommée httpd24 en utilisant un référentiel Git.
[user@host ~]$ oc new-app https://github.com/apache/httpd.git#2.4.56

imagestream.image.openshift.io "httpd24" created
deployment.apps "httpd24" created
Récupération d’informations sur la ressource

Vous pouvez fournir un argument all aux commandes pour spécifier une liste de types de
ressources courants. Cependant, l’option all ne contient pas tous les types de ressources
disponibles. Au lieu de cela, all est une forme abrégée pour un sous-ensemble prédéfini de
types. Lorsque vous utilisez cet argument de commande, assurez-vous que all contient tous les
types à prendre en compte.
Vous pouvez afficher des informations détaillées sur une ressource, telles que les paramètres
définis, en utilisant la commande describe. Par exemple, RHOCP fournit des modèles dans le
projet openshift à utiliser avec la commande oc new-app. L’exemple de commande suivant
affiche des informations détaillées sur le modèle mysql-ephemeral :
DO180-OCP4.14-fr-2-20240530 237
[user@host ~]$ oc describe template mysql-ephemeral -n openshift

Name: mysql-ephemeral
Namespace: openshift
Parameters:
Name: MEMORY_LIMIT
Display Name: Memory Limit
Description: Maximum amount of memory the container can use.
Required: true
Value: 512Mi
Name: NAMESPACE
Display Name: Namespace
Description: The OpenShift Namespace where the ImageStream resides.
Required: false
Value: openshift
Objects:
Secret ${DATABASE_SERVICE_NAME}
Service ${DATABASE_SERVICE_NAME}
DeploymentConfig.apps.openshift.io ${DATABASE_SERVICE_NAME}
La commande describe ne peut pas générer de sortie structurée, comme les formats YAML ou
JSON. Sans format structuré, la commande describe ne peut pas analyser ni filtrer la sortie avec
des outils tels que JSONPath ou des modèles Go. Utilisez plutôt la commande get pour générer,
puis analyser la sortie structurée d’une ressource.
Références
Documentation OpenShift Container Platform – Understanding Deployment
and DeploymentConfig Objects (Présentation des objets Deployment et
DeploymentConfig)
openshift_container_platform/4.14/html-single/building_applications/index#what-
deployments-are
Documentation OpenShift Container Platform - Working with Projects

(Utilisation de projets)
openshift_container_platform/4.14/html-single/building_applications/
index#working-with-projects
Documentation OpenShift Container Platform – Creating Applications Using

the CLI (Création d’applications à l’aide de l’interface de ligne de commande)
index#creating-applications-using-cli
Documentation OpenShift Container Platform – Using Pods (Utilisation de

pods)
openshift_container_platform/4.14/html-single/nodes/index#nodes-pods-using-
pp
238 DO180-OCP4.14-fr-2-20240530
Exercice guidé
Déploiement d’applications à partir

d’images et de modèles
Déployez une base de données à partir d’une image de conteneur et d’un modèle à l’aide
de l’interface de ligne de commande OpenShift, et comparez les ressources et les attributs
générés par chaque méthode.
Résultats
Au cours de cet exercice, vous allez déployer deux pods de serveur de base de données
MySQL pour comparer les méthodes de déploiement et les ressources créées dans chaque
cas.
• Déployer une base de données à partir d’un modèle.
• Déployer une base de données à partir d’une image de conteneur.
Avant De Commencer
Cette commande permet de s’assurer que les ressources sont disponibles pour l’exercice.
[student@workstation ~]$ lab start deploy-newapp
Instructions
1. En tant qu’utilisateur developer, créez un projet et vérifiez qu’il n’est pas vide après la
création.

1.2. Créez un projet nommé deploy-newapp.
[student@workstation ~]$ oc new-project deploy-newapp

Now using project "deploy-newapp" on server ...output omitted...
Le nouveau projet est automatiquement sélectionné.
1.3. Comme vous pouvez le constater, les ressources du nouveau projet ne sont pas
renvoyées avec la commande oc get all.
DO180-OCP4.14-fr-2-20240530 239
[student@workstation ~]$ oc get all

No resources found in deploy-newapp namespace.
Important
Les commandes qui utilisent all pour le type de ressource n’incluent pas tous
les types de ressources disponibles. Au lieu de cela, all est une forme abrégée
pour un sous-ensemble prédéfini de types. Lorsque vous utilisez cet argument de
commande, assurez-vous que all contient tous les types que vous comptez traiter.
1.4. Notez que le nouveau projet contient d’autres types de ressources.
[student@workstation ~]$ oc get serviceaccounts

NAME SECRETS AGE
builder 1 20s
default 1 20s
deployer 1 20s
[student@workstation ~]$ oc get secrets

NAME TYPE DATA AGE
builder-dockercfg-sczxg kubernetes.io/dockercfg 1 36m
builder-token-gsnqj kubernetes.io/service-account-token 4 36m
default-dockercfg-6f8nm kubernetes.io/dockercfg 1 36m
2. Créez deux instances MySQL en utilisant la commande oc new-app avec des options
différentes.
2.1. Affichez la définition du modèle mysql-persistent pour voir les ressources

qui sont créées. Spécifiez le projet qui héberge le modèle en utilisant l’option -n
openshift.
[student@workstation ~]$ oc describe template mysql-persistent -n openshift

Name: mysql-persistent
Objects:
Secret ${DATABASE_SERVICE_NAME}
Service ${DATABASE_SERVICE_NAME}
PersistentVolumeClaim ${DATABASE_SERVICE_NAME}
DeploymentConfig.apps.openshift.io ${DATABASE_SERVICE_NAME}
L’attribut objects spécifie plusieurs définitions de ressources qui sont appliquées

lors de l’utilisation du modèle. Ces ressources incluent chacun des types suivants :
secret, service (svc), revendication de volume persistant (pvc) et configuration de
déploiement (dc).
2.2. Créez une instance à l’aide du modèle mysql-persistent. Spécifiez une option
name et associez une étiquette team=red personnalisée aux ressources créées.
240 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ oc new-app -l team=red --template mysql-persistent \

-p MYSQL_USER=developer \
-p MYSQL_PASSWORD=developer
--> Creating resources with label team=red ...
secret "mysql" created
service "mysql" created
persistentvolumeclaim "mysql" created
deploymentconfig.apps.openshift.io "mysql" created
--> Success
Le modèle crée des ressources avec les types de l’étape précédente.
2.3. Affichez le pod et attendez qu’il démarre. Cela peut prendre quelques minutes. Vous
devrez peut-être exécuter la commande à plusieurs reprises avant que l’état ne passe
sur Running.

mysql-1-deploy 0/1 Completed 0 93s
mysql-1-qmxbf 1/1 Running 1 60s
Les noms de vos pods peuvent être différents de ceux de la sortie précédente.
2.4. Créez une instance en utilisant une image de conteneur. Spécifiez une option name et
associez une étiquette team=blue personnalisée aux ressources créées.
[student@workstation ~]$ oc new-app --name db-image -l team=blue \

-e MYSQL_USER=developer \
-e MYSQL_PASSWORD=developer \
-e MYSQL_ROOT_PASSWORD=redhat
--> Creating resources with label team=blue ...
imagestream.image.openshift.io "db-image" created
deployment.apps "db-image" created
service "db-image" created
--> Success
La commande crée des ressources prédéfinies qui sont nécessaires au déploiement

d’une image. Ces types de ressources sont le flux d’images (is), le déploiement et le
service (svc). Les flux d’images et les services sont abordés plus en détail dans une
autre partie de ce cours.
Note
Vous pouvez ignorer les avertissements de sécurité des pods pour les exercices de
ce cours. OpenShift utilise le contrôleur Contraintes du contexte de sécurité pour
fournir des valeurs par défaut sécurisées pour la sécurité des pods.
2.5. Attendez que le pod démarre. Après quelques instants, listez tous les pods qui
contiennent team comme étiquette.
DO180-OCP4.14-fr-2-20240530 241
[student@workstation ~]$ oc get pods -L team

NAME READY STATUS RESTARTS AGE TEAM
db-image-8d4b97594-6jb85 1/1 Running 0 55s blue
mysql-1-deploy 0/1 Completed 0 2m
mysql-1-hn64v 1/1 Running 0 1m30s
Le nom de votre pod peut être différent de celui de la sortie précédente. Sans
readinessProbe, ce pod apparaît comme étant prêt avant que le service MySQL
ne soit prêt pour les requêtes. Les sondes Readiness sont abordées plus en détail
dans une autre partie de ce cours.
Notez que seul le pod db-image a une étiquette qui contient le mot team. Les pods
créés par le modèle mysql-persistent n’ont pas l’étiquette team=red, car le
modèle ne définit pas cette étiquette dans son modèle de spécification de pod.
3. Comparez les ressources créées par chaque méthode de modèle et d’image.
3.1. Affichez le pod template-created et notez qu’il contient une sonde Readiness.
[student@workstation ~]$ oc get pods -l deploymentconfig=mysql \

-o jsonpath='{.items[0].spec.containers[0].readinessProbe}' | jq
{
"exec": {
"command": [
"/bin/sh",
"-i",
"-c",
"MYSQL_PWD=\"$MYSQL_PASSWORD\" mysqladmin -u $MYSQL_USER ping"
]
},
"failureThreshold": 3,
"initialDelaySeconds": 5,
"periodSeconds": 10,
"successThreshold": 1,
"timeoutSeconds": 1
}
Note
Les résultats de la commande oc précédente sont transmis à la commande jq, qui
formate la sortie JSON.
3.2. Notez que le pod basé sur une image ne contient pas de sonde Readiness.
[student@workstation ~]$ oc get pods -l deployment=db-image \

-o jsonpath='{.items[0].spec.containers[0].readinessProbe}' | jq
no output expected
3.3. Notez que le pod basé sur un modèle présente une limite de ressources mémoire,
ce qui limite la mémoire allouée aux pods obtenus. Les limites de ressources sont
abordées plus en détail dans une autre partie de ce cours.
242 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ oc get pods -l deploymentconfig=mysql \

-o jsonpath='{.items[0].spec.containers[0].resources.limits}' | jq
{
"memory": "512Mi"
}
3.4. Notez que les ressources ne sont pas limitées dans le cas du pod basé sur une image.
[student@workstation ~]$ oc get pods -l deployment=db-image \

-o jsonpath='{.items[0].spec.containers[0].resources}' | jq
{}
3.5. Récupérez des secrets dans le projet. Notez que le modèle a généré un secret,
contrairement au pod qui a été créé avec uniquement une image.
[student@workstation ~]$ oc get secrets

NAME TYPE DATA AGE
mysql Opaque 4 3m
4. Explorez le filtrage des ressources au moyen d’étiquettes.
4.1. Notez que tous les services sont affichés si aucune étiquette n’est fournie.
[student@workstation ~]$ oc get services

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
db-image ClusterIP 172.30.38.113 <none> 3306/TCP 1m30s
mysql ClusterIP 172.30.95.52 <none> 3306/TCP 2m30s
4.2. Notez que si une étiquette est fournie, seuls les services associés à cette étiquette
sont affichés.
[student@workstation ~]$ oc get services -l team=red

mysql ClusterIP 172.30.95.52 <none> 3306/TCP 2m43s
4.3. Notez que toutes les ressources n’incluent pas l’étiquette ; c’est le cas des pods créés
avec le modèle.
[student@workstation ~]$ oc get pods -l team=red

5. Utilisez des étiquettes pour supprimer uniquement les ressources associées au

déploiement basé sur un modèle.
5.1. Supprimez uniquement les ressources qui utilisent l’étiquette team=red en l’utilisant
avec la commande oc delete. Listez les types de ressources du modèle pour vous
assurer que toutes les ressources pertinentes sont supprimées.
DO180-OCP4.14-fr-2-20240530 243
[student@workstation ~]$ oc delete all -l team=red

replicationcontroller "mysql-1" deleted
service "mysql" deleted
deploymentconfig.apps.openshift.io "mysql" deleted
[studen@workstation ~]$ oc delete secret,pvc -l team=red

secret "mysql" deleted
persistentvolumeclaim "mysql" deleted
Note
L’utilisation de la commande oc delete all -l team=red supprime certaines
ressources, mais la revendication de volume persistant et le secret sont conservés.
5.2. Notez que les ressources créées par le modèle sont supprimées.
[student@workstation ~]$ oc get secret,svc,pvc,dc -l team=red

5.3. Notez que les ressources basées sur une image restent inchangées.
[student@workstation ~]$ oc get is,deployment,svc

NAME IMAGE REPOSITORY ...output omitted...
imagestream.image.openshift.io/db-image image-registry.openshift...output
omitted...
deployment.apps/db-image 1/1 1 1 46m

service/db-image ClusterIP 172.30.71.0 <none> 3306/TCP 46m
Fin
[student@workstation ~]$ lab finish deploy-newapp
244 DO180-OCP4.14-fr-2-20240530
Gestion des applications de longue

durée et de courte durée à l’aide de l’API
Kubernetes Workload
Résultats
• Déployer des applications en conteneur en tant que pods gérés par des ressources de charge de
travail Kubernetes.
Ressources de charge de travail Kubernetes

L’API Kubernetes Workloads se compose de ressources qui représentent différents types de
tâches, de jobs et de charges de travail de cluster. Cette API est composée de diverses API et
extensions Kubernetes qui simplifient le déploiement et la gestion d’applications. Les types de
ressources de l’API Workloads les plus utilisés sont les suivants :
• Jobs
• Déploiements
• Ensembles avec état
Jobs
Une ressource de job représente une tâche unique à effectuer sur le cluster. Comme pour la
plupart des tâches de cluster, les jobs sont exécutés via des pods. Si le pod d’un job échoue, le
cluster réessaie autant de fois que le job l’indique. Le job cesse de s’exécuter après un nombre
spécifié d’exécutions réussies.
Les jobs diffèrent de l’utilisation des commandes kubectl run et oc run ; ces deux dernières
créent uniquement un pod.
Voici quelques exemples d’utilisations courantes des jobs :
• Initialisation ou migration d’une base de données

• Calcul de métriques ponctuelles à partir d’informations au sein du cluster
• Création ou restauration à partir d’une sauvegarde de données
L’exemple de commande suivant crée un job qui enregistre la date et l’heure :
[user@host ~]$ oc create job \

date-job \
-- /bin/bash -c "date"
Crée une ressource de job.
Spécifie le nom de job date-job.
Définit registry.access.redhat.com/ubi8/ubi comme image de conteneur pour les

pods de job
Spécifie la commande à exécuter à l’intérieur des pods.
DO180-OCP4.14-fr-2-20240530 245
Vous pouvez également créer une tâche à partir de la console Web en cliquant sur le menu
Workloads > Jobs. Cliquez sur Create Job et personnalisez le manifeste YAML.
Tâches cron
Une ressource tâche cron s’appuie sur une ressource de tâche standard en vous permettant
de spécifier la fréquence d’exécution de la tâche. Les tâches cron sont particulièrement utiles
pour créer des tâches périodiques et récurrentes, telles que des sauvegardes ou pour générer
des rapports. Elles permettent également de planifier des tâches individuelles pour une heure
spécifique ; une tâche au cours d’une période de faible activité, par exemple. À l’instar du fichier
crontab (table cron) sur un système Linux, la ressource CronJob utilise le format Cron pour
la planification. Une ressource CronJob crée une ressource job en fonction du fuseau horaire
configuré sur le nœud du plan de contrôle qui exécute le contrôleur de tâche cron.
L’exemple de commande suivant crée une tâche cron intitulée date qui imprime la date et l’heure
système toutes les minutes :
[user@host ~]$ oc create cronjob date-cronjob \

--schedule "*/1 * * * *" \
-- date
Crée une ressource de tâche cron intitulée date-cronjob.

pods de la tâche.
Spécifie le programme de la tâche au format Cron.
Commande à exécuter à l’intérieur des pods.
Vous pouvez également créer un cronjob à partir de la console Web en cliquant sur le menu
Workloads > CronJobs. Cliquez sur Create CronJob et personnalisez le manifeste YAML.
Déploiements
Un déploiement _ crée un jeu de réplicas pour gérer les pods. Un _jeu de réplicas gère un nombre
spécifié de réplicas d’un pod. Les jeux de réplicas utilisent des sélecteurs, tels qu’une étiquette,
pour identifier les pods qui en font partie. Des pods sont créés ou supprimés jusqu’à ce que les
réplicas atteignent le nombre spécifié par le déploiement. Les jeux de réplicas ne sont pas gérés
directement, mais de manière indirecte par les déploiements.
Contrairement aux jobs, les pods d’un déploiement sont recréés après un plantage ou une
suppression. Cela est dû au fait que les déploiements utilisent des jeux de réplicas.
L’exemple de commande suivant crée un déploiement :
[user@host ~]$ oc create deployment \

my-deployment \
--replicas 3
Crée une ressource de déploiement.
Spécifie my-deployment comme nom de déploiement.
246 DO180-OCP4.14-fr-2-20240530

pods.
Définit le déploiement pour gérer trois instances du pod.
Vous pouvez également créer un déploiement à partir de la console Web en cliquant sur l’onglet
Deployments dans le menu Workloads.
Cliquez sur Create Deployment et personnalisez le formulaire ou le manifeste YAML.
Les pods d’un jeu de réplicas sont identiques et correspondent au modèle de pod dans la
définition du jeu de réplicas. Si le nombre de réplicas n’est pas atteint, un nouveau pod est créé à
l’aide du modèle. Par exemple, si un pod plante ou s’il est supprimé, un nouveau pod est créé pour
le remplacer.
Les étiquettes constituent un type de métadonnées de ressource qui sont représentées sous la
forme de paires clé-valeur de chaîne. Une étiquette indique une caractéristique commune pour
les ressources auxquelles elle est associée. Par exemple, vous pouvez associer une étiquette
layer=frontend aux ressources liées aux composants d’interface utilisateur d’une application.
De nombreuses commandes oc et kubectl acceptent une étiquette pour filtrer les ressources
affectées. Par exemple, la commande suivante supprime tous les pods avec l’étiquette
environment=testing :
DO180-OCP4.14-fr-2-20240530 247
[user@host ~]$ oc delete pod -l environment=testing
En appliquant librement des étiquettes aux ressources, vous pouvez référencer les ressources
et créer des sélecteurs précis. Un sélecteur est un objet de requête qui décrit les attributs de
ressources correspondantes.
Certaines ressources utilisent des sélecteurs pour en rechercher d’autres. Dans l’extrait YAML
suivant, un exemple de jeu de réplicas utilise un sélecteur pour faire correspondre ses pods.
apiVersion: apps/v1
kind: ReplicaSet
spec:
replicas: 1
selector:
matchLabels:
app: httpd
pod-template-hash: 7c84fbdb57
Ensembles avec état

À l’instar des déploiements, les ensembles avec état gèrent un ensemble de pods en fonction
d’une spécification de conteneur. Cependant, chaque pod créé par un ensemble avec état est
unique. L’unicité du pod s’avère utile lorsque, par exemple, un pod a besoin d’un identifiant réseau
unique ou d’un stockage persistant.
Comme leur nom l’indique, les ensembles avec état sont destinés aux pods qui nécessitent un état
au sein du cluster. Les déploiements sont utilisés pour les pods sans état.
Vous trouverez une description détaillée des ensembles avec état dans un chapitre ultérieur.
Références
Charges de travail Kubernetes
https://kubernetes.io/docs/concepts/workloads/
Étiquettes et sélecteurs Kubernetes

https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
248 DO180-OCP4.14-fr-2-20240530
Exercice guidé
Gestion des applications de longue

durée et de courte durée à l’aide de l’API
Kubernetes Workload
Déployez une application par lots gérée par une ressource de tâche et un serveur de base
de données géré par une ressource de déploiement en utilisant l’interface de ligne de
commande Kubernetes.
Résultats
Au cours de cet exercice, vous allez déployer un serveur de base de données et une
application par lots qui sont tous deux gérés par des ressources de charge de travail.
• Créer des déploiements.
• Mettre à jour des variables d’environnement sur un modèle de pod.
• Créer et exécuter des ressources de tâche.
• Récupérer les journaux et l’état d’arrêt d’une tâche.
• Afficher le modèle de pod d’une ressource de tâche.
Avant De Commencer
Cette commande permet de s’assurer que les ressources sont disponibles pour l’exercice.
[student@workstation ~]$ lab start deploy-workloads
Instructions
1. En tant qu’utilisateur developer, créez un déploiement MySQL dans un nouveau projet.

1.2. Créez un projet nommé deploy-workloads.
[student@workstation ~]$ oc new-project deploy-workloads

Now using project "deploy-workloads" on server "https://
api.ocp4.example.com:6443".
DO180-OCP4.14-fr-2-20240530 249
1.3. Créez un déploiement qui exécute un serveur MySQL éphémère.
[student@workstation ~]$ oc create deployment my-db \

--image registry.ocp4.example.com:8443/rhel9/mysql-80:1
deployment.apps/my-db created
1.4. Récupérez l’état du déploiement.
[student@workstation ~]$ oc get deployments

my-db 0/1 1 0 67s
Le déploiement n’a jamais d’instance « Ready ».
1.5. Récupérez l’état du pod créé. Le nom de votre pod peut être différent de celui de la
sortie.

my-db-8567b478dd-d28f7 0/1 CrashLoopBackOff 4 (60s ago) 2m35s
Le pod ne démarre pas et plante à plusieurs reprises. Si l’état du pod revient à

Pending, accordez au pod quelques minutes pour se bloquer avant de continuer.
1.6. Examinez les journaux du pod pour déterminer la cause de l’échec de démarrage.
[student@workstation ~]$ oc logs deploy/my-db

MYSQL_USER (regex: '^$')
MYSQL_PASSWORD (regex: '^[a-zA-Z0-9_~!@#$%^&*()-=<>,.?;:|]$')
MYSQL_DATABASE (regex: '^$')
MYSQL_ROOT_PASSWORD (regex: '^[a-zA-Z0-9_~!@#$%^&*()-=<>,.?;:|]$')
Notez que le conteneur ne démarre pas, car il manque des variables d’environnement.
2. Corrigez le déploiement de la base de données et vérifiez que le serveur est en cours

d’exécution.
2.1. Définissez les variables d’environnement MYSQL_USER, MYSQL_PASSWORD et

MYSQL_DATABASE.
[student@workstation ~]$ oc set env deployment/my-db \

MYSQL_USER=developer \
MYSQL_PASSWORD=developer \
MYSQL_DATABASE=sampledb
deployment.apps/my-db updated
2.2. Récupérez la liste des déploiements et notez qu’un pod est en cours d’exécution sur
le déploiement my-db.
250 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ oc get deployments

my-db 1/1 1 1 4m50s
2.3. Récupérez l’adresse IP interne du pod MySQL dans la liste de tous les pods.
[student@workstation ~]$ oc get pods -o wide

NAME READY STATUS RESTARTS AGE IP ...
my-db-748c97d478-g8xc9 1/1 Running 0 64s 10.8.0.91 ...
L’option -o wide active des sorties supplémentaires, telles que les adresses IP. Votre
valeur d’adresse IP peut être différente de celle de la sortie précédente.
2.4. Exécutez une requête pour vérifier que le serveur de base de données est en cours
d’exécution. Remplacez l’adresse IP par celle que vous avez récupérée à l’étape
précédente.
[student@workstation ~]$ oc run -it db-test --restart=Never \

-- mysql sampledb -h 10.8.0.91 -u developer --password=developer \
-e "select 1;"
---
| 1 |
---
| 1 |
---
3. Supprimez le pod du serveur de base de données et notez qu’il est recréé à la suite du
déploiement.
3.1. Supprimez le pod MySQL existant en utilisant l’étiquette associée au déploiement.
[student@workstation ~]$ oc delete pod -l app=my-db

pod "my-db-84c8995d5-2sssl" deleted
3.2. Récupérez les informations du pod MySQL et, comme vous pouvez le constater, il
vient d’être créé. Le nom de votre pod peut être différent dans votre sortie.
[student@workstation ~]$ oc get pod -l app=my-db

my-db-fbccb9447-p99jd 1/1 Running 0 6s
4. Créez et appliquez une ressource de tâche qui imprime l’heure et la date de manière
répétitive.
4.1. Créez une ressource de tâche appelée date-loop qui exécute un script. Ignorez
l’avertissement.
DO180-OCP4.14-fr-2-20240530 251
[student@workstation ~]$ oc create job date-loop \

-- /bin/bash -c "for i in {1..30}; do date; done"
job.batch/date-loop created
4.2. Récupérez la ressource de tâche afin d’examiner la spécification du pod.
[student@workstation ~]$ oc get job date-loop -o yaml

spec:
containers:
- command:
- /bin/bash
- -c
- for i in {1..30}; do date; done
image: registry.ocp4.example.com:8443/ubi9/ubi
name: date-loop
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
restartPolicy: Never
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
L’objet command spécifie le script défini à exécuter dans le pod.
Définit l’image de conteneur pour le pod.
Définit la politique de redémarrage pour le pod. Kubernetes ne redémarre pas le

pod de tâche après sa fermeture.
4.3. Listez les tâches pour vérifier que la tâche date-loop a bien été exécutée.
[student@workstation ~]$ oc get jobs

NAME COMPLETIONS DURATION AGE
date-loop 1/1 7s 8s
Vous devrez peut-être attendre la fin du script et exécuter à nouveau la commande.
4.4. Récupérez les journaux du pod associé. Les valeurs de journal peuvent être
différentes dans votre sortie.
[student@workstation ~]$ oc logs job/date-loop

Fri Nov 18 14:50:56 UTC 2022
Fri Nov 18 14:50:59 UTC 2022
5. Supprimez le pod pour la tâche date-loop et notez que le pod n’est pas recréé.
252 DO180-OCP4.14-fr-2-20240530
5.1. Supprimez le pod associé.
[student@workstation ~]$ oc delete pod -l job-name=date-loop

pod "date-loop-wvn2q" deleted
5.2. Affichez la liste des pods et notez que le pod n’est pas recréé pour la tâche.
[student@workstation ~]$ oc get pod -l job-name=date-loop

No resources found in deploy-workloads namespace.
5.3. Vérifiez que l’état de la tâche est toujours listé comme étant terminé avec succès.
[student@workstation ~]$ oc get job -l job-name=date-loop

date-loop 1/1 7s 7m36s
Fin
[student@workstation ~]$ lab finish deploy-workloads
DO180-OCP4.14-fr-2-20240530 253
Réseaux de pods et de services

Kubernetes
Résultats
• Interconnecter les pods d’applications au sein du même cluster à l’aide des services Kubernetes.
Réseau défini par logiciel (SDN)

Kubernetes implémente un réseau défini par logiciel (SDN) pour gérer l’infrastructure réseau du
cluster et des applications utilisateur. Le réseau SDN est un réseau virtuel qui englobe tous les
nœuds du cluster. Le réseau virtuel permet une communication entre tout conteneur ou pod à
l’intérieur du cluster. Les processus de nœud de cluster gérés par les pods Kubernetes peuvent
accéder au réseau SDN. Cependant, le réseau SDN n’est pas accessible depuis l’extérieur du
cluster, ni par les processus standard sur les nœuds du cluster. Le modèle réseau défini par logiciel
vous permet de gérer les services réseau grâce à l’abstraction de plusieurs couches réseau.
Le réseau SDN vous permet de gérer le trafic et les ressources réseau par programme, afin que les
équipes de l’organisation puissent décider comment exposer leurs applications. L’implémentation
SDN crée un modèle compatible avec les pratiques réseau traditionnelles. Cela rend les pods
comparables à des machines virtuelles en termes d’allocation de ports, de location d’adresses IP
et de réservation.
Avec la conception du SDN, il n’est pas nécessaire de modifier la façon dont les composants
de l’application communiquent les uns avec les autres, ce qui facilite la mise en conteneur des
applications existantes. Si votre application comprend de nombreux services qui communiquent
par le biais de la pile TCP/UDP, cette approche fonctionne toujours, car les conteneurs d’un pod
utilisent la même pile réseau.
Le schéma ci-dessous montre comment tous les pods sont connectés à un réseau partagé :
Figure 4.5: Gestion du réseau par le SDN Kubernetes
Parmi les nombreuses fonctions du SDN, les normes ouvertes permettent aux fournisseurs de
proposer leurs solutions pour une gestion centralisée, un routage dynamique et l’isolation des
tenants.
254 DO180-OCP4.14-fr-2-20240530
Mise en réseau Kubernetes

La mise en réseau dans Kubernetes fournit un mode de communication évolutif entre les
conteneurs.
La mise en réseau Kubernetes offre les fonctionnalités suivantes :
• Communications de conteneur à conteneur à couplage fort
• Communications de pod à pod
• Communications du pod vers le service
• Communication externe vers le service : cette fonctionnalité est traitée dans la section Mise à
l’échelle et exposition d’applications pour un accès externe
Kubernetes attribue automatiquement une adresse IP à chaque pod. Cependant, les adresses IP
des pods sont instables, car les pods sont éphémères. Les pods sont constamment créés et
détruits sur les nœuds du cluster. Par exemple, lorsque vous déployez une nouvelle version de
votre application, Kubernetes détruit les pods existants, puis en déploie de nouveaux.
Tous les conteneurs d’un pod partagent des ressources réseau. L’adresse IP et l’adresse MAC
attribuées au pod sont partagées entre tous les conteneurs du pod. Tous les conteneurs d’un
pod peuvent ainsi accéder aux ports des autres via l’adresse de bouclage localhost. Les ports
liés à localhost sont disponibles pour tous les conteneurs qui s’exécutent à l’intérieur du pod. En
revanche, ils ne le sont jamais pour les conteneurs situés en dehors.
Par défaut, les pods peuvent communiquer entre eux même s’ils s’exécutent sur des nœuds de
cluster différents ou appartiennent à des espaces de noms Kubernetes différents. Chaque pod se
voit attribuer une adresse IP dans un espace de noms réseau plat partagé ayant un accès complet
aux autres ordinateurs physiques et conteneurs sur le réseau. Une adresse IP unique est attribuée
à tous les pods à partir d’une plage d’adresses hôtes CIDR (Classless Inter-Domain Routing). La
plage d’adresses partagée place tous les pods dans le même sous-réseau.
Étant donné que tous les pods se trouvent sur le même sous-réseau, les pods de tous les nœuds
peuvent communiquer avec ceux de n’importe quel autre nœud sans recourir à la traduction
d’adresses réseau (NAT). Kubernetes fournit également un sous-réseau de services, qui lie
l’adresse IP stable d’une ressource de service à un ensemble de pods spécifiés. Le trafic est
acheminé de manière transparente vers les pods ; un agent (selon le mode réseau utilisé) gère
les règles de routage pour acheminer le trafic vers les pods qui correspondent aux sélecteurs de
ressource du service. Les pods peuvent donc être considérés comme des machines virtuelles ou
des hôtes physiques du point de vue de l’allocation de ports, de la mise en réseau, de l’attribution
de noms, de la découverte de services, de l’équilibrage de charge, de la configuration des
applications et de la migration. Kubernetes met en œuvre cette infrastructure en gérant le réseau
SDN.
L’illustration suivante vous permet de mieux comprendre la façon dont les composants
d’infrastructure fonctionnent avec les sous-réseaux de pods et de services pour permettre un
accès réseau entre les pods à l’intérieur d’une instance OpenShift.
DO180-OCP4.14-fr-2-20240530 255
Figure 4.6: Accès réseau entre les pods d’un cluster
L’espace de noms réseau partagé des pods permet un modèle de communication simple.
Cependant, la nature dynamique des pods pose problème. Des pods peuvent être ajoutés à
la volée pour gérer une augmentation du trafic. De même, ils peuvent être réduits de manière
dynamique. Si un pod échoue, Kubernetes le remplace automatiquement par un nouveau. Ces
événements modifient les adresses IP des pods.
256 DO180-OCP4.14-fr-2-20240530
Figure 4.7: Problème d’accès direct aux pods
Dans le schéma, le côté Before illustre le conteneur Front-end qui s’exécute dans un pod
avec l’adresse IP 10.8.0.1. Le conteneur fait également référence à un conteneur Back-
end qui s’exécute dans un pod avec l’adresse IP 10.8.0.2. Dans cet exemple, un événement
se produit et entraîne l’échec du conteneur Back-end. L’échec d’un pod peut être dû à de
nombreux facteurs. En réponse à l’échec, Kubernetes crée un pod pour le conteneur Back-end,
qui utilise une nouvelle adresse IP, 10.8.0.4. Du côté After du schéma, le conteneur Front-
end a désormais une référence non valide au conteneur Back-end en raison du changement
d’adresse IP. Kubernetes résout ce problème avec des ressources service.
Utilisation des services

Les conteneurs qui se trouvent à l’intérieur des pods Kubernetes ne doivent pas se connecter
directement à l’adresse IP dynamique de leurs homologues. À la place, Kubernetes attribue une
adresse IP stable à une ressource de service qui est liée à un ensemble de pods spécifiés. Le
service agit ensuite comme un équilibreur de charge de réseau virtuel pour les pods qui y sont liés.
Si les pods sont redémarrés, répliqués ou replanifiés sur des nœuds différents, les points d’accès
du service sont mis à jour, offrant ainsi une évolutivité et une tolérance aux pannes pour vos
applications. Contrairement aux adresses IP des pods, celles des services ne changent pas.
DO180-OCP4.14-fr-2-20240530 257
Figure 4.8: Les services résolvent les problèmes de défaillance des pods
Dans le schéma, le côté Before montre que le conteneur Front-end contient désormais une
référence à l’adresse IP stable du service Back-end, au lieu de l’adresse IP du pod qui exécute
le conteneur Back-end. Lorsque le conteneur Back-end échoue, Kubernetes crée un pod avec
le conteneur New back-end pour remplacer le pod défaillant. En réponse à la modification,
Kubernetes supprime le pod défaillant de la liste des hôtes du service, ou des points d’accès
du service, puis ajoute l’adresse IP du pod de conteneur New back-end aux points d’accès
du service. Avec l’ajout du service, les demandes du conteneur Front-end vers le conteneur
Back-end continuent de fonctionner, car le service est mis à jour de manière dynamique avec le
changement d’adresse IP. Un service fournit une adresse IP statique permanente à un groupe de
pods appartenant au même déploiement ou au même jeu de réplicas pour une application. Tant
que vous n’avez pas supprimé le service, l’adresse IP attribuée ne change pas et le cluster ne la
réutilise pas.
La plupart des applications réelles ne s’exécutent pas comme un pod unique. Les applications
doivent être mises à l’échelle horizontalement. Plusieurs pods exécutent les mêmes conteneurs
pour répondre à une demande croissante des utilisateurs. Une ressource de déploiement gère
plusieurs pods qui exécutent le même conteneur. Un service fournit une seule adresse IP pour
l’intégralité du jeu, ainsi qu’un équilibrage de charge pour les demandes des clients entre les pods
membres.
Les services permettent aux conteneurs d’un pod d’ouvrir des connexions réseau vers les
conteneurs d’un autre pod. Il n’est pas nécessaire que les pods, dont le service effectue le
suivi, existent sur le même nœud de calcul, ou dans le même espace de noms ou projet. Étant
donné qu’un service fournit une adresse IP stable que d’autres pods peuvent utiliser, il n’est
pas nécessaire non plus qu’un pod découvre la nouvelle adresse IP d’un autre pod après un
redémarrage. Le service fournit une adresse IP stable à utiliser, quel que soit le nœud de calcul qui
exécute le pod après chaque redémarrage.
258 DO180-OCP4.14-fr-2-20240530
Figure 4.9: Service avec des pods sur de nombreux nœuds
L’objet SERVICE fournit une adresse IP stable pour le conteneur CLIENT sur NODE X afin
d’envoyer une demande à l’un des conteneurs API.
Kubernetes utilise des étiquettes sur les pods pour sélectionner ceux qui sont associés à un
service. Pour qu’un pod puisse être inclus dans un service, les étiquettes de pod doivent inclure
chacun des champs selector du service.
selector:
app: myapp
label: label: label:

app: myapp app: myapp app: myapp
Figure 4.10: Correspondance du sélecteur de service avec les étiquettes de pod
Dans cet exemple, le sélecteur a la paire clé-valeur app: myapp. Dès lors, les pods avec
l’étiquette correspondante app: myapp sont inclus dans l’ensemble qui est associé au service.
L’attribut selector d’un service est utilisé pour identifier l’ensemble des pods qui forment les points
d’accès du service. Chaque pod de l’ensemble est un point d’accès du service.
DO180-OCP4.14-fr-2-20240530 259
Pour créer un service pour un déploiement, utilisez la commande oc expose :
[user@host ~]$ oc expose deployment/<deployment-name> [--selector <selector>]

[--port <port>][--target-port <target port>][--protocol <protocol>][--name <name>]
La commande oc expose peut utiliser l’option --selector pour spécifier les sélecteurs
d’étiquettes à utiliser. Lorsque la commande est utilisée sans l’option --selector, elle applique
un sélecteur pour établir une correspondance avec le contrôleur de réplication ou le jeu de
réplicas.
L’option --port de la commande oc expose spécifie le port sur lequel le service écoute. Ce
port est disponible uniquement pour les pods à l’intérieur du cluster. Si aucune valeur de port n’est
fournie, le port est copié à partir de la configuration de déploiement.
L’option --target-port de la commande oc expose spécifie le nom ou le numéro du port de

conteneur que le service utilise pour communiquer avec les pods.
L’option --protocol détermine le protocole réseau du service. Le protocole TCP est utilisé par
défaut.
L’option --name de la commande oc expose peut nommer explicitement le service. Si rien n’est
spécifié, le service utilise le même nom que celui qui est fourni pour le déploiement.
Pour afficher le sélecteur utilisé par un service, utilisez l’option -o wide avec la commande oc
get.
[user@host ~]$ oc get service db-pod -o wide

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
db-pod ClusterIP 172.30.108.92 <none> 3306/TCP 108s app=db-pod
Dans cet exemple, db-pod est le nom du service. Les pods doivent utiliser l’étiquette app=db-
pod pour être inclus dans la liste d’hôtes du service db-pod. Pour afficher les points d’accès
utilisés par un service, utilisez la commande oc get endpoints.
[user@host ~]$ oc get endpoints

NAME ENDPOINTS AGE
db-pod 10.8.0.86:3306,10.8.0.88:3306 27s
Cet exemple illustre un service avec deux pods dans la liste d’hôtes. La commande oc get
endpoints renvoie tous les points d’accès du service dans le projet sélectionné. Ajoutez le nom
du service à la commande pour n’afficher que les points d’accès d’un seul service. Utilisez l’option
--namepace pour afficher les points d’accès dans un autre espace de noms.
Utilisez la commande oc describe deployment <deployment name> pour afficher le

sélecteur de déploiement.
260 DO180-OCP4.14-fr-2-20240530
[user@host ~]$ oc describe deployment db-pod

Name: db-pod
Namespace: deploy-services
CreationTimestamp: Wed, 18 Jan 2023 17:46:03 -0500
Labels: app=db-pod
Annotations: deployment.kubernetes.io/revision: 2
Selector: app=db-pod
Vous pouvez afficher ou analyser le sélecteur de la sortie YAML ou JSON pour la ressource de
déploiement à partir de l’objet spec.selector.matchLabels. Dans cet exemple, l’option -o
yaml de la commande oc get renvoie l’étiquette selector utilisée par le déploiement.
[user@host ~]$ oc get deployment/<deployment_name> -o yaml

...output ommitted...
selector:
matchLabels:
app: db-pod
...output ommitted...
DNS Kubernetes pour la découverte de services

Kubernetes utilise un serveur DNS (Domain Name System) interne déployé par l’opérateur
DNS. L’opérateur DNS crée un nom DNS de cluster par défaut et attribue des noms DNS aux
services que vous définissez. L’opérateur DNS implémente l’API DNS à partir du groupe d’API
operator.openshift.io. L’opérateur déploie CoreDNS, crée une ressource de service
pour CoreDNS, puis configure le kubelet pour indiquer aux pods d’utiliser l’adresse IP du
service CoreDNS pour la résolution de noms. Lorsqu’un service n’a pas d’adresse IP de cluster,
l’opérateur DNS lui attribue un enregistrement DNS qui est résolu sur l’ensemble d’adresses IP des
pods qui sous-tendent le service.
Le serveur DNS découvre un service à partir d’un pod en utilisant le serveur DNS interne, qui est
visible uniquement par les pods. Chaque service se voit attribuer dynamiquement un nom de
domaine complètement qualifié qui utilise le format suivant :
SVC-NAME.PROJECT-NAME.svc.CLUSTER-DOMAIN
Lorsqu’un pod est créé, Kubernetes fournit au conteneur un fichier /etc/resolv.conf avec un
contenu semblable aux éléments suivants :
[user@host ~]$ cat /etc/resolv.conf

search deploy-services.svc.cluster.local svc.cluster.local ...
nameserver 172.30.0.10
options ndots:5
Dans cet exemple, deploy-services est le nom de projet du pod et cluster.local est le
domaine du cluster.
La directive nameserver fournit l’adresse IP du serveur DNS Kubernetes interne. La directive

options ndots spécifie le nombre de points qui doivent apparaître dans un nom pour pouvoir
bénéficier d’une requête absolue initiale. D’autres valeurs de nom d’hôte sont déduites en ajoutant
des valeurs de la directive Search au nom qui est envoyé au serveur DNS.
DO180-OCP4.14-fr-2-20240530 261
Dans la directive search de cet exemple, l’entrée svc.cluster.local permet à n’importe quel
pod de communiquer avec un autre pod du même cluster en utilisant le nom du service et le nom
du projet :
SVC-NAME.PROJECT-NAME
La première entrée de la directive search permet à un pod d’utiliser le nom du service pour
spécifier un autre pod du même projet. Dans RHOCP, un projet est également l’espace de noms
du pod. Le nom du service, à lui seul, suffit pour les pods du même projet RHOCP :
SVC-NAME
Pilotes réseau Kubernetes

Les plug-ins CNI (Container Network Interface) fournissent une interface commune entre le
fournisseur réseau et l’exécution du conteneur. L’interface CNI définit les spécifications pour les
plug-ins qui configurent des interfaces réseau à l’intérieur de conteneurs. Les plug-ins écrits dans
la spécification permettent à différents fournisseurs réseau de contrôler le réseau de clusters
RHOCP.
Red Hat fournit les plug-ins CNI suivants pour un cluster RHOCP :
• OVN-Kubernetes : plug-in par défaut pour les premières installations de RHOCP, à partir de
RHOCP 4.10.
• OpenShift SDN : plug-in plus ancien de RHOCP 3.x ; il est incompatible avec certaines fonctions
ultérieures de RHOCP 4.x.
• Kuryr : plug-in destiné à l’intégration et aux performances sur les déploiements OpenStack.
Les plug-ins CNI certifiés d’autres fournisseurs sont également compatibles avec un cluster
RHOCP.
Le SDN utilise des plug-ins CNI pour créer des espaces de noms Linux afin de partitionner
l’utilisation des ressources et des processus sur les hôtes physiques et virtuels. Cette
implémentation permet aux conteneurs à l’intérieur des pods de partager des ressources réseau,
telles que des périphériques, des piles IP, des règles de pare-feu et des tables de routage. Le SDN
alloue une adresse IP routable unique à chaque pod, de sorte que vous puissiez accéder au pod à
partir de n’importe quel autre service du même réseau.
Dans OpenShift 4.14, OVN-Kubernetes est le fournisseur réseau par défaut.
OVN-Kubernetes utilise Open Virtual Network (OVN) pour gérer le réseau de clusters. Un cluster
qui utilise le plug-in OVN-Kubernetes exécute également Open vSwitch (OVS) sur chaque nœud.
OVN configure OVS sur chaque nœud afin d’implémenter la configuration réseau déclarée.
Opérateur de réseau de clusters OpenShift

RHOCP fournit un opérateur de réseau de clusters (CNO, Cluster Network Operator) qui configure
la mise en réseau de clusters OpenShift. CNO est un opérateur de cluster OpenShift qui charge
et configure les plug-ins CNI (Container Network Interface). En tant qu’administrateur de cluster,
exécutez la commande suivante pour observer l’état de l’opérateur CNO :
262 DO180-OCP4.14-fr-2-20240530
[user@host ~]$ oc get -n openshift-network-operator deployment/network-operator

network-operator 1/1 1 1 41d
Un administrateur configure l’opérateur CNO au moment de l’installation. Pour afficher la

configuration, utilisez la commande suivante :
[user@host ~]$ oc describe network.config/cluster

Name: cluster
Spec:
Cluster Network:
Cidr: 10.8.0.0/14
Host Prefix: 23
External IP:
Policy:
Network Type: OVNKubernetes
Service Network:
172.30.0.0/16
Le CIDR du réseau de clusters définit la plage d’adresses IP pour tous les pods du cluster.
Le CIDR du réseau de services définit la plage d’adresses IP pour tous les services du cluster.
Références
Pour plus d’informations, reportez-vous au chapitre About Kubernetes Pods and
Services (À propos des pods et des services Kubernetes) de la documentation
Networking (Mise en réseau) de Red Hat OpenShift Container Platform 4.14,
disponible à l’adresse
openshift_container_platform/4.14/html-single/architecture/index#building-
simple-container
Pour plus d’informations, reportez-vous au chapitre Cluster Network Operator

in OpenShift Container Platform de la documentation Networking de Red Hat
openshift_container_platform/4.14/html-single/networking/index#cluster-network-
operator
Pour plus d’informations, reportez-vous au chapitre About the OVN-Kubernetes

Network Plug-in (À propos du plug-in réseau OVN-Kubernetes) de la
documentation Networking (Mise en réseau) de Red Hat OpenShift Container
openshift_container_platform/4.14/html-single/networking/index#about-ovn-
kubernetes
Réseau de clusters
https://kubernetes.io/docs/concepts/cluster-administration/networking/
DO180-OCP4.14-fr-2-20240530 263
Exercice guidé
Réseaux de pods et de services

Kubernetes
Déployez un serveur de base de données et accédez-y par le biais d’un service Kubernetes.
Résultats
Vous devriez être en mesure de déployer un serveur de base de données et d’y accéder, de
manière indirecte, via un service Kubernetes, ainsi que directement de pod à pod pour la
résolution des problèmes.
Avant De Commencer
Cette commande permet de s’assurer que toutes les ressources sont disponibles pour
cet exercice. Elle crée également le projet deploy-services et le fichier /home/student/
DO180/labs/deploy-services/resources.txt. Le fichier resources.txt contient
certaines commandes que vous utiliserez au cours de l’exercice. Vous pouvez utiliser ce
fichier pour copier et coller ces commandes.
[student@workstation ~]$ lab start deploy-services
Note
Vous pouvez ignorer les avertissements de sécurité des pods pour les
exercices de ce cours. OpenShift utilise le contrôleur Contraintes du contexte
de sécurité pour fournir des valeurs par défaut sécurisées pour la sécurité des
pods.
Instructions
passe developer. Utilisez le projet deploy-services.

Login successful.
1.2. Définissez le projet deploy-services comme projet actif.
264 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ oc project deploy-services

2. Utilisez l’image de conteneur registry.ocp4.example.com:8443/rhel8/mysql-80

pour créer un déploiement MySQL nommé db-pod. Ajoutez les variables d’environnement
manquantes pour que le pod s’exécute.
2.1. Créez le déploiement db-pod.
[student@workstation ~]$ oc create deployment db-pod --port 3306 \

--image registry.ocp4.example.com:8443/rhel8/mysql-80
deployment.apps/db-pod created
2.2. Ajoutez les variables d’environnement.
[student@workstation ~]$ oc set env deployment/db-pod \

MYSQL_USER=user1 \
MYSQL_PASSWORD=mypa55w0rd \
MYSQL_DATABASE=items
deployment.apps/db-pod updated
2.3. Vérifiez que le pod est en cours d’exécution.

db-pod-6ccc485cfc-vrc4r 1/1 Running 0 2m30s
Le nom de votre pod peut être différent de celui de la sortie précédente.
3. Exposez le déploiement db-pod pour créer un service ClusterIP.
3.1. Affichez le déploiement du pod.
[student@workstation ~]$ oc get deployment

db-pod 1/1 1 1 3m36s
3.2. Exposez le déploiement db-pod pour créer un service.
[student@workstation ~]$ oc expose deployment/db-pod

service/db-pod exposed
4. Validez le service. Vérifiez que le sélecteur de service correspond bien à l’étiquette du pod.
Vérifiez ensuite que le point d’accès du service db-pod correspond à l’adresse IP du pod.
4.1. Identifiez le sélecteur du service db-pod. Utilisez la commande oc get service

command avec l’option -o wide pour récupérer le sélecteur utilisé par le service.
DO180-OCP4.14-fr-2-20240530 265
[student@workstation ~]$ oc get service db-pod -o wide

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
db-pod ClusterIP 172.30.108.92 <none> 3306/TCP 108s app=db-pod
Le sélecteur affiche une paire clé-valeur app=db-pod.
4.2. Saisissez le nom du pod dans une variable.
[student@workstation ~]$ PODNAME=$(oc get pods \

-o jsonpath='{.items[0].metadata.name}')
4.3. Interrogez l’étiquette sur le pod.
[student@workstation ~]$ oc get pod $PODNAME --show-labels

db-pod-6ccc485cfc-vrc4r 1/1 Running 0 6m50s app=db-pod ...
Notez que la liste des étiquettes inclut la paire clé-valeur app=db-pod, qui est le
sélecteur du service db-pod.
4.4. Récupérez les points d’accès pour le service db-pod.
[student@workstation ~]$ oc get endpoints

NAME ENDPOINTS AGE
db-pod 10.8.0.85:3306 4m38s
Les valeurs de vos points d’accès peuvent être différentes de celles de la sortie
précédente.
4.5. Vérifiez que le point d’accès du service correspond à l’adresse IP db-pod . Utilisez la
commande oc get pods avec l’option -o wide pour afficher l’adresse IP du pod.

db-pod-6ccc485cfc-vrc4r 1/1 Running 0 54m 10.8.0.85 ...
Le point d’accès du service est résolu sur l’adresse IP attribuée au pod.
5. Supprimez, puis recréez le déploiement db-pod. Vérifiez que le point d’accès du service
db-pod est résolu automatiquement sur l’adresse IP du nouveau pod.
5.1. Supprimez le déploiement db-pod.
[student@workstation ~]$ oc delete deployment.apps/db-pod

deployment.apps "db-pod" deleted
5.2. Vérifiez que le service existe toujours sans le déploiement.
[student@workstation ~]$ oc get service

db-pod ClusterIP 172.30.108.92 <none> 3306/TCP 9m53s
266 DO180-OCP4.14-fr-2-20240530
5.3. La liste des points d’accès du service est désormais vide.

NAME ENDPOINTS AGE
db-pod <none> 12m
5.4. Recréez le déploiement db-pod.


MYSQL_USER=user1 \
5.6. Vérifiez que le pod qui vient d’être créé dispose du sélecteur app=db-pod.
[student@workstation ~]$ oc get pods --selector app=db-pod -o wide

db-pod-6ccc485cfc-l2x 1/1 Running 0 32s 10.8.0.85 ...
Notez le changement dans le nom du pod. Il se peut que l’adresse IP du pod soit
également modifiée. Le nom et l’adresse IP de votre pod peuvent être différents de
ceux de la sortie précédente.
5.7. Vérifiez que les points d’accès du service db-pod incluent le pod qui vient d’être créé.

NAME ENDPOINTS AGE
db-pod 10.8.0.85:3306 16m
6. Créez un pod pour identifier les affectations de noms DNS disponibles pour le service.
6.1. Créez un pod nommé shell à utiliser dans le cadre de la résolution

des problèmes. Utilisez la commande oc run et l’image de conteneur
registry.ocp4.example.com:8443/openshift4/network-tools-rhel8.
[student@workstation ~]$ oc run shell -it \

--image registry.ocp4.example.com:8443/openshift4/network-tools-rhel8
bash-4.4$
6.2. À partir de l’invite à l’intérieur du pod shell, affichez le fichier /etc/resolv.conf

pour identifier le nom de domaine du cluster.
DO180-OCP4.14-fr-2-20240530 267
bash-4.4$ cat /etc/resolv.conf

search deploy-services.svc.cluster.local svc.cluster.local ...
nameserver 172.30.0.10
options ndots:5
Le conteneur utilise les valeurs de la directive search comme valeurs de suffixe lors
des recherches DNS. Le conteneur ajoute ces valeurs à une requête DNS, dans l’ordre
indiqué, pour résoudre la recherche. Le nom de domaine du cluster correspond aux
derniers composants de ces valeurs qui commencent après svc.
6.3. Utilisez les commandes nc et echo pour tester les noms DNS disponibles pour le
service.
nc -z <service>_<server>_ <port>
La version longue du nom DNS est requise lors de l’accès au service à partir d’un
autre projet. Lorsque le pod se trouve dans le même projet, vous pouvez utiliser une
version plus courte du nom DNS.
bash-4.4$ nc -z db-pod.deploy-services 3306 && \

echo "Connection success to db-pod.deploy-services:3306" || \
echo "Connection failed"
Connection success to db-pod.deploy-services:3306
6.4. Quittez la session interactive.
bash-4.4$ exit
Session ended, resume using 'oc attach shell -c shell -i -t' command when the pod
is running
6.5. Supprimez le pod du shell.
[student@workstation ~]$ oc delete pod shell

pod "shell" deleted
7. Utilisez un nouveau projet pour tester les communications des pods entre les espaces de
noms.
7.1. Créez un deuxième espace de noms avec la commande oc new-project.
[student@workstation ~]$ oc new-project deploy-services-2

Now using project "deploy-services-2" on server "https://
7.2. Exécutez les commandes nc et echo à partir d’un pod pour tester l’accès du
nom DNS à un autre espace de noms.
268 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ oc run shell -it --rm \

--image registry.ocp4.example.com:8443/openshift4/network-tools-rhel8 \
--restart Never -- nc -z db-pod.deploy-services.svc.cluster.local 3306 && \
echo "Connection success to db-pod.deploy-services.svc.cluster.local:3306" \
|| echo "Connection failed"
pod "shell" deleted
Connection success to db-pod.deploy-services.svc.cluster.local:3306
7.3. Revenez au projet deploy-services.
[student@workstation ~]$ oc project deploy-services

Now using project "deploy-services" on server "https://api.ocp4.example.com:6443".
8. Utilisez une tâche Kubernetes pour ajouter des données d’initialisation à la base de
données.
8.1. Créez un pod nommé mysql-init qui utilise l’image de conteneur

registry.ocp4.example.com:8443/redhattraining/do180-dbinit:v1.
Cette image utilise l’image de conteneur mysql-80 comme image de base et
contient un script qui ajoute quelques enregistrements initiaux à la base de données.
[student@workstation ~]$ oc create job mysql-init \

--image registry.ocp4.example.com:8443/redhattraining/do180-dbinit:v1 \
-- /bin/bash -c "mysql -uuser1 -pmypa55w0rd --protocol tcp \
-h db-pod -P3306 items </tmp/db-init.sql"
job.batch/mysql-init created
L’option -h de la commande mysql lui indique de communiquer avec le nom DNS

court du service db-pod. Le nom court db-pod peut être utilisé ici, car le pod de la
tâche est créé dans le même espace de noms que le service.
Le double trait -- avant /bin/bash sépare les arguments de la commande oc de
la commande dans le pod. L’option -c de /bin/bash indique à l’interpréteur de
commande du conteneur d’exécuter la chaîne de commandes. Le fichier /tmp/db-
init.sql est redirigé en tant qu’entrée pour la commande. Le fichier db-init.sql
est inclus dans l’image et contient le script suivant.
DROP TABLE IF EXISTS Ìtem`;

CREATE TABLE Ìtem` (ìd` BIGINT not null auto_increment primary key,
`description` VARCHAR(100), `done` BIT);
INSERT INTO Ìtem` (ìd`,`description`,`done`) VALUES (1,'Pick up newspaper', 0);
INSERT INTO Ìtem` (ìd`,`description`,`done`) VALUES (2,'Buy groceries', 1);
8.2. Vérifiez l’état de la tâche mysql-init. Attendez que la tâche soit terminée.
[student@workstation ~]$ oc get job

mysql-init 1/1 22m
8.3. Récupérez l’état du pod de la tâche mysql-init pour vérifier qu’il s’agit bien de
Completed.
DO180-OCP4.14-fr-2-20240530 269

db-pod-6ccc485cfc-2lklx 1/1 Running 0 4h24m
mysql-init-ln9cg 0/1 Completed 0 23m
8.4. Supprimez la tâche mysql-init, car elle n’est plus nécessaire.
[student@workstation ~]$ oc delete job mysql-init

job.batch "mysql-init" deleted
8.5. Vérifiez que le pod mysql-init correspondant est également supprimé.

db-pod-6ccc485cfc-2lklx 1/1 Running 0 4h2
9. Créez un pod query-db à l’aide de commande oc run et de l’image de conteneur

registry.ocp4.example.com:8443/redhattraining/do180-dbinit:v1. Utilisez
le pod pour exécuter une requête sur le service de base de données.
9.1. Créez le pod query-db. Configurez le pod pour qu’il utilise le client MySQL afin
d’exécuter une requête sur le service db-pod. Vous pouvez utiliser le nom court du
service db-pod, qui fournit une référence stable.
[student@workstation ~]$ oc run query-db -it --rm \

--image registry.ocp4.example.com:8443/redhattraining/do180-dbinit:v1 \
--restart Never \
-- mysql -uuser1 -pmypa55w0rd --protocol tcp \
-h db-pod -P3306 items -e 'select * from Item;'
mysql: [Warning] Using a password on the command line interface can be insecure.
+----+-------------------+------------+
| id | description | done |
+----+-------------------+------------+
| 1 | Pick up newspaper | 0x00 |
| 2 | Buy groceries | 0x01 |
+----+-------------------+------------+
pod "query-db" deleted
10. Il peut être nécessaire d’utiliser des communications de pod à pod pour la résolution des
problèmes. Utilisez la commande oc run pour créer un pod qui exécute un test réseau sur
l’adresse IP du pod de base de données.
10.1. Vérifiez l’adresse IP du pod de base de données MySQL. L’adresse IP de votre pod
peut être différente de celle de la sortie.

db-pod-6ccc485cfc-2lklx 1/1 Running 0 4h5 10.8.0.69 ...
10.2. Saisissez l’adresse IP dans une variable d’environnement.
270 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ POD_IP=$(oc get pod -l app=db-pod \

-o jsonpath='{.items[0].status.podIP}')
10.3. Créez un pod de test nommé shell avec la commande oc run. Exécutez la
commande nc pour effectuer un test sur la variable d’environnement $POD_IP et sur
le port 3306 de la base de données.
[student@workstation ~]$ oc run shell --env POD_IP=$POD_IP -it --rm \

--image registry.ocp4.example.com:8443/openshift4/network-tools-rhel8 \
--restart Never \
-- nc -z $POD_IP 3306 && echo "Connection success to $POD_IP:3306" \
|| echo "Connection failed"
pod "shell" deleted
Connection success to 10.8.0.69:3306
Fin
[student@workstation ~]$ lab finish deploy-services
DO180-OCP4.14-fr-2-20240530 271
Mise à l’échelle et exposition

d’applications pour un accès externe
Résultats
• Exposer des applications aux clients situés à l’extérieur du cluster à l’aide d’une entrée
Adresses IP des pods et des services

La plupart des applications réelles ne s’exécutent pas comme un pod unique. Étant donné que
les applications doivent effectuer une mise à l’échelle horizontale, de nombreux pods exécutent
les mêmes conteneurs à partir de la même définition de ressources de pod pour répondre à la
demande croissante des utilisateurs. Un service définit une combinaison adresse IP/port unique, et
fournit une adresse IP unique à un pool de pods, ainsi qu’une demande de client d’équilibrage de
charge entre les pods membres.
Par défaut, les services connectent les clients aux pods à tour de rôle, et chaque service se voit
attribuer une adresse IP unique à laquelle les clients peuvent se connecter. Cette adresse IP
provient d’un autre réseau virtuel OpenShift interne qui, bien que distinct du réseau interne des
pods, est visible uniquement par ceux-ci. Chaque pod correspondant au sélecteur est ajouté à la
ressource de service comme point d’accès.
Les conteneurs qui se trouvent à l’intérieur des pods Kubernetes ne doivent pas se connecter
directement à l’adresse IP dynamique de leurs homologues. Les services résolvent ce problème
en liant des adresses IP plus stables à partir du SDN vers les pods. Si les pods sont redémarrés,
répliqués ou replanifiés sur des nœuds différents, les services sont mis à jour pour offrir une
évolutivité et une tolérance aux pannes.
Types de services
Vous pouvez choisir entre plusieurs types de services en fonction des besoins de votre application,
de l’infrastructure du cluster et des exigences en termes de sécurité.
ClusterIP
Il s’agit du type par défaut, sauf si vous spécifiez explicitement un type pour un service. Le
type ClusterIP expose le service sur une adresse IP interne au cluster. Si vous choisissez cette
valeur, le service sera accessible uniquement à partir du cluster.
Le type de service ClusterIP est utilisé pour le routage de pod à pod au sein du cluster
RHOCP. Il permet aux pods de communiquer entre eux et d’accéder les uns aux autres. Les
adresses IP des services ClusterIP sont attribuées à partir d’un réseau de services dédié,
accessible uniquement depuis l’intérieur du cluster. La plupart des applications doivent utiliser
ce type de service, dont Kubernetes automatise la gestion.
Équilibreur de charge
Cette ressource indique à RHOCP d’activer un équilibreur de charge dans un environnement
cloud. Un équilibreur de charge indique à Kubernetes d’interagir avec le fournisseur de cloud
dans lequel s’exécute le cluster afin de déployer un module de ce type. L’équilibreur de charge
fournit ensuite à l’application une adresse IP accessible depuis l’extérieur.
Prenez toutes les précautions nécessaires avant de déployer ce type de service. Les
équilibreurs de charge sont généralement trop onéreux pour que vous en attribuiez un à
272 DO180-OCP4.14-fr-2-20240530
chaque application d’un cluster. De plus, les applications qui utilisent ce type de service
deviennent accessibles à partir de réseaux situés à l’extérieur du cluster. Une configuration de
sécurité supplémentaire est requise pour empêcher tout accès indésirable.
NodePort
Avec cette méthode, Kubernetes expose un service sur un port sur l’adresse IP du nœud. Le
port est exposé sur tous les nœuds du cluster, et chaque nœud redirige le trafic vers les points
d’accès (pods) du service.
Un service NodePort nécessite d’autoriser des connexions réseau directes à un nœud de

cluster, ce qui présente un risque pour la sécurité.
ExternalName
Ce service indique à Kubernetes que le nom DNS dans le champ externalName est
l’emplacement de la ressource qui fournit le service. Lorsqu’une demande DNS est effectuée
sur le serveur DNS Kubernetes, elle renvoie l’externalName dans un enregistrement CNAME
(Canonical Name) et indique au client de rechercher le nom renvoyé pour obtenir l’adresse IP.
Utilisation de routes pour la connectivité externe

RHOCP fournit des ressources pour exposer vos applications à des réseaux à l’extérieur du cluster.
Vous pouvez exposer le trafic HTTP et HTTPS, les applications TCP, mais également le trafic non
TCP. Cependant, seules les applications basées sur HTTP et TLS doivent être exposées à un accès
externe. Les applications qui utilisent d’autres protocoles, comme les bases de données, ne sont
généralement pas exposées à un accès externe (depuis l’extérieur d’un cluster). Les routes et
l’entrée constituent les ressources principales pour la gestion du trafic entrant.
RHOCP fournit la ressource route pour exposer vos applications à des réseaux externes. Les
routes vous permettent d’accéder à votre application à l’aide d’un nom d’hôte unique accessible
au public. Les routes s’appuient sur un contrôleur d’entrée Kubernetes pour rediriger le trafic
de l’adresse IP publique vers les pods. Par défaut, Kubernetes fournit un contrôleur d’entrée à
partir de la version 1.24. Pour les clusters RHOCP, le contrôleur d’entrée est fourni par l’opérateur
d’entrée OpenShift. Les clusters RHOCP peuvent également utiliser divers contrôleurs d’entrée
tiers qui peuvent être déployés parallèlement au contrôleur d’entrée OpenShift.
Les routes transmettent le trafic entrant aux services dans le cluster. Elles ont été créées avant les
objets d’entrée Kubernetes et fournissent davantage de fonctions. Elles fournissent des fonctions
avancées qui peuvent ne pas être prises en charge par les contrôleurs d’entrée Kubernetes via
une interface standard, telle que le rechiffrement TLS, le relais TLS et le trafic partagé pour les
déploiements bleu-vert.
Pour créer une route (sécurisée ou non) avec l’interface de ligne de commande oc, utilisez la
commande oc expose service service-name. Incluez l’option --hostname pour fournir un
nom d’hôte personnalisé pour la route.
[user@host ~]$ oc expose service api-frontend \

--hostname api.apps.acme.com
Si vous omettez le nom d’hôte, RHOCP en génère automatiquement un avec la structure

suivante : <route-name>-<project-name>.<default-domain>. Par exemple, si vous créez
une route frontend dans un projet api, dans un cluster qui utilise apps.example.com comme
domaine générique, le nom d’hôte de la route sera le suivant :
frontend-api.apps.example.com
DO180-OCP4.14-fr-2-20240530 273
Important
Le serveur DNS qui héberge le domaine générique ignore tous les noms d’hôte de la
route ; il résout uniquement les noms sur les adresses IP configurées. Seul le routeur
RHOCP connaît les noms d’hôte de la route et traite chacun d’eux comme un hôte
virtuel HTTP.
Les noms d’hôtes de domaines génériques non valides, ou les noms d’hôtes qui ne
correspondent à aucune route, sont bloqués par le routeur RHOCP et génèrent une
erreur HTTP 503.
Lors de la création d’une route, veuillez prendre en compte les paramètres suivants :
• Le nom d’un service. La route utilise le service pour déterminer les pods vers lesquels rediriger
le trafic.
• Un nom d’hôte pour la route. Une route est toujours un sous-domaine de votre domaine
générique de cluster. Par exemple, si vous utilisez le domaine générique apps.dev-
cluster.acme.com et que vous devez exposer un service frontend via une route, le nom de
la route sera :
frontend.apps.dev-cluster.acme.com.
RHOCP peut également générer automatiquement un nom d’hôte pour la route.
• Un chemin facultatif, pour les routes basées sur des chemins.
• Un port cible sur lequel l’application écoute. Le port cible correspond au port que vous
définissez dans la clé targetPort du service.
• Une stratégie de chiffrement, selon que vous avez besoin d’une route sécurisée ou
non sécurisée.
La liste suivante présente une définition minimale pour un itinéraire :
kind: Route
apiVersion: route.openshift.io/v1
metadata:
name: a-simple-route
labels:
app: API
name: api-frontend
spec:
host: api.apps.acme.com
to:
kind: Service
name: api-frontend
port: 8080
targetPort: 8443
Nom de la route. Ce nom doit être unique.
Ensemble de libellés que vous pouvez utiliser comme sélecteurs.
274 DO180-OCP4.14-fr-2-20240530
Nom d’hôte de la route. Ce nom d’hôte doit être un sous-domaine de votre domaine
générique, étant donné que RHOCP achemine le domaine générique vers les routeurs.
Service vers lequel rediriger le trafic. Bien que vous utilisiez un nom de service, la route utilise
uniquement ces informations pour déterminer la liste des pods qui reçoivent le trafic.
Mappage de ports d’un routeur vers un point d’accès dans les points d’accès de service. Port
cible sur les pods sélectionnés par le service vers lequel pointe cette route.
Note
Certains composants de l’écosystème sont intégrés dans des ressources
d’entrée, mais pas dans des ressources de la route. Dans ce cas, RHOCP crée
automatiquement des objets de route gérés lorsqu’un objet d’entrée est créé.
Ces objets de route sont supprimés lors de la suppression des objets d’entrée
correspondants.
Vous pouvez supprimer une route à l’aide de la commande oc delete route route-name.
[user@host ~]$ oc delete route myapp-route
Vous pouvez également exposer un service à partir de la console Web en cliquant sur le menu
Networking > Routes. Cliquez sur Create Route et personnalisez le nom, le nom d’hôte, le chemin
d’accès et le service vers lequel effectuer le routage à l’aide de la vue Form ou du manifeste
YAML.
Utilisation d’objets d’entrée pour une connectivité

externe
Une entrée est une ressource Kubernetes qui fournit certaines fonctions identiques à celles des
routes (qui constituent une ressource RHOCP). Les objets d’entrée acceptent les demandes
externes et les transfèrent sur la base de la route. Vous ne pouvez activer que certains
types de trafic : HTTP, HTTPS, SNI (Identification de nom de serveur) et TLS avec SNI. Les
ressources d’entrée Kubernetes standard sont généralement peu nombreuses. De nombreuses
fonctionnalités courantes sur lesquelles reposent les applications, telles que la terminaison TLS, la
redirection de chemin et les sessions permanentes, dépendent du contrôleur d’entrée. Kubernetes
ne définit pas la syntaxe de configuration. Dans RHOCP, les routes sont générées pour répondre
aux conditions spécifiées par l’objet d’entrée.
DO180-OCP4.14-fr-2-20240530 275
Note
La ressource d’entrée est couramment utilisée pour Kubernetes. Cependant,
la ressource route est la méthode privilégiée pour la connectivité externe dans
RHOCP.
Pour créer un objet d’entrée, utilisez la commande oc create ingress ingress-name --

rule=URL_route=service-name:port-number. Utilisez l’option --rule pour fournir une
règle personnalisée au format host/path=service:port[,tls=secretname]. Si l’option
TLS est omise, une route non sécurisée est créée.
[user@host ~]$ oc create ingress ingr-sakila \

--rule="ingr-sakila.apps.ocp4.example.com/*=sakila-service:8080"
La liste suivante présente une définition minimale pour un objet d’entrée :
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: frontend
spec:
rules:
- host: "www.example.com
http:
paths:
- backend:
service:
name: frontend
port:
number: 80
pathType: Prefix
path: /
tls:
- hosts:
- www.example.com
secretName: example-com-tls-certificate
Nom de l’objet d’entrée. Ce nom doit être unique.
Règle HTTP ou HTTPS de l’objet d’entrée.
Hôte de l’objet d’entrée. Applique la règle HTTP au trafic HTTP entrant de l’hôte spécifié.
Backend vers lequel rediriger le trafic. Définit le nom du service, le numéro de port et les
noms des ports pour l’objet d’entrée. Pour se connecter au backend, les demandes entrantes
doivent correspondre à l’hôte et au chemin de la règle.
Configuration de TLS pour l’objet d’entrée ; elle est requise pour les chemins sécurisés.
L’hôte de l’objet TLS doit correspondre à celui de l’objet « rules ».
Vous pouvez supprimer un objet d’entrée à l’aide de la commande oc delete ingress

ingress-name.
276 DO180-OCP4.14-fr-2-20240530
[user@host ~]$ oc delete ingress example-ingress
Sessions permanentes
Les sessions permanentes permettent un trafic d’applications avec état en veillant à ce que toutes
les demandes atteignent le même point d’accès. RHOCP utilise des cookies pour configurer la
persistance de session pour les ressources d’entrée et de route. Le contrôleur d’entrée sélectionne
un point d’accès pour gérer les demandes utilisateur et crée un cookie pour la session. Le cookie
est renvoyé en réponse à la demande, et l’utilisateur le renvoie avec la demande suivante dans
la session. Le cookie indique au contrôleur d’entrée le point d’accès qui gère la session, pour
s’assurer que les demandes des clients l’utilisent afin d’être acheminées vers le même pod.
RHOCP génère automatiquement le nom du cookie pour les ressources d’entrée et de route. Vous
pouvez remplacer le nom du cookie par défaut en utilisant la commande annotate avec kubectl
ou oc. Avec cette annotation, l’application qui reçoit le trafic de routage connaît le nom du cookie.
L’exemple suivant configure un cookie pour un objet d’entrée :
[user@host ~]$ oc annotate ingress ingr-example \

ingress.kubernetes.io/affinity=cookie
L’exemple suivant configure un cookie intitulé myapp pour un objet de route :
[user@host ~]$ oc annotate route route-example \

router.openshift.io/cookie_name=myapp
Après avoir annoté la route, capturez son nom d’hôte dans une variable :
[user@host ~]$ ROUTE_NAME=$(oc get route <route_name> \

-o jsonpath='{.spec.host}')
Ensuite, utilisez la commande curl pour enregistrer le cookie et accéder à la route :
[user@host ~]$ curl $ROUTE_NAME -k -c /tmp/cookie_jar
Le cookie est renvoyé en réponse à la demande et enregistré dans le répertoire /tmp/

cookie_jar. Utilisez la commande curl et le cookie qui a été enregistré à partir de la
commande précédente pour vous connecter à la route :
[user@host ~]$ curl $ROUTE_NAME -k -b /tmp/cookie_jar
En utilisant le cookie enregistré, la demande est envoyée au même pod que la demande
précédente.
Mise à l’échelle et équilibrage de la charge des

applications
Les développeurs et les administrateurs peuvent choisir de mettre à l’échelle manuellement le
nombre de pods répliqués d’un déploiement. Des pods supplémentaires peuvent être nécessaires
pour une augmentation anticipée du trafic, ou le nombre de pods peut être réduit pour récupérer
des ressources que le cluster peut utiliser ailleurs.
DO180-OCP4.14-fr-2-20240530 277
Vous pouvez modifier manuellement le nombre de réplicas d’une ressource de déploiement à

l’aide de la commande oc scale.
[user@host ~]$ oc scale --replicas 5 deployment/scale
La ressource de déploiement propage la modification au jeu de réplicas. Le jeu de réplicas réagit

à la modification en créant des pods (réplicas) ou en supprimant les pods existants, selon que le
nouveau nombre de réplicas prévu est inférieur ou supérieur au nombre existant.
Bien que vous puissiez manipuler directement une ressource de jeu de réplicas, il est recommandé
de manipuler plutôt la ressource de déploiement. Un nouveau déploiement crée soit un jeu de
réplicas soit un contrôleur de réplication, et les modifications apportées directement à un jeu de
réplicas ou à un contrôleur de réplication antérieur sont ignorées.
Équilibrage de la charge des pods

Un service Kubernetes fait office d’équilibreur de charge interne. Les services standard agissent
comme un équilibreur de charge ou un proxy et donnent accès à l’objet de charge de travail en
utilisant le nom de service. Un service identifie un ensemble de pods répliqués pour transférer les
connexions qu’il reçoit.
Un routeur utilise le sélecteur de service pour trouver le service et les points d’accès, ou pods, qui
prennent en charge le service. Lorsqu’un routeur et un service assurent l’équilibrage de la charge,
RHOCP utilise le routeur pour équilibrer la charge du trafic vers les pods. Un routeur détecte
les modifications pertinentes dans les adresses IP de ses services et adapte sa configuration en
conséquence. Les routeurs personnalisés peuvent ainsi communiquer des modifications d’objets
API à une solution de routage externe.
Les routeurs RHOCP mappent les noms d’hôtes externes et équilibrent la charge des points
d’accès de service sur des protocoles qui leur transmettent directement des informations
distinctives. Le nom d’hôte doit exister dans le protocole pour que le routeur puisse déterminer sa
destination.
Références
Pour plus d’informations, reportez-vous à la section About Networking (À propos
de la mise en réseau) de la documentation Networking (Mise en réseau) de Red Hat
openshift_container_platform/4.14/html-single/networking/index#about-
networking
278 DO180-OCP4.14-fr-2-20240530
Exercice guidé
Mise à l’échelle et exposition

d’applications pour un accès externe
Déployez un serveur Web et accédez-y via une entrée Kubernetes ; déployez un autre
serveur Web et accédez-y via une route OpenShift.
Résultats
Au cours de cet exercice, vous allez déployer deux applications Web pour y accéder via un
objet d’entrée et une route, et les mettre à l’échelle pour vérifier l’équilibrage de la charge
entre les pods.
• Déployez deux applications Web.
• Créez une route et un objet d’entrée pour accéder aux applications Web.
• Activez les sessions permanentes pour les applications Web.
• Mettez à l’échelle les applications Web pour équilibrer la charge du service.
Avant De Commencer
pour préparer votre système pour cet exercice. Cette commande garantit que le cluster est
accessible.
[student@workstation ~]$ lab start deploy-routes
Instructions
1. Créez deux déploiements d’applications Web, nommés satir-app et sakila-app.
Utilisez l’image de conteneur registry.ocp4.example.com:8443/httpd-app:v1
pour les deux déploiements.
1.1. Connectez-vous au cluster OpenShift en tant qu’utilisateur developer avec le mot

de passe developer.

Login successful
1.2. Passez au projet web-applications.
[student@workstation ~]$ oc project web-applications

Now using project "web-applications" on server "https://
DO180-OCP4.14-fr-2-20240530 279
1.3. Créez le déploiement d’application Web satir-app à l’aide de l’image de conteneur

registry.ocp4.example.com:8443/redhattraining/do180-httpd-
app:v1. Ignorez le message d’avertissement.
[student@workstation ~]$ oc create deployment satir-app \

--image registry.ocp4.example.com:8443/redhattraining/do180-httpd-app:v1
deployment.apps/satir-app created
1.4. Après quelques instants, vérifiez que le déploiement a réussi.

NAME READY STATUS RESTARTS ...
satir-app-787b7d7858-5dfsh 1/1 Running 0 ...
[student@workstation ~]$ oc status

deployment/satir-app deploys registry.ocp4.example.com:8443/redhattraining/do180-
httpd-app:v1
deployment #1 running for 20 seconds - 1 pod
1.5. Créez le déploiement d’application Web sakila-app à l’aide de l’image

registry.ocp4.example.com:8443/redhattraining/do180-httpd-
app:v1. Ignorez le message d’avertissement.
[student@workstation ~]$ oc create deployment sakila-app \

--image registry.ocp4.example.com:8443/redhattraining/do180-httpd-app:v1
deployment.apps/sakila-app created
1.6. Patientez un peu, puis vérifiez que le déploiement a réussi.

sakila-app-6694...5kpd 1/1 Running 0 ...
satir-app-787b7...dfsh 1/1 Running 0 ...

deployment/satir-app deploys registry.ocp4.example.com:8443/redhattraining/do180-
httpd-app:v1
deployment #1 running for 5 minutes - 1 pod
deployment/sakila-app deploys registry.ocp4.example.com:8443/redhattraining/do180-

httpd-app:v1
2. Créez des services pour les déploiements d’applications Web. Utilisez ensuite les services
pour créer une route pour l’application satir-app et un objet d’entrée pour l’application
sakila-app.
280 DO180-OCP4.14-fr-2-20240530
2.1. Exposez le déploiement satir-app. Attribuez le nom satir-svc au service, et

spécifiez le port 8080 comme port et port cible.
[student@workstation ~]$ oc expose deployment satir-app --name satir-svc \

--port 8080 --target-port 8080
service/satir-svc exposed
2.2. Exposez le déploiement sakila-app pour créer le service sakila-svc.
[student@workstation ~]$ oc expose deployment sakila-app --name sakila-svc \

service/sakila-svc exposed
2.3. Vérifiez l’état des services.

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) ...
sakila-svc ClusterIP 172.30.230.41 <none> 8080/TCP ...
satir-svc ClusterIP 172.30.143.15 <none> 8080/TCP ...

NAME ENDPOINTS ...
sakila-svc 10.8.0.66:8080 ...
satir-svc 10.8.0.65:8080 ...

sakila-app-6694...5kpd 1/1 Running 0 92s 10.8.0.66 ...
satir-app-787b7...dfsh 1/1 Running 0 2m49s 10.8.0.65 ...
2.4. Créez une route nommée satir pour l’application Web satir-app en exposant le
service satir-svc.
[student@workstation ~]$ oc expose service satir-svc --name satir

route.route.openshift.io/satir exposed
[student@workstation ~]$ oc get routes

NAME HOST/PORT ... SERVICES PORT ...
satir satir-web-applications.apps.ocp4.example.com ... satir-svc 8080 ...
2.5. Créez un objet d’entrée nommé ingr-sakila pour le service sakila-svc.

Configurez l’option --rule avec les valeurs suivantes :
Champ Valeur
Hôte ingr-sakila.apps.ocp4.example.com
Service name sakila-svc
Port number 8080
DO180-OCP4.14-fr-2-20240530 281
[student@workstation ~]$ oc create ingress ingr-sakila \

--rule "ingr-sakila.apps.ocp4.example.com/*=sakila-svc:8080"
ingress.networking.k8s.io/ingr-sakila created
[student@workstation ~]$ oc get ingress

NAME ... HOSTS ADDRESS PORTS ...
ingr-sakila ... ingr-sakila.apps.ocp4.example.com router...com 80 ...
2.6. Vérifiez qu’il existe bien une route pour l’objet d’entrée ingr-sakila.

NAME HOST/PORT ... SERVICES PORT
ingr-sakila... ingr-sakila.apps.ocp4.example.com ... sakila-svc <all>
satir satir-web-applications.apps.ocp4.example.com ... satir-svc 8080
Aucun port spécifique n’est affecté aux routes créées par les objets d’entrée. En
revanche, une route créée par un service exposé se voit attribuer les mêmes ports
que le service.
2.7. Utilisez la commande curl pour accéder à l’objet d’entrée ingr-sakila et à la

route satir. La sortie indique le nom du pod qui traite la demande.
[student@workstation ~]$ curl ingr-sakila.apps.ocp4.example.com

Welcome to Red Hat Training, from sakila-app-66947cdd78-x5kpd
[student@workstation ~]$ curl satir-web-applications.apps.ocp4.example.com

Welcome to Red Hat Training, from satir-app-787b7d7858-bdfsh
3. Mettez à l’échelle les déploiements d’applications Web pour équilibrer la charge de leurs
services. Mettez à l’échelle l’application sakila-app sur deux réplicas et satir-app sur
trois réplicas.
3.1. Mettez à l’échelle le déploiement sakila-app avec deux réplicas.
[student@workstation ~]$ oc scale deployment sakila-app --replicas 2

deployment.apps/sakila-app scaled
3.2. Patientez quelques instants, puis vérifiez l’état des pods répliqués.

sakila-app-6694...5kpd 1/1 Running 0 ...
sakila-app-6694...rfzg 1/1 Running 0 ...
satir-app-787b...dfsh 1/1 Running 0 ...
3.3. Mettez à l’échelle le déploiement satir-app avec trois réplicas.
[student@workstation ~]$ oc scale deployment satir-app --replicas 3

deployment.apps/satir-app scaled
282 DO180-OCP4.14-fr-2-20240530
3.4. Patientez quelques instants, puis vérifiez l’état des pods répliqués.

NAME READY STATUS RESTARTS ... IP ...
sakila-app-6694...5kpd 1/1 Running 0 ... 10.8.0.66 ...
sakila-app-6694...rfzg 1/1 Running 0 ... 10.8.0.67 ...
satir-app-787b...dfsh 1/1 Running 0 ... 10.8.0.65 ...
satir-app-787b...z8xm 1/1 Running 0 ... 10.8.0.69 ...
satir-app-787b...7bhj 1/1 Running 0 ... 10.8.0.70 ...
3.5. Récupérez les points d’accès de service pour vérifier que la charge des services est
bien équilibrée entre les pods répliqués supplémentaires.

NAME ENDPOINTS ...
sakila-svc 10.8.0.66:8080,10.8.0.67:8080 ...
satir-svc 10.8.0.65:8080,10.8.0.69:8080,10.8.0.70:8080 ...
4. Activez les sessions permanentes pour l’application Web sakila-app. Utilisez ensuite
la commande curl pour vérifier que les sessions persistantes fonctionnent pour l’objet
ingr-sakila.
4.1. Configurez un cookie pour l’objet d’entrée ingr-sakila.
[student@workstation ~]$ oc annotate ingress ingr-sakila \

ingress.kubernetes.io/affinity=cookie
ingress.networking.k8s.io/ingr-sakila annotated
4.2. Utilisez la commande curl pour accéder à l’objet d’entrée ingr-sakila. La sortie
indique le nom du pod qui traite la demande. Notez que la charge de la connexion est
équilibrée entre les réplicas.
[student@workstation ~]$ for i in {1..3}; do \

curl ingr-sakila.apps.ocp4.example.com ; done
Welcome to Red Hat Training, from sakila-app-66947cdd78-xrfzg
4.3. Utilisez la commande curl pour enregistrer le cookie d’objet d’entrée ingr-sakila
dans le fichier /tmp/cookie_jar. Vérifiez que le cookie existe bien dans le fichier /
tmp/cookie_jar.
[student@workstation ~]$ curl ingr-sakila.apps.ocp4.example.com \

-c /tmp/cookie_jar
[student@workstation ~]$ cat /tmp/cookie_jar

#HttpOnly_ingr-sakila.apps.ocp4.example.com FALSE / FALSE 0
b9b484110526b4b1b3159860d3aebe04 921e139c5145950d00424bf3b0a46d22
DO180-OCP4.14-fr-2-20240530 283
4.4. Le cookie assure la persistance de session pour les connexions à la route ingr-
sakila. Utilisez la commande curl et le cookie du fichier /tmp/cookie_jar pour
vous reconnecter à la route ingr-sakila. Vérifiez que vous bien êtes connecté au
même pod que celui qui a traité la demande à l’étape précédente.

curl ingr-sakila.apps.ocp4.example.com -b /tmp/cookie_jar; done
4.5. Utilisez la commande curl pour vous connecter à la route ingr-sakila sans le
cookie . Notez que la persistance de session se produit uniquement avec le cookie.

curl ingr-sakila.apps.ocp4.example.com ; done
5. Activez les sessions permanentes pour l’application Web satir-app. Utilisez ensuite la
commande curl pour vérifier que les sessions permanentes sont actives pour la route
satir.
5.1. Configurez un cookie avec la valeur hello pour la route satir.
[student@workstation ~]$ oc annotate route satir \

router.openshift.io/cookie_name="hello"
route.route.openshift.io/satir annotated
5.2. Utilisez la commande curl pour accéder à la route satir. La sortie indique le nom
du pod qui traite la demande. Notez que la charge de la connexion est équilibrée
entre les trois pods répliqués.

curl satir-web-applications.apps.ocp4.example.com; done
Welcome to Red Hat Training, from satir-app-787b7d7858-gz8xm
Welcome to Red Hat Training, from satir-app-787b7d7858-q7bhj
5.3. Utilisez la commande curl pour enregistrer le cookie hello dans le fichier /tmp/
cookie_jar. Vérifiez ensuite que le cookie hello existe bien dans le fichier /tmp/
cookie_jar.
[student@workstation ~]$ curl satir-web-applications.apps.ocp4.example.com \

-c /tmp/cookie_jar
284 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ cat /tmp/cookie_jar

#HttpOnly_satir-web-applications.apps.ocp4.example.com FALSE / FALSE 0 hello
b7dd73d32003e513a072e25a32b6c881
5.4. Le cookie hello assure la persistance de session pour les connexions à la route
satir. Utilisez la commande curl et le cookie hello du fichier /tmp/cookie_jar
pour vous reconnecter à la route satir. Vérifiez que vous bien êtes connecté au
même pod que celui qui a traité la demande à l’étape précédente.

curl satir-web-applications.apps.ocp4.example.com -b /tmp/cookie_jar; done
5.5. Utilisez la commande curl pour vous connecter à la route satir sans le cookie
hello. Notez que la persistance de session se produit uniquement avec le cookie.

curl satir-web-applications.apps.ocp4.example.com; done
Welcome to Red Hat Training, from satir-app-787b7d7858-gz8xm
Fin
[student@workstation ~]$ lab finish deploy-routes
DO180-OCP4.14-fr-2-20240530 285
Open Lab
Déployer des applications gérées et en

réseau sur Kubernetes
Déployez un serveur de base de données et une application Web qui s’y connecte, et
exposez l’application Web à un accès externe.
Résultats
• Déployer une base de données MySQL à partir d’une image de conteneur.
• Déployer une application Web à partir d’une image du conteneur.
• Configurer des variables d’environnement pour un déploiement.
• Rendre l’application Web accessible en externe.
Avant De Commencer
Cette commande permet de s’assurer que le cluster est accessible et que toutes les
ressources de l’exercice sont disponibles. Elle crée également le projet database-
applications.
[student@workstation ~]$ lab start deploy-review
Instructions

developer.
Utilisez le projet database-applications pour votre travail.

1. Connectez-vous au cluster OpenShift et accédez au projet database-applications.
2. Créez un déploiement de base de données MySQL nommé mysql-app à l’aide de l’image
registry.ocp4.example.com:8443/redhattraining/mysql-app:v1 et identifiez
la cause première de l’échec.
3. Configurez les variables d’environnement pour le déploiement mysql-app à l’aide des
informations suivantes :
286 DO180-OCP4.14-fr-2-20240530
Champ Valeur
MYSQL_USER redhat
MYSQL_DATABASE world_x
Ensuite, exécutez la commande suivante dans le pod de déploiement mysql-app pour

charger la base de données world_x :
/bin/bash -c "mysql -uredhat -predhat123 </tmp/world_x.sql"
4. Créez un service pour le déploiement mysql-app en utilisant les informations suivantes :
Champ Valeur
Name mysql-service
Port 3306
Target port 3306
5. Créez un déploiement d’application Web nommé php-app à l’aide de l’image

registry.ocp4.example.com:8443/redhattraining/php-webapp:v1.
6. Créez un service pour le déploiement php-app en utilisant les informations suivantes :
Champ Valeur
Name php-svc
Port 8080
Target port 8080
Créez ensuite une route nommée phpapp pour exposer l’application Web à un accès externe.
7. Testez la connectivité entre l’application Web et la base de données
MySQL. Dans un navigateur Web, accédez à la route phpapp-database-
applications.apps.ocp4.example.com et vérifiez que l’application récupère les
données de la base de données MySQL.
Évaluation
persistent.
[student@workstation ~]$ lab grade deploy-review
DO180-OCP4.14-fr-2-20240530 287
Fin
[student@workstation ~]$ lab finish deploy-review
288 DO180-OCP4.14-fr-2-20240530
Solution
Déployer des applications gérées et en

réseau sur Kubernetes
Déployez un serveur de base de données et une application Web qui s’y connecte, et
exposez l’application Web à un accès externe.
Résultats
• Déployer une base de données MySQL à partir d’une image de conteneur.
• Déployer une application Web à partir d’une image du conteneur.
• Configurer des variables d’environnement pour un déploiement.
• Rendre l’application Web accessible en externe.
Avant De Commencer
ressources de l’exercice sont disponibles. Elle crée également le projet database-
applications.
[student@workstation ~]$ lab start deploy-review
Instructions

developer.
Utilisez le projet database-applications pour votre travail.

1. Connectez-vous au cluster OpenShift et accédez au projet database-applications.

Login successful
1.2. Passez au projet database-applications.
DO180-OCP4.14-fr-2-20240530 289
[student@workstation ~]$ oc project database-applications

Now using project "database-applications" on server "https://
2. Créez un déploiement de base de données MySQL nommé mysql-app à l’aide de l’image

registry.ocp4.example.com:8443/redhattraining/mysql-app:v1 et identifiez
la cause première de l’échec.
2.1. Créez le déploiement de base de données MySQL. Ignorez le message

d’avertissement.
[student@workstation ~]$ oc create deployment mysql-app \

--image registry.ocp4.example.com:8443/redhattraining/mysql-app:v1
deployment.apps/mysql-app created
2.2. Vérifiez l’état du déploiement. Le nom du pod peut être différent dans votre sortie.

mysql-app-75dfd58f99-5xfqc 0/1 Error ...
Errors:
pod/mysql-app-75dfd58f99-5xfqc is crash-looping
1 error, 1 info identified, use 'oc status --suggest' to see details.
2.3. Identifiez la cause première de l’échec du déploiement.
[student@workstation ~]$ oc logs mysql-app-75dfd58f99-5xfqc

MYSQL_USER
MYSQL_PASSWORD
MYSQL_DATABASE
MYSQL_ROOT_PASSWORD (regex: '^[a-zA-Z0-9_~!@#$%^&*()-=<>,.?;:|]+$')
3. Configurez les variables d’environnement pour le déploiement mysql-app à l’aide des

informations suivantes :
Champ Valeur
MYSQL_USER redhat
MYSQL_DATABASE world_x
290 DO180-OCP4.14-fr-2-20240530
Ensuite, exécutez la commande suivante dans le pod de déploiement mysql-app pour

charger la base de données world_x :
/bin/bash -c "mysql -uredhat -predhat123 </tmp/world_x.sql"
3.1. Mettez à jour les variables d’environnement pour le déploiement mysql-app.
[student@workstation ~]$ oc set env deployment/mysql-app \

MYSQL_USER=redhat MYSQL_PASSWORD=redhat123 MYSQL_DATABASE=world_x
deployment.apps/mysql-app updated
3.2. Vérifiez que le pod d’application mysql-app se trouve à l’état RUNNING. Le nom du
pod peut être différent dans votre sortie.

mysql-app-57c44f646-5qt2k 1/1 Running ...
3.3. Chargez la base de données world_x.
[student@workstation ~]$ oc exec -it mysql-app-57c44f646-5qt2k \

-- /bin/bash -c "mysql -uredhat -predhat123 </tmp/world_x.sql"
...output omitted..
3.4. Vérifiez que vous pouvez accéder à la base de données MySQL.
[student@workstation ~]$ oc rsh mysql-app-57c44f646-5qt2k
sh-4.4$ mysql -uredhat -predhat123 world_x

mysql>
3.5. Quittez la base de données MySQL, puis quittez le conteneur.
mysql> exit
Bye
sh-4.4$ exit
4. Créez un service pour le déploiement mysql-app en utilisant les informations suivantes :
Champ Valeur
Name mysql-service
Port 3306
Target port 3306
4.1. Exposez le déploiement mysql-app.
DO180-OCP4.14-fr-2-20240530 291
[student@workstation ~]$ oc expose deployment mysql-app --name mysql-service \

service/mysql-service created
4.2. Vérifiez la configuration du service. L’adresse IP du point d’accès peut être différente
dans votre sortie.

mysql-service ClusterIP 172.30.146.213 <none> 3306/TCP 10s
NAME ENDPOINTS AGE
mysql-service 10.8.0.102:3306 19s
5. Créez un déploiement d’application Web nommé php-app à l’aide de l’image

registry.ocp4.example.com:8443/redhattraining/php-webapp:v1.
5.1. Créez le déploiement d’application Web. Ignorez le message d’avertissement.
[student@workstation ~]$ oc create deployment php-app \

--image registry.ocp4.example.com:8443/redhattraining/php-webapp:v1
deployment.apps/php-app created
5.2. Vérifiez l’état du déploiement. Vérifiez que le pod d’application php-app se trouve à
l’état RUNNING.

php-app-725... 1/1 Running ...
mysql-app-57c... 1/1 Running ...

deployment/php-app deploys registry.ocp4.example.com:8443/redhattraining/php-
webapp:v1
deployment #1 running for about a minute - 1 pod
6. Créez un service pour le déploiement php-app en utilisant les informations suivantes :
Champ Valeur
Name php-svc
Port 8080
Target port 8080
Créez ensuite une route nommée phpapp pour exposer l’application Web à un accès externe.
6.1. Exposez le déploiement php-app.
292 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ oc expose deployment php-app --name php-svc \

service/php-svc exposed
dans votre sortie.

mysql-service ClusterIP 172.30.146.213 <none> 3306/TCP 7m47s
php-svc ClusterIP 172.30.228.80 <none> 8080/TCP 4m34s
NAME ENDPOINTS AGE
mysql-service 10.8.0.102:3306 7m50s
php-svc 10.8.0.107:8080 4m37s
6.3. Exposez le service php-svc.
[student@workstation ~]$ oc expose service/php-svc --name phpapp

route.route.openshift.io/phpapp exposed

NAME HOST/PORT ...
phpapp phpapp-database-applications.apps.ocp4.example.com ...
7. Testez la connectivité entre l’application Web et la base de données

MySQL. Dans un navigateur Web, accédez à la route phpapp-database-
applications.apps.ocp4.example.com et vérifiez que l’application récupère les
données de la base de données MySQL.
7.1. Accédez à la route phpapp-database-applications.apps.ocp4.example.com

dans un navigateur Web.
Évaluation
persistent.
[student@workstation ~]$ lab grade deploy-review
DO180-OCP4.14-fr-2-20240530 293
Fin
[student@workstation ~]$ lab finish deploy-review
294 DO180-OCP4.14-fr-2-20240530
Résumé
• De nombreuses ressources dans Kubernetes et RHOCP créent des pods ou ont une incidence
sur ceux-ci.
• Les ressources sont créées de manière impérative ou déclarative. La stratégie impérative

indique au cluster ce qu’il doit faire. La stratégie déclarative définit l’état auquel le cluster
correspond.
• La commande oc new-app crée des ressources qui sont déterminées au moyen de méthodes
heuristiques.
• Pour déployer une application, la méthode la plus courante consiste à créer un déploiement.
• L’API de charge de travail comprend plusieurs ressources pour créer des pods. Le choix de la
ressource dépend de la durée et de la fréquence d’exécution du pod.
• Une ressource de job exécute une tâche unique sur le cluster via un pod. Le cluster tente
d’exécuter la tâche jusqu’à ce qu’elle réussisse ou réessaie autant de fois qu’il est spécifié.
• Les ressources sont organisées en projets et sélectionnées via des étiquettes.
• Une route relie une adresse IP et un nom d’hôte DNS publics à une adresse IP de service interne.
Les services fournissent un accès réseau entre les pods, tandis que les routes fournissent un
accès réseau aux pods à partir d’utilisateurs et d’applications situés à l’extérieur du cluster
RHOCP.
DO180-OCP4.14-fr-2-20240530 295
296 DO180-OCP4.14-fr-2-20240530
chapitre 5
Gestion du stockage pour les

données et la configuration de
l’application
Objectif Externaliser les configurations d’applications dans
les ressources Kubernetes et approvisionner des
volumes de stockage pour les fichiers de données
persistants.
Résultats • Configurer des applications à l’aide de secrets

et de mappages de configuration Kubernetes
pour initialiser des variables d’environnement,
et fournir des fichiers de configuration texte et
binaires.
• Fournir aux applications des volumes de
stockage persistant pour les données basées
sur des blocs et des fichiers.
• Associer des applications à des classes de
stockage qui fournissent des services de
stockage pour répondre aux exigences des
applications.
• Déployer des applications qui peuvent être
mises à l’échelle sans partager le stockage.
Sections • Externalisation de la configuration des

applications (et exercice guidé)
• Approvisionnement de volumes de données
persistants (et exercice guidé)
• Sélection d’une classe de stockage pour une
application (et exercice guidé)
• Gestion du stockage non partagé avec des
ensembles avec état (et exercice guidé)
Atelier • Gestion du stockage pour les données et la

configuration de l’application
DO180-OCP4.14-fr-2-20240530 297
chapitre 5 | Gestion du stockage pour les données et la configuration de l’application
Externalisation de la configuration des

applications
Résultats
• Configurer des applications à l’aide de secrets et de mappages de configuration Kubernetes
pour initialiser des variables d’environnement, et fournir des fichiers de configuration texte et
binaires.
Configuration d’applications Kubernetes

Lorsqu’une application est exécutée dans Kubernetes avec une image préexistante, elle utilise la
configuration par défaut. Cette action est valide à des fins de test. Cependant, dans le cas des
environnements de production, vous devrez peut-être personnaliser vos applications avant de les
déployer.
Kubernetes vous permet d’utiliser des manifestes aux formats JSON et YAML pour spécifier la
configuration prévue pour chaque application. Vous pouvez définir le nom de l’application, des
étiquettes, la source de l’image, le stockage, des variables d’environnement, etc.
L’extrait de code suivant montre un exemple de fichier manifeste YAML d’un déploiement :
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-deployment
spec:
replicas: 1
selector:
matchLabels:
app: hello-deployment
template:
metadata:
labels:
app: hello-deployment
spec:
containers:
- env:
- name: ENV_VARIABLE_1
valueFrom:
secretKeyRef:
key: hello
name: world
image: quay.io/hello-image:latest
Version d’API de la ressource.
Type de ressource Deployment.
Dans cette section, vous spécifiez les métadonnées de votre application, telles que son nom.
298 DO180-OCP4.14-fr-2-20240530
Vous pouvez définir la configuration générale de la ressource qui est appliquée au

déploiement, comme le nombre de réplicas (pods), l’étiquette du sélecteur et les données du
modèle.
Dans cette section, vous spécifiez la configuration de votre application, telle que le nom de
l’image, le nom du conteneur, les ports, les variables d’environnement, etc.
Vous pouvez définir les variables d’environnement de manière à configurer les besoins de
votre application.
Dans certains cas, votre application nécessite la configuration d’une combinaison de fichiers.
Par exemple, au moment de la création, des données et une base de données doivent être
préchargées dans un déploiement de base de données. La plupart du temps, vous configurez des
applications à l’aide de variables d’environnement, de fichiers externes ou d’arguments de ligne
de commande. Ce processus d’externalisation de la configuration garantit que l’application peut
être portée dans tous les environnements lorsque l’image de conteneur, les fichiers externes et les
variables d’environnement sont disponibles dans l’environnement dans lequel elle s’exécute.
Kubernetes fournit un mécanisme permettant d’externaliser la configuration de vos applications à

l’aide de mappages de configuration et de secrets.
Vous pouvez utiliser des mappages de configuration pour « injecter » des données de
configuration dans des conteneurs. Les objets avec espace de noms ConfigMap (mappage
de configuration) permettent d’injecter des données de configuration dans des conteneurs,
ce qui permet de maintenir l’indépendance des conteneurs vis-à-vis de la plateforme. Ces
objets permettent de stocker des informations précises, telles que des propriétés individuelles,
ou plus générales, comme des blobs JSON (sections JSON) ou des fichiers de configuration
complets. Les informations contenues dans les mappages de configuration ne nécessitent aucune
protection.
La liste qui suit montre un exemple de mappage de configuration :
apiVersion: v1
kind: ConfigMap
metadata:
name: example-configmap
namespace: my-app
data:
example.property.1: hello
example.property.2: world
example.property.file: |-
property.1=value-1
property.2=value-2
property.3=value-3
binaryData:
bar: L3Jvb3QvMTAw
Type de ressource ConfigMap.
Contient les données de configuration.
Pointe vers un fichier codé en base64 qui contient des données non UTF-8 ; un fichier de
magasin de clés Java binaire, par exemple. Placez une clé suivie du fichier encodé.
Souvent, les applications ont besoin d’accéder à des informations sensibles. Par exemple, une
application Web backend doit avoir accès aux informations d’identification de la base de données
DO180-OCP4.14-fr-2-20240530 299
pour interroger cette dernière. Kubernetes et OpenShift utilisent des secrets pour stocker des
informations sensibles. Par exemple, vous pouvez utiliser des secrets pour stocker les types
d’informations sensibles suivants :
• Mots de passe
• Fichiers de configuration sensibles
• Informations d’identification à une ressource externe, telles qu’une clé SSH ou un token OAuth
La liste qui suit montre un exemple de secret :
apiVersion: v1
kind: Secret
metadata:
name: example-secret
namespace: my-app
type: Opaque
data:
username: bXl1c2VyCg==
password: bXlQQDU1Cg==
stringData:
hostname: myapp.mydomain.com
secret.properties: |
property1=valueA
property2=valueB
Spécifie le type de secret.
Spécifie la chaîne et les données encodées.
Spécifie la chaîne et les données décodées.
Un secret est un objet avec espace de noms capable de stocker n’importe quel type de données.
Les données d’un secret sont codées en Base64 ; elles ne sont pas stockées en texte clair. Les
données secrètes ne sont pas chiffrées ; vous pouvez décoder le secret au format Base64 pour
accéder aux données d’origine. L’exemple suivant montre les valeurs décodées pour les objets
username et password à partir du secret example-secret :
[user@host] echo bXl1c2VyCg== | base64 --decode

myuser
[user@host] echo bXlQQDU1Cg== | base64 --decode
myP@55
Kubernetes et OpenShift prennent en charge les types de secrets suivants :
• Secrets opaques : un secret opaque stocke des paires clé/valeur qui contiennent des valeurs
arbitraires et qui ne sont pas validées pour se conformer à une convention relative aux noms ou
valeurs de clé.
• Jetons de compte de service : stockez des informations d’identification de jeton pour les
applications qui s’authentifient auprès de l’API Kubernetes.
• Secrets d’authentification de base : stockez les informations d’identification nécessaires pour

l’authentification de base. Le paramètre data de l’objet secret doit contenir l’utilisateur et les
clés de mot de passe qui sont codées au format Base64.
300 DO180-OCP4.14-fr-2-20240530
• Clés SSH : stockent les données utilisées pour l’authentification SSH.
• Certificats TLS : stockez un certificat et une clé qui sont utilisés pour TLS.
• Secrets de configuration Docker : stockez les informations d’identification pour accéder à un

registre d’images de conteneur.
Lorsque vous stockez des informations dans un type de ressource secrète spécifique, Kubernetes
confirme que les données sont conformes au type de secret.
Note
Par défaut, les mappages de configuration et les secrets ne sont pas chiffrés. Pour
chiffrer vos données secrètes au repos, vous devez chiffrer la base de données
Etcd. Lorsque cela est activé, Etcd chiffre les ressources suivantes : secrets,
mappages de configuration, routes, tokens d’accès OAuth et tokens d’autorisation
OAuth. Le chiffrement de la base de données Etcd sort du cadre de ce cours.
Pour plus d’informations, reportez-vous au chapitre Encrypting Etcd Data

(Chiffrement de données Etcd) de la documentation Security and Compliance
(Sécurité et conformité) de Red Hat OpenShift Container Platform 4.14,
disponible à l’adresse https://access.redhat.com/documentation/en-us/
openshift_container_platform/4.14/html-single/security_and_compliance/
index#encrypting-etcd
Création de secrets
Si un pod a besoin d’accéder à des informations sensibles, créez un secret pour ces informations
avant de déployer le pod. Les outils de ligne de commande oc et kubectl fournissent tous deux
la commande create secret. Utilisez l’une des commandes suivantes pour créer un secret :
• Créez un secret générique contenant des paires clé-valeur à partir des valeurs littérales saisies
sur la ligne de commande :
[user@host ~]$ oc create secret generic secret_name \

--from-literal key1=secret1 \
--from-literal key2=secret2
• Créez un secret générique à l’aide des noms de clé spécifiés sur la ligne de commande et des
valeurs à partir des fichiers :
[user@host ~]$ kubectl create secret generic ssh-keys \

--from-file id_rsa=/path-to/id_rsa \
--from-file id_rsa.pub=/path-to/id_rsa.pub
• Créez un secret TLS spécifiant un certificat et la clé associée :
[user@host ~]$ oc create secret tls secret-tls \

--cert /path-to-certificate --key /path-to-key
Pour créer un secret opaque à partir de la console Web, cliquez sur le menu Workloads > Secrets.
Cliquez sur Create et sélectionnez Key/value secret. Complétez le formulaire avec le nom de la clé
et spécifiez la valeur en l’écrivant dans la section suivante ou en l’extrayant d’un fichier.
DO180-OCP4.14-fr-2-20240530 301
Pour créer un secret à partir de la console Web qui stocke les informations d’identification
permettant d’accéder à un registre d’images de conteneur, cliquez sur le menu Workloads
> Secrets. Cliquez sur Create et sélectionnez Image pull secret. Remplissez le formulaire
ou téléchargez un fichier de configuration avec le nom du secret, sélectionnez le type
d’authentification et ajoutez l’adresse du serveur de registre, le nom d’utilisateur, le mot de passe
et les informations d’identification de messagerie.
Création de mappages de configuration

La syntaxe de création d’un mappage de configuration est très semblable à celle qui est utilisée
pour créer un secret. Vous pouvez saisir des paires clé-valeur sur la ligne de commande ou utiliser
le contenu d’un fichier comme valeur d’une clé spécifiée. Vous pouvez utiliser les outils de ligne
de commande oc ou kubectl pour créer un mappage de configuration. La commande suivante
montre comment créer un mappage de configuration :
[user@host ~]$ kubectl create configmap my-config \

--from-literal key1=config1 --from-literal key2=config2
Vous pouvez également utiliser le nom court cm pour créer un mappage de configuration.
[user@host ~]$ oc create cm my-config \

--from-literal key1=config1 --from-literal key2=config2
302 DO180-OCP4.14-fr-2-20240530
Pour créer un mappage de configuration à partir de la console Web, cliquez sur le menu Workloads
> ConfigMaps. Cliquez sur Create ConfigMap et complétez le mappage de configuration en
utilisant la vue Form ou la vue YAML.
Vous pouvez utiliser des fichiers sur chaque clé que vous ajoutez en cliquant sur Browse en regard
du champ Value. Le champ Key doit être le nom du fichier ajouté dans le champ Value.
Note
Utilisez une clé de données binaire au lieu d’une clé de données si le fichier utilise le
format binaire, tel qu’un fichier PNG.
Utilisation de mappages de configuration et de secrets

pour initialiser des variables d’environnement
Vous pouvez utiliser des mappages de configuration pour renseigner des variables
d’environnement individuelles qui configurent votre application. Contrairement aux secrets, les
informations contenues dans les mappages de configuration ne nécessitent aucune protection. La
liste suivante montre un exemple d’initialisation de variables d’environnement :
DO180-OCP4.14-fr-2-20240530 303
apiVersion: v1
kind: ConfigMap
metadata:
name: config-map-example
namespace: example-app
data:
database.name: sakila
database.user: redhat
Projet dans lequel réside le mappage de configuration. Les objets ConfigMap ne peuvent
être référencés que par des pods du même projet.
Initialise la variable database.name sur la valeur sakila.
Initialise la variable database.user sur la valeur redhat.
Vous pouvez ensuite utiliser le mappage de configuration pour renseigner des variables
d’environnement pour votre application. L’exemple suivant montre une ressource de pod qui
renseigne des variables d’environnement spécifiques à l’aide d’un mappage de configuration.
apiVersion: v1
kind: Pod
metadata:
name: config-map-example-pod
spec:
containers:
- name: example-container
image: registry.example.com/mysql-80:1-237
command: [ "/bin/sh", "-c", "env" ]
env:
valueFrom:
configMapKeyRef:
key: database.name
- name: MYSQL_USER
valueFrom:
configMapKeyRef:
key: database.user
optional: true
Attribut permettant de spécifier des variables d’environnement pour le pod.
Nom d’une variable d’environnement de pod dans laquelle vous renseignez la valeur d’une clé.
Nom de l’objet ConfigMap à partir duquel extraire les variables d’environnement.
Variable d’environnement à extraire de l’objet ConfigMap.
Définit la variable d’environnement comme étant facultative. Le pod est démarré même si les
clés et l’objet ConfigMap spécifiés n’existent pas.
304 DO180-OCP4.14-fr-2-20240530
L’exemple suivant montre une ressource de pod qui injecte toutes les variables d’environnement à
partir d’un mappage de configuration.
apiVersion: v1
kind: Pod
metadata:
name: config-map-example-pod2
spec:
containers:
- name: example-container
image: registry.example.com/mysql-80:1-237
command: [ "/bin/sh", "-c", "env" ]
envFrom:
- configMapRef:
Attribut permettant d’extraire toutes les variables d’environnement d’un objet ConfigMap.
Nom de l’objet ConfigMap à partir duquel extraire les variables d’environnement.
Vous pouvez utiliser des secrets avec d’autres ressources Kubernetes telles que des pods, des
déploiements, des compilations, etc. Vous pouvez spécifier des clés secrètes ou des volumes avec
un chemin de montage pour stocker vos secrets. L’extrait de code suivant montre un exemple de
pod qui renseigne des variables d’environnement avec les données du secret Kubernetes test-
secret :
apiVersion: v1
kind: Pod
metadata:
name: secret-example-pod
spec:
containers:
- name: secret-test-container
image: busybox
command: [ "/bin/sh", "-c", "export" ]
env:
- name: TEST_SECRET_USERNAME_ENV_VAR
valueFrom:
secretKeyRef:
name: test-secret
key: username
Spécifie les variables d’environnement pour le pod.
Indique la source des variables d’environnement.
Objet source secretKeyRef des variables d’environnement.
Nom du secret, qui doit exister.
La clé extraite du secret est le nom d’utilisateur pour l’authentification.
DO180-OCP4.14-fr-2-20240530 305
Contrairement aux mappages de configuration, les valeurs des secrets sont toujours codées (et
non pas chiffrées) et leur accès est limité à un nombre moins élevé d’utilisateurs autorisés.
Utilisation de secrets et de mappages de configuration

en tant que volumes
Pour exposer un secret à un pod, vous devez d’abord le créer dans le même espace de noms, ou
projet, que le pod. Dans le secret, affectez chaque élément de données sensibles à une clé. Après
la création, le secret contient des paires clé-valeur.
La commande suivante crée un secret générique contenant des paires clé-valeur à partir
des valeurs littérales saisies sur la ligne de commande : user avec la valeur demo-user et
root_password avec la valeur zT1kTgk.
[user@host ~]$ oc create secret generic demo-secret \

--from-literal user=demo-user \
--from-literal root_password=zT1KTgk
Vous pouvez également créer un secret générique en spécifiant des noms de clé sur la ligne de
commande et des valeurs à partir des fichiers :
[user@host ~]$ oc create secret generic demo-secret \

--from-file user=/tmp/demo/user \
--from-file root_password=/tmp/demo/root_password
Vous pouvez monter un secret sur un répertoire à l’intérieur d’un pod. Kubernetes crée un fichier
pour chaque clé du secret qui utilise le nom de la clé. Le contenu de chaque fichier est la valeur
décodée du secret. La commande suivante montre comment monter des secrets dans un pod :
[user@host ~]$ oc set volume deployment/demo \

--add --type secret \
--secret-name demo-secret \
--mount-path /app-secrets
Modifiez la configuration du volume dans le déploiement demo.
Ajoutez un nouveau volume à partir d’un secret.
Utilisez le secret demo-secret.
Rendez les données secrètes disponibles dans le répertoire /app-secrets du pod. Le

contenu du fichier /app-secrets/user est demo-user. Le contenu du fichier /app/
secrets/root_password est zT1KTgk.
Pour affecter un secret en tant que volume à un déploiement à partir de la console Web, listez les
secrets disponibles dans le menu Workloads > Secrets.
306 DO180-OCP4.14-fr-2-20240530
Sélectionnez un secret, puis cliquez sur Add Secret to workload.
Sélectionnez la charge de travail, choisissez l’option Volume et définissez le chemin de montage

du secret.
Comme pour les secrets, vous devez créer un mappage de configuration avant qu’un pod puisse
l’utiliser. Le mappage de configuration doit exister dans le même espace de noms, ou projet, que
le pod. La commande suivante montre comment créer un mappage de configuration à partir d’un
fichier de configuration externe :
[user@host ~]$ oc create configmap demo-map \

--from-file=config-files/httpd.conf
Vous pouvez également ajouter un mappage de configuration en tant que volume à l’aide de la
commande suivante :
[user@host ~]$ oc set volume deployment/demo \

--add --type configmap \
--configmap-name demo-map \
--mount-path /app-secrets
DO180-OCP4.14-fr-2-20240530 307
Pour vérifier que le volume est bien attaché au déploiement, utilisez la commande suivante :
[user@host ~]$ oc set volume deployment/demo

demo
configMap/demo-map as volume-du9in
mounted at /app-secrets
Vous pouvez également utiliser la commande oc set env pour définir les variables
d’environnement de l’application à partir de secrets ou de mappages de configuration. Dans
certains cas, vous pouvez modifier les noms des clés pour qu’ils correspondent aux noms de
variables d’environnement en utilisant l’option --prefix. Dans l’exemple suivant, la clé user du
secret demo-secret définit la variable d’environnement MYSQL_USER et la clé root_password
du secret demo-secret définit la variable d’environnement MYSQL_ROOT_PASSWORD. Si le nom
de la clé est indiqué en minuscules, la variable d’environnement correspondante est convertie en
majuscules afin de correspondre au modèle défini par l’option --prefix.
[user@host ~]$ oc set env deployment/demo \

--from secret/demo-secret --prefix MYSQL_
Note
Vous ne pouvez pas affecter de mappages de configuration à l’aide de la console
Web.
Mise à jour des secrets et des mappages de

configuration
Les secrets et les mappages de configuration nécessitent parfois des mises à jour. OpenShift
fournit la commande oc extract pour vous assurer que vous disposez des données les plus
récentes. Vous pouvez enregistrer les données dans un répertoire spécifique à l’aide de l’option
--to. Chaque clé du secret ou du mappage de configuration crée un fichier ayant le même
nom qu’elle. Le contenu de chaque fichier est la valeur de la clé associée. Si vous exécutez la
commande oc extract plusieurs fois, vous devez utiliser l’option --confirm pour écraser les
fichiers existants. Vous pouvez également utiliser l’option --confirm pour créer le répertoire
cible pour le contenu extrait.
[user@host ~]$ oc extract secret/demo-secrets -n demo \

--to /tmp/demo --confirm
[user@host ~]$ ls /tmp/demo/
user root_password
[user@host ~]$ cat /tmp/demo/root_password
zT1KTgk
[user@host ~]$ echo k8qhcw3m0 > /tmp/demo/root_password
Après avoir mis à jour les fichiers enregistrés en local, utilisez la commande oc set data pour
mettre à jour le secret ou le mappage de configuration. Pour chaque clé qui nécessite une mise à
jour, indiquez le nom d’une clé et la valeur associée. Si un fichier contient la valeur, utilisez l’option
--from-file.
[user@host ~]$ oc set data secret/demo-secrets -n demo \

--from-file /tmp/demo/root_password
308 DO180-OCP4.14-fr-2-20240530
Vous devez redémarrer les pods qui utilisent des variables d’environnement pour que les pods
puissent lire le secret mis à jour ou le mappage de configuration. Les pods qui utilisent un montage
de volume pour référencer des secrets ou des mappages de configuration reçoivent les mises à
jour sans redémarrage en utilisant à terme une approche cohérente. Par défaut, l’agent kubelet
surveille les modifications apportées aux clés et aux valeurs utilisées dans les volumes des pods
sur le nœud. L’agent kubelet détecte les modifications et les propage aux pods pour assurer la
cohérence des données de volume. Malgré les mises à jour automatiques fournies par Kubernetes,
un redémarrage du pod est toujours nécessaire si le logiciel lit les données de configuration
uniquement au démarrage.
Suppression de secrets et de mappages de

configuration
Comme pour les autres ressources Kubernetes, vous pouvez utiliser la commande delete pour
supprimer les secrets et les mappages de configuration qui ne sont plus nécessaires ni en cours
d’utilisation.
[user@host ~]$ kubectl delete secret/demo-secrets -n demo
[user@host ~]$ oc delete configmap/demo-map -n demo
Références
Pour plus d’informations, reportez-vous au chapitre Using Config Maps with
Applications (Utilisation de mappages de configuration avec des applications) de
la documentation Building Applications (Compilation d’applications) de Red Hat
index#config-maps
Pour plus d’informations, reportez-vous à la section Providing Sensitive Data to

Pods (Fourniture de données sensibles à des pods) de la documentation Working
with Pods (Utilisation de pods) de Red Hat OpenShift Container Platform 4.14,
openshift_container_platform/4.14/html-single/nodes/index#nodes-pods-secrets
Pour plus d’informations, reportez-vous au chapitre Encrypting Etcd Data

(Chiffrement de données Etcd) de la documentation Security and Compliance
(Sécurité et conformité) de Red Hat OpenShift Container Platform 4.14, disponible
à l’adresse
openshift_container_platform/4.14/html-single/security_and_compliance/
index#encrypting-etcd
DO180-OCP4.14-fr-2-20240530 309
Exercice guidé
Externalisation de la configuration des

applications
Déployez un serveur Web en utilisant des fichiers de configuration d’un mappage de
configuration.
Résultats
Dans cet exercice, vous allez déployer une application Web pour monter les fichiers
manquants à partir d’un mappage de configuration.
• Créez un déploiement d’application Web.
• Rendre le déploiement d’application Web accessible en externe.
• Créer un mappage de configuration à partir de deux fichiers.
• Monter le mappage de configuration dans le déploiement d’application Web.
Avant De Commencer
pour préparer votre système pour cet exercice. Cette commande garantit que le cluster est
accessible.
[student@workstation ~]$ lab start storage-configs
Instructions
1. Créez un déploiement d’application Web nommé webconfig à partir de la console
Web. Utilisez l’image de conteneur registry.ocp4.example.com:8443/rhscl/
httpd-24-rhel7:latest.
1.1. Connectez-vous au cluster OpenShift en tant qu’utilisateur developer avec le

mot de passe developer en utilisant l’URL https://console-openshift-
console.apps.ocp4.example.com de la console Web OpenShift.
1.2. Passez à la perspective Administrator, puis au projet storage-configs.

Sélectionnez l’option Workloads > Deployments, puis cliquez sur le bouton Create
Deployments. Ajoutez le nom de déploiement webconfig et le nom d’image
registry.ocp4.example.com:8443/rhscl/httpd-24-rhel7:latest, et
laissez la valeur par défaut pour les autres valeurs.
310 DO180-OCP4.14-fr-2-20240530
1.3. Sélectionnez le bouton Create. Vérifiez que les trois pods ont bien été déployés.
2. Rendez l’application Web accessible en externe à partir de la console Web. Utilisez les
informations suivantes pour créer un service et une route pour l’application Web, et laissez
les champs hostname et path vides.
Champ de service Valeur de service
Service name webconfig-svc
App selector webconfig
Port number 8080
Target port 8080
Champ de route Valeur de route
Route name webconfig-rt
Service name webconfig-svc
Target port 8080
2.1. Sélectionnez l’option Networking > Services et cliquez sur le bouton Create Service
pour créer le service webconfig-svc qui expose le déploiement webconfig.
Mettez à jour les valeurs de la propriété et cliquez sur Create. Vérifiez l’état du
service.
DO180-OCP4.14-fr-2-20240530 311
Vous pouvez également créer le service à partir de l’interface de ligne de commande

à l’aide de la commande oc expose deploy/webconfig --name 'webconfig-
svc' --selector 'app=webconfig' --target-port '8080' --port
'8080'.
2.2. Sélectionnez l’option Networking > Routes et cliquez sur le bouton Create Route
pour créer le service webconfig-rt qui expose le service webconfig-svc. Mettez
à jour les valeurs de la propriété et cliquez sur Create. Vérifiez l'état de la route.
312 DO180-OCP4.14-fr-2-20240530
Vous pouvez également créer la route à partir de l’interface de ligne de commande à

l’aide de la commande oc expose svc/webconfig-svc --name 'webconfig-
rt'.
2.3. Utilisez un navigateur Web pour accéder à la route http://webconfig-rt-

storage-configs.apps.ocp4.example.com. Une page de test s’affiche par
défaut en raison des fichiers manquants.
3. Utilisez les fichiers manquants pour créer un mappage de configuration à partir de la

console Web. Utilisez les informations suivantes pour créer le mappage de configuration
pour l’application Web :
Champ de mappage de configuration Valeur
Name webfiles
Clé des données index.html
Valeur des données Contenu de index.html
Clé des données binaires redhatlogo.png
Valeur des données binaires Contenu non imprimable du fichier

redhatlogo.png
3.1. Sélectionnez l’option Workloads > ConfigMaps et cliquez sur Create ConfigMap
pour afficher le formulaire de mappage de configuration. En utilisant webfiles pour
le nom, créez le mappage de configuration à l’aide des fichiers redhatlogo.png
et index.html dans le répertoire /home/student/DO180/labs/storage-
configs. Ajoutez une clé Data, définissez le nom index.html en tant que valeur
Key et ouvrez le fichier /home/student/DO180/labs/storage-configs/
index.html pour associer le contenu du fichier à la clé de données.
DO180-OCP4.14-fr-2-20240530 313
Ajoutez une clé Binary Data, définissez le nom redhatlogo.png en tant que valeur
Key et ouvrez le fichier /home/student/DO180/labs/storage-configs/
redhatlogo.png pour associer le contenu binaire à la clé binaire.
3.2. Cliquez sur Create pour créer le mappage de configuration.
4. Connectez-vous au cluster OpenShift à partir de la ligne de commande et montez le

mappage de configuration webfiles en tant que volume dans le déploiement webconfig
à partir de la ligne de commande.

de passe developer.
314 DO180-OCP4.14-fr-2-20240530

..output omitted...
4.2. Sélectionnez le projet storage-configs.
[student@workstation ~]$ oc project storage-configs

Now using project "storage-configs" on server "https://api.ocp4.example.com:6443".
4.3. Montez le mappage de configuration webfiles en tant que volume.
[student@workstation ~]$ oc set volume deployment/webconfig \

--add --type configmap --configmap-name webfiles \
--name webfiles-vol --mount-path /var/www/html/
deployment.apps/webconfig volume updated
4.4. Vérifiez l’état du déploiement. Vérifiez qu’un nouveau pod a été créé.

http://webconfig-rt-storage-configs.apps.ocp4.example.com to pod port 8080 (svc/
webconfig-svc)
deployment/webconfig deploys registry.ocp4.example.com:8443/rhscl/httpd-24-
rhel7:latest
deployment #1 deployed 17 minutes ago

webconfig-654bcf6cf-wcnnk 1/1 Running ...
4.5. Revenez au navigateur Web et accédez à la route webconfig-rt-storage-

configs.apps.ocp4.example.com. Cliquez sur le lien Click me! pour ouvrir le
fichier.
Le mappage de configuration a correctement ajouté les fichiers manquants à

l’application Web.
DO180-OCP4.14-fr-2-20240530 315
Fin
[student@workstation ~]$ lab finish storage-configs
316 DO180-OCP4.14-fr-2-20240530
Approvisionnement de volumes de
données persistants
Résultats
• Fournir aux applications des volumes de stockage persistant pour les données basées sur des
blocs et des fichiers.
Stockage persistant Kubernetes

Par défaut, les conteneurs disposent d’un stockage éphémère. La durée de vie de ce stockage
éphémère ne s’étend pas au-delà de celle du pod, et ce stockage éphémère ne peut pas être
partagé entre les pods. Lorsqu’un conteneur est supprimé, tous les fichiers et toutes les données
qu’il contient le sont également. Pour conserver les fichiers, les conteneurs utilisent des volumes
de stockage persistants.
Étant donné qu’OpenShift Container Platform utilise la structure de volume persistant (PV)
Kubernetes, les administrateurs de cluster peuvent fournir un stockage persistant pour un cluster.
Les développeurs peuvent utiliser des revendications de volume persistant (PVC) pour demander
des ressources PV sans connaître spécifiquement l’infrastructure de stockage sous-jacente.
Il existe deux modes d’approvisionnement du stockage pour le cluster : statique et dynamique.

Dans le cas d’un déploiement statique, l’administrateur de cluster doit créer manuellement des
volumes persistants. Le déploiement dynamique utilise des classes de stockage pour créer les
volumes persistants à la demande.
Les administrateurs peuvent utiliser des classes de stockage pour fournir un stockage persistant.
Les classes de stockage décrivent les types de stockage du cluster. Les administrateurs du cluster
créent des classes de stockage pour gérer les services de stockage ou les niveaux de stockage
d’un service. Au lieu de spécifier un stockage approvisionné, les PVC font référence à une classe
de stockage.
Les développeurs utilisent des PVC pour ajouter des volumes persistants à leurs applications.
Ils ne doivent pas nécessairement connaître les détails de l’infrastructure de stockage. Avec
l’approvisionnement statique, les développeurs utilisent des volumes persistants (PV) existants
ou demandent à un administrateur de cluster d’en créer manuellement pour leurs applications.
Avec l’approvisionnement dynamique, les développeurs déclarent les exigences de stockage de
l’application et le cluster crée un PV pour satisfaire la demande.
Volumes persistants
Les stockages ne sont pas tous égaux. Les différents types de stockage varient en termes de
coût, de performances et de fiabilité. Plusieurs types de stockage sont généralement disponibles
pour chaque cluster Kubernetes.
Vous trouverez, ci-dessous, les types de volumes de stockage couramment utilisés et leurs cas
d’utilisation. Cette liste n’est pas exhaustive.
configMap
Le volume configMap externalise les données de configuration de l’application. Cette
utilisation de la ressource configMap garantit que la configuration de l’application peut être
portée dans tous les environnements et peut faire l’objet d’un contrôle de version.
DO180-OCP4.14-fr-2-20240530 317
emptyDir
Un volume emptyDir fournit un répertoire par pod pour les données temporaires (scratch).
Le répertoire est généralement vide après l’approvisionnement. Bien souvent, des volumes
emptyDir sont nécessaires pour le stockage éphémère.
hostPath
Un volume hostPath monte un fichier ou un répertoire à partir du nœud hôte dans votre pod.
Pour utiliser un volume hostPath, l’administrateur du cluster doit configurer les pods pour
qu’ils s’exécutent avec des privilèges. Cette configuration accorde l’accès à d’autres pods
dans le même nœud.
Red Hat déconseille l’utilisation de volumes hostPath en production. À la place, Red Hat
prend en charge le montage de hostPath à des fins de développement et de test sur
un cluster à nœud unique. Bien que la plupart des pods n’aient pas besoin d’un volume
hostPath, cela permet de disposer d’une option rapide pour les tests si une application en a
besoin.
iSCSI
iSCSI (Internet Small Computer System Interface) est une norme IP qui fournit un accès de
niveau bloc aux périphériques de stockage. Avec des volumes iSCSI, les charges de travail
Kubernetes peuvent consommer le stockage persistant à partir de cibles iSCSI.
local
Vous pouvez utiliser des volumes persistants Local pour accéder à des périphériques de
stockage locaux, tels qu’un disque ou une partition, à l’aide de l’interface PVC standard. Les
volumes Local dépendent de la disponibilité du nœud sous-jacent et ne conviennent pas à
toutes les applications.
NFS
Un volume NFS (Network File System) est accessible à partir de plusieurs pods en même
temps et fournit donc des données partagées entre les pods. Le type de volume NFS est
couramment utilisé en raison de sa capacité à partager des données de manière sécurisée.
Red Hat recommande de n’utiliser NFS que pour les systèmes hors production.
Mode d’accès aux volumes

Les différents fournisseurs de volumes persistants varient sur le plan des capacités. Un volume
utilise des modes d’accès pour spécifier les modes qu’il prend en charge. Par exemple, NFS peut
prendre en charge plusieurs clients en lecture/écriture, mais un PV NFS spécifique peut être
exporté sur le serveur en lecture seule. OpenShift définit les modes d’accès suivants, qui sont
récapitulés dans le tableau ci-dessous :
Modes d’accès aux volumes
Access mode Abréviation Description
ReadWriteOnce RWO Un nœud unique monte le volume en lecture/écriture.
ReadOnlyMany ROX De nombreux nœuds montent le volume en lecture

seule.
ReadWriteMany RWX De nombreux nœuds montent le volume en lecture/

écriture.
318 DO180-OCP4.14-fr-2-20240530
Les développeurs doivent sélectionner un type de volume prenant en charge le niveau d’accès
requis par l’application. Le tableau suivant présente quelques exemples des modes d’accès pris en
charge :
Prise en charge des modes d’accès
Type de volume RWO ROX RWX
configMap Oui Non Non
emptyDir Oui Non Non
hostPath Oui Non Non
iSCSI Oui Oui Non
local Oui Non Non
NFS Oui Oui Oui
Modes de volume
Kubernetes prend en charge deux modes pour les volumes persistants : Filesystem et Block. Si
le mode n’est pas défini pour un volume, Kubernetes lui attribue le mode de volume par défaut, à
savoir Filesystem.
OpenShift Container Platform peut approvisionner des volumes en mode bloc bruts. Ces volumes
sont dépourvus de système de fichiers et peuvent améliorer les performances des applications
qui écrivent directement sur le disque ou qui implémentent leur propre service de stockage. Les
volumes en mode bloc bruts sont approvisionnés en indiquant volumeMode: Block dans les
spécifications PV et PVC.
Le tableau suivant fournit des exemples d’options de stockage avec prise en charge des volumes
en mode bloc :
Prise en charge des volumes en mode bloc
Plug-in de volume Approvisionnement manuel Approvisionnement

dynamique
AWS EBS Oui Oui
Disque Azure Oui Oui
Cinder Oui Oui
Fibre Channel Oui Non
GCP Oui Oui
iSCSI Oui Non
local Oui Non
Red Hat OpenShift Data Oui Oui

Foundation
DO180-OCP4.14-fr-2-20240530 319
Plug-in de volume Approvisionnement manuel Approvisionnement

dynamique
VMware vSphere Oui Oui
Création manuelle d’un PV

Utilisez un fichier manifeste PersistentVolume pour créer manuellement un volume persistant
(PV). L’exemple suivant crée un volume persistant à partir d’un périphérique de stockage
Fibre Channel qui utilise le mode bloc.
apiVersion: v1
kind: PersistentVolume
metadata:
name: block-pv
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
volumeMode: Block
persistentVolumeReclaimPolicy: Retain
fc:
targetWWNs: ["50060e801049cfd1"]
lun: 0
readOnly: false
PersistentVolume est le type de ressource des PV.
Indiquez un nom pour le PV, que les revendications suivantes utiliseront pour y accéder.
Spécifiez la quantité de stockage allouée à ce volume.
Le périphérique de stockage doit prendre en charge le mode d’accès spécifié par le PV.
L’attribut volumeMode est facultatif pour les volumes Filesystem, mais obligatoire pour
les volumes Block.
persistentVolumeReclaimPolicy détermine comment le cluster gère le PV lorsque la

PVC est supprimée. Les options valides sont Retain et Delete.
Les autres attributs sont spécifiques au type de stockage. Dans cet exemple, l’objet fc
spécifie les attributs de type de stockage Fiber Channel.
Si le manifeste précédent se trouve dans un fichier nommé my-fc-volume.yaml, la commande

suivante peut créer la ressource PV sur RHOCP :
[user@host]$ oc create -f my-fc-volume.yaml
Pour créer un volume persistant à partir de la console Web, cliquez sur le menu Storage >
PersistentVolumes.
320 DO180-OCP4.14-fr-2-20240530
Réclamations de volume persistantes

Une ressource PVC (Persistant Volume Claim, revendication de volume persistant) représente
une demande de stockage provenant d’une application. Une PVC spécifie les caractéristiques
de stockage minimales, telles que la capacité et le mode d’accès. Une PVC ne spécifie pas de
technologie de stockage, telle que NFS ou iSCSI.
Le cycle de vie d’une PVC n’est pas lié à un pod, mais à un espace de noms. Plusieurs pods du
même espace de noms, mais avec des contrôleurs de charge de travail potentiellement différents,
peuvent se connecter à la même PVC. Vous pouvez également connecter le stockage de manière
séquentielle à différents pods d’application, et l’en dissocier, pour initialiser, convertir, migrer ou
sauvegarder des données.
Kubernetes fait correspondre chaque PVC à une ressource de volume persistant (PV) capable
de répondre aux exigences de la revendication. Il ne s’agit pas d’une correspondance exacte. Une
PVC peut être liée à un PV ayant une taille de disque supérieure à celle qui est demandée. Une
PVC qui spécifie un accès unique peut être liée à un PV pouvant être partagé pour plusieurs accès
simultanés. Plutôt que d’appliquer une politique, les PVC déclarent les besoins d’une application,
ce à quoi Kubernetes répond dans la mesure du possible.
Création d’une PVC

Une revendication de volume persistant (PVC) appartient à un projet spécifique. Pour créer une
revendication de volume persistant, vous devez spécifier le mode d’accès et la taille, entre autres
options. Une PVC ne peut pas être partagée entre des projets. Les développeurs utilisent une
PVC pour accéder à un volume persistant (PV). Les volumes persistants ne sont pas exclusifs aux
projets et sont accessibles sur l’ensemble du cluster OpenShift. Lorsqu’un PV est lié à une PVC, il
ne peut pas être lié à une autre.
Pour ajouter un volume à un déploiement d’application, créez une ressource

PersistentVolumeClaim et ajoutez-la à l’application en tant que volume. Créez la PVC à
l’aide d’un manifeste Kubernetes ou de la commande oc set volumes. En plus de créer une
PVC ou d’utiliser une revendication existante, la commande oc set volumes peut modifier un
déploiement afin de monter la PVC en tant que volume dans le pod.
Pour ajouter un volume à un déploiement d’application, utilisez la commande oc set volumes :
[user@host ~]$ oc set volumes deployment/example-application \

--add \
--name example-pv-storage \
--type persistentVolumeClaim \
--claim-mode rwo \
--claim-size 15Gi \
--mount-path /var/lib/example-app \
--claim-name example-pv-claim
Spécifiez le nom du déploiement qui nécessite la ressource PVC.
La définition de l’option add sur true ajoute des volumes et des montages de volume pour
les conteneurs.
L’option name spécifie un nom de volume. Si rien n’est spécifié, un nom est généré
automatiquement.
Les types pris en charge pour l’opération add sont emptyDir, hostPath, secret,
configMap et persistentVolumeClaim.
DO180-OCP4.14-fr-2-20240530 321
L’option claim-mode est définie par défaut sur ReadWriteOnce. Les valeurs valides sont
ReadWriteOnce (RWO), ReadWriteMany (RWX) et ReadOnlyMany (ROX).
Créez une revendication avec la taille donnée en octets, si elle est spécifiée avec le type de
volume persistant. La taille doit utiliser la notation SI ; par exemple, 15, 15 G ou 15 Gi.
L’option mount-path spécifie le chemin de montage à l’intérieur du conteneur.
L’option claim-name fournit le nom de la PVC et est obligatoire pour le type

persistentVolumeClaim.
La commande crée une PVC et l’ajoute à l’application en tant que volume dans le pod.
La commande met à jour le déploiement pour l’application avec les spécifications volumeMounts
et volumes.
apiVersion: apps/v1
kind: Deployment
metadata:
namespace: storage-volumes
spec:
template:
spec:
volumeMounts:
- mountPath: /var/lib/example-app
name: example-pv-storage
volumes:
- name: example-pv-storage
persistentVolumeClaim:
claimName: example-pv-claim
Déploiement, qui doit se trouver dans le même espace de noms que la PVC.
Chemin de montage dans le conteneur.
Nom du volume, utilisé pour spécifier le volume associé au montage.
Nom de la revendication liée au volume.
L’exemple suivant spécifie une PVC à l’aide d’un manifeste YAML pour créer un objet d’API
PersistentVolumeClaim :
---
apiVersion: v1
metadata:
name: example-pv-claim
labels:
322 DO180-OCP4.14-fr-2-20240530
app: example-application
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 15Gi
PersistentVolumeClaim est le type de ressource d’une PVC.
Utilisez le nom indiqué dans le champ claimName de l’élément persistentVolumeClaim

dans la section volumes d’un manifeste de déploiement.
Spécifiez le mode d’accès demandé par cette PVC. L’approvisionneur de classe de stockage
doit fournir ce mode d’accès. Si des volumes persistants sont créés de manière statique, un
volume persistant éligible doit alors fournir ce mode d’accès.
La classe de stockage crée un volume persistant correspondant à cette demande de taille.

Si des volumes persistants sont créés de manière statique, un volume persistant éligible doit
avoir au moins la taille demandée.
Utilisez la commande oc create pour créer la PVC à partir du fichier manifeste.
[user@host ~]$ oc create -f pvc_file_name.yaml
Utilisez oc get pvc pour afficher les PVC disponibles dans l’espace de noms actuel.
[user@host ~]$ oc get pvc

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS ...
db-pod-pvc Bound pvc-13...ca45 1Gi RWO nfs-storage ...
Pour créer une revendication de volume persistant à partir de la console Web, cliquez sur le menu
Storage > PersistentVolumesClaims.
Cliquez sur Create PersistentVolumeClaim et complétez le formulaire en ajoutant le nom, la classe

de stockage, la taille, le mode d’accès et le mode de volume.
DO180-OCP4.14-fr-2-20240530 323
Approvisionnement dynamique Kubernetes

Les PV sont définis par un objet d’API PersistentVolume qui provient du stockage existant
dans le cluster. L’administrateur du cluster doit approvisionner certains types de stockage de
manière statique. La structure de volume persistant Kubernetes peut également utiliser un objet
StorageClass pour approvisionner des PV de manière dynamique.
Lorsque vous créez une PVC, vous spécifiez une quantité de stockage, le mode d’accès requis
ainsi qu’une classe de stockage pour décrire et classer le stockage. La boucle de contrôle dans
le nœud de contrôle RHOCP surveille les nouvelles PVC et associe la nouvelle PVC à un PV
approprié. S’il n’existe pas de PV approprié, un approvisionneur pour la classe de stockage en crée
un.
Les revendications restent indéfiniment dissociées s’il n’existe pas de volume correspondant ou s’il
s’avère impossible de créer un volume avec un approvisionneur disponible qui dessert une classe
de stockage. Les revendications sont liées lorsque des volumes correspondants sont disponibles.
Par exemple, un cluster contenant de nombreux volumes de 50 Gi approvisionnés manuellement
ne correspondrait pas à une PVC qui demande 100 Gi. La PVC peut être liée lorsqu’un PV de
100 Gi est ajouté au cluster.
Utilisez oc get storageclass pour afficher les classes de stockage fournies par le cluster.
[user@host ~]$ oc get storageclass

NAME PROVISIONER ...
nfs-storage (default) k8s-sigs.io/nfs-subdir-external-provisioner ...
lvms-vg1 topolvm.io ...
Dans cet exemple, la classe de stockage nfs-storage est marquée comme classe de stockage
par défaut. Lorsqu’une classe de stockage par défaut est configurée, la PVC doit nommer
explicitement une autre classe à utiliser, ou elle peut définir l’annotation storageClassName sur
"", afin d’être liée à un PV sans classe de stockage.
L’exemple de commande oc set volume suivant utilise l’option claim-class pour spécifier un
PV approvisionné de manière dynamique.
[user@host ~]$ oc set volumes deployment/example-application \

--add --name example-pv-storage --type pvc --claim-class nfs-storage \
--claim-mode rwo --claim-size 15Gi --mount-path /var/lib/example-app \
--claim-name example-pv-claim
324 DO180-OCP4.14-fr-2-20240530
Note
Étant donné qu’un administrateur de cluster peut modifier la classe de stockage par
défaut, Red Hat vous recommande de toujours spécifier la classe lorsque vous créez
une PVC.
Cycles de vie des PV et des PVC

Lorsque vous créez une PVC, vous demandez une quantité de stockage, un mode d’accès et une
classe de stockage spécifiques. Kubernetes lie la PVC à un PV approprié. S’il n’existe pas de PV
approprié, un approvisionneur pour la classe de stockage en crée un.
Figure 5.17: Cycle de vie des PV
Les PV suivent un cycle de vie basé sur leur relation avec la PVC.
Disponible
Une fois qu’un PV a été créé, il devient disponible pour toute PVC dans le cluster, dans
n’importe quel espace de noms.
Lié
Un PV qui est lié à une PVC l’également au même espace de noms que la PVC, et aucune
autre PVC ne peut l’utiliser.
En cours d’utilisation
Vous pouvez supprimer une PVC si aucun pod ne l’utilise activement. La fonction Storage
Object in Use Protection empêche la suppression des PV et PVC liés que les pods utilisent
activement. Une telle suppression peut entraîner une perte de données. Cette fonction est
activée par défaut.
Si un utilisateur supprime une PVC qu’un pod utilise activement, la suppression n’est
pas immédiate. Cette suppression est reportée jusqu’à ce que plus aucun pod ne l’utilise
activement. De même, si un administrateur de cluster supprime un PV lié à une PVC, la
suppression n’est pas immédiate. Elle est reportée jusqu’à ce que le PV ne soit plus lié à une
PVC.
Liberé
Une fois que le développeur a supprimé la PVC liée à un PV, ce dernier est libéré et le
stockage qu’il utilise peut être récupéré.
Récupéré
La politique de récupération d’un volume persistant indique au cluster ce qu’il doit faire
avec le volume après sa libération. La politique de récupération d’un volume peut être
« Retain » (Conserver) ou « Delete » (Supprimer).
DO180-OCP4.14-fr-2-20240530 325
Stratégie de récupération des volumes
Stratégie Description
Retain Active la récupération manuelle de la ressource pour les plug-ins de volume

qui la prennent en charge.
Delete Supprime l’objet PersistentVolume d’OpenShift Container Platform et

la ressource de stockage associée dans l’infrastructure externe.
Suppression d’une revendication de volume persistant (PVC)

Pour supprimer un volume, utilisez la commande oc delete afin de supprimer la PVC. La classe
de stockage récupère le volume après la suppression de la PVC.
[user@host ~]$ oc delete pvc/example-pvc-storage
Références
Pour plus d’informations, reportez-vous au chapitre Understanding Ephemeral
Storage (Présentation du stockage éphémère) de la documentation Storage
(Stockage) de Red Hat OpenShift Container Platform 4.14, disponible à l’adresse
openshift_container_platform/4.14/html-single/storage/index#understanding-
ephemeral-storage
Pour plus d’informations, reportez-vous au chapitre Understanding Persistent

Storage (Présentation du stockage persistant) de la documentation Storage
openshift_container_platform/4.14/html-single/storage/
index#pvcprotection_understanding-persistent-storage
https://developers.redhat.com/articles/2022/10/06/kubernetes-improves-
developer-agility#few_cloud_native_applications_are_stateless
https://developers.redhat.com/articles/2022/10/06/kubernetes-storage-
concepts#3_concepts_of_kubernetes_storage_for_developers_
https://loft.sh/blog/kubernetes-persistent-volumes-examples-and-best-practices/
326 DO180-OCP4.14-fr-2-20240530
Exercice guidé
Approvisionnement de volumes de
données persistants
Déployez une base de données MySQL avec un stockage persistant à partir d’une PVC, et
identifiez l’approvisionneur de PV et de stockage qui fournit l’application.
Résultats
Vous serez en mesure d’effectuer les tâches suivantes :
• Déployer une base de données MySQL avec un stockage persistant à partir d’une PVC.
• Identifier le PV qui fournit l’application.
• Identifier l’approvisionneur de stockage qui a créé le PV.
Avant De Commencer
exercice.
[student@workstation ~]$ lab start storage-volumes
Instructions
passe developer. Sélectionnez le projet storage-volumes.
1.1. Utilisez un navigateur Web pour accéder à la console Web OpenShift sur https://
console-openshift-console.apps.ocp4.example.com.
1.2. Connectez-vous à l’aide de Red Hat Identity Management avec le nom d’utilisateur
developer et le mot de passe developer.
1.3. Sélectionnez la vue Administrator pour accéder au menu d’administration.
1.4. Dans la page Home > Projects, électionnez le projet storage-volumes.
2. Identifiez la classe de stockage par défaut pour le cluster.
2.1. Sélectionnez l’option de menu Storage > StorageClasses.
DO180-OCP4.14-fr-2-20240530 327
Figure 5.18: Classes de stockage
La classe de stockage nfs-storage porte le libellé Default.

pour créer un déploiement MySQL nommé db-pod. Utilisez le projet storage-volumes.
Ajoutez un service pour la base de données.
3.1. Sélectionnez l’option de menu Workloads > Deployments.
3.2. Vérifiez que le projet storage-volumes est actif et sélectionnez le bouton Create
Deployment.
3.3. Utilisez db-pod pour le nom du déploiement et remplacez le nom de l’image par
registry.ocp4.example.com:8443/rhel8/mysql-80.
Variables d’environnement MYSQL
Name Valeur
MYSQL_USER user1
MYSQL_PASSWORD mypa55w0rd
MYSQL_DATABASE items
3.5. Sélectionnez le lien Advanced options > Scaling et définissez les répliques sur un.
3.6. Cliquez sur Create. Attendez que le cercle bleu indique qu’un seul pod est en cours
d’exécution.
3.7. Cliquez sur Networking > Services > Create Service.
3.8. Ajoutez les valeurs de service.
328 DO180-OCP4.14-fr-2-20240530
Champs de service
Nom du champ Valeur
Name db-pod
selector app=db-pod
Port 3306
Target port 3306
Figure 5.19: Ajouter un service
3.9. Cliquez sur le bouton Create.
4. Ajoutez une PVC RWO (ReadWriteOnce) de 1 Gi nommée db-pod-pvc au déploiement.

Définissez le répertoire /var/lib/mysql comme chemin de montage.
4.1. Sélectionnez l’élément de menu Workloads > Deployments.
4.2. Cliquez sur les trois points verticaux de la ligne avec le déploiement db-pod et
sélectionnez l’option Add storage.
4.3. Dans le formulaire Add Storage, cliquez sur Create new claim.
4.4. Ajoutez les valeurs de champ suivantes au formulaire.
Ajouter des champs de stockage PVC
Nom du champ Valeur
PersistentVolumeClaim name db-pod-pvc
Access mode RWO
Taille 1 GiB
Volume mode Filesystem
Mount path /var/lib/mysql
DO180-OCP4.14-fr-2-20240530 329
4.5. Cliquez sur Save.
4.6. Faites défiler les détails du déploiement jusqu’à la section Volumes.
4.7. Sélectionnez le lien db-pod-pvc pour afficher les détails du PVC.
Figure 5.20: Lien PVC
5. Observez de quelle façon le montage du volume a modifié le déploiement.
5.1. Sélectionnez l’onglet Workloads > Deployments > dp-pod > YAML.
5.2. Observez les ajouts volumes et volumeMounts au déploiement.
apiVersion: apps/v1
kind: Deployment
volumes:
- name: db-pod-pvc
persistentVolumeClaim:
claimName: db-pod-pvc
volumeMounts:
- mountPath: /var/lib/mysql
name: db-pod-pvc
6. Utilisez une ressource de mappage pour ajouter des données d’initialisation à la base de
données.
6.1. Observez le contenu du script init-db.sql qui initialise la base de données.
[student@workstation ~]$ cat \

~/DO180/labs/storage-volumes/configmap/init-db.sql
DROP TABLE IF EXISTS Ìtem`;

CREATE TABLE Ìtem` (ìd` BIGINT not null auto_increment primary key,
`description` VARCHAR(100), `done` BIT);
INSERT INTO Ìtem` (ìd`,`description`,`done`) VALUES (1,'Pick up newspaper', 0);
INSERT INTO Ìtem` (ìd`,`description`,`done`) VALUES (2,'Buy groceries', 1);
330 DO180-OCP4.14-fr-2-20240530

Login successful.
6.3. Définissez le projet storage-volumes comme projet actif.
[student@workstation ~]$ oc project storage-volumes

6.4. Utilisez le contenu du fichier init-db.sql pour créer un mappage de configuration

nommé init-db-cm.
[student@workstation ~]$ oc create configmap init-db-cm \

--from-file=/home/student/DO180/labs/storage-volumes/configmap/init-db.sql
configmap/init-db-cm created
6.5. Ajoutez la ressource de mappage de configuration init-db-cm en tant que volume

nommé init-db-volume dans le déploiement. Spécifiez le type du volume en tant
que configmap et définissez le répertoire /var/db/config comme chemin de
montage.
[student@workstation ~]$ oc set volumes deployment/db-pod \

--add --name init-db-volume --type configmap --configmap-name init-db-cm \
--mount-path /var/db/config
deployment.apps/db-pod volume updated
6.6. Démarrez une session Shell à distance à l’intérieur du conteneur.
[student@workstation ~]$ oc rsh deployment/db-pod

sh-4.4$
6.7. Utilisez le client mysql pour exécuter le script de base de données dans le volume /
var/db/config/init-db.
sh-4.4$ mysql -uuser1 -pmypa55w0rd items </var/db/config/init-db.sql

sh-4.4$
6.8. Exécutez une requête pour vérifier le contenu de la base de données.
sh-4.4$ mysql -uuser1 -pmypa55w0rd items -e 'select * from Item;'

+----+-------------------+------------+
+----+-------------------+------------+
+----+-------------------+------------+
sh-4.4$
DO180-OCP4.14-fr-2-20240530 331
6.9. Quittez la session shell.
sh-4.4$ exit
7. Supprimez, puis recréez le déploiement db-pod.
[student@workstation ~]$ oc delete deployment/db-pod

7.2. Vérifiez que la PVC existe toujours sans le déploiement.
[student@workstation ~]$ oc get pvc

NAME STATUS VOLUME CAPACITY ...
db-pod-pvc Bound pvc-ab5b38c7-359a-4e99-b81c-f7d11ef91cc9 1Gi ...
7.3. Recréez le déploiement db-pod.

--image=registry.ocp4.example.com:8443/rhel8/mysql-80

MYSQL_USER=user1 \
8. Utilisez la commande oc set volume pour associer la PVC existante au déploiement.

--add --type pvc \
--mount-path /var/lib/mysql \
--name db-pod-vol \
--claim-name db-pod-pvc
9. Créez un pod query-db à l’aide de commande oc run et de l’image de conteneur

registry.ocp4.example.com:8443/redhattraining/do180-dbinit. Utilisez le
pod pour exécuter une requête sur le service de base de données.
9.1. Créez le pod query-db. Configurez le pod pour qu’il utilise le client MySQL afin
d’exécuter une requête sur le service db-pod.
332 DO180-OCP4.14-fr-2-20240530

--image registry.ocp4.example.com:8443/redhattraining/do180-dbinit \
--restart Never \
-h db-pod -P3306 items -e 'select * from Item;'"
+----+-------------------+------------+
+----+-------------------+------------+
+----+-------------------+------------+
10. Supprimez le déploiement db-pod et la PVC db-pod-pvc.
[student@workstation ~]$ oc delete deployment/db-pod

10.2. Supprimez la PVC db-pod-pvc.
[student@workstation ~]$ oc delete pvc/db-pod-pvc

persistentvolumeclaim "db-pod-pvc" deleted
Fin
[student@workstation ~]$ lab finish storage-volumes
DO180-OCP4.14-fr-2-20240530 333
Sélection d’une classe de stockage pour

une application
Résultats
• Associer des applications à des classes de stockage qui fournissent des services de stockage
pour répondre aux exigences des applications.
Sélection de la classe de stockage

Les classes de stockage constituent un moyen de décrire des types de stockage pour le
cluster et d’approvisionner le stockage dynamique à la demande. L’administrateur du cluster
détermine la signification d’une classe de stockage, également appelée profil dans d’autres
systèmes de stockage. Un administrateur peut, par exemple, créer une classe de stockage pour le
développement et une autre pour la production.
Kubernetes prend en charge plusieurs backends de stockage. Les options de stockage se

différencient sur le plan des coûts, des performances, de la fiabilité et des fonctionnalités. Un
administrateur peut créer des classes de stockage différentes pour ces options. Les développeurs
peuvent ainsi sélectionner la solution de stockage qui correspond aux besoins de l’application. Ils
ne doivent pas nécessairement connaître les détails de l’infrastructure de stockage.
Rappelez-vous qu’un administrateur sélectionne la classe de stockage par défaut pour

l’approvisionnement dynamique. Une classe de stockage par défaut permet à Kubernetes
d’approvisionner automatiquement une revendication de volume persistant (PVC) qui n’en
spécifie aucune. Étant donné qu’un administrateur peut modifier la classe de stockage par défaut,
un développeur doit définir explicitement la classe d’une application.
Politique de récupération (reclaim)

Au-delà de la fonction de l’application, le développeur doit également prendre en compte l’impact
de la politique de récupération sur les exigences de stockage. Une politique de récupération
détermine ce qu’il advient des données situées sur une PVC après sa suppression. Lorsque vous
en avez terminé avec un volume, vous pouvez supprimer l’objet PVC de l’API, ce qui permet la
récupération de la ressource. Kubernetes libère le volume lorsque la PVC est supprimée, mais il
n’est pas encore disponible pour une autre revendication. Les données du demandeur précédent
restent sur le volume et doivent être traitées conformément à la politique. Pour conserver vos
données, sélectionnez une classe de stockage avec une politique de récupération retain.
Si vous utilisez la politique de récupération retain, seul l’objet PVC est supprimé du cluster
lorsque vous supprimez une PVC. Le volume persistant (PV) qui était associé à la PVC, le
périphérique de stockage physique utilisé par le PV et vos données existent toujours. Pour
récupérer le stockage et l’utiliser à nouveau dans votre cluster, l’administrateur du cluster doit
effectuer des étapes manuelles.
Pour récupérer manuellement un PV en tant qu’administrateur de cluster, procédez comme suit :
1. Supprimez le PV.
[user@host ~]$ oc delete pv <pv-name>
334 DO180-OCP4.14-fr-2-20240530
La ressource associée dans l’infrastructure de stockage externe, telle qu’un volume AWS EBS,
GCE PD, Azure Disk ou Cinder, existe toujours après la suppression du PV.
2. À ce stade, l’administrateur du cluster peut créer un autre PV en utilisant le même stockage et

les mêmes données que le PV précédent. Un développeur peut ensuite monter le nouveau PV
et accéder aux données du PV précédent.
3. L’administrateur du cluster peut également supprimer les données de la ressource de

stockage, puis supprimer cette dernière.
Pour supprimer automatiquement le PV, les données et le stockage physique d’une PVC
supprimée, vous devez choisir une classe de stockage qui utilise la politique de récupération
delete. Cette politique récupère automatiquement votre volume de stockage lorsque la PVC
est supprimée. La politique de récupération delete est le paramètre par défaut pour tous les
approvisionneurs de stockage qui respectent les normes CSI (Container Storage Interface)
de Kubernetes. Si vous utilisez une classe de stockage qui ne spécifie pas de politique de
récupération, la politique delete est utilisée.
Pour plus d’informations sur les normes Container Storage Interface (CSI) de Kubernetes,
consultez la page Kubernetes CSI Developer Documentation à l’adresse https://kubernetes-
csi.github.io/docs/
Responsabilités liées à Kubernetes et aux applications

Kubernetes ne modifie pas la relation entre une application et le stockage. L’application est
chargée d’utiliser ses périphériques de stockage, et de garantir l’intégrité et la cohérence
des données. Le stockage Kubernetes n’empêche pas une application de faire des choses
dangereuses, comme partager un volume de données entre deux bases de données qui
nécessitent un accès exclusif aux données.
Étant donné qu’une PVC est un périphérique de stockage monté par votre hôte Linux, une
application mal configurée peut se comporter de manière inattendue. Par exemple, vous pouvez
avoir un LUN iSCSI, qui est exprimé en tant que PVC RWO qui n’est pas censée être partagée, puis
monter cette même PVC sur deux pods du même hôte. Le fait de savoir si cette situation pose
problème dépend des applications.
En règle générale, deux processus sur le même hôte peuvent parfaitement partager un disque.
Après tout, de nombreuses applications installées sur votre ordinateur personnel partagent un
disque local. Cependant, rien n’empêche un éditeur de texte d’écraser et de perdre toutes les
modifications d’un autre éditeur. Il convient de prendre les mêmes précautions lors de l’utilisation
du stockage Kubernetes.
L’accès à un seul nœud (RWO) et l’accès partagé (RWX) ne garantissent pas un partage sûr et
fiable des fichiers. RWO signifie qu’un seul nœud du cluster peut lire et écrire des données sur
la PVC. Avec RWX, Kubernetes fournit un volume de stockage auquel n’importe quel pod peut
accéder en lecture ou en écriture.
Cas d’utilisation des classes de stockage

L’administrateur crée des classes de stockage qui répondent aux besoins des développeurs. Un
objet storageClass définit chaque classe de stockage, et l’objet contient des informations sur le
fournisseur de stockage et les fonctionnalités du support de stockage. Le fournisseur crée des PV
pour répondre aux spécifications de la classe de stockage. Les administrateurs peuvent créer des
classes de stockage avec différents niveaux fonctionnels, en fonction de nombreux facteurs.
DO180-OCP4.14-fr-2-20240530 335
Modes des volumes de stockage

Une classe de stockage avec prise en charge du mode de volume block permet d’accroître
les performances des applications qui peuvent utiliser des périphériques en mode bloc
bruts. Envisagez d’utiliser une classe de stockage avec prise en charge du mode de volume
Filesystem pour les applications qui partagent des fichiers ou qui fournissent un accès aux
fichiers.
Niveaux de qualité de service (QoS)

Un disque SSD (Solid State Drive) s’avère très rapide et offre une excellente prise en charge
pour les fichiers fréquemment consultés. Utilisez un disque dur plus lent et moins coûteux
pour les fichiers auxquels vous accédez moins souvent.
Niveau d’assistance administrative

Une classe de stockage de niveau production peut inclure des volumes dont la fréquence de
sauvegarde est élevée. En revanche, une classe de stockage de niveau développement peut
inclure des volumes qui ne sont pas configurés avec un programme de sauvegarde.
Les classes de stockage peuvent utiliser une combinaison de ces facteurs et d’autres facteurs
pour répondre au mieux aux besoins des développeurs.
Kubernetes met en correspondance les PVC avec le meilleur PV disponible qui n’est lié à aucune
autre PVC. Le PV doit fournir le mode d’accès spécifié dans la PVC et le volume doit avoir
au moins la taille demandée dans la PVC. Les modes d’accès pris en charge dépendent des
fonctionnalités du fournisseur de stockage. Une PVC peut spécifier des critères supplémentaires,
tels que le nom d’une classe de stockage. Si une PVC ne parvient pas à trouver un PV qui répond à
tous les critères, elle passe à l’état pending et attend qu’un PV approprié soit disponible.
Les PVC peuvent demander une classe de stockage spécifique en spécifiant l’attribut
storageClassName. Cette méthode de sélection d’une classe de stockage spécifique garantit
que le support de stockage convient parfaitement aux exigences de l’application. Seuls les PV
de la classe de stockage demandée peuvent être liés à la PVC. L’administrateur du cluster peut
configurer des approvisionneurs dynamiques pour desservir les classes de stockage. Il peut
également créer un PV à la demande qui répond aux spécifications de la PVC.
Création d’une classe de stockage

L’extrait YAML suivant décrit la définition de base d’un objet StorageClass. Un administrateur
de cluster ou un utilisateur storage-admin crée des objets StorageClass ayant une étendue
globale. La ressource suivante montre les paramètres de configuration d’une classe de stockage.
Cet exemple utilise la définition d’objet AWS ElasticBlockStore (EBS).
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: io1-gold-storage
annotations:
storageclass.kubernetes.io/is-default-class: 'false'
description:'Provides RWO and RWOP Filesystem & Block volumes'
...
parameters:
type: io1
iopsPerGB: "10"
...
provisioner: kubernetes.io/aws-ebs
336 DO180-OCP4.14-fr-2-20240530
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
Élément obligatoire spécifiant la version actuelle de l’API.
Élément obligatoire spécifiant le type d’objet API.
Élément obligatoire spécifiant le nom de la classe de stockage.
Élément facultatif spécifiant des annotations pour la classe de stockage.
Élément facultatif spécifiant les paramètres requis pour l’approvisionneur spécifique ; cet
objet diffère d’un plug-in à l’autre.
Élément obligatoire spécifiant le type d’approvisionneur associé à cette classe de stockage.
Élément facultatif spécifiant la stratégie de récupération sélectionnée pour la classe de

stockage.
Élément facultatif spécifiant le mode de liaison de volume sélectionné pour la classe de

stockage.
Élément facultatif spécifiant le paramètre d’extension de volume.
Plusieurs attributs, tels que la version de l’API, le type d’objet d’API et les annotations, sont
communs aux objets Kubernetes, tandis que d’autres sont spécifiques aux objets de classe de
stockage.
Paramètres
Les paramètres permettent de configurer des types de fichiers, de modifier des types de
stockage, d’activer le chiffrement, d’activer la réplication, etc. Chaque approvisionneur
dispose d’options de paramètres différentes. Les paramètres acceptés dépendent de
l’approvisionneur de stockage. Par exemple, la valeur io1 du paramètre type et le paramètre
iopsPerGB sont spécifiques à EBS. Lorsqu’un paramètre est omis, l’approvisionneur de
stockage utilise la valeur par défaut.
Approvisionneurs
L’attribut provisioner identifie la source du plug-in de support de stockage. Les
approvisionneurs dont le nom commence par une valeur kubernetes.io sont disponibles,
par défaut, dans un cluster Kubernetes.
ReclaimPolicy
La politique de récupération par défaut, Delete, récupère automatiquement le volume de
stockage lorsque la PVC est supprimée. Récupérer du stockage de cette manière permet
de réduire les coûts de stockage. La politique de récupération Retain ne supprime pas le
volume de stockage, de sorte que les données ne sont pas perdues en cas de suppression de
la PVC incorrecte. Cette politique de récupération peut entraîner des coûts de stockage plus
élevés si l’espace n’est pas récupéré manuellement.
VolumeBindingMode
L’attribut volumeBindingMode détermine la manière dont les associations de volume sont
gérées pour une PVC demandeuse. L’utilisation du mode de liaison de volume par défaut
Immediate crée un PV qui correspond à la PVC lorsque celle-ci est créée. Ce paramètre
n’attend pas que le pod utilise la PVC et peut donc s’avérer inefficace. Le mode de liaison
Immediate peut également entraîner des problèmes pour les backends de stockage qui sont
soumis à des contraintes de topologie ou qui ne sont pas globalement accessibles à partir
DO180-OCP4.14-fr-2-20240530 337
de tous les nœuds du cluster. Les PV sont également liés sans connaître les exigences de
planification d’un pod, ce qui peut se traduire par des pods non planifiables.
En utilisant le mode WaitForFirstConsumer, le volume est créé une fois que le pod qui
utilise la PVC est en cours d’utilisation. Avec ce mode, Kubernetes crée des PV qui respectent
les contraintes de planification du pod, telles que les sélecteurs et les exigences en matière de
ressources.
AllowVolumeExpansion
Lorsqu’elle est définie sur une valeur true, la classe de stockage spécifie que le volume de
stockage sous-jacent peut être étendu si davantage de stockage est requis. Les utilisateurs
peuvent redimensionner le volume en modifiant l’objet PVC correspondant. Cette fonction ne
peut être utilisée que pour augmenter un volume, et non pour le réduire.
L’administrateur du cluster peut utiliser la commande create pour créer une classe de stockage
à partir d’un fichier manifeste YAML. La classe de stockage qui en résulte est dépourvue d’espace
de noms. Elle est donc disponible pour tous les projets du cluster.
[user@host ~]$ oc create -f <storage-class-filename.yaml>
Pour créer une classe de stockage à partir de la console Web, cliquez sur le menu Storage >
StorageClasses. Cliquez sur Create StorageClass et complétez le formulaire ou le manifeste
YAML.
Classes de stockage du cluster

Utilisez la commande oc get storageclass pour afficher les options de classe de stockage
disponibles dans un cluster.
[user@host ~]$ oc get storageclass
Un utilisateur de cluster standard peut afficher les attributs d’une classe de stockage à l’aide de la
commande describe. L’exemple suivant interroge les attributs de la classe de stockage intitulée
lvms-vg1.
[user@host ~]$ oc describe storageclass lvms-vg1

IsDefaultClass: No
Annotations: description=Provides RWO and RWOP Filesystem & Block
volumes
Provisioner: topolvm.io
Parameters: csi.storage.k8s.io/fstype=xfs,topolvm.io/device-class=vg1
AllowVolumeExpansion: True
MountOptions: <none>
ReclaimPolicy: Delete
VolumeBindingMode: WaitForFirstConsumer
Events: <none>
La commande describe peut aider un développeur à déterminer si la classe de stockage est

adaptée ou non à une application. Si aucune des classes de stockage du cluster n’est appropriée
pour l’application, le développeur peut demander à l’administrateur du cluster de créer un PV avec
les fonctions requises.
338 DO180-OCP4.14-fr-2-20240530
Utilisation de la classe de stockage

Pour rappel, la commande oc set volume peut ajouter une PVC et un PV associé à
un déploiement. Un fichier manifeste YAML peut déclarer les paramètres d’une PVC
indépendamment du déploiement. Cette méthode est l’option privilégiée pour prendre en
charge la répétabilité, la gestion de la configuration et le contrôle de version. Utilisez l’attribut
storageClassName pour spécifier la classe de stockage à utiliser pour la PVC.
apiVersion: v1
metadata:
name: my-block-pvc
spec:
accessModes:
- RWO
volumeMode: Block
storageClassName: <storage-class-name>
resources:
requests:
storage: 10Gi
Utilisez la commande create pour créer la ressource à partir du fichier manifeste YAML.
[user@host ~]$ oc create -f <my-pvc-filename.yaml>
Utilisez l’option --claim-name avec la commande set volume pour associer la PVC existante à
un déploiement.
[user@host ~]$ oc set volume deployment/<deployment-name> \

--add --name <my-volume-name> \
--claim-name my-block-pvc \
--mount-path /var/tmp
Références
Pour plus d’informations, reportez-vous à la section Understanding Persistent
Storage (Présentation du stockage persistant) de la documentation Storage
openshift_container_platform/4.14/html-single/storage/index#understanding-
persistent-storage
Stockage Kubernetes
https://kubernetes.io/docs/concepts/storage/storage-classes/
Pour plus d’informations sur les normes Container Storage Interface (CSI) de
Kubernetes, consultez la page Kubernetes CSI Developer Documentation à l’adresse
https://kubernetes-csi.github.io/docs/
DO180-OCP4.14-fr-2-20240530 339
Exercice guidé
Sélection d’une classe de stockage pour

une application
Déployez une base de données MySQL avec un stockage persistant basé sur le stockage
en mode bloc en sélectionnant le stockage en mode bloc au lieu du stockage de fichiers par
défaut.
Résultats
Vous serez en mesure de déployer des applications avec un stockage persistant et de créer
des volumes à partir d’une classe de stockage. La classe de stockage doit répondre aux
exigences de stockage de l’application.
Avant De Commencer
exercice.
[student@workstation ~]$ lab start storage-classes
Instructions
passe developer. Utilisez le projet storage-classes.

Login successful.
1.2. Définissez le projet storage-classes comme projet actif.
[student@workstation ~]$ oc project storage-classes

2. Examinez les classes de stockage disponibles sur le cluster. Identifiez une classe de
stockage appropriée à utiliser pour une application de base de données.
2.1. Utilisez la commande get pour récupérer la liste des classes de stockage du cluster.
Vous pouvez utiliser le nom court storageclass, sc, dans la commande.
340 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ oc get sc

NAME PROVISIONER ...
nfs-storage (default) k8s-sigs.io/nfs-subdir-external-provisioner ...
lvms-vg1 topolvm.io ...
Étant donné qu’un administrateur peut modifier le stockage par défaut, les
applications doivent spécifier une classe de stockage qui répond aux exigences de
l’application.
2.2. Utilisez la commande oc describe pour afficher les détails de la classe de stockage
lvms-vg1.
[student@workstation ~]$ oc describe sc lvms-vg1

Name: lvms-vg1
IsDefaultClass: No
Annotations: description=Provides RWO and RWOP Filesystem & Block
volumes
Provisioner: topolvm.io
Parameters: csi.storage.k8s.io/fstype=xfs,topolvm.io/device-class=vg1
AllowVolumeExpansion: True
MountOptions: <none>
ReclaimPolicy: Delete
VolumeBindingMode: WaitForFirstConsumer
Events: <none>
L’annotation de description indique que la classe de stockage prend en charge les

volumes en mode bloc. Pour certaines applications, telles que les bases de données,
les volumes en mode bloc peuvent offrir un avantage en termes de performances par
rapport aux volumes de système de fichiers. Dans la classe de stockage lvms-vg1,
le champ AllowVolumeExpansion est défini sur True. Avec l’extension de volume,
les utilisateurs du cluster peuvent modifier leurs objets PVC et spécifier une nouvelle
taille pour la PVC. Kubernetes utilise ensuite le backend de stockage pour étendre
automatiquement le volume sur la taille demandée. Kubernetes étend également
le système de fichiers des pods qui utilisent la PVC. L’activation de l’extension de
volume peut aider à protéger une application contre les défaillances dues à une
croissance trop rapide des données. Avec ces fonctions, la classe de stockage lvms-
vg1 constitue un bon choix pour l’application de base de données.

pour créer un déploiement MySQL nommé db-pod. Ajoutez les variables d’environnement
manquantes pour que le pod s’exécute.
3.1. Créez le déploiement db-pod.

DO180-OCP4.14-fr-2-20240530 341

MYSQL_USER=user1 \
3.3. Vérifiez que le pod est en cours d’exécution.

db-pod-b4ccfb74-nn4s5 1/1 Running 0 5s
3.4. Exposez le déploiement db-pod pour créer un service.
[student@workstation ~]$ oc expose deployment/db-pod

service/db-pod exposed
4. Ajoutez une PVC RWO (ReadWriteOnce) de 1 Gi nommée db-pod-pvc au déploiement.

Spécifiez le nom du volume en tant que lvm-storage et définissez le répertoire /var/
lib/mysql comme chemin de montage. Utilisez la classe de stockage lvms-vg1.
4.1. Utilisez la commande oc set volume pour créer une PVC pour le déploiement.

--add --name lvm-storage --type pvc \
--claim-mode rwo --claim-size 1Gi --mount-path /var/lib/mysql \
--claim-class lvms-vg1 \
--claim-name db-pod-pvc
L’option claim-class spécifie une classe de stockage personnalisée.
Note
La commande oc set volumes n’a pas d’option pour définir la propriété du mode
de volume. Ainsi, la commande oc set volumes entraîne l’utilisation du mode
de volume par défaut Filesystem. Utilisez un manifeste déclaratif pour définir le
mode de volume à bloquer. L’utilisation de manifestes déclaratifs n’est pas abordée
dans ce cours.
4.2. Utilisez la commande oc get pvc pour afficher l’état de la PVC. Identifiez le nom du
PV et vérifiez que la PVC utilise bien la classe de stockage personnalisée lvms-vg1.

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS
...
db-pod-pvc Bound pvc-72...035a 1Gi RWO lvms-vg1 ...
4.3. Utilisez la commande oc describe pvc pour examiner les détails de la PVC db-
pod-pvc.
342 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ oc describe pvc db-pod-pvc

Name: db-pod-pvc
Namespace: storage-classes
StorageClass: lvms-vg1
Status: Bound
Volume: pvc-b3084a46-3f32-435e-987b-4ad3b9026021
Labels: <none>
Annotations: pv.kubernetes.io/bind-completed: yes
pv.kubernetes.io/bound-by-controller: yes
volume.beta.kubernetes.io/storage-provisioner: topolvm.io
volume.kubernetes.io/selected-node: master01
volume.kubernetes.io/storage-provisioner: topolvm.io
Finalizers: [kubernetes.io/pvc-protection]
Capacity: 1Gi
Access Modes: RWO
VolumeMode: Filesystem
Used By: db-pod-568888457d-qmxn9
Events:
L’attribut Used By confirme que la PVC est bien liée à un pod.
5. Connectez-vous à la base de données pour vérifier qu’elle fonctionne.

--image registry.ocp4.example.com:8443/rhel8/mysql-80 \
--restart Never --command \
-h db-pod -P3306 items -e 'show databases;'"
+--------------------+
| Database |
+--------------------+
| items |
+--------------------+
6. Supprimez le déploiement db-pod et la PVC db-pod-pvc.
[student@workstation ~]$ oc delete all -l app=db-pod

pod "db-pod-568888457d-fvklp" deleted
service "db-pod" deleted
replicaset.apps "db-pod-568888457d" deleted
6.2. Vérifiez que la PVC existe toujours sans le déploiement.
DO180-OCP4.14-fr-2-20240530 343

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS ...
db-pod-pvc Bound pvc-72...035a 1Gi RWO lvms-vg1 ...
6.3. Supprimez la PVC db-pod-pvc.
[student@workstation ~]$ oc delete pvc db-pod-pvc

persistentvolumeclaim "db-pod-pvc" deleted
7. Créez une PVC pour une application qui nécessite un volume de stockage partagé à partir
de la classe de stockage nfs-storage.
7.1. Créez un fichier manifeste YAML de PVC nommé nfs-pvc.yaml avec le contenu
suivant :
apiVersion: v1
metadata:
name: nfs-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
storageClassName: nfs-storage
7.2. Créez la PVC à l’aide de la commande oc create -f et du fichier manifeste YAML.
[student@workstation ~]$ oc create -f nfs-pvc.yaml

persistentvolumeclaim/nfs-pvc created
7.3. Utilisez la commande oc describe pvc pour afficher les détails de la ressource
PVC.
[student@workstation ~]$ oc describe pvc nfs-pvc

Name: nfs-pvc
Namespace: storage-classes
StorageClass: nfs-storage
Status: Bound
Volume: pvc-9f462124-d96e-43e5-96a7-f96dd9375579
Labels: <none>
Annotations: pv.kubernetes.io/bind-completed: yes
pv.kubernetes.io/bound-by-controller: yes
volume.beta.kubernetes.io/storage-provisioner: k8s-sigs.io/nfs-
subdir-external-provisioner
volume.kubernetes.io/storage-provisioner: k8s-sigs.io/nfs-subdir-
external-provisioner
Finalizers: [kubernetes.io/pvc-protection]
Capacity: 1Gi
Access Modes: RWO
344 DO180-OCP4.14-fr-2-20240530
VolumeMode: Filesystem
Used By: <none>
Events:
L’attribut Used By: <none> indique qu’aucun pod n’utilise la PVC. La valeur
Status: Bound et l’affectation d’attribut Volume confirment que l’attribut
VolumeBindingMode de la classe de stockage est défini sur Immediate.
8. Utilisez l’image de conteneur registry.ocp4.example.com:8443/ubi9/

httpd-24:1-321 pour créer un déploiement d’application MySQL nommé web-pod.
8.1. Créez le déploiement web-pod.
[student@workstation ~]$ oc create deployment web-pod --port 8080 \

--image registry.ocp4.example.com:8443/ubi9/httpd-24:1-321
deployment.apps/web-pod created
8.2. Créez un service pour l’application web-pod.
[student@workstation ~]$ oc expose deployment web-pod

service/web-pod exposed
8.3. Exposez le service pour créer une route pour l’application wep-pod. Spécifiez web-
pod.apps.ocp4.example.com comme nom d’hôte.
[student@workstation ~]$ oc expose svc web-pod \

--hostname web-pod.apps.ocp4.example.com
route.route.openshift.io/web-pod exposed
8.4. Affichez la route affectée à l’application web-pod.

NAME HOST/PORT PATH SERVICES PORT ...
web-pod web-pod.apps.ocp4.example.com web-pod 8080 ...
8.5. Utilisez la commande curl pour afficher la page d’index de l’application web-pod.
[student@workstation ~]$ curl http://web-pod.apps.ocp4.example.com/

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/
DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">

<head>
<title>Test Page for the HTTP Server on Red Hat Enterprise Linux</title>
9. Ajoutez la PVC nfs-pvc au déploiement web-pod.
9.1. Utilisez la commande oc set volume pour associer la PVC au déploiement.

Spécifiez le nom du volume en tant que nfs-volume et définissez le chemin de
montage sur le répertoire /var/www/html.
DO180-OCP4.14-fr-2-20240530 345
[student@workstation ~]$ oc set volumes deployment/web-pod \

--add --name nfs-volume \
--claim-name nfs-pvc \
--mount-path /var/www/html
deployment.apps/web-pod volume updated
Le volume mount-path est défini sur le répertoire /var/www/html. Le serveur

utilise ce chemin pour diffuser du contenu HTML.
10. Utilisez l’image de conteneur registry.ocp4.example.com:8443/

redhattraining/do180-roster pour créer un déploiement d’application Web
personnalisé nommé app-pod.
10.1. Créez le déploiement app-pod et spécifiez le port 9090 comme port cible.
[student@workstation ~]$ oc create deployment app-pod --port 9090 \

--image registry.ocp4.example.com:8443/redhattraining/do180-roster
deployment.apps/app-pod created
10.2. Créez un service pour l’application app-pod.
[student@workstation ~]$ oc expose deployment app-pod

service/app-pod exposed
10.3. Exposez le service pour créer une route pour l’application app-pod. Utilisez app-
pod.apps.ocp4.example.com comme nom d’hôte.
[student@workstation ~]$ oc expose svc app-pod \

--hostname app-pod.apps.ocp4.example.com
route.route.openshift.io/app-pod exposed
11. Ajoutez la PVC nfs-pvc au déploiement d’application app-pod.
11.1. Utilisez la commande oc set volume pour associer la PVC au déploiement.

Définissez le nom du volume sur nfs-volume et le chemin de montage sur le
répertoire /var/tmp.
[student@workstation ~]$ oc set volumes deployment/app-pod \

--add --name nfs-volume \
--claim-name nfs-pvc \
--mount-path /var/tmp
deployment.apps/app-pod volume updated
À ce stade, les applications web-pod et app-pod partagent une PVC. Kubernetes

est dépourvu de mécanisme pour empêcher les conflits de données entre les deux
applications. Dans ce cas, l’application app-pod est un programme d’écriture et
l’application web-pod est un programme de lecture. Il n’y a donc pas de conflit. C’est
l’implémentation de l’application, et non Kubernetes, qui empêche l’altération des
données des deux applications qui utilisent la même PVC. Le mode d’accès RWO ne
protège pas l’intégrité des données. Ce mode signifie qu’un seul nœud peut monter
le volume en lecture/écriture et que les pods qui partagent le volume doivent exister
sur le même nœud.
346 DO180-OCP4.14-fr-2-20240530
12. Utilisez l’application app-pod pour ajouter du contenu au volume partagé.
12.1. Ouvrez un navigateur Web pour accéder à la page http://app-

pod.apps.ocp4.example.com/
12.2. Saisissez vos informations dans le formulaire, puis cliquez sur save. L’application
ajoute vos informations à la liste après le formulaire.
12.3. Cliquez sur push pour créer le fichier /var/tmp/People.html sur le volume
partagé.
13. Ouvrez un autre onglet dans le navigateur et accédez à la page http://web-

pod.apps.ocp4.example.com/People.html. L’application web-pod affiche le fichier
People.html à partir du volume partagé.
Fin
[student@workstation ~]$ lab finish storage-classes
DO180-OCP4.14-fr-2-20240530 347
Gestion du stockage non partagé avec

des ensembles avec état
Résultats
• Déployer des applications qui peuvent être mises à l’échelle sans partager le stockage.
Mise en cluster d’applications

La mise en cluster d’applications, telles que MySQL et Cassandra, nécessite généralement
un stockage persistant pour maintenir l’intégrité des données et des fichiers utilisés par les
applications en question. Lorsque de nombreuses applications nécessitent un stockage persistant
en même temps, il se peut que l’approvisionnement de plusieurs disques s’avère impossible en
raison de la quantité limitée de ressources disponibles.
Le stockage partagé résout ce problème en allouant les mêmes ressources d’un seul périphérique
à plusieurs services.
Services de stockage
Les solutions de stockage de fichiers fournissent la structure de répertoire que l’on trouve dans de
nombreux environnements. L’utilisation du stockage de fichiers est idéale lorsque les applications
génèrent ou utilisent des volumes raisonnables de données organisées. Les applications qui
utilisent des implémentations basées sur des fichiers sont répandues, faciles à gérer et constituent
une solution de stockage abordable.
Les solutions basées sur les fichiers conviennent bien à la sauvegarde et à l’archivage des
données, en raison de leur fiabilité, à l’image des services de collaboration et de partage de
fichiers. La plupart des datacenters proposent des solutions de stockage de fichiers, telles qu’un
cluster NAS (Network Attached Storage), pour ces scénarios.
Le serveur de stockage en réseau (NAS) est une architecture de stockage basée sur des fichiers
qui rend les données stockées accessibles aux périphériques en réseau. Ce type de stockage offre
aux réseaux un point d’accès unique pour le stockage avec des fonctions intégrées de sécurité, de
gestion et de tolérance aux pannes. Parmi les nombreux protocoles de transfert de données que
les réseaux peuvent exécuter, deux sont fondamentaux pour la plupart des réseaux : IP (Internet
Protocol) et TCP (Transmission Control Protocol).
Les fichiers qui sont transférés via ces protocoles peuvent être formatés selon l’un des protocoles
suivants :
• NFS (Network File Systems) : ce protocole permet aux hôtes distants de monter des systèmes
de fichiers sur un réseau et d’interagir avec ces systèmes comme s’ils étaient montés en local.
• SMB (Server Message Blocks ) : ce protocole implémente un protocole réseau de couche

application utilisé pour accéder à des ressources sur un serveur, telles que des partages de
fichiers et des imprimantes partagées.
Les solutions NAS peuvent fournir un stockage basé sur des fichiers aux applications au sein du
même datacenter. Cette approche est commune à de nombreuses architectures d’application,
parmi lesquelles :
• Contenu de serveur Web
348 DO180-OCP4.14-fr-2-20240530
• Services de partage de fichiers

• Stockage FTP
• Archives de sauvegarde
Ces applications tirent parti de la fiabilité des données et de la facilité de partage des fichiers
qu’offre le stockage des fichiers. De plus, pour les données de stockage de fichiers, le système
d’exploitation et le système de fichiers gèrent le verrouillage et la mise en cache des fichiers.
Bien que familières et répandues, les solutions de stockage de fichiers ne sont pas idéales pour
tous les scénarios d’application. Un écueil particulier du stockage de fichiers est la mauvaise
gestion de grands ensembles de données ou de données non structurées.
Les solutions de stockage en mode bloc, telles que les technologies SAN (Storage Area
Network) et iSCSI, permettent d’accéder aux périphériques en mode bloc bruts pour le stockage
d’applications. Ces périphériques en mode bloc fonctionnent comme des volumes de stockage
indépendants, tels que les lecteurs physiques sur les serveurs, et nécessitent généralement un
formatage et un montage pour l’accès aux applications.
L’utilisation du stockage en mode bloc est idéale lorsque les applications nécessitent un accès
plus rapide pour optimiser les charges de travail de données lourdes sur le plan informatique.
Les applications qui utilisent des implémentations de stockage au niveau des blocs gagnent en
efficacité en communiquant au niveau du périphérique brut, au lieu de dépendre de l’accès à la
couche du système d’exploitation.
Les approches au niveau des blocs permettent de distribuer les données sur les blocs sur
l’ensemble du volume de stockage. Les blocs utilisent également des métadonnées de base,
notamment un numéro d’identification unique pour chaque bloc de données, afin de permettre
une récupération et un réassemblage rapides des blocs pour la lecture.
Les technologies SAN et iSCSI fournissent des applications avec des volumes au niveau des blocs
à partir de pools de stockage réseau. L’utilisation d’un accès au niveau des blocs aux volumes de
stockage est une approche courante pour les architectures d’applications, telles que :
• Bases de données SQL (accès à un seul nœud)

• Machines virtuelles (accès multi-nœuds)
• Accès aux données hautes performances
• Applications de traitement côté serveur
• Configurations RAID à plusieurs périphériques en mode bloc
Le stockage d’applications qui utilise plusieurs périphériques en mode bloc dans une configuration
RAID bénéficie de l’intégrité des données et des performances fournies par les différentes
matrices.
Avec Red Hat OpenShift Container Platform (RHOCP), vous pouvez créer des classes de
stockage personnalisées pour vos applications. Avec les technologies de stockage NAS et SAN,
les applications RHOCP peuvent utiliser soit le protocole NFS pour le stockage basé sur des
fichiers, soit le protocole au niveau des blocs pour le stockage en mode bloc.
Présentation des ensembles avec état

Une application avec état se caractérise par le fait qu’elle agit en fonction de transactions ou
d’états passés, qui affectent l’état actuel de l’application, ainsi que les états futurs. L’utilisation
d’une application avec état simplifie la récupération après une défaillance en commençant à partir
d’un point donné dans le temps.
Un ensemble avec état est la représentation d’un ensemble de pods avec des identités
cohérentes. Ces identités sont définies comme un réseau avec un seul nom d’hôte, un seul
DO180-OCP4.14-fr-2-20240530 349
stockage et un seul DNS stables à partir d’autant de revendications de volume qu’il est spécifié
par l’ensemble avec état. Un ensemble avec état garantit qu’une identité réseau donnée est
mappée sur la même identité de stockage.
Les déploiements représentent un ensemble de conteneurs à l’intérieur d’un pod. Chaque

déploiement peut avoir de nombreux réplicas actifs, en fonction de la spécification de l’utilisateur.
Ces réplicas peuvent être mis à l’échelle vers le haut (scale-up) ou vers le bas (scale-down),
suivant les besoins. Un jeu de réplicas est un objet d’API Kubernetes natif qui garantit que le
nombre spécifié de réplicas de pod est en cours d’exécution. Les déploiements sont utilisés par
défaut pour les applications sans état, et ils peuvent être utilisés pour les applications avec état en
associant un volume persistant. Tous les pods d’un déploiement partagent un volume et une PVC.
Contrairement aux déploiements, les pods d’ensembles avec état ne partagent pas de volume
persistant. À la place, ils ont chacun leurs propres volumes persistants uniques. Les pods sont
créés sans jeu de réplicas et chaque réplica enregistre ses propres transactions. Chaque réplica
possède son propre identifiant, qui est conservé lors de toute nouvelle planification. Vous devez
configurer la mise en cluster au niveau de l’application de sorte que les pods d’ensembles avec
état aient les mêmes données.
Les ensembles avec état constituent l’option idéale pour les applications, telles que les bases de
données, qui nécessitent des identités cohérentes et un stockage persistant non partagé.
Utilisation d’ensembles avec état

Kubernetes vous permet d’utiliser des fichiers manifestes pour spécifier la configuration prévue
d’un ensemble avec état. Vous pouvez définir le nom de l’application, des étiquettes, la source de
l’image, le stockage, des variables d’environnement, etc.
L’extrait de code suivant montre un exemple de fichier manifeste YAML pour un ensemble avec
état :
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: dbserver
spec:
selector:
matchLabels:
app: database
replicas: 3
template:
metadata:
labels:
app: database
spec:
containers:
- env:
- name: MYSQL_USER
valueFrom:
secretKeyRef:
key: user
name: sakila-cred
image: registry.ocp4.example.com:8443/redhattraining/mysql-app:v1
name: database
ports:
350 DO180-OCP4.14-fr-2-20240530
name: database
volumeMounts:
- mountPath: /var/lib/mysql
name: data
volumeClaimTemplates:
- metadata:
name: data
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "lvms-vg1"
resources:
requests:
storage: 1Gi
Nom de l’ensemble avec état.
Étiquettes d’application.
Nombre de réplicas.
Variables d’environnement pouvant être définies explicitement ou à l’aide d’un objet secret.
Source d’image.
Nom du conteneur.
Ports du conteneur.
Informations sur le chemin de montage des volumes persistants pour chaque réplica. Chaque
volume persistant présente la même configuration.
Mode d’accès du volume persistant. Vous avez le choix entre les options ReadWriteOnce,
ReadWriteMany et ReadOnlyMany.
Classe de stockage utilisée par le volume persistant.
Taille du volume persistant.
Note
Les ensembles avec état ne peuvent être créés qu’à l’aide de fichiers manifestes.
Les interfaces de ligne de commande (CLI) oc et kubectl ne disposent pas de
commandes permettant de créer des ensembles avec état de manière impérative.
Créez l’ensemble avec état à l’aide de la commande create :
[user@host ~]$ oc create -f statefulset-dbserver.yml
Vérifiez la création de l’ensemble avec état nommé dbserver :
DO180-OCP4.14-fr-2-20240530 351
[user@host ~]$ kubectl get statefulset

NAME READY AGE
dbserver 3/3 6s
Vérifiez l’état des instances :
[user@host ~]$ oc get pods

dbserver-0 1/1 Running 0 85s
Vérifiez l’état des volumes persistants :
[user@host ~]$ kubectl get pvc

NAME STATUS VOLUME CAPACITY ACCESS MODES
STORAGECLASS ...
data-dbserver-0 Bound pvc-c28f61ee-... 1Gi RWO nfs-
storage ...
data-dbserver-1 Bound pvc-ddbe6af1-... 1Gi RWO nfs-
storage ...
data-dbserver-2 Bound pvc-8302924a-... 1Gi RWO nfs-
storage ...
Notez que trois PVC ont été créées. Vérifiez que des volumes persistants sont associés à chaque
instance :
[user@host ~]$ oc describe pod dbserver-0

Volumes:
data:
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in
the same namespace)
ClaimName: data-dbserver-0

Volumes:
data:
the same namespace)
352 DO180-OCP4.14-fr-2-20240530

Volumes:
data:
the same namespace)
Note
Vous devez configurer la mise en cluster au niveau de l’application pour que les pods
d’ensembles avec état aient les mêmes données.
Vous pouvez mettre à jour le nombre de réplicas de l’ensemble avec état à l’aide de la commande
scale :
[user@host ~]$ oc scale statefulset/dbserver --replicas 1

dbserver-0 1/1 Running 0 ...
Pour supprimer l’ensemble avec état, utilisez la commande delete statefulset :
[user@host ~]$ kubectl delete statefulset dbserver

statefulset.apps "dbserver" deleted
Notez que les PVC ne sont pas supprimées après l’exécution de la commande oc delete
statefulset :
[user@host ~]$ oc get pvc

NAME STATUS VOLUME CAPACITY ACCESS MODES
STORAGECLASS ...
data-dbserver-0 Bound pvc-c28f61ee-... 1Gi RWO nfs-
storage ...
data-dbserver-1 Bound pvc-ddbe6af1-... 1Gi RWO nfs-
storage ...
data-dbserver-2 Bound pvc-8302924a-... 1Gi RWO nfs-
storage ...
Vous pouvez également créer un ensemble avec état à partir de la console Web en cliquant sur
le menu Workloads > StatefulSets. Cliquez sur Create StatefulSet et personnalisez le manifeste
YAML.
DO180-OCP4.14-fr-2-20240530 353
Références
Documentation de Kubernetes –StatefulSets
https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
Pour plus d’informations, reportez-vous à la section Le stockage en réseau, qu’est-

ce que c’est ? du chapitre Comprendre le stockage des données à l’adresse
https://www.redhat.com/en/topics/data-storage/network-attached-storage#how-
does-it-work
354 DO180-OCP4.14-fr-2-20240530
Exercice guidé
Gestion du stockage non partagé avec

des ensembles avec état
Déployez un serveur Web répliqué à l’aide d’un déploiement et vérifiez que tous les pods
de serveur Web partagent un PV. Déployez aussi une base de données MySQL répliquée à
l’aide d’un ensemble avec état et vérifiez que chaque instance de la base de données reçoit
un PV dédié.
Résultats
Au cours de cet exercice, vous allez déployer un serveur Web avec un volume persistant
partagé entre les réplicas, ainsi qu’un serveur de base de données à partir d’un ensemble
avec état avec des volumes persistants dédiés pour chaque instance.
• Déployer un serveur Web avec un stockage persistant.
• Ajouter des données au stockage persistant.
• Mettre à l’échelle le déploiement du serveur Web et observer les données partagées avec
les réplicas.
• Créer un serveur de base de données avec un ensemble avec état à l’aide d’un fichier
manifeste YAML.
• Vérifier que chaque instance de l’ensemble avec état possède une revendication de
volume persistant (PVC).
Avant De Commencer
exercice.
[student@workstation ~]$ lab start storage-statefulsets
Instructions
1. Créez un déploiement de serveur Web nommé web-server. Utilisez l’image de
conteneur registry.ocp4.example.com:8443/redhattraining/hello-world-
nginx:latest.

de passe developer.
[student@workstation]$ oc login -u developer -p developer \

DO180-OCP4.14-fr-2-20240530 355
1.2. Passez au projet storage-statefulsets.
[student@workstation]$ oc project storage-statefulsets

Now using project "storage-statefulsets" on server ...output omitted...
1.3. Créez le déploiement web-server.
[student@workstation ~]$ oc create deployment web-server \

--image registry.ocp4.example.com:8443/redhattraining/hello-world-nginx:latest
deployment.apps/web-server created
1.4. Vérifiez l’état du déploiement.
[student@workstation ~]$ oc get pods -l app=web-server

web-server-7d7cb4cdc7-t7hx8 1/1 Running 0 4s
2. Ajoutez le volume persistant web-pv au déploiement web-server. Utilisez la classe de

stockage par défaut et les informations suivantes pour créer le volume persistant :
Champ Valeur
Name web-pv
Type persistentVolumeClaim
Claim mode rwo
Claim size 5Gi
Mount path /usr/share/nginx/html
Claim name web-pv-claim
2.1. Ajoutez le volume persistant web-pv au déploiement web-server.
[student@workstation ~]$ oc set volumes deployment/web-server \

--add --name web-pv --type persistentVolumeClaim --claim-mode rwo \
--claim-size 5Gi --mount-path /usr/share/nginx/html --claim-name web-pv-claim
deployment.apps/web-server volume updated
Étant donné qu’aucune classe de stockage n’a été spécifiée avec l’option --claim-
class, la commande utilise la classe de stockage par défaut pour créer le volume
persistant.
2.2. Vérifiez l’état du déploiement. Notez qu’un nouveau pod est créé.
[student@workstation ~]$ oc get pods -l app=web-server

web-server-64689877c6-mdr6f 1/1 Running 0 5s
2.3. Vérifiez l’état du volume persistant.
356 DO180-OCP4.14-fr-2-20240530

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
web-pv-claim Bound pvc-42...63ab 5Gi RWO nfs-storage 29s
La classe de stockage par défaut, nfs-storage, a approvisionné le volume

persistant.
3. Ajoutez des données au PV à l’aide de la commande exec.
3.1. Listez les pods pour récupérer le nom du pod web-server.

web-server-64689877c6-mdr6f 1/1 Running 0 17m
Le nom du pod peut être différent dans votre sortie.
3.2. Utilisez la commande exec pour ajouter le nom du pod que vous avez récupéré à
l’étape précédente au fichier /usr/share/nginx/html/index.html sur le pod.
Ensuite, récupérez le contenu du fichier /var/www/hmtl/index.html pour vérifier
que le nom du pod figure bien dans le fichier.
[student@workstation ~]$ oc exec -it pod/web-server-64689877c6-mdr6f \

-- /bin/bash -c \
'echo "Hello, World from ${HOSTNAME}" > /usr/share/nginx/html/index.html'

-- cat /usr/share/nginx/html/index.html
Hello, World from web-server-64689877c6-mdr6f
4. Mettez à l’échelle le déploiement web-server sur deux réplicas et vérifiez qu’un pod
supplémentaire est créé.
4.1. Mettez à l’échelle le déploiement web-server sur deux réplicas.
[student@workstation ~]$ oc scale deployment web-server --replicas 2

deployment.apps/web-server scaled
4.2. Vérifiez l’état du réplica et récupérez les noms des pods.

web-server-64689877c6-mbj6g 1/1 Running 0 2s
web-server-64689877c6-mdr6f 1/1 Running 0 17m
Les noms des pods peuvent être différents de ceux de votre sortie.
5. Récupérez le contenu du fichier /usr/share/nginx/html/index.html sur les pods

web-server à l’aide de la commande oc exec pour vérifier que le fichier est le même
dans les deux pods.
DO180-OCP4.14-fr-2-20240530 357
5.1. Vérifiez que le fichier /usr/share/nginx/html/index.html est le même dans

les deux pods.
[student@workstation ~]$ oc exec -it pod/web-server-64689877c6-mbj6g \


Notez que les deux fichiers affichent le nom de la première instance, étant donné
qu’ils partagent le volume persistant.
6. Créer un serveur de base de données avec un ensemble avec état à l’aide du fichier
statefulset-db.yml dans le répertoire /home/student/DO180/labs/storage-
statefulsets. Mettez à jour le fichier avec les informations suivantes :
Champ Valeur
metadata.name dbserver
spec.selector.matchLabels.app database
spec.template.metadata.labels.app database
spec.template.spec.containers.name dbserver
spec.template.spec.containers.volumeMounts.name data
spec.template.spec.containers.volumeMounts.mountPath /var/lib/mysql
spec.volumeClaimTemplates.metadata.name data
spec.volumeClaimTemplates.spec.storageClassName lvms-vg1
6.1. Ouvrez le fichier /home/student/DO180/labs/storage-statefulsets/

statefulset-db.yml dans un éditeur. Remplacez les objets <CHANGE_ME> par les
valeurs du tableau précédent :
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: dbserver
spec:
selector:
matchLabels:
app: database
replicas: 2
template:
metadata:
labels:
app: database
spec:
358 DO180-OCP4.14-fr-2-20240530
containers:
- name: dbserver
image: registry.ocp4.example.com:8443/redhattraining/mysql-app:v1
ports:
- name: database
containerPort: 3306
env:
- name: MYSQL_USER
value: "redhat"
- name: MYSQL_PASSWORD
value: "redhat123"
value: "sakila"
volumeMounts:
- name: data
mountPath: /var/lib/mysql
volumeClaimTemplates:
- metadata:
name: data
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "lvms-vg1"
resources:
requests:
storage: 1Gi
6.2. Créez le serveur de base de données à l’aide de la commande oc create -f /

home/student/DO180/labs/storage-statefulsets/statefulset-
db.yml.
[student@workstation ~]$ oc create -f \

/home/student/DO180/labs/storage-statefulsets/statefulset-db.yml
statefulset.apps/bdserver created
6.3. Patientez quelques instants, puis vérifiez le statut de l’ensemble avec état et de ses
instances.
[student@workstation ~]$ oc get statefulset

NAME READY AGE
dbserver 2/2 10s
[student@workstation ~]$ oc get pods -l app=database

dbserver-0 1/1 Running ...
dbserver-1 1/1 Running ...
6.4. Utilisez la commande exec pour ajouter des données à chacun des pods de
l’ensemble avec état.
DO180-OCP4.14-fr-2-20240530 359
[student@workstation ~]$ oc exec -it pod/dbserver-0 -- /bin/bash -c \

"mysql -uredhat -predhat123 sakila -e 'create table items (count INT);'"

"mysql -uredhat -predhat123 sakila -e 'create table inventory (count INT);'"
7. Vérifiez que chaque instance de l’ensemble avec état dbserver possède une
revendication de volume persistant (PVC). Vérifiez ensuite que chaque revendication de
volume persistant contient des données uniques.
7.1. Vérifiez que l’état des revendications de volume persistant est bien défini sur Bound.
[student@workstation ~]$ oc get pvc -l app=database

NAME STATUS ... CAPACITY ACCESS MODE ...
data-dbserver-0 Bound ... 1Gi RWO ...
7.2. Vérifiez que chaque instance de l’ensemble avec état dbserver possède sa
propre PVC en utilisant la commande oc get pod pod-name -o json |
jq .spec.volumes[0].persistentVolumeClaim.claimName.
[student@workstation ~]$ oc get pod dbserver-0 -o json | \

jq .spec.volumes[0].persistentVolumeClaim.claimName
"data-dbserver-0"
[student@workstation ~]$ oc get pod dbserver-1 -o json | \

jq .spec.volumes[0].persistentVolumeClaim.claimName
"data-dbserver-1"
7.3. La mise en cluster au niveau de l’application n’est pas activée pour l’ensemble avec
état dbserver. Vérifiez que chaque instance de l’ensemble avec état dbserver
possède des données uniques.

"mysql -uredhat -predhat123 sakila -e 'show tables;'"
------------------
| Tables_in_sakila |
------------------
| items |
------------------
360 DO180-OCP4.14-fr-2-20240530

------------------
------------------
| inventory |
------------------
8. Supprimez un pod dans l’ensemble avec état dbserver. Vérifiez qu’un nouveau pod est
créé et qu’il utilise la PVC du pod précédent. Vérifiez que la table ajoutée précédemment
existe bien dans la base de données sakila.
8.1. Supprimez le pod dbserver-0 dans l’ensemble avec état dbserver. Vérifiez qu’un
nouveau pod est généré pour l’ensemble avec état. Ensuite, vérifiez que la PVC
data-dbserver-0 existe toujours.
[student@workstation ~]$ oc delete pod dbserver-0

pod "dbserver-0" deleted
[student@workstation ~]$ oc get pods -l app=database

dbserver-1 1/1 Running 0 5m
[student@workstation ~]$ oc get pvc -l app=database

NAME STATUS ... CAPACITY ACCESS MODE ...
8.2. Utilisez la commande exec pour vérifier que le nouveau pod dbserver-0 contient la
table items dans la base de données sakila.

------------------
------------------
| items |
------------------
Fin
DO180-OCP4.14-fr-2-20240530 361
[student@workstation ~]$ lab finish storage-statefulsets
362 DO180-OCP4.14-fr-2-20240530
Open Lab
Gestion du stockage pour les données et

la configuration de l’application
Déployez une application Web et sa base de données qui partagent des informations
d’identification de base de données à partir d’un secret. La base de données doit utiliser
le stockage par défaut pour le cluster. Déployez également une application de partage de
fichiers qui s’exécute avec plusieurs réplicas et partage son volume de stockage avec une
application de téléchargement de fichiers. Les applications de partage et de téléchargement
de fichiers prennent les fichiers de configuration d’un mappage de configuration, et doivent
utiliser le stockage de fichiers NFS pour faciliter le partage. La base de données doit utiliser
le stockage local pour améliorer les performances.
Résultats
• Déployer un serveur de bases de données.
• Déployer une application Web.
• Créer un secret qui contient les informations d’identification du serveur de base de

données.
• Créer un mappage de configuration qui contient un fichier SQL.
• Ajouter et supprimer un volume sur le serveur de base de données et l’application Web.
• Exposer le serveur de base de données et l’application Web.
• Mettre à l’échelle l’application Web vers le haut (scale-up).
• Monter le mappage de configuration en tant que volume.
Avant De Commencer
ressources de l’exercice sont disponibles. Elle crée également le projet storage-review,
ainsi que les fichiers utilisés par cet atelier, dans le répertoire /home/student/DO180/
labs/storage-review.
[student@workstation ~]$ lab start storage-review
Instructions

developer.
DO180-OCP4.14-fr-2-20240530 363
Utilisez le projet storage-review pour votre travail.

1. Connectez-vous au cluster OpenShift et accédez au projet storage-review.
2. Créez un secret nommé world-cred qui contient les données suivantes :
Champ Valeur
user redhat
password redhat123
database world_x
3. Créez un mappage de configuration nommé dbfiles à l’aide du fichier ~/DO180/labs/

storage-review/insertdata.sql.
4. Créez un déploiement de serveur de base de données nommé dbserver à l’aide de l’image
de conteneur registry.ocp4.example.com:8443/redhattraining/mysql-app:v1.
Définissez ensuite les variables d’environnement manquantes à l’aide du secret world-
cred.
5. Ajoutez un service au déploiement dbserver en utilisant les informations suivantes :
Champ Valeur
name dbserver-lvm
type persistentVolumeClaim
claim mode rwo
claim size 1Gi
mount path /var/lib/mysql
claim class lvms-vg1
claim name dbserver-lvm-pvc
6. Créez un service pour le déploiement dbserver en utilisant les informations suivantes :
Champ Valeur
Name mysql-service
Port 3306
Target port 3306
7. Créez un déploiement d’application Web nommé file-sharing à l’aide de l’image de

conteneur registry.ocp4.example.com:8443/redhattraining/php-webapp-
364 DO180-OCP4.14-fr-2-20240530
mysql:v1. Mettez à l’échelle le déploiement sur deux réplicas. Exposez ensuite le

déploiement en utilisant les informations suivantes :
Champ Valeur
Name file-sharing
Port 8080
Target port 8080
Créez une route nommée file-sharing pour exposer l’application Web file-sharing à
un accès externe. Accédez à la route file-sharing dans un navigateur Web pour tester la
connexion entre l’application Web et le serveur de base de données.
8. Montez le mappage de configuration dbfiles sur le déploiement file-sharing en tant
que volume intitulé config-map-pvc. Définissez le chemin de montage sur le répertoire /
home/database-files. Vérifiez ensuite le contenu du fichier insertdata.sql.
9. Ajoutez un volume partagé au déploiement file-sharing. Utilisez les informations
suivantes pour créer le volume :
Champ Valeur
Name shared-volume
Claim mode rwo
Claim size 1Gi
Mount path /home/sharedfiles
Claim class nfs-storage
Claim name shared-pvc
Ensuite, connectez-vous à un pod de déploiement file-sharing et utilisez la commande

cp pour copier le fichier /home/database-files/insertdata.sql dans le répertoire
/home/sharedfiles. Supprimez ensuite le volume config-map-pvc du déploiement
file-sharing.
10. Ajoutez la PVC shared-volume au déploiement dbserver. Ensuite, connectez-vous à
un pod de déploiement dbserver et vérifiez le contenu du fichier /home/sharedfiles/
insertdata.sql.
11. Connectez-vous au serveur de base de données et exécutez le fichier /home/
sharedfiles/insertdata.sql pour ajouter des données à la base de données
world_x. Vous pouvez exécuter le fichier à l’aide de la commande suivante :
mysql -u$MYSQL_USER -p$MYSQL_PASSWORD world_x </home/sharedfiles/insertdata.sql
Ensuite, vérifiez la connectivité entre l’application Web et le serveur de base de données en

accédant à la route file-sharing dans un navigateur Web.
DO180-OCP4.14-fr-2-20240530 365
Évaluation
persistent.
[student@workstation ~]$ lab grade storage-review
Fin
[student@workstation ~]$ lab finish storage-review
366 DO180-OCP4.14-fr-2-20240530
Solution
Gestion du stockage pour les données et

la configuration de l’application
Déployez une application Web et sa base de données qui partagent des informations
d’identification de base de données à partir d’un secret. La base de données doit utiliser
le stockage par défaut pour le cluster. Déployez également une application de partage de
fichiers qui s’exécute avec plusieurs réplicas et partage son volume de stockage avec une
application de téléchargement de fichiers. Les applications de partage et de téléchargement
de fichiers prennent les fichiers de configuration d’un mappage de configuration, et doivent
utiliser le stockage de fichiers NFS pour faciliter le partage. La base de données doit utiliser
le stockage local pour améliorer les performances.
Résultats
• Déployer un serveur de bases de données.
• Déployer une application Web.
• Créer un secret qui contient les informations d’identification du serveur de base de

données.
• Créer un mappage de configuration qui contient un fichier SQL.
• Ajouter et supprimer un volume sur le serveur de base de données et l’application Web.
• Exposer le serveur de base de données et l’application Web.
• Mettre à l’échelle l’application Web vers le haut (scale-up).
• Monter le mappage de configuration en tant que volume.
Avant De Commencer
ressources de l’exercice sont disponibles. Elle crée également le projet storage-review,
ainsi que les fichiers utilisés par cet atelier, dans le répertoire /home/student/DO180/
labs/storage-review.
[student@workstation ~]$ lab start storage-review
Instructions

developer.
DO180-OCP4.14-fr-2-20240530 367
Utilisez le projet storage-review pour votre travail.

1. Connectez-vous au cluster OpenShift et accédez au projet storage-review.

1.2. Passez au projet storage-review.
[student@workstation ~]$ oc project storage-review

Now using project "storage-review" on server "https://api.ocp4.example.com:6443".
2. Créez un secret nommé world-cred qui contient les données suivantes :
Champ Valeur
user redhat
password redhat123
database world_x
2.1. Créer un secret qui contient les informations d’identification de la base de données.
[student@workstation]$ oc create secret generic world-cred \

--from-literal user=redhat \
--from-literal password=redhat123 \
--from-literal database=world_x
secret/world-cred created
2.2. Confirmez la création du secret.
[student@workstation ~]$ oc get secrets world-cred

NAME TYPE DATA AGE
world-cred Opaque 3 2m34s
3. Créez un mappage de configuration nommé dbfiles à l’aide du fichier ~/DO180/labs/

storage-review/insertdata.sql.
3.1. Créez un mappage de configuration nommé dbfiles à l’aide du fichier

insertdata.sql dans le répertoire ~/DO180/labs/storage-review.
[student@workstation ~]$ oc create configmap dbfiles \

--from-file ~/DO180/labs/storage-review/insertdata.sql
configmap/dbfiles created
3.2. Vérifiez que le mappage de configuration a bien été créé.
368 DO180-OCP4.14-fr-2-20240530
[student@workstation]$ oc get configmaps

NAME DATA AGE
dbfiles 1 11s
4. Créez un déploiement de serveur de base de données nommé dbserver à l’aide de l’image

de conteneur registry.ocp4.example.com:8443/redhattraining/mysql-app:v1.
Définissez ensuite les variables d’environnement manquantes à l’aide du secret world-
cred.
4.1. Créez le déploiement de serveur de base de données.
[student@workstation ~]$ oc create deployment dbserver \

--image registry.ocp4.example.com:8443/redhattraining/mysql-app:v1
deployment.apps/dbserver created
4.2. Définissez les variables d’environnement manquantes.
[student@workstation ~]$ oc set env deployment/dbserver --from secret/world-cred \

--prefix MYSQL_
deployment.apps/dbserver updated
4.3. Vérifiez que le pod dbserver se trouve à l’état RUNNING. Le nom du pod peut être
différent dans votre sortie.

dbserver-6d5bf5d86c-ptrb2 1/1 Running ...
5. Ajoutez un service au déploiement dbserver en utilisant les informations suivantes :
Champ Valeur
name dbserver-lvm
type persistentVolumeClaim
claim mode rwo
claim size 1Gi
mount path /var/lib/mysql
claim class lvms-vg1
claim name dbserver-lvm-pvc
5.1. Ajoutez un volume au déploiement dbserver.
DO180-OCP4.14-fr-2-20240530 369
[student@workstation ~]$ oc set volume deployment/dbserver \

--add --name dbserver-lvm --type persistentVolumeClaim \
--claim-mode rwo --claim-size 1Gi --mount-path /var/lib/mysql \
--claim-class lvms-vg1 --claim-name dbserver-lvm-pvc
deployment.apps/dbserver volume updated

dbserver-5bc6bd5d7b-7z7lv 1/1 Running ...
5.3. Vérifiez l’état du volume.

NAME STATUS VOLUME CAPACITY ...output omitted...
dbserver-lvm-pvc Bound pvc-2cb85025-... 1Gi ...output omitted...
6. Créez un service pour le déploiement dbserver en utilisant les informations suivantes :
Champ Valeur
Name mysql-service
Port 3306
Target port 3306
6.1. Exposez le déploiement dbserver.
[student@workstation ~]$ oc expose deployment dbserver --name mysql-service \

service/mysql-service exposed
dans votre sortie.

mysql-service ClusterIP 172.30.240.100 <none> 3306/TCP ...

NAME ENDPOINTS ...
mysql-service 10.8.1.36:3306 ...
7. Créez un déploiement d’application Web nommé file-sharing à l’aide de l’image de

conteneur registry.ocp4.example.com:8443/redhattraining/php-webapp-
mysql:v1. Mettez à l’échelle le déploiement sur deux réplicas. Exposez ensuite le
déploiement en utilisant les informations suivantes :
370 DO180-OCP4.14-fr-2-20240530
Champ Valeur
Name file-sharing
Port 8080
Target port 8080
Créez une route nommée file-sharing pour exposer l’application Web file-sharing à
un accès externe. Accédez à la route file-sharing dans un navigateur Web pour tester la
connexion entre l’application Web et le serveur de base de données.
7.1. Créez un déploiement d’application Web.
[student@workstation ~]$ oc create deployment file-sharing \

--image registry.ocp4.example.com:8443/redhattraining/php-webapp-mysql:v1
deployment.apps/file-sharing created
7.2. Vérifiez l’état du déploiement. Vérifiez que le pod d’application file-sharing se

trouve à l’état RUNNING. Les noms des pods peuvent être différents sur votre système.

file-sharing-789c5948c8-gdrlz 1/1 Running ...
7.3. Mettez à l’échelle le déploiement sur deux réplicas.
[student@workstation ~]$ oc scale deployment file-sharing --replicas 2

deployment.apps/file-sharing scaled
7.4. Vérifiez l’état du réplica et récupérez le nom du pod. Les noms des pods peuvent être
différents sur votre système.

file-sharing-789c5948c8-62j9s 1/1 Running ...
file-sharing-789c5948c8-gdrlz 1/1 Running ...
7.5. Exposez le déploiement file-sharing.
[student@workstation ~]$ oc expose deployment file-sharing --name file-sharing \

service/file-sharing exposed
dans votre sortie.
DO180-OCP4.14-fr-2-20240530 371

file-sharing ClusterIP 172.30.139.210 <none> 8080/TCP ...
mysql-service ClusterIP 172.30.240.100 <none> 3306/TCP ...

NAME ENDPOINTS
file-sharing 10.8.1.37:8080,10.8.1.38:8080 ...
mysql-service 10.8.1.36:3306 ...
7.7. Exposez le service file-sharing.
[student@workstation ~]$ oc expose service/file-sharing

route.route.openshift.io/file-sharing exposed

NAME HOST/PORT ... SERVICES
...
file-sharing file-sharing-storage-review.apps.ocp4.example.com ... file-
sharing ...
7.8. Testez la connectivité entre l’application Web et le serveur de base de données.

Dans un navigateur Web, accédez à http://file-sharing-storage-
review.apps.ocp4.example.com et vérifiez qu’un message Connected
successfully est affiché.
8. Montez le mappage de configuration dbfiles sur le déploiement file-sharing en tant

que volume intitulé config-map-pvc. Définissez le chemin de montage sur le répertoire /
home/database-files. Vérifiez ensuite le contenu du fichier insertdata.sql.
8.1. Montez le mappage de configuration dbfiles sur le déploiement file-sharing.
[student@workstation ~]$ oc set volume deployment/file-sharing \

--add --name config-map-pvc --type configmap \
--configmap-name dbfiles \
--mount-path /home/database-files
deployment.apps/file-sharing volume updated

file-sharing-7f77855b7f-949lg 1/1 Running ...
file-sharing-7f77855b7f-9zvwq 1/1 Running ...
8.3. Vérifiez le contenu du fichier /home/database-files/insertdata.sql.
372 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ oc exec -it pod/file-sharing-7f77855b7f-949lg -- \

head /home/database-files/insertdata.sql
-- MySQL dump 10.13 Distrib 8.0.19, for osx10.14 (x86_64)
--
-- Host: 127.0.0.1 Database: world_x
-- ------------------------------------------------------
-- Server version 8.0.19-debug
9. Ajoutez un volume partagé au déploiement file-sharing. Utilisez les informations

suivantes pour créer le volume :
Champ Valeur
Name shared-volume
Claim mode rwo
Claim size 1Gi
Mount path /home/sharedfiles
Claim class nfs-storage
Claim name shared-pvc
Ensuite, connectez-vous à un pod de déploiement file-sharing et utilisez la commande

cp pour copier le fichier /home/database-files/insertdata.sql dans le répertoire
/home/sharedfiles. Supprimez ensuite le volume config-map-pvc du déploiement
file-sharing.
9.1. Ajoutez le volume shared-volume au déploiement file-sharing.

--add --name shared-volume --type persistentVolumeClaim \
--claim-mode rwo --claim-size 1Gi --mount-path /home/sharedfiles \
--claim-class nfs-storage --claim-name shared-pvc
9.2. Vérifiez l’état du déploiement. Les noms de vos pods peuvent être différents sur votre
système.

file-sharing-65884f75bb-92fxf 1/1 Running ...
file-sharing-65884f75bb-gsghk 1/1 Running ...
9.3. Vérifiez l’état du volume.
DO180-OCP4.14-fr-2-20240530 373

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS
dbserver-lvm-pvc Bound pvc-2cb... 1Gi RWO lvms-vg1 ...
shared-pvc Bound pvc-cf2... 1Gi RWO nfs-storage ...
9.4. Copiez le fichier /home/database-files/insertdata.sql dans le chemin

d’accès /home/sharedfiles.
[student@workstation ~]$ oc exec -it pod/file-sharing-65884f75bb-92fxf -- \

cp /home/database-files/insertdata.sql /home/sharedfiles/
[student@workstation ~]$ oc exec -it pod/file-sharing-65884f75bb-92fxf -- \

ls /home/sharedfiles/
insertdata.sql
9.5. Supprimez le volume config-map-pvc du déploiement file-sharing.

--remove --name=config-map-pvc
10. Ajoutez la PVC shared-volume au déploiement dbserver. Ensuite, connectez-vous à

un pod de déploiement dbserver et vérifiez le contenu du fichier /home/sharedfiles/
insertdata.sql.
10.1. Ajoutez le volume shared-volume au déploiement dbserver.
[student@workstation ~]$ oc set volume deployment/dbserver \

--add --name shared-volume \
--claim-name shared-pvc \
--mount-path /home/sharedfiles
deployment.apps/dbserver volume updated
10.2. Vérifiez l’état du déploiement. Les noms des pods peuvent être différents sur votre
système.

dbserver-6676fbf5fc-n9hpk 1/1 Running ...
file-sharing-5fdb44cf57-2hhwj 1/1 Running ...
file-sharing-5fdb44cf57-z4n7g 1/1 Running ...
10.3. Vérifiez le contenu du fichier /home/sharedfiles/insertdata.sql.
374 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ oc exec -it pod/dbserver-6676fbf5fc-n9hpk -- \

head /home/sharedfiles/insertdata.sql
-- MySQL dump 10.13 Distrib 8.0.19, for osx10.14 (x86_64)
--
-- Host: 127.0.0.1 Database: world_x
-- ------------------------------------------------------
-- Server version 8.0.19-debug
11. Connectez-vous au serveur de base de données et exécutez le fichier /home/

sharedfiles/insertdata.sql pour ajouter des données à la base de données
world_x. Vous pouvez exécuter le fichier à l’aide de la commande suivante :
mysql -u$MYSQL_USER -p$MYSQL_PASSWORD world_x </home/sharedfiles/insertdata.sql
Ensuite, vérifiez la connectivité entre l’application Web et le serveur de base de données en

accédant à la route file-sharing dans un navigateur Web.
11.1. Connectez-vous au serveur de base de données et exécutez le fichier /home/

sharedfiles/insertdata.sql. Quittez ensuite le serveur de base de données.
[student@workstation ~]$ oc rsh dbserver-6676fbf5fc-n9hpk
sh-4.4$ mysql -u$MYSQL_USER -p$MYSQL_PASSWORD world_x

</home/sharedfiles/insertdata.sql
sh-4.4$ exit
exit
11.2. Testez la connectivité entre l’application Web et le serveur de base de données.

Dans un navigateur Web, accédez à http://file-sharing-storage-
review.apps.ocp4.example.com et vérifiez que l’application récupère les données
de la base de données world_x.
Évaluation
persistent.
[student@workstation ~]$ lab grade storage-review
DO180-OCP4.14-fr-2-20240530 375
Fin
[student@workstation ~]$ lab finish storage-review
376 DO180-OCP4.14-fr-2-20240530
Résumé
• Les mappages de configuration sont des objets qui fournissent un mécanisme permettant
d’injecter des données de configuration dans des conteneurs.
• Les valeurs des secrets sont toujours codées (et non chiffrées).
• Une ressource PVC représente une demande de stockage émise par une application. Elle
spécifie les caractéristiques de stockage minimales, telles que la capacité et le mode d’accès.
• Kubernetes prend en charge deux modes pour les volumes persistants : Filesystem et Block.
• Les classes de stockage constituent un moyen de décrire des types de stockage pour le cluster
et d’approvisionner le stockage dynamique à la demande.
• Une politique de récupération détermine ce qu’il advient des données situées sur une PVC
après sa suppression.
• Une classe de stockage avec prise en charge du mode de volume de type bloc permet
d’accroître les performances des applications qui peuvent utiliser des périphériques en mode
bloc bruts.
• Un ensemble avec état est la représentation d’un ensemble de pods avec des identités
cohérentes.
• Les pods d’ensembles avec état se voient attribuer des volumes persistants individuels.
DO180-OCP4.14-fr-2-20240530 377
378 DO180-OCP4.14-fr-2-20240530
chapitre 6
Configuration des applications

sur le plan de la fiabilité
Objectif Configurer des applications pour qu’elles
fonctionnent avec Kubernetes pour offrir une
haute disponibilité et une résilience élevée.
Résultats • Décrire comment Kubernetes essaie de faire

en sorte que les applications continuent de
s’exécuter après une défaillance.
• Décrire comment Kubernetes utilise les sondes
d’intégrité lors du déploiement, de la mise à
l’échelle et du basculement des applications.
• Configurer une application avec des demandes
de ressources afin que Kubernetes puisse
prendre des décisions de planification.
• Configurer une application avec des limites
de ressources afin que Kubernetes puisse en
protéger d’autres.
• Configurer un autoscaler de pod horizontal
pour une application.
Sections • Haute disponibilité des applications avec

Kubernetes (et exercice guidé)
• Sondes d’intégrité des applications (et exercice
guidé)
• Réservation de capacité de calcul pour les
• Limitation de la capacité de calcul pour les
• Mise à l’échelle automatique des
Atelier • Configuration des applications sur le plan de la

fiabilité
DO180-OCP4.14-fr-2-20240530 379
chapitre 6 | Configuration des applications sur le plan de la fiabilité
Haute disponibilité des applications avec

Kubernetes
Résultats
• Décrire comment Kubernetes essaie de faire en sorte que les applications continuent de
Concepts de déploiement d’applications à haute

disponibilité
La haute disponibilité (HA) vise à rendre les applications plus robustes et plus résistantes aux
pannes d’exécution. L’implémentation de techniques de haute disponibilité réduit la probabilité
qu’une application soit totalement indisponible pour les utilisateurs.
En général, la haute disponibilité peut protéger une application contre les défaillances dans les
contextes suivants :
• D’elle-même sous la forme de bogues d’application
• De son environnement (les problèmes de mise en réseau, par exemple)
• D’autres applications qui épuisent les ressources du cluster
En outre, les pratiques de haute disponibilité peuvent protéger le cluster contre les applications,
comme celles qui présentent une fuite de mémoire.
Écriture d’applications fiables

Fondamentalement, les outils de haute disponibilité au niveau du cluster permettent d’atténuer les
scénarios les plus défavorables. La haute disponibilité ne remplace pas la résolution des problèmes
au niveau de l’application, mais elle renforce les mesures d’atténuation pour les développeurs. Bien
qu’elle soit requise pour la fiabilité, la sécurité des applications est une préoccupation distincte.
Les applications doivent fonctionner avec le cluster pour que Kubernetes puisse gérer au mieux
les scénarios de défaillance. Kubernetes attend d’une application qu’elle se comporte comme suit :
• Elle doit tolérer les redémarrages
• Elle doit répondre aux sondes d’intégrité, telles que les sondes Startup, Readiness et Liveness
• Elle doit prendre en charge plusieurs instances simultanées
• Son utilisation des ressources doit être adaptée et bien définie
• Elle doit fonctionner avec des privilèges restreints
Bien que le cluster puisse exécuter des applications qui ne présentent pas les comportements
précédents, celles qui sont conformes utilisent mieux les fonctions de fiabilité et de haute
disponibilité fournies par Kubernetes.
La plupart des applications HTTP fournissent un point d’accès pour vérifier l’intégrité de
l’application. Le cluster peut être configuré pour observer ce point d’accès et atténuer les
problèmes potentiels pour l’application.
380 DO180-OCP4.14-fr-2-20240530
L’application est chargée de fournir un tel point d’accès. Les développeurs doivent décider
comment l’application détermine son état.
Par exemple, si une application dépend d’une connexion à une base de données, elle peut
répondre avec un état « sain » uniquement si la base de données est accessible. Cependant,
toutes les applications qui établissent des connexions à la base de données n’ont pas besoin d’une
telle vérification. Cette décision est laissée au choix des développeurs.
Fiabilité des applications Kubernetes

En cas de plantage, un pod d’application ne peut pas répondre aux demandes. Suivant la
configuration, le cluster peut redémarrer automatiquement le pod. Si l’application échoue sans
« planter » le pod, celui-ci ne reçoit pas de demandes. Cependant, le cluster ne peut procéder de
la sorte qu’avec les sondes d’intégrité appropriées.
Kubernetes utilise les techniques de haute disponibilité suivantes pour améliorer la fiabilité des
applications :
• Redémarrage des pods : en configurant une politique de redémarrage sur un pod, le cluster
redémarre les instances d’une application dont le comportement n’est pas conforme.
• Sondage : l’utilisation de sondes d’intégrité permet au cluster de savoir quand les applications
ne peuvent pas répondre aux demandes. Il peut ainsi agir automatiquement pour atténuer le
problème.
• Mise à l’échelle horizontale : lorsque la charge de l’application change, le cluster peut

dimensionner le nombre de réplicas pour qu’il corresponde à la charge.
Ces techniques sont abordées tout au long de ce chapitre.
DO180-OCP4.14-fr-2-20240530 381
Exercice guidé
Haute disponibilité des applications avec

Kubernetes
Simulez différents types de défaillances d’applications et observez de quelle manière
Kubernetes les gère.
Résultats
• Découvrir comment l’attribut restartPolicy affecte les pods défaillants.
• Observer le comportement d’une application à démarrage lent sur laquelle aucune sonde
n’est configurée.
• Utiliser un déploiement pour mettre à l’échelle l’application et observer le comportement

d’un pod défectueux.
Avant De Commencer
Cette commande s’assure que les conditions suivantes sont remplies :
• Le projet reliability-ha existe.

• Les fichiers de ressources sont disponibles dans le répertoire du cours.
• Le registre de la salle de classe contient l’image de conteneur long-load.
L’image de conteneur long-load contient une application avec des points d’accès
d’utilitaire. Ces points d’accès exécutent des tâches telles que l’arrêt brutal du processus et
le basculement de l’état d’intégrité du serveur.
[student@workstation ~]$ lab start reliability-ha
Instructions
1. En tant qu’utilisateur developer, créez un pod à partir d’un manifeste YAML dans le projet
reliability-ha.

1.2. Sélectionnez le projet reliability-ha.
[student@workstation ~]$ oc project reliability-ha

Now using project "reliability-ha" on server "https://api.ocp4.example.com:6443".
382 DO180-OCP4.14-fr-2-20240530
1.3. Accédez au répertoire des supports d’atelier et affichez le contenu de la définition de

pod. En particulier, restartPolicy est défini sur Always.
[student@workstation ~]$ cd DO180/labs/reliability-ha
[student@workstation reliability-ha]$ cat long-load.yaml

apiVersion: v1
kind: Pod
metadata:
name: long-load
spec:
containers:
- image: registry.ocp4.example.com:8443/redhattraining/long-load:v1
name: long-load
securityContext:
allowPrivilegeEscalation: false
1.4. Créez un pod à l’aide de la commande oc apply.
[student@workstation reliability-ha]$ oc apply -f long-load.yaml

pod/long-load created
1.5. Envoyez une demande au pod pour vérifier qu’il est en cours d’exécution et qu’il
répond.
[student@workstation reliability-ha]$ oc exec long-load -- \

curl -s localhost:3000/health
Ok
2. Déclenchez le plantage du pod et observez que restartPolicy indique au cluster de le

recréer.
2.1. Observez que le pod est en cours d’exécution et qu’il n’a pas redémarré.
[student@workstation reliability-ha]$ oc get pods

long-load 1/1 Running 0 1m
2.2. Envoyez une demande au point d’accès /destruct dans l’application. Cette
demande déclenche le plantage du processus.

curl -s localhost:3000/destruct
command terminated with exit code 52
2.3. Observez que le pod est en cours d’exécution et qu’il a redémarré une fois.
DO180-OCP4.14-fr-2-20240530 383

long-load 1/1 Running 1 (34s ago) 4m16s
2.4. Supprimez le pod long-load.
[student@workstation reliability-ha]$ oc delete pod long-load

pod "long-load" deleted
Le pod n’est pas recréé, car il a été créé manuellement, et non via une ressource de
charge de travail telle qu’un déploiement.
3. Utilisez une politique de redémarrage Never pour créer le pod et notez qu’il n’est pas
recréé lors du plantage.
3.1. Modifiez le fichier long-load.yaml de sorte que restartPolicy soit défini sur
Never.
3.2. Créez le pod avec le fichier YAML mis à jour.

3.3. Envoyez une demande au pod pour vérifier qu’il est en cours d’exécution et que
l’application répond.

Ok
3.4. Envoyez une demande au point d’accès /destruct dans l’application pour
provoquer son plantage.

curl -s localhost:3000/destruct
command terminated with exit code 52
3.5. Observez que le pod n’est pas redémarré et qu’il est dans un état d’erreur.

long-load 0/1 Error 0 2m36s
3.6. Supprimez le pod long-load.
[student@workstation reliability-ha]$ oc delete pod long-load

pod "long-load" deleted
384 DO180-OCP4.14-fr-2-20240530
4. Le cluster ne sait pas à quel moment l’application située à l’intérieur du pod est prête
à recevoir des demandes. Par conséquent, vous devez ajouter un délai de démarrage à
l’application. L’ajout de cette fonctionnalité à l’aide de sondes sera abordé au cours d’un
prochain exercice.
4.1. Mettez à jour le fichier long-load.yaml en ajoutant un délai de démarrage et

utilisez la politique de redémarrage Always. Définissez la variable START_DELAY sur
60 000 millisecondes (une minute) afin que le fichier ressemble à l’extrait suivant :
spec:
containers:
securityContext:
allowPrivilegeEscalation: false
name: long-load
env:
- name: START_DELAY
value: "60000"
Note
Bien que les nombres soient d’un type YAML valide, les variables d’environnement
doivent être transmises en tant que chaînes. La syntaxe YAML est également
sensible à l’indentation.
Pour ces raisons, assurez-vous que votre fichier apparaît exactement comme dans
l’exemple précédent.
4.2. Appliquez le fichier YAML pour créer le pod et passez à l’étape suivante dans la
minute qui suit.

4.3. Vérifiez l’état du pod dans la minute qui suit sa création. L’état indique « ready »
même si le pod n’est pas prêt. Essayez d’envoyer une demande à l’application et
observez qu’elle échoue.

long-load 1/1 Running 0 16s

app is still starting
4.4. Après avoir attendu une minute que l’application démarre, envoyez une autre
demande au pod pour vérifier qu’il est en cours d’exécution et qu’il répond.
DO180-OCP4.14-fr-2-20240530 385

Ok
5. Utilisez un déploiement pour augmenter le nombre de pods déployés. Notez que la

suppression des pods entraîne des pannes de service, même si le déploiement gère la
recréation des pods.
5.1. Examinez le fichier long-load-deploy.yaml qui définit un déploiement, un

service et une route. Le déploiement crée trois réplicas du pod d’application.
Dans chaque pod, une variable d’environnement START_DELAY est définie sur
15 000 millisecondes (15 secondes). Dans chaque pod, l’application répond qu’elle
n’est pas prête avant la fin du délai.
[student@workstation reliability-ha]$ cat long-load-deploy.yaml

spec:
containers:
name: long-load
env:
- name: START_DELAY
value: "15000"
5.2. Démarrez le script de test de charge, qui envoie une demande au point d’accès de
l’API /health de l’application toutes les deux secondes. Laissez le script s’exécuter
dans une fenêtre de terminal visible.
[student@workstation reliability-ha]$ ./load-test.sh

5.3. Dans une nouvelle fenêtre de terminal, appliquez le fichier ~/DO180/labs/

reliability-ha/long-load-deploy.yaml.
[student@workstation ~]$ oc apply -f \

~/DO180/labs/reliability-ha/long-load-deploy.yaml
deployment.apps/long-load created
service/long-load created
route.route.openshift.io/long-load created
5.4. Observez la sortie du script de test de charge au démarrage des pods et des
instances de l’application. Après un certain délai, les demandes aboutissent.
Ok
Ok
Ok
386 DO180-OCP4.14-fr-2-20240530
5.5. En utilisant le point d’accès de l’API /togglesick de l’application, placez l’un des
trois pods dans l’état « Broken ».
[student@workstation ~]$ curl \

long-load-reliability-ha.apps.ocp4.example.com/togglesick
no output expected
5.6. Observez la sortie du script de test de charge lorsque certaines demandes

commencent à échouer. À cause de l’équilibreur de charge, l’ordre exact de la sortie
est aléatoire.
Ok
app is unhealthy
app is unhealthy
Ok
Ok
Appuyez sur Ctrl+C pour terminer le script de test de charge.
5.7. Revenez au répertoire /home/student/.
[student@workstation reliability-ha]$ cd /home/student/

Fin
[student@workstation ~]$ lab finish reliability-ha
DO180-OCP4.14-fr-2-20240530 387
Sondes d’intégrité des applications
Résultats
• Décrire comment Kubernetes utilise les sondes d’intégrité lors du déploiement, de la mise à
Sondes Kubernetes
Les sondes d’intégrité jouent un rôle important dans la préservation d’un cluster robuste. Les
sondes permettent au cluster de déterminer l’état d’une application en la sondant à plusieurs
reprises pour obtenir une réponse.
Un ensemble de sondes d’intégrité affecte la capacité d’un cluster à effectuer les tâches
suivantes :
• Atténuation des plantages en tentant automatiquement de redémarrer les pods en échec

• Basculement et équilibrage de charge en n’envoyant des demandes qu’aux pods sains
• Surveillance en déterminant les conditions d’échec des pods et à quel moment ils échouent
• Mise à l’échelle en déterminant quand un nouveau réplica est prêt à recevoir des demandes
Création des points d’accès des sondes

Les développeurs d’application doivent coder les points d’accès des sondes d’intégrité pendant
la phase de développement de l’application. Ces points d’accès déterminent l’intégrité et l’état
de l’application. Par exemple, une application pilotée par les données peut signaler une sonde
d’intégrité réussie uniquement si elle peut se connecter à la base de données.
Étant donné que le cluster les appelle souvent, les points d’accès des sondes d’intégrité doivent
être rapides. Les points d’accès ne doivent pas effectuer de requêtes de base de données
complexes ni de nombreux appels réseau.
Types de sondes
Kubernetes fournit les types de sondes suivants : Startup, Readiness et Liveness. En fonction de
l’application, vous pouvez configurer un ou plusieurs de ces types.
Sondes Readiness
Une sonde Readiness détermine si l’application est prête à traiter les demandes. Si la sonde
Readiness échoue, Kubernetes empêche le trafic client d’atteindre l’application en supprimant
l’adresse IP du pod de la ressource de service.
Les sondes Readiness permettent de détecter les problèmes temporaires susceptibles d’affecter
vos applications. Par exemple, il se peut que l’application soit temporairement indisponible
au démarrage, car elle doit établir les connexions initiales au réseau, charger des fichiers
dans un cache ou effectuer des tâches initiales qui prennent du temps. Il se peut également
que l’application doive, de temps à autre, exécuter de longues tâches par lots, ce qui la rend
temporairement indisponible pour les clients.
388 DO180-OCP4.14-fr-2-20240530
Kubernetes continue d’exécuter la sonde même après l’échec de l’application. Si la sonde réussit à
nouveau, Kubernetes ajoute l’adresse IP du pod à la ressource de service, et les demandes sont à
nouveau envoyées au pod.
Dans ce cas, la sonde Readiness résout un problème temporaire et améliore la disponibilité de

l’application.
Sondes Liveness
À l’instar de la sonde Readiness, la sonde Liveness est appelée pendant toute la durée de vie de
l’application. Les sondes Liveness déterminent si le conteneur de l’application est sain. Si la sonde
Liveness d’une application enregistre un certain nombre d’échecs d’activité, le cluster redémarre
le pod conformément à sa politique de redémarrage.
Contrairement aux sondes Startup, les sondes Liveness sont appelées après le processus de
démarrage initial de l’application. En règle générale, cette atténuation passe par le redémarrage
ou la recréation du pod.
Sondes Startup
Une sonde Startup détermine à quel moment le démarrage d’une application est terminé.
Contrairement à une sonde Liveness, une sonde Startup n’est pas appelée une fois la sonde
exécutée avec succès. Si la sonde Startup échoue après un délai d’expiration configurable, le pod
est redémarré en fonction de sa valeur restartPolicy.
Vous pouvez ajouter une sonde Startup aux applications dont la durée de démarrage est longue.
L’utilisation d’une sonde Startup permet à la sonde Liveness de rester courte et réactive.
Types de test
Lors de la définition d’une sonde, vous devez spécifier l’un des types de test suivants à effectuer :
HTTP GET
À chaque exécution de la sonde, le cluster envoie une demande au point d’accès HTTP
spécifié. Le test est considéré comme réussi si la demande répond avec un code de réponse
HTTP compris entre 200 et 399. D’autres réponses entraînent l’échec du test.
Commande de conteneur
À chaque exécution de la sonde, le cluster exécute la commande spécifiée dans le conteneur.
Si la commande se termine avec le code d’état 0, le test réussit. D’autres codes d’état
entraînent l’échec du test.
Socket TCP
À chaque exécution de la sonde, le cluster tente d’ouvrir un socket vers le conteneur. Le test
ne réussit que si la connexion est établie.
Horaires et seuils
Tous les types de sondes s’accompagnent de variables de minutage. La variable period seconds
(période en secondes) définit la fréquence d’exécution de la sonde. La variable failure threshold
(seuil d’échec) définit le nombre de tentatives infructueuses nécessaires avant l’échec de la sonde
proprement dite.
Par exemple, une sonde avec une variable « failure threshold » de 3 et une variable « period
seconds » de 5 peut échouer jusqu’à trois fois avant que la sonde globale échoue. L’utilisation
de cette configuration de sonde signifie que le problème peut se présenter pendant 10 secondes
DO180-OCP4.14-fr-2-20240530 389
avant d’être atténué. Cependant, l’exécution trop fréquente des sondes peut entraîner un
gaspillage des ressources. Tenez compte de ces valeurs lors de la définition de sondes.
Ajout de sondes via YAML

Étant donné que les sondes sont définies sur un modèle de pod, elles peuvent être ajoutées à
des ressources de charge de travail telles que des déploiements. Pour ajouter une sonde à un
déploiement existant, mettez à jour et appliquez le fichier YAML ou utilisez la commande oc
edit. Par exemple, l’extrait YAML suivant définit un modèle de pod de déploiement avec une
sonde :
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
containers:
- name: web-server
livenessProbe:
failureThreshold: 6
periodSeconds: 10
httpGet:
path: /health
port: 3000
Définit une sonde Liveness.
Indique le nombre d’échecs de la sonde avant l’atténuation du problème.
Définit la fréquence d’exécution de la sonde.
Définit la sonde en tant que demande HTTP, et définit le port et le chemin de la demande en
question.
Spécifie le chemin HTTP auquel envoyer la demande.
Spécifie le port sur lequel envoyer la demande HTTP.
Ajout de sondes via l’interface de ligne de commande

La commande oc set probe ajoute ou modifie une sonde sur un déploiement. Par exemple, la
commande suivante ajoute une sonde Readiness à un déploiement appelé front-end :
[user@host ~]$ oc set probe deployment/front-end \

--readiness \
--failure-threshold 6 \
--period-seconds 10 \
--get-url http://:8080/healthz
Définit une sonde Readiness.
Définit le nombre d’échecs de la sonde avant l’atténuation du problème.
390 DO180-OCP4.14-fr-2-20240530
Définit la fréquence d’exécution de la sonde.
Définit la sonde en tant que demande HTTP, et définit le port et le chemin de la demande en
question.
Ajout de sondes à l’aide de la console Web

Pour ajouter ou modifier une sonde sur un déploiement à partir de la console Web, accédez au
menu Workloads > Deployments et sélectionnez un déploiement.
Cliquez sur Actions, puis sur Add Health Checks.
Cliquez sur Edit probe pour spécifier le type de préparation, les en-têtes HTTP, le chemin d’accès,
le port, etc.
Note
La commande set probe est exclusive à RHOCP et oc.
DO180-OCP4.14-fr-2-20240530 391
Références
Configurer les Liveness, Readiness et Startup Probes
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-
readiness-startup-probes
Pour plus d’informations sur les sondes d’intégrité, reportez-vous au chapitre

Monitoring Application Health by Using Health Checks (Contrôle de l’intégrité des
applications à l’aide de bilans de santé) de la documentation Building Applications
(Compilation d’applications) de Red Hat OpenShift Container Platform 4.14,
index#application-health
392 DO180-OCP4.14-fr-2-20240530
Exercice guidé
Sondes d’intégrité des applications

Configurez des sondes d’intégrité dans un déploiement et vérifiez que les clients réseau sont
isolés des défaillances des applications.
Résultats
• Observer les problèmes potentiels avec une application qui n’est pas configurée avec des
sondes d’intégrité.
• Configurer les sondes Startup, Liveness et Readiness pour l’application.
Avant De Commencer
• Le projet reliability-probes existe.

• Le registre de la salle de classe contient l’image de conteneur long-load.
L’image de conteneur registry.ocp4.example.com:8443/redhattraining/long-

load:v1 contient une application avec des points d’accès d’utilitaire. Ces points d’accès
exécutent des tâches telles que l’arrêt brutal du processus et le basculement de l’état
d’intégrité du serveur.
[student@workstation ~]$ lab start reliability-probes
Instructions
1. En tant qu’utilisateur developer, déployez l’application long-load dans le projet
reliability-probes.

Login successful.
1.2. Définissez le projet reliability-probes comme projet actif.
[student@workstation ~]$ oc project reliability-probes

Now using project reliability-probes on server "https://
DO180-OCP4.14-fr-2-20240530 393
1.3. Appliquez le fichier long-load-deploy.yaml pour créer le pod. Passez à l’étape

suivante dans la minute qui suit.

~/DO180/labs/reliability-probes/long-load-deploy.yaml
1.4. Vérifiez que les pods mettent plusieurs minutes à démarrer en adressant une
demande à un pod dans le déploiement.
[student@workstation ~]$ oc exec deploy/long-load -- \

app is still starting
1.5. Vérifiez que les pods sont listés comme étant prêts même si l’application ne l’est pas.

long-load-8564d998cc-579nx 1/1 Running 0 30s
long-load-8564d998cc-ttqpg 1/1 Running 0 30s
long-load-8564d998cc-wjtfw 1/1 Running 0 30s
2. Ajoutez une sonde Startup aux pods afin que le cluster sache quand ils sont prêts.
2.1. Modifiez le fichier YAML ~/DO180/labs/reliability-probes/long-load-

deploy.yaml en définissant une sonde Startup. La sonde s’exécute toutes les
trois secondes et déclenche un pod comme ayant échoué après 30 tentatives
infructueuses. Le fichier doit correspondre à l’extrait suivant :
spec:
template:
spec:
containers:
name: long-load
startupProbe:
failureThreshold: 30
periodSeconds: 3
httpGet:
path: /health
port: 3000
env:
2.2. Appliquez le fichier long-load-deploy.yaml mis à jour.
394 DO180-OCP4.14-fr-2-20240530
[student@workstation ~] oc apply -f \
deployment.apps/long-load configured
service/long-load unchanged
route.route.openshift.io/long-load configured
2.3. Notez que les pods n’apparaissent pas comme étant prêts tant que l’application
n’est pas prête et que la sonde Startup n’a pas réussi. Attendez que les trois pods
atteignent l’état Ready. Appuyez sur Ctrl+c pour arrêter la commande watch.
[student@workstation ~]$ watch oc get pods

Every 2.0s: oc get pods

long-load-785b5b4fc8-7x5ln 1/1 Running 0 90s
long-load-785b5b4fc8-f7pdk 1/1 Running 0 90s
long-load-785b5b4fc8-r2nqj 1/1 Running 0 90s
3. Ajoutez une sonde Liveness pour redémarrer les instances interrompues de l’application.
3.1. Démarrez le script de test de charge.
[student@workstation ~]$ ~/DO180/labs/reliability-probes/load-test.sh

Ok
Ok
Ok
Laissez le script s’exécuter dans une fenêtre de terminal visible.
3.2. Dans une nouvelle fenêtre de terminal, utilisez le point d’accès /togglesick pour
rendre l’un des pods défectueux. Passez à l’étape suivante dans la minute qui suit.
[student@workstation ~]$ oc exec \

deploy/long-load -- curl -s localhost:3000/togglesick
no output expected
La fenêtre de test de charge commence à afficher app is unhealthy. Étant

donné qu’un seul pod est défectueux, les pods restants répondent toujours avec Ok.
3.3. Mettez à jour le fichier ~/DO180/labs/reliability-probes/long-load-

deploy.yaml pour ajouter une sonde Liveness. La sonde s’exécute toutes les
trois secondes et déclenche le pod comme ayant échoué après trois tentatives
infructueuses. Modifiez l’objet spec.template.spec.containers dans le fichier
pour qu’il corresponde à l’extrait suivant.
spec:
template:
spec:
containers:
DO180-OCP4.14-fr-2-20240530 395
startupProbe:
failureThreshold: 30
periodSeconds: 3
httpGet:
path: /health
port: 3000
livenessProbe:
failureThreshold: 3
periodSeconds: 3
httpGet:
path: /health
port: 3000
env:
3.4. Réduisez la taille (scale-down) du déploiement sur zéro réplica.
[student@workstation ~]$ oc scale deploy/long-load --replicas 0

deployment.apps/long-load scaled
Le script de test de charge indique que l’application n’est pas disponible.
Note
Red Hat recommande de réduire une application à zéro réplica avant d’apporter
plusieurs modifications à un déploiement, telles que l’ajout de sondes d’intégrité,
de demandes de ressources ou de variables d’environnement. La réduction à zéro
réplica empêche la création de pods et permet aux pods de s’arrêter correctement
une fois toutes les demandes en cours terminées.
Pour les mises à jour de déploiement multiples, la réduction à zéro empêche un

journal d’événements bruyant de Kubernetes de répondre à chaque modification, et
permet de conserver les ressources du cluster.
3.5. Appliquez le fichier long-load-deploy.yaml modifié pour mettre à jour le

déploiement, ce qui déclenche la recréation des pods par le déploiement.

route.route.openshift.io/long-load configured
3.6. Attendez que les trois pods atteignent l’état Ready. Appuyez sur Ctrl+c pour arrêter
la commande watch.
396 DO180-OCP4.14-fr-2-20240530

Every 2.0s: oc get pods

long-load-785b5b4fc8-8x5ln 1/1 Running 0 70s
long-load-785b5b4fc8-f8pdk 1/1 Running 0 70s
long-load-785b5b4fc8-r9nqj 1/1 Running 0 70s
3.7. Attendez que la fenêtre de test de charge affiche Ok pour toutes les réponses, puis
basculez l’un des pods pour qu’il soit défectueux.

deploy/long-load -- curl -s localhost:3000/togglesick
no output expected
La fenêtre de test de charge peut afficher app is unhealthy plusieurs fois avant
que le pod ne soit redémarré.
3.8. Notez que le pod défectueux est redémarré après l’échec de la sonde Liveness. Une
fois le pod redémarré, la fenêtre de test de charge affiche uniquement Ok.

long-load-fbb7468d9-8xm8j 1/1 Running 0 9m42s
long-load-fbb7468d9-k66dm 1/1 Running 0 8m38s
long-load-fbb7468d9-ncxkh 0/1 Running 1 (11s ago) 10m
4. Ajoutez une sonde Readiness afin que le trafic ne soit acheminé que vers les pods prêts et
sains.
4.1. Réduisez la taille (scale-down) du déploiement sur zéro réplica.

4.2. Utilisez la commande oc set probe pour ajouter la sonde Readiness.
[student@workstation ~]$ oc set probe deploy/long-load \

--readiness --failure-threshold 1 --period-seconds 3 \
--get-url http://:3000/health
deployment.apps/long-load probes updated
4.3. Dimensionnez (scale-up) le déploiement sur trois réplicas.

4.4. Observez l’état des pods à l’aide d’une commande watch.
DO180-OCP4.14-fr-2-20240530 397

long-load-d5794d744-8hqlh 0/1 Running 0 48s
long-load-d5794d744-hphgb 0/1 Running 0 48s
long-load-d5794d744-lgkns 0/1 Running 0 48s
La commande ne se termine pas immédiatement, mais continue d’afficher les mises à

jour de l’état des pods. Laissez cette commande s’exécuter dans une fenêtre visible.
4.5. Attendez que les pods s’affichent comme étant prêts. Ensuite, dans une nouvelle
fenêtre de terminal, rendez l’un des pods défectueux pendant cinq secondes à l’aide
du points d’accès /hiccup.

deploy/long-load -- curl -s localhost:3000/hiccup?time=5
no output expected
La fenêtre d’état du pod indique que l’un des pods n’est plus prêt. Au bout de cinq
secondes, le pod est à nouveau sain et indique qu’il est prêt.
Il se peut que la fenêtre de test de charge affiche app is unhealthy une fois
avant que le pod ne soit défini comme « non prêt ». Une fois que le cluster a
déterminé que le pod n’était plus prêt, il arrête d’acheminer le trafic vers le pod
jusqu’à ce que celui-ci soit réparé ou que la sonde Liveness échoue. Le pod n’est
« malade » que pendant cinq secondes, mais cela suffit pour que la sonde Readiness
échoue, mais pas la sonde Liveness.
Note
Vous pouvez éventuellement répéter cette étape et observer les changements
d’état du pod temporairement « malade ».
4.6. Arrêtez les commandes d’état et de test de charge en appuyant sur Ctrl+c dans leur
fenêtre respective.
Fin
[student@workstation ~]$ lab finish reliability-probes
398 DO180-OCP4.14-fr-2-20240530
Réservation de capacité de calcul pour les

applications
Résultats
• Configurer une application avec des demandes de ressources afin que Kubernetes puisse
Planification des pods Kubernetes

Le planificateur de pods Red Hat OpenShift Container Platform (RHOCP) détermine le
placement des nouveaux pods sur les nœuds dans le cluster. L’algorithme du planificateur de pods
suit un processus en trois étapes :
Filtrage des nœuds

Un pod peut définir un sélecteur de nœud qui correspond aux étiquettes dans les nœuds du
cluster. Seules les étiquettes correspondantes sont éligibles.
De plus, le planificateur filtre la liste des nœuds en cours d’exécution en évaluant chacun d’eux
par rapport à un jeu de prédicats. Un pod peut définir des demandes de ressources pour des
ressources informatiques telles que le processeur, la mémoire et le stockage. Seuls les nœuds
disposant de suffisamment de ressources informatiques sont éligibles.
L’étape de filtrage réduit la liste des nœuds éligibles. Dans certains cas, le pod peut s’exécuter
sur n’importe lequel des nœuds. Dans d’autres, tous les nœuds sont filtrés, de sorte que
le pod ne peut pas être planifié tant qu’un nœud répondant aux conditions préalables
appropriées n’est pas disponible.
Si tous les nœuds sont filtrés, un événement FailedScheduling est généré pour le pod.
Définition de priorités dans la liste de nœuds filtrée

En utilisant plusieurs critères de priorité, le planificateur détermine une note pondérée pour
chaque nœud. Les nœuds ayant les notes les plus élevées sont les meilleurs candidats pour
exécuter le pod.
Sélection du nœud le plus adapté

La liste de candidats est triée en fonction de ces notes ; le nœud ayant la note la plus élevée
est sélectionné pour héberger le pod. Si plusieurs nœuds ont la même note élevée, l’un
d’eux est sélectionné à tour de rôle. Une fois qu’un hôte a été sélectionné, un événement
Scheduled est généré pour le pod.
Le planificateur est flexible et peut être personnalisé afin de répondre à des situations de
planification avancées. La personnalisation du planificateur n’entre pas dans le cadre de ce cours.
Calcul des demandes de ressources

Pour les applications qui nécessitent une quantité spécifique de ressources de calcul, vous pouvez
définir une demande de ressources dans la définition de pod de votre déploiement d’application.
Les demandes de ressources affectent des ressources matérielles pour le déploiement de
l’application.
DO180-OCP4.14-fr-2-20240530 399
Les demandes de ressources précisent les ressources de calcul minimales requises pour planifier
un pod. Le planificateur essaie de trouver un nœud ayant suffisamment de ressources de calcul
pour satisfaire les demandes du pod.
Dans Kubernetes, les ressources mémoire sont mesurées en octets, tandis que les ressources
processeur (CPU) sont mesurées en unités processeur. Les unités processeur sont allouées en
utilisant des unités millicore. Un millicore est un cœur de processeur, virtuel ou physique, divisé
en 1 000 unités. Une valeur de demande de "1000 m" alloue un cœur de processeur en entier
à un pod. Vous pouvez également utiliser des valeurs fractionnaires pour allouer des ressources
processeur. Par exemple, vous pouvez définir la demande de ressources processeur sur une valeur
0.1, ce qui représente 100 millicores (100 m). De même, une demande de ressources processeur
avec une valeur 1.0 représente un processeur en entier ou 1 000 millicores (1000 m).
Vous pouvez définir des demandes de ressources pour chaque conteneur dans un déploiement ou
une ressource configuration de déploiement. Si les ressources ne sont pas définies, la spécification
du conteneur affiche une ligne resources: {}.
Dans votre déploiement, modifiez la ligne resources: {} afin de spécifier les demandes
choisies. L’exemple suivant définit une demande de ressource de 100 millicores (100 m) de
processeur et d’un gigaoctet (1 Gi) de mémoire.
spec:
containers:
- image: quay.io/redhattraining/hello-world-nginx:v1.0
name: hello-world-nginx
resources:
requests:
cpu: "100m"
memory: "1Gi"
Si vous utilisez la commande edit pour modifier un déploiement ou une configuration de

déploiement, assurez-vous d’utiliser la bonne mise en retrait. Les erreurs de mise en retrait
peuvent entraîner le refus de l’éditeur d’enregistrer les modifications. Vous pouvez également
utiliser la commande set resources fournie par les commandes kubectl et oc afin de
spécifier des demandes de ressources. La commande suivante définit les mêmes demandes que
dans l’exemple précédent :
[user@host ~]$ oc set resources deployment hello-world-nginx \

--requests cpu=10m,memory=1gi
La commande set resource fonctionne avec toutes les ressources qui incluent un modèle de
pod, comme les déploiements et les ressources de tâche.
Inspection des ressources de calcul du cluster

Les administrateurs du cluster peuvent afficher les ressources de calcul disponibles et utilisées
d’un nœud. Par exemple, en tant qu’administrateur du cluster, vous pouvez utiliser la commande
describe node pour déterminer la capacité des ressources de calcul d’un nœud. La commande
affiche la capacité du nœud ainsi que la part de cette capacité qui peut être allouée. Elle affiche
également la quantité de ressources allouées et demandées sur le nœud.
400 DO180-OCP4.14-fr-2-20240530
[user@host ~]$ oc describe node master01

Name: master01
Roles: control-plane,master,worker
Capacity:
cpu: 8
ephemeral-storage: 125293548Ki
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 20531668Ki
pods: 250
Allocatable:
cpu: 7500m
ephemeral-storage: 114396791822
hugepages-1Gi: 0
hugepages-2Mi: 0
memory: 19389692Ki
pods: 250
Non-terminated Pods: (88 in total)
... Name CPU Requests CPU Limits Memory Requests Memory Limits ...
... ---- ------------ ---------- --------------- -------------
... controller-... 10m (0%) 0 (0%) 20Mi (0%) 0 (0%) ...
... metallb-... 50m (0%) 0 (0%) 20Mi (0%) 0 (0%) ...
... metallb-... 0 (0%) 0 (0%) 0 (0%) 0 (0%) ...
-------- -------- ------
cpu 3183m (42%) 1202m (16%)
memory 12717Mi (67%) 1350Mi (7%)
Les administrateurs d’un cluster RHOCP peuvent également utiliser la commande oc adm top
pods. Elle affiche l’utilisation des ressources de calcul pour chaque pod d’un projet. Vous devez
inclure les options --namespace ou -n pour spécifier un projet. Sinon, la commande renvoie
l’utilisation des ressources pour les pods du projet actuellement sélectionné.
La commande suivante affiche l’utilisation des ressources pour les pods dans le projet
openshift-dns :
[user@host ~]$ oc adm top pods -n openshift-dns

NAME CPU(cores) MEMORY(bytes)
dns-default-5kpn5 1m 33Mi
node-resolver-6kdxp 0m 2Mi
De plus, les administrateurs de cluster peuvent utiliser la commande oc adm top node pour
afficher l’utilisation des ressources d’un nœud de cluster. Incluez le nom du nœud pour afficher
l’utilisation des ressources d’un nœud en particulier.
DO180-OCP4.14-fr-2-20240530 401
[user@host ~]$ oc adm top node master01

master01 1250m 16% 10268Mi 54%
Références
Pour plus d’informations sur la planification des pods, reportez-vous au chapitre
Controlling Pod Placement onto Nodes (Scheduling) de la documentation Nodes de
Red Hat Open Shift Container Platform 4.14, disponible à l’adresse
openshift_container_platform/4.14/html-single/nodes/index#controlling-pod-
placement-onto-nodes-scheduling
402 DO180-OCP4.14-fr-2-20240530
Exercice guidé
Réservation de capacité de calcul pour les

applications
Configurez une application avec des demandes de ressources de calcul qui autorisent et
empêchent une planification et une évolutivité réussies de ses pods.
Résultats
• Observer que les demandes de ressources mémoire allouent de la mémoire au nœud de
cluster.
• Déterminer dans quelle mesure l’ajustement des demandes de ressources a une incidence
sur le nombre de réplicas qui peuvent être planifiés sur un nœud.
Avant De Commencer
• Le projet reliability-requests existe.

• Le registre de la salle de classe contient l’image de conteneur
registry.ocp4.example.com:8443/redhattraining/long-load:v1.
L’image de conteneur registry.ocp4.example.com:8443/redhattraining/long-

load:v1 contient une application avec des points d’accès d’utilitaire. Ces points d’accès
exécutent des tâches telles que l’arrêt brutal du processus et le basculement de l’état
d’intégrité du serveur.
[student@workstation ~]$ lab start reliability-requests
Instructions
1. En tant qu’utilisateur admin, déployez l’application long-load en appliquant le fichier
long-load-deploy.yaml dans le projet reliability-requests.

Login successful.
DO180-OCP4.14-fr-2-20240530 403
Note
En règle générale, vous utilisez les comptes ayant les moindres privilèges requis
pour effectuer une tâche. Dans l’environnement de formation, ce compte
correspond à l’utilisateur developer. Cependant, des privilèges d’administrateur
de cluster sont requis pour afficher les métriques du nœud de cluster dans cet
exercice.
1.2. Affichez l’allocation de demande de mémoire totale pour le nœud.
[student@workstation ~]$ oc describe node master01

-------- -------- ------
cpu 3158m (42%) 980m (13%)
memory 12667Mi (66%) 1250Mi (6%)
La sortie de la commande montre que les pods en cours d’exécution sur le nœud
ont demandé un total de 12 667 Mio de mémoire. La valeur peut être légèrement
différente sur votre système.
Important
Compte tenu des projets et des objets des exercices précédents, il se peut que
l’utilisation de la mémoire de cet exercice ne corresponde pas aux résultats
escomptés. Supprimez tous les projets non liés avant de continuer.
Si vous rencontrez toujours des problèmes, recréez l’environnement de formation et

effectuez à nouveau cet exercice.
1.3. Sélectionnez le projet reliability-requests.
[student@workstation ~]$ oc project reliability-requests

Now using project "reliability-requests" on server "https://
1.4. Accédez au répertoire ~/DO180/labs/reliability-requests. Créez un

déploiement, un service et une route à l’aide de la commande oc apply et du fichier
long-load-deploy.yaml.
[student@workstation ~]$ cd DO180/labs/reliability-requests

[student@workstation reliability-requests]$ oc apply -f long-load-deploy.yaml
2. Ajoutez une demande de ressource à la définition du pod et mettez à l’échelle le

déploiement au-delà de la capacité du cluster.
404 DO180-OCP4.14-fr-2-20240530
2.1. Modifiez le fichier long-load-deploy.yaml en ajoutant une demande de

ressource. La demande alloue un gibioctet (1 Gio) à chacun des pods d’application.
spec:
template:
spec:
containers:
resources:
requests:
memory: 1Gi
2.2. Appliquez le fichier YAML pour modifier le déploiement avec la demande de

ressource.
[student@workstation reliability-requests]$ oc apply -f long-load-deploy.yaml

route.route.openshift.io/long-load unchanged
2.3. Mettez à l’échelle le déploiement pour qu’il comporte 10 réplicas.
[student@workstation reliability-requests]$ oc scale deploy/long-load \

--replicas 10
2.4. Notez que le cluster ne peut pas planifier l’ensemble des pods sur le nœud unique.
Les pods dont l’état est Pending ne peuvent pas être planifiés.
[student@workstation reliability-requests]$ oc get pods

long-load-86bb4b79f8-44zwd 0/1 Pending 0 58s
2.5. Récupérez le journal des événements du cluster et notez que l’échec de la

planification est dû à une mémoire insuffisante.
[student@workstation reliability-requests]$ oc get events \

--field-selector reason="FailedScheduling"
...output omitted... pod/long-load-86bb4b79f8-44zwd 0/1 nodes are available:
1 Insufficient memory. ...output omitted...
2.6. Vous pouvez également afficher les événements d’un pod en attente pour en
connaître la raison. Dans la commande suivante, remplacez le nom du pod par l’un des
pods en attente de votre salle de classe.
DO180-OCP4.14-fr-2-20240530 405
[student@workstation reliability-requests]$ oc describe \

pod/long-load-86bb4b79f8-44zwd
Events:
...output omitted... 0/1 nodes are available: 1 Insufficient memory. ...output
omitted...
2.7. Notez que l’utilisation de la mémoire demandée du nœud est élevée.
[student@workstation reliability-requests]$ oc describe node master01

-------- -------- ------
cpu 3158m (42%) 980m (13%)
memory 18811Mi (99%) 1250Mi (6%)
La sortie de la commande montre que les pods du déploiement long-load ont

demandé la plus grande partie de la mémoire restante du nœud. Cependant, la
mémoire disponible est insuffisante pour accueillir les 10 réplicas.
3. Réduisez la mémoire demandée par pod de sorte que les réplicas puissent s’exécuter sur le
nœud.
3.1. Définissez manuellement la demande de ressources sur 250Mi.
[student@workstation reliability-requests]$ oc set resources deploy/long-load \

--requests memory=250Mi
deployment.apps/long-load resource requirements updated
3.2. Supprimez les pods pour qu’ils soient recréés avec la nouvelle demande de
ressources.
[student@workstation reliability-requests]$ oc delete pod -l app=long-load

pod "long-load-557b4d94f5-29brx" deleted
3.3. Notez que tous les pods peuvent démarrer avec la demande de mémoire réduite.
En l’espace d’une minute, les pods sont marqués comme Ready et dans un état
Running, sans aucun pod avec l’état Pending.
[student@workstation reliability-requests]$ oc get pods

long-load-557b4d94f5-68hbb 1/1 Running 0 3m14s
long-load-557b4d94f5-bfk7c 1/1 Running 0 3m21s
long-load-557b4d94f5-bnpzh 1/1 Running 0 3m21s
long-load-557b4d94f5-chtv9 1/1 Running 0 3m21s
long-load-557b4d94f5-drg2p 1/1 Running 0 3m14s
long-load-557b4d94f5-hwsz6 1/1 Running 0 3m12s
long-load-557b4d94f5-k5vqj 1/1 Running 0 3m21s
406 DO180-OCP4.14-fr-2-20240530
long-load-557b4d94f5-lgstq 1/1 Running 0 3m21s

long-load-557b4d94f5-r8hq4 1/1 Running 0 3m21s
long-load-557b4d94f5-xrg7c 1/1 Running 0 3m21s
3.4. Notez que l’utilisation de la mémoire du nœud est plus faible.
[student@workstation reliability-requests]$ oc describe node master01

-------- -------- ------
cpu 3158m (42%) 980m (13%)
memory 15167Mi (80%) 1250Mi (6%)
3.5. Revenez au répertoire /home/student/.
[student@workstation reliability-requests]$ cd /home/student/

Fin
[student@workstation ~]$ lab finish reliability-requests
DO180-OCP4.14-fr-2-20240530 407
Limitation de la capacité de calcul pour

les applications
Résultats
• Configurer une application avec des limites de ressources afin que Kubernetes puisse en
Les demandes de mémoire et de processeur que vous définissez pour les conteneurs aident
Red Hat OpenShift Container Platform (RHOCP) à sélectionner un nœud de calcul pour
l’exécution de vos pods. Cependant, ces demandes de ressources ne limitent pas la mémoire ni
le processeur que les conteneurs peuvent utiliser. Par exemple, la définition d’une demande de
mémoire à 1 Gio n’empêche pas le conteneur d’utiliser davantage de mémoire.
Red Hat vous recommande de définir les demandes de mémoire et de processeur sur l’utilisation
maximale de votre application. En revanche, en définissant des valeurs plus basses, vous
surchargez les ressources du nœud. Si toutes les applications qui s’exécutent sur le nœud
commencent à utiliser des ressources supérieures aux valeurs demandées, il se peut que les
nœuds de calcul manquent de mémoire et de ressources processeur.
Outre les demandes, vous pouvez définir des limites de mémoire et de processeur pour éviter que
vos applications n’utilisent trop de ressources.
Définition des limites de mémoire

Une limite de mémoire spécifie la quantité de mémoire qu’un conteneur peut utiliser pour tous ses
processus.
Dès que le conteneur atteint cette limite, le nœud de calcul sélectionne puis supprime un
processus du conteneur. Lorsque cet événement se produit, RHOCP détecte que l’application ne
fonctionne plus, étant donné que le processus de conteneur principal est manquant ou parce que
les sondes d’intégrité signalent une erreur. RHOCP redémarre alors le conteneur en fonction de
l’attribut restartPolicy du pod, dont la valeur par défaut est Always.
RHOCP s’appuie sur les fonctions du noyau Linux pour implémenter les limites de ressources et
pour supprimer les processus dans les conteneurs qui atteignent leurs limites de mémoire :
Groupes de contrôles (cGroups)

RHOCP utilise des groupes de contrôle pour implémenter des limites de ressources. Les
groupes de contrôle constituent un mécanisme du noyau Linux permettant de contrôler et de
surveiller les ressources du système, telles que le processeur et la mémoire.
Out-of-Memory Killer (OOM Killer)

Lorsqu’un conteneur atteint sa limite de mémoire, le noyau Linux déclenche le sous-système
OOM Killer pour sélectionner, puis supprimer un processus.
Vous devez définir une limite de mémoire lorsque l’application comporte un modèle d’utilisation
de la mémoire que vous devez atténuer ; lorsque l’application présente une fuite de mémoire, par
exemple. Une fuite de mémoire est un bogue d’application qui se produit lorsque l’application
utilise de la mémoire, mais ne la libère pas après utilisation. Si la fuite apparaît dans une boucle
de service infinie, l’application utilise de plus en plus de mémoire au fil du temps et peut finir
par épuiser toute la mémoire disponible sur le système. Dans ce cas, la définition d’une limite
de mémoire empêche les applications de consommer toute la mémoire du nœud. La limite de
408 DO180-OCP4.14-fr-2-20240530
mémoire permet également à OpenShift de redémarrer régulièrement les applications pour

qu’elles libèrent leur mémoire lorsqu’elles atteignent la limite.
Pour définir une limite de mémoire pour le conteneur dans un pod, utilisez la commande oc set
resources :
[user@host ~]$ oc set resources deployment/hello --limits memory=1Gi
En plus de la commande oc set resources, vous pouvez définir des limites de ressources à
partir d’un fichier au format YAML :
apiVersion: apps/v1
kind: Deployment
spec:
containers:
- image: registry.access.redhat.com/ubi9/nginx-120:1-86
name: hello
resources:
requests:
cpu: 100m
memory: 500Mi
limits:
cpu: 200m
memory: 1Gi
Lorsque RHOCP redémarre un pod en raison d’un événement de mémoire insuffisante (OOM), il
met à jour l’attribut lastState du pod et définit la raison sur OOMKilled :
[user@host ~]$ oc get pod hello-67645f4865-vvr42 -o yaml

status:
containerStatuses:
- containerID: cri-o://806b...9fe7
image: registry.access.redhat.com/ubi9/nginx-120:1-86
imageID: registry.access.redhat.com/ubi9/nginx-120:1-86@sha256:1403...fd34
lastState:
terminated:
containerID: cri-o://bbc4...9eb2
exitCode: 137
finishedAt: "2023-03-08T07:56:06Z"
reason: OOMKilled
startedAt: "2023-03-08T07:51:43Z"
name: hello
ready: true
restartCount: 1
Pour définir une limite de mémoire pour le conteneur dans un pod à partir de la console Web,
sélectionnez un déploiement, puis cliquez sur Actions > Edit resource limits.
DO180-OCP4.14-fr-2-20240530 409
Définissez des limites de mémoire en augmentant ou en diminuant la mémoire dans la section

Limit.
Définition de limites de processeur

Les limites de processeur fonctionnent différemment des limites de mémoire. Lorsque le
conteneur atteint la limite de processeur, RHOCP inhibe ses processus, même si des cycles
de processeur sont disponibles sur le nœud. L’application continue de fonctionner, mais plus
lentement.
410 DO180-OCP4.14-fr-2-20240530
En revanche, si vous ne définissez pas de limite de processeur, le conteneur peut consommer

autant de ressources processeur qu’il y en a sur le nœud. Si le processeur du nœud est sous
pression (par exemple, parce que plusieurs conteneurs exécutent des tâches qui consomment
beaucoup de ressources processeur), le noyau Linux partage la ressource processeur entre tous
ces conteneurs, en fonction de la valeur CPU Requests (Demandes de processeur) définie pour
les conteneurs.
Vous devez définir une limite de processeur lorsque vous avez besoin d’un comportement
d’application cohérent entre les clusters et les nœuds. Par exemple, si l’application s’exécute sur
un nœud sur lequel le processeur est disponible, elle peut s’exécuter à pleine vitesse. En revanche,
si l’application s’exécute sur un nœud soumis à une pression du processeur, elle s’exécute plus
lentement.
Le même comportement peut se présenter entre vos clusters de développement et de

production. Étant donné que les deux environnements peuvent avoir des configurations de nœud
différentes, il se peut que l’application s’exécute différemment lorsque vous la faites passer du
développement à la production.
Note
Les clusters peuvent présenter des différences de configuration matérielle au-
delà des limites observées. Par exemple, les nœuds de deux clusters peuvent avoir
des processeurs avec un nombre de cœurs identique et des vitesses d’horloge
différentes.
Les demandes et les limites ne tiennent pas compte de ces différences matérielles.
Si vos clusters diffèrent à cet égard, veillez à ce que les demandes et les limites
soient appropriées pour les deux configurations.
La définition d’une limite de processeur vous permet d’atténuer les différences entre la
configuration des nœuds et d’obtenir un comportement plus cohérent.
Pour définir une limite de processeur pour le conteneur dans un pod, utilisez la commande oc set
resources :
[user@host ~]$ oc set resources deployment/hello --limits cpu=200m
Vous pouvez également définir des limites de processeur à partir d’un fichier au format YAML :
apiVersion: apps/v1
kind: Deployment
spec:
containers:
name: hello
resources:
requests:
cpu: 100m
memory: 500Mi
limits:
cpu: 200m
memory: 1Gi
DO180-OCP4.14-fr-2-20240530 411
Pour définir une limite de processeur pour le conteneur dans un pod à partir de la console Web,
sélectionnez un déploiement, puis cliquez sur Actions > Edit resource limits.
Définissez des limites de processeur en augmentant ou en diminuant le processeur dans la section

Limit.
Affichage des demandes, des limites et de l’utilisation

réelle
En utilisant l’interface de ligne de commande RHOCP, les administrateurs de cluster peuvent
afficher des informations sur l’utilisation des calculs sur des nœuds individuels. La commande oc
describe node affiche des informations détaillées sur un nœud, notamment des informations
412 DO180-OCP4.14-fr-2-20240530
sur les pods en cours d’exécution sur le nœud. Pour chaque pod, elle affiche les demandes et les
limites processeur, ainsi que les demandes et les limites de mémoire. Si vous ne spécifiez pas de
demande ni de limite, le pod affiche un zéro pour cette colonne. La commande affiche également
un résumé de toutes les limites et demandes de ressources.
[user@host ~]$ oc describe node master01

Name: master01
Roles: control-plane,master,worker
Non-terminated Pods: (88 in total)
... Name CPU Requests CPU Limits Memory Requests Memory Limits ...
... ---- ------------ ---------- --------------- -------------
... controller-... 10m (0%) 0 (0%) 20Mi (0%) 0 (0%) ...
... metallb-... 50m (0%) 0 (0%) 20Mi (0%) 0 (0%) ...
... metallb-... 0 (0%) 0 (0%) 0 (0%) 0 (0%) ...
-------- -------- ------
cpu 3183m (42%) 1202m (16%)
memory 12717Mi (67%) 1350Mi (7%)
La commande oc describe node affiche les demandes et les limites. La commande oc adm
top affiche l’utilisation des ressources. La commande oc adm top nodes affiche l’utilisation
des ressources pour les nœuds du cluster. Vous devez exécuter cette commande en tant
qu’administrateur du cluster.
La commande oc adm top pods affiche l’utilisation des ressources pour chaque pod d’un
projet.
La commande suivante affiche l’utilisation des ressources pour les pods du projet en cours :
[user@host ~]$ oc adm top pods -n openshift-console

hello-67645f4865-vvr42 121m 309Mi
intradb-6f8d7cfffb-fz55b 0m 440Mi
Pour visualiser la consommation de ressources à partir de la console Web, sélectionnez un

déploiement, puis cliquez sur l’onglet Metrics. À partir de cet onglet, vous pouvez afficher
l’utilisation de la mémoire, du processeur, du système de fichiers et du trafic entrant et sortant.
DO180-OCP4.14-fr-2-20240530 413
Références
Page de manuel (7)cgroups
Pour plus d’informations sur les limites de ressources, reportez-vous à la section

Configuring Cluster Memory to Meet Container Memory and Risk Requirements du
chapitre Working with Clusters de la documentation Nodes de Red Hat OpenShift
openshift_container_platform/4.14/html-single/nodes/index#nodes-cluster-
resource-configure
414 DO180-OCP4.14-fr-2-20240530
Exercice guidé
Limitation de la capacité de calcul pour

les applications
Configurez une application avec des limites de ressources de calcul qui permettent et
empêchent une exécution réussie des pods.
Résultats
Vous serez en mesure de surveiller l’utilisation de la mémoire d’une application et de définir
une limite de mémoire pour un pod.
Avant De Commencer
Cette commande permet de s’assurer que toutes les ressources sont disponibles
pour cet exercice. Elle crée également le projet reliability-limits et le fichier /
home/student/DO180/labs/reliability-limits/resources.txt. Le fichier
resources.txt contient certaines commandes que vous utiliserez au cours de l’exercice.
Vous pouvez utiliser ce fichier pour copier et coller ces commandes.
[student@workstation ~]$ lab start reliability-limits
Instructions
passe developer. Utilisez le projet reliability-limits.

Login successful.
1.2. Définissez le projet reliability-limits comme projet actif.
[student@workstation ~]$ oc project reliability-limits

2. Créez le déploiement leakapp à partir du fichier ~/DO180/labs/reliability-

limits/leakapp.yml que la commande lab a préparé. L’application comporte un bogue
et perd 1 Mio de mémoire chaque seconde.
DO180-OCP4.14-fr-2-20240530 415
2.1. Examinez le fichier de ressources ~/DO180/labs/reliability-limits/

leakapp.yml. La limite de mémoire est définie sur 35 Mio. Ne modifiez pas le
fichier.
resources:
requests:
memory: 20Mi
limits:
memory: 35Mi
2.2. Utilisez la commande oc apply pour créer l’application. Ignorez le message

d’avertissement.

~/DO180/labs/reliability-limits/leakapp.yml
deployment.apps/leakapp created
2.3. Attendez que le pod démarre. Vous devrez peut-être exécuter la commande à
plusieurs reprises pour que le pod signale l’état Running. Il est probable que le nom
du pod soit différent sur votre système.

leakapp-99bb64c8d-hk26k 1/1 Running 0 12s
3. Observez le pod. OpenShift redémarre le pod après 30 secondes.
3.1. Utilisez la commande watch pour surveiller la commande oc get pods. Attendez
qu’OpenShift redémarre le pod, puis appuyez sur Ctrl+C pour quitter la commande
watch.

Every 2.0s: oc get pods workstation: Wed Mar 8 07:27:45 2023

leakapp-99bb64c8d-hk26k 1/1 Running 1 (15s ago) 48s
3.2. Récupérez l’état du conteneur pour vérifier qu’OpenShift a redémarré le pod à la

suite d’un événement de mémoire insuffisante (OOM).
[student@workstation ~]$ oc get pods leakapp-99bb64c8d-hk26k \

-o jsonpath='{.status.containerStatuses[0].lastState}' | jq .
{
"terminated": {
"containerID": "cri-o://5800...1d04",
"exitCode": 137,
"finishedAt": "2023-03-08T12:29:24Z",
"reason": "OOMKilled",
"startedAt": "2023-03-08T12:28:53Z"
}
}
416 DO180-OCP4.14-fr-2-20240530
4. Observez l’état du pod pendant quelques minutes, jusqu’à ce que l’état

CrashLoopBackOff s’affiche. Au cours de cette période, OpenShift redémarre plusieurs
fois le pod en raison de la fuite de mémoire.
Entre chaque redémarrage, OpenShift définit l’état du pod sur CrashLoopBackOff,
observe un délai d’attente de plus en plus long entre les nouvelles tentatives, puis
redémarre le pod. Le délai entre les redémarrages offre à l’opérateur la possibilité de
résoudre le problème.
Après plusieurs tentatives, OpenShift définit enfin le temporisateur d’attente
CrashLoopBackOff sur cinq minutes. Pendant cette période d’attente, l’application n’est
pas disponible pour vos clients.


leakapp-99bb64c8d-hk26k 0/1 CrashLoopBackOff 4 (82s ago) 5m25s
Appuyez sur Ctrl+C pour quitter la commande watch.
5. La réparation de la fuite de mémoire permettrait de résoudre le problème. Cependant, la

correction du bogue peut demander un certain temps aux développeurs. En attendant,
définissez la limite de mémoire sur 600 Mio. Ce paramètre permet au pod de s’exécuter
pendant dix minutes avant que l’application n’atteigne la limite.
5.1. Utilisez la commande oc set resources pour définir la nouvelle limite. Ignorez le
message d’avertissement.
[student@workstation ~]$ oc set resources deployment/leakapp \

--limits memory=600Mi
deployment.apps/leakapp resource requirements updated

leakapp-6bc64dfcd-86fpc 1/1 Running 0 12s
5.3. Attendez deux minutes pour vérifier qu’OpenShift ne redémarre plus le pod toutes
les 30 secondes.


leakapp-6bc64dfcd-86fpc 1/1 Running 0 3m12s
6. Examinez la mémoire consommée par le pod. Vous devrez peut-être exécuter la

commande à plusieurs reprises pour que les métriques soient disponibles. Il est probable
que l’utilisation de la mémoire soit différente sur votre système.
DO180-OCP4.14-fr-2-20240530 417
[student@workstation ~]$ oc adm top pods

leakapp-6bc64dfcd-86fpc 0m 174Mi
7. Facultatif. Attendez environ 10 minutes à partir de l’heure de création, jusqu’à ce

que l’application atteigne l’état d’erreur de mémoire insuffisante. Après cette période,
OpenShift redémarre le pod, car il a atteint la limite de mémoire définie de 600 Mio.
7.1. Ouvrez une nouvelle fenêtre de terminal, puis exécutez la commande watch pour
surveiller la commande oc adm top pods.
[student@workstation ~]$ watch oc adm top pods

Every 2.0s: oc adm top pods workstation: Wed Mar 8 07:38:55 2023

leakapp-6bc64dfcd-86fpc 0m 176Mi
Laissez la commande s’exécuter et ne l’interrompez pas.
Note
Il se peut qu’un message s’affiche pour indiquer que les métriques ne sont pas
encore disponibles. Si tel est le cas, attendez encore un peu avant de réessayer.
7.2. Dans le premier terminal, exécutez la commande watch pour surveiller la commande
oc get pods. Observez la sortie de la commande oc adm top pods dans le
deuxième terminal. Lorsque l’utilisation de la mémoire atteint 600 Mio, le sous-
système OOM supprime le processus à l’intérieur du conteneur et OpenShift
redémarre le pod.


leakapp-6bc64dfcd-86fpc 1/1 Running 1 (3s ago) 9m58s
7.3. Appuyez sur Ctrl+C pour quitter la commande watch dans le deuxième terminal.
Fermez ce deuxième terminal lorsque vous avez terminé.
Fin
[student@workstation ~]$ lab finish reliability-limits
418 DO180-OCP4.14-fr-2-20240530
Mise à l’échelle automatique des

applications
Résultats
• Configurer un autoscaler de pod horizontal pour une application.
Kubernetes peut mettre à l’échelle automatiquement un déploiement en fonction

de la charge actuelle sur les pods de l’application au moyen d’une ressource de type
HorizontalPodAutoscaler (HPA).
Une ressource de mise à l’échelle automatique de pod horizontale utilise les métriques de
performance collectées par le sous-système OpenShift Metrics. Le sous-système Metrics est pré-
installé dans OpenShift. Pour mettre à l’échelle automatiquement un déploiement, vous devez
spécifier des demandes de ressources pour les pods afin que l’autoscaler de pod horizontal puisse
calculer le pourcentage d’utilisation.
L’autoscaler fonctionne en boucle. Par défaut, il effectue les étapes suivantes toutes les
15 secondes :
• L’autoscaler récupère les détails de la métrique pour effectuer une mise à l’échelle à partir de la
ressource HPA.
• Pour chaque pod ciblé par la ressource HPA, l’autoscaler collecte la métrique à partir du sous-
système de métriques.
• Pour chaque pod ciblé, l’autoscaler calcule le pourcentage d’utilisation à partir de la métrique
collectée et des demandes de ressources du pod.
• L’autoscaler calcule l’utilisation moyenne et les demandes de ressources moyennes sur

l’ensemble des pods ciblés. Il établit un rapport d’utilisation à partir de ces valeurs, puis il utilise
ce rapport pour prendre sa décision de mise à l’échelle.
Pour créer une ressource de mise à l’échelle automatique de pod horizontale, la méthode la plus
simple consiste à utiliser la commande oc autoscale, par exemple :
[user@host ~]$ oc autoscale deployment/hello --min 1 --max 10 --cpu-percent 80
La commande précédente crée une ressource de mise à l’échelle automatique de pod horizontale
qui modifie le nombre de réplicas sur le déploiement hello pour maintenir ses pods en dessous
de 80 % de leur utilisation de processeur totale requise.
La commande oc autoscale crée une ressource de mise à l’échelle automatique de pod

horizontale en utilisant le nom du déploiement comme argument (hello dans l’exemple
précédent).
Les valeurs maximale et minimale pour la ressource de mise à l’échelle automatique de pod
horizontale prennent en charge les pics de charge et évitent la surcharge du cluster OpenShift.
Si la charge de l’application change trop rapidement, il peut s’avérer utile de conserver plusieurs
pods libres pour faire face aux pics soudains de demandes de la part des utilisateurs. Inversement,
un nombre trop élevé de pods peut utiliser toute la capacité du cluster et affecter les autres
applications qui utilisent le même cluster OpenShift.
DO180-OCP4.14-fr-2-20240530 419
Pour obtenir des informations sur les ressources de mise à l’échelle automatique de pod
horizontale dans le projet en cours, utilisez les commandes oc get. Par exemple :
[user@host ~]$ oc get hpa

NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS ...
hello Deployment/hello <unknown>/80% 1 10 1 ...
scale Deployment/scale 60%/80% 2 10 2 ...
Important
L’autoscaler de pod horizontal a initialement la valeur <unknown> dans la colonne
TARGETS. Il faudra peut-être attendre jusqu’à cinq minutes pour que <unknown>
soit remplacé par un pourcentage de l’utilisation actuelle.
La valeur persistante de <unknown> dans la colonne TARGETS peut indiquer

que le déploiement ne définit pas les demandes de ressources pour la métrique.
L’autoscaler de pod horizontal ne met pas ces pods à l’échelle.
Les pods qui sont créés à l’aide de la commande oc create deployment ne

définissent pas de demandes de ressources. Ici, l’utilisation de la mise à l’échelle
automatique d’OpenShift peut, par conséquent, nécessiter de modifier les
ressources de déploiement, de créer des fichiers de ressources YAML ou JSON
personnalisés pour votre application ou d’ajouter des ressources de plage de limite
à votre projet qui définissent les demandes de ressource par défaut.
En plus de la commande oc autoscale, vous pouvez créer une ressource de mise à l’échelle
automatique de pod horizontale à partir d’un fichier au format YAML.
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: hello
spec:
minReplicas: 1
maxReplicas: 10
metrics:
- resource:
name: cpu
target:
averageUtilization: 80
type: Utilization
type: Resource
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: hello
Nombre minimal de pods
Nombre maximal de pods
Utilisation moyenne idéale du processeur pour chaque pod. Si l’utilisation moyenne globale
du processeur est supérieure à cette valeur, l’autoscaler de pod horizontal démarre de
420 DO180-OCP4.14-fr-2-20240530
nouveaux pods. Si l’utilisation moyenne globale du processeur est inférieure à cette valeur,
l’autoscaler de pod horizontal supprime des pods.
Référence au nom de la ressource de déploiement.
Utilisez la commande oc apply -f hello-hpa.yaml pour créer la ressource à partir du fichier.
L’exemple précédent crée une ressource de mise à l’échelle automatique de pod horizontale
qui effectue une mise à l’échelle en fonction de l’utilisation du processeur. Elle peut également
effectuer une mise à l’échelle en fonction de l’utilisation de la mémoire en définissant le nom de la
ressource sur memory, comme dans l’exemple suivant :
metadata:
name: hello
spec:
minReplicas: 1
maxReplicas: 10
metrics:
- resource:
name: memory
target:
Pour créer une ressource de mise à l’échelle automatique de pod horizontal à partir de la
console Web, cliquez sur le menu Workloads > HorizontalPodAutoscalers. Cliquez sur Create
HorizontalPodAutoscaler et personnalisez le manifeste YAML.
Note
Si une application utilise plus de mémoire globale à mesure que le nombre de
réplicas augmente, elle ne peut pas être utilisée avec la mise à l’échelle automatique
basée sur la mémoire.
Références
Pour plus d’informations, reportez-vous à la section Automatically Scaling Pods with
the Horizontal Pod Autoscaler du chapitre Working with pods de la documentation
Nodes de Red Hat OpenShift Container Platform 4.14, disponible à l’adresse
openshift_container_platform/4.14/html-single/nodes/index#nodes-pods-
autoscaling
DO180-OCP4.14-fr-2-20240530 421
Exercice guidé
Mise à l’échelle automatique des

applications
Configurez un autoscaler pour une application, puis testez la charge de cette application
pour observer la mise à l’échelle vers le haut (scale-up).
Résultats
Vous serez en mesure de mettre à l’échelle manuellement un déploiement vers le haut
(scale-up), de configurer une ressource de mise à l’échelle de pod horizontale et de
surveiller l’autoscaler.
Avant De Commencer
exercice. Elle crée également le projet reliability-autoscaling.
[student@workstation ~]$ lab start reliability-autoscaling
Instructions
passe developer. Utilisez le projet reliability-autoscaling.

Login successful.
1.2. Définissez le projet reliability-autoscaling comme projet actif.
[student@workstation ~]$ oc project reliability-autoscaling

2. Créez le déploiement loadtest, le service et la route. Le déploiement utilise l’image de

conteneur registry.ocp4.example.com:8443/redhattraining/loadtest:v1.0
qui fournit une application Web. L’application Web expose un point d’accès d’API qui crée
une tâche nécessitant une utilisation intensive du processeur lorsqu’elle est interrogée.
2.1. Examinez le fichier de ressources ~/DO180/labs/reliability-autoscaling/

loadtest.yml préparé par la commande lab. La spécification du conteneur n’inclut
pas la section resources que vous utilisez pour spécifier les demandes et les limites
422 DO180-OCP4.14-fr-2-20240530
du processeur. Vous configurerez cette section au cours d’une autre étape. Ne

modifiez pas le fichier maintenant.
apiVersion: v1
kind: List
metadata: {}
items:
- apiVersion: apps/v1
kind: Deployment
spec:
containers:
- image: registry.ocp4.example.com:8443/redhattraining/loadtest:v1.0
name: loadtest
readinessProbe:
failureThreshold: 3
httpGet:
path: /api/loadtest/v1/healthz
port: 8080
scheme: HTTP
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
- apiVersion: v1
kind: Service
- apiVersion: route.openshift.io/v1
kind: Route
2.2. Utilisez la commande oc apply pour créer l’application.

~/DO180/labs/reliability-autoscaling/loadtest.yml
deployment.apps/loadtest created
service/loadtest created
route.route.openshift.io/loadtest created

loadtest-65c55b7dc-r4s4s 1/1 Running 0 49s
3. Configurez une ressource de mise à l’échelle de pod horizontale pour le déploiement

loadtest. Définissez le nombre minimal de réplicas sur 2 et le nombre maximal sur 20.
Définissez l’utilisation moyenne du processeur sur 50 % de l’attribut des demandes de
processeur (CPU Requests).
DO180-OCP4.14-fr-2-20240530 423
L’autoscaler de pod horizontal ne fonctionne pas, car le déploiement loadtest ne spécifie

pas de demandes pour l’utilisation du processeur.
3.1. Utilisez la commande oc autoscale pour créer la ressource de mise à l’échelle

horizontale automatique du pod.
[student@workstation ~]$ oc autoscale deployment/loadtest --min 2 --max 20 \

--cpu-percent 50
horizontalpodautoscaler.autoscaling/loadtest autoscaled
3.2. Récupérez l’état de la ressource de mise à l’échelle automatique de pod horizontale

loadtest. La valeur unknown qui figure dans la colonne TARGETS indique
qu’OpenShift ne peut pas calculer l’utilisation actuelle du processeur pour le
déploiement loadtest. Le déploiement doit inclure l’attribut des demandes du
processeur pour qu’OpenShift puisse calculer l’utilisation du processeur.
[student@workstation ~]$ oc get hpa loadtest

NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
loadtest Deployment/loadtest <unknown>/50% 2 20 2 74s
3.3. Obtenez plus de détails sur l’état de la ressource. Vous devrez peut-être exécuter la
commande à plusieurs reprises. Attendez trois minutes que la commande signale le
message d’avertissement.
[student@workstation ~]$ oc describe hpa loadtest

Name: loadtest
Namespace: reliability-autoscaling
Conditions:
Type Status Reason Message
---- ------ ------ -------
AbleToScale True SucceededGetScale the HPA controller was able to
get the target's current scale
ScalingActive False FailedGetResourceMetric the HPA was unable to compute
the replica count: failed to get cpu utilization: missing request for cpu
Events:
Type ... Message
---- ... -------
Warning ... failed to get cpu utilization: missing request for cpu
3.4. Supprimez la ressource de mise à l’échelle automatique de pod horizontale. Vous

recréerez la ressource au cours d’une autre étape, après avoir corrigé le déploiement
loadtest.
[student@workstation ~]$ oc delete hpa loadtest

horizontalpodautoscaler.autoscaling "loadtest" deleted
3.5. Supprimez l’application loadtest.
424 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ oc delete -f \

deployment.apps "loadtest" deleted
service "loadtest" deleted
route.route.openshift.io "loadtest" deleted
4. Ajoutez une section de ressource de processeur au fichier ~/DO180/labs/

reliability-autoscaling/loadtest.yml. Redéployez l’application à partir du
fichier.
4.1. Modifiez le fichier ~/DO180/labs/reliability-autoscaling/loadtest.yml,

et configurez les demandes et les limites du processeur pour le déploiement
loadtest. Les pods ont besoin de 25 millicores pour fonctionner et ne doivent pas
consommer plus de 100 millicores.
Vous pouvez comparer votre travail avec le fichier ~/DO180/solutions/
reliability-autoscaling/loadtest.yml terminé que la commande lab a
préparé.
spec:
containers:
- image: registry.ocp4.example.com:8443/redhattraining/loadtest:v1.0
name: loadtest
readinessProbe:
failureThreshold: 3
httpGet:
path: /api/loadtest/v1/healthz
port: 8080
scheme: HTTP
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
resources:
requests:
cpu: 25m
limits:
cpu: 100m
4.2. Utilisez la commande oc apply pour déployer l’application à partir du fichier.

deployment.apps/loadtest created
service/loadtest created
route.route.openshift.io/loadtest created
DO180-OCP4.14-fr-2-20240530 425

loadtest-667bdcdc99-vhc9x 1/1 Running 0 36s
5. Mettez à l’échelle manuellement le déploiement loadtest en augmentant d’abord, puis en

réduisant le nombre de pods en cours d’exécution.
5.1. Mettez à l’échelle le déploiement loadtest vers le haut (scale-up) sur cinq pods.
[student@workstation ~]$ oc scale deployment/loadtest --replicas 5

deployment.apps/loadtest scaled
5.2. Vérifiez que les cinq pods d’application sont tous en cours d’exécution. Vous devrez
peut-être exécuter la commande à plusieurs reprises pour que tous les pods signalent
l’état Running. Il est probable que les noms des pods soient différents sur votre
système.

loadtest-667bdcdc99-5fcvh 1/1 Running 0 43s
loadtest-667bdcdc99-dpspr 1/1 Running 0 42s
loadtest-667bdcdc99-hkssk 1/1 Running 0 43s
loadtest-667bdcdc99-vhc9x 1/1 Running 0 8m11s
loadtest-667bdcdc99-z5n9q 1/1 Running 0 43s
5.3. Mettez à l’échelle le déploiement loadtest vers le bas (scale-down) sur un seul pod.
[student@workstation ~]$ oc scale deployment/loadtest --replicas 1

deployment.apps/loadtest scaled
5.4. Vérifiez qu’une seule application est en cours d’exécution. Vous devrez peut-être
exécuter la commande à plusieurs reprises pour que les pods s’arrêtent.

loadtest-667bdcdc99-vhc9x 1/1 Running 0 11m
6. Configurez une ressource de mise à l’échelle de pod horizontale pour le déploiement

loadtest. Définissez le nombre minimal de réplicas sur 2 et le nombre maximal sur 20.
Définissez l’utilisation moyenne du processeur sur 50 % de l’attribut des demandes de
processeur.
6.1. Utilisez la commande oc autoscale pour créer la ressource de mise à l’échelle

horizontale automatique du pod.
[student@workstation ~]$ oc autoscale deployment/loadtest --min 2 --max 20 \

--cpu-percent 50
horizontalpodautoscaler.autoscaling/loadtest autoscaled
426 DO180-OCP4.14-fr-2-20240530
6.2. Ouvrez une nouvelle fenêtre de terminal et exécutez la commande watch pour
surveiller la commande oc get hpa loadtest. Attendez cinq minutes que
l’autoscaler de pod horizontal loadtest signale l’utilisation dans la colonne
TARGETS.
Notez que l’autoscaler de pod horizontal augmente (scale-up) le déploiement sur
deux réplicas pour se conformer au nombre minimal de pods que vous avez configuré.
[student@workstation ~]$ watch oc get hpa loadtest

Every 2.0s: oc get hpa loadtest workstation: Fri Mar 3 06:26:24 2023

loadtest Deployment/loadtest 0%/50% 2 20 2 52s
7. Augmentez l’utilisation du processeur en envoyant des demandes à l’API de l’application

loadtest.
7.1. Utilisez la commande oc get route pour récupérer l’URL de l’application.
[student@workstation ~]$ oc get route loadtest

NAME HOST/PORT ...
loadtest loadtest-reliability-autoscaling.apps.ocp4.example.com ...
7.2. Envoyez une demande à l’API de l’application pour simuler une sollicitation
supplémentaire du processeur sur le conteneur. N’attendez pas la fin de la commande
curl pour poursuivre l’exercice. Au bout d’une minute, la commande signale une
erreur de timeout que vous pouvez ignorer.

loadtest-reliability-autoscaling.apps.ocp4.example.com/api/loadtest/v1/cpu/1
<html><body><h1>504 Gateway Time-out</h1>
The server didn't respond in time.
</body></html>
7.3. Observez la sortie de la commande oc get hpa loadtest dans le deuxième

terminal. Au bout d’une minute, l’autoscaler de pod horizontal détecte une
augmentation de l’utilisation du processeur et déploie des pods supplémentaires.
Note
L’augmentation de l’activité de l’application ne déclenche pas immédiatement la
mise à l’échelle automatique. Patientez quelques instants si vous ne voyez aucune
modification du nombre de répliques.
Vous devrez peut-être exécuter la commande curl plusieurs fois avant que
l’application n’utilise suffisamment de ressources processeur pour déclencher
l’autoscaler.
Il est probable que l’utilisation du processeur et le nombre de réplicas soient

différents sur votre système.
DO180-OCP4.14-fr-2-20240530 427

loadtest Deployment/loadtest 220%/50% 2 20 9 16m
7.4. Attendez cinq minutes après l’exécution de la commande curl. La commande oc

get hpa loadtest montre que la charge du processeur diminue.
Note
La mise à l’échelle vers le haut (scale-up) de la ressource autoscaler de pod
horizontal peut être rapide, mais l’opération inverse (scale-down) peut prendre plus
de temps.

7.5. Facultatif : attendez que l’application loadtest soit mise à l’échelle vers le bas
(scale-down). Il faut cinq minutes supplémentaires pour que l’autoscaler de pod
horizontal passe à deux réplicas.

7.6. Appuyez sur Ctrl+C pour quitter la commande watch. Fermez ce deuxième terminal
lorsque vous avez terminé.
Fin
[student@workstation ~]$ lab finish reliability-autoscaling
428 DO180-OCP4.14-fr-2-20240530
Open Lab
Configuration des applications sur le plan

de la fiabilité
Déployez et dépannez une application fiable qui définit des sondes d’intégrité, des
demandes de ressources de calcul et des limites de ressources de calcul afin qu’elle puisse
exécuter N instances par nœud ; et configurez un autoscaler de pod horizontal qui évoluera
jusqu’à un maximum de N instances.
Résultats
Vous serez en mesure d’ajouter des demandes de ressources à un objet Deployment, de
configurer des sondes et de créer une ressource de mise à l’échelle automatique de pod
horizontale.
Avant De Commencer
exercice. Elle crée également le projet reliability-review et y déploie l’application
longload.
[student@workstation ~]$ lab start reliability-review
Instructions

developer.
Utilisez le projet reliability-review pour votre travail.

1. L’application longload dans le projet reliability-review ne démarre pas.
Diagnostiquez le problème, puis corrigez-le. L’application a besoin de 512 Mio de mémoire
pour fonctionner.
Une fois le problème résolu, vous pouvez vérifier que l’application fonctionne en exécutant
le script ~/DO180/labs/reliability-review/curl_loop.sh que la commande lab
a préparé. Ce script envoie des demandes à l’application dans une boucle. Pour chaque
demande, le script affiche le nom du pod et l’état de l’application. Appuyez sur Ctrl+C pour
arrêter le script.
2. Lorsque l’application est mise à l’échelle vers le haut (scale-up), vos clients se plaignent
de l’échec de certaines demandes. Pour répliquer le problème, faites passer manuellement
l’application longload sur trois réplicas et exécutez le script ~/DO180/labs/
reliability-review/curl_loop.sh en même temps.
DO180-OCP4.14-fr-2-20240530 429
L’initialisation de l’application prend sept secondes. L’application expose le point d’accès de

l’API /health sur le port HTTP 3000. Configurez le déploiement longload pour qu’il utilise
ce point d’accès, pour vous assurer que l’application est prête avant de traiter les demandes
des clients.
3. Configurez l’application de sorte qu’elle soit mise automatiquement à l’échelle vers le haut
(scale-up) lorsque l’utilisation moyenne de la mémoire est supérieure à 60 % de la valeur
des demandes de mémoire, et vers le bas (scale-down) lorsque l’utilisation est inférieure à
ce pourcentage. Le nombre minimal de réplicas doit être égal à un et le nombre maximal, à
trois. La ressource que vous créez pour la mise à l’échelle de l’application doit être intitulée
longload.
La commande lab fournit le fichier de ressources ~/DO180/labs/reliability-
review/hpa.yml comme exemple. Utilisez la commande oc explain pour connaître les
paramètres valides pour l’attribut hpa.spec.metrics.resource.target. Étant donné
que le fichier est incomplet, vous devez d’abord le mettre à jour si vous choisissez de l’utiliser.
Pour tester votre travail, utilisez la commande oc exec deploy/longload — curl
localhost:3000/leak pour envoyer une requête HTTP au point d’accès de l’API de
l’application /leak. Chaque demande utilise 480 Mio de mémoire supplémentaire. Pour
libérer cette mémoire, vous pouvez utiliser le script ~/DO180/labs/reliability-
review/free.sh.
Évaluation
persistent.
[student@workstation ~]$ lab grade reliability-review
Fin
[student@workstation ~]$ lab finish reliability-review
430 DO180-OCP4.14-fr-2-20240530
Solution

de la fiabilité
Déployez et dépannez une application fiable qui définit des sondes d’intégrité, des
demandes de ressources de calcul et des limites de ressources de calcul afin qu’elle puisse
exécuter N instances par nœud ; et configurez un autoscaler de pod horizontal qui évoluera
jusqu’à un maximum de N instances.
Résultats
Vous serez en mesure d’ajouter des demandes de ressources à un objet Deployment, de
configurer des sondes et de créer une ressource de mise à l’échelle automatique de pod
horizontale.
Avant De Commencer
exercice. Elle crée également le projet reliability-review et y déploie l’application
longload.
[student@workstation ~]$ lab start reliability-review
Instructions

developer.
Utilisez le projet reliability-review pour votre travail.

1. L’application longload dans le projet reliability-review ne démarre pas.
Diagnostiquez le problème, puis corrigez-le. L’application a besoin de 512 Mio de mémoire
pour fonctionner.
Une fois le problème résolu, vous pouvez vérifier que l’application fonctionne en exécutant
le script ~/DO180/labs/reliability-review/curl_loop.sh que la commande lab
a préparé. Ce script envoie des demandes à l’application dans une boucle. Pour chaque
demande, le script affiche le nom du pod et l’état de l’application. Appuyez sur Ctrl+C pour
arrêter le script.
DO180-OCP4.14-fr-2-20240530 431

Login successful.
1.2. Définissez le projet reliability-review comme projet actif.
[student@workstation ~]$ oc project reliability-review

1.3. Listez les pods du projet. Le pod se trouve a l’état Pending. Il est probable que le nom

longload-64bf8dd776-b6rkz 0/1 Pending 0 8m1s
1.4. Récupérez les événements du pod. Aucun nœud de calcul ne dispose de suffisamment
de mémoire pour prendre en charge le pod.
[student@workstation ~]$ oc describe pod longload-64bf8dd776-b6rkz

Name: longload-64bf8dd776-b6rkz
Namespace: reliability-review
Events:
---- ------ ---- ---- -------
Warning FailedScheduling 8m default-scheduler 0/1 nodes are available:
1 Insufficient memory. preemption: 0/1 nodes are available: 1 No preemption
victims found for incoming pod.
1.5. Examinez les demandes de ressources relatives à la mémoire. Le déploiement

longload demande 8 Gio de mémoire.
[student@workstation ~]$ oc get deployment longload -o \

jsonpath='{.spec.template.spec.containers[0].resources.requests.memory}{"\n"}'
8Gi
1.6. Définissez les demandes de mémoire sur 512 MiB. Ignorez le message d’avertissement.
[student@workstation ~]$ oc set resources deployment/longload \

--requests memory=512Mi
deployment.apps/longload resource requirements updated
1.7. Attendez que le pod démarre. Vous devrez peut-être exécuter la commande à plusieurs
reprises pour que le pod signale l’état Running. Il est probable que le nom du pod soit
différent sur votre système.
432 DO180-OCP4.14-fr-2-20240530

longload-5897c9558f-cx4gt 1/1 Running 0 86s
1.8. Exécutez le script ~/DO180/labs/reliability-review/curl_loop.sh pour

vérifier que l’application fonctionne correctement.
[student@workstation ~]$ ~/DO180/labs/reliability-review/curl_loop.sh

1 curl: (7) Failed to connect to master01.ocp4.example.com port 30372: Connection
refused
2 longload-5897c9558f-cx4gt: app is still starting
5 longload-5897c9558f-cx4gt: Ok
Appuyez sur Ctrl+C pour arrêter le script.
2. Lorsque l’application est mise à l’échelle vers le haut (scale-up), vos clients se plaignent
de l’échec de certaines demandes. Pour répliquer le problème, faites passer manuellement
l’application longload sur trois réplicas et exécutez le script ~/DO180/labs/
reliability-review/curl_loop.sh en même temps.
L’initialisation de l’application prend sept secondes. L’application expose le point d’accès de
l’API /health sur le port HTTP 3000. Configurez le déploiement longload pour qu’il utilise
ce point d’accès, pour vous assurer que l’application est prête avant de traiter les demandes
des clients.
2.1. Ouvrez une nouvelle fenêtre de terminal et exécutez le script ~/DO180/labs/

reliability-review/curl_loop.sh.
[student@workstation ~]$ ~/DO180/labs/reliability-review/curl_loop.sh

Laissez le script s’exécuter et ne l’interrompez pas.
2.2. Dimensionnez (scale-up) l’application sur trois réplicas.
[student@workstation ~]$ oc scale deployment/longload --replicas 3

deployment.apps/longload scaled
2.3. Observez la sortie du script curl_loop.sh dans le deuxième terminal. Certaines

demandes échouent, car OpenShift les envoie aux nouveaux pods avant que
l’application ne soit prête.
DO180-OCP4.14-fr-2-20240530 433
refused
refused
refused
refused
31 longload-5897c9558f-tpssf: app is still starting
32 longload-5897c9558f-kkvm5: app is still starting
Laissez le script s’exécuter et ne l’interrompez pas.
2.4. Ajoutez une sonde Readiness au déploiement longload. Ignorez le message

d’avertissement.
[student@workstation ~]$ oc set probe deployment/longload --readiness \

--initial-delay-seconds 7 \
--get-url http://:3000/health
deployment.apps/longload probes updated
2.5. Mettez à l’échelle l’application vers le bas (scale-down) sur un seul pod.

Si la réduction interrompt le script curl_loop.sh, appuyez sur Ctrl+c pour arrêter le

script dans le deuxième terminal. Ensuite, redémarrez le script.
2.6. Pour tester votre travail, dimensionnez (scale-up) à nouveau l’application sur trois
réplicas.

2.7. Observez la sortie du script curl_loop.sh dans le deuxième terminal. Aucune

demande n’échoue.
434 DO180-OCP4.14-fr-2-20240530
92 longload-7ddcc9b7fd-72dtm: Ok
95 longload-7ddcc9b7fd-qln95: Ok
96 longload-7ddcc9b7fd-wrxrb: Ok
97 longload-7ddcc9b7fd-qln95: Ok
98 longload-7ddcc9b7fd-wrxrb: Ok
Appuyez sur Ctrl+C pour arrêter le script.
3. Configurez l’application de sorte qu’elle soit mise automatiquement à l’échelle vers le haut
(scale-up) lorsque l’utilisation moyenne de la mémoire est supérieure à 60 % de la valeur
des demandes de mémoire, et vers le bas (scale-down) lorsque l’utilisation est inférieure à
ce pourcentage. Le nombre minimal de réplicas doit être égal à un et le nombre maximal, à
trois. La ressource que vous créez pour la mise à l’échelle de l’application doit être intitulée
longload.
La commande lab fournit le fichier de ressources ~/DO180/labs/reliability-
review/hpa.yml comme exemple. Utilisez la commande oc explain pour connaître les
paramètres valides pour l’attribut hpa.spec.metrics.resource.target. Étant donné
que le fichier est incomplet, vous devez d’abord le mettre à jour si vous choisissez de l’utiliser.
Pour tester votre travail, utilisez la commande oc exec deploy/longload — curl
localhost:3000/leak pour envoyer une requête HTTP au point d’accès de l’API de
l’application /leak. Chaque demande utilise 480 Mio de mémoire supplémentaire. Pour
libérer cette mémoire, vous pouvez utiliser le script ~/DO180/labs/reliability-
review/free.sh.
3.1. Avant de créer la ressource de mise à l’échelle automatique de pod horizontale,

réduisez (scale-down) l’application à un seul pod.

3.2. Modifiez le fichier de ressources ~/DO180/labs/reliability-review/

hpa.yml. Vous pouvez récupérer les paramètres de l’attribut resource à l’aide
des commandes oc explain hpa.spec.metrics.resource et oc explain
hpa.spec.metrics.resource.target.
metadata:
name: longload
labels:
app: longload
spec:
maxReplicas: 3
minReplicas: 1
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: longload
DO180-OCP4.14-fr-2-20240530 435
metrics:
- type: Resource
resource:
name: memory
target:
type: Utilization
3.3. Utilisez la commande oc apply pour déployer l’autoscaler de pod horizontal.
[student@workstation ~]$ oc apply -f ~/DO180/labs/reliability-review/hpa.yml

horizontalpodautoscaler.autoscaling/longload created
3.4. Dans le deuxième terminal, exécutez la commande watch pour surveiller la commande
oc get hpa longload. Attendez que l’autoscaler de pod horizontal longload
signale l’utilisation dans la colonne TARGETS. Il est probable que le pourcentage soit
[student@workstation ~]$ watch oc get hpa longload

Every 2.0s: oc get hpa longload workstation: Fri Mar 10 05:15:34 2023

longload Deployment/longload 13%/60% 1 3 1 75s
3.5. Pour tester votre travail, exécutez la commande oc exec deploy/longload — curl
localhost:3000/leak dans le premier terminal pour que l’application alloue
480 Mio de mémoire.
[student@workstation ~]$ oc exec deploy/longload -- curl -s localhost:3000/leak

longload-7ddcc9b7fd-72dtm: consuming memory!
3.6. Dans le deuxième terminal, après deux minutes, la commande oc get hpa
longload affiche l’augmentation de la mémoire. L’autoscaler de pod horizontal
met à l’échelle (scale-up) l’application sur plusieurs réplicas. Il est probable que le
pourcentage soit différent sur votre système.

longload Deployment/longload 145%/60% 1 3 2 5m18s
3.7. Pour tester votre travail, exécutez le script ~/DO180/labs/reliability-review/

free.sh dans le premier terminal pour que l’application libère la mémoire. Vérifiez
que le pod qui libère la mémoire est le même que celui qui consommait de la mémoire.
Exécutez le script free.sh plusieurs fois, si nécessaire.
[student@workstation ~]$ ~/DO180/labs/reliability-review/free.sh

longload-7ddcc9b7fd-72dtm: releasing memory!
436 DO180-OCP4.14-fr-2-20240530
3.8. Dans le deuxième terminal, après deux minutes, la commande oc get hpa
longload affiche la diminution de la mémoire. La mise à l’échelle horizontale
automatique de pod réduit l’application à un réplica. Il est probable que le pourcentage
soit différent sur votre système.

longload Deployment/longload 12%/60% 1 3 1 15m28s
Appuyez sur Ctrl+C pour quitter la commande watch. Fermez ce deuxième terminal
lorsque vous avez terminé.
Évaluation
persistent.
[student@workstation ~]$ lab grade reliability-review
Fin
[student@workstation ~]$ lab finish reliability-review
DO180-OCP4.14-fr-2-20240530 437
Quiz

de la fiabilité
1. Dans l’atelier précédent, compte tenu de la capacité de votre nœud et de la demande

de mémoire initiale de l’application, combien de pods OpenShift peut-il planifier ?
a. La demande est définie sur 8 Gio, par conséquent, aucun pod ne peut être planifié.
b. La demande est définie sur 8 Gio, par conséquent, un seul pod peut être planifié.
c. La demande est définie sur 512 Mio, par conséquent, aucun pod ne peut être planifié.
d. La demande est définie sur 512 Mio, par conséquent, trois pods peuvent être planifiés.
2. Dans l’atelier précédent, quel paramètre de déploiement est incorrect et empêche le

démarrage de l’application ?
a. La sonde Readiness est mal configurée et échoue toujours.
b. La sonde Liveness est mal configurée et échoue toujours.
c. La demande de mémoire est trop élevée. Aucun nœud de calcul ne dispose de
suffisamment de mémoire pour prendre en charge l’application
d. La limite de mémoire est trop basse. Le sous-système du noyau OOM continue de
supprimer les processus de conteneur.
3. Dans l’atelier précédent, quel paramètre est initialement absent du déploiement, mais
n’empêche pas l’exécution de l’application ?
a. La sonde Liveness n’est pas définie.
b. La sonde Readiness n’est pas définie.
c. La limite de mémoire n’est pas définie.
d. La limite de processeur n’est pas définie.
438 DO180-OCP4.14-fr-2-20240530
Solution

de la fiabilité
1. Dans l’atelier précédent, compte tenu de la capacité de votre nœud et de la demande

de mémoire initiale de l’application, combien de pods OpenShift peut-il planifier ?
a. La demande est définie sur 8 Gio, par conséquent, aucun pod ne peut être planifié.
b. La demande est définie sur 8 Gio, par conséquent, un seul pod peut être planifié.
c. La demande est définie sur 512 Mio, par conséquent, aucun pod ne peut être planifié.
d. La demande est définie sur 512 Mio, par conséquent, trois pods peuvent être planifiés.
2. Dans l’atelier précédent, quel paramètre de déploiement est incorrect et empêche le

démarrage de l’application ?
a. La sonde Readiness est mal configurée et échoue toujours.
b. La sonde Liveness est mal configurée et échoue toujours.
c. La demande de mémoire est trop élevée. Aucun nœud de calcul ne dispose de
suffisamment de mémoire pour prendre en charge l’application
d. La limite de mémoire est trop basse. Le sous-système du noyau OOM continue de
supprimer les processus de conteneur.
3. Dans l’atelier précédent, quel paramètre est initialement absent du déploiement, mais
n’empêche pas l’exécution de l’application ?
a. La sonde Liveness n’est pas définie.
b. La sonde Readiness n’est pas définie.
c. La limite de mémoire n’est pas définie.
d. La limite de processeur n’est pas définie.
DO180-OCP4.14-fr-2-20240530 439
Résumé
• Une application à haute disponibilité résiste aux scénarios qui pourraient autrement la rendre
indisponible.
• Kubernetes et RHOCP fournissent des fonctions de haute disponibilité (HA), telles que
des sondes d’intégrité, qui aident le cluster à acheminer le trafic uniquement vers les pods
opérationnels.
• Les limites et les demandes de ressources permettent d’équilibrer l’utilisation des ressources du
nœud de cluster.
• Les autoscalers de pod horizontaux ajoutent ou suppriment automatiquement des réplicas en

fonction de l’utilisation actuelle des ressources et des paramètres spécifiés.
440 DO180-OCP4.14-fr-2-20240530
chapitre 7
Gestion des mises à jour des

applications
Objectif Gérer des mises à jour d’application
reproductibles, ainsi que des restaurations de code
et de configurations.
Résultats • Associer les balises d’image de conteneur à

leurs hachages d’identifiant, et identifier les
images de conteneur à partir de pods et de
conteneurs sur les nœuds Kubernetes.
• Mettez à jour les applications avec un temps
d’arrêt minimal à l’aide de stratégies de
déploiement.
• Garantir la reproductibilité des déploiements
d’applications en utilisant des flux d’images et
des noms d’images courts.
• Garantir la mise à jour automatique des pods
d’application en utilisant des flux d’images avec
les ressources de charge de travail Kubernetes.
Sections • Identité et balises d’images de conteneur (et

exercice guidé)
• Mise à jour des paramètres et de l’image de
l’application (et exercice guidé)
• Déploiements reproductibles avec des flux
d’images OpenShift (et exercice guidé)
• Mises à jour automatiques des images avec
les déclencheurs de changement d’image
OpenShift (et exercice guidé)
Atelier • Gestion des mises à jour des applications
DO180-OCP4.14-fr-2-20240530 441
chapitre 7 | Gestion des mises à jour des applications
Identité et balises d’images de conteneur
Résultats
• Associer les balises d’image de conteneur à leurs hachages d’identifiant, et identifier les images
de conteneur à partir de pods et de conteneurs sur les nœuds Kubernetes.
Balises d’images Kubernetes

Le nom complet d’une image de conteneur est constitué de plusieurs parties. Par exemple,
vous pouvez décomposer le nom de l’image registry.access.redhat.com/ubi9/
nginx-120:1-86 en plusieurs éléments, comme indiqué ci-dessous :
• Le serveur de registre est registry.access.redhat.com.
• L’espace de noms est ubi9.
• Le nom est nginx-120. Dans cet exemple, le nom de l’image contient la version du logiciel :
Nginx version 1.20.
• La balise, qui pointe vers une version spécifique de l’image, est 1-86. Si vous omettez la balise,
la plupart des outils de conteneur utilisent latest par défaut.
Plusieurs balises peuvent faire référence à la même version de l’image. La capture d’écran suivante
de Red Hat Ecosystem Catalog à l’adresse https://catalog.redhat.com/software/containers/
explore liste les balises de l’image ubi9/nginx-120 :
Dans ce cas, les balises 1.86, latest et 1 pointent vers la même version de l’image. Vous pouvez
utiliser n’importe laquelle de ces balises pour faire référence à cette version.
442 DO180-OCP4.14-fr-2-20240530
Les balises latest et 1 sont dites flottantes, car elles peuvent pointer vers différentes versions
de l’image au fil du temps. Par exemple, lorsque les développeurs publient une nouvelle version de
l’image, ils modifient la balise latest pour qu’elle pointe vers cette nouvelle version. Ils mettent
également à jour la balise 1 pour qu’elle pointe vers la dernière édition de cette version, telle que
1-87 ou 1-88.
En tant qu’utilisateur de l’image, en spécifiant une balise flottante, vous vous assurez de toujours
utiliser la version d’image à jour correspondant à la balise.
Problèmes liés aux balises flottantes

Les fournisseurs, entreprises et développeurs qui publient des images gèrent leurs balises et
créent leur propre cycle de vie pour les balises flottantes. Ils peuvent réaffecter une balise
flottante à une nouvelle version d’image sans préavis.
En tant qu’utilisateur de l’image, vous ne remarquerez peut-être pas que la balise que vous utilisiez
pointe désormais vers une autre version.
Supposons que vous déployiez une application sur OpenShift et que vous utilisiez la balise
latest pour l’image. La série d’événements suivante peut se produire :
1. Quand OpenShift déploie le conteneur, il extrait l’image avec la balise latest du registre de
conteneurs.
2. Par la suite, le développeur de l’image envoie une nouvelle version de l’image par push et
réaffecte la balise latest à cette nouvelle version.
3. OpenShift déplace le pod vers un autre nœud de cluster ; en raison de l’échec du nœud
d’origine, par exemple.
4. Sur ce nouveau nœud, OpenShift extrait l’image avec la balise latest et récupère ainsi la
nouvelle version.
5. À présent, le déploiement OpenShift s’exécute avec une nouvelle version de l’application,

sans que vous soyez conscient de cette mise à jour de version.
Un problème similaire est que lorsque vous mettez à l’échelle votre déploiement, OpenShift
démarre de nouveaux pods. Sur les nœuds, OpenShift extrait la version de l’image latest pour
ces nouveaux pods. Par conséquent, si une nouvelle version est disponible, votre déploiement
s’exécute avec des conteneurs qui utilisent des versions différentes de l’image. Des incohérences
d’application peuvent apparaître et des comportements inattendus peuvent se produire.
Pour éviter ces problèmes, sélectionnez une image dont la stabilité dans le temps est garantie.
Vous contrôlez ainsi le cycle de vie de votre application : vous pouvez choisir quand et comment
OpenShift déploie une nouvelle version de l’image.
Vous pouvez sélectionner une version d’image statique de plusieurs manières :
• Utilisez une balise qui ne change pas, au lieu de recourir à des balises flottantes.
• Utilisez des flux d’images OpenShift pour un contrôle strict des versions d’images. Vous
trouverez une description plus détaillée des flux d’images dans une autre section de ce cours.
• Utilisez l’ID d’image SHA (Secure Hash Algorithm) au lieu d’une balise lorsque vous référencez la
version d’une image.
La distinction entre balise flottante et balise non flottante n’est pas de nature technique, mais
conventionnelle. Bien que cela soit déconseillé, il n’existe aucun mécanisme pour empêcher un
développeur d’envoyer (par push) une image différente vers une balise existante. Par conséquent,
DO180-OCP4.14-fr-2-20240530 443
vous devez spécifier l’ID d’image SHA pour garantir que l’image de conteneur référencée ne
change pas.
Utilisation de l’ID d’image SHA

Les développeurs affectent des balises aux images. En revanche, un ID d’image SHA, ou
condensé, est un identifiant unique que le registre de conteneurs calcule et attribue aux images.
L’ID SHA est une chaîne immuable qui fait référence à une version d’image spécifique. L’utilisation
de l’ID SHA pour identifier une image constitue la méthode la plus sûre.
Pour faire référence à une image par son ID SHA, remplacez name:tag par name@SHA-ID dans le
nom de l’image. L’exemple suivant utilise l’ID d’image SHA au lieu d’une balise.
registry.access.redhat.com/ubi9/nginx-120@sha256:1be2006abd21735e7684eb4cc6eb62...
Pour récupérer l’ID d’image SHA à partir de la balise, utilisez la commande oc image info.
Note
Une image multi-architecture référence des images pour plusieurs architectures de
processeur. Les images multi-architectures contiennent un index qui pointe vers les
images pour différentes plateformes et architectures de processeur.
Pour ces images, la commande oc image info vous oblige à sélectionner une
architecture à l’aide de l’option --filter-by-os :
[user@host ~]$ oc image info registry.access.redhat.com/ubi9/nginx-120:1-86

error: the image is a manifest list and contains multiple images - use --
filter-by-os to select from:
OS DIGEST
linux/amd64 sha256:1be2006abd21735e7684eb4cc6eb6295346a89411a187e37cd4...
linux/arm64 sha256:d765193e823bb89b878d2d2cb8be0e0073839a6c19073a21485...
linux/ppc64le sha256:0dd0036620f525b3ba9a46f9f1c52ac70414f939446b2ba3a07...
linux/s390x sha256:d8d95cc17764b82b19977bc7ef2f60ff56a3944b3c7c14071dd...
L’exemple suivant affiche l’ID SHA de l’image vers laquelle pointe actuellement la balise 1-86.
[user@host ~]$ oc image info --filter-by-os linux/amd64 \

registry.access.redhat.com/ubi9/nginx-120:1-86
Name: registry.access.redhat.com/ubi9/nginx-120:1-86
Digest: sha256:1be2006abd21735e7684eb4cc6eb6295346a89411a187e37cd4a3aa2f1bd13a5
Manifest List: sha256:5bc635dc946fedb4ba391470e8f84f9860e06a1709e30206a95ed9955...
Media Type: application/vnd.docker.distribution.manifest.v2+json
Vous pouvez également utiliser la commande skopeo inspect. Le format de sortie diffère de
celui de la commande oc image info, bien que les deux commandes renvoient des données
similaires.
Si vous utilisez la commande oc debug node/node-name pour vous connecter à un nœud

de calcul, vous pouvez lister les images disponibles en local en exécutant la commande crictl
images --digests --no-trunc. L’option --digests indique à la commande d’afficher les
444 DO180-OCP4.14-fr-2-20240530
ID d’image SHA, tandis que l’option --no-trunc lui indique d’afficher la chaîne SHA complète ;
sinon, la commande affiche uniquement les premiers caractères.
[user@host ~]$ oc debug node/node-name

Temporary namespace openshift-debug-csn2p is created for debugging node...
Starting pod/node-name-debug ...
Pod IP: 192.168.50.10
sh-4.4# crictl images --digests --no-trunc \
registry.access.redhat.com/ubi9/nginx-120:1-86
IMAGE TAG DIGEST IMAGE ID ...
registry.access.redhat.com/ubi9/nginx-120 1-86 sha256:1be2...13a5 2e68...949e ...
La colonne IMAGE ID affiche l’identifiant d’image local que le moteur de conteneur affecte à
l’image. Cet identifiant n’est pas lié à l’ID SHA.
Le format d’image de conteneur s’appuie sur des hachages SHA-256 pour identifier plusieurs
composants d’image, tels que les couches ou les métadonnées d’image. Étant donné que
certaines commandes renvoient également ces chaînes SHA-256, assurez-vous d’utiliser le
hachage SHA-256 qui correspond à l’ID d’image SHA. Les commandes font souvent référence à
l’ID d’image SHA en tant que condensé d’image.
Sélection d’une politique d’extraction

Lorsque vous déployez une application, OpenShift sélectionne un nœud de calcul pour exécuter le
pod. Sur ce nœud, OpenShift extrait l’image, puis démarre le conteneur.
En définissant l’attribut imagePullPolicy dans la ressource de déploiement, vous pouvez

contrôler la manière dont OpenShift extrait l’image.
L’exemple suivant montre la ressource de déploiement myapp. La politique d’extraction est définie
sur IfNotPresent.
[user@host ~]$ oc get deployment myapp -o yaml

apiVersion: apps/v1
kind: Deployment
template:
metadata:
creationTimestamp: null
labels:
app: myapp
spec:
containers:
name: nginx-120
L’attribut imagePullPolicy peut utiliser les valeurs suivantes :
DO180-OCP4.14-fr-2-20240530 445
IfNotPresent
Si l’image se trouve déjà sur le nœud de calcul, parce qu’un autre conteneur l’utilise ou parce
qu’OpenShift l’a extraite lors d’une exécution de pod précédente, OpenShift utilise cette
image locale. Sinon, OpenShift extrait l’image du registre de conteneurs.
Si vous utilisez une balise flottante dans votre déploiement et que l’image associée à cette
balise se trouve déjà sur le nœud, OpenShift n’extrait pas à nouveau l’image, même s’il se
peut que la balise flottante pointe vers une image plus récente dans le registre de conteneurs
source.
Par défaut, OpenShift définit l’attribut imagePullPolicy sur IfNotPresent lorsque vous
utilisez une balise ou l’ID SHA pour identifier l’image.
Always
OpenShift vérifie toujours si une version mise à jour de l’image est disponible dans le registre
de conteneurs source. Pour ce faire, OpenShift récupère l’ID SHA de l’image à partir du
registre. Si une image locale ayant le même ID SHA se trouve déjà sur le nœud de calcul,
OpenShift l’utilise. Sinon, OpenShift extrait l’image.
Si vous utilisez une balise flottante dans votre déploiement et qu’une image avec cette balise
se trouve déjà sur le nœud, OpenShift interroge quand même le registre pour s’assurer que la
balise pointe toujours vers la même version de l’image. Cependant, si le développeur a envoyé
(push) une nouvelle version de l’image et a mis à jour la balise flottante, OpenShift récupère
cette nouvelle version.
Par défaut, OpenShift définit l’attribut imagePullPolicy sur Always lorsque vous utilisez
la balise latest ou lorsque vous n’en spécifiez aucune.
Never
OpenShift n’extrait pas l’image et s’attend à ce qu’elle soit déjà disponible sur le nœud. Sinon,
le déploiement échoue.
Pour utiliser cette option, vous devez préremplir vos nœuds de calcul avec les images que
vous avez l’intention d’utiliser. Vous utilisez ce mécanisme pour améliorer les performances ou
pour éviter de dépendre d’un registre de conteneurs pour ces images.
Nettoyage d’images à partir de nœuds de cluster

Quand OpenShift supprime un pod d’un nœud de calcul, il ne supprime pas l’image associée.
OpenShift peut réutiliser les images sans avoir à les extraire à nouveau du registre distant.
Étant donné que les images utilisent de l’espace disque sur les nœuds de calcul, OpenShift
doit supprimer, ou nettoyer, les images inutilisées lorsque l’espace disque vient à manquer. Le
processus kubelet, qui s’exécute sur les nœuds de calcul, inclut un récupérateur de mémoire
(ou garbage collector) qui s’exécute toutes les cinq minutes. Si l’utilisation du système de fichiers
qui stocke les images est supérieure à 85 %, le récupérateur de mémoire supprime les images
inutilisées les plus anciennes. Le nettoyage de la mémoire s’arrête lorsque l’utilisation du système
de fichiers passe en dessous de 80 %.
Vous trouverez, dans la documentation de référence à la fin de ce cours, des instructions pour
ajuster ces seuils par défaut.
À partir d’un nœud de calcul, vous pouvez exécuter la commande crictl imagefsinfo pour
récupérer le nom du système de fichiers qui stocke les images :
446 DO180-OCP4.14-fr-2-20240530
[user@host ~]$ oc debug node/node-name

Temporary namespace openshift-debug-csn2p is created for debugging node...
Starting pod/node-name-debug ...
Pod IP: 192.168.50.10
sh-4.4# crictl imagefsinfo
{
"status": {
"timestamp": "1674465624446958511",
"fsId": {
"mountpoint": "/var/lib/containers/storage/overlay-images"
},
"usedBytes": {
"value": "1318560"
},
"inodesUsed": {
"value": "446"
}
}
}
D’après la sortie de la commande précédente, le système de fichiers qui stocke les images est /
var/lib/containers/storage/overlay-images. Les images utilisent 1 318 560 octets
d’espace disque.
Vous pouvez utiliser crictl rmi à partir du nœud de calcul pour supprimer une image inutilisée.
Cependant, le nettoyage d’objets à l’aide de la commande crictl peut perturber le récupérateur
de mémoire et le processus kubelet.
Il est recommandé de recourir au récupérateur de mémoire pour nettoyer les objets, images
et conteneurs inutilisés à partir des nœuds de calcul. Le récupérateur de mémoire peut être
configuré afin de mieux répondre aux besoins personnalisés que vous pourriez avoir.
DO180-OCP4.14-fr-2-20240530 447
Références
Pages de manuel skopeo-inspect(1) et podman-system-prune(1)
Pour plus d’informations sur les noms d’images, reportez-vous au chapitre Overview
of Images (Présentation des images) de la documentation Images de Red Hat
openshift_container_platform/4.14/html-single/images/index#overview-of-images
Pour plus d’informations sur les politiques d’extraction, reportez-vous à la section

Image Pull Policy (Politique d’extraction des images) du chapitre Managing Images
(Gestion des images) de la documentation Images de Red Hat OpenShift Container
openshift_container_platform/4.14/html-single/images/index#image-pull-policy
Pour plus d’informations sur le nettoyage de la mémoire, reportez-vous à la

section Understanding How Terminated Containers Are Removed Through Garbage
Collection (Comprendre comment les conteneurs arrêtés sont supprimés au moyen
du nettoyage de la mémoire) du chapitre Working with Nodes (Utilisation des
nœuds) dans la documentation Nodes (Nœuds) de Red Hat OpenShift Container
Platform 4.14, à l’adresse
openshift_container_platform/4.14/html-single/nodes/index#nodes-nodes-
garbage-collection-containers_nodes-nodes-configuring
448 DO180-OCP4.14-fr-2-20240530
Exercice guidé
Identité et balises d’images de conteneur

Vous allez mettre à jour une application en modifiant son déploiement pour référencer une
balise d’image plus récente, et rechercher les hachages des anciennes et des nouvelles
images d’application.
Résultats
Vous devriez être en mesure d’examiner des images de conteneur, de lister les images de
conteneurs qui s’exécutent sur des nœuds de calcul et de déployer des applications en
utilisant des balises d’image ou des ID SHA.
Avant De Commencer
exercice. Elle crée également le projet updates-ids et le fichier /home/student/DO180/
labs/updates-ids/resources.txt. Le fichier resources.txt contient le nom des
images et certaines des commandes que vous utiliserez au cours de l’exercice. Vous pouvez
utiliser le fichier pour copier et coller ces noms d’image et ces commandes.
[student@workstation ~]$ lab start updates-ids
Instructions
passe developer. Utilisez le projet updates-ids.

Login successful.
1.2. Définissez le projet updates-ids comme projet actif.
[student@workstation ~]$ oc project updates-ids

2. Examinez les deux versions de l’image registry.ocp4.example.com:8443/ubi8/

httpd-24 à partir du registre de conteneurs de la salle de classe. La configuration de
la salle de classe a copié cette image à partir de Red Hat Ecosystem Catalog. L’image
d’origine est registry.access.redhat.com/ubi8/httpd-24.
DO180-OCP4.14-fr-2-20240530 449
2.1. Utilisez la commande oc image info pour examiner la version de l’image

référencée par la balise 1-209. Notez l’ID SHA unique qui identifie la version de
l’image.
Note
Sur votre système, les commandes renvoient les chaînes SHA-256 complètes. Vous
devez également saisir la chaîne SHA-256 complète pour fournir un tel paramètre à
une commande.

registry.ocp4.example.com:8443/ubi8/httpd-24:1-209
Name: registry.ocp4.example.com:8443/ubi8/httpd-24:1-209
Digest: sha256:b1e3...f876
2.2. Examinez la version de l’image référencée par la balise 1-215. Notez que l’ID SHA, ou
condensé, diffère de la version d’image précédente.

Digest: sha256:91ad...fd83
2.3. Pour examiner des images, vous pouvez également utiliser la commande skopeo
inspect. Le format de sortie diffère de celui de la commande oc image info,
bien que les deux commandes renvoient des données similaires.
Connectez-vous au registre en tant qu’utilisateur developer avec le mot de passe
developer en utilisant la commande skopeo login. Utilisez ensuite la commande
skopeo inspect pour examiner la balise d’image 1-215.
[student@workstation ~]$ skopeo login registry.ocp4.example.com:8443 -u developer

Password: developer
Login Succeeded!

docker://registry.ocp4.example.com:8443/ubi8/httpd-24:1-215
{
"Name": "registry.ocp4.example.com:8443/ubi8/httpd-24",
"Digest": "sha256:91ad...fd83",
"RepoTags": [
"1-209",
"1-215"
],
}
450 DO180-OCP4.14-fr-2-20240530
La commande skopeo inspect affiche également d’autres balises d’image

existantes.
3. Déployez une application à partir de la version d’image référencée par la balise 1-209.
3.1. Utilisez la commande oc create deployment pour déployer l’application.

Définissez le nom du déploiement sur httpd1.
[student@workstation ~]$ oc create deployment httpd1 \

--image registry.ocp4.example.com:8443/ubi8/httpd-24:1-209
deployment.apps/httpd1 created
3.2. Attendez que le pod démarre, puis récupérez le nom du nœud de cluster qui
l’exécute. Vous devrez peut-être exécuter la commande à plusieurs reprises pour que
le pod signale l’état Running. Il est probable que le nom du pod soit différent sur
votre système.

NAME READY STATUS RESTARTS AGE IP NODE ...
httpd1-6dff796d99-pm2x6 1/1 Running 0 19s 10.8.0.104 master01 ...
3.3. Récupérez le nom du conteneur qui s’exécute à l’intérieur du pod. La commande

crictl ps que vous exécuterez au cours d’une étape ultérieure utilise le nom du
conteneur comme argument.
[student@workstation ~]$ oc get deployment httpd1 -o wide

NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS ...
httpd1 1/1 1 1 1m10s httpd-24 ...
4. Accédez au nœud de cluster, puis récupérez l’image utilisée par le conteneur.
4.1. Vous devez vous connecter en tant qu’utilisateur admin pour accéder au nœud du
cluster. Utilisez le mot de passe redhatocp.

Login successful.
4.2. Utilisez la commande oc debug node pour accéder au nœud du cluster.

Temporary namespace openshift-debug-flz4d is created for debugging node...
Pod IP: 192.168.50.10
4.3. Dans le shell distant, exécutez la commande chroot /host.

sh-4.4#
DO180-OCP4.14-fr-2-20240530 451
4.4. Utilisez la commande crictl ps pour vérifier que le conteneur httpd-24 est en
cours d’exécution. Ajoutez l’option -o yaml pour afficher les détails du conteneur au
format YAML.
sh-4.4# crictl ps --name httpd-24 -o yaml

containers:
- annotations:
image:
annotations: {}
image: registry.ocp4.example.com:8443/ubi8/httpd-24@sha256:b1e3...f876
imageRef: registry.ocp4.example.com:8443/ubi8/httpd-24@sha256:b1e3...f876
labels:
state: CONTAINER_RUNNING
Notez que la commande fait référence à l’image par son ID SHA, et non par la balise
que vous avez spécifiée lors de la création de la ressource de déploiement.
4.5. Utilisez la commande crictl images pour lister toutes les images disponibles
en local sur le nœud. L’image registry.ocp4.example.com:8443/ubi8/
httpd-24:1-209 figure dans cette liste, car le moteur de conteneur local l’a extraite
lorsque vous avez déployé l’application httpd1.
Note
La colonne IMAGE ID affiche l’identifiant d’image local que le moteur de conteneur
affecte à l’image. Cet identifiant n’est pas lié à l’ID d’image SHA que le registre de
conteneurs a affecté à l’image.
La plupart des commandes crictl, telles que crictl images ou crictl

rmi, acceptent un identifiant d’image local au lieu du nom complet de
l’image. Par exemple, vous pouvez exécuter la commande crictl images
8ee59251acc93 en tant que version abrégée de la commande crictl images
registry.ocp4.example.com:8443/ubi8/httpd-24:1-209.
sh-4.4# crictl images

IMAGE TAG IMAGE ID SIZE
quay.io/openshift-release-dev/ocp-release <none> d52324cb88017 444MB
quay.io/openshift-release-dev/ocp-v4.0-art-dev <none> 22e6e45df32af 468MB
quay.io/openshift-release-dev/ocp-v4.0-art-dev <none> e798432938c49 503MB
quay.io/openshift-release-dev/ocp-v4.0-art-dev <none> 3ca084e53b321 873MB
registry.ocp4.example.com:8443/ubi8/httpd-24 1-209 8ee59251acc93 461MB
4.6. La commande crictl images précédente n’affiche pas les ID d’image SHA
par défaut. Exécutez à nouveau la commande et ajoutez l’option --digests
pour afficher les ID SHA. Ajoutez également l’ID de l’image locale à la commande
pour limiter la sortie à l’image registry.ocp4.example.com:8443/ubi8/
httpd-24:1-209.
452 DO180-OCP4.14-fr-2-20240530
La commande ne renvoie que les premiers caractères de l’ID d’image SHA. Ces
caractères correspondent à l’ID SHA de l’image utilisée par le conteneur httpd-24.
Par conséquent, le conteneur httpd-24 utilise l’image prévue.
sh-4.4# crictl images --digests 8ee59251acc93

IMAGE TAG DIGEST IMAGE ID ...
registry.ocp4.example.com:8443/ubi8/httpd-24 1-209 b1e3c572516d1 8ee59251acc93 ...
4.7. Déconnectez-vous du nœud de cluster.
sh-4.4# exit
exit
sh-4.4# exit
exit

Temporary namespace openshift-debug-flz4d was removed.
5. Connectez-vous en tant qu’utilisateur developer, puis déployez une autre application en

utilisant l’ID SHA de l’image comme condensé.
5.1. Connectez-vous au cluster OpenShift en tant qu’utilisateur developer.
[student@workstation ~]$ oc login -u developer -p developer

Login successful.
5.2. Réexécutez la commande oc image info pour récupérer l’ID SHA de la version
d’image référencée par la balise 1-209. Spécifiez le format JSON pour la sortie de
la commande. Analysez la sortie JSON avec la commande jq -r pour récupérer la
valeur de l’objet .digest. Exportez l’ID SHA en tant que variable d’environnement
$IMAGE.

registry.ocp4.example.com:8443/ubi8/httpd-24:1-209 -o json | \
jq -r .digest
sha256:b1e3...f876
[student@workstation ~]$ IMAGE=sha256:b1e3...f876
5.3. Utilisez la commande oc create deployment pour déployer l’application.

Définissez le nom du déploiement sur httpd2.

--image registry.ocp4.example.com:8443/ubi8/httpd-24@$IMAGE
5.4. Vérifiez que le nouveau déploiement fait référence à la version d’image par son
ID SHA.
DO180-OCP4.14-fr-2-20240530 453

NAME READY ... CONTAINERS IMAGES ...
httpd2 1/1 ... httpd-24 registry.../ubi8/httpd-24@sha256:b1e3...f876 ...
6. Mettez à jour l’application httpd2 en utilisant une version d’image plus récente.
6.1. Dans le déploiement httpd2, mettez à jour le conteneur httpd-24 pour qu’il utilise
la version d’image référencée par la balise 1-215.
[student@workstation ~]$ oc set image deployment/httpd2 \

httpd-24=registry.ocp4.example.com:8443/ubi8/httpd-24:1-215
deployment.apps/httpd2 image updated
6.2. Vérifiez que le déploiement fait référence à la nouvelle version de l’image.

NAME READY ... IMAGES ...
httpd2 1/1 ... registry.ocp4.example.com:8443/ubi8/httpd-24:1-215 ...
6.3. Vérifiez que le redéploiement du pod est terminé. Vous devrez peut-être exécuter la
commande à plusieurs reprises pour que le pod signale l’état Running. Il est probable
que les noms des pods soient différents sur votre système.

httpd1-6dff796d99-pm2x6 1/1 Running 0 118m
httpd2-998d9b9b9-5859j 1/1 Running 0 21s
6.4. Examinez le pod pour vérifier que le conteneur utilise la nouvelle image. Remplacez le
nom du pod par celui de l’étape précédente.
[student@workstation ~]$ oc get pod httpd2-998d9b9b9-5859j \

-o jsonpath='{.spec.containers[0].image}{"\n"}'
7. Ajoutez la balise latest à la version de l’image déjà référencée par la balise 1-209.
Déployez une application à partir de l’image associée à la balise latest.
7.1. Utilisez la commande skopeo login pour vous connecter au registre de conteneurs
de la salle de classe en tant qu’utilisateur developer. Utilisez developer comme
mot de passe.
[student@workstation ~]$ skopeo login -u developer -p developer \

registry.ocp4.example.com:8443
Login Succeeded!
7.2. Utilisez la commande skopeo copy pour ajouter la balise latest à l’image.
454 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ skopeo copy \

docker://registry.ocp4.example.com:8443/ubi8/httpd-24:1-209 \
docker://registry.ocp4.example.com:8443/ubi8/httpd-24:latest
Getting image source signatures
Writing manifest to image destination
Storing signatures
7.3. Utilisez la commande oc image info pour vérifier que les deux balises font bien
référence à la même image. Les deux commandes renvoient le même ID d’image
SHA, ce qui indique que les balises pointent vers la même version de l’image.


registry.ocp4.example.com:8443/ubi8/httpd-24:latest
Name: registry.ocp4.example.com:8443/ubi8/httpd-24:latest
7.4. Utilisez la commande oc create deployment pour déployer une autre application.
Définissez le nom du déploiement sur httpd3. Pour vérifier que, par défaut, la
commande sélectionne la balise latest, n’indiquez pas la partie « balise » dans le
nom de l’image.

--image registry.ocp4.example.com:8443/ubi8/httpd-24
7.5. Vérifiez que le pod est en cours d’exécution. Vous devrez peut-être exécuter la
que les noms des pods soient différents sur votre système.

httpd2-998d9b9b9-5859j 1/1 Running 0 32m
httpd3-85b978d758-fvqdr 1/1 Running 0 42s
7.6. Vérifiez que le pod utilise l’image prévue. Notez que l’ID d’image SHA correspond à
l’image référencée par la balise 1-209. Vous avez récupéré cet ID d’image SHA au
cours d’une étape précédente, en exécutant la commande oc image info.
DO180-OCP4.14-fr-2-20240530 455
[student@workstation ~]$ oc describe pod httpd3-85b978d758-fvqdr

Containers:
httpd-24:
Container ID: cri-o://2cee...3a68
Image: registry.ocp4.example.com:8443/ubi8/httpd-24
Image ID: registry.ocp4.example.com:8443/ubi8/httpd-24@sha256:b1e3...f876
8. Attribuez la balise latest à une autre version de l’image. Cette opération simule un
développeur qui envoie une nouvelle version d’une image par push et affecte la balise
latest à cette nouvelle version.
8.1. Utilisez la commande skopeo copy pour ajouter la balise latest à la version
de l’image déjà référencée par la balise 1-215. La commande supprime
automatiquement la balise latest de l’image précédente.
[student@workstation ~]$ skopeo copy \

docker://registry.ocp4.example.com:8443/ubi8/httpd-24:1-215 \
docker://registry.ocp4.example.com:8443/ubi8/httpd-24:latest
Getting image source signatures
Writing manifest to image destination
Storing signatures
8.2. Déconnectez-vous du registre de conteneurs de la salle de classe.
[student@workstation ~]$ skopeo logout registry.ocp4.example.com:8443

Removed login credentials for registry.ocp4.example.com:8443
Note
La commande skopeo logout se déconnecte d’un serveur de registre spécifié en
supprimant les informations d’identification mises en cache qui sont stockées dans
le fichier ${XDG_RUNTIME_DIR}/containers/auth.json.
Red Hat recommande de supprimer les informations d’identification en cache qui ne

sont plus nécessaires.
8.3. Même si la balise latest fait désormais référence à une version d’image différente,
OpenShift ne redéploie pas les pods qui s’exécutent avec la version d’image
précédente.
Exécutez à nouveau la commande oc describe pod pour vérifier que le pod utilise
toujours l’image précédente.
456 DO180-OCP4.14-fr-2-20240530

Containers:
httpd-24:
9. Mettez à l’échelle le déploiement httpd3 sur deux pods.
9.1. Utilisez la commande oc scale pour ajouter un nouveau pod au déploiement.
[student@workstation ~]$ oc scale deployment/httpd3 --replicas 2

deployment.apps/httpd3 scaled
9.2. Listez les pods pour vérifier que deux d’entre eux sont en cours d’exécution pour le
déploiement httpd3. Il est probable que les noms des pods soient différents sur
votre système.

httpd2-998d9b9b9-5859j 1/1 Running 0 30m
httpd3-85b978d758-f98jh 1/1 Running 0 54s
httpd3-85b978d758-fvqdr 1/1 Running 0 11m
9.3. Récupérez l’ID d’image SHA pour le pod que le déploiement a initialement créé. L’ID
n’a pas changé. Le conteneur utilise toujours la version d’image d’origine.

Containers:
httpd-24:
9.4. Récupérez l’ID d’image SHA pour le pod supplémentaire. Comme vous pouvez le
voir, l’ID est différent. Le pod supplémentaire utilise l’image qui est actuellement
référencée par la balise latest.
[student@workstation ~]$ oc describe pod httpd3-85b978d758-f98jh

Containers:
httpd-24:
Container ID: cri-o://d254...c893
Image ID: registry.ocp4.example.com:8443/ubi8/httpd-24@sha256:91ad...fd83
DO180-OCP4.14-fr-2-20240530 457
L’état du déploiement est incohérent. Les deux pods répliqués utilisent une version
d’image différente. Par conséquent, il se peut que l’application mise à l’échelle ne se
comporte pas correctement. Red Hat vous recommande d’utiliser une balise moins
volatile que latest dans les environnements de production ou d’opérer un contrôle
plus strict des affectations de balises dans votre registre de conteneurs.
Fin
[student@workstation ~]$ lab finish updates-ids
458 DO180-OCP4.14-fr-2-20240530
Mise à jour des paramètres et de l’image

de l’application
Résultats
• Mettez à jour les applications avec un temps d’arrêt minimal à l’aide de stratégies de
déploiement.
Code d’application, configuration et données

Les applications modernes associent librement le code, la configuration et les données. Les
fichiers de configuration et les données ne sont pas codés en dur en tant que partie intégrante
du logiciel. Le logiciel charge plutôt la configuration et les données à partir d’une source externe.
Cette externalisation permet de déployer une application dans différents environnements sans
avoir à modifier le code source de l’application.
OpenShift fournit des ressources de volume, de secret et de mappage de configuration pour

stocker la configuration et les données de l’application. Le code de l’application est disponible par
le biais d’images de conteneur.
Étant donné qu’OpenShift déploie des applications à partir d’images de conteneur, les
développeurs doivent créer une nouvelle version de l’image lorsqu’ils mettent à jour le code de
leur application. Les entreprises utilisent généralement un pipeline d’intégration et de livraison
continues (CI/CD) pour générer automatiquement l’image à partir du code source de l’application,
puis pour envoyer (push) l’image obtenue à un registre de conteneurs.
Vous utilisez des ressources OpenShift, telles que des mappages de configuration et des secrets,
pour mettre à jour la configuration de l’application. Pour contrôler le processus de déploiement
d’une nouvelle version d’image, vous utilisez un objet Deployment.
Stratégies de déploiement
Le déploiement de modifications d’application fonctionnelles ou de nouvelles versions pour les
utilisateurs est une phase importante des pipelines CI/CD, au cours de laquelle vous valorisez le
processus de développement.
Apporter des modifications aux applications comporte des risques, comme des temps
d’arrêt pendant le déploiement, l’apparition de bogues ou la réduction des performances des
applications. Vous pouvez réduire ou atténuer certains risques en intégrant des étapes de test et
de validation dans vos pipelines.
L’indisponibilité d’une application ou d’un service peut impliquer, entre autres, une perte d’activité,
la perturbation d’autres services qui dépendent des vôtres et la violation de contrats de niveau
de service (SLA). Pour réduire les temps d’arrêt et minimiser les risques lors des déploiements,
utilisez une stratégie de déploiement. Cette stratégie permet de modifier ou de mettre à niveau
une application de manière à réduire l’impact de ces changements.
Dans OpenShift, vous utilisez des objets Deployment pour définir des déploiements et des
stratégies de déploiement. RollingUpdate et Recreate sont les principales stratégies de
déploiement disponibles dans OpenShift.
DO180-OCP4.14-fr-2-20240530 459
Pour sélectionner les stratégies RollingUpdate ou Recreate, vous définissez la propriété

.spec.strategy.type de l’objet Deployment. L’extrait de code suivant illustre un objet
Deployment qui utilise la stratégie Recreate :
apiVersion: apps/v1
kind: Deployment
metadata:
spec:
progressDeadlineSeconds: 600
replicas: 10
revisionHistoryLimit: 10
selector:
matchLabels:
app: myapp2
strategy:
type: Recreate
template:
Stratégie RollingUpdate
La stratégie RollingUpdate consiste à mettre à jour une version d’une application par étapes.
Les instances sont remplacées les unes après les autres jusqu’à ce qu’il n’en reste plus aucune à
remplacer.
Dans cette stratégie, les deux versions de l’application s’exécutent simultanément, et les instances
de la version précédente ne sont réduites que lorsque la nouvelle version est prête. Le principal
inconvénient de cette stratégie est qu’elle nécessite une compatibilité entre les versions du
déploiement.
Le graphique suivant illustre le déploiement d’une nouvelle version d’une application à l’aide de la
stratégie RollingUpdate :
1. Certaines instances d’application exécutent une version de code qui doit être mise à jour
(v1). OpenShift effectue une mise à l’échelle vers le haut (scale-up) d’une nouvelle instance
avec la version mise à jour de l’application (v2). Étant donné que la nouvelle instance avec la
460 DO180-OCP4.14-fr-2-20240530
version v2 n’est pas prête, seules les instances avec la version v1 répondent aux demandes des
clients.
2. L’instance avec v2 est prête et accepte les demandes des clients. OpenShift effectue une
mise à l’échelle vers le bas (scale-down) d’une instance avec la version v1et vers le haut
(scale-up) d’une nouvelle instance avec la version v2. Les deux versions de l’application
répondent aux demandes des clients.
3. La nouvelle instance avec v2 est prête et accepte les demandes des clients. Red Hat
OpenShift met à l’échelle vers le bas (scale-down) l’instance restante avec la version v1.
4. Il ne reste plus aucune instance à remplacer. La mise à jour de l’application s’est déroulée avec
succès, et sans temps d’arrêt.
La stratégie RollingUpdate prend en charge un déploiement continu et élimine les temps

d’arrêt de l’application pendant les déploiements. Vous pouvez utiliser cette stratégie si les
différentes versions de votre application peuvent s’exécuter en même temps.
Note
La stratégie RollingUpdate est la stratégie par défaut si vous ne spécifiez pas de
stratégie sur les objets Deployment.
L’extrait de code suivant illustre un objet Deployment qui utilise la stratégie RollingUpdate :
apiVersion: apps/v1
kind: Deployment
metadata:
spec:
progressDeadlineSeconds: 600
replicas: 10
revisionHistoryLimit: 10
selector:
matchLabels:
app: myapp2
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 50%
type: RollingUpdate
template:
Il existe de nombreux paramètres permettant de configurer la stratégie RollingUpdate. L’extrait

de code précédent présente les paramètres maxSurge et maxUnavailable.
Au cours d’une mise à jour progressive, le nombre de pods de l’application varie, car OpenShift
démarre de nouveaux pods pour la nouvelle révision et supprime des pods de la révision
précédente. Le paramètre maxSurge indique le nombre de pods qu’OpenShift peut créer au-
dessus du nombre normal de réplicas. Le paramètre maxUnavailable indique le nombre de pods
qu’OpenShift peut supprimer en dessous du nombre normal de réplicas. Vous pouvez exprimer
ces paramètres sous la forme d’un pourcentage ou d’un nombre de pods.
DO180-OCP4.14-fr-2-20240530 461
Si vous ne configurez pas de sonde Readiness pour votre déploiement, lors d’une mise à jour
progressive, OpenShift commence à envoyer le trafic client vers les nouveaux pods dès qu’ils
sont en cours d’exécution. Cependant, il se peut que l’application à l’intérieur d’un conteneur ne
soit pas immédiatement prête à accepter les demandes des clients. Il se peut que l’application
doive charger des fichiers dans le cache, établir une connexion réseau à une base de données ou
effectuer des tâches initiales qui peuvent prendre du temps. Par conséquent, OpenShift redirige
les demandes des clients vers un conteneur qui n’est pas encore prêt, et ces demandes échouent.
L’ajout d’une sonde Readiness à votre déploiement empêche OpenShift d’envoyer du trafic vers
de nouveaux pods qui ne sont pas prêts.
Stratégie de recréation
Dans cette stratégie, toutes les instances d’une application sont d’abord arrêtées, puis remplacées
par de nouvelles. L’inconvénient majeur de cette stratégie est qu’elle entraîne un temps d’arrêt de
vos services. Pendant une certaine période, aucune instance d’application n’est disponible pour
répondre aux demandes.
Le graphique suivant illustre le déploiement d’une nouvelle version d’une application qui utilise la
stratégie Recreate :
1. Certaines instances de l’application exécutent une version de code à mettre à jour (v1).
2. OpenShift réduit (scale-down) à zéro les instances en cours d’exécution. Cette action
entraîne un temps d’arrêt de l’application, car aucune instance n’est disponible pour répondre
aux demandes.
3. OpenShift effectue une mise à l’échelle vers le haut des nouvelles instances avec une
nouvelle version de l’application (v2). Lorsque les nouvelles instances démarrent, le temps
d’arrêt continue.
4. Les nouvelles instances ont fini de démarrer, et sont prêtes à répondre aux demandes. Il s’agit
de la dernière étape de la stratégie Recreate et elle résout la panne de l’application.
Vous pouvez utiliser cette stratégie lorsque plusieurs versions du code de votre application ne
peuvent pas être exécutées en même temps. Vous pouvez également l’utiliser pour exécuter
des migrations ou des transformations de données avant le démarrage du nouveau code. Cette
stratégie n’est pas recommandée pour les applications qui nécessitent une haute disponibilité, par
exemple les systèmes médicaux.
462 DO180-OCP4.14-fr-2-20240530
Déploiement d’applications
Lorsque vous mettez à jour un objet Deployment, OpenShift déploie automatiquement
l’application. Si vous appliquez plusieurs modifications d’affilée, telles que la modification de la
version de l’image, la mise à jour des variables d’environnement et la configuration de la sonde
Readiness, OpenShift déploie l’application pour chacune d’elles.
Pour éviter ces déploiements multiples, suspendez le déploiement, appliquez toutes vos
modifications à l’objet Deployment, puis reprenez le déploiement. OpenShift effectue ensuite un
déploiement unique pour appliquer toutes vos modifications :
• Utilisez la commande oc rollout pause pour suspendre la mise en œuvre du déploiement

myapp :
[user@host ~]$ oc rollout pause deployment/myapp
• Appliquez toutes vos modifications à l’objet Deployment. L’exemple suivant modifie l’image,
une variable d’environnement et la sonde Readiness.
[user@host ~]$ oc set image deployment/myapp \

nginx-120=registry.access.redhat.com/ubi9/nginx-120:1-86
[user@host ~]$ oc set env deployment/myapp NGINX_LOG_TO_VOLUME=1
[user@host ~]$ oc set probe deployment/myapp --readiness --get-url http://:8080
• Reprenez le déploiement :
[user@host ~]$ oc rollout resume deployment/myapp
OpenShift déploie l’application pour appliquer toutes vos modifications à l’objet Deployment.
Vous pouvez suivre un processus similaire lorsque vous créez et configurez un nouveau
déploiement :
• Créez le déploiement et définissez le nombre de réplicas sur zéro. De cette façon, OpenShift ne
déploie pas votre application et aucun pod n’est exécuté.
[user@host ~]$ oc create deployment myapp2 \

--image registry.access.redhat.com/ubi9/nginx-120:1-86 --replicas 0
[user@host ~]$ oc get deployment/myapp2
myapp2 0/0 0 0 9s
• Appliquez la configuration à l’objet Deployment. L’exemple suivant ajoute une sonde

Readiness.
[user@host ~]$ oc set probe deployment/myapp2 --readiness --get-url http://:8080
• Mettez à l’échelle le déploiement vers le haut (scale-up). OpenShift déploie l’application.
[user@host ~]$ oc scale deployment/myapp2 --replicas 10

[user@host ~]$ oc get deployment/myapp2
myapp2 10/10 10 10 18s
DO180-OCP4.14-fr-2-20240530 463
Surveillance des jeux de réplicas

Chaque fois qu’OpenShift déploie une application à partir d’un objet Deployment, il crée un objet
ReplicaSet. Les jeux de réplicas sont responsables de la création et de la surveillance des pods.
Si un pod échoue, l’objet ReplicaSet en déploie un nouveau.
Pour déployer des pods, les jeux de réplicas utilisent la définition du modèle de pod à partir de
l’objet Deployment. OpenShift copie la définition du modèle à partir de l’objet Deployment
lorsqu’il crée l’objet ReplicaSet.
Lorsque vous mettez à jour l’objet Deployment, OpenShift ne met pas à jour l’objet ReplicaSet
existant. À la place, il crée un autre objet ReplicaSet avec la nouvelle définition du modèle de
pod. Ensuite, il déploie l’application conformément à la stratégie de mise à jour.
Il peut donc y avoir plusieurs objets ReplicaSet en même temps pour un déploiement sur
votre système. Lors d’une mise à jour progressive, l’ancien objet et le nouvel objet ReplicaSet
coexistent et coordonnent le déploiement de la nouvelle version de l’application. Une fois le
déploiement terminé, OpenShift conserve l’ancien objet ReplicaSet afin que vous puissiez
revenir en arrière si la nouvelle version ne fonctionne pas correctement.
Le graphique suivant illustre un objet Deployment et deux objets ReplicaSet. L’ancien objet
ReplicaSet pour la version 1 de l’application n’exécute aucun pod. L’objet ReplicaSet actuel
pour la version 2 de l’application gère trois pods répliqués.
Abstenez-vous de modifier ou de supprimer directement des objets ReplicaSet, car OpenShift

les gère via les objets Deployment associés. L’attribut .spec.revisionHistoryLimit
dans les objets Deployment spécifie le nombre d’objets ReplicaSet qu’OpenShift conserve.
OpenShift supprime automatiquement les objets ReplicaSet supplémentaires. De même,
lorsque vous supprimez un objet Deployment, OpenShift supprime tous les objets ReplicaSet
associés.
Exécutez la commande oc get replicaset pour lister les objets ReplicaSet. OpenShift
utilise le nom d’objet Deployment comme préfixe pour les objets ReplicaSet.
[user@host ~]$ oc get replicaset

myapp2-574968dd59 0 0 0 3m27s
myapp2-76679885b9 10 10 10 22s
myapp2-786cbf9bc8 0 0 0 114s
464 DO180-OCP4.14-fr-2-20240530
La sortie précédente présente trois objets ReplicaSet pour le déploiement myapp2. Chaque
fois que vous modifiiez le déploiement myapp2, OpenShift créait un objet ReplicaSet. Le
deuxième objet de la liste est actif et surveille 10 pods. Les autres objets ReplicaSet ne gèrent
aucun pod. Ils représentent les versions précédentes de l’objet Deployment.
Lors d’une mise à jour progressive, deux objets ReplicaSet sont actifs. L’ancien objet
ReplicaSet est mis à l’échelle vers le bas (scale-down), tandis que le nouvel objet est mis à
l’échelle vers le haut (scale-up) :
[user@host ~]$ oc get replicaset

myapp2-574968dd59 0 0 0 13m
myapp2-5fb5766df5 4 4 2 21s
myapp2-76679885b9 8 8 8 10m
myapp2-786cbf9bc8 0 0 0 11m
Le nouvel objet ReplicaSet a déjà démarré quatre pods, mais la colonne READY indique
que, jusqu’à présent, la sonde Readiness n’a réussi que pour deux pods. Ces deux pods sont
susceptibles de recevoir du trafic client.
L’objet ReplicaSet a déjà effectué une réduction (scale-down) de 10 à 8 pods.
Gestion du déploiement
Étant donné qu’OpenShift conserve les objets ReplicaSet des versions de déploiement
antérieures, vous pouvez revenir en arrière si vous constatez que la nouvelle version de
l’application ne fonctionne pas.
Exécutez la commande oc rollout undo pour restaurer la version de déploiement précédente.

La commande utilise l’objet ReplicaSet existant de cette version pour restaurer les pods. Elle
rétablit également la version précédente de l’objet Deployment.
[user@host ~]$ oc rollout undo deployment/myapp2
Utilisez la commande oc rollout status pour contrôler le processus de déploiement :
[user@host ~]$ oc rollout status deployment/myapp2

deployment "myapp2" successfully rolled out
Si l’opération de déploiement échoue, parce que vous spécifiez un nom d’image de conteneur
incorrect ou que la sonde Readiness échoue, OpenShift ne restaure pas automatiquement
votre déploiement. Dans ce cas, exécutez la commande oc rollout undo pour revenir à la
configuration valide précédente.
Par défaut, la commande oc rollout undo rétablit la version de déploiement précédente. Si

vous devez revenir à une révision antérieure, listez les révisions disponibles et ajoutez l’option --
to-revision rev à la commande oc rollout undo.
• Utilisez la commande oc rollout history pour lister les révisions disponibles :
DO180-OCP4.14-fr-2-20240530 465
[user@host ~]$ oc rollout history deployment/myapp2

deployment.apps/myapp2
REVISION CHANGE-CAUSE
1 <none>
3 <none>
4 <none>
5 <none>
Note
La colonne CHANGE-CAUSE fournit un message défini par l’utilisateur qui décrit
la révision. Vous pouvez stocker le message dans l’annotation de déploiement
kubernetes.io/change-cause après chaque déploiement :
[user@host ~]$ oc annotate deployment/myapp2 \

kubernetes.io/change-cause="Image updated to 1-86"
deployment.apps/myapp2 annotated
[user@host ~]$ oc rollout history deployment/myapp2
deployment.apps/myapp2
REVISION CHANGE-CAUSE
1 <none>
3 <none>
4 <none>
5 Image updated to 1-86
• Ajoutez l’option --revision à la commande oc rollout history pour plus de détails sur
une révision spécifique :
[user@host ~]$ oc rollout history deployment/myapp2 --revision 1

deployment.apps/myapp2 with revision #1
Pod Template:
Labels: app=myapp2
pod-template-hash=574968dd59
Containers:
nginx-120:
Image: registry.access.redhat.com/ubi9/nginx-120:1-86
Port: <none>
Host Port: <none>
Environment: <none>
Mounts: <none>
Volumes: <none>
L’attribut pod-template-hash est le suffixe de l’objet ReplicaSet associé. Vous pouvez

examiner cet objet ReplicaSet pour obtenir plus de détails en utilisant la commande oc
describe replicaset myapp2-574968dd59, par exemple.
• Pour revenir à une révision spécifique, ajoutez l’option --to-revision à la commande oc

rollout undo :
[user@host ~]$ oc rollout undo deployment/myapp2 --to-revision 1
466 DO180-OCP4.14-fr-2-20240530
Si vous utilisez des balises flottantes pour faire référence à des versions d’image de conteneur
dans des déploiements, il se peut que l’image obtenue lors de la restauration d’un déploiement ait
changé dans le registre de conteneurs. Ainsi, il est possible que l’image que vous exécutez après la
restauration ne soit pas l’image d’origine que vous avez utilisée.
Pour éviter ce problème, utilisez des flux d’images OpenShift pour référencer des images au lieu
de balises flottantes. Vous trouverez une description plus détaillée des flux d’images dans une
autre section de ce cours.
Références
Pour plus d’informations sur les stratégies de déploiement, reportez-vous à la
section Using Deployment Strategies (Utilisation de stratégies de déploiement) du
chapitre Deployments (Déploiements) de la documentation Building Applications
index#deployment-strategies
Pour plus d’informations sur les sondes Readiness, reportez-vous au chapitre

Monitoring Application Health by Using Health Checks (Contrôle de l’intégrité des
applications à l’aide de bilans de santé) de la documentation Building Applications
index#application-health
DO180-OCP4.14-fr-2-20240530 467
Exercice guidé
Mise à jour des paramètres et de l’image

de l’application
Mettez à jour les manifestes d’une base de données et d’une application Web, tout en
réduisant les interruptions de service pour leurs utilisateurs.
Résultats
Vous serez en mesure de suspendre, mettre à jour et reprendre un déploiement, ainsi que de
restaurer une application défaillante.
Avant De Commencer
exercice. Elle crée également le projet updates-rollout-db et y déploie une base de
données MySQL. Elle crée le projet updates-rollout-web, puis déploie une application
Web avec 10 réplicas.
La commande crée le fichier /home/student/DO180/labs/updates-rollout/

resources.txt. Le fichier resources.txt contient le nom des images et certaines des
commandes que vous utiliserez au cours de l’exercice. Vous pouvez utiliser le fichier pour
copier et coller ces noms d’image et ces commandes.
[student@workstation ~]$ lab start updates-rollout
Instructions
passe developer. Utilisez le projet updates-rollout-db.

Login successful.
1.2. Définissez le projet updates-rollout-db comme projet actif.
[student@workstation ~]$ oc project updates-rollout-db

468 DO180-OCP4.14-fr-2-20240530
2. Examinez les ressources créées par la commande lab. Vérifiez que vous pouvez vous
connecter à la base de données. La base de données MySQL utilise un stockage
éphémère.
2.1. Listez l’objet Deployment et vérifiez que le pod est disponible. Récupérez le nom
du conteneur. Vous utiliserez ces informations lors de la mise à jour de l’image de
conteneur au cours d’une autre étape.
[student@workstation ~]$ oc get deployment -o wide

mydb 1/1 0 1 17m mysql-80 ...
2.2. Listez les pods et vérifiez que le pod est en cours d’exécution. Il est probable que le
nom du pod soit différent sur votre système.
[student@workstation ~]$ oc get pod

mydb-5c79866d48-5xzkk 1/1 Running 0 18m
2.3. Récupérez le nom de l’image utilisée par le pod. Le pod utilise la version 1-224 de
l’image rhel9/mysql-80. Remplacez le nom du pod par celui de l’étape précédente.
[student@workstation ~]$ oc get pod mydb-5c79866d48-5xzkk \

La configuration de la salle de classe a copié cette image à partir de Red Hat

Ecosystem Catalog. L’image d’origine est registry.redhat.io/rhel9/
mysql-80.
2.4. Vérifiez que vous pouvez vous connecter au système de base de données en listant
les bases de données disponibles. Exécutez la commande mysql depuis l’intérieur du
pod et connectez-vous en tant qu’utilisateur operator1 avec test comme mot de
passe.
[student@workstation ~]$ oc rsh mydb-5c79866d48-5xzkk \

mysql --user=operator1 --password=test -e "SHOW DATABASES"
+--------------------+
| Database |
+--------------------+
| quotes |
+--------------------+
3. Vous devez appliquer plusieurs mises à jour à l’objet Deployment. Suspendez le

déploiement pour empêcher OpenShift de déployer l’application pour chaque modification
que vous effectuez. Après avoir suspendu le déploiement, modifiez le mot de passe de
l’utilisateur de base de données operator1, mettez à jour l’image de conteneur, puis
reprenez le déploiement.
3.1. Suspendez le déploiement mydb.
DO180-OCP4.14-fr-2-20240530 469
[student@workstation ~]$ oc rollout pause deployment/mydb

deployment.apps/mydb paused
3.2. Remplacez le mot de passe de l’utilisateur de base de données operator1 par

redhat123. Pour modifier le mot de passe, mettez à jour la variable d’environnement
MYSQL_PASSWORD dans le modèle de pod de l’objet Deployment.
[student@workstation ~]$ oc set env deployment/mydb MYSQL_PASSWORD=redhat123

deployment.apps/mydb updated
3.3. Étant donné que l’objet Deployment est suspendu, vérifiez que le nouveau mot de
passe n’est pas encore actif. Pour ce faire, exécutez à nouveau la commande mysql
en utilisant le mot de passe actuel. La connexion à la base de données est établie.
[student@workstation ~]$ oc rsh mydb-5c79866d48-5xzkk \

mysql --user=operator1 --password=test -e "SHOW DATABASES"
+--------------------+
| Database |
+--------------------+
| quotes |
+--------------------+
3.4. Mettez à jour l’image de conteneur MySQL vers la version 1-228.
[student@workstation ~]$ oc set image deployment/mydb \

mysql-80=registry.ocp4.example.com:8443/rhel9/mysql-80:1-228
deployment.apps/mydb image updated
3.5. Étant donné que l’objet Deployment est suspendu, vérifiez que le pod utilise
toujours la version d’image 1-224.
[student@workstation ~]$ oc get pod mydb-5c79866d48-5xzkk \

3.6. Reprenez le déploiement mydb.
[student@workstation ~]$ oc rollout resume deployment/mydb

deployment.apps/mydb resumed
3.7. Vérifiez que le nouveau déploiement est terminé en attendant que le nouveau pod
soit en cours d’exécution. Il est probable que le nom du pod soit différent sur votre
système.

mydb-dd5dcbddb-rmf85 1/1 Running 0 2m2s
470 DO180-OCP4.14-fr-2-20240530
4. Vérifiez qu’OpenShift a bien appliqué toutes vos modifications à l’objet Deployment.
4.1. Récupérez le nom de l’image utilisée par le nouveau pod. Dans la commande oc get
pod ci-dessous, utilisez le nom du nouveau pod comme paramètre. Le pod utilise à
présent la version d’image 1-228.
[student@workstation ~]$ oc get pod mydb-dd5dcbddb-rmf85 \

4.2. Vérifiez que vous pouvez vous connecter au système de base de données en
utilisant le nouveau mot de passe, redhat123, pour l’utilisateur de base de données
operator1.
[student@workstation ~]$ oc rsh mydb-dd5dcbddb-rmf85 \

mysql --user=operator1 --password=redhat123 -e "SHOW DATABASES"
+--------------------+
| Database |
+--------------------+
| quotes |
+--------------------+
5. Dans la deuxième partie de l’exercice, vous allez effectuer une mise à jour progressive
d’une application Web répliquée. Utilisez le projet updates-rollout-web et examinez les
ressources créées par la commande lab.
5.1. Définissez le projet updates-rollout-web comme projet actif.
[student@workstation ~]$ oc project updates-rollout-web

5.2. Listez l’objet Deployment et vérifiez que les pods sont disponibles. Récupérez le
nom des conteneurs. Vous utiliserez ces informations lors de la mise à jour de l’image
de conteneur au cours d’une autre étape.

version 10/10 10 10 32m versioned-hello ...
5.3. Listez les objets ReplicaSet. Étant donné qu’OpenShift n’a pas encore effectué de
mises à jour progressives, il n’existe qu’un seul objet ReplicaSet. Il est probable que
le nom de l’objet ReplicaSet soit différent sur votre système.
[student@workstation ~]$ oc get replicaset

version-7bfff6b5b4 10 10 10 11m
DO180-OCP4.14-fr-2-20240530 471
5.4. Récupérez le nom et la version de l’image que l’objet ReplicaSet utilise pour
déployer les pods. Les pods utilisent la version v1.0 de l’image redhattraining/
versioned-hello.
[student@workstation ~]$ oc get replicaset version-7bfff6b5b4 \

-o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'
registry.ocp4.example.com:8443/redhattraining/versioned-hello:v1.0
5.5. Vérifiez qu’une sonde Readiness est incluse dans le déploiement version. La sonde
effectue une requête HTTP GET sur le port 8080.
[student@workstation ~]$ oc get deployment version \

-o jsonpath='{.spec.template.spec.containers[0].readinessProbe}' | jq .
{
"failureThreshold": 3,
"httpGet": {
"path": "/",
"port": 8080,
"scheme": "HTTP"
},
"initialDelaySeconds": 3,
"periodSeconds": 10,
"successThreshold": 1,
"timeoutSeconds": 1
}
6. Pour observer la mise à jour progressive qui sera effectuée lors d’une étape ultérieure,
ouvrez une nouvelle fenêtre de terminal, puis exécutez le script ~/DO180/labs/
updates-rollout/curl_loop.sh que la commande lab a préparé. Le script envoie
des requêtes Web à l’application dans une boucle.
6.1. Ouvrez un nouveau terminal.
6.2. Exécutez le script /home/student/DO180/labs/updates-rollout/

curl_loop.sh. Laissez le script s’exécuter et ne l’interrompez pas.
[student@workstation ~]$ /home/student/DO180/labs/updates-rollout/curl_loop.sh

Hi!
Hi!
Hi!
Hi!
7. Modifiez l’image de conteneur du déploiement version. La nouvelle version de

l’application crée une page Web avec un message différent.
7.1. Revenez à la première fenêtre de terminal, puis utilisez la commande oc set image
pour mettre à jour le déploiement.
[student@workstation ~]$ oc set image deployment/version \

versioned-hello=registry.ocp4.example.com:8443/redhattraining/versioned-hello:v1.1
deployment.apps/version image updated
472 DO180-OCP4.14-fr-2-20240530
7.2. La modification de l’image a entraîné une mise à jour progressive. Observez la

sortie du script curl_loop.sh dans le deuxième terminal. Si la sortie du script
curl_loop.sh n’est pas mise à jour, appuyez sur Ctrl+c pour l’arrêter dans le
deuxième terminal. Ensuite, redémarrez le script.
Avant la mise à jour, seuls les pods qui exécutent la version v1.0 de l’application
répondent. Durant les mises à jour progressives, les anciens et les nouveaux pods
répondent. Après la mise à jour, seuls les pods qui exécutent la version v1.1 de
l’application répondent. La sortie suivante sera probablement différente sur votre
système.
Hi!
Hi!
Hi!
Hi!
Hi! v1.1
Hi! v1.1
Hi!
Hi! v1.1
Hi!
Hi! v1.1
Hi! v1.1
Hi! v1.1
Hi! v1.1
N’arrêtez pas le script.
8. Vérifiez que le processus de déploiement est arrivé à son terme. Listez les objets
ReplicaSet et vérifiez que le nouvel objet utilise la nouvelle version de l’image.
8.1. Utilisez la commande oc rollout status pour vérifier que le processus de

déploiement a réussi.
[student@workstation ~]$ oc rollout status deployment/version

deployment "version" successfully rolled out
8.2. Listez les objets ReplicaSet. L’objet initial a été réduit (scale-down) à zéro pod.
La taille du nouvel objet ReplicaSet a été augmentée (scale-up) sur 10 pods. Il est
probable que les noms des objets ReplicaSet soient différents sur votre système.

version-b7fddfc8c 10 10 10 3m40s
8.3. Récupérez le nom et la version de l’image que le nouvel objet ReplicaSet utilise.
Cette image fournit la nouvelle version de l’application.
[student@workstation ~]$ oc get replicaset version-b7fddfc8c \

-o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'
DO180-OCP4.14-fr-2-20240530 473
9. Restaurez le déploiement version.
9.1. Utilisez la commande oc rollout undo pour revenir à la version initiale de

l’application. Ignorez le message d’avertissement.
[student@workstation ~]$ oc rollout undo deployment/version

deployment.apps/version rolled back
9.2. Observez la sortie du script curl_loop.sh dans le deuxième terminal. Les pods qui
exécutent la version v1.0 de l’application répondent à nouveau. La sortie suivante
sera probablement différente sur votre système.
Hi! v1.1
Hi! v1.1
Hi! v1.1
Hi! v1.1
Hi!
Hi! v1.1
Hi!
Hi! v1.1
Hi! v1.1
Hi!
Hi!
Hi!
Appuyez sur Ctrl+C pour arrêter le script. Fermez ce deuxième terminal lorsque
vous avez terminé.
9.3. Listez les objets ReplicaSet. La taille de l’objet initial a été augmentée (scale-up)
sur 10 pods. L’objet de la nouvelle version de l’application a été réduit (scale-down) à
zéro pod.

version-b7fddfc8c 0 0 0 27m
Fin
[student@workstation ~]$ lab finish updates-rollout
474 DO180-OCP4.14-fr-2-20240530
Déploiements reproductibles avec des

flux d’images OpenShift
Résultats
• Garantir la reproductibilité des déploiements d’applications en utilisant des flux d’images et des
noms d’images courts.
Flux d’images
La distinction entre balise flottante et balise non flottante est de nature conventionnelle plutôt
que technique. Bien que cela soit déconseillé, il n’existe aucun mécanisme pour empêcher un
développeur d’envoyer (par push) une image différente vers une balise existante. Par conséquent,
il n’est pas garanti qu’un pod qui fait référence à une balise d’image récupère la même image
au redémarrage du pod. Les flux d’images résolvent ce problème et offrent également des
fonctionnalités de restauration essentielles.
Les flux d’images sont l’un des principaux éléments de différenciation entre OpenShift et
Kubernetes en amont. Les ressources Kubernetes font directement référence aux images
de conteneur, les ressources OpenShift, telles que les configurations de compilation, font
référence aux flux d’images. OpenShift étend également les ressources Kubernetes, telles que
les déploiements Kubernetes, avec des annotations qui les rendent compatibles avec des flux
d’images OpenShift.
Les flux d’images permettent à OpenShift d’assurer des déploiements reproductibles et stables
d’applications mises en conteneur, ainsi que des restaurations de déploiements sur leur dernier
état connu de fonctionnement correct.
Les flux d’images fournissent un nom stable et court pour faire référence à une image de
conteneur indépendante de toute configuration de serveur de registre et de configuration
d’exécution de conteneur.
Balises de flux d’images

Un flux d’images représente un ou plusieurs ensembles d’images de conteneur. Chaque ensemble,
ou flux, est identifié par une balise de flux d’images. Contrairement aux images de conteneur
dans un serveur de registre, qui comportent plusieurs balises du même référentiel d’images (ou
utilisateur ou organisation), un flux d’images peut avoir plusieurs balises de flux d’images qui
font référence à des images de conteneur à partir de différents serveurs de registre et différents
référentiels d’images.
Un flux d’images fournit des configurations par défaut pour un ensemble de balises de flux
d’images. Chaque balise de flux d’images fait référence à un flux d’images de conteneur et peut
remplacer la plupart des configurations de son flux d’images associé.
Dans l’illustration suivante, un déploiement qui utilise l’image Image-4 peut être restauré à
l’utilisation de l’image Image-3, car la balise de flux d’images ISTAT-B conserve un historique
des images utilisées :
DO180-OCP4.14-fr-2-20240530 475
Une balise de flux d’images stocke une copie des métadonnées relative à son image de conteneur
actuelle, notamment l’ID d’image SHA. L’ID d’image SHA est un identifiant unique que le registre
de conteneurs calcule et attribue aux images. Le stockage des métadonnées permet une
recherche et une inspection plus rapides des images de conteneur, dans la mesure où il n’est pas
nécessaire d’accéder au serveur de registre source.
Vous pouvez également configurer une balise de flux d’images de manière à stocker les couches
d’image source dans le registre de conteneur interne OpenShift, qui fait office de cache d’images
local. Le stockage des couches d’image évite d’aller les récupérer dans leur serveur de registre
source. Les consommateurs de l’image mise en cache, tels que les pods et les configurations de
déploiement, font simplement référence au registre interne comme registre source de l’image.
Pour mieux visualiser la relation entre les flux d’images et les balises de flux d’images, vous pouvez
explorer le projet openshift qui est créé au préalable dans tous les clusters OpenShift. Comme
vous pouvez le constater, il existe de nombreux flux d’images dans ce projet, y compris le flux
d’images php :
[user@host ~]$ oc get is -n openshift -o name

imagestream.image.openshift.io/nodejs
imagestream.image.openshift.io/perl
imagestream.image.openshift.io/php
imagestream.image.openshift.io/postgresql
imagestream.image.openshift.io/python
Il existe plusieurs balises pour le flux d’images php, et il existe une ressource de balise pour
chacune d’elles :
[user@host ~]$ oc get istag -n openshift | grep php

8.0-ubi9 image-registry ... 6 days ago
L’exécution de la commande oc describe sur un flux d’images affiche des informations

provenant à la fois du flux d’images et de ses balises :
476 DO180-OCP4.14-fr-2-20240530
[user@host ~]$ oc describe is php -n openshift

Name: php
Tags: 5
8.0-ubi9
tagged from registry.access.redhat.com/ubi9/php-80:latest
8.0-ubi8 (latest)
7.4-ubi8
7.3-ubi7
Dans l’exemple précédent, chacune des balises de flux d’images php fait référence à un nom
d’image différent.
Noms d’image, balises et ID

Le nom textuel d’une image de conteneur est une chaîne. Ce nom est parfois interprété comme
étant constitué de plusieurs composants, tels que registry-host-name/repository-or-
organization-or-user-name/image-name:tag-name, mais le fractionnement du nom
d’image en composants est une question de convention, et non de structure.
Un ID d’image SHA est un hachage SHA-256 qui identifie de façon unique une image de
conteneur immuable Vous ne pouvez pas modifier une image de conteneur. Au lieu de cela, vous
créez une image de conteneur qui possède un nouvel ID. Lorsque vous envoyez par push une
nouvelle image de conteneur à un serveur de registre, le serveur associe le nom textuel existant et
le nouvel ID d’image.
Lorsque vous démarrez un conteneur à partir d’un nom d’image, vous téléchargez l’image
actuellement associée à ce nom. L’ID d’image sous-jacent peut changer à tout moment et le
prochain conteneur que vous démarrerez aura peut-être un ID différent. Si l’image associée à un
nom d’image présente des problèmes, et que vous ne connaissez que le nom de l’image, vous ne
pouvez pas revenir à une image antérieure.
Les balises de flux d’images OpenShift conservent l’historique des derniers ID d’image qu’elles ont
récupérés d’un serveur de registre. L’historique des ID d’image est le flux d’images d’une balise
de flux d’images. Vous pouvez utiliser l’historique à l’intérieur d’une balise de flux d’images pour
revenir à une image précédente, si par exemple une nouvelle image de conteneur provoque une
erreur de déploiement.
La mise à jour d’une image de conteneur dans un registre externe ne met pas automatiquement
à jour une balise de flux d’images. La balise de flux d’images conserve la référence au dernier ID
d’image qu’elle a récupéré. Ce comportement est crucial pour l’évolutivité des applications, car il
isole OpenShift des changements qui se produisent au niveau d’un serveur de registre.
DO180-OCP4.14-fr-2-20240530 477
Supposons que vous déployiez une application à partir d’un registre externe, et qu’après quelques
jours de test avec quelques utilisateurs, vous décidiez d’étendre son déploiement pour accroître
son nombre d’utilisateurs. En attendant, votre fournisseur met à jour l’image du conteneur sur
le registre externe. Si OpenShift n’avait aucune balise de flux d’images, les nouveaux pods
obtiendraient la nouvelle image de conteneur, qui est différente de l’image sur le pod d’origine.
En fonction des modifications effectuées, cette nouvelle image pourrait entraîner l’échec de
votre application. Étant donné qu’OpenShift stocke l’ID de l’image d’origine dans une balise
de flux d’images, il peut créer des pods en utilisant le même ID d’image, et éviter ainsi toute
incompatibilité entre l’image d’origine et l’image mise à jour.
OpenShift conserve l’ID d’image du premier pod et s’assure que les nouveaux pods utilisent le
même ID. OpenShift garantit que tous les pods utilisent la même image.
Pour mieux visualiser la relation entre un flux d’images, une balise de flux d’images, un nom
d’image et un ID d’image, consultez la commande oc describe is suivante, qui affiche l’image
source et l’ID d’image actuelle pour chaque balise de flux d’images :

Name: php
8.0-ubi9
* registry.access.redhat.com/ubi9/php-80@sha256:2b82...f544
2 days ago
8.0-ubi8 (latest)
* registry.access.redhat.com/ubi8/php-80@sha256:2c74...5ef4
2 days ago
Si votre administrateur de cluster OpenShift a déjà mis à jour la balise de flux d’images php:8.0-
ubi9, la commande oc describe is affiche plusieurs ID d’image pour cette balise :

Name: php
8.0-ubi9
* registry.access.redhat.com/ubi9/php-80@sha256:2b82...f544
2 days ago
registry.access.redhat.com/ubi9/php-80@sha256:8840...94f0
5 days ago
registry.access.redhat.com/ubi9/php-80@sha256:506c...5d90
9 days ago
Dans l’exemple précédent, l’astérisque (*) indique quel ID d’image est l’ID actuel pour chaque
balise de flux d’images. Il s’agit généralement du dernier à être importé et du premier à être listé.
478 DO180-OCP4.14-fr-2-20240530
Lorsqu’une balise de flux d’images OpenShift fait référence à une image de conteneur d’un
registre externe, vous devez mettre à jour explicitement cette balise pour obtenir de nouveaux ID
d’image du registre externe. Par défaut, OpenShift ne surveille pas les enregistrements externes
pour les modifications apportées à l’ID d’image associé à un nom d’image.
Vous pouvez configurer une balise de flux d’images pour vérifier dans le registre externe les mises
à jour qui ont eu lieu selon un calendrier établi. Par défaut, les nouvelles balises de flux d’images
ne vérifient pas les images mises à jour.
Cas d'utilisation de flux d'images

Les flux d’images fournissent une approche d’évolution pour les workflows de conteneur d’une
organisation et peuvent améliorer la fiabilité et la résilience du déploiement.
Par exemple, une organisation peut commencer par télécharger des images de conteneur
directement à partir du registre public Red Hat, et plus tard, mettre en place un registre
d’entreprise comme un miroir de ces images pour économiser de la bande passante. Les
utilisateurs d’OpenShift ne remarqueraient aucun changement, car ils se réfèrent toujours à ces
images en utilisant le même nom de flux d’images. Les utilisateurs des outils de conteneur RHEL
remarqueraient la modification parce qu’ils devraient changer les noms de registre dans leurs
commandes ou leurs configurations de moteur de conteneur pour rechercher le miroir local en
premier.
Dans d’autres scénarios, l’indirection fournie par un flux d’images peut s’avérer utile. Supposons
que vous commenciez avec une image de conteneur de base de données qui présente des
problèmes de sécurité et que le fournisseur prenne trop de temps pour mettre à jour l’image
avec des correctifs. Plus tard, vous trouvez un autre fournisseur qui propose une autre image de
conteneur pour la même base de données, où ces problèmes de sécurité ont déjà été corrigés.
Mieux encore, il a démontré sa capacité à fournir des mises à jour en temps opportun. Si ces
images de conteneur disposent d’une configuration compatible des volumes et des variables
d’environnement, vous pouvez modifier votre flux d’images pour qu’il pointe vers l’image de l’autre
fournisseur.
Red Hat fournit des images de conteneur prises en charge et renforcées, telles que la base de
données MariaDB, qui fonctionnent principalement comme des remplacements d’images de
conteneur de certains projets Open Source répandus. Le remplacement de sources d’images peu
fiables par des solutions Red Hat prises en charge, lorsqu'elles sont disponibles, est une utilisation
par défaut des flux d'images.
Création de balises et de flux d’images

En plus des flux d’images dans le projet openshift, vous pouvez en créer dans votre projet afin
que les ressources de ce projet, telles que les objets Deployment, puissent les utiliser.
Utilisez la commande oc create is pour créer un flux d’images dans le projet en cours.
L’exemple suivant crée un flux d’images nommé keycloak :
[user@host ~]$ oc create is keycloak
Après avoir créé le flux d’images, utilisez la commande oc create istag pour ajouter des
balises de flux d’images. L’exemple suivant ajoute la balise 20.0 au flux d’images keycloak.
Dans cet exemple, la balise de flux d’images fait référence à l’image quay.io/keycloak/
keycloak:20.0.2 du référentiel public Quay.io.
DO180-OCP4.14-fr-2-20240530 479
[user@host ~]$ oc create istag keycloak:20.0 \

--from-image quay.io/keycloak/keycloak:20.0.2
Répétez la commande précédente si vous avez besoin de balises de flux d’images

supplémentaires :
[user@host ~]$ oc create istag keycloak:19.0 \

--from-image quay.io/keycloak/keycloak:19.0
Utilisez la commande oc tag SOURCE-IMAGE IMAGE-STREAM-TAG pour mettre à jour une

balise de flux d’images avec une nouvelle référence d’image source. L’exemple suivant modifie la
balise de flux d’images keycloak:20.0 pour qu’elle pointe vers l’image quay.io/keycloak/
keycloak:20.0.3.
[user@host ~]$ oc tag quay.io/keycloak/keycloak:20.0.3 keycloak:20.0
Utilisez la commande oc describe is pour vérifier que la balise de flux d’images pointe vers
l’ID SHA de l’image source :
[user@host ~]$ oc describe is keycloak

Name: keycloak
Namespace: myproject
Labels: <none>
Annotations: openshift.io/image.dockerRepositoryCheck=2023-01-31T11:12:44Z
Image Repository: image-registry.openshift-image-registry.svc:5000/.../keycloak
Image Lookup: local=false
Unique Images: 3
Tags: 2
20.0
tagged from quay.io/keycloak/keycloak:20.0.3
* quay.io/keycloak/keycloak@sha256:c167...62e9
47 seconds ago
quay.io/keycloak/keycloak@sha256:5569...b311
5 minutes ago
19.0
tagged from quay.io/keycloak/keycloak:19.0
* quay.io/keycloak/keycloak@sha256:40cc...ffde
5 minutes ago
Importation périodique de balises de flux d’images

Lorsque vous créez une balise de flux d’images, OpenShift la configure avec l’ID SHA de l’image
source que vous spécifiez. Après cette création initiale, la balise de flux d’images ne change pas,
même si le développeur envoie une nouvelle version de l’image source par push.
480 DO180-OCP4.14-fr-2-20240530
L’utilisation de balises de flux d’images vous permet de contrôler les images utilisées par vos
applications. Si vous souhaitez utiliser une nouvelle version de l’image, vous devez mettre à jour
manuellement la balise de flux d’images pour qu’elle pointe vers cette nouvelle version.
Cependant, pour certains registres de conteneurs auxquels vous faites confiance, ou pour
certaines images spécifiques, vous préférerez peut-être que les balises de flux d’images soient
actualisées automatiquement.
Par exemple, Red Hat met régulièrement à jour les images de Red Hat Ecosystem Catalog avec
des correctifs de bogues et de sécurité. Pour bénéficier de ces mises à jour dès que Red Hat les
publie, vous pouvez configurer vos balises de flux d’images de sorte qu’elles soient actualisées
régulièrement.
OpenShift peut vérifier périodiquement si une nouvelle version d’image est disponible. Lorsqu’il
détecte une nouvelle version, il met automatiquement à jour la balise de flux d’images. Pour
activer cette actualisation périodique, ajoutez l’option --scheduled à la commande oc tag.
[user@host ~]$ oc tag quay.io/keycloak/keycloak:20.0.3 keycloak:20.0 --scheduled
Par défaut, OpenShift vérifie l’image toutes les 15 minutes. Il s’agit d’un paramètre que les
administrateurs de votre cluster peuvent adapter.
Configuration de l’extraction d’image

Quand OpenShift démarre un pod qui utilise une balise de flux d’images, il extrait l’image
correspondante du registre de conteneurs source.
Si l’image provient d’un registre sur Internet, son extraction peut prendre du temps, voire échouer
en cas d’indisponibilité du réseau. Certains registres publics s’accompagnent de règles de
limitation de bande passante qui peuvent ralentir davantage encore vos téléchargements.
Pour atténuer ces problèmes, vous pouvez configurer vos balises de flux d’images de manière à
mettre en cache les images dans le registre de conteneurs OpenShift interne. La première fois
qu’OpenShift extrait l’image, il la télécharge à partir du référentiel source, puis la stocke dans son
registre interne. Après cette extraction initiale, OpenShift récupère l’image dans le registre interne.
Pour activer l’extraction d’image, ajoutez l’option --reference-policy local à la commande

oc tag.
[user@host ~]$ oc tag quay.io/keycloak/keycloak:20.0.3 keycloak:20.0 \

--reference-policy local
Utilisation de flux d’images dans les déploiements

Lorsque vous créez un objet Deployment, vous pouvez spécifier un flux d’images au lieu d’une
image de conteneur à partir d’un registre. L’utilisation d’un flux d’images dans des ressources de
charge de travail Kubernetes, telles que les déploiements, requiert une certaine préparation :
• Créez l’objet de flux d’images dans le même projet que l’objet Deployment.
• Activez la politique de recherche locale dans l’objet de flux d’images.
• Dans l’objet Deployment, référencez la balise de flux d’images par son nom, tel que
keycloak:20.0, et non par le nom d’image complet issu du registre source.
DO180-OCP4.14-fr-2-20240530 481
Activation de la politique de recherche locale

Lorsque vous utilisez un flux d’images dans un objet Deployment, OpenShift le recherche dans
le projet en cours. Cependant, il recherche uniquement les flux d’images pour lesquels vous avez
activé la politique de recherche locale.
Utilisez la commande oc set image-lookup pour activer la politique de recherche locale pour
un flux d’images :
[user@host ~]$ oc set image-lookup keycloak
Utilisez la commande oc describe is pour vérifier que la politique est active :

Name: keycloak
Created: 3 hours ago
Labels: <none>
Annotations: openshift.io/image.dockerRepositoryCheck=2023-01-31T11:12:44Z
Image Repository: image-registry.openshift-image-registry.svc:5000/.../keycloak
Image Lookup: local=true
Unique Images: 3
Tags: 2
Vous pouvez également récupérer l’état de la politique de recherche locale pour tous les
flux d’images du projet en cours en exécutant la commande oc set image-lookup sans
paramètres :
[user@host ~]$ oc set image-lookup

NAME LOCAL
keycloak true
zabbix-agent false
nagios false
Pour désactiver la politique de recherche locale, ajoutez l’option --enabled=false à la

commande oc set image-lookup :
[user@host ~]$ oc set image-lookup keycloak --enabled=false
Configuration de flux d’images dans les déploiements

Lorsque vous créez un objet Deployment à l’aide de la commande oc create deployment,
utilisez l’option --image pour spécifier la balise de flux d’images :
[user@host ~]$ oc create deployment mykeycloak --image keycloak:20.0
Lorsque vous utilisez un nom court, OpenShift recherche un flux d’images correspondant dans le
projet en cours. OpenShift prend uniquement en compte les flux d’images pour lesquels vous avez
activé la politique de recherche locale. S’il ne trouve pas de flux d’images, il recherche une image
de conteneur standard dans les registres de conteneurs autorisés. Consultez la documentation de
référence à la fin de ce cours pour savoir comment configurer ces registres autorisés.
482 DO180-OCP4.14-fr-2-20240530
Vous pouvez également utiliser des flux d’images avec d’autres ressources de charge de travail
Kubernetes :
• Objets Job que vous pouvez créer à l’aide de la commande suivante :
[user@host ~]$ oc create job NAME --image IMAGE-STREAM-TAG -- COMMAND
• Objets CronJob que vous pouvez créer à l’aide de la commande suivante :
[user@host ~]$ oc create cronjob NAME --image IMAGE-STREAM-TAG \

--schedule CRON-SYNTAX -- COMMAND
• Objets Pod que vous pouvez créer à l’aide de la commande suivante :
[user@host ~]$ oc run NAME --image IMAGE-STREAM-TAG
Une autre section de ce cours explique comment la modification d’une balise de flux d’images
peut mettre en œuvre automatiquement les déploiements associés.
Références
Pour plus d’informations sur les flux d’images, reportez-vous au chapitre Managing
Image Streams (Gestion de flux d’images) de la documentation Images de Red Hat
openshift_container_platform/4.14/html-single/images/index#managing-image-
streams
Pour plus d’informations sur l’utilisation de flux d’images avec des déploiements,
reportez-vous au chapitre Using Image Streams with Kubernetes Resources
(Utilisation de flux d’images avec des ressources Kubernetes) de la documentation
Images de Red Hat OpenShift Container Platform 4.14, disponible à l’adresse
openshift_container_platform/4.14/html-single/images/index#using-
imagestreams-with-kube-resources
Pour plus d’informations sur la configuration des registres de conteneurs dans

OpenShift, reportez-vous au chapitre Image Configuration Resources (Ressources
de configuration des images) dans la documentation Images de Red Hat OpenShift
openshift_container_platform/4.14/html-single/images/index#image-configuration
Simplifier la gestion des images de conteneur dans Kubernetes avec des flux
d’images OpenShift
https://cloud.redhat.com/blog/image-streams-faq
DO180-OCP4.14-fr-2-20240530 483
Exercice guidé
Déploiements reproductibles avec des

flux d’images OpenShift
Déployez une application qui référence indirectement des images de conteneur en utilisant
des flux d’images.
Résultats
Vous serez en mesure de créer des flux d’images et des balises de flux d’images, ainsi que de
déployer des applications qui utilisent des balises de flux d’images.
Avant De Commencer
cet exercice. Elle crée également le projet updates-imagestreams et le fichier /
home/student/DO180/labs/updates-imagestreams/resources.txt. Le fichier
resources.txt contient le nom des images et certaines des commandes que vous
utiliserez au cours de l’exercice. Vous pouvez utiliser le fichier pour copier et coller ces noms
d’image et ces commandes.
[student@workstation ~]$ lab start updates-imagestreams
Instructions
passe developer. Utilisez le projet updates-imagestreams.

Login successful.
1.2. Définissez le projet updates-imagestreams comme projet actif.
[student@workstation ~]$ oc project updates-imagestreams

2. Créez le flux d’images versioned-hello et la balise de flux d’images v1.0 à partir

de l’image registry.ocp4.example.com:8443/redhattraining/versioned-
hello:v1.0.
2.1. Utilisez la commande oc create is pour créer le flux d’images.
484 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ oc create is versioned-hello

imagestream.image.openshift.io/versioned-hello created
2.2. Utilisez la commande oc create istag pour créer la balise de flux d’images.
[student@workstation ~]$ oc create istag versioned-hello:v1.0 \

--from-image registry.ocp4.example.com:8443/redhattraining/versioned-hello:v1.0
imagestreamtag.image.openshift.io/versioned-hello:v1.0 created
3. Activez la résolution de flux d’images pour versioned-hello afin que les ressources
Kubernetes du projet en cours puissent l’utiliser.
3.1. Utilisez la commande oc set image-lookup pour activer la résolution de

recherche d’images.
[student@workstation ~]$ oc set image-lookup versioned-hello

imagestream.image.openshift.io/versioned-hello image lookup updated
3.2. Exécutez la commande oc set image-lookup sans aucun argument pour vérifier
votre travail.
[student@workstation ~]$ oc set image-lookup

NAME LOCAL
versioned-hello true
4. Examinez le flux d’images et vérifiez que sa balise fait référence à l’image

source par son ID SHA. Vérifiez que l’image source dans le registre
registry.ocp4.example.com:8443 a le même ID SHA.
4.1. Récupérez les détails du flux d’images versioned-hello.
Note
[student@workstation ~]$ oc describe is versioned-hello

Name: versioned-hello
Namespace: updates-imagestreams
v1.0
tagged from registry.ocp4.example.com:8443/redhattraining/versioned-hello:v1.0
* registry.ocp4.example.com:8443/.../versioned-hello@sha256:66e0...105e
7 minutes ago
DO180-OCP4.14-fr-2-20240530 485
4.2. Utilisez la commande oc image info pour interroger l’image à partir du registre de
conteneurs de la salle de classe. L’ID d’image SHA est le même que celui de la balise
de flux d’images.

Name: registry.ocp4.example.com:8443/redhattraining/versioned-hello:v1.0
Digest: sha256:66e0...105e
Media Type: application/vnd.docker.distribution.manifest.v2+json
5. Créez un déploiement nommé version qui utilise la balise de flux d’images versioned-
hello:v1.0.
5.1. Utilisez la commande oc create deployment pour créer l’objet.
[student@workstation ~]$ oc create deployment version --image versioned-hello:v1.0

deployment.apps/version created

version-744bf7694b-bzhd2 1/1 Running 0 2m11s
6. Vérifiez que le déploiement et le pod font tous deux référence à l’image par son ID SHA.
6.1. Récupérez l’image utilisée par le déploiement. Le déploiement fait référence à

l’image du registre source par son ID SHA. La balise de flux d’images v1.0 pointe
également vers cet ID d’image SHA.

... IMAGES ...
... registry.ocp4.example.com:8443/.../versioned-hello@sha256:66e0...105e ...
6.2. Récupérez l’image utilisée par le pod. Le pod fait également référence à l’image par
son ID SHA.
[student@workstation ~]$ oc get pod version-744bf7694b-bzhd2 \

registry.ocp4.example.com:8443/redhattraining/versioned-hello@sha256:66e0...105e
Fin
[student@workstation ~]$ lab finish updates-imagestreams
486 DO180-OCP4.14-fr-2-20240530
DO180-OCP4.14-fr-2-20240530 487
Mises à jour automatiques des images

avec les déclencheurs de changement
d’image OpenShift
Résultats
• Garantir la mise à jour automatique des pods d’application en utilisant des flux d’images avec les
ressources de charge de travail Kubernetes.
Utilisation de déclencheurs pour gérer les images

Les balises de flux d’images enregistrent l’ID SHA de l’image de conteneur source. Ainsi, une
balise de flux d’images pointe toujours vers une image immuable.
Si une nouvelle version de l’image source est disponible, vous pouvez modifier la balise de flux
d’images pour qu’elle pointe vers cette nouvelle image. Cependant, un objet Deployment
qui utilise la balise de flux d’images n’est pas déployé automatiquement. Pour un déploiement
automatique, vous devez configurer l’objet Deployment avec un déclencheur d’image.
Si vous mettez à jour une balise de flux d’images pour qu’elle pointe vers une nouvelle version de
l’image et que vous constatez que cette version ne fonctionne pas comme prévu, vous pouvez
restaurer la balise en question. Les objets Deployment pour lesquels vous avez configuré un
déclencheur restaurent automatiquement cette image antérieure.
D’autres charges de travail Kubernetes acceptent également les déclencheurs d’image, tels que
les objets Pod, CronJob et Job.
Configuration d’un déclencheur d’image pour les

déploiements
Avant de pouvoir configurer des déclencheurs d’images pour un objet Deployment, assurez-vous
que l’objet Deployment utilise des balises de flux d’images pour ses conteneurs :
• Créez l’objet de flux d’images dans le même projet que l’objet Deployment.
• Activez la politique de recherche locale dans l’objet de flux d’images à l’aide de la commande oc
set image-lookup.
• Dans l’objet Deployment, référencez les balises de flux d’images par leurs noms, comme
keycloak:20, et non par les noms d’images complets issus du registre source.
Les déclencheurs d’images s’appliquent au niveau du conteneur. Si votre objet Deployment inclut
plusieurs conteneurs, vous pouvez spécifier un déclencheur pour chacun d’eux. Avant de pouvoir
définir des déclencheurs, vous devez récupérer les noms des conteneurs :
[user@host ~]$ oc get deployment mykeycloak -o wide

mykeycloak 0/1 1 0 6s keycloak ...
Utilisez la commande oc set triggers pour configurer un déclencheur d’image pour le

conteneur à l’intérieur de l’objet Deployment. Utilisez l’option --from-image pour spécifier la
balise de flux d’images à surveiller.
488 DO180-OCP4.14-fr-2-20240530
[user@host ~]$ oc set triggers deployment/mykeycloak --from-image keycloak:20 \

--containers keycloak
Pour fournir un déploiement d’image automatique pour les objets Deployment, OpenShift ajoute
l’annotation image.openshift.io/triggers afin de stocker la configuration au format JSON.
L’exemple suivant récupère le contenu de l’annotation image.openshift.io/triggers, puis

utilise la commande jq pour afficher la configuration dans un format plus lisible :
[user@host ~]$ oc get deployment mykeycloak \

-o jsonpath='{.metadata.annotations.image\.openshift\.io/triggers}' | jq .
[
{
"from": {
"kind": "ImageStreamTag",
"name": "keycloak:20"
},
"fieldPath": "spec.template.spec.containers[?(@.name==\"keycloak\")].image"
}
]
L’attribut fieldPath est une expression JSONPath qu’OpenShift utilise pour rechercher
l’attribut qui stocke le nom de l’image de conteneur. OpenShift met à jour cet attribut avec le
nouvel ID SHA et le nouveau nom d’image chaque fois que la balise de flux d’images est modifiée.
Pour une vue plus concise, utilisez la commande oc set triggers avec le nom de l’objet
Deployment comme argument :
[user@host ~]$ oc set triggers deployment/mykeycloak

NAME TYPE VALUE AUTO
deployments/mykeycloak config true
deployments/mykeycloak image keycloak:20 (keycloak) true
OpenShift utilise le déclencheur de configuration pour mettre en œuvre le déploiement

chaque fois que vous modifiez sa configuration ; par exemple, pour mettre à jour des
variables d’environnement ou pour configurer la sonde Readiness.
OpenShift surveille la balise de flux d’images keycloak:20 utilisée par le conteneur

keycloak.
La valeur true située sous la colonne AUTO indique que le déclencheur est activé.
Vous pouvez désactiver le déclencheur de configuration à l’aide de la commande oc rollout

pause et le réactiver avec la commande oc rollout resume.
Vous pouvez désactiver le déclencheur d’image en ajoutant l’option --manual à la commande oc

set triggers :
[user@host ~]$ oc set triggers deployment/mykeycloak --manual \

--from-image keycloak:20 --containers keycloak
Pour réactiver le déclencheur, utilisez l’option --auto :
DO180-OCP4.14-fr-2-20240530 489
[user@host ~]$ oc set triggers deployment/mykeycloak --auto \

--from-image keycloak:20 --containers keycloak
Vous pouvez supprimer les déclencheurs de tous les conteneurs de l’objet Deployment en
ajoutant l’option --remove-all à la commande :
[user@host ~]$ oc set triggers deployment/mykeycloak --remove-all
Mise en œuvre des déploiements

Un objet Deployment avec un déclencheur d’image est automatiquement déployé lorsque la
balise de flux d’images est modifiée.
La balise de flux d’images peut changer, car vous la mettez à jour manuellement pour qu’elle
pointe vers une nouvelle version de l’image source. Ce changement peut également être effectué
automatiquement si vous configurez la balise pour une actualisation périodique, en ajoutant
l’option --scheduled à la commande oc tag. Lorsque la balise de flux d’images change
automatiquement, tous les objets Deployment disposant d’un déclencheur qui y fait référence
sont également déployés.
Restauration des déploiements

Pour les objets Kubernetes Deployment, pour restaurer le déploiement, vous rétablissez la balise
de flux d’images. Lors du rétablissement de cette balise, OpenShift déploie l’objet Deployment
pour utiliser à nouveau l’image précédente vers laquelle elle pointe.
Gestion des balises de flux d’images

Vous pouvez créer des flux d’images et des balises de flux d’images de plusieurs manières.
Les commandes suivantes effectuent la même opération. Elles créent toutes le flux d’images
keycloak s’il n’existe pas, puis la balise de flux d’images keycloak:20.0.2 :
[user@host ~]$ oc create istag keycloak:20.0.2 \

[user@host ~]$ oc import-image keycloak:20.0.2 \

--from quay.io/keycloak/keycloak:20.0.2 --confirm
[user@host ~]$ oc tag quay.io/keycloak/keycloak:20.0.2 keycloak:20.0.2
Vous pouvez réexécuter les commandes oc import-image et oc tag pour mettre à jour la
balise de flux d’images à partir de l’image source. Si l’image source change, les commandes
mettent à jour la balise de flux d’images pour qu’elle pointe vers cette nouvelle version.
Cependant, vous ne pouvez utiliser la commande oc create istag que pour la création
initiale de la balise de flux d’images. Vous ne pouvez pas mettre à jour les balises à l’aide de cette
commande.
Pour plus d’informations sur les commandes, utilisez l’option --help.
Vous pouvez créer plusieurs balises de flux d’images pointant vers la même image. La commande
suivante crée la balise de flux d’images keycloak:20 qui pointe vers la même image que la balise
keycloak:20.0.2. En d’autres termes, la balise de flux d’images keycloak:20 est un alias de
la balise keycloak:20.0.2.
490 DO180-OCP4.14-fr-2-20240530
[user@host ~]$ oc tag --alias keycloak:20.0.2 keycloak:20
La commande oc describe is signale que les deux balises pointent vers la même image :

Name: keycloak
20.0.2 (20)
* quay.io/keycloak/keycloak@sha256:5569...b311
3 minutes ago
L’utilisation d’alias est un concept semblable à celui des balises flottantes pour les images de
conteneur. Supposons qu’une nouvelle version d’image soit disponible dans le référentiel Quay.io.
Vous pouvez créer une balise de flux d’images pour cette nouvelle image :
[user@host ~]$ oc create istag keycloak:20.0.3 \

imagestreamtag.image.openshift.io/keycloak:20.0.3 created
Name: keycloak
20.0.3
36 seconds ago
20.0.2 (20)
About an hour ago
La balise de flux d’images keycloak:20 ne change pas. Par conséquent, les objets Deployment
qui l’utilisent ne sont pas déployés.
Après avoir testé la nouvelle image, vous pouvez déplacer la balise keycloak:20 pour qu’elle
pointe vers la nouvelle balise de flux d’images :

Tag keycloak:20 set up to track keycloak:20.0.3.
Name: keycloak
DO180-OCP4.14-fr-2-20240530 491
20.0.3 (20)
10 minutes ago
20.0.2
About an hour ago
Étant donné que la balise de flux d’images keycloak:20 pointe vers une nouvelle image,
OpenShift déploie tous les objets Deployment qui l’utilisent.
Si la nouvelle application ne fonctionne pas comme prévu, vous pouvez restaurer les déploiements
en réinitialisant la balise keycloak:20 sur la balise de flux d’images précédente :
En fournissant un niveau d’indirection, les flux d’images vous permettent de contrôler la gestion
des images de conteneur que vous utilisez dans votre cluster OpenShift.
Références
Pour plus d’informations sur les déclencheurs d’images, reportez-vous au chapitre
Triggering Updates on Image Stream Changes (Déclenchement de mises à jour
lors des changements du flux d’images) de la documentation Images de Red Hat
openshift_container_platform/4.14/html-single/images/index#triggering-updates-
on-imagestream-changes
Pour plus d’informations sur les balises de flux d’images, reportez-vous à la

section Tagging Images (Balisage d’images) du chapitre Managing Images
(Gestion d’images) de la documentation Images de Red Hat OpenShift Container
openshift_container_platform/4.14/html-single/images/index#tagging-images
Using Red Hat OpenShift Image Streams with Kubernetes Deployments

https://developers.redhat.com/blog/2019/09/20/using-red-hat-openshift-image-
streams-with-kubernetes-deployments
(Utilisation de flux d’images Red Hat OpenShift avec des déploiements Kubernetes)
492 DO180-OCP4.14-fr-2-20240530
Exercice guidé
Mises à jour automatiques des images

avec les déclencheurs de changement
d’image OpenShift
Mettez à jour une application qui référence indirectement des images de conteneur via des
flux d’images.
Résultats
• Ajouter un déclencheur d’image à un déploiement.
• Modifier une balise de flux d’images pour qu’elle pointe vers une nouvelle image.
• Surveiller le déploiement de l’application.
• Restaurer un déploiement sur l’image précédente.
Avant De Commencer
exercice. Elle crée également le projet updates-triggers et déploie une application Web
avec 10 réplicas.
La commande crée le fichier /home/student/DO180/labs/updates-triggers/

resources.txt. Le fichier resources.txt contient le nom des images et certaines des
commandes que vous utiliserez au cours de l’exercice. Vous pouvez utiliser le fichier pour
copier et coller ces noms d’image et ces commandes.
[student@workstation ~]$ lab start updates-triggers
Instructions
passe developer. Utilisez le projet updates-triggers.

Login successful.
1.2. Définissez le projet updates-triggers comme projet actif.
DO180-OCP4.14-fr-2-20240530 493
[student@workstation ~]$ oc project updates-triggers

2. Examinez le flux d’images versioned-hello créé par la commande lab.
2.1. Vérifiez que la commande lab a activé la politique de recherche locale pour le flux
d’images versioned-hello.

NAME LOCAL
versioned-hello true
2.2. Vérifiez que la commande lab a créé par la balise de flux d’images versioned-
hello:1. La balise de flux d’images fait référence à l’image dans le registre de la
salle de classe par son ID SHA.
Note
Sur votre système, les commandes renvoient les chaînes SHA-256 complètes. Vous
devez également saisir la chaîne SHA-256 complète pour fournir un tel paramètre à
une commande.
[student@workstation ~]$ oc get istag

NAME IMAGE REFERENCE ...
versioned-hello:1 ...:8443/redhattraining/versioned-hello@sha256:66e0...105e ...
2.3. Vérifiez que la commande lab a créé par la balise de flux d’images versioned-
hello:1 à partir de l’image registry.ocp4.example.com:8443/
redhattraining/versioned-hello:1-123.
[student@workstation ~]$ oc get istag versioned-hello:1 \

-o jsonpath='{.tag.from.name}{"\n"}'
registry.ocp4.example.com:8443/redhattraining/versioned-hello:1-123
3. Examinez l’objet Deployment créé par la commande lab. Vérifiez que l’application est
disponible depuis l’extérieur du cluster.
3.1. Listez les objets Deployment. Le déploiement version a récupéré l’ID d’image
SHA à partir de la balise de flux d’images versioned-hello:1. L’objet
Deployment inclut un conteneur nommé versioned-hello. Vous utiliserez ces
informations au cours d’une étape ultérieure, lors de la configuration du déclencheur.

version 10/10 ... versioned-hello .../versioned-hello@sha256:66e0...105e ...
3.2. Ouvrez un nouveau terminal.
494 DO180-OCP4.14-fr-2-20240530
3.3. Exécutez le script /home/student/DO180/labs/updates-triggers/

curl_loop.sh que la commande lab a préparé. Le script envoie des requêtes Web
à l’application dans une boucle. Laissez le script s’exécuter et ne l’interrompez pas.
[student@workstation ~]$ /home/student/DO180/labs/updates-triggers/curl_loop.sh

Hi!
Hi!
Hi!
Hi!
4. Ajoutez un déclencheur d’image à l’objet Deployment.
4.1. Revenez à la première fenêtre de terminal, puis utilisez la commande oc set

triggers pour ajouter le déclencheur de la balise de flux d’images versioned-
hello:1 au conteneur versioned-hello.
[student@workstation ~]$ oc set triggers deployment/version \

--from-image versioned-hello:1 --containers versioned-hello
deployment.apps/version triggers updated
4.2. Examinez la définition du déclencheur à partir de l’annotation

image.openshift.io/triggers.
[student@workstation ~]$ oc get deployment version \

-o jsonpath='{.metadata.annotations.image\.openshift\.io/triggers}' | jq .
[
{
"from": {
"kind": "ImageStreamTag",
"name": "versioned-hello:1"
},
"fieldPath": "spec.template.spec.containers[?(@.name==\"versioned-hello
\")].image"
}
]
5. Mettez à jour la balise de flux d’images versioned-hello:1 pour qu’elle pointe vers la
balise 1-125 de l’image registry.ocp4.example.com:8443/redhattraining/
versioned-hello. Observez la sortie du script curl_loop.sh pour vérifier que l’objet
Deployment est déployé automatiquement.
5.1. Utilisez la commande oc tag pour mettre à jour la balise versioned-hello:1.
[student@workstation ~]$ oc tag \

registry.ocp4.example.com:8443/redhattraining/versioned-hello:1-125 \
versioned-hello:1
Tag versioned-hello:1 set to registry.ocp4.example.com:8443/redhattraining/
versioned-hello:1-125.
5.2. La modification de la balise de flux d’images a déclenché une mise à jour progressive.
Observez la sortie du script curl_loop.sh dans le deuxième terminal.
DO180-OCP4.14-fr-2-20240530 495
Avant la mise à jour, seuls les pods qui exécutent la version précédente de l’image
répondent. Pendant les mises à jour progressives, les anciens et les nouveaux pods
répondent. Après la mise à jour, seuls les pods qui exécutent la dernière version
de l’image répondent. La sortie suivante sera probablement différente sur votre
système.
Hi!
Hi!
Hi!
Hi!
Hi! v1.1
Hi! v1.1
Hi!
Hi! v1.1
Hi!
Hi! v1.1
Hi! v1.1
Hi! v1.1
Hi! v1.1
N’arrêtez pas le script.
6. Examinez l’objet Deployment et le flux d’images.
6.1. Listez le déploiement version et notez que l’image a changé.
[student@workstation ~]$ oc get deployment version -o wide

version 10/10 ... versioned-hello .../versioned-hello@sha256:834d...fcb4 ...
6.2. Affichez les détails du flux d’images versioned-hello. La balise de flux d’images
versioned-hello:1 pointe vers l’image ayant le même ID SHA que dans l’objet
Deployment.
Notez que l’image précédente est toujours disponible. À l’étape suivante, vous allez
restaurer cette image en spécifiant son ID SHA.
[student@workstation ~]$ oc describe is versioned-hello

Name: versioned-hello
Namespace: updates-triggers
1
tagged from registry.ocp4.example.com:8443/redhattraining/versioned-hello:1-125
* registry.ocp4.example.com:8443/.../versioned-hello@sha256:834d...fcb4
6 minutes ago
registry.ocp4.example.com:8443/.../versioned-hello@sha256:66e0...105e
37 minutes ago
7. Restaurez l’objet Deployment en rétablissant la balise de flux d’images versioned-

hello:1.
496 DO180-OCP4.14-fr-2-20240530
7.1. Utilisez la commande oc tag. Pour l’image source, copiez et collez l’ancien nom
d’image et l’ID SHA à partir de la sortie de la commande précédente.
[student@workstation ~]$ oc tag \

registry.ocp4.example.com:8443/redhattraining/versioned-hello@sha256:66e0...105e \
versioned-hello:1
Tag versioned-hello:1 set to registry.ocp4.example.com:8443/redhattraining/
versioned-hello@sha256:66e0...105e.
7.2. Observez la sortie du script curl_loop.sh dans le deuxième terminal. Les pods qui
exécutent la version v1.0 de l’application répondent à nouveau. La sortie suivante
sera probablement différente sur votre système.
Hi! v1.1
Hi! v1.1
Hi! v1.1
Hi! v1.1
Hi!
Hi! v1.1
Hi! v1.1
Hi! v1.1
Hi!
Hi! v1.1
Hi! v1.1
Hi!
Hi!
Hi!
Appuyez sur Ctrl+C pour arrêter le script. Fermez ce deuxième terminal lorsque
vous avez terminé.
Fin
[student@workstation ~]$ lab finish updates-triggers
DO180-OCP4.14-fr-2-20240530 497
Open Lab
Gestion des mises à jour des applications

Mettez à jour deux applications en ligne vers les versions les plus récentes, identifiées par
des balises non flottantes.
Résultats
Vous serez en mesure de configurer des objets Deployment avec des images et des
déclencheurs, ainsi que des alias et des balises de flux d’images.
Avant De Commencer
exercice. Elle crée également le projet updates-review et y déploie deux applications,
app1 et app2.
La commande crée le fichier /home/student/DO180/labs/updates-review/

resources.txt. Le fichier resources.txt contient le nom des images que vous
utiliserez au cours de l’exercice. Vous pouvez utiliser ce fichier pour copier et coller ces noms
d’image.
[student@workstation ~]$ lab start updates-review
Instructions

developer. Utilisez le projet updates-review pour votre travail.
1. Votre équipe a créé le déploiement app1 dans le projet updates-review à partir de
l’image de conteneur registry.ocp4.example.com:8443/redhattraining/php-
ssl:latest. Récemment, un développeur de votre organisation a envoyé (push) une
nouvelle version de l’image, puis a réaffecté la balise latest à cette version.
Reconfigurez le déploiement app1 de manière à utiliser la balise statique 1-222 au lieu de la
balise flottante latest, afin d’éviter un redéploiement accidentel de votre application avec
des versions d’image non testées que vos développeurs peuvent publier à tout moment.
2. Le déploiement app2 utilise la balise de flux d’images php-ssl:1, qui est un alias de la
balise php-ssl:1-222.
Activez le déclenchement d’image pour le déploiement app2, de sorte que chaque fois que
la balise de flux d’images php-ssl:1 change, OpenShift déploie l’application. Vous testerez
votre configuration lors d’une étape ultérieure, lorsque vous réaffecterez l’alias php-ssl:1 à
une nouvelle balise de flux d’images.
498 DO180-OCP4.14-fr-2-20240530
3. Une nouvelle version de l’image, registry.ocp4.example.com:8443/

redhattraining/php-ssl:1-234, est disponible dans le registre de conteneurs. Votre
équipe en charge de l’assurance qualité a testé et approuvé cette version. Elle est prête pour
la production.
Créez la balise de flux d’images php-ssl:1-234 qui pointe vers la nouvelle image. Déplacez
l’alias de balise de flux d’images php-ssl:1 vers la nouvelle balise php-ssl:1-234.
Vérifiez que l’application app2 est redéployée.
Évaluation
persistent.
[student@workstation ~]$ lab grade updates-review
Fin
[student@workstation ~]$ lab finish updates-review
DO180-OCP4.14-fr-2-20240530 499
Solution
Gestion des mises à jour des applications

Mettez à jour deux applications en ligne vers les versions les plus récentes, identifiées par
des balises non flottantes.
Résultats
Vous serez en mesure de configurer des objets Deployment avec des images et des
déclencheurs, ainsi que des alias et des balises de flux d’images.
Avant De Commencer
exercice. Elle crée également le projet updates-review et y déploie deux applications,
app1 et app2.
La commande crée le fichier /home/student/DO180/labs/updates-review/

resources.txt. Le fichier resources.txt contient le nom des images que vous
utiliserez au cours de l’exercice. Vous pouvez utiliser ce fichier pour copier et coller ces noms
d’image.
[student@workstation ~]$ lab start updates-review
Instructions

developer. Utilisez le projet updates-review pour votre travail.
1. Votre équipe a créé le déploiement app1 dans le projet updates-review à partir de
l’image de conteneur registry.ocp4.example.com:8443/redhattraining/php-
ssl:latest. Récemment, un développeur de votre organisation a envoyé (push) une
nouvelle version de l’image, puis a réaffecté la balise latest à cette version.
Reconfigurez le déploiement app1 de manière à utiliser la balise statique 1-222 au lieu de la
balise flottante latest, afin d’éviter un redéploiement accidentel de votre application avec
des versions d’image non testées que vos développeurs peuvent publier à tout moment.

Login successful.
500 DO180-OCP4.14-fr-2-20240530
1.2. Définissez le projet updates-review comme projet actif.
[student@workstation ~]$ oc project updates-review

1.3. Vérifiez que le déploiement app1 utilise bien la balise latest. Récupérez le nom du
conteneur.
[student@workstation ~]$ oc get deployment/app1 -o wide

app1 1/1 ... php-ssl registry...:8443/redhattraining/php-ssl:latest ...
1.4. Dans l’objet Deployment, remplacez l’image par

registry.ocp4.example.com:8443/redhattraining/php-ssl:1-222.
[student@workstation ~]$ oc set image deployment/app1 \

php-ssl=registry.ocp4.example.com:8443/redhattraining/php-ssl:1-222
deployment.apps/app1 image updated
1.5. Vérifiez votre travail.

app1 1/1 ... php-ssl registry...:8443/redhattraining/php-ssl:1-222 ...
2. Le déploiement app2 utilise la balise de flux d’images php-ssl:1, qui est un alias de la
balise php-ssl:1-222.
Activez le déclenchement d’image pour le déploiement app2, de sorte que chaque fois que
la balise de flux d’images php-ssl:1 change, OpenShift déploie l’application. Vous testerez
votre configuration lors d’une étape ultérieure, lorsque vous réaffecterez l’alias php-ssl:1 à
une nouvelle balise de flux d’images.
2.1. Récupérez le nom du conteneur à partir de l’objet Deployment.

app2 1/1 1 1 21m php-ssl ...
2.2. Ajoutez un déclencheur d’images à l’objet Deployment.
[student@workstation ~]$ oc set triggers deployment/app2 \

--from-image php-ssl:1 --containers php-ssl
deployment.apps/app2 triggers updated
[student@workstation ~]$ oc set triggers deployment/app2

NAME TYPE VALUE AUTO
deployments/app2 config true
deployments/app2 image php-ssl:1 (php-ssl) true
DO180-OCP4.14-fr-2-20240530 501
3. Une nouvelle version de l’image, registry.ocp4.example.com:8443/

redhattraining/php-ssl:1-234, est disponible dans le registre de conteneurs. Votre
équipe en charge de l’assurance qualité a testé et approuvé cette version. Elle est prête pour
la production.
Créez la balise de flux d’images php-ssl:1-234 qui pointe vers la nouvelle image. Déplacez
l’alias de balise de flux d’images php-ssl:1 vers la nouvelle balise php-ssl:1-234.
Vérifiez que l’application app2 est redéployée.
3.1. Créez la balise de flux d’images php-ssl:1-234.
[student@workstation ~]$ oc create istag php-ssl:1-234 \

--from-image registry.ocp4.example.com:8443/redhattraining/php-ssl:1-234
imagestreamtag.image.openshift.io/php-ssl:1-234 created
3.2. Déplacez l’alias php-ssl:1 vers la nouvelle balise de flux d’images php-ssl:1-234.
[student@workstation ~]$ oc tag --alias php-ssl:1-234 php-ssl:1

Tag php-ssl:1 set up to track php-ssl:1-234.
3.3. Vérifiez que l’application app2 est déployée. Les noms des jeux de réplicas seront
probablement différents sur votre système.
[student@workstation ~]$ oc describe deployment/app2

Name: app2
Namespace: updates-review
Events:
Type ... Age Message
---- ---- -------
Normal ... 33m ... Scaled up replica set app2-7dd589f6d5 to 1
Normal ... 3m30s ... Scaled up replica set app2-7bf5b7787 to 1
Normal ... 3m28s ... Scaled down replica set app2-7dd589f6d5 to 0 from 1
Évaluation
persistent.
[student@workstation ~]$ lab grade updates-review
Fin
[student@workstation ~]$ lab finish updates-review
502 DO180-OCP4.14-fr-2-20240530
Résumé
• Vous référencez des images de conteneur par balises ou par ID SHA. Les développeurs
d’images affectent des balises aux images. Les registres de conteneurs calculent et affectent
des ID SHA aux images.
• Les objets Deployment possèdent un attribut imagePullPolicy qui spécifie la manière dont
les nœuds de calcul extraient l’image du registre.
• Une stratégie de déploiement est un moyen de modifier ou de mettre à niveau votre application
afin de minimiser l’impact de ces changements.
• Les objets Deployment prennent en charge les stratégies de déploiement RollingUpdate et

Recreate.
• Les ressources de balise et de flux d’images OpenShift fournissent des références stables aux
images de conteneur.
• Les ressources de charge de travail Kubernetes, telles que Deployments et Jobs, peuvent
utiliser des flux d’images. Vous devez créer les flux d’images dans le même projet que les
ressources Kubernetes, et vous devez activer la politique de recherche locale dans les flux
d’images pour les utiliser.
• Vous pouvez configurer la surveillance d’images dans les déploiements, de telle sorte
qu’OpenShift déploie l’application chaque fois que la balise de flux d’images change.
DO180-OCP4.14-fr-2-20240530 503
504 DO180-OCP4.14-fr-2-20240530
chapitre 8
Révision complète
Objectif Tâches de révision depuis Red Hat OpenShift
Administration I: Operating a Production Cluster.
Sections • Révision complète
Atelier • Déploiement d’applications Web
• Résolution des problèmes et mise à l’échelle

des applications
DO180-OCP4.14-fr-2-20240530 505
chapitre 8 | Révision complète
Révision complète
Résultats
Après avoir terminé cette section, vous devriez avoir révisé et rafraîchi les connaissances et
compétences que vous avez acquises dans Red Hat OpenShift Administration I: Operating a
Production Cluster.
Révision Red Hat OpenShift Administration I:

Operating a Production Cluster
Avant de commencer la révision complète de ce cours, vous devez être familiarisé avec les
rubriques abordées dans chaque chapitre. N’hésitez pas à poser des questions au formateur pour
clarifier certains aspects de ces rubriques, ou à lui demander des conseils.
Chapitre 1, Présentation de Kubernetes et d’OpenShift

Identifier les principaux services de cluster Kubernetes et de plateforme OpenShift, et les
surveiller à l’aide de la console Web.
• Décrire les principales caractéristiques des conteneurs et de Kubernetes.
• Décrire la relation entre OpenShift, Kubernetes et d’autres projets Open Source, et lister les
principales fonctions des produits et éditions de Red Hat OpenShift.
• Naviguer dans la console Web OpenShift pour identifier les applications et les services de
• Parcourir les panneaux Events, Compute et Observe de la console Web OpenShift pour évaluer
l’état général d’un cluster.
Chapitre 2, API et interfaces de ligne de commande

Accéder à un cluster OpenShift à l’aide de la ligne de commande et interroger ses ressources
d’API Kubernetes pour évaluer l’intégrité d’un cluster.
• Accéder à un cluster OpenShift à l’aide des interfaces de ligne de commande Kubernetes et

OpenShift.
• Interroger, formater et filtrer les attributs des ressources Kubernetes.
• Exécuter une requête pour connaître l’intégrité des services et composants de cluster
essentiels.
Chapitre 3, Exécuter des applications en tant que conteneurs

et pods
Exécuter et résoudre les problèmes des applications en conteneur en tant que pods Kubernetes
non gérés.
• Exécuter des conteneurs dans des pods, et identifier les espaces de noms et processus de
système d’exploitation hôtes utilisés par les conteneurs.
506 DO180-OCP4.14-fr-2-20240530
• Rechercher des applications en conteneur dans des registres de conteneurs et obtenir des
informations sur les paramètres d’exécution des images de conteneur de la communauté et
prises en charge.
• Résoudre les problèmes liés à un pod en démarrant des processus supplémentaires sur ses
conteneurs, en modifiant les systèmes de fichiers éphémères et en ouvrant des tunnels réseau à
courte durée de vie.
Chapitre 4, Déployer des applications gérées et en réseau sur

Kubernetes
Déployer des applications et permettre un accès depuis l’intérieur et l’extérieur d’un cluster
Kubernetes.
• Identifier les principaux paramètres et ressources utilisés par Kubernetes pour gérer les
applications de longue durée, et montrer comment OpenShift simplifie les workflows de
• Déployer des applications en conteneur en tant que pods gérés par des ressources de charge de
travail Kubernetes.
• Interconnecter les pods d’applications au sein du même cluster à l’aide des services Kubernetes.
• Exposer des applications aux clients situés à l’extérieur du cluster à l’aide d’une entrée
Chapitre 5, Gestion du stockage pour les données et la

configuration de l’application
Externaliser les configurations d’applications dans les ressources Kubernetes et approvisionner
des volumes de stockage pour les fichiers de données persistants.
• Configurer des applications à l’aide de secrets et de mappages de configuration Kubernetes

pour initialiser des variables d’environnement, et fournir des fichiers de configuration texte et
binaires.
• Fournir aux applications des volumes de stockage persistant pour les données basées sur des
blocs et des fichiers.
• Associer des applications à des classes de stockage qui fournissent des services de stockage
pour répondre aux exigences des applications.
• Déployer des applications qui peuvent être mises à l’échelle sans partager le stockage.
Chapitre 6, Configuration des applications sur le plan de la

fiabilité
Configurer des applications pour qu’elles fonctionnent avec Kubernetes pour offrir une haute
disponibilité et une résilience élevée.
• Décrire comment Kubernetes essaie de faire en sorte que les applications continuent de
• Décrire comment Kubernetes utilise les sondes d’intégrité lors du déploiement, de la mise à
• Configurer une application avec des demandes de ressources afin que Kubernetes puisse
DO180-OCP4.14-fr-2-20240530 507
• Configurer une application avec des limites de ressources afin que Kubernetes puisse en
• Configurer un autoscaler de pod horizontal pour une application.
Chapitre 7, Gestion des mises à jour des applications

Gérer des mises à jour d’application reproductibles, ainsi que des restaurations de code et de
configurations.
• Associer les balises d’image de conteneur à leurs hachages d’identifiant, et identifier les images
de conteneur à partir de pods et de conteneurs sur les nœuds Kubernetes.
• Mettez à jour les applications avec un temps d’arrêt minimal à l’aide de stratégies de
déploiement.
• Garantir la reproductibilité des déploiements d’applications en utilisant des flux d’images et des
noms d’images courts.
• Garantir la mise à jour automatique des pods d’application en utilisant des flux d’images avec les
ressources de charge de travail Kubernetes.
508 DO180-OCP4.14-fr-2-20240530
Open Lab
Déploiement d’applications Web

Utiliser des flux d’images avec des ressources de charge de travail Kubernetes pour garantir
la reproductibilité des déploiements d’applications.
Configurer des applications à l’aide de secrets Kubernetes pour initialiser des variables
d’environnement.
Fournir aux applications des volumes de stockage persistant.
Exposer les applications aux clients situés en dehors du cluster.
Résultats
Vous serez en mesure de créer et de configurer des ressources OpenShift et Kubernetes,
telles que des projets, des secrets, des déploiements, des volumes persistants, des services
et des routes.
Avant De Commencer
cet exercice. La commande crée également le fichier /home/student/DO180/labs/
compreview-deploy/resources.txt. Le fichier resources.txt contient les URL de
votre cluster OpenShift et les noms des images que vous utiliserez au cours de l’exercice.
Vous pouvez utiliser ce fichier pour copier et coller ces URL et ces noms d’images.
[student@workstation ~]$ lab start compreview-deploy
Spécifications
L’URL de la console Web OpenShift est https://console-openshift-

console.apps.ocp4.example.com. Lorsque vous accédez à la console Web, sélectionnez Red Hat
Identity Management comme mécanisme d’authentification.

developer. Le mot de passe de l’utilisateur admin est redhatocp, bien que vous ne deviez pas
nécessairement disposer des privilèges d’administrateur pour effectuer l’exercice.
Au cours de cet exercice, vous allez déployer une application Web et sa base de données à des fins
de test. La configuration obtenue n’est pas prête pour la production, car vous ne configurez pas de
sondes ni de limites de ressources, deux éléments requis dans le cadre de la production. Ces sujets
sont traités dans un autre exercice de révision complète.
Procédez comme suit pour effectuer l’exercice :
DO180-OCP4.14-fr-2-20240530 509
• Créez un projet nommé review pour stocker votre travail.
• Configurez votre projet de sorte que ses charges de travail fassent référence à l’image de base
de données par le nom court mysql8:1.
– Le nom court doit pointer vers l’image de conteneur

registry.ocp4.example.com:8443/rhel9/mysql-80:1-228. Il est prévu que le nom
de l’image de base de données et son registre source changent dans un proche avenir, et vous
souhaitez que vos charges de travail ne soient pas affectées par ce changement.
La configuration de la salle de classe a copié cette image à partir de Red Hat Ecosystem
Catalog. L’image d’origine est registry.redhat.io/rhel9/mysql-80:1-228.
– Assurez-vous que les ressources de charge de travail du projet review peuvent utiliser la
ressource mysql8:1. Vous créerez ces ressources de charge de travail au cours d’une étape
ultérieure.
• Créez le secret dbparams pour stocker les paramètres de la base de données MySQL. La
base de données et le déploiement frontal ont tous deux besoin de ces paramètres. Le secret
dbparams doit inclure les variables suivantes :
Name Valeur
user operator1
password redhat123
database quotesdb
• Créez le déploiement quotesdb et configurez-le comme suit :
– Utilisez l’image mysql8:1 pour le déploiement.
– La base de données doit être automatiquement déployée à chaque changement du

conteneur source dans la ressource mysql8:1.
Pour tester votre configuration, vous pouvez modifier l’image mysql8:1 pour qu’elle
pointe vers l’image de conteneur registry.ocp4.example.com:8443/rhel9/
mysql-80:1-237 fournie par la salle de classe, puis vérifier que le déploiement quotesdb
est bien effectué. N’oubliez pas de réinitialiser l’image mysql8:1 sur l’image de conteneur
registry.ocp4.example.com:8443/rhel9/mysql-80:1-228 avant de noter votre
travail.
– Définissez les variables d’environnement suivantes dans le déploiement à partir des clés du
secret dbparams :
Variable d’environnement Clé du secret dbparams
MYSQL_USER user
MYSQL_PASSWORD password
MYSQL_DATABASE database
– Assurez-vous qu’OpenShift conserve les données de la base de données entre les

redémarrages du pod. Ces données n’utilisent pas plus de 2 Gio d’espace disque. La base de
510 DO180-OCP4.14-fr-2-20240530
données MySQL stocke ses données dans le répertoire /var/lib/mysql. Utilisez la classe
de stockage lvms-vg1 pour le volume.
• Créez un service quotesdb pour mettre la base de données à la disposition de l’application

Web frontale. Le service de base de données écoute sur le port 3306.
• Créez le déploiement frontend et configurez-le comme suit :
– Utilisez l’image registry.ocp4.example.com:8443/redhattraining/famous-

quotes:2-42. Pour ce déploiement, vous faites référence à l’image par son nom complet,
car votre organisation la développe et contrôle son processus de lancement.
– Définissez les variables d’environnement suivantes dans le déploiement :
Nom de la variable Valeur

d’environnement
QUOTES_USER Clé user du secret dbparams
QUOTES_PASSWORD Clé password du secret dbparams
QUOTES_DATABASE Clé database du secret dbparams
QUOTES_HOSTNAME quotesdb
• Vous ne pouvez pas encore tester l’application depuis l’extérieur du cluster. Exposez le
déploiement frontend afin que l’application soit accessible à l’adresse http://frontend-
review.apps.ocp4.example.com.
Le déploiement frontend écoute le port 8000.
Lorsque vous accédez à l’URL http://frontend-review.apps.ocp4.example.com, l’application

renvoie une liste de citations d’auteurs célèbres.
Évaluation
persistent.
[student@workstation ~]$ lab grade compreview-deploy
Fin
[student@workstation ~]$ lab finish compreview-deploy
DO180-OCP4.14-fr-2-20240530 511
Solution
Déploiement d’applications Web

Utiliser des flux d’images avec des ressources de charge de travail Kubernetes pour garantir
la reproductibilité des déploiements d’applications.
Configurer des applications à l’aide de secrets Kubernetes pour initialiser des variables
d’environnement.
Fournir aux applications des volumes de stockage persistant.
Exposer les applications aux clients situés en dehors du cluster.
Résultats
Vous serez en mesure de créer et de configurer des ressources OpenShift et Kubernetes,
telles que des projets, des secrets, des déploiements, des volumes persistants, des services
et des routes.
Avant De Commencer
cet exercice. La commande crée également le fichier /home/student/DO180/labs/
compreview-deploy/resources.txt. Le fichier resources.txt contient les URL de
votre cluster OpenShift et les noms des images que vous utiliserez au cours de l’exercice.
Vous pouvez utiliser ce fichier pour copier et coller ces URL et ces noms d’images.
[student@workstation ~]$ lab start compreview-deploy
1. Connectez-vous au cluster OpenShift à partir de la ligne de commande, puis créez le projet

review.
1.1. Connectez-vous en tant qu’utilisateur developer.

Login successful.
1.2. Créez le projet review.
[student@workstation ~]$ oc new-project review

Now using project "review" on server "https://api.ocp4.example.com:6443".
512 DO180-OCP4.14-fr-2-20240530
2. Créez la balise de flux d’images mysql8:1 à partir de l’image

registry.ocp4.example.com:8443/rhel9/mysql-80:1-228. Activez la résolution
de flux d’images pour mysql8 afin que les ressources Kubernetes du projet en cours puissent
l’utiliser.
2.1. Utilisez la commande oc create istag pour créer le flux d’images et la balise de
flux d’images.
[student@workstation ~]$ oc create istag mysql8:1 \

--from-image registry.ocp4.example.com:8443/rhel9/mysql-80:1-228
imagestreamtag.image.openshift.io/mysql8:1 created
2.2. Utilisez la commande oc set image-lookup pour activer la résolution de recherche

d’images.
[student@workstation ~]$ oc set image-lookup mysql8

imagestream.image.openshift.io/mysql8 image lookup updated
2.3. Exécutez la commande oc set image-lookup sans aucun argument pour vérifier
votre travail.

NAME LOCAL
mysql8 true
3. Créez le secret dbparams.
[student@workstation ~]$ oc create secret generic dbparams \

--from-literal user=operator1 --from-literal password=redhat123 \
--from-literal database=quotesdb
secret/dbparams created
4. Créez le déploiement quotesdb à partir de la balise de flux d’images mysql8:1. Définissez

le nombre de réplicas sur zéro pour empêcher OpenShift de déployer la base de données
avant que vous ayez terminé sa configuration.
[student@workstation ~]$ oc create deployment quotesdb --image mysql8:1 \

--replicas 0
deployment.apps/quotesdb created
5. Ajoutez un déclencheur d’image au déploiement quotesdb.
5.1. Récupérez le nom du conteneur à partir du déploiement quotesdb.
[student@workstation ~]$ oc get deployment quotesdb -o wide

quotesdb 0/0 0 0 11s mysql8 ...
5.2. Utilisez la commande oc set triggers pour ajouter le déclencheur de la balise de

flux d’images mysql8:1 au conteneur mysql8.
DO180-OCP4.14-fr-2-20240530 513
[student@workstation ~]$ oc set triggers deployment/quotesdb \

--from-image mysql8:1 --containers mysql8
deployment.apps/quotesdb triggers updated
6. Ajoutez des variables d’environnement au déploiement quotesdb à partir du secret

dbparams. Ajoutez le préfixe MYSQL_ à chaque nom de variable.
[student@workstation ~]$ oc set env deployment/quotesdb \

--from secret/dbparams --prefix MYSQL_
deployment.apps/quotesdb updated
7. Ajoutez un volume persistant de 2 Gio au déploiement quotesdb. Utilisez la classe de

stockage lvms-vg1. À l’intérieur des pods, montez le volume dans le répertoire /var/lib/
mysql.
[student@workstation ~]$ oc set volumes deployment/quotesdb --add \

--claim-class lvms-vg1 --claim-size 2Gi --mount-path /var/lib/mysql
info: Generated volume name: volume-n7xpd
deployment.apps/quotesdb volume updated
8. Démarrez la base de données en dimensionnant (scale-up) le déploiement quotesdb sur un

réplica.
8.1. Mettez à l’échelle le déploiement vers le haut (scale-up).
[student@workstation ~]$ oc scale deployment/quotesdb --replicas 1

deployment.apps/quotesdb scaled

quotesdb-99f9b4ff8-ggs7z 1/1 Running 0 4s
9. Créez le service quotesdb pour le déploiement quotesdb. Le serveur de base de données

écoute sur le port 3306.
9.1. Utilisez la commande oc expose deployment pour créer le service.
[student@workstation ~]$ oc expose deployment quotesdb --port 3306

service/quotesdb exposed
9.2. Vérifiez qu’OpenShift associe l’adresse IP du serveur MySQL au point d’accès. Il est
probable que l’adresse IP du point d’accès soit différente sur votre système.
514 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ oc describe service quotesdb

Name: quotesdb
Namespace: review
TargetPort: 3306/TCP
Endpoints: 10.8.0.123:3306
Session Affinity: None
Events: <none>
10. Créez le déploiement frontend à partir de l’image

registry.ocp4.example.com:8443/redhattraining/famous-quotes:2-42.
Définissez le nombre de réplicas sur zéro pour empêcher OpenShift de déployer l’application
avant que vous ayez terminé sa configuration.
[student@workstation ~]$ oc create deployment frontend \

--image registry.ocp4.example.com:8443/redhattraining/famous-quotes:2-42 \
--replicas 0
deployment.apps/frontend created
11. Ajoutez des variables d’environnement au déploiement frontend à partir du secret

dbparams et ajoutez la variable QUOTES_HOSTNAME avec la valeur quotesdb.
11.1. Ajoutez les variables à partir du secret dbparams. Ajoutez le préfixe QUOTES_ à
chaque nom de variable.
[student@workstation ~]$ oc set env deployment/frontend \

--from secret/dbparams --prefix QUOTES_
deployment.apps/frontend updated
11.2. Déclarez la variable QUOTES_HOSTNAME.
[student@workstation ~]$ oc set env deployment/frontend QUOTES_HOSTNAME=quotesdb

deployment.apps/frontend updated
12. Démarrez l’application en dimensionnant (scale-up) le déploiement frontend sur un réplica.
12.1. Mettez à l’échelle le déploiement vers le haut (scale-up).
[student@workstation ~]$ oc scale deployment/frontend --replicas 1

deployment.apps/frontend scaled

frontend-86cdd7c7bf-hpnwz 1/1 Running 0 44s
quotesdb-99f9b4ff8-ggs7z 1/1 Running 0 2m11s
DO180-OCP4.14-fr-2-20240530 515
13. Exposez le déploiement frontend afin que l’application soit accessible depuis l’extérieur du
cluster. L’application Web écoute sur le port 8000.
13.1. Créez le service frontend pour le déploiement frontend.
[student@workstation ~]$ oc expose deployment frontend --port 8000

service/frontend exposed
13.2. Créez la route.
[student@workstation ~]$ oc expose service frontend

route.route.openshift.io/frontend exposed
13.3. Récupérez l’URL de l’application à partir de la route.
[student@workstation ~]$ oc get route

NAME HOST/PORT PATH SERVICES ...
frontend frontend-review.apps.ocp4.example.com frontend ...
13.4. Utilisez la commande curl pour tester l’application.
[student@workstation ~]$ curl http://frontend-review.apps.ocp4.example.com

<html>
<head>
<title>Quotes</title>
</head>
<body>
<h1>Quote List</h1>
<ul>
<li>1: When words fail, music speaks.

- William Shakespeare
</li>
Évaluation
persistent.
[student@workstation ~]$ lab grade compreview-deploy
Fin
516 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ lab finish compreview-deploy
DO180-OCP4.14-fr-2-20240530 517
Open Lab
Résolution des problèmes et mise à

l’échelle des applications
Naviguer dans la console Web OpenShift pour identifier les charges de travail qui utilisent
des ressources processeur.
Résoudre les problèmes liés à l’échec d’un pod MySQL.
Mettre à l’échelle manuellement une application.
Configurer des sondes d’intégrité.
Résultats
Vous serez en mesure de résoudre des problèmes de charge de travail, de configurer des
déploiements et de mettre à l’échelle des applications.
Avant De Commencer
cet exercice. Elle crée également le projet compreview-scale et y déploie quelques
applications.
La commande crée le fichier /home/student/DO180/labs/compreview-scale/

resources.txt. Le fichier resources.txt contient les URL de votre cluster OpenShift
et les noms des images que vous utiliserez au cours de l’exercice. Vous pouvez utiliser ce
fichier pour copier et coller ces URL et ces noms d’images.
[student@workstation ~]$ lab start compreview-scale
Spécifications
L’URL de la console Web OpenShift est https://console-openshift-

console.apps.ocp4.example.com. Lorsque vous accédez à la console Web, sélectionnez Red Hat
Identity Management comme mécanisme d’authentification.

developer. Le mot de passe de l’utilisateur admin est redhatocp.
Effectuez les tâches suivantes pour accomplir la révision complète :
• Un pod du cluster consomme trop de ressources processeur et perturbe d’autres tâches.

Identifiez le pod en question et supprimez sa charge de travail.
518 DO180-OCP4.14-fr-2-20240530
• Le projet compreview-scale inclut déjà une application Web à l’adresse http://frontend-

compreview-scale.apps.ocp4.example.com. Lorsque vous accédez à cette URL, l’application
renvoie une liste de citations d’auteurs célèbres. L’application est actuellement endommagée et
certains éléments doivent être configurés pour qu’elle soit prête pour la production.
L’application utilise deux objets Deployment de Kubernetes. Le déploiement frontend fournit

les pages Web de l’application et s’appuie sur le déploiement quotesdb qui exécute une base
de données MySQL. La commande lab a déjà créé les services et les routes qui connectent les
composants de l’application, et qui permettent d’y accéder depuis l’extérieur du cluster.
Corrigez l’application et préparez-la pour la production :
– Le déploiement quotesdb dans le projet compreview-scale démarre un serveur MySQL,

mais la base de données échoue. Examinez les journaux du pod pour identifier le problème et
le corriger.
Utilisez les paramètres suivants pour la base de données :
Name Valeur
Username operator1
Password redhat123
Nom de la base de données quotes
– Votre équipe de sécurité a validé une nouvelle version de l’image de conteneur

MySQL qui résout un problème de sécurité. La nouvelle image de conteneur est
registry.ocp4.example.com:8443/rhel9/mysql-80:1-237.
Mettez à jour le déploiement quotesdb pour qu’il utilise cette image. Assurez-vous que la
base de données est redéployée.
La configuration de la salle de classe a copié cette image à partir de Red Hat Ecosystem
Catalog. L’image d’origine est registry.redhat.io/rhel9/mysql-80:1-237.
– Ajoutez une sonde au déploiement quotesdb afin qu’OpenShift puisse détecter à quel
moment la base de données est prête à accepter des demandes. Utilisez la commande
mysqladmin ping pour la sonde.
– Ajoutez une deuxième sonde qui vérifie régulièrement l’état de la base de données. Utilisez
également la commande mysqladmin ping.
– Configurez l’utilisation du processeur et de la mémoire pour le déploiement quotesdb.

Le déploiement a besoin de 200 millicores de processeur et de 256 Mio de mémoire pour
DO180-OCP4.14-fr-2-20240530 519
s’exécuter. Vous devez, en outre, limiter son utilisation du processeur à 500 millicores et son
utilisation de la mémoire à 1 Gio.
– Ajoutez une sonde au déploiement frontend afin qu’OpenShift puisse détecter à quel
moment l’application Web est prête à accepter des demandes. L’application est prête
lorsqu’une demande HTTP sur le port 8000 adressée au chemin /status aboutit.
– Ajoutez une deuxième sonde qui vérifie régulièrement l’état de l’application frontale Web.
L’application frontale fonctionne comme prévu lorsqu’une demande HTTP sur le port 8000
adressée au chemin /env aboutit.
– Configurez l’utilisation du processeur et de la mémoire pour le déploiement frontend.

Le déploiement a besoin de 200 millicores de processeur et de 256 Mio de mémoire pour
s’exécuter. Vous devez, en outre, limiter son utilisation du processeur à 500 millicores et son
utilisation de la mémoire à 512 Mio.
– Mettez à l’échelle l’application frontend sur trois pods pour qu’elle accepte la charge de
production estimée.
– Pour vérifier votre travail, accédez à l’URL http://frontend-compreview-

scale.apps.ocp4.example.com. L’application renvoie une liste de citations d’auteurs célèbres.
Évaluation
persistent.
[student@workstation ~]$ lab grade compreview-scale
Fin
[student@workstation ~]$ lab finish compreview-scale
520 DO180-OCP4.14-fr-2-20240530
Solution
Résolution des problèmes et mise à

l’échelle des applications
Naviguer dans la console Web OpenShift pour identifier les charges de travail qui utilisent
des ressources processeur.
Résoudre les problèmes liés à l’échec d’un pod MySQL.
Mettre à l’échelle manuellement une application.
Configurer des sondes d’intégrité.
Résultats
Vous serez en mesure de résoudre des problèmes de charge de travail, de configurer des
déploiements et de mettre à l’échelle des applications.
Avant De Commencer
cet exercice. Elle crée également le projet compreview-scale et y déploie quelques
applications.
La commande crée le fichier /home/student/DO180/labs/compreview-scale/

resources.txt. Le fichier resources.txt contient les URL de votre cluster OpenShift
et les noms des images que vous utiliserez au cours de l’exercice. Vous pouvez utiliser ce
fichier pour copier et coller ces URL et ces noms d’images.
[student@workstation ~]$ lab start compreview-scale
1. Utilisez la console Web OpenShift pour identifier puis supprimer le pod qui utilise trop de
ressources processeur.
1.1. Utilisez un navigateur Web pour accéder à l’URL https://console-openshift-

console.apps.ocp4.example.com.
1.2. Sélectionnez Red Hat Identity Management, puis connectez-vous en tant

qu’utilisateur admin avec le mot de passe redhatocp. Cliquez sur Skip tour si le
message Welcome to the Developer Perspective est affiché.
1.3. Passez à la perspective Administrator et accédez ensuite à Observe > Dashboards.
DO180-OCP4.14-fr-2-20240530 521
1.4. Sélectionnez le tableau de bord Kubernetes / Compute Resources / Cluster, puis

cliquez sur Inspect dans le graphique CPU Usage.
522 DO180-OCP4.14-fr-2-20240530
1.5. Réglez le zoom sur cinq minutes, puis survolez le graphique avec le pointeur de la
souris. Notez que l’interface liste l’espace de noms compreview-scale-load en
première position, ce qui indique que cet espace de noms est le premier consommateur
de ressources processeur.
1.6. Accédez à Observe > Dashboards, puis sélectionnez le tableau de bord Kubernetes /
Compute Resources / Namespace (Workloads). Sélectionnez l’espace de noms
compreview-scale-load, puis définissez la valeur Time Range (Période) sur Last
5 minutes (Les 5 dernières minutes). Le déploiement computeprime est la charge de
travail qui consomme une quantité excessive de ressources processeur.
DO180-OCP4.14-fr-2-20240530 523
1.7. Accédez à Workloads > Deployments, puis sélectionnez le projet compreview-

scale-load. Sélectionnez le menu pour le déploiement computeprime, puis cliquez
sur Delete Deployment. Cliquez sur Delete pour confirmer l’opération.
2. Examinez les journaux du pod qui échoue pour le déploiement quotesdb. Définissez les
variables d’environnement manquantes dans le déploiement quotesdb.
2.1. Connectez-vous au cluster OpenShift à partir de la ligne de commande.

Login successful.
2.2. Définissez le projet compreview-scale comme projet actif.
[student@workstation ~]$ oc project compreview-scale

2.3. Listez les pods pour identifier le pod défaillant à partir du déploiement quotesdb. Il est
probable que les noms des pods soient différents sur votre système.

frontend-5fb85b4c75-5s7xr 0/1 CrashLoopBackOff 14 (2m52s ago) 50m
quotesdb-9b9776479-4z4g9 0/1 CrashLoopBackOff 14 (3m4s ago) 50m
2.4. Récupérez les journaux du pod défaillant. Il manque des variables d’environnement.
524 DO180-OCP4.14-fr-2-20240530
[student@workstation ~]$ oc logs quotesdb-9b9776479-4z4g9

=> sourcing 20-validate-variables.sh ...
MYSQL_USER (regex: '^[a-zA-Z0-9_]+$')
MYSQL_PASSWORD (regex: '[a-zA-Z0-9_~!@#$% &*()-=<>,.?;:|]+$')
MYSQL_DATABASE (regex: '^[a-zA-Z0-9_]+$')
2.5. Ajoutez les variables d’environnement manquantes au déploiement quotesdb.
[student@workstation ~]$ oc set env deployment/quotesdb \

MYSQL_USER=operator1 MYSQL_PASSWORD=redhat123 MYSQL_DATABASE=quotes
deployment.apps/quotesdb updated
3. Mettez à jour l’image de conteneur MySQL pour le déploiement quotesdb.
3.1. Récupérez le nom du conteneur qui s’exécute à l’intérieur du pod. Vous avez besoin du
nom du conteneur pour mettre à jour son image.
[student@workstation ~]$ oc get deployment/quotesdb -o wide

quotesdb 1/1 1 1 59m mysql-80 ...
3.2. Définissez l’image sur registry.ocp4.example.com:8443/rhel9/

mysql-80:1-237.
[student@workstation ~]$ oc set image deployment/quotesdb \

mysql-80=registry.ocp4.example.com:8443/rhel9/mysql-80:1-237
deployment.apps/quotesdb image updated
[student@workstation ~]$ oc get deployment/quotesdb -o wide

NAME ... CONTAINERS IMAGES
quotesdb ... mysql-80 registry.ocp4.example.com:8443/rhel9/mysql-80:1-237
3.4. Attendez que le déploiement soit effectué. Vous devrez peut-être exécuter la
que le nom du pod soit différent sur votre système.

frontend-5fb85b4c75-5s7xr 0/1 CrashLoopBackOff 15 (3m39s ago) 56m
quotesdb-54d64749c4-chhq6 1/1 Running 0 106s
4. Ajouter une sonde Readiness et une sonde Liveness au déploiement quotesdb qui exécute
la commande mysqladmin ping.
4.1. Utilisez la commande oc set probe avec l’option --readiness pour ajouter la
sonde Readiness.
DO180-OCP4.14-fr-2-20240530 525
[student@workstation ~]$ oc set probe deployment/quotesdb \

--readiness -- mysqladmin ping
deployment.apps/quotesdb probes updated
4.2. Utilisez la commande oc set probe avec l’option --liveness pour ajouter la sonde
Liveness.
[student@workstation ~]$ oc set probe deployment/quotesdb \

--liveness -- mysqladmin ping
deployment.apps/quotesdb probes updated
5. Définissez des limites de ressources pour le déploiement quotesdb. Définissez la demande

de processeur sur 200 millicores et la demande de mémoire sur 256 Mio. Définissez la limite
du processeur sur 500 millicores et la limite de la mémoire sur 1 Gio.
[student@workstation ~]$ oc set resources deployment/quotesdb \

--requests cpu=200m,memory=256Mi --limits cpu=500m,memory=1Gi
deployment.apps/quotesdb resource requirements updated
6. Ajoutez une sonde Readiness et une sonde Liveness au déploiement frontend.
6.1. Utilisez la commande oc set probe avec l’option --readiness pour ajouter la
sonde Readiness qui teste le chemin /status sur le port HTTP 8000.
[student@workstation ~]$ oc set probe deployment/frontend --readiness \

--get-url http://:8000/status
deployment.apps/frontend probes updated
6.2. Utilisez la commande oc set probe avec l’option --liveness pour ajouter la sonde
Liveness qui teste le chemin /env sur le port HTTP 8000.
[student@workstation ~]$ oc set probe deployment/frontend --liveness \

--get-url http://:8000/env
deployment.apps/frontend probes updated
7. Définissez des limites de ressources pour le déploiement frontend. Définissez la demande

de processeur sur 200 millicores et la demande de mémoire sur 256 Mio. Définissez la limite
du processeur sur 500 millicores et la limite de la mémoire sur 512 Mio.
[student@workstation ~]$ oc set resources deployment/frontend \

--requests cpu=200m,memory=256Mi --limits cpu=500m,memory=512Mi
deployment.apps/frontend resource requirements updated
8. Mettez à l’échelle le déploiement frontend sur trois pods.
8.1. Mettez à l’échelle le déploiement.
[student@workstation ~]$ oc scale deployment/frontend --replicas 3

deployment.apps/frontend scaled
526 DO180-OCP4.14-fr-2-20240530
8.2. Attendez que le déploiement soit mis à l’échelle vers le haut (scale-up). Vous devrez
peut-être exécuter la commande à plusieurs reprises pour que les pods signalent l’état
Running. Il est probable que les noms des pods soient différents sur votre système.

frontend-86cdd7c7bf-8vrrs 1/1 Running 0 3m10s
frontend-86cdd7c7bf-ds79w 1/1 Running 0 44s
frontend-86cdd7c7bf-hpnwz 1/1 Running 0 44s
quotesdb-66ff98b88c-fhwhs 1/1 Running 0 12m
9. Vérifiez que l’application répond aux demandes Web.
9.1. Récupérez l’URL de l’application.
[student@workstation ~]$ oc get route

NAME HOST/PORT PATH SERVICES ...
frontend frontend-compreview-scale.apps.ocp4.example.com frontend ...
9.2. Utilisez la commande curl pour tester l’application.

http://frontend-compreview-scale.apps.ocp4.example.com
<html>
<head>
<title>Quotes</title>
</head>
<body>
<h1>Quote List</h1>
<ul>
<li>1: When words fail, music speaks.

- William Shakespeare
</li>
Évaluation
persistent.
[student@workstation ~]$ lab grade compreview-scale
Fin
DO180-OCP4.14-fr-2-20240530 527
[student@workstation ~]$ lab finish compreview-scale
528 DO180-OCP4.14-fr-2-20240530

Do180 4.14 Student Guide FR

Transféré par

Droits d'auteur :

Formats disponibles

Do180 4.14 Student Guide FR

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Do180 4.14 Student Guide FR

Transféré par

Droits d'auteur :

Formats disponibles

Student Workbook (ROLE)

OCP 4.14 DO180

DO180-OCP4.14-fr-2-20240530 Copyright ©2024 Red Hat, Inc.

Java® is a registered trademark of Oracle American, Inc. and/or its affiliates.

All other trademarks are the property of their respective owners.

Contributeurs:Sourabh Mishra, Ted Singdahlsen

1. Présentation de Kubernetes et d’OpenShift 1

2. API et interfaces de ligne de commande Kubernetes et OpenShift 65

3. Exécuter des applications en tant que conteneurs et pods 147

4. Déployer des applications gérées et en réseau sur Kubernetes 225

Cette section décrit les différentes conventions et pratiques utilisées dans

Red Hat OpenShift Administration I: Operating a

• Gestion de clusters OpenShift à partir de l’interface de ligne de

• Administrateurs système intéressés par la gestion continue des clusters

• Conteneurs, Kubernetes et Red Hat OpenShift Technical Overview

Ces trois systèmes se trouvent dans le domaine DNS lab.example.com.

Figure 0.1: Environnement de formation :

Machines de la salle de classe

Nom de la machine Adresses IP Rôle

bastion.lab.example.com 172.25.250.254 Routeur reliant les machines

classroom.lab.example.com 172.25.252.254 Serveur qui héberge les

idm.ocp4.example.com 192.168.50.40 Serveur de gestion des

master01.ocp4.example.com 192.168.50.10 Un cluster RHOCP à nœud

Nom de la machine Adresses IP Rôle

registry.ocp4.example.com 192.168.50.50 Serveur de registre pour

utility.lab.example.com 192.168.50.254 Serveur qui fournit les

workstation.lab.example.com 172.25.250.9 Poste de travail graphique

Méthodes d’accès RHOCP

Méthode Point d’accès

Console Web https://console-openshift-console.apps.ocp4.example.com

Registre de la salle de classe

Le serveur registry fournit le registre d’images de conteneur https://

Référentiels d’images de conteneur de la salle de classe et sources publiques

Référentiels de registres de la salle de Référentiel source public

Référentiels de registres de la salle de Référentiel source public

Contrôle de vos systèmes

Contrôle des machines virtuelles

Figure 0.2: Exemple de page de gestion Lab Environment d’un cours

État de la machine Description

building La machine virtuelle est en cours de création.

active La machine virtuelle est en cours d’exécution et disponible. Si elle

stopped La machine virtuelle est arrêtée. Au démarrage, la machine virtuelle

Actions de la salle de classe

Bouton ou action Description

CREATING Les machines virtuelles de la salle de classe ROLE sont en cours de

DELETE Permet de supprimer la salle de classe ROLE. Détruit toutes les

START Permet de démarrer toutes les machines virtuelles de la salle de

STARTING Toutes les machines virtuelles de la salle de classe démarrent.

STOP Permet d’arrêter toutes les machines virtuelles de la salle de classe.

Bouton ou action Description

OPEN CONSOLE Permet de se connecter à la console système de la machine virtuelle

ACTION > Start Démarrer (mettre sous tension) la machine virtuelle.

ACTION > Arrêtez correctement la machine virtuelle, en préservant le contenu

Les compteurs d’arrêt automatique et de destruction

Exécution des exercices pratiques

La syntaxe d’exécution d’un script d’exercice est la suivante :

[student@workstation ~]$ lab action exercise

Affichage du guide du stagiaire

Considérations relatives au répertoire de l’atelier