SupportConsoleDéveloppeursCommencer un essaiContact

Mise à jour des grappes

OpenShift Container Platform 4.12

Mise à jour des clusters d'OpenShift Container Platform

Red Hat OpenShift Documentation Team

Résumé

Ce document fournit des instructions pour la mise à jour ou la mise à niveau des clusters OpenShift Container Platform. La mise à jour de votre cluster est un processus simple qui ne nécessite pas la mise hors ligne de votre cluster.

Chapitre 1. Vue d'ensemble de la mise à jour des clusters

Vous pouvez mettre à jour un cluster OpenShift Container Platform 4 en une seule opération en utilisant la console web ou l'OpenShift CLI (oc).

1.1. Comprendre les mises à jour d'OpenShift Container Platform

À propos du service de mise à jour OpenShift: Pour les clusters disposant d'un accès à Internet, Red Hat fournit des mises à jour over-the-air en utilisant un service de mise à jour OpenShift Container Platform en tant que service hébergé situé derrière des API publiques.

1.2. Comprendre les canaux de mise à niveau et les versions

Canaux de mise à niveau et versions: Les canaux de mise à niveau vous permettent de choisir une stratégie de mise à niveau. Les canaux de mise à niveau sont spécifiques à une version mineure d'OpenShift Container Platform. Les canaux de mise à niveau contrôlent uniquement la sélection des versions et n'ont pas d'impact sur la version du cluster que vous installez. Le fichier binaire openshift-install pour une version spécifique d'OpenShift Container Platform installe toujours cette version mineure. Pour plus d'informations, voir ce qui suit :

1.3. Comprendre les types d'état de cluster Operator

L'état des opérateurs de cluster comprend leur type de condition, qui vous informe de l'état de santé actuel de votre opérateur. Les définitions suivantes couvrent une liste de certains types d'états courants des ClusterOperators. Les opérateurs qui ont des types de condition supplémentaires et qui utilisent un langage spécifique à l'opérateur ont été omis.

L'opérateur de version de cluster (CVO) est chargé de collecter les conditions d'état des opérateurs de cluster afin que les administrateurs de cluster puissent mieux comprendre l'état du cluster OpenShift Container Platform.

  • Disponible : Le type de condition Available indique qu'un opérateur est fonctionnel et disponible dans le cluster. Si l'état est False, au moins une partie de l'opérande n'est pas fonctionnelle et l'état nécessite l'intervention d'un administrateur.

  • En progression : Le type de condition Progressing indique qu'un opérateur déploie activement un nouveau code, propage des changements de configuration ou passe d'un état stable à un autre.

    Les opérateurs ne signalent pas le type d'état Progressing comme True lorsqu'ils rapprochent un état antérieur connu. Si l'état observé de la grappe a changé et que l'opérateur y réagit, l'état est signalé comme étant True, puisqu'il passe d'un état stable à un autre.

  • Dégradé : Le type d'état Degraded indique que l'état actuel d'un opérateur ne correspond pas à l'état requis pendant un certain temps. La période de temps peut varier selon le composant, mais l'état Degraded représente une observation persistante de l'état d'un opérateur. Par conséquent, un opérateur ne fluctue pas dans et hors de l'état Degraded.

    Il peut y avoir un type de condition différent si la transition d'un état à un autre ne persiste pas pendant une période suffisamment longue pour que l'on puisse signaler Degraded. Un opérateur ne signale pas Degraded au cours d'une mise à niveau normale. Un opérateur peut signaler Degraded en réponse à une défaillance persistante de l'infrastructure qui nécessite l'intervention éventuelle d'un administrateur.

    Note

    Ce type de condition n'est qu'une indication que quelque chose peut nécessiter une investigation et un ajustement. Tant que l'opérateur est disponible, la condition Degraded n'entraîne pas de défaillance de la charge de travail de l'utilisateur ni de temps d'arrêt de l'application.

  • Évolutif : Le type de condition Upgradeable indique si l'opérateur peut être mis à niveau en toute sécurité en fonction de l'état actuel de la grappe. Le champ message contient une description lisible par l'homme de ce que l'administrateur doit faire pour que la mise à jour du cluster soit réussie. L'OVE autorise les mises à jour lorsque cette condition est True, Unknown ou manquante.

    Lorsque l'état de Upgradeable est False, seules les mises à jour mineures sont affectées, et l'OVE empêche le cluster d'effectuer les mises à jour affectées à moins d'y être contraint.

1.4. Comprendre les types de conditions relatives aux versions des clusters

L'opérateur de version de cluster (CVO) surveille les opérateurs de cluster et d'autres composants, et est responsable de la collecte de l'état de la version de cluster et de ses opérateurs. Ce statut inclut le type de condition, qui vous informe de la santé et de l'état actuel du cluster OpenShift Container Platform.

Outre Available, Progressing et Upgradeable, il existe des types de conditions qui affectent les versions des clusters et les opérateurs.

  • Échec : Le type de condition de version de cluster Failing indique qu'un cluster ne peut pas atteindre l'état souhaité, qu'il n'est pas sain et qu'il nécessite l'intervention d'un administrateur.
  • Invalide : Le type de condition de version de cluster Invalid indique que la version de cluster présente une erreur qui empêche le serveur d'agir. L'OVE ne réconcilie l'état actuel que si cette condition est définie.
  • RetrievedUpdates : Le type de condition de version du cluster RetrievedUpdates indique si les mises à jour disponibles ont été récupérées ou non auprès du serveur de mise à jour en amont. La condition est Unknown avant la récupération, False si les mises à jour ont récemment échoué ou n'ont pas pu être récupérées, ou True si le champ availableUpdates est à la fois récent et exact.
  • ReleaseAccepted : Le type de condition de la version du cluster ReleaseAccepted avec un statut True indique que la charge utile de libération demandée a été chargée avec succès et sans échec lors de la vérification de l'image et de la vérification des conditions préalables.
  • ImplicitlyEnabledCapabilities : Le type de condition de version de cluster ImplicitlyEnabledCapabilities avec un statut True indique qu'il existe des capacités activées que l'utilisateur ne demande pas actuellement via spec.capabilities. L'OVC ne prend pas en charge la désactivation des capacités si les ressources associées ont été précédemment gérées par l'OVC.

1.5. Préparation d'une mise à jour EUS-to-EUS

Préparation d'une mise à jour EUS-to-EUS: En raison de la conception fondamentale de Kubernetes, toutes les mises à jour d'OpenShift Container Platform entre les versions mineures doivent être sérialisées. Vous devez mettre à jour OpenShift Container Platform 4.10 vers 4.11, puis vers 4.12. Vous ne pouvez pas mettre à jour OpenShift Container Platform 4.10 vers 4.12 directement. Cependant, si vous souhaitez effectuer une mise à jour entre deux versions EUS (Extended Update Support), vous pouvez le faire en ne subissant qu'un seul redémarrage des hôtes du plan de contrôle. Pour plus d'informations, voir ce qui suit :

1.6. Mise à jour d'un cluster à l'aide de la console web

Mise à jour d'un cluster à l'aide de la console web: Vous pouvez mettre à jour un cluster OpenShift Container Platform en utilisant la console web. Les étapes suivantes permettent de mettre à jour un cluster au sein d'une version mineure. Vous pouvez utiliser les mêmes instructions pour mettre à jour un cluster entre des versions mineures.

1.7. Mise à jour d'un cluster à l'aide du CLI

Mise à jour d'un cluster à l'aide de la CLI: Vous pouvez mettre à jour un cluster OpenShift Container Platform dans une version mineure en utilisant la CLI OpenShift (oc). Les étapes suivantes permettent de mettre à jour un cluster au sein d'une version mineure. Vous pouvez utiliser les mêmes instructions pour mettre à jour un cluster entre des versions mineures.

1.8. Effectuer une mise à jour du déploiement du canari

Exécution d'une mise à jour par déploiement canarien: en contrôlant le déploiement d'une mise à jour vers les nœuds de travail, vous pouvez vous assurer que les applications stratégiques restent disponibles pendant toute la durée de la mise à jour, même si le processus de mise à jour entraîne une défaillance de vos applications. En fonction des besoins de votre organisation, vous pouvez mettre à jour un petit sous-ensemble de nœuds de travail, évaluer la santé de la grappe et de la charge de travail pendant un certain temps, puis mettre à jour les nœuds restants. C'est ce que l'on appelle une mise à jour canary. Il est également possible d'intégrer les mises à jour des nœuds de travail, qui nécessitent souvent un redémarrage de l'hôte, dans des fenêtres de maintenance définies plus petites lorsqu'il n'est pas possible de prendre une grande fenêtre de maintenance pour mettre à jour l'ensemble de la grappe en une seule fois. Vous pouvez effectuer les procédures suivantes :

1.9. Mise à jour d'un cluster comprenant des machines de calcul RHEL

Mise à jour d'un cluster comprenant des machines de calcul RHEL: Si votre cluster contient des machines Red Hat Enterprise Linux (RHEL), vous devez effectuer des étapes supplémentaires pour mettre à jour ces machines. Vous pouvez effectuer les procédures suivantes :

1.10. Mise à jour d'un cluster dans un environnement déconnecté

A propos des mises à jour de clusters dans un environnement déconnecté: Si votre hôte miroir ne peut pas accéder à la fois à Internet et au cluster, vous pouvez mettre en miroir les images sur un système de fichiers déconnecté de cet environnement. Vous pouvez ensuite faire passer l'hôte ou le support amovible à travers ce fossé. Si le registre de conteneurs local et le cluster sont connectés à l'hôte miroir d'un registre, vous pouvez directement pousser les images de version vers le registre local.

1.11. Mise à jour du matériel sur les nœuds fonctionnant dans vSphere

Mise à jour du matériel sur vSphere: Vous devez vous assurer que vos nœuds fonctionnant dans vSphere utilisent la version matérielle prise en charge par OpenShift Container Platform. Actuellement, la version 13 ou ultérieure du matériel est prise en charge pour les machines virtuelles vSphere dans un cluster. Pour plus d'informations, voir ce qui suit :

Important

L'utilisation de la version 13 du matériel pour vos nœuds de cluster fonctionnant sur vSphere est désormais obsolète. Cette version est encore entièrement prise en charge, mais elle sera supprimée dans une prochaine version d'OpenShift Container Platform. La version 15 du matériel est désormais la version par défaut pour les machines virtuelles vSphere dans OpenShift Container Platform.

Chapitre 2. Comprendre les mises à jour d'OpenShift Container Platform

Avec OpenShift Container Platform 4, vous pouvez mettre à jour un cluster OpenShift Container Platform en une seule opération en utilisant la console web ou l'OpenShift CLI (oc). Les administrateurs de la plateforme sont automatiquement notifiés lorsqu'une mise à jour est disponible pour leur cluster.

L'OpenShift Update Service (OSUS) construit un graphique des possibilités de mise à jour basé sur les images de version dans le registre. Le graphique est basé sur des chemins de mise à jour recommandés et testés à partir d'une version spécifique. Les clusters OpenShift Container Platform se connectent aux serveurs Red Hat Hybrid Cloud et identifient les clusters exécutés par l'utilisateur, ainsi que les informations relatives à la version. OSUS répond avec des informations sur les cibles de mise à jour connues. Un administrateur de cluster ou un contrôleur de mise à jour automatique édite la ressource personnalisée (CR) de l'opérateur de version de cluster (CVO) avec la nouvelle version à mettre à jour. Une fois que l'OVE a reçu l'image de mise à jour du registre, il applique les modifications.

Note

Les opérateurs précédemment installés par le biais du gestionnaire du cycle de vie des opérateurs (OLM) suivent un processus de mise à jour différent. Pour plus d'informations, voir Mise à jour des opérateurs installés.

2.1. À propos du service de mise à jour OpenShift

L'OpenShift Update Service (OSUS) fournit des recommandations de mise à jour à OpenShift Container Platform, y compris Red Hat Enterprise Linux CoreOS (RHCOS). Il fournit un graphique, ou diagramme, qui contient le site vertices des opérateurs de composants et le site edges qui les relie. Les arêtes du graphique indiquent les versions que vous pouvez mettre à jour en toute sécurité. Les sommets sont des charges utiles de mise à jour qui spécifient l'état prévu des composants du cluster géré.

Le Cluster Version Operator (CVO) dans votre cluster vérifie avec l'OpenShift Update Service pour voir les mises à jour valides et les chemins de mise à jour basés sur les versions actuelles des composants et les informations dans le graphique. Lorsque vous demandez une mise à jour, le CVO utilise l'image de la version de cette mise à jour pour mettre à jour votre cluster. Les artefacts de version sont hébergés dans Quay en tant qu'images de conteneur.

Pour permettre à OpenShift Update Service de ne fournir que des mises à jour compatibles, un pipeline de vérification des versions pilote l'automatisation. Chaque artefact de version est vérifié pour sa compatibilité avec les plateformes cloud et les architectures système prises en charge, ainsi qu'avec d'autres packages de composants. Une fois que le pipeline a confirmé l'adéquation d'une version, l'OpenShift Update Service vous informe qu'elle est disponible.

Important

Le service de mise à jour d'OpenShift affiche toutes les mises à jour recommandées pour votre cluster actuel. Si un chemin de mise à jour n'est pas recommandé par OpenShift Update Service, cela peut être dû à un problème connu avec la mise à jour ou la version cible.

Deux contrôleurs fonctionnent en mode de mise à jour continue. Le premier contrôleur met continuellement à jour les manifestes de charge utile, applique les manifestes au cluster et produit l'état de déploiement contrôlé des opérateurs pour indiquer s'ils sont disponibles, en cours de mise à niveau ou s'ils ont échoué. Le second contrôleur interroge le service de mise à jour OpenShift pour déterminer si des mises à jour sont disponibles.

Important

Seule la mise à niveau vers une version plus récente est prise en charge. L'inversion ou le retour à une version antérieure de votre cluster n'est pas pris en charge. Si votre mise à jour échoue, contactez l'assistance Red Hat.

Au cours du processus de mise à jour, le MCO (Machine Config Operator) applique la nouvelle configuration aux machines de votre cluster. Le MCO bloque le nombre de nœuds spécifié dans le champ maxUnavailable du pool de configuration de la machine et les marque comme étant indisponibles. Par défaut, cette valeur est définie sur 1. Le MCO met à jour les nœuds concernés par ordre alphabétique de zone, sur la base de l'étiquette topology.kubernetes.io/zone. Si une zone comporte plusieurs nœuds, les nœuds les plus anciens sont mis à jour en premier. Pour les nœuds qui n'utilisent pas de zones, comme dans les déploiements bare metal, les nœuds sont mis à niveau par âge, les nœuds les plus anciens étant mis à jour en premier. Le MCO met à jour le nombre de nœuds spécifié par le champ maxUnavailable du pool de configuration de la machine à la fois. Le MCO applique ensuite la nouvelle configuration et redémarre la machine.

Si vous utilisez des machines Red Hat Enterprise Linux (RHEL) en tant que travailleurs, le MCO ne met pas à jour le kubelet car vous devez d'abord mettre à jour l'API OpenShift sur les machines.

Avec la spécification de la nouvelle version appliquée à l'ancien kubelet, la machine RHEL ne peut pas revenir à l'état Ready. Vous ne pouvez pas terminer la mise à jour tant que les machines ne sont pas disponibles. Toutefois, le nombre maximal de nœuds indisponibles est défini de manière à ce que les opérations normales du cluster puissent se poursuivre avec ce nombre de machines hors service.

Le service de mise à jour OpenShift est composé d'un opérateur et d'une ou plusieurs instances d'application.

2.2. Termes courants

Control plane
Le site control plane, qui est composé de machines de plan de contrôle, gère le cluster OpenShift Container Platform. Les machines du plan de contrôle gèrent les charges de travail sur les machines de calcul, qui sont également connues sous le nom de machines de travail.
Opérateur de version de cluster
Le site Cluster Version Operator (CVO) lance le processus de mise à jour du cluster. Il vérifie auprès d'OSUS la version actuelle du cluster et récupère le graphique qui contient les chemins de mise à jour disponibles ou possibles.
Machine Config Operator
Le Machine Config Operator (MCO) est un opérateur au niveau du cluster qui gère le système d'exploitation et les configurations des machines. Grâce au MCO, les administrateurs de la plateforme peuvent configurer et mettre à jour systemd, CRI-O et Kubelet, le noyau, NetworkManager et d'autres fonctionnalités du système sur les nœuds de travail.
Service de mise à jour OpenShift
Le site OpenShift Update Service (OSUS) fournit des mises à jour over-the-air à OpenShift Container Platform, y compris à Red Hat Enterprise Linux CoreOS (RHCOS). Il fournit un graphique, ou diagramme, qui contient les sommets des composants Operators et les arêtes qui les relient.
Canaux
Channels déclarer une stratégie de mise à jour liée aux versions mineures d'OpenShift Container Platform. L'OSUS utilise cette stratégie configurée pour recommander des bords de mise à jour conformes à cette stratégie.
Bord de mise à jour recommandé
Un recommended update edge est une mise à jour recommandée entre les versions d'OpenShift Container Platform. Le fait qu'une mise à jour donnée soit recommandée peut dépendre du canal configuré du cluster, de la version actuelle, des bogues connus et d'autres informations. OSUS communique les bords recommandés à l'OVC, qui s'exécute dans chaque cluster.
Support de mise à jour étendu

Toutes les versions mineures postérieures à la version 4.7, dont le numéro est pair, sont étiquetées comme étant des versions Extended Update Support (EUS). Ces versions introduisent un chemin de mise à jour vérifié entre les versions EUS, permettant aux clients de rationaliser les mises à jour des nœuds de travailleur et de formuler des stratégies de mise à jour des versions EUS à EUS d'OpenShift Container Platform qui entraîneront moins de redémarrages des nœuds de travailleur.

Pour plus d'informations, voir Red Hat OpenShift Extended Update Support (EUS) Overview.

Ressources supplémentaires

Chapitre 3. Comprendre les canaux de mise à jour et les versions

Les canaux de mise à jour sont le mécanisme par lequel les utilisateurs déclarent la version mineure d'OpenShift Container Platform vers laquelle ils ont l'intention de mettre à jour leurs clusters. Ils permettent également aux utilisateurs de choisir le moment et le niveau de support de leurs mises à jour grâce aux options des canaux fast, stable, candidate, et eus. Le Cluster Version Operator utilise un graphique de mise à jour basé sur la déclaration de canal, ainsi que d'autres informations conditionnelles, pour fournir une liste de mises à jour recommandées et conditionnelles disponibles pour le cluster.

Les canaux de mise à jour correspondent à une version mineure d'OpenShift Container Platform. Le numéro de version du canal représente la version mineure cible vers laquelle le cluster sera éventuellement mis à jour, même si elle est supérieure à la version mineure actuelle du cluster.

Par exemple, les canaux de mise à jour d'OpenShift Container Platform 4.10 fournissent les recommandations suivantes :

  • Mises à jour dans 4.10.
  • Mises à jour dans 4.9.
  • Mise à jour de la version 4.9 à la version 4.10, permettant à tous les clusters 4.9 de passer à la version 4.10, même s'ils ne répondent pas immédiatement aux exigences minimales de la version z-stream.
  • eus-4.10 uniquement : mises à jour dans le cadre de 4.8.
  • eus-4.10 uniquement : mise à jour de la version 4.8 à la version 4.9 puis à la version 4.10, permettant à tous les clusters 4.8 d'être mis à jour vers la version 4.10.

4.10 ne recommandent pas les mises à jour vers la version 4.11 ou les versions ultérieures. Cette stratégie garantit que les administrateurs doivent explicitement décider de mettre à jour la prochaine version mineure d'OpenShift Container Platform.

Les canaux de mise à jour ne contrôlent que la sélection des versions et n'ont pas d'impact sur la version du cluster que vous installez. Le fichier binaire openshift-install pour une version spécifique d'OpenShift Container Platform installe toujours cette version.

OpenShift Container Platform 4.12 offre les canaux de mise à jour suivants :

  • stable-4.12
  • eus-4.y (offert uniquement pour les versions EUS et destiné à faciliter les mises à niveau entre les versions EUS)
  • fast-4.12
  • candidate-4.12

Si vous ne souhaitez pas que le Cluster Version Operator récupère les mises à jour disponibles auprès du service de recommandation de mise à jour, vous pouvez utiliser la commande oc adm upgrade channel dans la CLI OpenShift pour configurer un canal vide. Cette configuration peut être utile si, par exemple, un cluster a un accès réseau restreint et qu'il n'y a pas de service de recommandation de mise à jour local et joignable.

Avertissement

Red Hat recommande de mettre à jour les versions suggérées par OpenShift Update Service uniquement. Pour une mise à jour de version mineure, les versions doivent être contiguës. Red Hat ne teste pas les mises à jour vers des versions non contiguës et ne peut pas garantir la compatibilité avec les versions antérieures.

3.1. Mise à jour des canaux

3.1.1. canal rapide-4.12

Le canal fast-4.12 est mis à jour avec les nouvelles versions d'OpenShift Container Platform 4.12 dès que Red Hat déclare la version comme étant une version de disponibilité générale (GA). En tant que telles, ces versions sont entièrement prises en charge et destinées à être utilisées dans des environnements de production.

3.1.2. canal stable-4.12

Alors que le canal fast-4.12 contient les communiqués dès que leurs errata sont publiés, les communiqués sont ajoutés au canal stable-4.12 après un certain délai. Pendant ce délai, des données sont collectées à partir de sources multiples et analysées pour détecter les signes de régression des produits. Une fois qu'un nombre significatif de points de données a été collecté, et en l'absence de signaux négatifs, ces versions sont ajoutées au canal stable.

Note

Étant donné que le temps nécessaire pour obtenir un nombre significatif de points de données varie en fonction de nombreux facteurs, l'objectif de niveau de service (SLO) n'est pas proposé pour la durée du délai entre les canaux rapides et les canaux stables. Pour plus d'informations, veuillez consulter le document "Choosing the correct channel for your cluster" (en anglais)

Les clusters nouvellement installés utilisent par défaut les canaux stables.

3.1.3. canal eus-4.y

En plus du canal stable, toutes les versions mineures paires d'OpenShift Container Platform offrent un support de mise à jour étendu (EUS). Les versions promues sur le canal stable sont également promues simultanément sur les canaux EUS. L'objectif principal des canaux EUS est de servir de commodité pour les clusters effectuant une mise à jour EUS-to-EUS.

Note

Les abonnés standard et non EUS peuvent accéder à tous les dépôts EUS et aux RPM nécessaires (rhel-*-eus-rpms) pour pouvoir répondre à des besoins critiques tels que le débogage et la construction de pilotes.

3.1.4. canal candidat-4.12

Le canal candidate-4.12 offre un accès anticipé non supporté aux versions dès qu'elles sont construites. Les versions présentes uniquement dans les canaux candidats peuvent ne pas contenir l'ensemble des fonctionnalités des éventuelles versions GA ou des fonctionnalités peuvent être supprimées avant la GA. De plus, ces versions n'ont pas été soumises à l'assurance qualité complète de Red Hat et peuvent ne pas offrir de chemins de mise à jour vers les versions GA ultérieures. Compte tenu de ces mises en garde, le canal candidat ne convient qu'à des fins de test où la destruction et la recréation d'un cluster sont acceptables.

3.1.5. Mise à jour des recommandations dans le canal

OpenShift Container Platform dispose d'un service de recommandation de mise à jour qui connaît la version d'OpenShift Container Platform que vous avez installée et le chemin à suivre au sein du canal pour passer à la version suivante. Les chemins de mise à jour sont également limités aux versions pertinentes pour votre canal actuellement sélectionné et ses caractéristiques de promotion.

Vous pouvez imaginer voir les communiqués suivants dans votre chaîne :

  • 4.12.0
  • 4.12.1
  • 4.12.3
  • 4.12.4

Le service recommande uniquement les mises à jour qui ont été testées et qui ne présentent aucune régression grave connue. Par exemple, si votre cluster est sur 4.12.1 et que OpenShift Container Platform suggère 4.12.4, il est recommandé de mettre à jour de 4.12.1 à 4.12.4.

Important

Ne vous fiez pas aux numéros de correctifs consécutifs. Dans cet exemple, la version 4.12.2 n'est pas et n'a jamais été disponible dans le canal ; les mises à jour vers la version 4.12.2 ne sont donc ni recommandées ni prises en charge.

3.1.6. Suppression des recommandations de mise à jour et mises à jour conditionnelles

Red Hat surveille les nouvelles versions et les chemins de mise à jour associés à ces versions avant et après leur ajout aux canaux pris en charge. Si une régression sérieuse est identifiée, Red Hat peut supprimer les recommandations de mise à jour concernées. Lorsque Red Hat choisit de supprimer les recommandations de mise à jour, cette action est prise simultanément dans tous les canaux concernés. La suppression des recommandations de mise à jour peut avoir lieu avant ou après que les mises à jour aient été promues dans les canaux pris en charge.

Si Red Hat supprime les recommandations de mise à jour d'une version prise en charge, une recommandation de mise à jour de remplacement sera fournie pour une version future qui corrige la régression. Il peut cependant y avoir un délai pendant que le défaut est corrigé, testé et promu à votre canal sélectionné.

À partir d'OpenShift Container Platform 4.10, lorsque les recommandations de mise à jour sont supprimées des canaux pris en charge, elles sont remplacées par des mises à jour conditionnelles qui déclarent un ou plusieurs risques connus. Chaque risque connu peut s'appliquer à tous les clusters ou uniquement aux clusters correspondant à certaines conditions. Par exemple, si le site Platform est défini sur None ou si le fournisseur CNI est défini sur OpenShiftSDN, l'opérateur de version de cluster (CVO) évalue en permanence les risques connus par rapport à l'état actuel du cluster. Si aucun risque ne correspond, la mise à jour est recommandée. Si le risque correspond, ces mises à jour sont répertoriées comme une mise à jour Supported But Not Recommended et un lien de référence est fourni. Le lien de référence aide l'administrateur du cluster à décider s'il souhaite accepter le risque et procéder à la mise à jour.

3.1.7. Choisir le bon canal pour votre cluster

Le choix du canal approprié implique deux décisions.

Tout d'abord, sélectionnez la version mineure que vous souhaitez pour la mise à niveau de votre cluster. La sélection d'un canal correspondant à votre version actuelle garantit que vous n'appliquerez que les mises à jour du flux z et que vous ne recevrez pas de mises à jour des fonctionnalités. En sélectionnant un canal disponible dont la version est supérieure à votre version actuelle, vous vous assurez qu'après une ou plusieurs mises à jour, votre cluster aura été mis à jour vers cette version. Votre cluster ne se verra proposer que des canaux correspondant à sa version actuelle, à la version suivante ou à la version EUS suivante.

Note

En raison de la complexité de la planification des mises à jour entre des versions éloignées de plusieurs mineurs, les canaux qui aident à planifier les mises à jour au-delà d'une seule mise à jour de EUS à EUS ne sont pas proposés.

Deuxièmement, vous devez choisir votre stratégie de déploiement. Vous pouvez choisir de mettre à jour dès que Red Hat déclare une version GA en sélectionnant les canaux rapides ou vous pouvez attendre que Red Hat promeuve les versions vers le canal stable. Les recommandations de mise à jour proposées sur fast-4.12 et stable-4.12 sont toutes deux entièrement prises en charge et bénéficient de la même manière de l'analyse continue des données. Le délai de promotion avant de promouvoir une version vers le canal stable représente la seule différence entre les deux canaux. Les mises à jour des derniers flux z sont généralement promues vers le canal stable dans un délai d'une semaine ou deux, mais le délai de déploiement initial des mises à jour de la dernière version mineure est beaucoup plus long, généralement de 45 à 90 jours. Veuillez tenir compte du délai de promotion lorsque vous choisissez le canal que vous souhaitez, car l'attente de la promotion vers le canal stable peut avoir une incidence sur vos plans de programmation.

En outre, plusieurs facteurs peuvent amener une organisation à passer à la voie rapide de manière permanente ou temporaire, notamment

  • Le désir d'appliquer sans délai un correctif spécifique dont on sait qu'il affecte votre environnement.
  • Application sans délai des corrections CVE. Les correctifs CVE peuvent introduire des régressions, de sorte que les délais de promotion s'appliquent toujours aux flux z comportant des correctifs CVE.
  • Processus de test interne. S'il faut plusieurs semaines à votre organisation pour qualifier les versions, il est préférable de tester en même temps que notre processus de promotion plutôt que d'attendre. Cela garantit également que tout signal de télémétrie fourni à Red Hat est pris en compte dans notre déploiement, de sorte que les problèmes qui vous concernent peuvent être corrigés plus rapidement.

3.1.8. Clusters de réseaux restreints

Si vous gérez vous-même les images de conteneurs pour vos clusters OpenShift Container Platform, vous devez consulter l'errata de Red Hat qui est associé aux versions du produit et noter tout commentaire ayant un impact sur les mises à jour. Lors d'une mise à jour, l'interface utilisateur peut vous avertir de la nécessité de passer d'une version à l'autre, vous devez donc vous assurer que vous avez sélectionné une version appropriée avant de contourner ces avertissements.

3.1.9. Passer d'un canal à l'autre

Un canal peut être commuté à partir de la console web ou de la commande adm upgrade channel: 

$ oc adm upgrade channel <channel>

La console web affichera une alerte si vous passez à un canal qui n'inclut pas la version actuelle. La console web ne recommande aucune mise à jour lorsque vous êtes sur un canal sans la version actuelle. Vous pouvez toutefois revenir au canal d'origine à tout moment.

Le changement de canal peut avoir un impact sur la capacité de support de votre cluster. Les conditions suivantes peuvent s'appliquer :

  • Votre cluster est toujours pris en charge si vous passez du canal stable-4.12 au canal fast-4.12.
  • Vous pouvez passer au canal candidate-4.12 à tout moment, mais certaines versions de ce canal peuvent ne pas être prises en charge.
  • Vous pouvez passer du canal candidate-4.12 au canal fast-4.12 si votre version actuelle est une version de disponibilité générale.
  • Vous pouvez toujours passer du canal fast-4.12 au canal stable-4.12. Un délai pouvant aller jusqu'à un jour peut s'écouler avant que la version soit promue sur stable-4.12 si la version actuelle a été récemment promue.

Ressources supplémentaires

Chapitre 4. Comprendre la durée de mise à jour d'OpenShift Container Platform

La durée de mise à jour d'OpenShift Container Platform varie en fonction de la topologie du déploiement. Cette page vous aide à comprendre les facteurs qui affectent la durée de la mise à jour et à estimer la durée de la mise à jour du cluster dans votre environnement.

4.1. Conditions préalables

4.2. Facteurs influençant la durée de la mise à jour

Les facteurs suivants peuvent affecter la durée de mise à jour de votre cluster :

  • Le redémarrage des nœuds de calcul vers la nouvelle configuration de la machine par l'opérateur de configuration de la machine (MCO)

    • La valeur de MaxUnavailable dans le pool de configuration de la machine
    • Le nombre minimum ou les pourcentages de répliques définis dans le budget de perturbation des pods (PDB)
  • Le nombre de nœuds dans la grappe
  • L'état de santé des nœuds de la grappe

4.3. Phases de mise à jour des clusters

Dans OpenShift Container Platform, la mise à jour du cluster se fait en deux phases :

  • Déploiement de la charge utile de mise à jour de la cible de l'opérateur de version de cluster (CVO)
  • Mises à jour du nœud de configuration de la machine (MCO)

4.3.1. Cluster Version Operator target update payload deployment (déploiement de la charge utile de mise à jour de la cible)

Le Cluster Version Operator (CVO) récupère l'image de la mise à jour cible et l'applique au cluster. Tous les composants qui fonctionnent en tant que pods sont mis à jour au cours de cette phase, tandis que les composants hôtes sont mis à jour par l'opérateur de configuration de la machine (MCO). Ce processus peut durer de 60 à 120 minutes.

Note

La phase CVO de la mise à jour ne redémarre pas les nœuds.

Ressources supplémentaires

4.3.2. Config Machine Mises à jour du nœud de l'opérateur

L'opérateur de configuration de machine (MCO) applique une nouvelle configuration de machine à chaque plan de contrôle et à chaque nœud de calcul. Au cours de ce processus, le MCO effectue les actions séquentielles suivantes sur chaque nœud de la grappe :

  1. Cordon et drainage de tous les nœuds
  2. Mettre à jour le système d'exploitation (OS)
  3. Redémarrer les nœuds
  4. Déconnexion de tous les nœuds et programmation des charges de travail sur le nœud
Note

Lorsqu'un nœud est bloqué, il n'est pas possible d'y planifier des charges de travail.

La durée de ce processus dépend de plusieurs facteurs, notamment de la configuration du nœud et de l'infrastructure. Ce processus peut prendre 5 minutes ou plus par nœud.

Outre le MCO, vous devez tenir compte de l'impact des paramètres suivants :

  • La durée de mise à jour des nœuds du plan de contrôle est prévisible et souvent plus courte que celle des nœuds de calcul, car les charges de travail du plan de contrôle sont réglées pour des mises à jour gracieuses et des vidanges rapides.
  • Vous pouvez mettre à jour les nœuds de calcul en parallèle en définissant le champ maxUnavailable sur une valeur supérieure à 1 dans le pool de configuration de la machine (MCP). Le MCO met en cordon le nombre de nœuds spécifié dans maxUnavailable et les marque comme indisponibles pour la mise à jour.
  • Lorsque vous augmentez maxUnavailable sur le MCP, cela peut aider le pool à se mettre à jour plus rapidement. Toutefois, si maxUnavailable est trop élevé et que plusieurs nœuds sont bloqués simultanément, les charges de travail protégées par le budget de perturbation des pods (PDB) risquent de ne pas s'écouler car aucun nœud planifiable ne peut être trouvé pour exécuter les répliques. Si vous augmentez maxUnavailable pour le MCP, assurez-vous que vous disposez toujours d'un nombre suffisant de nœuds ordonnançables pour permettre aux charges de travail protégées par PDB de s'écouler.

  • Avant de commencer la mise à jour, vous devez vous assurer que tous les nœuds sont disponibles. Tout nœud indisponible peut avoir un impact significatif sur la durée de la mise à jour, car l'indisponibilité du nœud affecte les budgets d'interruption de maxUnavailable et de pod.

    Pour vérifier l'état des nœuds à partir du terminal, exécutez la commande suivante : 

    $ oc get node

    Example Output

    NAME                                        STATUS                      ROLES   AGE     VERSION
ip-10-0-137-31.us-east-2.compute.internal   Ready,SchedulingDisabled    worker  12d     v1.23.5+3afdacb
ip-10-0-151-208.us-east-2.compute.internal  Ready                       master  12d     v1.23.5+3afdacb
ip-10-0-176-138.us-east-2.compute.internal  Ready                       master  12d     v1.23.5+3afdacb
ip-10-0-183-194.us-east-2.compute.internal  Ready                       worker  12d     v1.23.5+3afdacb
ip-10-0-204-102.us-east-2.compute.internal  Ready                       master  12d     v1.23.5+3afdacb
ip-10-0-207-224.us-east-2.compute.internal  Ready                       worker  12d     v1.23.5+3afdacb

    Si l'état du nœud est NotReady ou SchedulingDisabled, le nœud n'est pas disponible, ce qui a une incidence sur la durée de la mise à jour.

    Vous pouvez vérifier l'état des nœuds à partir de la perspective Administrator dans la console web en développant Compute → Node.

Ressources supplémentaires

4.4. Estimation du temps de mise à jour des grappes

L'historique de la durée de mise à jour de clusters similaires vous fournit la meilleure estimation pour les futures mises à jour de clusters. Toutefois, si les données historiques ne sont pas disponibles, vous pouvez utiliser la convention suivante pour estimer la durée de mise à jour de votre grappe : 

Cluster update time = CVO target update payload deployment time + (# node update iterations x MCO node update time)

Une itération de mise à jour de nœud consiste en un ou plusieurs nœuds mis à jour en parallèle. Les nœuds du plan de contrôle sont toujours mis à jour en parallèle avec les nœuds de calcul. En outre, un ou plusieurs nœuds de calcul peuvent être mis à jour en parallèle sur la base de la valeur maxUnavailable.

Par exemple, pour estimer le temps de mise à jour, considérons un cluster OpenShift Container Platform avec trois nœuds de plan de contrôle et six nœuds de calcul et chaque hôte prend environ 5 minutes pour redémarrer.

Note

Le temps nécessaire au redémarrage d'un nœud donné varie considérablement. Dans les instances en nuage, le redémarrage peut prendre environ 1 à 2 minutes, alors que dans les hôtes physiques en métal nu, le redémarrage peut prendre plus de 15 minutes.

Scénario 1

Lorsque vous définissez maxUnavailable sur 1 pour le plan de contrôle et les nœuds de calcul Machine Config Pool (MCP), les six nœuds de calcul seront mis à jour l'un après l'autre à chaque itération : 

Cluster update time = 60 + (6 x 5) = 90 minutes

Scénario 2

Lorsque vous définissez maxUnavailable sur 2 pour le nœud de calcul MCP, deux nœuds de calcul sont mis à jour en parallèle à chaque itération. Il faut donc trois itérations au total pour mettre à jour tous les nœuds. 

Cluster update time = 60 + (3 x 5) = 75 minutes
Important

Le paramètre par défaut pour maxUnavailable est 1 pour tous les MCP dans OpenShift Container Platform. Il est recommandé de ne pas modifier maxUnavailable dans le MCP du plan de contrôle.

4.5. Nœuds de calcul Red Hat Enterprise Linux (RHEL)

Les nœuds de calcul Red Hat Enterprise Linux (RHEL) nécessitent une utilisation supplémentaire de openshift-ansible pour mettre à jour les composants binaires des nœuds. Le temps réel consacré à la mise à jour des nœuds de calcul RHEL ne devrait pas être très différent de celui des nœuds de calcul Red Hat Enterprise Linux CoreOS (RHCOS).

Ressources supplémentaires

Chapitre 5. Préparation de la mise à jour vers OpenShift Container Platform 4.12

OpenShift Container Platform 4.12 utilise Kubernetes 1.25, qui a supprimé plusieurs API obsolètes.

Un administrateur de cluster doit fournir un accusé de réception manuel avant que le cluster puisse être mis à jour d'OpenShift Container Platform 4.11 à 4.12. Cela permet d'éviter les problèmes après la mise à niveau vers OpenShift Container Platform 4.12, lorsque les API qui ont été supprimées sont encore utilisées par des charges de travail, des outils ou d'autres composants s'exécutant sur le cluster ou interagissant avec lui. Les administrateurs doivent évaluer leur cluster pour détecter les API utilisées qui seront supprimées et migrer les composants concernés pour utiliser la nouvelle version appropriée de l'API. Une fois l'évaluation et la migration terminées, l'administrateur peut fournir l'accusé de réception.

Avant de pouvoir mettre à jour votre cluster OpenShift Container Platform 4.11 vers 4.12, vous devez fournir l'accusé de réception de l'administrateur.

5.1. API Kubernetes supprimées

OpenShift Container Platform 4.12 utilise Kubernetes 1.25, qui a supprimé les API dépréciées suivantes. Vous devez migrer les manifestes et les clients API pour utiliser la version appropriée de l'API. Pour plus d'informations sur la migration des API supprimées, consultez la documentation Kubernetes.

Tableau 5.1. API supprimées de Kubernetes 1.25
RessourcesAPI suppriméeMigrer versChangements notables

CronJob

batch/v1beta1

batch/v1

Non

EndpointSlice

discovery.k8s.io/v1beta1

discovery.k8s.io/v1

Oui

Event

events.k8s.io/v1beta1

events.k8s.io/v1

Oui

HorizontalPodAutoscaler

autoscaling/v2beta1

autoscaling/v2

Non

PodDisruptionBudget

policy/v1beta1

policy/v1

Oui

PodSecurityPolicy

policy/v1beta1

Admission à la sécurité des pods [1]

Oui

RuntimeClass

node.k8s.io/v1beta1

node.k8s.io/v1

Non

  1. Pour plus d'informations sur l'admission de la sécurité des pods dans OpenShift Container Platform, voir Understanding and managing pod security admission.

Ressources supplémentaires

5.2. Évaluation de votre cluster pour les API supprimées

Il existe plusieurs méthodes pour aider les administrateurs à identifier où les API qui seront supprimées sont utilisées. Cependant, OpenShift Container Platform ne peut pas identifier toutes les instances, en particulier les charges de travail qui sont inactives ou les outils externes qui sont utilisés. Il est de la responsabilité de l'administrateur d'évaluer correctement toutes les charges de travail et autres intégrations pour les instances d'API supprimées.

5.2.1. Examen des alertes pour identifier les utilisations d'API supprimées

Deux alertes sont déclenchées lorsqu'une API est utilisée et seront supprimées dans la prochaine version :

  • APIRemovedInNextReleaseInUse - pour les API qui seront supprimées dans la prochaine version d'OpenShift Container Platform.
  • APIRemovedInNextEUSReleaseInUse - pour les API qui seront supprimées dans la prochaine version d'OpenShift Container Platform Extended Update Support (EUS).

Si l'une de ces alertes se déclenche dans votre cluster, examinez les alertes et prenez des mesures pour les supprimer en migrant les manifestes et les clients API afin d'utiliser la nouvelle version de l'API.

Utilisez l'API APIRequestCount pour obtenir davantage d'informations sur les API utilisées et les charges de travail qui utilisent les API supprimées, car les alertes ne fournissent pas ces informations. En outre, certaines API peuvent ne pas déclencher ces alertes, mais sont tout de même capturées par APIRequestCount. Les alertes sont réglées pour être moins sensibles afin d'éviter la fatigue des alertes dans les systèmes de production.

5.2.2. Utiliser APIRequestCount pour identifier les utilisations d'API supprimées

Vous pouvez utiliser l'API APIRequestCount pour suivre les demandes d'API et vérifier si l'une d'entre elles utilise l'une des API supprimées.

Conditions préalables

  • Vous devez avoir accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

  • Exécutez la commande suivante et examinez la colonne REMOVEDINRELEASE du résultat pour identifier les API supprimées qui sont actuellement utilisées : 

    $ oc get apirequestcounts

    Exemple de sortie

    NAME                                                                      REMOVEDINRELEASE   REQUESTSINCURRENTHOUR   REQUESTSINLAST24H
...
poddisruptionbudgets.v1.policy                                                               391                     8114
poddisruptionbudgets.v1beta1.policy                                       1.25               2                       23
podmonitors.v1.monitoring.coreos.com                                                         3                       70
podnetworkconnectivitychecks.v1alpha1.controlplane.operator.openshift.io                     612                     11748
pods.v1                                                                                      1531                    38634
podsecuritypolicies.v1beta1.policy                                        1.25               3                       39
podtemplates.v1                                                                              2                       79
preprovisioningimages.v1alpha1.metal3.io                                                     2                       39
priorityclasses.v1.scheduling.k8s.io                                                         12                      248
prioritylevelconfigurations.v1beta1.flowcontrol.apiserver.k8s.io          1.26               3                       86
...

    Important

    Vous pouvez ignorer les entrées suivantes qui apparaissent dans les résultats :

    • Les utilisateurs system:serviceaccount:kube-system:generic-garbage-collector et system:serviceaccount:kube-system:namespace-controller peuvent apparaître dans les résultats car ces services invoquent toutes les API enregistrées lorsqu'ils recherchent des ressources à supprimer.
    • Les utilisateurs system:kube-controller-manager et system:cluster-policy-controller peuvent apparaître dans les résultats parce qu'ils parcourent toutes les ressources tout en appliquant diverses politiques.

    Vous pouvez également utiliser -o jsonpath pour filtrer les résultats : 

    $ oc get apirequestcounts -o jsonpath='{range .items[ ?(@.status.removedInRelease!="\N")]}{.status.removedInRelease}{\N-"\N-"\N"}{\N-"\N"\N"\N"}{\N-"\N"\N"\N"\N"\N"\N"\N"\N"\N"\N"\N"\N "end}

    Exemple de sortie

    1.26	flowschemas.v1beta1.flowcontrol.apiserver.k8s.io
1.26	horizontalpodautoscalers.v2beta2.autoscaling
1.25	poddisruptionbudgets.v1beta1.policy
1.25	podsecuritypolicies.v1beta1.policy
1.26	prioritylevelconfigurations.v1beta1.flowcontrol.apiserver.k8s.io

5.2.3. Utiliser APIRequestCount pour identifier les charges de travail qui utilisent les API supprimées

Vous pouvez examiner la ressource APIRequestCount pour une version donnée de l'API afin d'identifier les charges de travail qui utilisent l'API.

Conditions préalables

  • Vous devez avoir accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

  • Exécutez la commande suivante et examinez les champs username et userAgent pour identifier les charges de travail qui utilisent l'API : 

    $ oc get apirequestcounts <resource>.<version>.<group> -o yaml

    Par exemple : 

    $ oc get apirequestcounts poddisruptionbudgets.v1beta1.policy -o yaml

    Vous pouvez également utiliser -o jsonpath pour extraire les valeurs username et userAgent d'une ressource APIRequestCount: 

    $ oc get apirequestcounts poddisruptionbudgets.v1beta1.policy \
  -o jsonpath='{range .status.currentHour..byUser[*]}{..byVerb[*].verb}{","}{.username}{","}{.userAgent}{"\n"}{end}' \
  | sort -k 2 -t, -u | column -t -s, -NVERBS,USERNAME,USERAGENT

    Exemple de sortie

    VERBS  USERNAME                                                                       USERAGENT
watch  system:serviceaccount:openshift-operators:3scale-operator                      manager/v0.0.0
watch  system:serviceaccount:openshift-operators:datadog-operator-controller-manager  manager/v0.0.0

5.3. Migration des instances d'API supprimées

Pour plus d'informations sur la migration des API Kubernetes supprimées, voir le Deprecated API Migration Guide dans la documentation Kubernetes.

5.4. Fournir l'accusé de réception de l'administrateur

Une fois que vous avez évalué votre cluster pour les API supprimées et que vous avez migré les API supprimées, vous pouvez confirmer que votre cluster est prêt à passer d'OpenShift Container Platform 4.11 à 4.12.

Avertissement

Sachez qu'il incombe à l'administrateur de s'assurer que toutes les utilisations des API supprimées ont été résolues et migrées si nécessaire avant de fournir cet accusé de réception de l'administrateur. OpenShift Container Platform peut aider à l'évaluation, mais ne peut pas identifier toutes les utilisations possibles des API supprimées, en particulier les charges de travail inactives ou les outils externes.

Conditions préalables

  • Vous devez avoir accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

  • Exécutez la commande suivante pour confirmer que vous avez terminé l'évaluation et que votre cluster est prêt pour les suppressions de l'API Kubernetes dans OpenShift Container Platform 4.12 : 

    $ oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.11-kube-1.25-api-removals-in-4.12":"true"}}' --type=merge

Chapitre 6. Préparation d'une mise à jour EUS-to-EUS

En raison de la conception fondamentale de Kubernetes, toutes les mises à jour d'OpenShift Container Platform entre les versions mineures doivent être sérialisées. Vous devez mettre à jour OpenShift Container Platform <4.y> vers <4.y 1>, puis vers <4.y 2>. Vous ne pouvez pas mettre à jour OpenShift Container Platform <4.y> vers <4.y 2> directement. Cependant, les administrateurs qui souhaitent effectuer une mise à jour entre deux versions Extended Update Support (EUS) peuvent le faire en ne subissant qu'un seul redémarrage des hôtes ne faisant pas partie du plan de contrôle.

Important

Les mises à jour EUS-to-EUS ne sont viables qu'entre even-numbered minor versions d'OpenShift Container Platform.

Il y a un certain nombre de mises en garde à prendre en compte lors d'une mise à jour EUS-to-EUS.

  • Les mises à jour EUS-to-EUS ne sont proposées que lorsque les mises à jour entre toutes les versions concernées ont été mises à disposition sur les canaux stable.
  • Si vous rencontrez des problèmes pendant ou après la mise à jour vers la version mineure impaire mais avant la mise à jour vers la version paire suivante, la résolution de ces problèmes peut nécessiter que les hôtes du plan de contrôle terminent la mise à jour vers la version impaire avant d'aller de l'avant.
  • Vous pouvez effectuer une mise à jour partielle en mettant à jour les nœuds du pool de travail ou du pool personnalisé pour tenir compte du temps nécessaire à la maintenance.
  • Vous pouvez terminer le processus de mise à jour pendant plusieurs fenêtres de maintenance en vous arrêtant à des étapes intermédiaires. Cependant, prévoyez de terminer la mise à jour complète dans les 60 jours. Ce délai est essentiel pour garantir l'achèvement des processus normaux d'automatisation des clusters, y compris ceux associés à la rotation des certificats.
  • Jusqu'à ce que les pools de configuration des machines soient désactivés et que la mise à jour soit terminée, certaines fonctionnalités et corrections de bogues dans <4.y 1> et <4.y 2> d'OpenShift Container Platform ne sont pas disponibles.
  • Tous les clusters peuvent se mettre à jour en utilisant les canaux EUS pour une mise à jour conventionnelle sans pause des pools, mais seuls les clusters avec des objets MachineConfigPools sans plan de contrôle peuvent effectuer une mise à jour EUS-to-EUS avec pause des pools.

6.1. Mise à jour EUS-to-EUS

La procédure suivante met en pause tous les pools de configuration de machines non maîtres et effectue les mises à jour de OpenShift Container Platform <4.y> vers <4.y 1> vers <4.y 2>, puis annule les pools de configuration de machines précédemment mis en pause. Cette procédure permet de réduire la durée totale des mises à jour et le nombre de redémarrages des nœuds de travail.

Conditions préalables

  • Consultez les notes de version pour OpenShift Container Platform <4.y 1> et <4.y 2>
  • Examinez les notes de mise à jour et les cycles de vie des produits en couches et des opérateurs OLM (Operator Lifecycle Manager). Certains peuvent nécessiter des mises à jour avant ou pendant une mise à jour EUS-to-EUS.
  • Assurez-vous que vous connaissez les conditions préalables spécifiques à la version, telles que la suppression des API obsolètes, qui sont requises avant la mise à jour de OpenShift Container Platform <4.y 1> vers <4.y 2>.

6.1.1. Mise à jour EUS-to-EUS à l'aide de la console web

Conditions préalables

  • Vérifiez que les pools de configuration des machines sont désactivés.
  • Avoir accès à la console web en tant qu'utilisateur avec les privilèges admin.

Procédure

  1. En utilisant la perspective de l'administrateur sur la console web, mettez à jour tous les opérateurs OLM (Operator Lifecycle Manager) vers les versions compatibles avec la version mise à jour que vous souhaitez obtenir. Vous trouverez de plus amples informations sur la manière d'effectuer cette action dans la section "Mise à jour des opérateurs installés" ; voir "Ressources supplémentaires".

  2. Vérifiez que tous les pools de configuration de machines affichent un état de Up to date et qu'aucun pool de configuration de machines n'affiche un état de UPDATING.

    Pour afficher l'état de tous les pools de configuration de machines, cliquez sur Compute → MachineConfigPools et examinez le contenu de la colonne Update status.

    Note

    Si les pools de configuration de votre machine ont un statut Updating, veuillez attendre que ce statut passe à Up to date. Ce processus peut prendre plusieurs minutes.

  3. Réglez votre chaîne sur eus-<4.y 2>.

    Pour définir votre canal, cliquez sur Administration → Cluster Settings → Channel. Vous pouvez modifier votre chaîne en cliquant sur la chaîne actuelle en hyperlien.

  4. Mettez en pause tous les pools de machines de travail, à l'exception du pool principal. Vous pouvez effectuer cette action dans l'onglet MachineConfigPools sous la page Compute. Sélectionnez les ellipses verticales à côté du pool de configuration de machines que vous souhaitez mettre en pause et cliquez sur Pause updates.
  5. Mettez à jour vers la version <4.y 1> et complétez jusqu'à l'étape Save. Vous trouverez plus d'informations sur la manière d'effectuer ces actions dans "Mise à jour d'un cluster à l'aide de la console Web" ; voir "Ressources supplémentaires".
  6. Assurez-vous que les mises à jour <4.y 1> sont complètes en consultant le site Last completed version de votre cluster. Vous trouverez ces informations sur la page Cluster Settings, sous l'onglet Details.
  7. Si nécessaire, mettez à jour vos opérateurs OLM en utilisant la perspective de l'administrateur dans la console web. Vous trouverez plus d'informations sur la manière d'effectuer ces actions dans "Mise à jour des opérateurs installés" ; voir "Ressources supplémentaires".
  8. Mettez à jour vers la version <4.y 2> et complétez jusqu'à l'étape Save. Vous trouverez plus d'informations sur la manière d'effectuer ces actions dans "Mise à jour d'un cluster à l'aide de la console Web" ; voir "Ressources supplémentaires".
  9. Assurez-vous que la mise à jour <4.y 2> est terminée en consultant le site Last completed version de votre cluster. Vous trouverez ces informations sur la page Cluster Settings, sous l'onglet Details.

  10. Désactiver tous les pools de configuration de machines précédemment mis en pause. Vous pouvez effectuer cette action dans l'onglet MachineConfigPools sous la page Compute. Sélectionnez les ellipses verticales à côté du pool de configuration de machines que vous souhaitez mettre en pause et cliquez sur Unpause updates.

    Important

    Si les pools ne sont pas désactivés, la grappe n'est pas autorisée à passer à une version mineure ultérieure et les tâches de maintenance telles que la rotation des certificats sont inhibées. La grappe risque donc de se dégrader à l'avenir.

  11. Vérifiez que les pools précédemment mis en pause sont mis à jour et que votre cluster a terminé la mise à jour vers la version <4.y 2>.

    Vous pouvez vérifier que vos pools ont été mis à jour dans l'onglet MachineConfigPools sous la page Compute en confirmant que la valeur de Update status est Up to date.

    Vous pouvez vérifier que votre cluster a terminé la mise à jour en consultant le site Last completed version de votre cluster. Vous trouverez ces informations sur la page Cluster Settings, sous l'onglet Details.

Ressources supplémentaires

6.1.2. Mise à jour EUS-to-EUS à l'aide de la CLI

Conditions préalables

  • Vérifiez que les pools de configuration des machines sont désactivés.
  • Mettre à jour l'OpenShift CLI (oc) à la version cible avant chaque mise à jour.
Important

Il est fortement déconseillé d'ignorer ce prérequis. Si l'OpenShift CLI (oc) n'est pas mis à jour à la version cible avant votre mise à jour, des problèmes inattendus peuvent survenir.

Procédure

  1. En utilisant la perspective de l'administrateur sur la console web, mettez à jour tous les opérateurs OLM (Operator Lifecycle Manager) vers les versions compatibles avec la version mise à jour que vous souhaitez obtenir. Vous trouverez de plus amples informations sur la manière d'effectuer cette action dans la section "Mise à jour des opérateurs installés" ; voir "Ressources supplémentaires".

  2. Vérifiez que tous les pools de configuration de machines affichent un état de UPDATED et qu'aucun pool de configuration de machines n'affiche un état de UPDATING. Pour afficher l'état de tous les pools de configuration de machines, exécutez la commande suivante : 

    $ oc get mcp

    Exemple de sortie

    NAME     CONFIG                                         	UPDATED   UPDATING
master   rendered-master-ecbb9582781c1091e1c9f19d50cf836c       True  	  False
worker   rendered-worker-00a3f0c68ae94e747193156b491553d5       True  	  False

  3. Votre version actuelle est <4.y>, et la version que vous souhaitez mettre à jour est <4.y 2>. Passez au canal eus-<4.y 2> en exécutant la commande suivante : 

    $ oc adm upgrade channel eus-<4.y 2>
    Note

    Si vous recevez un message d'erreur indiquant que eus-<4.y 2> n'est pas l'un des canaux disponibles, cela signifie que Red Hat est toujours en train de déployer les mises à jour de la version EUS. Ce processus de déploiement prend généralement de 45 à 90 jours à partir de la date de l'AG.

  4. Mettez en pause tous les pools de machines de travail, à l'exception du pool maître, en exécutant la commande suivante : 

    $ oc patch mcp/worker --type merge --patch '{"spec":{"paused":true}}'
    Note

    Vous ne pouvez pas mettre en pause le pool principal.

  5. Mettez à jour la version la plus récente en exécutant la commande suivante : 

    $ oc adm upgrade --to-latest

    Exemple de sortie

    Mise à jour vers la dernière version <4.y 1.z>

  6. Vérifiez la version du cluster pour vous assurer que les mises à jour sont complètes en exécutant la commande suivante : 

    $ oc adm upgrade

    Exemple de sortie

    Cluster version is <4.y+1.z>
...

  7. Mettez à jour la version <4.y 2> en exécutant la commande suivante : 

    $ oc adm upgrade --to-latest

  8. Récupérez la version du cluster pour vous assurer que les mises à jour <4.y 2> sont complètes en exécutant la commande suivante : 

    $ oc adm upgrade

    Exemple de sortie

    Cluster version is <4.y+1.z>
...

  9. Pour mettre à jour vos nœuds de travail en <4.y 2>, désactivez tous les pools de configuration de machines précédemment mis en pause en exécutant la commande suivante : 

    $ oc patch mcp/worker --type merge --patch '{"spec":{"paused":false}}'
    Important

    Si les pools ne sont pas désactivés, la grappe n'est pas autorisée à se mettre à jour vers de futures versions mineures, et les tâches de maintenance telles que la rotation des certificats sont inhibées. La grappe risque donc de se dégrader à l'avenir.

  10. Vérifiez que les pools précédemment mis en pause sont mis à jour et que la mise à jour vers la version <4.y 2> est terminée en exécutant la commande suivante : 

    $ oc get mcp

    Exemple de sortie

    NAME 	   CONFIG                                            UPDATED     UPDATING
master   rendered-master-52da4d2760807cb2b96a3402179a9a4c    True  	 False
worker   rendered-worker-4756f60eccae96fb9dcb4c392c69d497    True 	 False

Ressources supplémentaires

6.1.3. Mise à jour EUS-to-EUS pour les produits en couches et les opérateurs installés via Operator Lifecycle Manager

En plus des étapes de mise à jour EUS vers EUS mentionnées pour la console web et le CLI, il existe des étapes supplémentaires à prendre en compte lors de l'exécution des mises à jour EUS vers EUS pour les clusters avec les éléments suivants :

  • Produits stratifiés
  • Opérateurs installés via le gestionnaire du cycle de vie des opérateurs (OLM)

Qu'est-ce qu'un produit en couches ?

Les produits en couches sont des produits composés de plusieurs produits sous-jacents destinés à être utilisés ensemble et qui ne peuvent pas être divisés en abonnements individuels. Pour des exemples de produits en couches de OpenShift Container Platform, voir Offre en couches sur OpenShift.

Lorsque vous effectuez une mise à jour EUS vers EUS pour les clusters de produits en couche et ceux des opérateurs qui ont été installés via OLM, vous devez effectuer les opérations suivantes :

  1. Assurez-vous que tous vos opérateurs précédemment installés par OLM sont mis à jour à leur dernière version dans leur dernier canal. La mise à jour des opérateurs garantit qu'ils disposent d'un chemin de mise à jour valide lorsque les catalogues OperatorHub par défaut passent de la version mineure actuelle à la suivante lors d'une mise à jour du cluster. Pour plus d'informations sur la mise à jour de vos opérateurs, voir "Preparing for an Operator update" dans "Additional resources".
  2. Confirmez la compatibilité de la version du cluster entre la version actuelle et la version prévue de l'opérateur. Vous pouvez vérifier avec quelles versions vos opérateurs OLM sont compatibles en utilisant le vérificateur d'informations de mise à jour des opérateurs de Red Hat OpenShift Container Platform.

À titre d'exemple, voici les étapes pour effectuer une mise à jour EUS-to-EUS de <4.y> vers <4.y 2> pour OpenShift Data Foundation (ODF). Cette opération peut être effectuée via le CLI ou la console web. Pour plus d'informations sur la mise à jour des clusters via l'interface de votre choix, consultez EUS-to-EUS update using the web console et \N "Mise à jour EUS-to-EUS à l'aide de la CLI" dans \N "Ressources supplémentaires".

Exemple de flux de travail

  1. Mettre en pause les pools de machines de travail.
  2. Mettre à jour OpenShift <4.y> → OpenShift <4.y 1>.
  3. Mise à jour ODF <4.y> → ODF <4.y 1>.
  4. Mettre à jour OpenShift <4.y 1> → OpenShift <4.y 2>.
  5. Mise à niveau vers ODF <4.y 2>.
  6. Désactivez les pools de machines de travail.
Note

La mise à niveau vers ODF <4.y 2> peut avoir lieu avant ou après que les pools de machines de travail aient été désactivés.

Ressources supplémentaires

Chapitre 7. Préparation de la mise à jour d'un cluster avec des informations d'identification gérées manuellement

L'état de Cloud Credential Operator (CCO) Upgradable pour un cluster dont les informations d'identification sont gérées manuellement est False par défaut.

  • Pour les versions mineures, par exemple de 4.12 à 4.13, ce statut vous empêche de procéder à la mise à jour tant que vous n'avez pas pris en compte toutes les permissions mises à jour et annoté la ressource CloudCredential pour indiquer que les permissions sont mises à jour en fonction des besoins pour la prochaine version. Cette annotation modifie le statut de Upgradable en True.
  • Pour les versions z-stream, par exemple, de 4.13.0 à 4.13.1, aucune autorisation n'est ajoutée ou modifiée, de sorte que la mise à jour n'est pas bloquée.

Avant de mettre à jour un cluster avec des informations d'identification gérées manuellement, vous devez prendre en compte toutes les informations d'identification nouvelles ou modifiées dans l'image de la version d'OpenShift Container Platform vers laquelle vous effectuez la mise à jour.

7.1. Exigences de mise à jour pour les clusters dont les informations d'identification sont gérées manuellement

Avant de mettre à jour un cluster qui utilise des informations d'identification gérées manuellement avec le Cloud Credential Operator (CCO), vous devez mettre à jour les ressources du fournisseur de cloud pour la nouvelle version.

Si la gestion des informations d'identification dans le nuage pour votre cluster a été configurée à l'aide de l'utilitaire CCO (ccoctl), utilisez l'utilitaire ccoctl pour mettre à jour les ressources. Les clusters qui ont été configurés pour utiliser le mode manuel sans l'utilitaire ccoctl nécessitent des mises à jour manuelles des ressources.

Après avoir mis à jour les ressources du fournisseur de cloud, vous devez mettre à jour l'annotation upgradeable-to pour le cluster afin d'indiquer qu'il est prêt à être mis à jour.

Note

Le processus de mise à jour des ressources du fournisseur de cloud et de l'annotation upgradeable-to ne peut être effectué qu'à l'aide d'outils de ligne de commande.

7.1.1. Options de configuration des informations d'identification dans le nuage et exigences de mise à jour par type de plateforme

Certaines plates-formes ne prennent en charge l'utilisation du CCO que dans un seul mode. Pour les clusters installés sur ces plates-formes, le type de plate-forme détermine les exigences en matière de mise à jour des informations d'identification.

Pour les plates-formes qui prennent en charge l'utilisation de l'OCC dans plusieurs modes, vous devez déterminer le mode que le cluster est configuré pour utiliser et prendre les mesures nécessaires pour cette configuration.

Red Hat OpenStack Platform (RHOSP), Red Hat Virtualization (RHV) et VMware vSphere

Ces plateformes ne permettent pas d'utiliser le CCO en mode manuel. Les clusters sur ces plateformes gèrent automatiquement les changements dans les ressources des fournisseurs de cloud et ne nécessitent pas de mise à jour de l'annotation upgradeable-to.

Les administrateurs de clusters sur ces plates-formes doivent ignorer la section des informations d'identification gérées manuellement dans le processus de mise à jour.

Alibaba Cloud, IBM Cloud et Nutanix

Les clusters installés sur ces plateformes sont configurés à l'aide de l'utilitaire ccoctl.

Les administrateurs de clusters sur ces plateformes doivent prendre les mesures suivantes :

  1. Configurer l'utilitaire ccoctl pour la nouvelle version.
  2. Utilisez l'utilitaire ccoctl pour mettre à jour les ressources du fournisseur de cloud.
  3. Indique que le cluster est prêt à être mis à jour avec l'annotation upgradeable-to.
Microsoft Azure Stack Hub

Ces clusters utilisent le mode manuel avec des informations d'identification à long terme et n'utilisent pas l'utilitaire ccoctl.

Les administrateurs de clusters sur ces plateformes doivent prendre les mesures suivantes :

  1. Mettre à jour manuellement les ressources du fournisseur de cloud pour la nouvelle version.
  2. Indique que le cluster est prêt à être mis à jour avec l'annotation upgradeable-to.
Amazon Web Services (AWS), Microsoft Azure et Google Cloud Platform (GCP)

Les grappes installées sur ces plates-formes prennent en charge plusieurs modes CCO.

Le processus de mise à jour requis dépend du mode pour lequel le cluster est configuré. Si vous n'êtes pas sûr du mode que le CCO est configuré pour utiliser sur votre cluster, vous pouvez utiliser la console web ou le CLI pour déterminer cette information.

Ressources supplémentaires

7.1.2. Détermination du mode Cloud Credential Operator à l'aide de la console web

Vous pouvez déterminer le mode de fonctionnement du Cloud Credential Operator (CCO) à l'aide de la console web.

Note

Seuls les clusters Amazon Web Services (AWS), Microsoft Azure et Google Cloud Platform (GCP) prennent en charge plusieurs modes de CCO.

Conditions préalables

  • Vous avez accès à un compte OpenShift Container Platform avec des permissions d'administrateur de cluster.

Procédure

  1. Connectez-vous à la console web de OpenShift Container Platform en tant qu'utilisateur ayant le rôle cluster-admin.
  2. Naviguez jusqu'à Administration → Cluster Settings.
  3. Sur la page Cluster Settings, sélectionnez l'onglet Configuration.
  4. Sous Configuration resource, sélectionnez CloudCredential.
  5. Sur la page CloudCredential details, sélectionnez l'onglet YAML.

  6. Dans le bloc YAML, vérifiez la valeur de spec.credentialsMode. Les valeurs suivantes sont possibles, bien qu'elles ne soient pas toutes prises en charge sur toutes les plateformes :

    • '': Le CCO fonctionne dans le mode par défaut. Dans cette configuration, le CCO fonctionne en mode "menthe" ou "passthrough", en fonction des informations d'identification fournies lors de l'installation.
    • Mint: Le CCO fonctionne en mode menthe.
    • Passthrough: Le CCO fonctionne en mode "passthrough".
    • Manual: Le CCO fonctionne en mode manuel.
    Important

    Pour déterminer la configuration spécifique d'un cluster AWS ou GCP dont l'adresse spec.credentialsMode est '', Mint, ou Manual, vous devez procéder à des recherches plus approfondies.

    Les clusters AWS et GCP prennent en charge l'utilisation du mode mint avec le secret racine supprimé. Si le cluster est spécifiquement configuré pour utiliser le mode mint ou utilise le mode mint par défaut, vous devez déterminer si le secret racine est présent sur le cluster avant de procéder à la mise à jour.

    Un cluster AWS ou GCP qui utilise le mode manuel peut être configuré pour créer et gérer des informations d'identification cloud depuis l'extérieur du cluster à l'aide du service de jetons de sécurité AWS (STS) ou de l'identité de charge de travail GCP. Vous pouvez déterminer si votre cluster utilise cette stratégie en examinant l'objet cluster Authentication.

  7. Clusters AWS ou GCP qui utilisent uniquement le mode menthe : Pour déterminer si le cluster fonctionne sans le secret racine, accédez à Workloads → Secrets et recherchez le secret racine de votre fournisseur de cloud.

    Note

    Assurez-vous que la liste déroulante Project est réglée sur All Projects.

    Plate-formeNom secret

    AWS

    aws-creds

    PCG

    gcp-credentials

    • Si vous voyez l'une de ces valeurs, votre cluster utilise le mode mint ou passthrough avec le secret root présent.
    • Si vous ne voyez pas ces valeurs, c'est que votre cluster utilise l'OCC en mode menthe avec le secret racine supprimé.

  8. Clusters AWS ou GCP qui utilisent uniquement le mode manuel : Pour déterminer si le cluster est configuré pour créer et gérer des informations d'identification cloud depuis l'extérieur du cluster, vous devez vérifier les valeurs YAML de l'objet cluster Authentication.

    1. Naviguez jusqu'à Administration → Cluster Settings.
    2. Sur la page Cluster Settings, sélectionnez l'onglet Configuration.
    3. Sous Configuration resource, sélectionnez Authentication.
    4. Sur la page Authentication details, sélectionnez l'onglet YAML.

    5. Dans le bloc YAML, vérifiez la valeur du paramètre .spec.serviceAccountIssuer.

      • Une valeur qui contient une URL associée à votre fournisseur de cloud indique que le CCO utilise le mode manuel avec AWS STS ou GCP Workload Identity pour créer et gérer les informations d'identification du cloud depuis l'extérieur du cluster. Ces clusters sont configurés à l'aide de l'utilitaire ccoctl.
      • Une valeur vide ('') indique que le cluster utilise le CCO en mode manuel mais qu'il n'a pas été configuré à l'aide de l'utilitaire ccoctl.

Prochaines étapes

  • Si vous mettez à jour un cluster dont l'OCC fonctionne en mode mint ou passthrough et que le secret racine est présent, vous n'avez pas besoin de mettre à jour les ressources du fournisseur de cloud et vous pouvez passer à la partie suivante du processus de mise à jour.
  • Si votre cluster utilise l'OCC en mode mineur et que le secret racine a été supprimé, vous devez rétablir le secret d'authentification avec l'authentification de niveau administrateur avant de passer à la partie suivante du processus de mise à jour.

  • Si votre cluster a été configuré à l'aide de l'utilitaire CCO (ccoctl), vous devez prendre les mesures suivantes :

    1. Configurez l'utilitaire ccoctl pour la nouvelle version et utilisez-le pour mettre à jour les ressources du fournisseur de cloud.
    2. Mettre à jour l'annotation upgradeable-to pour indiquer que le cluster est prêt à être mis à jour.

  • Si votre cluster utilise le CCO en mode manuel mais n'a pas été configuré à l'aide de l'utilitaire ccoctl, vous devez prendre les mesures suivantes :

    1. Mettre à jour manuellement les ressources du fournisseur de cloud pour la nouvelle version.
    2. Mettre à jour l'annotation upgradeable-to pour indiquer que le cluster est prêt à être mis à jour.

Ressources supplémentaires

7.1.3. Détermination du mode Cloud Credential Operator à l'aide de la CLI

Vous pouvez déterminer le mode de configuration du Cloud Credential Operator (CCO) à l'aide de la CLI.

Note

Seuls les clusters Amazon Web Services (AWS), Microsoft Azure et Google Cloud Platform (GCP) prennent en charge plusieurs modes de CCO.

Conditions préalables

  • Vous avez accès à un compte OpenShift Container Platform avec des permissions d'administrateur de cluster.
  • Vous avez installé l'OpenShift CLI (oc).

Procédure

  1. Connectez-vous à oc sur le cluster en tant qu'utilisateur ayant le rôle cluster-admin.

  2. Pour déterminer le mode dans lequel le CCO est configuré, entrez la commande suivante : 

    $ oc get cloudcredentials cluster \
  -o=jsonpath={.spec.credentialsMode}

    Les valeurs de sortie suivantes sont possibles, bien qu'elles ne soient pas toutes prises en charge sur toutes les plates-formes :

    • '': Le CCO fonctionne dans le mode par défaut. Dans cette configuration, le CCO fonctionne en mode "menthe" ou "passthrough", en fonction des informations d'identification fournies lors de l'installation.
    • Mint: Le CCO fonctionne en mode menthe.
    • Passthrough: Le CCO fonctionne en mode "passthrough".
    • Manual: Le CCO fonctionne en mode manuel.
    Important

    Pour déterminer la configuration spécifique d'un cluster AWS ou GCP dont l'adresse spec.credentialsMode est '', Mint, ou Manual, vous devez procéder à des recherches plus approfondies.

    Les clusters AWS et GCP prennent en charge l'utilisation du mode mint avec le secret racine supprimé. Si le cluster est spécifiquement configuré pour utiliser le mode mint ou utilise le mode mint par défaut, vous devez déterminer si le secret racine est présent sur le cluster avant de procéder à la mise à jour.

    Un cluster AWS ou GCP qui utilise le mode manuel peut être configuré pour créer et gérer des informations d'identification cloud depuis l'extérieur du cluster à l'aide du service de jetons de sécurité AWS (STS) ou de l'identité de charge de travail GCP. Vous pouvez déterminer si votre cluster utilise cette stratégie en examinant l'objet cluster Authentication.

  3. Clusters AWS ou GCP qui utilisent uniquement le mode menthe : Pour déterminer si le cluster fonctionne sans le secret racine, exécutez la commande suivante : 

    $ oc get secret <secret_name> \
  -n=kube-system

    où <secret_name> est aws-creds pour AWS ou gcp-credentials pour GCP.

    Si le secret racine est présent, la sortie de cette commande renvoie des informations sur le secret. Une erreur indique que le secret racine n'est pas présent sur le cluster.

  4. Clusters AWS ou GCP qui utilisent uniquement le mode manuel : Pour déterminer si le cluster est configuré pour créer et gérer des informations d'identification cloud depuis l'extérieur du cluster, exécutez la commande suivante : 

    $ oc get authentication cluster \
  -o jsonpath \
  --template='{ .spec.serviceAccountIssuer }'

    Cette commande affiche la valeur du paramètre .spec.serviceAccountIssuer dans l'objet cluster Authentication.

    • Une sortie d'une URL associée à votre fournisseur de cloud indique que le CCO utilise le mode manuel avec AWS STS ou GCP Workload Identity pour créer et gérer les informations d'identification du cloud depuis l'extérieur du cluster. Ces clusters sont configurés à l'aide de l'utilitaire ccoctl.
    • Une sortie vide indique que le cluster utilise le CCO en mode manuel mais qu'il n'a pas été configuré à l'aide de l'utilitaire ccoctl.

Prochaines étapes

  • Si vous mettez à jour un cluster dont l'OCC fonctionne en mode mint ou passthrough et que le secret racine est présent, vous n'avez pas besoin de mettre à jour les ressources du fournisseur de cloud et vous pouvez passer à la partie suivante du processus de mise à jour.
  • Si votre cluster utilise l'OCC en mode mineur et que le secret racine a été supprimé, vous devez rétablir le secret d'authentification avec l'authentification de niveau administrateur avant de passer à la partie suivante du processus de mise à jour.

  • Si votre cluster a été configuré à l'aide de l'utilitaire CCO (ccoctl), vous devez prendre les mesures suivantes :

    1. Configurez l'utilitaire ccoctl pour la nouvelle version et utilisez-le pour mettre à jour les ressources du fournisseur de cloud.
    2. Mettre à jour l'annotation upgradeable-to pour indiquer que le cluster est prêt à être mis à jour.

  • Si votre cluster utilise le CCO en mode manuel mais n'a pas été configuré à l'aide de l'utilitaire ccoctl, vous devez prendre les mesures suivantes :

    1. Mettre à jour manuellement les ressources du fournisseur de cloud pour la nouvelle version.
    2. Mettre à jour l'annotation upgradeable-to pour indiquer que le cluster est prêt à être mis à jour.

Ressources supplémentaires

7.2. Configuration de l'utilitaire Cloud Credential Operator pour la mise à jour d'un cluster

Pour mettre à niveau un cluster qui utilise le Cloud Credential Operator (CCO) en mode manuel afin de créer et de gérer les informations d'identification du cloud depuis l'extérieur du cluster, extrayez et préparez le binaire de l'utilitaire CCO (ccoctl).

Note

L'utilitaire ccoctl est un binaire Linux qui doit être exécuté dans un environnement Linux.

Conditions préalables

  • Vous avez accès à un compte OpenShift Container Platform avec un accès administrateur de cluster.
  • Vous avez installé l'OpenShift CLI (oc).
  • Votre cluster a été configuré à l'aide de l'utilitaire ccoctl pour créer et gérer des identifiants cloud depuis l'extérieur du cluster.

Procédure

  1. Obtenez l'image de la version d'OpenShift Container Platform en exécutant la commande suivante : 

    $ RELEASE_IMAGE=$(./openshift-install version | awk '/release image/ {print $3}')

  2. Obtenez l'image du conteneur CCO à partir de l'image de la version d'OpenShift Container Platform en exécutant la commande suivante : 

    $ CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator' $RELEASE_IMAGE -a ~/.pull-secret)
    Note

    Veillez à ce que l'architecture de $RELEASE_IMAGE corresponde à l'architecture de l'environnement dans lequel vous utiliserez l'outil ccoctl.

  3. Extrayez le binaire ccoctl de l'image du conteneur CCO dans l'image de la version d'OpenShift Container Platform en exécutant la commande suivante : 

    $ oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ~/.pull-secret

  4. Modifiez les autorisations pour rendre ccoctl exécutable en exécutant la commande suivante : 

    $ chmod 775 ccoctl

Vérification

  • Pour vérifier que ccoctl est prêt à être utilisé, affichez le fichier d'aide en exécutant la commande suivante : 

    $ ccoctl --help

    Sortie de ccoctl --help:

    OpenShift credentials provisioning tool

Usage:
  ccoctl [command]

Available Commands:
  alibabacloud Manage credentials objects for alibaba cloud
  aws          Manage credentials objects for AWS cloud
  gcp          Manage credentials objects for Google cloud
  help         Help about any command
  ibmcloud     Manage credentials objects for IBM Cloud
  nutanix      Manage credentials objects for Nutanix

Flags:
  -h, --help   help for ccoctl

Use "ccoctl [command] --help" for more information about a command.

7.3. Mise à jour des ressources des fournisseurs de nuages à l'aide de l'utilitaire Cloud Credential Operator

Le processus de mise à niveau d'un cluster OpenShift Container Platform configuré à l'aide de l'utilitaire CCO (ccoctl) est similaire à la création des ressources du fournisseur de cloud lors de l'installation.

Note

Par défaut, ccoctl crée les objets dans le répertoire dans lequel les commandes sont exécutées. Pour créer les objets dans un autre répertoire, utilisez l'option --output-dir. Cette procédure utilise <path_to_ccoctl_output_dir> pour faire référence à ce répertoire.

Sur les clusters AWS, certaines commandes ccoctl appellent l'API AWS pour créer ou modifier des ressources AWS. Vous pouvez utiliser l'option --dry-run pour éviter les appels d'API. Cette option permet de créer des fichiers JSON sur le système de fichiers local. Vous pouvez examiner et modifier les fichiers JSON, puis les appliquer à l'aide de l'outil CLI AWS en utilisant les paramètres --cli-input-json.

Conditions préalables

  • Obtenez l'image de la version d'OpenShift Container Platform pour la version que vous mettez à niveau.
  • Extraire et préparer le binaire ccoctl à partir de l'image de sortie.

Procédure

  1. Extract the list of CredentialsRequest custom resources (CRs) from the OpenShift Container Platform release image by running the following command: 

    $ oc adm release extract --credentials-requests \
  --cloud=<provider_type> \
  --to=<path_to_directory_with_list_of_credentials_requests>/credrequests \
  quay.io/<path_to>/ocp-release:<version>

    où :

    • <provider_type> est la valeur de votre fournisseur de cloud. Les valeurs valides sont alibabacloud, aws, gcp, ibmcloud, et nutanix.
    • credrequests est le répertoire dans lequel la liste des objets CredentialsRequest est stockée. Cette commande crée le répertoire s'il n'existe pas.

  2. Pour chaque CR CredentialsRequest dans l'image de version, assurez-vous qu'un espace de noms correspondant au texte du champ spec.secretRef.namespace existe dans le cluster. C'est dans ce champ que sont stockés les secrets générés qui contiennent la configuration des informations d'identification.

    Exemple d'objet AWS CredentialsRequest 

    apiVersion: cloudcredential.openshift.io/v1
kind: CredentialsRequest
metadata:
  name: cloud-credential-operator-iam-ro
  namespace: openshift-cloud-credential-operator
spec:
  providerSpec:
    apiVersion: cloudcredential.openshift.io/v1
    kind: AWSProviderSpec
    statementEntries:
    - effect: Allow
      action:
      - iam:GetUser
      - iam:GetUserPolicy
      - iam:ListAccessKeys
      resource: "*"
  secretRef:
    name: cloud-credential-operator-iam-ro-creds
    namespace: openshift-cloud-credential-operator 1

    1
    Ce champ indique l'espace de noms qui doit exister pour contenir le secret généré.

    Les CR CredentialsRequest pour les autres plateformes ont un format similaire avec des valeurs différentes spécifiques à la plateforme.

  3. Pour tout CredentialsRequest CR pour lequel le cluster ne dispose pas encore d'un espace de noms portant le nom spécifié dans spec.secretRef.namespace, créez l'espace de noms en exécutant la commande suivante : 

    oc create namespace <component_namespace> $ oc create namespace <component_namespace>

  4. Utilisez l'outil ccoctl pour traiter tous les objets CredentialsRequest dans le répertoire credrequests en exécutant la commande correspondant à votre fournisseur de cloud. Les commandes suivantes traitent les objets CredentialsRequest:

    • Alibaba Cloud : ccoctl alibabacloud create-ram-users
    • Amazon Web Services (AWS) : ccoctl aws create-iam-roles
    • Google Cloud Platform (GCP) : ccoctl gcp create-all
    • IBM Cloud : ccoctl ibmcloud create-service-id
    • Nutanix : ccoctl nutanix create-shared-secrets
    Important

    Reportez-vous aux instructions de l'utilitaire ccoctl dans le contenu d'installation de votre fournisseur de cloud pour obtenir d'importants détails spécifiques à la plateforme sur les arguments requis et les considérations spéciales.

    Pour chaque objet CredentialsRequest, ccoctl crée les ressources fournisseur requises et une politique de permissions telle que définie dans chaque objet CredentialsRequest de l'image de la version d'OpenShift Container Platform.

  5. Appliquez les secrets à votre cluster en exécutant la commande suivante : 

    $ ls <path_to_ccoctl_output_dir>/manifests/*-credentials.yaml | xargs -I{} oc apply -f {}

Vérification

Vous pouvez vérifier que les ressources du fournisseur et les règles d'autorisation requises ont été créées en interrogeant le fournisseur de cloud computing. Pour plus d'informations, reportez-vous à la documentation de votre fournisseur de cloud computing sur l'établissement de listes de rôles ou de comptes de service.

Prochaines étapes

  • Mettre à jour l'annotation upgradeable-to pour indiquer que le cluster est prêt à être mis à niveau.

Ressources supplémentaires

7.4. Mise à jour des ressources des fournisseurs de services en nuage à l'aide d'informations d'identification gérées manuellement

Avant de mettre à niveau un cluster dont les informations d'identification sont gérées manuellement, vous devez créer de nouvelles informations d'identification pour l'image de version vers laquelle vous effectuez la mise à niveau. Vous devez également examiner les autorisations requises pour les informations d'identification existantes et prendre en compte les nouvelles exigences en matière d'autorisations dans la nouvelle version pour ces composants.

Procédure

  1. Extraire et examiner la ressource personnalisée CredentialsRequest pour la nouvelle version.

    La section "Création manuelle de IAM" du contenu d'installation de votre fournisseur de cloud explique comment obtenir et utiliser les informations d'identification requises pour votre cloud.

  2. Mettez à jour les informations d'identification gérées manuellement sur votre cluster :

    • Créer de nouveaux secrets pour toutes les ressources personnalisées CredentialsRequest qui sont ajoutées par la nouvelle image.
    • Si les ressources personnalisées CredentialsRequest pour les informations d'identification existantes qui sont stockées dans des secrets ont modifié les exigences en matière d'autorisations, mettez à jour les autorisations comme il se doit.

  3. Si votre cluster utilise les capacités du cluster pour désactiver un ou plusieurs composants optionnels, supprimez les ressources personnalisées CredentialsRequest pour tous les composants désactivés.

    Exemple credrequests contenu du répertoire pour OpenShift Container Platform 4.12 sur AWS

    0000_30_machine-api-operator_00_credentials-request.yaml 1
0000_50_cloud-credential-operator_05-iam-ro-credentialsrequest.yaml 2
0000_50_cluster-image-registry-operator_01-registry-credentials-request.yaml 3
0000_50_cluster-ingress-operator_00-ingress-credentials-request.yaml 4
0000_50_cluster-network-operator_02-cncc-credentials.yaml 5
0000_50_cluster-storage-operator_03_credentials_request_aws.yaml 6

    1
    Le certificat de conducteur de machine API est exigé.
    2
    Le certificat d'opérateur de titres de créance en nuage est requis.
    3
    Le certificat d'opérateur de registre d'images est requis.
    4
    Le CR de l'opérateur d'entrée est requis.
    5
    Le certificat d'opérateur de réseau est requis.
    6
    Le Storage Operator CR est un composant optionnel et peut être désactivé dans votre cluster.

    Exemple credrequests contenu du répertoire pour OpenShift Container Platform 4.12 sur GCP

    0000_26_cloud-controller-manager-operator_16_credentialsrequest-gcp.yaml 1
0000_30_machine-api-operator_00_credentials-request.yaml 2
0000_50_cloud-credential-operator_05-gcp-ro-credentialsrequest.yaml 3
0000_50_cluster-image-registry-operator_01-registry-credentials-request-gcs.yaml 4
0000_50_cluster-ingress-operator_00-ingress-credentials-request.yaml 5
0000_50_cluster-network-operator_02-cncc-credentials.yaml 6
0000_50_cluster-storage-operator_03_credentials_request_gcp.yaml 7

    1
    Le contrôleur de nuages Manager Operator CR est requis.
    2
    Le certificat de conducteur de machine API est exigé.
    3
    Le certificat d'opérateur de titres de créance en nuage est requis.
    4
    Le certificat d'opérateur de registre d'images est requis.
    5
    Le CR de l'opérateur d'entrée est requis.
    6
    Le certificat d'opérateur de réseau est requis.
    7
    Le Storage Operator CR est un composant optionnel et peut être désactivé dans votre cluster.

Prochaines étapes

  • Mettre à jour l'annotation upgradeable-to pour indiquer que le cluster est prêt à être mis à niveau.

Ressources supplémentaires

7.5. Indique que la grappe est prête à être mise à niveau

L'état de Cloud Credential Operator (CCO) Upgradable pour un cluster dont les informations d'identification sont gérées manuellement est False par défaut.

Conditions préalables

  • Pour l'image de version vers laquelle vous effectuez la mise à niveau, vous avez traité toutes les nouvelles informations d'identification manuellement ou à l'aide de l'utilitaire Cloud Credential Operator (ccoctl).
  • Vous avez installé l'OpenShift CLI (oc).

Procédure

  1. Connectez-vous à oc sur le cluster en tant qu'utilisateur ayant le rôle cluster-admin.

  2. Modifiez la ressource CloudCredential pour ajouter une annotation upgradeable-to dans le champ metadata en exécutant la commande suivante : 

    $ oc edit cloudcredential cluster

    Texte à ajouter

    ...
  metadata:
    annotations:
      cloudcredential.openshift.io/upgradeable-to: <version_number>
...

    Où <version_number> est la version vers laquelle vous effectuez la mise à niveau, au format x.y.z. Par exemple, utilisez 4.12.2 pour OpenShift Container Platform 4.12.2.

    Plusieurs minutes peuvent s'écouler après l'ajout de l'annotation avant que l'état de mise à niveau ne change.

Vérification

  1. Dans la perspective Administrator de la console web, naviguez vers Administration → Cluster Settings.

  2. Pour afficher les détails du statut du CCO, cliquez sur cloud-credential dans la liste Cluster Operators.

    • Si le statut Upgradeable de la section Conditions est False, vérifiez que l'annotation upgradeable-to est exempte d'erreurs typographiques.
  3. Lorsque l'état Upgradeable de la section Conditions est True, commencez la mise à niveau d'OpenShift Container Platform.

Chapitre 8. Mise à jour d'un cluster à l'aide de la console web

Vous pouvez mettre à jour, ou mettre à niveau, un cluster OpenShift Container Platform en utilisant la console web. Les étapes suivantes permettent de mettre à jour un cluster au sein d'une version mineure. Vous pouvez utiliser les mêmes instructions pour mettre à jour un cluster entre des versions mineures.

Note

Utilisez la console web ou oc adm upgrade channel <channel> pour modifier le canal de mise à jour. Vous pouvez suivre les étapes de la section Mise à jour d'un cluster à l'aide de l'interface CLI pour terminer la mise à jour après être passé à un canal 4.12.

8.1. Conditions préalables

  • Avoir accès au cluster en tant qu'utilisateur avec des privilèges admin. Voir Utilisation de RBAC pour définir et appliquer des autorisations.
  • Disposez d'une sauvegarde etcd récente au cas où votre mise à jour échouerait et que vous deviez restaurer votre cluster dans un état antérieur.
  • La prise en charge des travailleurs RHEL7 est supprimée dans OpenShift Container Platform 4.12. Vous devez remplacer les travailleurs RHEL7 par des travailleurs RHEL8 ou RHCOS avant de mettre à niveau OpenShift Container Platform 4.12. Red Hat ne prend pas en charge les mises à jour RHEL7 à RHEL8 sur place pour les travailleurs RHEL ; ces hôtes doivent être remplacés par une installation de système d'exploitation propre.
  • S'assurer que tous les opérateurs précédemment installés via Operator Lifecycle Manager (OLM) sont mis à jour à leur dernière version dans leur dernier canal. La mise à jour des opérateurs garantit qu'ils disposent d'un chemin de mise à jour valide lorsque les catalogues OperatorHub par défaut passent de la version mineure actuelle à la suivante lors d'une mise à jour du cluster. Voir Mise à jour des opérateurs installés pour plus d'informations.
  • Assurez-vous que tous les pools de configuration de machines (MCP) sont en cours d'exécution et ne sont pas en pause. Les nœuds associés à un MCP en pause sont ignorés lors du processus de mise à jour. Vous pouvez mettre les MCP en pause si vous exécutez une stratégie de mise à jour par déploiement canarien.
  • Pour tenir compte du temps nécessaire à la mise à jour, vous pouvez effectuer une mise à jour partielle en mettant à jour les nœuds du pool de travail ou du pool personnalisé. Vous pouvez interrompre et reprendre la mise à jour dans la barre de progression de chaque pool.
  • Si votre cluster utilise des informations d'identification gérées manuellement, mettez à jour les ressources du fournisseur de cloud pour la nouvelle version. Pour plus d'informations, notamment sur la manière de déterminer s'il s'agit d'une exigence pour votre cluster, voir Préparation de la mise à jour d'un cluster avec des informations d'identification gérées manuellement.
  • Examinez la liste des API qui ont été supprimées dans Kubernetes 1.25, migrez tous les composants concernés pour utiliser la nouvelle version de l'API et fournissez l'accusé de réception de l'administrateur. Pour plus d'informations, voir Préparation de la mise à jour vers OpenShift Container Platform 4.12.
  • Si vous exécutez un opérateur ou si vous avez configuré une application avec le budget d'interruption des pods, il se peut que vous subissiez une interruption pendant le processus de mise à niveau. Si minAvailable est défini à 1 dans PodDisruptionBudget, les nœuds sont vidés pour appliquer les configurations de machine en attente, ce qui peut bloquer le processus d'éviction. Si plusieurs nœuds sont redémarrés, tous les pods peuvent s'exécuter sur un seul nœud, et le champ PodDisruptionBudget peut empêcher la vidange des nœuds.
Important
  • Lorsqu'une mise à jour n'aboutit pas, l'opérateur de version de cluster (CVO) signale l'état des composants bloquants tout en essayant de réconcilier la mise à jour. Le retour de votre cluster à une version précédente n'est pas pris en charge. Si votre mise à jour n'aboutit pas, contactez l'assistance de Red Hat.
  • L'utilisation de la section unsupportedConfigOverrides pour modifier la configuration d'un opérateur n'est pas prise en charge et peut bloquer les mises à jour de la grappe. Vous devez supprimer ce paramètre avant de pouvoir mettre à jour votre cluster.

Ressources supplémentaires

8.2. Effectuer une mise à jour du déploiement du canari

Dans certains cas d'utilisation spécifiques, vous pouvez souhaiter un processus de mise à jour plus contrôlé où vous ne souhaitez pas que des nœuds spécifiques soient mis à jour en même temps que le reste de la grappe. Ces cas d'utilisation incluent, mais ne sont pas limités à :

  • Vous avez des applications critiques que vous ne voulez pas voir indisponibles pendant la mise à jour. Vous pouvez tester lentement les applications sur vos nœuds par petits lots après la mise à jour.
  • Vous avez une petite fenêtre de maintenance qui ne laisse pas le temps à tous les nœuds d'être mis à jour, ou vous avez plusieurs fenêtres de maintenance.

Le processus de mise à jour en continu est not un flux de travail de mise à jour typique. Dans le cas de clusters plus importants, ce processus peut prendre beaucoup de temps et nécessiter l'exécution de plusieurs commandes. Cette complexité peut entraîner des erreurs susceptibles d'affecter l'ensemble du cluster. Il est recommandé d'examiner attentivement si votre organisation souhaite utiliser une mise à jour glissante et de planifier soigneusement la mise en œuvre du processus avant de commencer.

Le processus de mise à jour en continu décrit dans cette rubrique implique :

  • Création d'un ou plusieurs pools de configuration de machines (MCP) personnalisés.
  • Étiqueter chaque nœud que vous ne voulez pas mettre à jour immédiatement pour déplacer ces nœuds vers les MCP personnalisés.
  • Mise en pause de ces MCP personnalisés, ce qui empêche les mises à jour de ces nœuds.
  • Effectuer la mise à jour du cluster.
  • Désactiver un MCP personnalisé, ce qui déclenche la mise à jour de ces nœuds.
  • Tester les applications sur ces nœuds pour s'assurer qu'elles fonctionnent comme prévu sur ces nœuds nouvellement mis à jour.
  • Éventuellement, retirer les étiquettes personnalisées des nœuds restants par petits lots et tester les applications sur ces nœuds.
Note

La mise en pause d'un MCP empêche l'opérateur de configuration de la machine d'appliquer des modifications de configuration sur les nœuds associés. La mise en pause d'un MCP empêche également la transmission aux nœuds associés de tout certificat ayant fait l'objet d'une rotation automatique, y compris la rotation automatique du certificat de l'autorité de certification kube-apiserver-to-kubelet-signer.

Si le MCP est mis en pause lorsque le certificat de l'autorité de certification kube-apiserver-to-kubelet-signer expire et que le MCO tente de renouveler automatiquement le certificat, le nouveau certificat est créé mais n'est pas appliqué aux nœuds dans le pool de configuration de la machine concernée. Cela entraîne l'échec de plusieurs commandes oc, notamment oc debug, oc logs, oc exec, et oc attach. Vous recevez des alertes dans l'interface utilisateur d'alerte de la console Web d'OpenShift Container Platform si un MCP est mis en pause lors de la rotation des certificats.

La mise en pause d'un MCP doit être effectuée en tenant compte de l'expiration du certificat de l'autorité de certification kube-apiserver-to-kubelet-signer et uniquement pour de courtes périodes.

Si vous souhaitez utiliser le processus de mise à jour par déploiement canarien, voir Exécution d'une mise à jour par déploiement canarien.

8.3. Mise à jour des ressources des fournisseurs de services en nuage à l'aide d'informations d'identification gérées manuellement

Avant de mettre à niveau un cluster dont les informations d'identification sont gérées manuellement, vous devez créer de nouvelles informations d'identification pour l'image de version vers laquelle vous effectuez la mise à niveau. Vous devez également examiner les autorisations requises pour les informations d'identification existantes et prendre en compte les nouvelles exigences en matière d'autorisations dans la nouvelle version pour ces composants.

Procédure

  1. Extraire et examiner la ressource personnalisée CredentialsRequest pour la nouvelle version.

    La section "Création manuelle de IAM" du contenu d'installation de votre fournisseur de cloud explique comment obtenir et utiliser les informations d'identification requises pour votre cloud.

  2. Mettez à jour les informations d'identification gérées manuellement sur votre cluster :

    • Créer de nouveaux secrets pour toutes les ressources personnalisées CredentialsRequest qui sont ajoutées par la nouvelle image.
    • Si les ressources personnalisées CredentialsRequest pour les informations d'identification existantes qui sont stockées dans des secrets ont modifié les exigences en matière d'autorisations, mettez à jour les autorisations comme il se doit.

  3. Si votre cluster utilise les capacités du cluster pour désactiver un ou plusieurs composants optionnels, supprimez les ressources personnalisées CredentialsRequest pour tous les composants désactivés.

    Exemple credrequests contenu du répertoire pour OpenShift Container Platform 4.12 sur AWS

    0000_30_machine-api-operator_00_credentials-request.yaml 1
0000_50_cloud-credential-operator_05-iam-ro-credentialsrequest.yaml 2
0000_50_cluster-image-registry-operator_01-registry-credentials-request.yaml 3
0000_50_cluster-ingress-operator_00-ingress-credentials-request.yaml 4
0000_50_cluster-network-operator_02-cncc-credentials.yaml 5
0000_50_cluster-storage-operator_03_credentials_request_aws.yaml 6

    1
    Le certificat de conducteur de machine API est exigé.
    2
    Le certificat d'opérateur de titres de créance en nuage est requis.
    3
    Le certificat d'opérateur de registre d'images est requis.
    4
    Le CR de l'opérateur d'entrée est requis.
    5
    Le certificat d'opérateur de réseau est requis.
    6
    Le Storage Operator CR est un composant optionnel et peut être désactivé dans votre cluster.

    Exemple credrequests contenu du répertoire pour OpenShift Container Platform 4.12 sur GCP

    0000_26_cloud-controller-manager-operator_16_credentialsrequest-gcp.yaml 1
0000_30_machine-api-operator_00_credentials-request.yaml 2
0000_50_cloud-credential-operator_05-gcp-ro-credentialsrequest.yaml 3
0000_50_cluster-image-registry-operator_01-registry-credentials-request-gcs.yaml 4
0000_50_cluster-ingress-operator_00-ingress-credentials-request.yaml 5
0000_50_cluster-network-operator_02-cncc-credentials.yaml 6
0000_50_cluster-storage-operator_03_credentials_request_gcp.yaml 7

    1
    Le contrôleur de nuages Manager Operator CR est requis.
    2
    Le certificat de conducteur de machine API est exigé.
    3
    Le certificat d'opérateur de titres de créance en nuage est requis.
    4
    Le certificat d'opérateur de registre d'images est requis.
    5
    Le CR de l'opérateur d'entrée est requis.
    6
    Le certificat d'opérateur de réseau est requis.
    7
    Le Storage Operator CR est un composant optionnel et peut être désactivé dans votre cluster.

Prochaines étapes

  • Mettre à jour l'annotation upgradeable-to pour indiquer que le cluster est prêt à être mis à niveau.

Ressources supplémentaires

8.4. Mise en pause d'une ressource MachineHealthCheck à l'aide de la console web

Au cours du processus de mise à niveau, les nœuds de la grappe peuvent devenir temporairement indisponibles. Dans le cas des nœuds de travail, le contrôle de l'état de la machine peut identifier ces nœuds comme étant malsains et les redémarrer. Pour éviter de redémarrer ces nœuds, mettez en pause toutes les ressources MachineHealthCheck avant de mettre à jour le cluster.

Conditions préalables

  • Vous avez accès au cluster avec les privilèges cluster-admin.
  • Vous avez accès à la console web de OpenShift Container Platform.

Procédure

  1. Connectez-vous à la console web de OpenShift Container Platform.
  2. Naviguez jusqu'à Compute → MachineHealthChecks.

  3. Pour mettre en pause les contrôles de santé de la machine, ajoutez l'annotation cluster.x-k8s.io/paused="" à chaque ressource MachineHealthCheck. Par exemple, pour ajouter l'annotation à la ressource machine-api-termination-handler, procédez comme suit :

    1. Cliquez sur le menu Options kebab à côté de machine-api-termination-handler et cliquez sur Edit annotations.
    2. Dans la boîte de dialogue Edit annotations, cliquez sur Add more.
    3. Dans les champs Key et Value, ajoutez respectivement les valeurs cluster.x-k8s.io/paused et "", puis cliquez sur Save.

8.5. A propos de la mise à jour d'un nœud unique OpenShift Container Platform

Vous pouvez mettre à jour ou mettre à niveau un cluster OpenShift Container Platform à nœud unique en utilisant la console ou le CLI.

Il convient toutefois de noter les limites suivantes :

  • La condition préalable de mise en pause des ressources MachineHealthCheck n'est pas requise car il n'y a pas d'autre nœud pour effectuer le contrôle de santé.
  • La restauration d'un cluster OpenShift Container Platform à un seul nœud à l'aide d'une sauvegarde etcd n'est pas officiellement prise en charge. Cependant, c'est une bonne pratique d'effectuer la sauvegarde etcd au cas où votre mise à niveau échouerait. Si votre plan de contrôle est sain, vous pourriez être en mesure de restaurer votre cluster à un état antérieur en utilisant la sauvegarde.

  • La mise à jour d'un cluster OpenShift Container Platform à un seul nœud nécessite un temps d'arrêt et peut inclure un redémarrage automatique. Le temps d'arrêt dépend de la charge utile de la mise à jour, comme décrit dans les scénarios suivants :

    • Si la charge utile de la mise à jour contient une mise à jour du système d'exploitation, qui nécessite un redémarrage, le temps d'arrêt est important et a un impact sur la gestion de la grappe et les charges de travail des utilisateurs.
    • Si la mise à jour contient des changements de configuration de la machine qui ne nécessitent pas de redémarrage, le temps d'arrêt est moindre et l'impact sur la gestion du cluster et les charges de travail des utilisateurs est réduit. Dans ce cas, l'étape de vidange des nœuds est ignorée avec OpenShift Container Platform à nœud unique car il n'y a pas d'autre nœud dans le cluster pour reprogrammer les charges de travail.
    • Si la charge utile de la mise à jour ne contient pas de mise à jour du système d'exploitation ou de modifications de la configuration de la machine, une brève interruption de l'API se produit et se résout rapidement.
Important

Certaines conditions, telles que des bogues dans un paquetage mis à jour, peuvent empêcher le nœud unique de redémarrer après un redémarrage. Dans ce cas, la mise à jour ne revient pas automatiquement en arrière.

Ressources supplémentaires

8.6. Mise à jour d'un cluster à l'aide de la console web

Si des mises à jour sont disponibles, vous pouvez mettre à jour votre cluster à partir de la console web.

Vous pouvez trouver des informations sur les avis et les mises à jour disponibles pour OpenShift Container Platform dans la section errata du portail client.

Conditions préalables

  • Avoir accès à la console web en tant qu'utilisateur avec les privilèges admin.
  • Mettre en pause toutes les ressources MachineHealthCheck.

Procédure

  1. Dans la console web, cliquez sur Administration → Cluster Settings et examinez le contenu de l'onglet Details.

  2. Pour les clusters de production, assurez-vous que Channel est défini sur le canal correct pour la version que vous souhaitez mettre à jour, par exemple stable-4.12.

    Important

    Pour les clusters de production, vous devez vous abonner à un canal stable-*, eus-* ou fast-*.

    Note

    Lorsque vous êtes prêt à passer à la version mineure suivante, choisissez le canal qui correspond à cette version mineure. Plus le canal de mise à jour est déclaré tôt, plus le cluster peut recommander des chemins de mise à jour vers la version cible. Le cluster peut prendre un certain temps pour évaluer toutes les mises à jour possibles et proposer les meilleures recommandations de mise à jour. Les recommandations de mise à jour peuvent changer au fil du temps, car elles sont basées sur les options de mise à jour disponibles à ce moment-là.

    Si vous ne voyez pas de chemin de mise à jour pour votre version mineure cible, continuez à mettre à jour votre cluster avec la dernière version de correctif pour votre version actuelle jusqu'à ce que la version mineure suivante soit disponible dans le chemin.

    • Si le site Update status n'est pas Updates available, vous ne pouvez pas mettre à jour votre cluster.
    • Select channel indique la version du cluster en cours d'exécution ou en cours de mise à jour.

  3. Sélectionnez une version à mettre à jour et cliquez sur Save.

    Le canal d'entrée Update status devient Update to <product-version> in progress, et vous pouvez suivre la progression de la mise à jour de la grappe en observant les barres de progression des opérateurs et des nœuds.

    Note

    Si vous mettez à niveau votre cluster vers la version mineure suivante, comme la version 4.y vers 4.(y 1), il est recommandé de confirmer que vos nœuds sont mis à jour avant de déployer des charges de travail qui dépendent d'une nouvelle fonctionnalité. Tous les pools dont les nœuds de travail n'ont pas encore été mis à jour sont affichés sur la page Cluster Settings.

  4. Une fois que la mise à jour est terminée et que l'opérateur de version de cluster actualise les mises à jour disponibles, vérifiez si d'autres mises à jour sont disponibles dans votre canal actuel.

    • Si des mises à jour sont disponibles, continuez à effectuer des mises à jour dans le canal actuel jusqu'à ce que vous ne puissiez plus effectuer de mises à jour.
    • Si aucune mise à jour n'est disponible, passez du canal Channel au canal stable-*, eus-* ou fast-* pour la prochaine version mineure, et mettez à jour la version que vous souhaitez dans ce canal.

    Il se peut que vous deviez effectuer plusieurs mises à jour intermédiaires jusqu'à ce que vous obteniez la version souhaitée.

8.7. Modifier le serveur de mise à jour à l'aide de la console web

La modification du serveur de mise à jour est facultative. Si vous avez un OpenShift Update Service (OSUS) installé et configuré localement, vous devez définir l'URL du serveur comme upstream pour utiliser le serveur local lors des mises à jour.

Procédure

  1. Naviguez vers Administration → Cluster Settings, cliquez sur version.

  2. Cliquez sur l'onglet YAML et modifiez la valeur du paramètre upstream:

    Exemple de sortie

      ...
  spec:
    clusterID: db93436d-7b05-42cc-b856-43e11ad2d31a
    upstream: '<update-server-url>' 1
  ...

    1
    La variable <update-server-url> indique l'URL du serveur de mise à jour.

    La valeur par défaut de upstream est https://api.openshift.com/api/upgrades_info/v1/graph.

  3. Cliquez sur Save.

Ressources supplémentaires

Chapitre 9. Mise à jour d'un cluster à l'aide du CLI

Vous pouvez mettre à jour, ou mettre à niveau, un cluster OpenShift Container Platform au sein d'une version mineure en utilisant l'OpenShift CLI (oc). Vous pouvez également mettre à jour un cluster entre des versions mineures en suivant les mêmes instructions.

9.1. Conditions préalables

  • Avoir accès au cluster en tant qu'utilisateur avec des privilèges admin. Voir Utilisation de RBAC pour définir et appliquer des autorisations.
  • Disposez d'une sauvegarde etcd récente au cas où votre mise à jour échouerait et que vous deviez restaurer votre cluster dans un état antérieur.
  • La prise en charge des travailleurs RHEL7 est supprimée dans OpenShift Container Platform 4.12. Vous devez remplacer les travailleurs RHEL7 par des travailleurs RHEL8 ou RHCOS avant de mettre à niveau OpenShift Container Platform 4.12. Red Hat ne prend pas en charge les mises à jour RHEL7 à RHEL8 sur place pour les travailleurs RHEL ; ces hôtes doivent être remplacés par une installation de système d'exploitation propre.
  • S'assurer que tous les opérateurs précédemment installés via Operator Lifecycle Manager (OLM) sont mis à jour à leur dernière version dans leur dernier canal. La mise à jour des opérateurs garantit qu'ils disposent d'un chemin de mise à jour valide lorsque les catalogues OperatorHub par défaut passent de la version mineure actuelle à la suivante lors d'une mise à jour du cluster. Voir Mise à jour des opérateurs installés pour plus d'informations.
  • Assurez-vous que tous les pools de configuration de machines (MCP) sont en cours d'exécution et ne sont pas en pause. Les nœuds associés à un MCP en pause sont ignorés lors du processus de mise à jour. Vous pouvez mettre les MCP en pause si vous exécutez une stratégie de mise à jour par déploiement canarien.
  • Si votre cluster utilise des informations d'identification gérées manuellement, mettez à jour les ressources du fournisseur de cloud pour la nouvelle version. Pour plus d'informations, notamment sur la manière de déterminer s'il s'agit d'une exigence pour votre cluster, voir Préparation de la mise à jour d'un cluster avec des informations d'identification gérées manuellement.
  • Veillez à résoudre toutes les conditions de Upgradeable=False afin que le cluster puisse être mis à jour vers la version mineure suivante. Une alerte s'affiche en haut de la page Cluster Settings lorsqu'un ou plusieurs opérateurs de cluster ne peuvent pas être mis à niveau. Vous pouvez toujours passer à la prochaine mise à jour de correctifs disponible pour la version mineure que vous utilisez actuellement.
  • Examinez la liste des API qui ont été supprimées dans Kubernetes 1.25, migrez tous les composants concernés pour utiliser la nouvelle version de l'API et fournissez l'accusé de réception de l'administrateur. Pour plus d'informations, voir Préparation de la mise à jour vers OpenShift Container Platform 4.12.
  • Si vous exécutez un opérateur ou si vous avez configuré une application avec le budget d'interruption des pods, il se peut que vous subissiez une interruption pendant le processus de mise à niveau. Si minAvailable est défini à 1 dans PodDisruptionBudget, les nœuds sont vidés pour appliquer les configurations de machine en attente, ce qui peut bloquer le processus d'éviction. Si plusieurs nœuds sont redémarrés, tous les pods peuvent s'exécuter sur un seul nœud, et le champ PodDisruptionBudget peut empêcher la vidange des nœuds.
Important
  • Lorsqu'une mise à jour n'aboutit pas, l'opérateur de version de cluster (CVO) signale l'état des composants bloquants tout en essayant de réconcilier la mise à jour. Le retour de votre cluster à une version précédente n'est pas pris en charge. Si votre mise à jour n'aboutit pas, contactez l'assistance de Red Hat.
  • L'utilisation de la section unsupportedConfigOverrides pour modifier la configuration d'un opérateur n'est pas prise en charge et peut bloquer les mises à jour de la grappe. Vous devez supprimer ce paramètre avant de pouvoir mettre à jour votre cluster.

Ressources supplémentaires

9.2. Mise en pause d'une ressource MachineHealthCheck

Au cours du processus de mise à niveau, les nœuds de la grappe peuvent devenir temporairement indisponibles. Dans le cas des nœuds de travail, le contrôle de l'état de la machine peut identifier ces nœuds comme étant malsains et les redémarrer. Pour éviter de redémarrer ces nœuds, mettez en pause toutes les ressources MachineHealthCheck avant de mettre à jour le cluster.

Conditions préalables

  • Installez le CLI OpenShift (oc).

Procédure

  1. Pour dresser la liste de toutes les ressources MachineHealthCheck disponibles que vous souhaitez mettre en pause, exécutez la commande suivante : 

    $ oc get machinehealthcheck -n openshift-machine-api

  2. Pour mettre en pause les contrôles de santé de la machine, ajoutez l'annotation cluster.x-k8s.io/paused="" à la ressource MachineHealthCheck. Exécutez la commande suivante : 

    $ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused=""

    La ressource annotée MachineHealthCheck ressemble au fichier YAML suivant : 

    apiVersion: machine.openshift.io/v1beta1
kind: MachineHealthCheck
metadata:
  name: example
  namespace: openshift-machine-api
  annotations:
    cluster.x-k8s.io/paused: ""
spec:
  selector:
    matchLabels:
      role: worker
  unhealthyConditions:
  - type:    "Ready"
    status:  "Unknown"
    timeout: "300s"
  - type:    "Ready"
    status:  "False"
    timeout: "300s"
  maxUnhealthy: "40%"
status:
  currentHealthy: 5
  expectedMachines: 5
    Important

    Reprendre les contrôles de santé des machines après avoir mis à jour le cluster. Pour reprendre le contrôle, supprimez l'annotation de pause de la ressource MachineHealthCheck en exécutant la commande suivante : 

    $ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused-

9.3. A propos de la mise à jour d'un nœud unique OpenShift Container Platform

Vous pouvez mettre à jour ou mettre à niveau un cluster OpenShift Container Platform à nœud unique en utilisant la console ou le CLI.

Il convient toutefois de noter les limites suivantes :

  • La condition préalable de mise en pause des ressources MachineHealthCheck n'est pas requise car il n'y a pas d'autre nœud pour effectuer le contrôle de santé.
  • La restauration d'un cluster OpenShift Container Platform à un seul nœud à l'aide d'une sauvegarde etcd n'est pas officiellement prise en charge. Cependant, c'est une bonne pratique d'effectuer la sauvegarde etcd au cas où votre mise à niveau échouerait. Si votre plan de contrôle est sain, vous pourriez être en mesure de restaurer votre cluster à un état antérieur en utilisant la sauvegarde.

  • La mise à jour d'un cluster OpenShift Container Platform à un seul nœud nécessite un temps d'arrêt et peut inclure un redémarrage automatique. Le temps d'arrêt dépend de la charge utile de la mise à jour, comme décrit dans les scénarios suivants :

    • Si la charge utile de la mise à jour contient une mise à jour du système d'exploitation, qui nécessite un redémarrage, le temps d'arrêt est important et a un impact sur la gestion de la grappe et les charges de travail des utilisateurs.
    • Si la mise à jour contient des changements de configuration de la machine qui ne nécessitent pas de redémarrage, le temps d'arrêt est moindre et l'impact sur la gestion du cluster et les charges de travail des utilisateurs est réduit. Dans ce cas, l'étape de vidange des nœuds est ignorée avec OpenShift Container Platform à nœud unique car il n'y a pas d'autre nœud dans le cluster pour reprogrammer les charges de travail.
    • Si la charge utile de la mise à jour ne contient pas de mise à jour du système d'exploitation ou de modifications de la configuration de la machine, une brève interruption de l'API se produit et se résout rapidement.
Important

Certaines conditions, telles que des bogues dans un paquetage mis à jour, peuvent empêcher le nœud unique de redémarrer après un redémarrage. Dans ce cas, la mise à jour ne revient pas automatiquement en arrière.

Ressources supplémentaires

9.4. Mise à jour d'un cluster à l'aide de la CLI

Si des mises à jour sont disponibles, vous pouvez mettre à jour votre cluster en utilisant l'OpenShift CLI (oc).

Vous pouvez trouver des informations sur les avis et les mises à jour disponibles pour OpenShift Container Platform dans la section errata du portail client.

Conditions préalables

  • Installez le CLI OpenShift (oc) qui correspond à la version de votre version mise à jour.
  • Connectez-vous au cluster en tant qu'utilisateur avec les privilèges cluster-admin.
  • Mettre en pause toutes les ressources MachineHealthCheck.

Procédure

  1. Affichez les mises à jour disponibles et notez le numéro de version de la mise à jour que vous souhaitez appliquer : 

    $ oc adm upgrade

    Exemple de sortie

    Cluster version is 4.9.23

Upstream is unset, so the cluster will use an appropriate default.
Channel: stable-4.9 (available channels: candidate-4.10, candidate-4.9, fast-4.10, fast-4.9, stable-4.10, stable-4.9, eus-4.10)

Recommended updates:

VERSION IMAGE
4.9.24  quay.io/openshift-release-dev/ocp-release@sha256:6a899c54dda6b844bb12a247e324a0f6cde367e880b73ba110c056df6d018032
4.9.25  quay.io/openshift-release-dev/ocp-release@sha256:2eafde815e543b92f70839972f585cc52aa7c37aa72d5f3c8bc886b0fd45707a
4.9.26  quay.io/openshift-release-dev/ocp-release@sha256:3ccd09dd08c303f27a543351f787d09b83979cd31cf0b4c6ff56cd68814ef6c8
4.9.27  quay.io/openshift-release-dev/ocp-release@sha256:1c7db78eec0cf05df2cead44f69c0e4b2c3234d5635c88a41e1b922c3bedae16
4.9.28  quay.io/openshift-release-dev/ocp-release@sha256:4084d94969b186e20189649b5affba7da59f7d1943e4e5bc7ef78b981eafb7a8
4.9.29  quay.io/openshift-release-dev/ocp-release@sha256:b04ca01d116f0134a102a57f86c67e5b1a3b5da1c4a580af91d521b8fa0aa6ec
4.9.31  quay.io/openshift-release-dev/ocp-release@sha256:2a28b8ebb53d67dd80594421c39e36d9896b1e65cb54af81fbb86ea9ac3bf2d7
4.9.32  quay.io/openshift-release-dev/ocp-release@sha256:ecdb6d0df547b857eaf0edb5574ddd64ca6d9aff1fa61fd1ac6fb641203bedfa

    Note

    Pour plus de détails et d'informations sur la manière d'effectuer une mise à niveau du canal EUS-to-EUS, veuillez consulter la page Preparing to perform an EUS-to-EUS upgrade, répertoriée dans la section Ressources supplémentaires.

  2. En fonction des besoins de votre organisation, définissez le canal de mise à niveau approprié. Par exemple, vous pouvez définir votre canal sur stable-4.12, fast-4.12, ou eus-4.12. Pour plus d'informations sur les canaux, consultez le site Understanding update channels and releases dans la section Ressources supplémentaires. 

    $ oc adm upgrade channel <channel>

    Par exemple, pour régler le canal sur stable-4.12: 

    $ oc adm upgrade channel stable-4.12
    Important

    Pour les clusters de production, vous devez vous abonner à un canal stable-*, eus-* ou fast-*.

    Note

    Lorsque vous êtes prêt à passer à la version mineure suivante, choisissez le canal qui correspond à cette version mineure. Plus le canal de mise à jour est déclaré tôt, plus le cluster peut recommander des chemins de mise à jour vers la version cible. Le cluster peut prendre un certain temps pour évaluer toutes les mises à jour possibles et proposer les meilleures recommandations de mise à jour. Les recommandations de mise à jour peuvent changer au fil du temps, car elles sont basées sur les options de mise à jour disponibles à ce moment-là.

    Si vous ne voyez pas de chemin de mise à jour pour votre version mineure cible, continuez à mettre à jour votre cluster avec la dernière version de correctif pour votre version actuelle jusqu'à ce que la version mineure suivante soit disponible dans le chemin.

  3. Appliquer une mise à jour :

    • Pour mettre à jour la dernière version : 

      $ oc adm upgrade --to-latest=true 1

    • Pour mettre à jour une version spécifique : 

      oc adm upgrade --to=<version> 1
      1 1
      <version> est la version de mise à jour que vous avez obtenue à partir de la sortie de la commande oc adm upgrade.

  4. Examinez l'état de l'opérateur de la version du cluster : 

    $ oc adm upgrade

  5. Une fois la mise à jour terminée, vous pouvez confirmer que la version du cluster a été mise à jour : 

    $ oc get clusterversion

    Exemple de sortie

    Cluster version is <version>

Upstream is unset, so the cluster will use an appropriate default.
Channel: stable-4.10 (available channels: candidate-4.10, candidate-4.11, eus-4.10, fast-4.10, fast-4.11, stable-4.10)

No updates available. You may force an upgrade to a specific release image, but doing so might not be supported and might result in downtime or data loss.

    Note

    Si la commande oc get clusterversion affiche l'erreur suivante alors que l'état de PROGRESSING est True, vous pouvez ignorer l'erreur. 

    NAME    VERSION AVAILABLE PROGRESSING SINCE STATUS
version 4.10.26 True      True        24m   Unable to apply 4.11.0-rc.7: an unknown error has occurred: MultipleErrors

  6. Si vous mettez à niveau votre cluster vers la version mineure suivante, telle que la version X.y vers X.(y 1), il est recommandé de confirmer que vos nœuds sont mis à niveau avant de déployer des charges de travail qui dépendent d'une nouvelle fonctionnalité : 

    $ oc get nodes

    Exemple de sortie

    NAME                           STATUS   ROLES    AGE   VERSION
ip-10-0-168-251.ec2.internal   Ready    master   82m   v1.25.0
ip-10-0-170-223.ec2.internal   Ready    master   82m   v1.25.0
ip-10-0-179-95.ec2.internal    Ready    worker   70m   v1.25.0
ip-10-0-182-134.ec2.internal   Ready    worker   70m   v1.25.0
ip-10-0-211-16.ec2.internal    Ready    master   82m   v1.25.0
ip-10-0-250-100.ec2.internal   Ready    worker   69m   v1.25.0

Ressources supplémentaires

9.5. Mise à jour le long d'un chemin de mise à niveau conditionnel

Vous pouvez mettre à jour en suivant un chemin de mise à jour conditionnelle recommandé en utilisant la console web ou l'OpenShift CLI (oc). Lorsqu'une mise à jour conditionnelle n'est pas recommandée pour votre cluster, vous pouvez effectuer une mise à jour conditionnelle à l'aide de l'OpenShift CLI (oc) 4.10 ou ultérieure.

Procédure

  1. Pour afficher la description de la mise à jour lorsqu'elle n'est pas recommandée en raison d'un risque potentiel, exécutez la commande suivante : 

    $ oc adm upgrade --include-not-recommended

  2. Si l'administrateur du cluster évalue les risques potentiels connus et décide qu'ils sont acceptables pour le cluster actuel, il peut alors renoncer aux mesures de sécurité et procéder à la mise à jour en exécutant la commande suivante : 

    $ oc adm upgrade --allow-not-recommended --to <version> <.>

    <.> <version> est la version de mise à jour supportée mais non recommandée que vous avez obtenue à partir de la sortie de la commande précédente.

ifndef::openshift-origin

Ressources supplémentaires

9.6. Modification du serveur de mise à jour à l'aide de l'interface de ligne de commande

La modification du serveur de mise à jour est facultative. Si vous avez un OpenShift Update Service (OSUS) installé et configuré localement, vous devez définir l'URL du serveur comme upstream pour utiliser le serveur local lors des mises à jour. La valeur par défaut de upstream est https://api.openshift.com/api/upgrades_info/v1/graph.

Procédure

  • Modifier la valeur du paramètre upstream dans la version du cluster : 

    $ oc patch clusterversion/version --patch '{"spec":{"upstream":"<update-server-url>"}}' --type=merge

    La variable <update-server-url> indique l'URL du serveur de mise à jour.

    Exemple de sortie

    clusterversion.config.openshift.io/version patched

Chapitre 10. Effectuer une mise à jour du déploiement du canari

Dans certains cas, vous pouvez souhaiter un déploiement plus contrôlé d'une mise à jour vers les nœuds de travail afin de garantir que les applications stratégiques restent disponibles pendant toute la durée de la mise à jour, même si le processus de mise à jour entraîne une défaillance de vos applications. En fonction des besoins de votre organisation, vous pouvez mettre à jour un petit sous-ensemble de nœuds de travail, évaluer la santé du cluster et de la charge de travail pendant un certain temps, puis mettre à jour les nœuds restants. C'est ce que l'on appelle communément une mise à jour canary. Il se peut également que vous souhaitiez intégrer les mises à jour des nœuds de travail, qui nécessitent souvent un redémarrage de l'hôte, dans des fenêtres de maintenance définies plus petites, lorsqu'il n'est pas possible de prendre une grande fenêtre de maintenance pour mettre à jour l'ensemble de la grappe en une seule fois.

Dans ce cas, vous pouvez créer plusieurs pools de configuration de machines (MCP) personnalisés afin d'empêcher la mise à jour de certains nœuds de travail lors de la mise à jour de la grappe. Une fois le reste de la grappe mis à jour, vous pouvez mettre à jour ces nœuds de travail par lots au moment opportun.

Par exemple, si vous avez un cluster de 100 nœuds avec une capacité excédentaire de 10, des fenêtres de maintenance qui ne doivent pas dépasser 4 heures, et que vous savez qu'il ne faut pas plus de 8 minutes pour drainer et redémarrer un nœud de travail, vous pouvez utiliser les MCP pour atteindre vos objectifs. Par exemple, vous pouvez définir quatre MCP, nommés workerpool-canary, workerpool-A, workerpool-B et workerpool-C, avec respectivement 10, 30, 30 et 30 nœuds.

Au cours de votre première fenêtre de maintenance, vous devez mettre en pause le MCP pour workerpool-A, workerpool-B, et workerpool-C, puis lancer la mise à jour du cluster. Cela met à jour les composants qui s'exécutent au-dessus d'OpenShift Container Platform et les 10 nœuds qui sont membres du MCP workerpool-canary, car ce pool n'a pas été mis en pause. Les trois autres MCP ne sont pas mis à jour, car ils étaient en pause. Si, pour une raison quelconque, vous déterminez que la santé de votre cluster ou de votre charge de travail a été affectée négativement par la mise à jour de workerpool-canary, vous devez alors boucler et drainer tous les nœuds de ce pool tout en maintenant une capacité suffisante jusqu'à ce que vous ayez diagnostiqué le problème. Lorsque tout fonctionne comme prévu, vous évaluez la santé du cluster et de la charge de travail avant de décider de remettre en pause, et donc de mettre à jour, workerpool-A, workerpool-B, et workerpool-C successivement au cours de chaque fenêtre de maintenance supplémentaire.

Bien que la gestion des mises à jour des nœuds ouvriers à l'aide de MCP personnalisés offre une certaine souplesse, elle peut s'avérer fastidieuse et nécessiter l'exécution de plusieurs commandes. Cette complexité peut entraîner des erreurs susceptibles d'affecter l'ensemble du cluster. Il est recommandé d'examiner attentivement les besoins de votre organisation et de planifier soigneusement la mise en œuvre du processus avant de commencer.

Note

Il n'est pas recommandé de mettre à jour les MCP vers différentes versions d'OpenShift Container Platform. Par exemple, ne mettez pas à jour un MCP de 4.y.10 à 4.y.11 et un autre à 4.y.12. Ce scénario n'a pas été testé et pourrait entraîner un état indéfini du cluster.

Important

La mise en pause d'un pool de configuration machine empêche l'opérateur de configuration machine d'appliquer des modifications de configuration sur les nœuds associés. La mise en pause d'un MCP empêche également la transmission aux nœuds associés de tout certificat ayant fait l'objet d'une rotation automatique, y compris la rotation automatique du certificat de l'autorité de certification kube-apiserver-to-kubelet-signer.

Si le MCP est en pause lorsque le certificat de l'autorité de certification kube-apiserver-to-kubelet-signer expire et que le MCO tente de renouveler automatiquement le certificat, le MCO ne peut pas pousser les certificats nouvellement renouvelés vers ces nœuds. Cela entraîne l'échec de plusieurs commandes oc, notamment oc debug, oc logs, oc exec, et oc attach. Vous recevez des alertes dans l'interface utilisateur Alerting de la console Web d'OpenShift Container Platform si un MCP est mis en pause lors de la rotation des certificats.

La mise en pause d'un MCP doit être effectuée en tenant compte de l'expiration du certificat de l'autorité de certification kube-apiserver-to-kubelet-signer et uniquement pour de courtes périodes.

10.1. À propos du processus de mise à jour du déploiement du canari et des PCM

Dans OpenShift Container Platform, les nœuds ne sont pas considérés individuellement. Les nœuds sont regroupés en pools de configuration de machines (MCP). Il y a deux MCP dans un cluster OpenShift Container Platform par défaut : un pour les nœuds du plan de contrôle et un pour les nœuds de travail. Une mise à jour d'OpenShift Container Platform affecte tous les MCPs simultanément.

Pendant la mise à jour, l'opérateur de configuration de la machine (MCO) draine et cordonne tous les nœuds d'un MCP jusqu'au nombre de nœuds spécifié sur maxUnavailable (s'il est spécifié), par défaut 1. La vidange et le cordonage d'un nœud déschedule tous les pods sur le nœud et marque le nœud comme inschedulable. Une fois le nœud vidé, le Machine Config Daemon applique une nouvelle configuration de machine, qui peut inclure la mise à jour du système d'exploitation (OS). La mise à jour du système d'exploitation nécessite le redémarrage de l'hôte.

Pour empêcher la mise à jour de nœuds spécifiques et, par conséquent, leur vidange, leur cordon et leur mise à jour, vous pouvez créer des MCP personnalisés. Ensuite, mettez ces MCP en pause pour vous assurer que les nœuds associés à ces MCP ne sont pas mis à jour. Le MCO ne met pas à jour les MCP mis en pause. Vous pouvez créer un ou plusieurs MCP personnalisés, ce qui vous permet de mieux contrôler l'ordre dans lequel vous mettez à jour ces nœuds. Après avoir mis à jour les nœuds du premier MCP, vous pouvez vérifier la compatibilité de l'application, puis mettre à jour progressivement les autres nœuds vers la nouvelle version.

Note

Pour garantir la stabilité du plan de contrôle, la création d'un MCP personnalisé à partir des nœuds du plan de contrôle n'est pas prise en charge. L'opérateur de configuration de la machine (MCO) ignore tout MCP personnalisé créé pour les nœuds du plan de contrôle.

Vous devez bien réfléchir au nombre de MCP que vous créez et au nombre de nœuds dans chaque MCP, en fonction de la topologie de déploiement de votre charge de travail. Par exemple, si vous devez intégrer des mises à jour dans des fenêtres de maintenance spécifiques, vous devez savoir combien de nœuds OpenShift Container Platform peut mettre à jour dans une fenêtre. Ce nombre dépend des caractéristiques uniques de votre cluster et de votre charge de travail.

Vous devez également tenir compte de la capacité supplémentaire dont vous disposez dans votre cluster. Par exemple, si vos applications ne fonctionnent pas comme prévu sur les nœuds mis à jour, vous pouvez boucler et drainer ces nœuds dans le pool, ce qui déplace les pods d'application vers d'autres nœuds. Vous devez tenir compte de la capacité supplémentaire dont vous disposez pour déterminer le nombre de MCP personnalisés dont vous avez besoin et le nombre de nœuds dans chaque MCP. Par exemple, si vous utilisez deux MCP personnalisés et que 50 % de vos nœuds se trouvent dans chaque pool, vous devez déterminer si l'exécution de 50 % de vos nœuds offre une qualité de service (QoS) suffisante pour vos applications.

Vous pouvez utiliser ce processus de mise à jour avec tous les processus de mise à jour documentés d'OpenShift Container Platform. Cependant, le processus ne fonctionne pas avec les machines Red Hat Enterprise Linux (RHEL), qui sont mises à jour à l'aide des playbooks Ansible.

10.2. A propos de l'exécution d'une mise à jour du déploiement canarien

Cette rubrique décrit le déroulement général du processus de mise à jour du déploiement du canari. Les étapes de l'exécution de chaque tâche du processus sont décrites dans les sections suivantes.

  1. Créez des MCP en fonction du pool de travailleurs. Le nombre de nœuds dans chaque MCP dépend de plusieurs facteurs, tels que la durée de la fenêtre de maintenance pour chaque MCP et la capacité de réserve, c'est-à-dire les nœuds de travail supplémentaires, disponibles dans votre cluster.

    Note

    Vous pouvez modifier le paramètre maxUnavailable dans un MCP pour spécifier le pourcentage ou le nombre de machines qui peuvent être mises à jour à un moment donné. La valeur par défaut est 1.

  2. Ajoutez un sélecteur de nœuds aux MCP personnalisés. Pour chaque nœud que vous ne souhaitez pas mettre à jour en même temps que le reste de la grappe, ajoutez une étiquette correspondante aux nœuds. Cette étiquette associe le nœud au MCP.

    Note

    Ne supprimez pas l'étiquette de travailleur par défaut des nœuds. Les nœuds must ont une étiquette de rôle pour fonctionner correctement dans le cluster.

  3. Mettez en pause les MCP que vous ne souhaitez pas mettre à jour dans le cadre du processus de mise à jour.

    Note

    La mise en pause du MCP entraîne également la mise en pause de la rotation automatique des certificats d'autorité de certification sur le site kube-apiserver-to-kubelet-signer. Les nouveaux certificats CA sont générés 292 jours après la date d'installation et les anciens certificats sont supprimés 365 jours après la date d'installation. Consultez la section Comprendre le renouvellement automatique des certificats CA dans Red Hat OpenShift 4 pour savoir combien de temps il vous reste avant la prochaine rotation automatique des certificats CA.

    Assurez-vous que les pools ne sont pas interrompus lorsque la rotation des certificats d'AC a lieu. Si les MCP sont en pause, le MCO ne peut pas envoyer les nouveaux certificats à ces nœuds. Cela entraîne la dégradation du cluster et l'échec de plusieurs commandes oc, notamment oc debug, oc logs, oc exec et oc attach. Vous recevez des alertes dans l'interface utilisateur d'alerte de la console Web d'OpenShift Container Platform si un MCP est mis en pause lors de la rotation des certificats.

  4. Effectuez la mise à jour du cluster. Le processus d'actualisation met à jour les MCP qui ne sont pas en pause, y compris les nœuds du plan de contrôle.
  5. Testez les applications sur les nœuds mis à jour pour vous assurer qu'elles fonctionnent comme prévu.
  6. Désactivez les MCP restants un par un et testez les applications sur ces nœuds jusqu'à ce que tous les nœuds de travail soient mis à jour. L'interruption d'un MCP lance le processus de mise à jour pour les nœuds associés à ce MCP. Vous pouvez vérifier la progression de la mise à jour à partir de la console web en cliquant sur Administration → Cluster settings. Vous pouvez également utiliser la commande CLI oc get machineconfigpools.
  7. Il est possible de supprimer l'étiquette personnalisée des nœuds mis à jour et de supprimer les MCP personnalisés.

10.3. Création de pools de configuration de machines pour effectuer une mise à jour de déploiement canary

La première tâche à effectuer lors de la mise à jour du déploiement de Canary est de créer un ou plusieurs pools de configuration de machines (MCP).

  1. Créer un MCP à partir d'un nœud de travail.

    1. Dressez la liste des nœuds de travail de votre cluster. 

      $ oc get -l 'node-role.kubernetes.io/master!=' -o 'jsonpath={range .items[*]}{.metadata.name}{"\n"}{end}' nodes

      Exemple de sortie

      ci-ln-pwnll6b-f76d1-s8t9n-worker-a-s75z4
ci-ln-pwnll6b-f76d1-s8t9n-worker-b-dglj2
ci-ln-pwnll6b-f76d1-s8t9n-worker-c-lldbm

    2. Pour les nœuds que vous souhaitez retarder, ajoutez une étiquette personnalisée au nœud : 

      $ oc label node <node name> node-role.kubernetes.io/<custom-label>=

      Par exemple : 

      $ oc label node ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz node-role.kubernetes.io/workerpool-canary=

      Exemple de sortie

      node/ci-ln-gtrwm8t-f76d1-spbl7-worker-a-xk76k labeled

    3. Créer le nouveau MCP : 

      apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: workerpool-canary 1
spec:
  machineConfigSelector:
    matchExpressions: 2
      - {
         key: machineconfiguration.openshift.io/role,
         operator: In,
         values: [worker,workerpool-canary]
        }
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/workerpool-canary: "" 3
      1
      Spécifiez un nom pour le MCP.
      2
      Spécifiez le nom worker et le nom personnalisé du MCP.
      3
      Indiquez l'étiquette personnalisée que vous avez ajoutée aux nœuds que vous souhaitez inclure dans ce pool. 
      oc create -f <nom_du_fichier>

      Exemple de sortie

      machineconfigpool.machineconfiguration.openshift.io/workerpool-canary created

    4. Afficher la liste des MCP du cluster et leur état actuel : 

      $ oc get machineconfigpool

      Exemple de sortie

      NAME              CONFIG                                                        UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master            rendered-master-b0bb90c4921860f2a5d8a2f8137c1867              True      False      False      3              3                   3                     0                      97m
workerpool-canary rendered-workerpool-canary-87ba3dec1ad78cb6aecebf7fbb476a36   True      False      False      1              1                   1                     0                      2m42s
worker            rendered-worker-87ba3dec1ad78cb6aecebf7fbb476a36              True      False      False      2              2                   2                     0                      97m

      Le nouveau pool de configuration de machines, workerpool-canary, est créé et le nombre de nœuds auxquels vous avez ajouté l'étiquette personnalisée est indiqué dans le décompte des machines. Le nombre de machines MCP du travailleur est réduit du même nombre. La mise à jour du nombre de machines peut prendre plusieurs minutes. Dans cet exemple, un nœud a été déplacé du MCP worker vers le MCP workerpool-canary.

10.4. Mise en pause des pools de configuration de la machine

Dans ce processus de mise à jour du déploiement canarien, après avoir étiqueté les nœuds que vous ne voulez pas mettre à jour avec le reste de votre cluster OpenShift Container Platform et créé les pools de configuration de machines (MCP), vous mettez en pause ces MCP. La mise en pause d'un MCP empêche l'opérateur de configuration de machine (MCO) de mettre à jour les nœuds associés à ce MCP.

Note

La mise en pause du MCP entraîne également la mise en pause de la rotation automatique des certificats d'autorité de certification sur le site kube-apiserver-to-kubelet-signer. Les nouveaux certificats CA sont générés 292 jours après la date d'installation et les anciens certificats sont supprimés 365 jours après la date d'installation. Consultez la section Comprendre le renouvellement automatique des certificats CA dans Red Hat OpenShift 4 pour savoir combien de temps il vous reste avant la prochaine rotation automatique des certificats CA.

Assurez-vous que les pools ne sont pas interrompus lorsque la rotation des certificats d'AC a lieu. Si les MCP sont en pause, le MCO ne peut pas envoyer les nouveaux certificats à ces nœuds. Cela entraîne la dégradation du cluster et l'échec de plusieurs commandes oc, notamment oc debug, oc logs, oc exec et oc attach. Vous recevez des alertes dans l'interface utilisateur d'alerte de la console Web d'OpenShift Container Platform si un MCP est mis en pause lors de la rotation des certificats.

Pour mettre en pause un MCP :

  1. Patch le MCP que vous voulez mettre en pause : 

    $ oc patch mcp/<mcp_name> --patch '{"spec":{"paused":true}}' --type=merge

    Par exemple : 

    $  oc patch mcp/workerpool-canary --patch '{"spec":{"paused":true}}' --type=merge

    Exemple de sortie

    machineconfigpool.machineconfiguration.openshift.io/workerpool-canary patched

10.5. Mise à jour de la grappe

Lorsque les MCP sont prêts, vous pouvez procéder à la mise à jour de la grappe. Utilisez l'une des méthodes de mise à jour suivantes, en fonction de votre cluster :

Une fois la mise à jour terminée, vous pouvez commencer à débloquer les MCP un par un.

10.6. Désactiver les pools de configuration des machines

Dans ce processus de mise à jour du déploiement canarien, une fois la mise à jour d'OpenShift Container Platform terminée, désactivez vos MCP personnalisés un par un. Unpauser un MCP permet à l'opérateur de configuration de machine (MCO) de mettre à jour les nœuds associés à ce MCP.

Pour annuler la pause d'un MCP :

  1. Patch le MCP que vous voulez débloquer : 

    $ oc patch mcp/<mcp_name> --patch '{"spec":{"paused":false}}' --type=merge

    Par exemple : 

    $  oc patch mcp/workerpool-canary --patch '{"spec":{"paused":false}}' --type=merge

    Exemple de sortie

    machineconfigpool.machineconfiguration.openshift.io/workerpool-canary patched

    Vous pouvez vérifier la progression de la mise à jour en utilisant la commande oc get machineconfigpools.

  2. Testez vos applications sur les nœuds mis à jour pour vous assurer qu'elles fonctionnent comme prévu.
  3. Déconnectez un à un tous les autres MCP en pause et vérifiez que vos applications fonctionnent.

10.6.1. En cas d'échec de la demande

En cas de défaillance, par exemple si vos applications ne fonctionnent pas sur les nœuds mis à jour, vous pouvez boucler et drainer les nœuds du pool, ce qui permet de déplacer les pods d'application vers d'autres nœuds afin de maintenir la qualité de service des applications. Ce premier MCP ne doit pas être plus grand que la capacité excédentaire.

10.7. Déplacement d'un nœud vers le pool de configuration de la machine d'origine

Dans ce processus de mise à jour du déploiement canarien, après avoir désactivé un pool de configuration machine (MCP) personnalisé et vérifié que les applications sur les nœuds associés à ce MCP fonctionnent comme prévu, vous devez replacer le nœud dans son MCP d'origine en supprimant l'étiquette personnalisée que vous avez ajoutée au nœud.

Important

Un nœud doit avoir un rôle pour fonctionner correctement dans le cluster.

Pour déplacer un nœud vers son MCP d'origine :

  1. Retirer l'étiquette personnalisée du nœud. 

    $ oc label node <node_name> node-role.kubernetes.io/<custom-label>-

    Par exemple : 

    $ oc label node ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz node-role.kubernetes.io/workerpool-canary-

    Exemple de sortie

    node/ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz labeled

    Le MCO déplace les nœuds vers le MCP d'origine et réconcilie le nœud avec la configuration du MCP.

  2. Afficher la liste des MCP du cluster et leur état actuel : 

    $oc get mcp
    NAME                CONFIG                                                   UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master              rendered-master-1203f157d053fd987c7cbd91e3fbc0ed         True      False      False      3              3                   3                     0                      61m
workerpool-canary   rendered-mcp-noupdate-5ad4791166c468f3a35cd16e734c9028   True      False      False      0              0                   0                     0                      21m
worker              rendered-worker-5ad4791166c468f3a35cd16e734c9028         True      False      False      3              3                   3                     0                      61m

    Le nœud est retiré du MCP personnalisé et replacé dans le MCP d'origine. La mise à jour du nombre de machines peut prendre plusieurs minutes. Dans cet exemple, un nœud a été déplacé du MCP workerpool-canary supprimé vers le MCP `worker`.

  3. Optionnel : Supprimer le MCP personnalisé : 

    oc delete mcp <mcp_name>

Chapitre 11. Mise à jour d'un cluster comprenant des machines de calcul RHEL

Vous pouvez mettre à jour, ou mettre à niveau, un cluster OpenShift Container Platform. Si votre cluster contient des machines Red Hat Enterprise Linux (RHEL), vous devez effectuer d'autres étapes pour mettre à jour ces machines.

11.1. Conditions préalables

  • Avoir accès au cluster en tant qu'utilisateur avec des privilèges admin. Voir Utilisation de RBAC pour définir et appliquer des autorisations.
  • Disposez d'une sauvegarde etcd récente au cas où votre mise à jour échouerait et que vous deviez restaurer votre cluster dans un état antérieur.
  • La prise en charge des travailleurs RHEL7 est supprimée dans OpenShift Container Platform 4.12. Vous devez remplacer les travailleurs RHEL7 par des travailleurs RHEL8 ou RHCOS avant de mettre à niveau OpenShift Container Platform 4.12. Red Hat ne prend pas en charge les mises à jour RHEL7 à RHEL8 sur place pour les travailleurs RHEL ; ces hôtes doivent être remplacés par une installation de système d'exploitation propre.
  • Si votre cluster utilise des informations d'identification gérées manuellement, mettez à jour les ressources du fournisseur de cloud pour la nouvelle version. Pour plus d'informations, notamment sur la manière de déterminer s'il s'agit d'une exigence pour votre cluster, voir Préparation de la mise à jour d'un cluster avec des informations d'identification gérées manuellement.
  • Si vous exécutez un opérateur ou si vous avez configuré une application avec le budget d'interruption des pods, il se peut que vous subissiez une interruption pendant le processus de mise à niveau. Si minAvailable est défini à 1 dans PodDisruptionBudget, les nœuds sont vidés pour appliquer les configurations de machine en attente, ce qui peut bloquer le processus d'éviction. Si plusieurs nœuds sont redémarrés, tous les pods peuvent s'exécuter sur un seul nœud, et le champ PodDisruptionBudget peut empêcher la vidange des nœuds.

Ressources supplémentaires

11.2. Mise à jour d'un cluster à l'aide de la console web

Si des mises à jour sont disponibles, vous pouvez mettre à jour votre cluster à partir de la console web.

Vous pouvez trouver des informations sur les avis et les mises à jour disponibles pour OpenShift Container Platform dans la section errata du portail client.

Conditions préalables

  • Avoir accès à la console web en tant qu'utilisateur avec les privilèges admin.
  • Mettre en pause toutes les ressources MachineHealthCheck.

Procédure

  1. Dans la console web, cliquez sur Administration → Cluster Settings et examinez le contenu de l'onglet Details.

  2. Pour les clusters de production, assurez-vous que Channel est défini sur le canal correct pour la version que vous souhaitez mettre à jour, par exemple stable-4.12.

    Important

    Pour les clusters de production, vous devez vous abonner à un canal stable-*, eus-* ou fast-*.

    Note

    Lorsque vous êtes prêt à passer à la version mineure suivante, choisissez le canal qui correspond à cette version mineure. Plus le canal de mise à jour est déclaré tôt, plus le cluster peut recommander des chemins de mise à jour vers la version cible. Le cluster peut prendre un certain temps pour évaluer toutes les mises à jour possibles et proposer les meilleures recommandations de mise à jour. Les recommandations de mise à jour peuvent changer au fil du temps, car elles sont basées sur les options de mise à jour disponibles à ce moment-là.

    Si vous ne voyez pas de chemin de mise à jour pour votre version mineure cible, continuez à mettre à jour votre cluster avec la dernière version de correctif pour votre version actuelle jusqu'à ce que la version mineure suivante soit disponible dans le chemin.

    • Si le site Update status n'est pas Updates available, vous ne pouvez pas mettre à jour votre cluster.
    • Select channel indique la version du cluster en cours d'exécution ou en cours de mise à jour.

  3. Sélectionnez une version à mettre à jour et cliquez sur Save.

    Le canal d'entrée Update status devient Update to <product-version> in progress, et vous pouvez suivre la progression de la mise à jour de la grappe en observant les barres de progression des opérateurs et des nœuds.

    Note

    Si vous mettez à niveau votre cluster vers la version mineure suivante, comme la version 4.y vers 4.(y 1), il est recommandé de confirmer que vos nœuds sont mis à jour avant de déployer des charges de travail qui dépendent d'une nouvelle fonctionnalité. Tous les pools dont les nœuds de travail n'ont pas encore été mis à jour sont affichés sur la page Cluster Settings.

  4. Une fois que la mise à jour est terminée et que l'opérateur de version de cluster actualise les mises à jour disponibles, vérifiez si d'autres mises à jour sont disponibles dans votre canal actuel.

    • Si des mises à jour sont disponibles, continuez à effectuer des mises à jour dans le canal actuel jusqu'à ce que vous ne puissiez plus effectuer de mises à jour.
    • Si aucune mise à jour n'est disponible, passez du canal Channel au canal stable-*, eus-* ou fast-* pour la prochaine version mineure, et mettez à jour la version que vous souhaitez dans ce canal.

    Il se peut que vous deviez effectuer plusieurs mises à jour intermédiaires jusqu'à ce que vous obteniez la version souhaitée.

    Note

    Lorsque vous mettez à jour un cluster qui contient des machines de travail Red Hat Enterprise Linux (RHEL), ces machines deviennent temporairement indisponibles pendant le processus de mise à jour. Vous devez exécuter le playbook de mise à niveau sur chaque machine RHEL lorsqu'elle entre dans l'état NotReady pour que la mise à jour du cluster soit terminée.

11.3. Optionnel : Ajout de crochets pour exécuter des tâches Ansible sur des machines RHEL

Vous pouvez utiliser hooks pour exécuter des tâches Ansible sur les machines de calcul RHEL pendant la mise à jour d'OpenShift Container Platform.

11.3.1. À propos des crochets Ansible pour les mises à niveau

Lorsque vous mettez à jour OpenShift Container Platform, vous pouvez exécuter des tâches personnalisées sur vos nœuds Red Hat Enterprise Linux (RHEL) pendant des opérations spécifiques en utilisant hooks. Les crochets vous permettent de fournir des fichiers qui définissent les tâches à exécuter avant ou après des tâches de mise à jour spécifiques. Vous pouvez utiliser les crochets pour valider ou modifier l'infrastructure personnalisée lorsque vous mettez à jour les nœuds de calcul RHEL dans votre cluster OpenShift Container Platform.

Comme l'échec d'un crochet entraîne l'échec de l'opération, vous devez concevoir des crochets idempotents, c'est-à-dire capables de s'exécuter plusieurs fois et de fournir les mêmes résultats.

Les crochets présentent les limitations importantes suivantes : - Les Hooks n'ont pas d'interface définie ou versionnée. Ils peuvent utiliser des variables internes openshift-ansible, mais il est possible que ces variables soient modifiées ou supprimées dans les prochaines versions d'OpenShift Container Platform. - Les hooks n'ont pas de gestion des erreurs, donc une erreur dans un hook interrompt le processus de mise à jour. Si vous obtenez une erreur, vous devez résoudre le problème et recommencer la mise à jour.

11.3.2. Configurer le fichier d'inventaire Ansible pour qu'il utilise des crochets

Vous définissez les crochets à utiliser lorsque vous mettez à jour les machines de calcul Red Hat Enterprise Linux (RHEL), qui sont également connues sous le nom de machines de travail, dans le fichier d'inventaire hosts sous la section all:vars.

Conditions préalables

  • Vous avez accès à la machine que vous avez utilisée pour ajouter le cluster de machines de calcul RHEL. Vous devez avoir accès au fichier d'inventaire Ansible hosts qui définit vos machines RHEL.

Procédure

  1. Après avoir conçu le crochet, créez un fichier YAML qui définit les tâches Ansible pour celui-ci. Ce fichier doit être un ensemble de tâches et ne peut pas être un playbook, comme le montre l'exemple suivant : 

    ---
# Trivial example forcing an operator to acknowledge the start of an upgrade
# file=/home/user/openshift-ansible/hooks/pre_compute.yml

- name: note the start of a compute machine update
  debug:
      msg: "Compute machine upgrade of {{ inventory_hostname }} is about to start"

- name: require the user agree to start an upgrade
  pause:
      prompt: "Press Enter to start the compute machine update"

  2. Modifiez le fichier d'inventaire Ansible hosts pour spécifier les fichiers d'accroche. Les fichiers de crochets sont spécifiés en tant que valeurs de paramètres dans la section [all:vars], comme indiqué :

    Exemple de définitions de crochets dans un fichier d'inventaire

    [all:vars]
openshift_node_pre_upgrade_hook=/home/user/openshift-ansible/hooks/pre_node.yml
openshift_node_post_upgrade_hook=/home/user/openshift-ansible/hooks/post_node.yml

    Pour éviter toute ambiguïté dans les chemins d'accès aux crochets, utilisez des chemins absolus plutôt que des chemins relatifs dans leurs définitions.

11.3.3. Crochets disponibles pour les machines de calcul RHEL

Vous pouvez utiliser les crochets suivants lorsque vous mettez à jour les machines de calcul Red Hat Enterprise Linux (RHEL) dans votre cluster OpenShift Container Platform.

Nom du crochetDescription

openshift_node_pre_cordon_hook

  • Exécute before chaque nœud est entouré d'un cordon.
  • Ce crochet s'exécute contre each node en série.
  • Si une tâche doit être exécutée sur un hôte différent, elle doit utiliser delegate_to ou local_action.

openshift_node_pre_upgrade_hook

  • Le site after permet d'isoler chaque nœud, mais le site before permet de le mettre à jour.
  • Ce crochet s'exécute contre each node en série.
  • Si une tâche doit être exécutée sur un hôte différent, elle doit utiliser delegate_to ou local_action.

openshift_node_pre_uncordon_hook

  • L'exécution de after permet de mettre à jour chaque nœud, mais before n'est pas enregistré.
  • Ce crochet s'exécute contre each node en série.
  • Si une tâche doit être exécutée sur un hôte différent, elle doit utiliser delegate_to ou local_action.

openshift_node_post_upgrade_hook

  • Exécute after chaque nœud non enregistré. Il s'agit de l'action de mise à jour du nœud last.
  • Ce crochet s'exécute contre each node en série.
  • Si une tâche doit être exécutée sur un hôte différent, elle doit utiliser delegate_to ou local_action.

11.4. Mise à jour des machines de calcul RHEL dans votre cluster

Après avoir mis à jour votre cluster, vous devez mettre à jour les machines de calcul Red Hat Enterprise Linux (RHEL) dans votre cluster.

Important

Les versions 8.4 et 8.5 de Red Hat Enterprise Linux (RHEL) sont prises en charge pour les machines de calcul RHEL.

Vous pouvez également mettre à jour vos machines de calcul vers une autre version mineure d'OpenShift Container Platform si vous utilisez RHEL comme système d'exploitation. Vous n'avez pas besoin d'exclure les paquets RPM de RHEL lorsque vous effectuez une mise à jour de version mineure.

Important

Vous ne pouvez pas mettre à niveau les machines de calcul RHEL 7 vers RHEL 8. Vous devez déployer de nouveaux hôtes RHEL 8 et les anciens hôtes RHEL 7 doivent être supprimés.

Conditions préalables

  • Vous avez mis à jour votre cluster.

    Important

    Comme les machines RHEL ont besoin des ressources générées par la grappe pour terminer le processus de mise à jour, vous devez mettre à jour la grappe avant de mettre à jour les machines de travail RHEL qu'elle contient.

  • Vous avez accès à la machine locale que vous avez utilisée pour ajouter les machines de calcul RHEL à votre cluster. Vous devez avoir accès au fichier d'inventaire Ansible hosts qui définit vos machines RHEL et au playbook upgrade.
  • Pour les mises à jour d'une version mineure, le dépôt RPM utilise la même version d'OpenShift Container Platform que celle qui s'exécute sur votre cluster.

Procédure

  1. Arrêtez et désactivez firewalld sur l'hôte : 

    # systemctl disable --now firewalld.service
    Note

    Par défaut, le système d'exploitation de base RHEL avec l'option d'installation "Minimal" active le service firewalld. L'activation du service firewalld sur votre hôte vous empêche d'accéder aux journaux d'OpenShift Container Platform sur le worker. N'activez pas le service firewalld par la suite si vous souhaitez continuer à accéder aux journaux d'OpenShift Container Platform sur le worker.

  2. Activer les référentiels requis pour OpenShift Container Platform 4.12 :

    1. Sur la machine où vous exécutez les playbooks Ansible, mettez à jour les dépôts requis : 

      # subscription-manager repos --disable=rhocp-4.11-for-rhel-8-x86_64-rpms \
                             --disable=ansible-2.9-for-rhel-8-x86_64-rpms \
                             --enable=rhocp-4.12-for-rhel-8-x86_64-rpms
      Important

      À partir d'OpenShift Container Platform 4.11, les playbooks Ansible sont fournis uniquement pour RHEL 8. Si un système RHEL 7 a été utilisé comme hôte pour les playbooks Ansible d'OpenShift Container Platform 4.10, vous devez soit mettre à niveau l'hôte Ansible vers RHEL 8, soit créer un nouvel hôte Ansible sur un système RHEL 8 et copier les inventaires à partir de l'ancien hôte Ansible.

    2. Sur la machine où vous exécutez les playbooks Ansible, mettez à jour le package Ansible : 

      # yum swap ansible ansible-core

    3. Sur la machine où vous exécutez les playbooks Ansible, mettez à jour les paquets requis, y compris openshift-ansible: 

      # yum update openshift-ansible openshift-clients

    4. Sur chaque nœud de calcul RHEL, mettez à jour les référentiels requis : 

      # subscription-manager repos --disable=rhocp-4.11-for-rhel-8-x86_64-rpms \
                             --enable=rhocp-4.12-for-rhel-8-x86_64-rpms

  3. Mettre à jour un poste de travail RHEL :

    1. Examinez votre fichier d'inventaire Ansible à l'adresse /<path>/inventory/hosts et mettez à jour son contenu pour que les machines RHEL 8 soient répertoriées dans la section [workers], comme indiqué dans l'exemple suivant : 

      [all:vars]
ansible_user=root
#ansible_become=True

openshift_kubeconfig_path="~/.kube/config"

[workers]
mycluster-rhel8-0.example.com
mycluster-rhel8-1.example.com
mycluster-rhel8-2.example.com
mycluster-rhel8-3.example.com

    2. Allez dans le répertoire openshift-ansible: 

      $ cd /usr/share/ansible/openshift-ansible

    3. Exécutez le manuel de jeu upgrade: 

      $ ansible-playbook -i /<path>/inventory/hosts playbooks/upgrade.yml 1
      1
      Pour <path>, indiquez le chemin d'accès au fichier d'inventaire Ansible que vous avez créé.
      Note

      Le playbook upgrade ne met à jour que les paquets OpenShift Container Platform. Il ne met pas à jour les paquets du système d'exploitation.

  4. Après avoir mis à jour tous les travailleurs, confirmez que tous les nœuds de votre cluster ont été mis à jour avec la nouvelle version : 

    # oc get node

    Exemple de sortie

    NAME                        STATUS                        ROLES    AGE    VERSION
mycluster-control-plane-0   Ready                         master   145m   v1.25.0
mycluster-control-plane-1   Ready                         master   145m   v1.25.0
mycluster-control-plane-2   Ready                         master   145m   v1.25.0
mycluster-rhel8-0           Ready                         worker   98m    v1.25.0
mycluster-rhel8-1           Ready                         worker   98m    v1.25.0
mycluster-rhel8-2           Ready                         worker   98m    v1.25.0
mycluster-rhel8-3           Ready                         worker   98m    v1.25.0

  5. Facultatif : Mettez à jour les paquets du système d'exploitation qui n'ont pas été mis à jour par le playbook upgrade. Pour mettre à jour les paquets qui ne sont pas sur 4.12, utilisez la commande suivante : 

    # yum update
    Note

    Vous n'avez pas besoin d'exclure les paquets RPM si vous utilisez le même dépôt RPM que celui que vous avez utilisé lors de l'installation de la version 4.12.

Chapitre 12. Mise à jour d'un cluster dans un environnement déconnecté

12.1. A propos des mises à jour de clusters dans un environnement déconnecté

Un environnement déconnecté est un environnement dans lequel les nœuds du cluster ne peuvent pas accéder à l'internet. Pour cette raison, vous devez remplir un registre avec les images d'installation. Si l'hôte de votre registre ne peut pas accéder à la fois à Internet et au cluster, vous pouvez mettre en miroir les images sur un système de fichiers qui est déconnecté de cet environnement, puis amener cet hôte ou ce support amovible à travers la brèche. Si le registre de conteneurs local et le cluster sont connectés à l'hôte du registre miroir, vous pouvez directement pousser les images de version vers le registre local.

Un seul registre d'images de conteneurs suffit pour héberger des images en miroir pour plusieurs clusters dans le réseau déconnecté.

12.1.1. Mise en miroir du référentiel d'images d'OpenShift Container Platform

Pour mettre à jour votre cluster dans un environnement déconnecté, celui-ci doit avoir accès à un registre miroir contenant les images et les ressources nécessaires à la mise à jour ciblée. La page suivante contient des instructions pour la mise en miroir d'images sur un référentiel dans votre cluster déconnecté :

12.1.2. Mise à jour d'un cluster dans un environnement déconnecté

Vous pouvez utiliser l'une des procédures suivantes pour mettre à jour un cluster OpenShift Container Platform déconnecté :

12.1.3. Désinstallation du service de mise à jour OpenShift d'un cluster

Vous pouvez utiliser la procédure suivante pour désinstaller une copie locale d'OpenShift Update Service (OSUS) de votre cluster :

12.2. Mise en miroir du référentiel d'images d'OpenShift Container Platform

Vous devez mettre en miroir les images de conteneur sur un registre miroir avant de pouvoir mettre à jour un cluster dans un environnement déconnecté. Vous pouvez également utiliser cette procédure dans les environnements connectés pour vous assurer que vos clusters n'exécutent que des images de conteneurs approuvées qui ont satisfait aux contrôles organisationnels pour le contenu externe.

Note

Votre registre miroir doit fonctionner en permanence lorsque le cluster est en cours d'exécution.

Les étapes suivantes décrivent le flux de travail de haut niveau pour la mise en miroir d'images dans un registre miroir :

  1. Installer le CLI OpenShift (oc) sur tous les appareils utilisés pour récupérer et pousser les images de version.
  2. Téléchargez le secret d'extraction du registre et ajoutez-le à votre cluster.

  3. Si vous utilisez le plugin oc-mirror OpenShift CLI (oc) :

    1. Installer le plugin oc-mirror sur tous les dispositifs utilisés pour récupérer et envoyer des images de version.
    2. Créez un fichier de configuration du jeu d'images que le plugin utilisera pour déterminer les images de la version à mettre en miroir. Vous pouvez modifier ce fichier de configuration ultérieurement pour changer les images de la version que le plugin met en miroir.
    3. Mettez en miroir vos images de versions ciblées directement dans un registre miroir, ou sur un support amovible, puis dans un registre miroir.
    4. Configure your cluster to use the resources generated by the oc-mirror plugin.
    5. Répétez ces étapes si nécessaire pour mettre à jour le registre du miroir.

  4. Si vous utilisez la commandeoc adm release mirror :

    1. Définissez les variables d'environnement correspondant à votre environnement et aux images de la version que vous souhaitez reproduire.
    2. Mettez en miroir vos images de versions ciblées directement dans un registre miroir, ou sur un support amovible, puis dans un registre miroir.
    3. Répétez ces étapes si nécessaire pour mettre à jour le registre du miroir.

Par rapport à la commande oc adm release mirror, le plugin oc-mirror présente les avantages suivants :

  • Il peut mettre en miroir des contenus autres que des images de conteneurs.
  • Après la première mise en miroir des images, il est plus facile de mettre à jour les images dans le registre.
  • Le plugin oc-mirror fournit un moyen automatisé de mettre en miroir la charge utile de Quay, et construit également la dernière image de données graphiques pour le service de mise à jour OpenShift fonctionnant dans l'environnement déconnecté.

12.2.1. Conditions préalables

  • You must have a container image registry that supports Docker v2-2 in the location that will host the OpenShift Container Platform cluster, such as Red Hat Quay.

    Note

    If you use Red Hat Quay, you must use version 3.6 or later with the oc-mirror plugin. If you have an entitlement to Red Hat Quay, see the documentation on deploying Red Hat Quay for proof-of-concept purposes or by using the Quay Operator. If you need additional assistance selecting and installing a registry, contact your sales representative or Red Hat Support.

    Si vous n'avez pas de solution existante pour un registre d'images de conteneurs, le registre miroir pour Red Hat OpenShift est inclus dans les abonnements à OpenShift Container Platform. Le site mirror registry for Red Hat OpenShift est un registre de conteneurs à petite échelle que vous pouvez utiliser pour mettre en miroir les images de conteneurs OpenShift Container Platform dans des installations et des mises à jour déconnectées.

12.2.2. Preparing your mirror host

Before you perform the mirror procedure, you must prepare the host to retrieve content and push it to the remote location.

12.2.2.1. Installer le CLI OpenShift en téléchargeant le binaire

Vous pouvez installer l'OpenShift CLI (oc) pour interagir avec OpenShift Container Platform à partir d'une interface de ligne de commande. Vous pouvez installer oc sur Linux, Windows ou macOS.

Important

Si vous avez installé une version antérieure de oc, vous ne pouvez pas l'utiliser pour effectuer toutes les commandes dans OpenShift Container Platform 4.12. Téléchargez et installez la nouvelle version de oc. Si vous mettez à niveau un cluster dans un environnement déconnecté, installez la version de oc vers laquelle vous prévoyez de passer.

Installation de la CLI OpenShift sur Linux

Vous pouvez installer le binaire OpenShift CLI (oc) sur Linux en utilisant la procédure suivante.

Procédure

  1. Naviguez jusqu'à la page de téléchargements OpenShift Container Platform sur le portail client Red Hat.
  2. Sélectionnez l'architecture dans la liste déroulante Product Variant.
  3. Sélectionnez la version appropriée dans la liste déroulante Version.
  4. Cliquez sur Download Now à côté de l'entrée OpenShift v4.12 Linux Client et enregistrez le fichier.

  5. Décompressez l'archive : 

    tar xvf <file>

  6. Placez le fichier binaire oc dans un répertoire situé sur votre site PATH.

    Pour vérifier votre PATH, exécutez la commande suivante : 

    $ echo $PATH

Après l'installation de la CLI OpenShift, elle est disponible à l'aide de la commande oc: 

oc <command>
Installation de la CLI OpenShift sur Windows

Vous pouvez installer le binaire OpenShift CLI (oc) sur Windows en utilisant la procédure suivante.

Procédure

  1. Naviguez jusqu'à la page de téléchargements OpenShift Container Platform sur le portail client Red Hat.
  2. Sélectionnez la version appropriée dans la liste déroulante Version.
  3. Cliquez sur Download Now à côté de l'entrée OpenShift v4.12 Windows Client et enregistrez le fichier.
  4. Décompressez l'archive à l'aide d'un programme ZIP.

  5. Déplacez le fichier binaire oc dans un répertoire situé sur votre site PATH.

    Pour vérifier votre PATH, ouvrez l'invite de commande et exécutez la commande suivante : 

    C:\N> path

Après l'installation de la CLI OpenShift, elle est disponible à l'aide de la commande oc: 

C:\N> oc <command>
Installation de la CLI OpenShift sur macOS

Vous pouvez installer le binaire OpenShift CLI (oc) sur macOS en utilisant la procédure suivante.

Procédure

  1. Naviguez jusqu'à la page de téléchargements OpenShift Container Platform sur le portail client Red Hat.
  2. Sélectionnez la version appropriée dans la liste déroulante Version.

  3. Cliquez sur Download Now à côté de l'entrée OpenShift v4.12 macOS Client et enregistrez le fichier.

    Note

    Pour macOS arm64, choisissez l'entrée OpenShift v4.12 macOS arm64 Client.

  4. Décompressez l'archive.

  5. Déplacez le binaire oc dans un répertoire de votre PATH.

    Pour vérifier votre PATH, ouvrez un terminal et exécutez la commande suivante : 

    $ echo $PATH

Après l'installation de la CLI OpenShift, elle est disponible à l'aide de la commande oc: 

oc <command>

Ressources supplémentaires

12.2.2.2. Configuration des informations d'identification permettant la mise en miroir des images

Créez un fichier d'informations d'identification pour le registre des images de conteneurs qui permet la mise en miroir des images de Red Hat vers votre miroir.

Avertissement

Do not use this image registry credentials file as the pull secret when you install a cluster. If you provide this file when you install cluster, all of the machines in the cluster will have write access to your mirror registry.

Avertissement

This process requires that you have write access to a container image registry on the mirror registry and adds the credentials to a registry pull secret.

Conditions préalables

  • Vous avez configuré un registre miroir à utiliser dans votre environnement déconnecté.
  • You identified an image repository location on your mirror registry to mirror images into.
  • You provisioned a mirror registry account that allows images to be uploaded to that image repository.

Procédure

Effectuez les étapes suivantes sur l'hôte d'installation :

  1. Téléchargez votre registry.redhat.io pull secret depuis le gestionnaire de cluster Red Hat OpenShift.

  2. Faites une copie de votre secret d'extraction au format JSON : 

    $ cat ./pull-secret | jq . > <path>/<pull_secret_file_in_json> 1
    1
    Indiquez le chemin d'accès au dossier dans lequel stocker le secret d'extraction et un nom pour le fichier JSON que vous créez.

    Le contenu du fichier ressemble à l'exemple suivant : 

    {
  "auths": {
    "cloud.openshift.com": {
      "auth": "b3BlbnNo...",
      "email": "you@example.com"
    },
    "quay.io": {
      "auth": "b3BlbnNo...",
      "email": "you@example.com"
    },
    "registry.connect.redhat.com": {
      "auth": "NTE3Njg5Nj...",
      "email": "you@example.com"
    },
    "registry.redhat.io": {
      "auth": "NTE3Njg5Nj...",
      "email": "you@example.com"
    }
  }
}
  3. Facultatif : si vous utilisez le plugin oc-mirror, enregistrez le fichier sous ~/.docker/config.json ou $XDG_RUNTIME_DIR/containers/auth.json.

  4. Générer le nom d'utilisateur et le mot de passe ou le jeton encodés en base64 pour votre registre miroir : 

    $ echo -n '<user_name>:<password>' | base64 -w0 1
BGVtbYk3ZHAtqXs=
    1
    Pour <user_name> et <password>, indiquez le nom d'utilisateur et le mot de passe que vous avez configurés pour votre registre.

  5. Modifiez le fichier JSON et ajoutez-y une section décrivant votre registre : 

      "auths": {
    "<mirror_registry>": { 1
      "auth": "<credentials>", 2
      "email": "you@example.com"
    }
  },
    1
    Pour <mirror_registry>, indiquez le nom de domaine du registre, et éventuellement le port, que votre registre miroir utilise pour servir le contenu. Par exemple, registry.example.com ou registry.example.com:8443
    2
    Pour <credentials>, indiquez le nom d'utilisateur et le mot de passe encodés en base64 pour le registre miroir.

    Le fichier ressemble à l'exemple suivant : 

    {
  "auths": {
    "registry.example.com": {
      "auth": "BGVtbYk3ZHAtqXs=",
      "email": "you@example.com"
    },
    "cloud.openshift.com": {
      "auth": "b3BlbnNo...",
      "email": "you@example.com"
    },
    "quay.io": {
      "auth": "b3BlbnNo...",
      "email": "you@example.com"
    },
    "registry.connect.redhat.com": {
      "auth": "NTE3Njg5Nj...",
      "email": "you@example.com"
    },
    "registry.redhat.io": {
      "auth": "NTE3Njg5Nj...",
      "email": "you@example.com"
    }
  }
}

12.2.3. Mise en miroir des ressources à l'aide du plugin oc-mirror

Vous pouvez utiliser le plugin oc-mirror OpenShift CLI (oc) pour mettre en miroir des images vers un registre miroir dans vos environnements totalement ou partiellement déconnectés. Vous devez exécuter oc-mirror à partir d'un système disposant d'une connectivité Internet pour télécharger les images requises à partir des registres officiels de Red Hat.

12.2.3.1. About the oc-mirror plugin

You can use the oc-mirror OpenShift CLI (oc) plugin to mirror all required OpenShift Container Platform content and other images to your mirror registry by using a single tool. It provides the following features:

  • Provides a centralized method to mirror OpenShift Container Platform releases, Operators, helm charts, and other images.
  • Maintains update paths for OpenShift Container Platform and Operators.
  • Uses a declarative image set configuration file to include only the OpenShift Container Platform releases, Operators, and images that your cluster needs.
  • Performs incremental mirroring, which reduces the size of future image sets.
  • Prunes images from the target mirror registry that were excluded from the image set configuration since the previous execution.
  • Optionally generates supporting artifacts for OpenShift Update Service (OSUS) usage.

When using the oc-mirror plugin, you specify which content to mirror in an image set configuration file. In this YAML file, you can fine-tune the configuration to only include the OpenShift Container Platform releases and Operators that your cluster needs. This reduces the amount of data that you need to download and transfer. The oc-mirror plugin can also mirror arbitrary helm charts and additional container images to assist users in seamlessly synchronizing their workloads onto mirror registries.

The first time you run the oc-mirror plugin, it populates your mirror registry with the required content to perform your disconnected cluster installation or update. In order for your disconnected cluster to continue receiving updates, you must keep your mirror registry updated. To update your mirror registry, you run the oc-mirror plugin using the same configuration as the first time you ran it. The oc-mirror plugin references the metadata from the storage backend and only downloads what has been released since the last time you ran the tool. This provides update paths for OpenShift Container Platform and Operators and performs dependency resolution as required.

Important

When using the oc-mirror CLI plugin to populate a mirror registry, any further updates to the mirror registry must be made using the oc-mirror tool.

12.2.3.2. oc-mirror compatibility and support

The oc-mirror plugin supports mirroring OpenShift Container Platform payload images and Operator catalogs for OpenShift Container Platform versions 4.9 and later.

Use the latest available version of the oc-mirror plugin regardless of which versions of OpenShift Container Platform you need to mirror.

12.2.3.3. À propos du registre miroir

You can mirror the images that are required for OpenShift Container Platform installation and subsequent product updates to a container mirror registry that supports Docker v2-2, such as Red Hat Quay. If you do not have access to a large-scale container registry, you can use the mirror registry for Red Hat OpenShift, which is a small-scale container registry included with OpenShift Container Platform subscriptions.

Regardless of your chosen registry, the procedure to mirror content from Red Hat hosted sites on the internet to an isolated image registry is the same. After you mirror the content, you configure each cluster to retrieve this content from your mirror registry.

Important

Le registre d'images OpenShift ne peut pas être utilisé comme registre cible car il ne prend pas en charge la poussée sans balise, ce qui est nécessaire pendant le processus de mise en miroir.

Si vous choisissez un registre de conteneurs qui n'est pas mirror registry for Red Hat OpenShift, il doit être accessible par chaque machine des clusters que vous provisionnez. Si le registre est inaccessible, l'installation, la mise à jour ou les opérations normales telles que la relocalisation de la charge de travail risquent d'échouer. Pour cette raison, vous devez exécuter les registres miroirs de manière hautement disponible, et les registres miroirs doivent au moins correspondre à la disponibilité de production de vos clusters OpenShift Container Platform.

Lorsque vous remplissez votre registre miroir avec des images OpenShift Container Platform, vous pouvez suivre deux scénarios. Si vous avez un hôte qui peut accéder à la fois à Internet et à votre registre miroir, mais pas à vos nœuds de cluster, vous pouvez directement mettre en miroir le contenu à partir de cette machine. Ce processus est appelé connected mirroring. Si vous ne disposez pas d'un tel hôte, vous devez mettre en miroir les images sur un système de fichiers, puis amener cet hôte ou ce support amovible dans votre environnement restreint. Ce processus est appelé disconnected mirroring.

Dans le cas des registres en miroir, pour connaître la source des images extraites, vous devez consulter l'entrée de journal Trying to access dans les journaux CRI-O. Les autres méthodes permettant d'afficher la source d'extraction des images, telles que la commande crictl images sur un nœud, affichent le nom de l'image non miroitée, même si l'image est extraite de l'emplacement miroitant.

Note

Red Hat ne teste pas les registres tiers avec OpenShift Container Platform.

Ressources supplémentaires

12.2.3.4. Installing the oc-mirror OpenShift CLI plugin

To use the oc-mirror OpenShift CLI plugin to mirror registry images, you must install the plugin. If you are mirroring image sets in a fully disconnected environment, ensure that you install the oc-mirror plugin on the host with internet access and the host in the disconnected environment with access to the mirror registry.

Conditions préalables

  • Vous avez installé l'OpenShift CLI (oc).

Procédure

  1. Download the oc-mirror CLI plugin.

    1. Navigate to the Downloads page of the OpenShift Cluster Manager Hybrid Cloud Console.
    2. Under the OpenShift disconnected installation tools section, click Download for OpenShift Client (oc) mirror plugin and save the file.

  2. Extract the archive: 

    $ tar xvzf oc-mirror.tar.gz

  3. If necessary, update the plugin file to be executable: 

    $ chmod +x oc-mirror
    Note

    Do not rename the oc-mirror file.

  4. Install the oc-mirror CLI plugin by placing the file in your PATH, for example, /usr/local/bin: 

    $ sudo mv oc-mirror /usr/local/bin/.

Vérification

  • Run oc mirror help to verify that the plugin was successfully installed: 

    $ oc-mirror help
12.2.3.5. Creating the image set configuration

Before you can use the oc-mirror plugin to mirror image sets, you must create an image set configuration file. This image set configuration file defines which OpenShift Container Platform releases, Operators, and other images to mirror, along with other configuration settings for the oc-mirror plugin.

You must specify a storage backend in the image set configuration file. This storage backend can be a local directory or a registry that supports Docker v2-2. The oc-mirror plugin stores metadata in this storage backend during image set creation.

Important

Do not delete or modify the metadata that is generated by the oc-mirror plugin. You must use the same storage backend every time you run the oc-mirror plugin for the same mirror registry.

Conditions préalables

  • You have created a container image registry credentials file. For instructions, see Configuring credentials that allow images to be mirrored.

Procédure

  1. Use the oc mirror init command to create a template for the image set configuration and save it to a file called imageset-config.yaml: 

    oc mirror init --registry example.com/mirror/oc-mirror-metadata > imageset-config.yaml 1
    1
    Replace example.com/mirror/oc-mirror-metadata with the location of your registry for the storage backend.

  2. Edit the file and adjust the settings as necessary: 

    kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v1alpha2
archiveSize: 4                                                      1
storageConfig:                                                      2
  registry:
    imageURL: example.com/mirror/oc-mirror-metadata                 3
    skipTLS: false
mirror:
  platform:
    channels:
    - name: stable-4.12                                             4
      type: ocp
    graph: true                                                     5
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.12  6
    packages:
    - name: serverless-operator                                     7
      channels:
      - name: stable                                                8
  additionalImages:
  - name: registry.redhat.io/ubi8/ubi:latest                        9
  helm: {}
    1
    Add archiveSize to set the maximum size, in GiB, of each file within the image set.
    2
    Set the back-end location to save the image set metadata to. This location can be a registry or local directory. It is required to specify storageConfig values, unless you are using the Technology Preview OCI feature.
    3
    Set the registry URL for the storage backend.
    4
    Set the channel to retrieve the OpenShift Container Platform images from.
    5
    Add graph: true to build and push the graph-data image to the mirror registry. The graph-data image is required to create OpenShift Update Service (OSUS) applications. The graph: true field also generates the UpdateService CR manifest. The oc command-line interface (CLI) can use the UpdateService CR manifest to create OSUS applications. For more information, see About the OpenShift Update Service.
    6
    Set the Operator catalog to retrieve the OpenShift Container Platform images from.
    7
    Specify only certain Operator packages to include in the image set. Remove this field to retrieve all packages in the catalog.
    8
    Specify only certain channels of the Operator packages to include in the image set. You must always include the default channel for the Operator package even if you do not use the bundles in that channel. You can find the default channel by running the following command: oc mirror list operators --catalog=<catalog_name> --package=<package_name>.
    9
    Specify any additional images to include in image set.

    See Image set configuration parameters for the full list of parameters and Image set configuration examples for various mirroring use cases.

  3. Save the updated file.

    This image set configuration file is required by the oc mirror command when mirroring content.

Ressources supplémentaires

12.2.3.6. Mirroring an image set to a mirror registry

Vous pouvez utiliser le plugin CLI oc-mirror pour mettre en miroir des images vers un registre miroir dans un environnement partiellement déconnecté ou dans un environnement totalement déconnecté.

Les procédures suivantes supposent que le registre du miroir est déjà configuré.

12.2.3.6.1. Mirroring an image set in a partially disconnected environment

In a partially disconnected environment, you can mirror an image set directly to the target mirror registry.

12.2.3.6.1.1. Mirroring from mirror to mirror

You can use the oc-mirror plugin to mirror an image set directly to a target mirror registry that is accessible during image set creation.

You are required to specify a storage backend in the image set configuration file. This storage backend can be a local directory or a Docker v2 registry. The oc-mirror plugin stores metadata in this storage backend during image set creation.

Important

Do not delete or modify the metadata that is generated by the oc-mirror plugin. You must use the same storage backend every time you run the oc-mirror plugin for the same mirror registry.

Conditions préalables

  • You have access to the internet to obtain the necessary container images.
  • Vous avez installé l'OpenShift CLI (oc).
  • You have installed the oc-mirror CLI plugin.
  • You have created the image set configuration file.

Procédure

  • Run the oc mirror command to mirror the images from the specified image set configuration to a specified registry: 

    $ oc mirror --config=./imageset-config.yaml \1
  docker://registry.example:5000             2
    1
    Pass in the image set configuration file that was created. This procedure assumes that it is named imageset-config.yaml.
    2
    Specify the registry to mirror the image set file to. The registry must start with docker://. If you specify a top-level namespace for the mirror registry, you must also use this same namespace on subsequent executions.

Vérification

  1. Navigate into the oc-mirror-workspace/ directory that was generated.
  2. Navigate into the results directory, for example, results-1639608409/.
  3. Verify that YAML files are present for the ImageContentSourcePolicy and CatalogSource resources.

Prochaines étapes

  • Configure your cluster to use the resources generated by oc-mirror.
12.2.3.6.2. Mirroring an image set in a fully disconnected environment

Pour mettre en miroir un jeu d'images dans un environnement totalement déconnecté, vous devez d'abord mettre en miroir le jeu d'images sur le disque, puis mettre en miroir le fichier du jeu d'images sur le disque vers un miroir.

12.2.3.6.2.1. Mirroring from mirror to disk

You can use the oc-mirror plugin to generate an image set and save the contents to disk. The generated image set can then be transferred to the disconnected environment and mirrored to the target registry.

Important

Depending on the configuration specified in the image set configuration file, using oc-mirror to mirror images might download several hundreds of gigabytes of data to disk.

The initial image set download when you populate the mirror registry is often the largest. Because you only download the images that changed since the last time you ran the command, when you run the oc-mirror plugin again, the generated image set is often smaller.

You are required to specify a storage backend in the image set configuration file. This storage backend can be a local directory or a docker v2 registry. The oc-mirror plugin stores metadata in this storage backend during image set creation.

Important

Do not delete or modify the metadata that is generated by the oc-mirror plugin. You must use the same storage backend every time you run the oc-mirror plugin for the same mirror registry.

Conditions préalables

  • You have access to the internet to obtain the necessary container images.
  • Vous avez installé l'OpenShift CLI (oc).
  • You have installed the oc-mirror CLI plugin.
  • You have created the image set configuration file.

Procédure

  • Run the oc mirror command to mirror the images from the specified image set configuration to disk: 

    $ oc mirror --config=./imageset-config.yaml \1
  file://<path_to_output_directory>          2
    1
    Pass in the image set configuration file that was created. This procedure assumes that it is named imageset-config.yaml.
    2
    Specify the target directory where you want to output the image set file. The target directory path must start with file://.

Vérification

  1. Navigate to your output directory: 

    $ cd <path_to_output_directory>

  2. Verify that an image set .tar file was created: 

    $ ls

    Exemple de sortie

    mirror_seq1_000000.tar

Prochaines étapes

  • Transfer the image set .tar file to the disconnected environment.
12.2.3.6.2.2. Mirroring from disk to mirror

You can use the oc-mirror plugin to mirror the contents of a generated image set to the target mirror registry.

Conditions préalables

  • You have installed the OpenShift CLI (oc) in the disconnected environment.
  • You have installed the oc-mirror CLI plugin in the disconnected environment.
  • You have generated the image set file by using the oc mirror command.
  • You have transferred the image set file to the disconnected environment.

Procédure

  • Run the oc mirror command to process the image set file on disk and mirror the contents to a target mirror registry: 

    $ oc mirror --from=./mirror_seq1_000000.tar \1
  docker://registry.example:5000             2
    1
    Pass in the image set .tar file to mirror, named mirror_seq1_000000.tar in this example. If an archiveSize value was specified in the image set configuration file, the image set might be broken up into multiple .tar files. In this situation, you can pass in a directory that contains the image set .tar files.
    2
    Specify the registry to mirror the image set file to. The registry must start with docker://. If you specify a top-level namespace for the mirror registry, you must also use this same namespace on subsequent executions.

    This command updates the mirror registry with the image set and generates the ImageContentSourcePolicy and CatalogSource resources.

Vérification

  1. Navigate into the oc-mirror-workspace/ directory that was generated.
  2. Navigate into the results directory, for example, results-1639608409/.
  3. Verify that YAML files are present for the ImageContentSourcePolicy and CatalogSource resources.

Prochaines étapes

  • Configure your cluster to use the resources generated by oc-mirror.
12.2.3.7. Configuring your cluster to use the resources generated by oc-mirror

After you have mirrored your image set to the mirror registry, you must apply the generated ImageContentSourcePolicy, CatalogSource, and release image signature resources into the cluster.

The ImageContentSourcePolicy resource associates the mirror registry with the source registry and redirects image pull requests from the online registries to the mirror registry. The CatalogSource resource is used by Operator Lifecycle Manager (OLM) to retrieve information about the available Operators in the mirror registry. The release image signatures are used to verify the mirrored release images.

Conditions préalables

  • You have mirrored the image set to the registry mirror in the disconnected environment.
  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

  1. Log in to the OpenShift CLI as a user with the cluster-admin role.

  2. Apply the YAML files from the results directory to the cluster by running the following command: 

    $ oc apply -f ./oc-mirror-workspace/results-1639608409/

  3. Apply the release image signatures to the cluster by running the following command: 

    $ oc apply -f ./oc-mirror-workspace/results-1639608409/release-signatures/

Vérification

  1. Verify that the ImageContentSourcePolicy resources were successfully installed by running the following command: 

    $ oc get imagecontentsourcepolicy --all-namespaces

  2. Verify that the CatalogSource resources were successfully installed by running the following command: 

    $ oc get catalogsource --all-namespaces
12.2.3.8. Keeping your mirror registry content updated

Après avoir rempli le registre du miroir cible avec le jeu d'images initial, vous devez le mettre à jour régulièrement pour qu'il contienne le contenu le plus récent. Si possible, vous pouvez configurer une tâche cron pour mettre à jour le registre miroir régulièrement.

Mettez à jour votre configuration d'ensemble d'images pour ajouter ou supprimer les versions d'OpenShift Container Platform et d'Operator si nécessaire. Les images supprimées sont élaguées du registre des miroirs.

12.2.3.8.1. About updating your mirror registry content

When you run the oc-mirror plugin again, it generates an image set that only contains new and updated images since the previous execution. Because it only pulls in the differences since the previous image set was created, the generated image set is often smaller and faster to process than the initial image set.

Important

Generated image sets are sequential and must be pushed to the target mirror registry in order. You can derive the sequence number from the file name of the generated image set archive file.

Adding new and updated images

Depending on the settings in your image set configuration, future executions of oc-mirror can mirror additional new and updated images. Review the settings in your image set configuration to ensure that you are retrieving new versions as necessary. For example, you can set the minimum and maximum versions of Operators to mirror if you want to restrict to specific versions. Alternatively, you can set the minimum version as a starting point to mirror, but keep the version range open so you keep receiving new Operator versions on future executions of oc-mirror. Omitting any minimum or maximum version gives you the full version history of an Operator in a channel. Omitting explicitly named channels gives you all releases in all channels of the specified Operator. Omitting any named Operator gives you the entire catalog of all Operators and all their versions ever released.

All these constraints and conditions are evaluated against the publicly released content by Red Hat on every invocation of oc-mirror. This way, it automatically picks up new releases and entirely new Operators. Constraints can be specified by only listing a desired set of Operators, which will not automatically add other newly released Operators into the mirror set. You can also specify a particular release channel, which limits mirroring to just this channel and not any new channels that have been added. This is important for Operator products, such as Red Hat Quay, that use different release channels for their minor releases. Lastly, you can specify a maximum version of a particular Operator, which causes the tool to only mirror the specified version range so that you do not automatically get any newer releases past the maximum version mirrored. In all these cases, you must update the image set configuration file to broaden the scope of the mirroring of Operators to get other Operators, new channels, and newer versions of Operators to be available in your target registry.

It is recommended to align constraints like channel specification or version ranges with the release strategy that a particular Operator has chosen. For example, when the Operator uses a stable channel, you should restrict mirroring to that channel and potentially a minimum version to find the right balance between download volume and getting stable updates regularly. If the Operator chooses a release version channel scheme, for example stable-3.7, you should mirror all releases in that channel. This allows you to keep receiving patch versions of the Operator, for example 3.7.1. You can also regularly adjust the image set configuration to add channels for new product releases, for example stable-3.8.

Pruning images

Images are pruned automatically from the target mirror registry if they are no longer included in the latest image set that was generated and mirrored. This allows you to easily manage and clean up unneeded content and reclaim storage resources.

If there are OpenShift Container Platform releases or Operator versions that you no longer need, you can modify your image set configuration to exclude them, and they will be pruned from the mirror registry upon mirroring. This can be done by adjusting a minimum or maximum version range setting per Operator in the image set configuration file or by deleting the Operator from the list of Operators to mirror from the catalog. You can also remove entire Operator catalogs or entire OpenShift Container Platform releases from the configuration file.

Important

If there are no new or updated images to mirror, the excluded images are not pruned from the target mirror registry. Additionally, if an Operator publisher removes an Operator version from a channel, the removed versions are pruned from the target mirror registry.

To disable automatic pruning of images from the target mirror registry, pass the --skip-pruning flag to the oc mirror command.

12.2.3.8.2. Updating your mirror registry content

After you publish the initial image set to the mirror registry, you can use the oc-mirror plugin to keep your disconnected clusters updated.

Depending on your image set configuration, oc-mirror automatically detects newer releases of OpenShift Container Platform and your selected Operators that have been released after you completed the inital mirror. It is recommended to run oc-mirror at regular intervals, for example in a nightly cron job, to receive product and security updates on a timely basis.

Conditions préalables

  • You have used the oc-mirror plugin to mirror the initial image set to your mirror registry.

  • You have access to the storage backend that was used for the initial execution of the oc-mirror plugin.

    Note

    You must use the same storage backend as the initial execution of oc-mirror for the same mirror registry. Do not delete or modify the metadata image that is generated by the oc-mirror plugin.

Procédure

  1. If necessary, update your image set configuration file to pick up new OpenShift Container Platform and Operator versions. See Image set configuration examples for example mirroring use cases.

  2. Follow the same steps that you used to mirror your initial image set to the mirror registry. For instructions, see Mirroring an image set in a partially disconnected environment or Mirroring an image set in a fully disconnected environment.

    Important
    • You must provide the same storage backend so that only a differential image set is created and mirrored.
    • If you specified a top-level namespace for the mirror registry during the initial image set creation, then you must use this same namespace every time you run the oc-mirror plugin for the same mirror registry.
  3. Configure your cluster to use the resources generated by oc-mirror.

Ressources supplémentaires

12.2.3.9. Performing a dry run

You can use oc-mirror to perform a dry run, without actually mirroring any images. This allows you to review the list of images that would be mirrored, as well as any images that would be pruned from the mirror registry. It also allows you to catch any errors with your image set configuration early or use the generated list of images with other tools to carry out the mirroring operation.

Conditions préalables

  • You have access to the internet to obtain the necessary container images.
  • Vous avez installé l'OpenShift CLI (oc).
  • You have installed the oc-mirror CLI plugin.
  • You have created the image set configuration file.

Procédure

  1. Run the oc mirror command with the --dry-run flag to perform a dry run: 

    $ oc mirror --config=./imageset-config.yaml \1
  docker://registry.example:5000            \2
  --dry-run                                  3
    1
    Pass in the image set configuration file that was created. This procedure assumes that it is named imageset-config.yaml.
    2
    Specify the mirror registry. Nothing is mirrored to this registry as long as you use the --dry-run flag.
    3
    Use the --dry-run flag to generate the dry run artifacts and not an actual image set file.

    Exemple de sortie

    Checking push permissions for registry.example:5000
Creating directory: oc-mirror-workspace/src/publish
Creating directory: oc-mirror-workspace/src/v2
Creating directory: oc-mirror-workspace/src/charts
Creating directory: oc-mirror-workspace/src/release-signatures
No metadata detected, creating new workspace
wrote mirroring manifests to oc-mirror-workspace/operators.1658342351/manifests-redhat-operator-index

...

info: Planning completed in 31.48s
info: Dry run complete
Writing image mapping to oc-mirror-workspace/mapping.txt

  2. Navigate into the workspace directory that was generated: 

    $ cd oc-mirror-workspace/

  3. Review the mapping.txt file that was generated.

    This file contains a list of all images that would be mirrored.

  4. Review the pruning-plan.json file that was generated.

    This file contains a list of all images that would be pruned from the mirror registry when the image set is published.

    Note

    The pruning-plan.json file is only generated if your oc-mirror command points to your mirror registry and there are images to be pruned.

12.2.3.10. Mirroring file-based catalog Operator images in OCI format

You can use the oc-mirror plugin to mirror Operators in the Open Container Initiative (OCI) image format, instead of Docker v2 format. You can copy Operator images to a file-based catalog on disk in OCI format. Then you can copy local OCI images to your target mirror registry.

Important

Using the oc-mirror plugin to mirror Operator images in OCI format is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

Conditions préalables

  • You have access to the internet to obtain the necessary container images.
  • Vous avez installé l'OpenShift CLI (oc).
  • You have installed the oc-mirror CLI plugin.

Procédure

  1. Optional: Retrieve the catalogs and images that you require and save them to disk. If you already have the catalog image in OCI format on disk, you can skip this step.

    1. Create the image set configuration file:

      Example image set configuration file for copying to disk

      kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v1alpha2
mirror:
 operators:
 - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.12
   packages:
   - name: aws-load-balancer-operator

      Note

      When using the OCI feature, only the mirror.operators.catalog setting is available for use.

      The storageConfig setting is ignored in favor of the location passed in to the oc mirror command.

    2. Run the oc mirror command to mirror the images from the specified image set configuration to disk: 

      $ oc mirror --config=./imageset-config.yaml \ 1
  --use-oci-feature \                         2
  --oci-feature-action=copy \                 3
  oci://my-oci-catalog                        4
      1
      Pass in the image set configuration file. This procedure assumes that it is named imageset-config.yaml.
      2
      Use the --use-oci-feature flag to enable the OCI feature.
      3
      To copy the catalog to disk, set the --oci-feature-action flag to copy.
      4
      Specify a directory on disk where you want to output the catalog. This procedure assumes that it is named my-oci-catalog. The path must start with oci://. If the specified directory is not a full path, the directory is created in the current working directory where the oc mirror command is run.
      Note

      You can optionally use the --oci-registries-config flag to specify the path to a TOML-formatted registries.conf file. You can use this to mirror from a different registry, such as a pre-production location for testing, without having to change the image set configuration file.

      Example registries.conf file

      [[registry]]
 location = "registry.redhat.io:5000"
 insecure = false
 blocked = false
 mirror-by-digest-only = true
 prefix = ""
 [[registry.mirror]]
    location = "preprod-registry.example.com"
    insecure = false

      Set the location field in the registry.mirror section to an alternative registry location that you want to pull images from. The location field in the registry section must be the same registry location as the one you specify in the image set configuration file.

    3. List your directory contents and verify that the following directories were created: 

      $ ls -l

      Exemple de sortie

      my-oci-catalog      1
oc-mirror-workspace 2
olm_artifacts       3

      1
      Directory that contains the OCI catalog. This procedure assumes that it is named my-oci-catalog.
      2
      Directory that contains each image in the catalog in its original format.
      3
      Directory that contains the files that describe the Operator bundles that this catalog references.

  2. Update the image set configuration file to specify the location of the catalog on disk to mirror to the target mirror registry:

    Example image set configuration file for mirroring to mirror registry

    kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v1alpha2
mirror:
 operators:
 - catalog: oci:///home/user/oc-mirror/my-oci-catalog/redhat-operator-index 1
   packages:
   - name: aws-load-balancer-operator

    1
    Specify the absolute path to the location of the OCI catalog on disk. This procedure assumes that you used my-oci-catalog as the directory and mirrored the redhat-operator-index catalog. The path must start with oci://.

  3. Run the oc mirror command to process the image set file on disk and mirror the contents to a target mirror registry: 

    $ oc mirror --config=./imageset-config.yaml \ 1
  --use-oci-feature \                         2
  --oci-feature-action=mirror \               3
  docker://registry.example:5000              4
    1
    Pass in the updated image set configuration file. This procedure assumes that it is named imageset-config.yaml.
    2
    Use the --use-oci-feature flag to enable the OCI feature.
    3
    To mirror the catalog to the target mirror registry, set the --oci-feature-action flag to mirror.
    4
    Specify the registry to mirror the image set file to. The registry must start with docker://. If you specify a top-level namespace for the mirror registry, you must also use this same namespace on subsequent executions.
    Note

    You can optionally use the --oci-insecure-signature-policy flag to not push signatures to the target mirror registry.

Prochaines étapes

  • Configure your cluster to use the resources generated by oc-mirror.

Ressources supplémentaires

12.2.3.11. Image set configuration parameters

The oc-mirror plugin requires an image set configuration file that defines what images to mirror. The following table lists the available parameters for the ImageSetConfiguration resource.

Tableau 12.1. ImageSetConfiguration parameters
ParamètresDescriptionValeurs

apiVersion

The API version for the ImageSetConfiguration content.

String. For example: mirror.openshift.io/v1alpha2.

archiveSize

The maximum size, in GiB, of each archive file within the image set.

Integer. For example: 4

mirror

The configuration of the image set.

Objet

mirror.additionalImages

The additional images configuration of the image set.

Array of objects. For example: 

additionalImages:
  - name: registry.redhat.io/ubi8/ubi:latest

mirror.additionalImages.name

The tag or digest of the image to mirror.

String. For example: registry.redhat.io/ubi8/ubi:latest

mirror.blockedImages

The full tag, digest, or pattern of images to block from mirroring.

Array of strings. For example: docker.io/library/alpine

mirror.helm

The helm configuration of the image set. Note that the oc-mirror plugin supports only helm charts that do not require user input when rendered.

Objet

mirror.helm.local

The local helm charts to mirror.

Array of objects. For example: 

local:
  - name: podinfo
    path: /test/podinfo-5.0.0.tar.gz

mirror.helm.local.name

The name of the local helm chart to mirror.

String. For example: podinfo.

mirror.helm.local.path

The path of the local helm chart to mirror.

String. For example: /test/podinfo-5.0.0.tar.gz.

mirror.helm.repositories

The remote helm repositories to mirror from.

Array of objects. For example: 

repositories:
  - name: podinfo
    url: https://example.github.io/podinfo
    charts:
      - name: podinfo
        version: 5.0.0

mirror.helm.repositories.name

The name of the helm repository to mirror from.

String. For example: podinfo.

mirror.helm.repositories.url

The URL of the helm repository to mirror from.

String. For example: https://example.github.io/podinfo.

mirror.helm.repositories.charts

The remote helm charts to mirror.

Array of objects.

mirror.helm.repositories.charts.name

The name of the helm chart to mirror.

String. For example: podinfo.

mirror.helm.repositories.charts.version

The version of the named helm chart to mirror.

String. For example: 5.0.0.

mirror.operators

The Operators configuration of the image set.

Array of objects. For example: 

operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.12
    packages:
      - name: elasticsearch-operator
        minVersion: '2.4.0'

mirror.operators.catalog

The Operator catalog to include in the image set.

String. For example: registry.redhat.io/redhat/redhat-operator-index:v4.12.

mirror.operators.full

When true, downloads the full catalog, Operator package, or Operator channel.

Boolean. The default value is false.

mirror.operators.packages

The Operator packages configuration.

Array of objects. For example: 

operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.12
    packages:
      - name: elasticsearch-operator
        minVersion: '5.2.3-31'

mirror.operators.packages.name

The Operator package name to include in the image set

String. For example: elasticsearch-operator.

mirror.operators.packages.channels

The Operator package channel configuration.

Objet

mirror.operators.packages.channels.name

The Operator channel name, unique within a package, to include in the image set.

String. For example: fast or stable-v4.12.

mirror.operators.packages.channels.maxVersion

The highest version of the Operator mirror across all channels in which it exists.

String. For example: 5.2.3-31

mirror.operators.packages.channels.minBundle

The name of the minimum bundle to include, plus all bundles in the upgrade graph to the channel head. Set this field only if the named bundle has no semantic version metadata.

String. For example: bundleName

mirror.operators.packages.channels.minVersion

The lowest version of the Operator to mirror across all channels in which it exists.

String. For example: 5.2.3-31

mirror.operators.packages.maxVersion

The highest version of the Operator to mirror across all channels in which it exists.

String. For example: 5.2.3-31.

mirror.operators.packages.minVersion

The lowest version of the Operator to mirror across all channels in which it exists.

String. For example: 5.2.3-31.

mirror.operators.skipDependencies

If true, dependencies of bundles are not included.

Boolean. The default value is false.

mirror.operators.targetName

Optional alternative name to mirror the referenced catalog as.

String. For example: my-operator-catalog

mirror.operators.targetTag

Optional alternative tag to append to the targetName.

String. For example: v1

mirror.platform

The platform configuration of the image set.

Objet

mirror.platform.architectures

The architecture of the platform release payload to mirror.

Array of strings. For example: 

architectures:
  - amd64
  - arm64

mirror.platform.channels

The platform channel configuration of the image set.

Array of objects. For example: 

channels:
  - name: stable-4.10
  - name: stable-4.12

mirror.platform.channels.full

When true, sets the minVersion to the first release in the channel and the maxVersion to the last release in the channel.

Boolean. The default value is false.

mirror.platform.channels.name

The name of the release channel.

String. For example: stable-4.12

mirror.platform.channels.minVersion

The minimum version of the referenced platform to be mirrored.

String. For example: 4.9.6

mirror.platform.channels.maxVersion

The highest version of the referenced platform to be mirrored.

String. For example: 4.12.1

mirror.platform.channels.shortestPath

Toggles shortest path mirroring or full range mirroring.

Boolean. The default value is false.

mirror.platform.channels.type

The type of the platform to be mirrored.

String. For example: ocp or okd. The default is ocp.

mirror.platform.graph

Indicates whether the OSUS graph is added to the image set and subsequently published to the mirror.

Boolean. The default value is false.

storageConfig

The back-end configuration of the image set.

Objet

storageConfig.local

The local back-end configuration of the image set.

Objet

storageConfig.local.path

The path of the directory to contain the image set metadata.

String. For example: ./path/to/dir/.

storageConfig.registry

The registry back-end configuration of the image set.

Objet

storageConfig.registry.imageURL

The back-end registry URI. Can optionally include a namespace reference in the URI.

String. For example: quay.io/myuser/imageset:metadata.

storageConfig.registry.skipTLS

Optionally skip TLS verification of the referenced back-end registry.

Boolean. The default value is false.

12.2.3.12. Image set configuration examples

The following ImageSetConfiguration file examples show the configuration for various mirroring use cases.

Use case: Including arbitrary images and helm charts

The following ImageSetConfiguration file uses a registry storage backend and includes helm charts and an additional Red Hat Universal Base Image (UBI).

Example ImageSetConfiguration file

apiVersion: mirror.openshift.io/v1alpha2
kind: ImageSetConfiguration
archiveSize: 4
storageConfig:
 registry:
   imageURL: example.com/mirror/oc-mirror-metadata
   skipTLS: false
mirror:
 platform:
   architectures:
     - "s390x"
   channels:
     - name: stable-4.12
 operators:
   - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.12
 helm:
   repositories:
     - name: redhat-helm-charts
       url: https://raw.githubusercontent.com/redhat-developer/redhat-helm-charts/master
       charts:
         - name: ibm-mongodb-enterprise-helm
           version: 0.2.0
 additionalImages:
   - name: registry.redhat.io/ubi8/ubi:latest

Use case: Including Operator versions from a minimum to the latest

The following ImageSetConfiguration file uses a local storage backend and includes only the Red Hat Advanced Cluster Security for Kubernetes Operator, versions starting at 3.68.0 and later in the latest channel.

Example ImageSetConfiguration file

apiVersion: mirror.openshift.io/v1alpha2
kind: ImageSetConfiguration
storageConfig:
  local:
    path: /home/user/metadata
mirror:
  operators:
    - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.12
      packages:
        - name: rhacs-operator
          channels:
          - name: latest
            minVersion: 3.68.0

Use case: Including the shortest OpenShift Container Platform upgrade path

The following ImageSetConfiguration file uses a local storage backend and includes all OpenShift Container Platform versions along the shortest upgrade path from the minimum version of 4.9.37 to the maximum version of 4.10.22.

Example ImageSetConfiguration file

apiVersion: mirror.openshift.io/v1alpha2
kind: ImageSetConfiguration
storageConfig:
  local:
    path: /home/user/metadata
mirror:
  platform:
    channels:
      - name: stable-4.10
        minVersion: 4.9.37
        maxVersion: 4.10.22
        shortestPath: true

Use case: Including all versions of OpenShift Container Platform from a minimum to the latest

The following ImageSetConfiguration file uses a registry storage backend and includes all OpenShift Container Platform versions starting at a minimum version of 4.10.10 to the latest version in the channel.

On every invocation of oc-mirror with this image set configuration, the latest release of the stable-4.10 channel is evaluated, so running oc-mirror at regular intervals ensures that you automatically receive the latest releases of OpenShift Container Platform images.

Example ImageSetConfiguration file

apiVersion: mirror.openshift.io/v1alpha2
kind: ImageSetConfiguration
storageConfig:
 registry:
   imageURL: example.com/mirror/oc-mirror-metadata
   skipTLS: false
mirror:
  platform:
    channels:
      - name: stable-4.10
        minVersion: 4.10.10

Use case: Including Operator versions from a minimum to a maximum

The following ImageSetConfiguration file uses a local storage backend and includes only an example Operator, versions starting at 1.0.0 through 2.0.0 in the stable channel.

This allows you to only mirror a specific version range of a particular Operator. As time progresses, you can use these settings to adjust the version to newer releases, for example when you no longer have version 1.0.0 running anywhere anymore. In this scenario, you can increase the minVersion to something newer, for example 1.5.0. When oc-mirror runs again with the updated version range, it automatically detects that any releases older than 1.5.0 are no longer required and deletes those from the registry to conserve storage space.

Example ImageSetConfiguration file

apiVersion: mirror.openshift.io/v1alpha2
kind: ImageSetConfiguration
storageConfig:
  local:
    path: /home/user/metadata
mirror:
  operators:
    - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.10
      packages:
        - name: example-operator
          channels:
            - name: stable
              minVersion: '1.0.0'
              maxVersion: '2.0.0'

Use case: Including the Nutanix CSI Operator

The following ImageSetConfiguration file uses a local storage backend and includes the Nutanix CSI Operator, the OpenShift Update Service (OSUS) graph image, and an additional Red Hat Universal Base Image (UBI).

Example ImageSetConfiguration file

  kind: ImageSetConfiguration
  apiVersion: mirror.openshift.io/v1alpha2
  storageConfig:
    registry:
      imageURL: mylocalregistry/ocp-mirror/openshift4
      skipTLS: false
  mirror:
    platform:
      channels:
      - name: stable-4.11
        type: ocp
      graph: true
    operators:
    - catalog: registry.redhat.io/redhat/certified-operator-index:v4.11
      packages:
      - name: nutanixcsioperator
        channels:
        - name: stable
    additionalImages:
    - name: registry.redhat.io/ubi8/ubi:latest

12.2.3.13. Command reference for oc-mirror

The following tables describe the oc mirror subcommands and flags:

Tableau 12.2. oc mirror subcommands
Sous-commandeDescription

completion

Generate the autocompletion script for the specified shell.

describe

Output the contents of an image set.

help

Show help about any subcommand.

init

Output an initial image set configuration template.

list

List available platform and Operator content and their version.

version

Output the oc-mirror version.

Tableau 12.3. oc mirror flags
DrapeauDescription

-c, --config <string>

Specify the path to an image set configuration file.

--continue-on-error

If any non image-pull related error occurs, continue and attempt to mirror as much as possible.

--dest-skip-tls

Disable TLS validation for the target registry.

--dest-use-http

Use plain HTTP for the target registry.

--dry-run

Print actions without mirroring images. Generates mapping.txt and pruning-plan.json files.

--from <string>

Specify the path to an image set archive that was generated by an execution of oc-mirror to load into a target registry.

-h, --help

Show the help.

--ignore-history

Ignore past mirrors when downloading images and packing layers. Disables incremental mirroring and might download more data.

--manifests-only

Generate manifests for ImageContentSourcePolicy objects to configure a cluster to use the mirror registry, but do not actually mirror any images.

--max-nested-paths <int>

Specify the maximum number of nested paths for destination registries that limit nested paths. The default is 2.

--max-per-registry <int>

Specify the number of concurrent requests allowed per registry. The default is 6.

--oci-feature-action

The action to perform when using the Technology Preview OCI feature. The options are copy or mirror.

--oci-insecure-signature-policy

Do not push signatures when using the Technology Preview OCI feature.

--oci-registries-config

Provide a registries configuration file to specify an alternative registry location to copy from when using the Technology Preview OCI feature.

--skip-cleanup

Skip removal of artifact directories.

--skip-image-pin

Do not replace image tags with digest pins in Operator catalogs.

--skip-metadata-check

Skip metadata when publishing an image set. This is only recommended when the image set was created with --ignore-history.

--skip-missing

If an image is not found, skip it instead of reporting an error and aborting execution. Does not apply to custom images explicitly specified in the image set configuration.

--skip-pruning

Disable automatic pruning of images from the target mirror registry.

--skip-verification

Skip digest verification.

--source-skip-tls

Disable TLS validation for the source registry.

--source-use-http

Use plain HTTP for the source registry.

--use-oci-feature

Use the Technology Preview OCI feature for copying OCI-formatted images.

-v, --verbose <int>

Specify the number for the log level verbosity. Valid values are 0 - 9. The default is 0.

12.2.4. Mise en miroir d'images à l'aide de la commande oc adm release mirror

Important

Pour éviter une utilisation excessive de la mémoire par l'application OpenShift Update Service, vous devez mettre en miroir les images de version dans un référentiel séparé comme décrit dans la procédure suivante.

Conditions préalables

  • Vous avez configuré un registre miroir à utiliser dans votre environnement déconnecté et vous pouvez accéder au certificat et aux informations d'identification que vous avez configurés.
  • Vous avez téléchargé le secret d'extraction depuis le Red Hat OpenShift Cluster Manager et l'avez modifié pour inclure l'authentification à votre dépôt miroir.
  • Si vous utilisez des certificats auto-signés, vous avez spécifié un Subject Alternative Name dans les certificats.

Procédure

  1. Utilisez le visualiseur Upgrade Graph et le planificateur de mise à jour de Red Hat OpenShift Container Platform pour planifier une mise à jour d'une version à une autre. L'OpenShift Upgrade Graph fournit des graphiques de canaux et un moyen de confirmer qu'il existe un chemin de mise à jour entre la version actuelle et la version prévue de votre cluster.

  2. Définir les variables d'environnement nécessaires :

    1. Exporter la version : 

      $ export OCP_RELEASE=<release_version>

      Pour <release_version>, indiquez la balise qui correspond à la version d'OpenShift Container Platform que vous souhaitez mettre à jour, par exemple 4.5.4.

    2. Exporter le nom du registre local et le port de l'hôte : 

      $ LOCAL_REGISTRY='<local_registry_host_name>:<local_registry_host_port>'

      Pour <local_registry_host_name>, indiquez le nom de domaine de votre dépôt miroir, et pour <local_registry_host_port>, indiquez le port sur lequel il sert le contenu.

    3. Exporter le nom du référentiel local : 

      $ LOCAL_REPOSITORY='<local_repository_name>'

      Pour <local_repository_name>, indiquez le nom du référentiel à créer dans votre registre, par exemple ocp4/openshift4.

    4. Si vous utilisez OpenShift Update Service, exportez un nom de dépôt local supplémentaire pour contenir les images de la version : 

      $ LOCAL_RELEASE_IMAGES_REPOSITORY='<local_release_images_repository_name>'

      Pour <local_release_images_repository_name>, indiquez le nom du référentiel à créer dans votre registre, par exemple ocp4/openshift4-release-images.

    5. Exportez le nom du référentiel à mettre en miroir : 

      $ PRODUCT_REPO='openshift-release-dev'

      Pour une version de production, vous devez spécifier openshift-release-dev.

    6. Exportez le chemin d'accès à votre registre secret : 

      $ LOCAL_SECRET_JSON='<path_to_pull_secret>'

      Pour <path_to_pull_secret>, indiquez le chemin absolu et le nom de fichier du secret d'extraction pour le registre miroir que vous avez créé.

      Note

      Si votre cluster utilise un objet ImageContentSourcePolicy pour configurer la mise en miroir du référentiel, vous ne pouvez utiliser que des secrets d'extraction globaux pour les registres mis en miroir. Vous ne pouvez pas ajouter un secret d'extraction à un projet.

    7. Exporter le miroir de validation : 

      $ RELEASE_NAME="ocp-release"

      Pour une version de production, vous devez spécifier ocp-release.

    8. Exportez le type d'architecture de votre serveur, par exemple x86_64.. : 

      aRCHITECTURE=<server_architecture>

    9. Exportez le chemin d'accès au répertoire qui hébergera les images en miroir : 

      rEMOVABLE_MEDIA_PATH=<path> $ REMOVABLE_MEDIA_PATH=<path> 1
      1
      Indiquer le chemin d'accès complet, y compris la barre oblique initiale (/).

  3. Examinez les images et les manifestes de configuration pour créer un miroir : 

    $ oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-dir=${REMOVABLE_MEDIA_PATH}/mirror quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} --dry-run

  4. Mettre en miroir les images de la version dans le registre miroir.

    • Si votre hôte miroir n'a pas d'accès à Internet, prenez les mesures suivantes :

      1. Connectez le support amovible à un système connecté à Internet.

      2. Mettez en miroir les images et les manifestes de configuration dans un répertoire du support amovible : 

        $ oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-dir=${REMOVABLE_MEDIA_PATH}/mirror quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE}
        Note

        Cette commande permet également de générer et d'enregistrer sur le support amovible la carte de configuration des signatures de l'image miroir de la version.

      3. Apportez le support à l'environnement déconnecté et téléchargez les images dans le registre local des conteneurs. 

        $ oc image mirror  -a ${LOCAL_SECRET_JSON} --from-dir=${REMOVABLE_MEDIA_PATH}/mirror "file://openshift/release:${OCP_RELEASE}*" ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} 1
        1
        Pour REMOVABLE_MEDIA_PATH, vous devez utiliser le même chemin d'accès que celui spécifié lors de la mise en miroir des images.
      4. Utilisez l'interface de ligne de commande (CLI) oc pour vous connecter au cluster que vous mettez à niveau.

      5. Appliquez la carte de configuration des signatures de l'image de version en miroir au cluster connecté : 

        oc apply -f ${REMOVABLE_MEDIA_PATH}/mirror/config/<image_signature_file> 1
        1
        Pour <image_signature_file>, indiquez le chemin d'accès et le nom du fichier, par exemple signature-sha256-81154f5c03294534.yaml.

      6. Si vous utilisez le service de mise à jour OpenShift, mettez en miroir l'image de la version sur un dépôt séparé : 

        $ oc image mirror -a ${LOCAL_SECRET_JSON} ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE} ${LOCAL_REGISTRY}/${LOCAL_RELEASE_IMAGES_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}

    • Si le registre de conteneurs local et le cluster sont connectés à l'hôte miroir, prenez les mesures suivantes :

      1. Poussez directement les images de version dans le registre local et appliquez la carte de configuration au cluster à l'aide de la commande suivante : 

        $ oc adm release mirror -a ${LOCAL_SECRET_JSON} --from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE} \
  --to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} --apply-release-image-signature
        Note

        Si vous incluez l'option --apply-release-image-signature, ne créez pas la carte de configuration pour la vérification de la signature de l'image.

      2. Si vous utilisez le service de mise à jour OpenShift, mettez en miroir l'image de la version sur un dépôt séparé : 

        $ oc image mirror -a ${LOCAL_SECRET_JSON} ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE} ${LOCAL_REGISTRY}/${LOCAL_RELEASE_IMAGES_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}

12.3. Mise à jour d'un cluster dans un environnement déconnecté à l'aide du service de mise à jour d'OpenShift

Pour obtenir une expérience de mise à jour similaire aux clusters connectés, vous pouvez utiliser les procédures suivantes pour installer et configurer OpenShift Update Service (OSUS) dans un environnement déconnecté.

Les étapes suivantes décrivent le processus de haut niveau de mise à jour d'un cluster dans un environnement déconnecté à l'aide d'OSUS :

  1. Configurer l'accès à un registre sécurisé.
  2. Mettez à jour le secret d'extraction du cluster global pour accéder à votre registre miroir.
  3. Installer l'OSUS Operator.
  4. Créer une image de conteneur de données graphiques pour le service de mise à jour OpenShift.
  5. Installez l'application OSUS et configurez vos clusters pour utiliser le service de mise à jour local d'OpenShift.
  6. Effectuez une procédure de mise à jour prise en charge à partir de la documentation, comme vous le feriez avec un cluster connecté.

12.3.1. Utiliser le service de mise à jour OpenShift dans un environnement déconnecté

Le service de mise à jour OpenShift (OSUS) fournit des recommandations de mise à jour aux clusters OpenShift Container Platform. Red Hat héberge publiquement le service de mise à jour OpenShift, et les clusters dans un environnement connecté peuvent se connecter au service via des API publiques pour récupérer les recommandations de mise à jour.

Cependant, les clusters dans un environnement déconnecté ne peuvent pas accéder à ces API publiques pour récupérer les informations de mise à jour. Pour avoir une expérience de mise à jour similaire dans un environnement déconnecté, vous pouvez installer et configurer OpenShift Update Service localement afin qu'il soit disponible dans l'environnement déconnecté.

Les sections suivantes décrivent comment installer une instance locale d'OSUS et la configurer pour qu'elle fournisse des recommandations de mise à jour à un cluster.

Ressources supplémentaires

12.3.2. Conditions préalables

12.3.3. Configurer l'accès à un registre sécurisé pour OpenShift Update Service

Si les images de version sont contenues dans un registre dont le certificat HTTPS X.509 est signé par une autorité de certification personnalisée, suivez les étapes de la section Configuration de référentiels de confiance supplémentaires pour l'accès au registre d'images, ainsi que les modifications suivantes pour le service de mise à jour.

L'opérateur du service de mise à jour OpenShift a besoin du nom de la clé de la carte de configuration updateservice-registry dans le certificat de l'autorité de certification du registre.

Registre d'images Exemple de carte de configuration de l'autorité de certification pour le service de mise à jour

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-registry-ca
data:
  updateservice-registry: | 1
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  registry-with-port.example.com..5000: | 2
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

1
L'opérateur du service de mise à jour OpenShift nécessite le nom de la clé de la carte de configuration updateservice-registry dans le certificat de l'autorité de certification du registre.
2
Si le registre comporte le port, tel que registry-with-port.example.com:5000, : doit être remplacé par ...

12.3.4. Mise à jour du secret d'extraction du cluster global

Vous pouvez mettre à jour le secret d'extraction global pour votre cluster en remplaçant le secret d'extraction actuel ou en ajoutant un nouveau secret d'extraction.

Cette procédure est nécessaire lorsque les utilisateurs utilisent, pour stocker les images, un registre différent de celui utilisé lors de l'installation.

Conditions préalables

  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

  1. Facultatif : Pour ajouter un nouveau secret d'extraction au secret d'extraction existant, procédez comme suit :

    1. Entrez la commande suivante pour télécharger le secret d'extraction : 

      $ oc get secret/pull-secret -n openshift-config --template='{{index .data ".dockerconfigjson" | base64decode}}' ><pull_secret_location> 1
      1
      Indiquer le chemin d'accès au fichier de secret d'extraction.

    2. Entrez la commande suivante pour ajouter le nouveau secret d'extraction : 

      $ oc registry login --registry="<registry>" \ 1
--auth-basic="<username>:<password>" \ 2
--to=<pull_secret_location> 3
      1
      Indiquez le nouveau registre. Vous pouvez inclure plusieurs référentiels dans le même registre, par exemple : --registry="<registry/my-namespace/my-repository>".
      2
      Fournir les informations d'identification du nouveau registre.
      3
      Indiquer le chemin d'accès au fichier de secret d'extraction.

      Vous pouvez également procéder à une mise à jour manuelle du fichier "pull secret".

  2. Entrez la commande suivante pour mettre à jour le secret d'extraction global pour votre cluster : 

    oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=<pull_secret_location> 1
    1
    Indiquez le chemin d'accès au nouveau fichier de secret d'extraction.

    Cette mise à jour est déployée sur tous les nœuds, ce qui peut prendre un certain temps en fonction de la taille de votre cluster.

    Note

    Depuis OpenShift Container Platform 4.7.4, les modifications apportées au secret de tirage global ne déclenchent plus la vidange ou le redémarrage d'un nœud.

12.3.5. Installation de l'opérateur OpenShift Update Service

Pour installer OpenShift Update Service, vous devez d'abord installer OpenShift Update Service Operator en utilisant la console web ou le CLI d'OpenShift Container Platform.

Note

Pour les clusters qui sont installés dans des environnements déconnectés, également connus sous le nom de clusters déconnectés, Operator Lifecycle Manager ne peut pas accéder par défaut aux sources OperatorHub fournies par Red Hat et hébergées sur des registres distants car ces sources distantes requièrent une connectivité Internet complète. Pour plus d'informations, voir Utilisation d'Operator Lifecycle Manager sur des réseaux restreints.

12.3.5.1. Installation de l'opérateur OpenShift Update Service à l'aide de la console web

Vous pouvez utiliser la console web pour installer l'opérateur OpenShift Update Service.

Procédure

  1. Dans la console web, cliquez sur Operators → OperatorHub.

    Note

    Entrez Update Service dans le champ Filter by keyword…​ pour trouver l'opérateur plus rapidement.

  2. Choisissez OpenShift Update Service dans la liste des opérateurs disponibles et cliquez sur Install.

    1. Le canal v1 est sélectionné comme Update Channel car c'est le seul canal disponible dans cette version.
    2. Sélectionnez A specific namespace on the cluster sous Installation Mode.
    3. Sélectionnez un espace de noms pour Installed Namespace ou acceptez l'espace de noms recommandé openshift-update-service.

    4. Sélectionnez un site Approval Strategy:

      • La stratégie Automatic permet à Operator Lifecycle Manager (OLM) de mettre automatiquement à jour l'opérateur lorsqu'une nouvelle version est disponible.
      • La stratégie Manual exige qu'un administrateur de cluster approuve la mise à jour de l'opérateur.
    5. Cliquez sur Install.
  3. Vérifiez que l'opérateur OpenShift Update Service est installé en passant à la page Operators → Installed Operators.
  4. Assurez-vous que OpenShift Update Service est répertorié dans l'espace de noms sélectionné avec un Status de Succeeded.
12.3.5.2. Installation de l'opérateur OpenShift Update Service à l'aide de la CLI

Vous pouvez utiliser l'OpenShift CLI (oc) pour installer l'OpenShift Update Service Operator.

Procédure

  1. Créer un espace de noms pour l'opérateur de service de mise à jour OpenShift :

    1. Créez un fichier YAML de l'objet Namespace, par exemple, update-service-namespace.yaml, pour l'opérateur du service de mise à jour OpenShift : 

      apiVersion: v1
kind: Namespace
metadata:
  name: openshift-update-service
  annotations:
    openshift.io/node-selector: ""
  labels:
    openshift.io/cluster-monitoring: "true" 1
      1
      Définissez l'étiquette openshift.io/cluster-monitoring pour activer la surveillance des clusters recommandée par l'opérateur sur cet espace de noms.

    2. Créer l'espace de noms : 

      $ oc create -f <filename>.yaml

      Par exemple : 

      $ oc create -f update-service-namespace.yaml

  2. Installez l'opérateur OpenShift Update Service en créant les objets suivants :

    1. Créez un fichier YAML de l'objet OperatorGroup, par exemple update-service-operator-group.yaml: 

      apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: update-service-operator-group
spec:
  targetNamespaces:
  - openshift-update-service

    2. Créer un objet OperatorGroup: 

      oc -n openshift-update-service create -f <filename>.yaml

      Par exemple : 

      $ oc -n openshift-update-service create -f update-service-operator-group.yaml

    3. Créez un fichier YAML de l'objet Subscription, par exemple update-service-subscription.yaml:

      Exemple d'abonnement

      apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: update-service-subscription
spec:
  channel: v1
  installPlanApproval: "Automatic"
  source: "redhat-operators" 1
  sourceNamespace: "openshift-marketplace"
  name: "cincinnati-operator"

      1
      Indiquez le nom de la source de catalogue qui fournit l'opérateur. Pour les clusters qui n'utilisent pas un Operator Lifecycle Manager (OLM) personnalisé, indiquez redhat-operators. Si votre cluster OpenShift Container Platform est installé dans un environnement déconnecté, indiquez le nom de l'objet CatalogSource créé lorsque vous avez configuré Operator Lifecycle Manager (OLM).

    4. Créer l'objet Subscription: 

      $ oc create -f <filename>.yaml

      Par exemple : 

      $ oc -n openshift-update-service create -f update-service-subscription.yaml

      L'opérateur OpenShift Update Service est installé dans l'espace de noms openshift-update-service et cible l'espace de noms openshift-update-service.

  3. Vérifier l'installation de l'opérateur : 

    $ oc -n openshift-update-service get clusterserviceversions

    Exemple de sortie

    NAME                             DISPLAY                    VERSION   REPLACES   PHASE
update-service-operator.v4.6.0   OpenShift Update Service   4.6.0                Succeeded
...

    Si l'opérateur OpenShift Update Service est listé, l'installation a réussi. Le numéro de version peut être différent de celui indiqué.

Ressources supplémentaires

12.3.6. Création de l'image du conteneur de données graphiques d'OpenShift Update Service

Le service de mise à jour OpenShift nécessite une image de conteneur de données graphiques, à partir de laquelle le service de mise à jour OpenShift récupère des informations sur l'appartenance à un canal et les bords de mise à jour bloqués. Les données de graphe sont généralement récupérées directement à partir du référentiel de données de graphe de la mise à jour. Dans les environnements où une connexion internet n'est pas disponible, le chargement de ces informations à partir d'un conteneur init est une autre façon de rendre les données graphiques disponibles pour le service de mise à jour OpenShift. Le rôle du conteneur init est de fournir une copie locale des données du graphe, et pendant l'initialisation du pod, le conteneur init copie les données sur un volume accessible par le service.

Note

Le plugin oc-mirror OpenShift CLI (oc) crée cette image de conteneur de données graphiques en plus de la mise en miroir des images de version. Si vous avez utilisé le plugin oc-mirror pour créer un miroir de vos images, vous pouvez sauter cette procédure.

Procédure

  1. Créez un fichier Docker, par exemple ./Dockerfile, contenant les éléments suivants : 

    FROM registry.access.redhat.com/ubi8/ubi:8.1

RUN curl -L -o cincinnati-graph-data.tar.gz https://api.openshift.com/api/upgrades_info/graph-data

RUN mkdir -p /var/lib/cincinnati-graph-data && tar xvzf cincinnati-graph-data.tar.gz -C /var/lib/cincinnati-graph-data/ --no-overwrite-dir --no-same-owner

CMD ["/bin/bash", "-c" ,"exec cp -rp /var/lib/cincinnati-graph-data/* /var/lib/cincinnati/graph-data"]

  2. Utilisez le fichier docker créé à l'étape précédente pour construire une image de conteneur de données graphiques, par exemple, registry.example.com/openshift/graph-data:latest: 

    $ podman build -f ./Dockerfile -t registry.example.com/openshift/graph-data:latest

  3. Pousser l'image du conteneur de données graphiques créée à l'étape précédente vers un dépôt accessible à OpenShift Update Service, par exemple, registry.example.com/openshift/graph-data:latest: 

    $ podman push registry.example.com/openshift/graph-data:latest
    Note

    Pour pousser une image de données graphiques vers un registre local dans un environnement déconnecté, copiez l'image du conteneur de données graphiques créée à l'étape précédente vers un référentiel accessible au service de mise à jour OpenShift. Exécutez oc image mirror --help pour connaître les options disponibles.

12.3.7. Création d'une application OpenShift Update Service

Vous pouvez créer une application OpenShift Update Service en utilisant la console web ou le CLI d'OpenShift Container Platform.

12.3.7.1. Créer une application OpenShift Update Service en utilisant la console web

Vous pouvez utiliser la console web d'OpenShift Container Platform pour créer une application OpenShift Update Service en utilisant l'OpenShift Update Service Operator.

Conditions préalables

  • L'opérateur de service de mise à jour OpenShift a été installé.
  • L'image du conteneur de données graphiques d'OpenShift Update Service a été créée et poussée vers un dépôt accessible à OpenShift Update Service.
  • La version actuelle et les versions cibles des mises à jour ont été mises en miroir dans un registre accessible localement.

Procédure

  1. Dans la console web, cliquez sur Operators → Installed Operators.
  2. Choisissez OpenShift Update Service dans la liste des opérateurs installés.
  3. Cliquez sur l'onglet Update Service.
  4. Cliquez sur Create UpdateService.
  5. Entrez un nom dans le champ Name, par exemple service.
  6. Saisissez le pullspec local dans le champ Graph Data Image vers l'image du conteneur de données graphiques créée dans \N "Création de l'image du conteneur de données graphiques d'OpenShift Update Service\N", par exemple, registry.example.com/openshift/graph-data:latest.
  7. Dans le champ Releases, saisissez le registre local et le référentiel créés pour contenir les images de version dans le document "Mirroring the OpenShift Container Platform image repository", par exemple, registry.example.com/ocp4/openshift4-release-images.
  8. Saisissez 2 dans le champ Replicas.
  9. Cliquez sur Create pour créer l'application OpenShift Update Service.

  10. Vérifiez l'application OpenShift Update Service :

    • Dans la liste UpdateServices de l'onglet Update Service, cliquez sur l'application Update Service que vous venez de créer.
    • Cliquez sur l'onglet Resources.
    • Vérifiez que chaque ressource d'application a un statut de Created.
12.3.7.2. Créer une application OpenShift Update Service en utilisant le CLI

Vous pouvez utiliser l'OpenShift CLI (oc) pour créer une application OpenShift Update Service.

Conditions préalables

  • L'opérateur de service de mise à jour OpenShift a été installé.
  • L'image du conteneur de données graphiques d'OpenShift Update Service a été créée et poussée vers un dépôt accessible à OpenShift Update Service.
  • La version actuelle et les versions cibles des mises à jour ont été mises en miroir dans un registre accessible localement.

Procédure

  1. Configurez l'espace de noms cible d'OpenShift Update Service, par exemple, openshift-update-service: 

    $ NAMESPACE=openshift-update-service

    L'espace de noms doit correspondre à la valeur targetNamespaces du groupe d'opérateurs.

  2. Configurez le nom de l'application OpenShift Update Service, par exemple, service: 

    $ NAME=service

  3. Configurez le registre local et le référentiel pour les images de version comme configuré dans "Mirroring the OpenShift Container Platform image repository", par exemple, registry.example.com/ocp4/openshift4-release-images: 

    $ RELEASE_IMAGES=registry.example.com/ocp4/openshift4-release-images

  4. Définir le pullspec local pour l'image de données graphiques à l'image de conteneur de données graphiques créée dans " Création de l'image de conteneur de données graphiques d'OpenShift Update Service ", par exemple, registry.example.com/openshift/graph-data:latest: 

    $ GRAPH_DATA_IMAGE=registry.example.com/openshift/graph-data:latest

  5. Créer un objet d'application OpenShift Update Service : 

    $ oc -n "${NAMESPACE}" create -f - <<EOF
apiVersion: updateservice.operator.openshift.io/v1
kind: UpdateService
metadata:
  name: ${NAME}
spec:
  replicas: 2
  releases: ${RELEASE_IMAGES}
  graphDataImage: ${GRAPH_DATA_IMAGE}
EOF

  6. Vérifiez l'application OpenShift Update Service :

    1. Utilisez la commande suivante pour obtenir un itinéraire de moteur de stratégie : 

      $ while sleep 1; do POLICY_ENGINE_GRAPH_URI="$(oc -n "${NAMESPACE}" get -o jsonpath='{.status.policyEngineURI}/api/upgrades_info/v1/graph{"\n"}' updateservice "${NAME}")"; SCHEME="${POLICY_ENGINE_GRAPH_URI%%:*}"; if test "${SCHEME}" = http -o "${SCHEME}" = https; then break; fi; done

      Il se peut que vous deviez interroger le système jusqu'à ce que la commande aboutisse.

    2. Récupérer un graphe du moteur de politiques. Veillez à spécifier une version valide pour channel. Par exemple, si vous utilisez OpenShift Container Platform 4.12, utilisez stable-4.12: 

      $ while sleep 10; do HTTP_CODE="$(curl --header Accept:application/json --output /dev/stderr --write-out "%{http_code}" "${POLICY_ENGINE_GRAPH_URI}?channel=stable-4.6")"; if test "${HTTP_CODE}" -eq 200; then break; fi; echo "${HTTP_CODE}"; done

      Cette opération s'effectue jusqu'à ce que la demande de graphique aboutisse ; toutefois, le graphique résultant peut être vide en fonction des images de version que vous avez mises en miroir.

Note

Le nom de la route du moteur de stratégie ne doit pas comporter plus de 63 caractères, conformément à la norme RFC-1123. Si vous voyez le statut ReconcileCompleted comme false avec la raison CreateRouteFailed causée par host must conform to DNS 1123 naming convention and must be no more than 63 characters, essayez de créer le service de mise à jour avec un nom plus court.

12.3.7.2.1. Configuration de l'opérateur de version de cluster (CVO)

Après l'installation de l'opérateur OpenShift Update Service et la création de l'application OpenShift Update Service, le Cluster Version Operator (CVO) peut être mis à jour pour extraire les données graphiques de l'OpenShift Update Service installé localement.

Conditions préalables

  • L'opérateur de service de mise à jour OpenShift a été installé.
  • L'image du conteneur de données graphiques d'OpenShift Update Service a été créée et poussée vers un dépôt accessible à OpenShift Update Service.
  • La version actuelle et les versions cibles des mises à jour ont été mises en miroir dans un registre accessible localement.
  • L'application OpenShift Update Service a été créée.

Procédure

  1. Définissez l'espace de noms cible du service de mise à jour OpenShift, par exemple, openshift-update-service: 

    $ NAMESPACE=openshift-update-service

  2. Définissez le nom de l'application OpenShift Update Service, par exemple, service: 

    $ NAME=service

  3. Obtenir la route du moteur de politique : 

    $ POLICY_ENGINE_GRAPH_URI="$(oc -n "${NAMESPACE}" get -o jsonpath='{.status.policyEngineURI}/api/upgrades_info/v1/graph{"\n"}' updateservice "${NAME}")"

  4. Définir le patch pour les données du graphique de traction : 

    $ PATCH="{\"spec\":{\"upstream\":\"${POLICY_ENGINE_GRAPH_URI}\"}}"

  5. Patch de l'OVE pour utiliser le service de mise à jour local d'OpenShift : 

    $ oc patch clusterversion version -p $PATCH --type merge
Note

Voir Activation du proxy à l'échelle du cluster pour configurer l'autorité de certification de manière à ce qu'elle fasse confiance au serveur de mise à jour.

12.3.8. Prochaines étapes

Avant de mettre à jour votre cluster, vérifiez que les conditions suivantes sont remplies :

  • Le Cluster Version Operator (CVO) est configuré pour utiliser votre application OpenShift Update Service installée localement.
  • La carte de configuration de la signature de l'image de version pour la nouvelle version est appliquée à votre cluster.
  • Les images de la version actuelle et de la version cible de la mise à jour sont mises en miroir dans un registre accessible localement.
  • Une image récente du conteneur de données graphiques a été mise en miroir dans votre registre local.

Après avoir configuré votre cluster pour utiliser le service de mise à jour OpenShift installé localement et le registre miroir local, vous pouvez utiliser l'une des méthodes de mise à jour suivantes :

12.4. Mise à jour d'un cluster dans un environnement déconnecté sans OpenShift Update Service

Utilisez les procédures suivantes pour mettre à jour un cluster dans un environnement déconnecté sans accès au service de mise à jour OpenShift.

12.4.1. Conditions préalables

  • L'outil d'interface de ligne de commande (CLI) oc doit être installé.
  • Vous devez approvisionner un registre local d'images de conteneurs avec les images de conteneurs pour votre mise à jour, comme décrit dans Mirroring the OpenShift Container Platform image repository.
  • Vous devez avoir accès au cluster en tant qu'utilisateur disposant de privilèges admin. Voir Utilisation de RBAC pour définir et appliquer des autorisations.
  • Vous devez disposer d'une sauvegarde etcd récente au cas où votre mise à jour échouerait et où vous devriez restaurer votre cluster à un état antérieur.
  • Vous devez vous assurer que tous les pools de configuration de machines (MCP) sont en cours d'exécution et ne sont pas en pause. Les nœuds associés à un MCP en pause sont ignorés lors du processus de mise à jour. Vous pouvez mettre les MCP en pause si vous effectuez une stratégie de mise à jour par déploiement canarien.
  • Si votre cluster utilise des informations d'identification gérées manuellement, mettez à jour les ressources du fournisseur de cloud pour la nouvelle version. Pour plus d'informations, notamment sur la manière de déterminer s'il s'agit d'une exigence pour votre cluster, voir Préparation de la mise à jour d'un cluster avec des informations d'identification gérées manuellement.
  • Si vous exécutez un opérateur ou si vous avez configuré une application avec le budget d'interruption des pods, il se peut que vous subissiez une interruption pendant le processus de mise à niveau. Si minAvailable est défini à 1 dans PodDisruptionBudget, les nœuds sont vidés pour appliquer les configurations de machine en attente, ce qui peut bloquer le processus d'éviction. Si plusieurs nœuds sont redémarrés, tous les pods peuvent s'exécuter sur un seul nœud, et le champ PodDisruptionBudget peut empêcher la vidange des nœuds.
Note

Si vous exécutez un opérateur ou si vous avez configuré une application avec le budget d'interruption des pods, il se peut que vous subissiez une interruption pendant le processus de mise à niveau. Si minAvailable est défini à 1 dans PodDisruptionBudget, les nœuds sont vidés pour appliquer les configurations de machine en attente, ce qui peut bloquer le processus d'éviction. Si plusieurs nœuds sont redémarrés, tous les pods peuvent s'exécuter sur un seul nœud, et le champ PodDisruptionBudget peut empêcher la vidange des nœuds.

12.4.2. Mise en pause d'une ressource MachineHealthCheck

Au cours du processus de mise à niveau, les nœuds de la grappe peuvent devenir temporairement indisponibles. Dans le cas des nœuds de travail, le contrôle de l'état de la machine peut identifier ces nœuds comme étant malsains et les redémarrer. Pour éviter de redémarrer ces nœuds, mettez en pause toutes les ressources MachineHealthCheck avant de mettre à jour le cluster.

Conditions préalables

  • Installez le CLI OpenShift (oc).

Procédure

  1. Pour dresser la liste de toutes les ressources MachineHealthCheck disponibles que vous souhaitez mettre en pause, exécutez la commande suivante : 

    $ oc get machinehealthcheck -n openshift-machine-api

  2. Pour mettre en pause les contrôles de santé de la machine, ajoutez l'annotation cluster.x-k8s.io/paused="" à la ressource MachineHealthCheck. Exécutez la commande suivante : 

    $ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused=""

    La ressource annotée MachineHealthCheck ressemble au fichier YAML suivant : 

    apiVersion: machine.openshift.io/v1beta1
kind: MachineHealthCheck
metadata:
  name: example
  namespace: openshift-machine-api
  annotations:
    cluster.x-k8s.io/paused: ""
spec:
  selector:
    matchLabels:
      role: worker
  unhealthyConditions:
  - type:    "Ready"
    status:  "Unknown"
    timeout: "300s"
  - type:    "Ready"
    status:  "False"
    timeout: "300s"
  maxUnhealthy: "40%"
status:
  currentHealthy: 5
  expectedMachines: 5
    Important

    Reprendre les contrôles de santé des machines après avoir mis à jour le cluster. Pour reprendre le contrôle, supprimez l'annotation de pause de la ressource MachineHealthCheck en exécutant la commande suivante : 

    $ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused-

12.4.3. Mise à jour du cluster déconnecté

Mettez à jour le cluster déconnecté vers la version d'OpenShift Container Platform pour laquelle vous avez téléchargé les images de mise à jour.

Note

Si vous avez un OpenShift Update Service local, vous pouvez mettre à jour en utilisant la console web connectée ou les instructions CLI au lieu de cette procédure.

Conditions préalables

  • Vous avez mis en miroir les images de la nouvelle version dans votre registre.
  • Vous avez appliqué à votre cluster la signature de l'image de version ConfigMap pour la nouvelle version.
  • Vous avez obtenu la valeur de la somme sha256 pour la version à partir de la signature de l'image ConfigMap.
  • Installez le CLI OpenShift (oc).
  • Mettre en pause toutes les ressources MachineHealthCheck.

Procédure

  • Mettre à jour le cluster : 

    $ oc adm upgrade --allow-explicit-upgrade --to-image ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}<sha256_sum_value> 1
    1
    La valeur <sha256_sum_value> est la valeur de la somme sha256 pour la libération de la signature de l'image ConfigMap, par exemple, @sha256:81154f5c03294534e1eaf0319bef7a601134f891689ccede5d705ef659aa8c92

    Si vous utilisez ImageContentSourcePolicy pour le registre miroir, vous pouvez utiliser le nom canonique du registre au lieu de LOCAL_REGISTRY.

    Note

    Vous ne pouvez configurer des secrets de tirage globaux que pour les clusters qui ont un objet ImageContentSourcePolicy. Vous ne pouvez pas ajouter un secret d'extraction à un projet.

12.4.4. Configuration de la mise en miroir du référentiel du registre d'images

La configuration de la mise en miroir du référentiel du registre des conteneurs vous permet d'effectuer les opérations suivantes :

  • Configurez votre cluster OpenShift Container Platform pour rediriger les demandes d'extraction d'images à partir d'un dépôt sur un registre d'images source et les faire résoudre par un dépôt sur un registre d'images miroir.
  • Identifier plusieurs référentiels miroirs pour chaque référentiel cible, afin de s'assurer que si un miroir est en panne, un autre peut être utilisé.

Les attributs de la mise en miroir de référentiel dans OpenShift Container Platform sont les suivants :

  • Les extractions d'images résistent aux interruptions du registre.
  • Les clusters situés dans des environnements déconnectés peuvent extraire des images de sites critiques, tels que quay.io, et demander aux registres situés derrière le pare-feu de l'entreprise de fournir les images demandées.
  • Un ordre particulier de registres est essayé lorsqu'une demande d'extraction d'image est faite, le registre permanent étant généralement le dernier essayé.
  • Les informations sur le miroir que vous saisissez sont ajoutées au fichier /etc/containers/registries.conf sur chaque nœud du cluster OpenShift Container Platform.
  • Lorsqu'un nœud demande une image à partir du référentiel source, il essaie chaque référentiel miroir à tour de rôle jusqu'à ce qu'il trouve le contenu demandé. Si tous les miroirs échouent, le cluster essaie le référentiel source. En cas de succès, l'image est transférée au nœud.

La configuration de la mise en miroir du référentiel peut se faire de la manière suivante :

  • A l'installation d'OpenShift Container Platform :

    En extrayant les images de conteneurs nécessaires à OpenShift Container Platform, puis en amenant ces images derrière le pare-feu de votre entreprise, vous pouvez installer OpenShift Container Platform dans un centre de données qui se trouve dans un environnement déconnecté.

  • Après l'installation d'OpenShift Container Platform :

    Même si vous ne configurez pas la mise en miroir lors de l'installation d'OpenShift Container Platform, vous pouvez le faire plus tard en utilisant l'objet ImageContentSourcePolicy.

La procédure suivante fournit une configuration miroir post-installation, dans laquelle vous créez un objet ImageContentSourcePolicy qui identifie :

  • La source du référentiel d'images de conteneurs que vous souhaitez mettre en miroir.
  • Une entrée distincte pour chaque référentiel miroir dans lequel vous souhaitez proposer le contenu demandé au référentiel source.
Note

Vous ne pouvez configurer des secrets de tirage globaux que pour les clusters qui ont un objet ImageContentSourcePolicy. Vous ne pouvez pas ajouter un secret d'extraction à un projet.

Conditions préalables

  • Accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

  1. Configurer les référentiels miroirs, en utilisant l'un ou l'autre :

    • La configuration d'un référentiel miroir avec Red Hat Quay, comme décrit dans Red Hat Quay Repository Mirroring. L'utilisation de Red Hat Quay vous permet de copier des images d'un référentiel vers un autre et de synchroniser automatiquement ces référentiels de manière répétée au fil du temps.

    • Utilisation d'un outil tel que skopeo pour copier manuellement les images du répertoire source vers le référentiel miroir.

      Par exemple, après avoir installé le paquetage RPM skopeo sur un système Red Hat Enterprise Linux (RHEL) 7 ou RHEL 8, utilisez la commande skopeo comme indiqué dans cet exemple : 

      $ skopeo copy \
docker://registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6 \
docker://example.io/example/ubi-minimal

      Dans cet exemple, vous avez un registre d'images de conteneurs nommé example.io avec un dépôt d'images nommé example dans lequel vous voulez copier l'image ubi8/ubi-minimal à partir de registry.access.redhat.com. Après avoir créé le registre, vous pouvez configurer votre cluster OpenShift Container Platform pour rediriger les requêtes faites sur le dépôt source vers le dépôt miroir.

  2. Connectez-vous à votre cluster OpenShift Container Platform.

  3. Créez un fichier ImageContentSourcePolicy (par exemple, registryrepomirror.yaml), en remplaçant la source et les miroirs par vos propres paires et images de registres et de référentiels : 

    apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  name: ubi8repo
spec:
  repositoryDigestMirrors:
  - mirrors:
    - example.io/example/ubi-minimal 1
    - example.com/example/ubi-minimal 2
    source: registry.access.redhat.com/ubi8/ubi-minimal 3
  - mirrors:
    - mirror.example.com/redhat
    source: registry.redhat.io/openshift4 4
  - mirrors:
    - mirror.example.com
    source: registry.redhat.io 5
  - mirrors:
    - mirror.example.net/image
    source: registry.example.com/example/myimage 6
  - mirrors:
    - mirror.example.net
    source: registry.example.com/example 7
  - mirrors:
    - mirror.example.net/registry-example-com
    source: registry.example.com 8
    1
    Indique le nom du registre d'images et du référentiel.
    2
    Indique plusieurs référentiels miroirs pour chaque référentiel cible. Si un miroir est hors service, le référentiel cible peut utiliser un autre miroir.
    3
    Indique le registre et le référentiel contenant le contenu qui est mis en miroir.
    4
    Vous pouvez configurer un espace de noms à l'intérieur d'un registre pour utiliser n'importe quelle image dans cet espace de noms. Si vous utilisez un domaine de registre comme source, la ressource ImageContentSourcePolicy est appliquée à tous les référentiels du registre.
    5
    Si vous configurez le nom du registre, la ressource ImageContentSourcePolicy est appliquée à tous les référentiels, du registre source au registre miroir.
    6
    Tire l'image mirror.example.net/image@sha256:…​.
    7
    Extrait l'image myimage dans l'espace de noms du registre source à partir du miroir mirror.example.net/myimage@sha256:…​.
    8
    Extrait l'image registry.example.com/example/myimage du registre miroir mirror.example.net/registry-example-com/example/myimage@sha256:…​. La ressource ImageContentSourcePolicy est appliquée à tous les référentiels d'un registre source à un registre miroir mirror.example.net/registry-example-com.

  4. Créer le nouvel objet ImageContentSourcePolicy: 

    $ oc create -f registryrepomirror.yaml

    Une fois l'objet ImageContentSourcePolicy créé, les nouveaux paramètres sont déployés sur chaque nœud et le cluster commence à utiliser le référentiel miroir pour les requêtes vers le référentiel source.

  5. Pour vérifier que les paramètres de configuration en miroir sont appliqués, procédez comme suit sur l'un des nœuds.

    1. Dressez la liste de vos nœuds : 

      $ oc get node

      Exemple de sortie

      NAME                           STATUS                     ROLES    AGE  VERSION
ip-10-0-137-44.ec2.internal    Ready                      worker   7m   v1.25.0
ip-10-0-138-148.ec2.internal   Ready                      master   11m  v1.25.0
ip-10-0-139-122.ec2.internal   Ready                      master   11m  v1.25.0
ip-10-0-147-35.ec2.internal    Ready                      worker   7m   v1.25.0
ip-10-0-153-12.ec2.internal    Ready                      worker   7m   v1.25.0
ip-10-0-154-10.ec2.internal    Ready                      master   11m  v1.25.0

      La ressource Imagecontentsourcepolicy ne redémarre pas les nœuds.

    2. Lancez le processus de débogage pour accéder au nœud : 

      $ oc debug node/ip-10-0-147-35.ec2.internal

      Exemple de sortie

      Starting pod/ip-10-0-147-35ec2internal-debug ...
To use host binaries, run `chroot /host`

    3. Changez votre répertoire racine en /host: 

      sh-4.2# chroot /host

    4. Vérifiez le fichier /etc/containers/registries.conf pour vous assurer que les changements ont bien été effectués : 

      sh-4.2# cat /etc/containers/registries.conf

      Exemple de sortie

      unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
short-name-mode = ""

[[registry]]
  prefix = ""
  location = "registry.access.redhat.com/ubi8/ubi-minimal"
  mirror-by-digest-only = true

  [[registry.mirror]]
    location = "example.io/example/ubi-minimal"

  [[registry.mirror]]
    location = "example.com/example/ubi-minimal"

[[registry]]
  prefix = ""
  location = "registry.example.com"
  mirror-by-digest-only = true

  [[registry.mirror]]
    location = "mirror.example.net/registry-example-com"

[[registry]]
  prefix = ""
  location = "registry.example.com/example"
  mirror-by-digest-only = true

  [[registry.mirror]]
    location = "mirror.example.net"

[[registry]]
  prefix = ""
  location = "registry.example.com/example/myimage"
  mirror-by-digest-only = true

  [[registry.mirror]]
    location = "mirror.example.net/image"

[[registry]]
  prefix = ""
  location = "registry.redhat.io"
  mirror-by-digest-only = true

  [[registry.mirror]]
    location = "mirror.example.com"

[[registry]]
  prefix = ""
  location = "registry.redhat.io/openshift4"
  mirror-by-digest-only = true

  [[registry.mirror]]
    location = "mirror.example.com/redhat"

    5. Transmet un condensé d'image au nœud à partir de la source et vérifie s'il est résolu par le miroir. Les objets ImageContentSourcePolicy ne prennent en charge que les condensés d'image, et non les balises d'image. 

      sh-4.2# podman pull --log-level=debug registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6

Dépannage de la mise en miroir du référentiel

Si la procédure de mise en miroir du référentiel ne fonctionne pas comme décrit, utilisez les informations suivantes sur le fonctionnement de la mise en miroir du référentiel pour résoudre le problème.

  • Le premier miroir de travail est utilisé pour fournir l'image tirée.
  • Le registre principal n'est utilisé que si aucun autre miroir ne fonctionne.
  • Dans le contexte du système, les drapeaux Insecure sont utilisés comme solution de repli.
  • Le format du fichier /etc/containers/registries.conf a récemment changé. Il s'agit désormais de la version 2 et du format TOML.

12.4.5. Élargissement de la portée du catalogue d'images miroirs afin de réduire la fréquence des redémarrages des nœuds de la grappe

Vous pouvez définir la portée du catalogue d'images en miroir au niveau du référentiel ou au niveau du registre général. Une ressource ImageContentSourcePolicy à portée étendue réduit le nombre de fois où les nœuds doivent redémarrer en réponse aux changements apportés à la ressource.

Pour élargir la portée du catalogue d'images miroirs dans la ressource ImageContentSourcePolicy, procédez comme suit.

Conditions préalables

  • Install the OpenShift Container Platform CLI oc.
  • Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.
  • Configurez un catalogue d'images en miroir à utiliser dans votre cluster déconnecté.

Procédure

  1. Exécutez la commande suivante, en spécifiant des valeurs pour <local_registry>, <pull_spec>, et <pull_secret_file>: 

    $ oc adm catalog mirror <local_registry>/<pull_spec> <local_registry> -a <pull_secret_file> --icsp-scope=registry

    où :

    <local_registry>
    est le registre local que vous avez configuré pour votre cluster déconnecté, par exemple, local.registry:5000.
    <pull_spec>
    est la spécification de traction telle qu'elle est configurée dans votre registre déconnecté, par exemple, redhat/redhat-operator-index:v4.12
    <pull_secret_file>
    est le secret d'extraction de registry.redhat.io au format de fichier .json. Vous pouvez télécharger le pull secret depuis le Red Hat OpenShift Cluster Manager.

    La commande oc adm catalog mirror crée un répertoire /redhat-operator-index-manifests et génère des fichiers imageContentSourcePolicy.yaml, catalogSource.yaml et mapping.txt.

  2. Appliquer la nouvelle ressource ImageContentSourcePolicy au cluster : 

    $ oc apply -f imageContentSourcePolicy.yaml

Vérification

  • Vérifiez que oc apply a bien appliqué la modification à ImageContentSourcePolicy: 

    $ oc get ImageContentSourcePolicy -o yaml

    Exemple de sortie

    apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1alpha1
  kind: ImageContentSourcePolicy
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"operator.openshift.io/v1alpha1","kind":"ImageContentSourcePolicy","metadata":{"annotations":{},"name":"redhat-operator-index"},"spec":{"repositoryDigestMirrors":[{"mirrors":["local.registry:5000"],"source":"registry.redhat.io"}]}}
...

Après avoir mis à jour la ressource ImageContentSourcePolicy, OpenShift Container Platform déploie les nouveaux paramètres sur chaque nœud et le cluster commence à utiliser le référentiel miroir pour les requêtes vers le référentiel source.

12.4.6. Ressources supplémentaires

12.5. Désinstallation du service de mise à jour OpenShift d'un cluster

Pour supprimer une copie locale d'OpenShift Update Service (OSUS) de votre cluster, vous devez d'abord supprimer l'application OSUS, puis désinstaller l'opérateur OSUS.

12.5.1. Suppression d'une application OpenShift Update Service

Vous pouvez supprimer une application OpenShift Update Service en utilisant la console web ou le CLI d'OpenShift Container Platform.

12.5.1.1. Suppression d'une application OpenShift Update Service à l'aide de la console web

Vous pouvez utiliser la console web de OpenShift Container Platform pour supprimer une application OpenShift Update Service en utilisant l'OpenShift Update Service Operator.

Conditions préalables

  • L'opérateur de service de mise à jour OpenShift a été installé.

Procédure

  1. Dans la console web, cliquez sur Operators → Installed Operators.
  2. Choisissez OpenShift Update Service dans la liste des opérateurs installés.
  3. Cliquez sur l'onglet Update Service.
  4. Dans la liste des applications OpenShift Update Service installées, sélectionnez l'application à supprimer et cliquez sur Delete UpdateService.
  5. Dans la boîte de dialogue de confirmation Delete UpdateService?, cliquez sur Delete pour confirmer la suppression.
12.5.1.2. Suppression d'une application OpenShift Update Service à l'aide de la CLI

Vous pouvez utiliser la CLI OpenShift (oc) pour supprimer une application OpenShift Update Service.

Procédure

  1. Obtenez le nom de l'application OpenShift Update Service en utilisant l'espace de noms dans lequel l'application OpenShift Update Service a été créée, par exemple, openshift-update-service: 

    $ oc get updateservice -n openshift-update-service

    Exemple de sortie

    NAME      AGE
service   6s

  2. Supprimer l'application OpenShift Update Service en utilisant la valeur NAME de l'étape précédente et l'espace de noms dans lequel l'application OpenShift Update Service a été créée, par exemple, openshift-update-service: 

    $ oc delete updateservice service -n openshift-update-service

    Exemple de sortie

    updateservice.updateservice.operator.openshift.io "service" deleted

12.5.2. Désinstallation de l'opérateur OpenShift Update Service

Vous pouvez désinstaller l'OpenShift Update Service Operator en utilisant la console web ou le CLI d'OpenShift Container Platform.

12.5.2.1. Désinstallation de l'OpenShift Update Service Operator à l'aide de la console web

Vous pouvez utiliser la console web d'OpenShift Container Platform pour désinstaller l'opérateur OpenShift Update Service.

Conditions préalables

  • Toutes les applications OpenShift Update Service ont été supprimées.

Procédure

  1. Dans la console web, cliquez sur Operators → Installed Operators.
  2. Sélectionnez OpenShift Update Service dans la liste des opérateurs installés et cliquez sur Uninstall Operator.
  3. Dans la boîte de dialogue de confirmation Uninstall Operator?, cliquez sur Uninstall pour confirmer la désinstallation.
12.5.2.2. Désinstallation de l'OpenShift Update Service Operator à l'aide de la CLI

Vous pouvez utiliser l'OpenShift CLI (oc) pour désinstaller l'OpenShift Update Service Operator.

Conditions préalables

  • Toutes les applications OpenShift Update Service ont été supprimées.

Procédure

  1. Passez au projet contenant l'opérateur OpenShift Update Service, par exemple, openshift-update-service: 

    $ oc project openshift-update-service

    Exemple de sortie

    Now using project "openshift-update-service" on server "https://example.com:6443".

  2. Obtenir le nom du groupe d'opérateurs OpenShift Update Service Operator : 

    $ oc get operatorgroup

    Exemple de sortie

    NAME                             AGE
openshift-update-service-fprx2   4m41s

  3. Supprimer le groupe d'opérateurs, par exemple openshift-update-service-fprx2: 

    $ oc delete operatorgroup openshift-update-service-fprx2

    Exemple de sortie

    operatorgroup.operators.coreos.com "openshift-update-service-fprx2" deleted

  4. Obtenir le nom de l'abonnement OpenShift Update Service Operator : 

    $ oc get subscription

    Exemple de sortie

    NAME                      PACKAGE                   SOURCE                        CHANNEL
update-service-operator   update-service-operator   updateservice-index-catalog   v1

  5. En utilisant la valeur Name de l'étape précédente, vérifiez la version actuelle de l'OpenShift Update Service Operator souscrit dans le champ currentCSV: 

    $ oc get subscription update-service-operator -o yaml | grep " currentCSV"

    Exemple de sortie

      currentCSV: update-service-operator.v0.0.1

  6. Supprimer l'abonnement, par exemple, update-service-operator: 

    $ oc delete subscription update-service-operator

    Exemple de sortie

    subscription.operators.coreos.com "update-service-operator" deleted

  7. Supprimez le CSV pour l'OpenShift Update Service Operator en utilisant la valeur currentCSV de l'étape précédente : 

    $ oc delete clusterserviceversion update-service-operator.v0.0.1

    Exemple de sortie

    clusterserviceversion.operators.coreos.com "update-service-operator.v0.0.1" deleted

Chapitre 13. Mise à jour du matériel sur les nœuds fonctionnant sous vSphere

Vous devez vous assurer que vos nœuds fonctionnant dans vSphere sont exécutés sur la version matérielle prise en charge par OpenShift Container Platform. Actuellement, la version 13 ou ultérieure du matériel est prise en charge pour les machines virtuelles vSphere dans un cluster.

Vous pouvez mettre à jour votre matériel virtuel immédiatement ou programmer une mise à jour dans vCenter.

13.1. Mise à jour du matériel virtuel sur vSphere

Pour mettre à jour le matériel de vos machines virtuelles (VM) sur VMware vSphere, mettez à jour vos machines virtuelles séparément afin de réduire le risque d'interruption de votre cluster.

13.1.1. Mise à jour du matériel virtuel pour les nœuds du plan de contrôle sur vSphere

Pour réduire le risque de temps d'arrêt, il est recommandé de mettre à jour les nœuds du plan de contrôle en série. Cela permet de s'assurer que l'API Kubernetes reste disponible et que etcd conserve le quorum.

Conditions préalables

  • Vous avez les permissions d'administrateur de cluster pour exécuter les permissions requises dans l'instance vCenter hébergeant votre cluster OpenShift Container Platform.
  • Vos hôtes vSphere ESXi sont en version 6.7U3 ou ultérieure.

Procédure

  1. Dressez la liste des nœuds du plan de contrôle dans votre cluster. 

    $ oc get nodes -l node-role.kubernetes.io/master

    Exemple de sortie

    NAME                    STATUS   ROLES    AGE   VERSION
control-plane-node-0    Ready    master   75m   v1.25.0
control-plane-node-1    Ready    master   75m   v1.25.0
control-plane-node-2    Ready    master   75m   v1.25.0

    Notez les noms des nœuds du plan de contrôle.

  2. Marquer le nœud du plan de contrôle comme non ordonnançable. 

    $ oc adm cordon <control_plane_node>
  3. Arrêtez la machine virtuelle (VM) associée au nœud du plan de contrôle. Pour ce faire, dans le client vSphere, cliquez avec le bouton droit de la souris sur la VM et sélectionnez Power → Shut Down Guest OS. N'arrêtez pas la VM à l'aide de Power Off, car elle pourrait ne pas s'arrêter en toute sécurité.
  4. Mettez à jour la machine virtuelle dans le client vSphere. Pour plus d'informations, consultez la section Mise à jour manuelle de la compatibilité d'une machine virtuelle dans la documentation VMware.
  5. Mettez sous tension la VM associée au nœud du plan de contrôle. Pour ce faire, dans le client vSphere, cliquez avec le bouton droit de la souris sur la VM et sélectionnez Power On.

  6. Attendez que le nœud soit signalé comme étant Ready: 

    oc wait --for=condition=Ready node/<control_plane_node>

  7. Marquer à nouveau le nœud du plan de contrôle comme planifiable : 

    oc adm uncordon <control_plane_node>
  8. Répétez cette procédure pour chaque nœud de plan de contrôle de votre cluster.

13.1.2. Mise à jour du matériel virtuel pour les nœuds de calcul sur vSphere

Pour réduire le risque de temps d'arrêt, il est recommandé de mettre à jour les nœuds de calcul en série.

Note

Plusieurs nœuds de calcul peuvent être mis à jour en parallèle si les charges de travail tolèrent que plusieurs nœuds se trouvent à l'adresse NotReady. Il incombe à l'administrateur de s'assurer que les nœuds de calcul requis sont disponibles.

Conditions préalables

  • Vous avez les permissions d'administrateur de cluster pour exécuter les permissions requises dans l'instance vCenter hébergeant votre cluster OpenShift Container Platform.
  • Vos hôtes vSphere ESXi sont en version 6.7U3 ou ultérieure.

Procédure

  1. Dressez la liste des nœuds de calcul de votre cluster. 

    $ oc get nodes -l node-role.kubernetes.io/worker

    Exemple de sortie

    NAME              STATUS   ROLES    AGE   VERSION
compute-node-0    Ready    worker   30m   v1.25.0
compute-node-1    Ready    worker   30m   v1.25.0
compute-node-2    Ready    worker   30m   v1.25.0

    Notez les noms de vos nœuds de calcul.

  2. Marquer le nœud de calcul comme non ordonnançable : 

    $ oc adm cordon <compute_node>

  3. Évacuer les pods du nœud de calcul. Il y a plusieurs façons de procéder. Par exemple, vous pouvez évacuer tous les pods d'un nœud ou certains d'entre eux : 

    $ oc adm drain <compute_node> [--pod-selector=<pod_selector>]

    Voir la section "Comprendre comment évacuer les pods sur les nœuds" pour connaître les autres options d'évacuation des pods d'un nœud.

  4. Arrêtez la machine virtuelle (VM) associée au nœud de calcul. Pour ce faire, dans le client vSphere, cliquez avec le bouton droit de la souris sur la VM et sélectionnez Power → Shut Down Guest OS. N'arrêtez pas la VM à l'aide de Power Off, car elle pourrait ne pas s'arrêter en toute sécurité.
  5. Mettez à jour la machine virtuelle dans le client vSphere. Pour plus d'informations, consultez la section Mise à jour manuelle de la compatibilité d'une machine virtuelle dans la documentation VMware.
  6. Mettez sous tension la VM associée au nœud de calcul. Pour ce faire, dans le client vSphere, cliquez avec le bouton droit de la souris sur la VM et sélectionnez Power On.

  7. Attendez que le nœud soit signalé comme étant Ready: 

    $ oc wait --for=condition=Ready node/<compute_node>

  8. Marquer à nouveau le nœud de calcul comme planifiable : 

    $ oc adm uncordon <compute_node>
  9. Répétez cette procédure pour chaque nœud de calcul de votre cluster.

13.1.3. Mise à jour du matériel virtuel pour les modèles sur vSphere

Conditions préalables

  • Vous avez les permissions d'administrateur de cluster pour exécuter les permissions requises dans l'instance vCenter hébergeant votre cluster OpenShift Container Platform.
  • Vos hôtes vSphere ESXi sont en version 6.7U3 ou ultérieure.

Procédure

  1. Si le modèle RHCOS est configuré en tant que modèle vSphere, suivez la procédure Convert a Template to a Virtual Machine (Convertir un modèle en machine virtuelle ) dans la documentation VMware avant de passer à l'étape suivante.
Note

Une fois convertie à partir d'un modèle, ne mettez pas la machine virtuelle sous tension.

  1. Mettez à jour la machine virtuelle dans le client vSphere. Pour plus d'informations, consultez la section Mise à jour manuelle de la compatibilité d'une machine virtuelle dans la documentation VMware.
  2. Convertissez la VM dans le client vSphere d'une VM à un modèle. Pour plus d'informations, reportez-vous à la section Convertir une machine virtuelle en modèle dans le client vSphere de la documentation VMware.

Ressources supplémentaires

13.2. Planification d'une mise à jour du matériel virtuel sur vSphere

Les mises à jour du matériel virtuel peuvent être programmées pour se produire lorsqu'une machine virtuelle est mise sous tension ou redémarrée. Vous pouvez planifier vos mises à jour de matériel virtuel exclusivement dans vCenter en suivant la rubrique Planifier une mise à niveau de compatibilité pour une machine virtuelle dans la documentation VMware.

Lorsque vous planifiez une mise à niveau avant d'effectuer une mise à niveau d'OpenShift Container Platform, la mise à jour du matériel virtuel se produit lorsque les nœuds sont redémarrés au cours de la mise à niveau d'OpenShift Container Platform.

Chapitre 14. Validation pré-vol pour les modules de gestion des modules du noyau (KMM)

Avant d'effectuer une mise à niveau sur la grappe avec des modules KMM appliqués, l'administrateur doit vérifier que les modules du noyau installés à l'aide de KMM peuvent être installés sur les nœuds après la mise à niveau de la grappe et l'éventuelle mise à niveau du noyau. Preflight tente de valider chaque site Module chargé dans la grappe, en parallèle. Preflight n'attend pas la fin de la validation d'un Module pour commencer la validation d'un autre Module.

14.1. Coup d'envoi de la validation

La validation Preflight est déclenchée par la création d'une ressource PreflightValidationOCP dans le cluster. Cette spécification contient deux champs : 

type PreflightValidationOCPSpec struct {
	// releaseImage describes the OCP release image that all Modules need to be checked against.
	// +kubebuilder:validation:Required
	ReleaseImage string `json:"releaseImage"` 1
	// Boolean flag that determines whether images build during preflight must also
	// be pushed to a defined repository
	// +optional
	PushBuiltImage bool `json:"pushBuiltImage"` 2
}
1
ReleaseImage - Champ obligatoire qui fournit le nom de l'image de la version d'OpenShift Container Platform vers laquelle le cluster est mis à niveau.
2
PushBuiltImage - Si true, les images créées lors de la validation de la construction et de la signature sont poussées vers leurs référentiels (false par défaut).

14.2. Cycle de vie de la validation

La validation Preflight tente de valider chaque module chargé dans le cluster. Preflight arrête l'exécution de la validation sur une ressource Module une fois que la validation est réussie. Si la validation du module a échoué, vous pouvez modifier les définitions du module et Preflight essaiera de valider à nouveau le module dans la boucle suivante.

Si vous souhaitez exécuter la validation Preflight pour un noyau supplémentaire, vous devez créer une autre ressource PreflightValidationOCP pour ce noyau. Une fois que tous les modules ont été validés, il est recommandé de supprimer la ressource PreflightValidationOCP.

14.3. Statut de validation

Preflight signale l'état et la progression de chaque module de la grappe qu'il tente de valider. 

type CRStatus struct {
	// Status of Module CR verification: true (verified), false (verification failed),
	// error (error during verification process), unknown (verification has not started yet)
	// +required
	// +kubebuilder:validation:Required
	// +kubebuilder:validation:Enum=True;False
	VerificationStatus string `json:"verificationStatus"` 1
	// StatusReason contains a string describing the status source.
	// +optional
	StatusReason string `json:"statusReason,omitempty"` 2
	// Current stage of the verification process:
	// image (image existence verification), build(build process verification)
	// +required
	// +kubebuilder:validation:Required
	// +kubebuilder:validation:Enum=Image;Build;Sign;Requeued;Done
	VerificationStage string `json:"verificationStage"` 3
	// LastTransitionTime is the last time the CR status transitioned from one status to another.
	// This should be when the underlying status changed.  If that is not known, then using the time when the API field changed is acceptable.
	// +required
	// +kubebuilder:validation:Required
	// +kubebuilder:validation:Type=string
	// +kubebuilder:validation:Format=date-time
	LastTransitionTime metav1.Time `json:"lastTransitionTime" protobuf:"bytes,4,opt,name=lastTransitionTime"` 4
}

Les champs suivants s'appliquent à chaque module :

1
VerificationStatus - true ou false, validé ou non.
2
StatusReason - Explication verbale du statut.
3
VerificationStage - Décrit l'étape de validation en cours d'exécution (Image, Construire, Signer).
4
LastTransitionTime - Heure de la dernière mise à jour de l'état.

14.4. Étapes de validation pré-vol par module

Preflight effectue les validations suivantes sur chaque module KMM présent dans le cluster :

  1. Étape de validation de l'image
  2. Étape de validation de la construction
  3. Étape de validation du signe

14.4.1. Étape de validation de l'image

La validation de l'image est toujours la première étape de la validation du contrôle en amont à exécuter. Si la validation de l'image est réussie, aucune autre validation n'est exécutée sur ce module spécifique.

La validation de l'image se fait en deux étapes :

  1. Existence et accessibilité de l'image. Le code tente d'accéder à l'image définie pour le noyau mis à jour dans le module et d'obtenir ses manifestes.
  2. Vérifiez la présence du module du noyau défini dans Module dans le chemin correct pour l'exécution future de modprobe. Le chemin correct est <dirname>/lib/modules/<upgraded_kernel>/.

Si cette validation est réussie, cela signifie probablement que le module du noyau a été compilé avec les bons en-têtes Linux.

14.4.2. Étape de validation de la construction

La validation de la compilation n'est exécutée que lorsque la validation de l'image a échoué et qu'il existe une section build dans le site Module qui est pertinente pour le noyau mis à niveau. La validation de la construction tente d'exécuter la tâche de construction et de valider qu'elle se termine avec succès.

Note

Vous devez spécifier la version du noyau lorsque vous exécutez depmod, comme indiqué ici : 

$ RUN depmod -b /opt ${KERNEL_VERSION}

Si l'indicateur PushBuiltImage est défini dans la ressource personnalisée (CR) PreflightValidationOCP, il essaiera également de pousser l'image résultante dans son référentiel. Le nom de l'image résultante est tiré de la définition du champ containerImage de la CR Module.

Note

Si la section sign est définie pour le noyau mis à niveau, l'image résultante ne sera pas le champ containerImage de la CR Module, mais un nom d'image temporaire, car l'image résultante doit être le produit du flux Sign.

14.4.3. Étape de validation du signe

La validation du signe n'est exécutée que lorsque la validation de l'image a échoué, qu'il existe une section sign dans le site Module qui est pertinente pour le noyau mis à niveau, et que la validation de la construction s'est terminée avec succès dans le cas où il existe une section build dans le site Module qui est pertinente pour le noyau mis à niveau. La validation de signature essaiera d'exécuter le travail de signature et de valider qu'il se termine avec succès.

Si l'indicateur PushBuiltImage est défini dans la CR PreflightValidationOCP, la validation du signe essaiera également de pousser l'image résultante vers son registre.

L'image résultante est toujours l'image définie dans le champ containerImage du formulaire Module. L'image d'entrée est soit la sortie de l'étape Build, soit une image définie dans le champ UnsignedImage.

Note

S'il existe une section build, l'image d'entrée de la section sign est l'image de sortie de la section build. Par conséquent, pour que l'image d'entrée soit disponible pour la section sign, l'indicateur PushBuiltImage doit être défini dans le CR PreflightValidationOCP.

14.5. Exemple de ressource PreflightValidationOCP

Cette section présente un exemple de la ressource PreflightValidationOCP au format YAML.

L'exemple vérifie tous les modules actuellement présents par rapport à la prochaine version du noyau incluse dans la version 4.11.18 d'OpenShift Container Platform, vers laquelle pointe l'image de version suivante : 

quay.io/openshift-release-dev/ocp-release@sha256:22e149142517dfccb47be828f012659b1ccf71d26620e6f62468c264a7ce7863

Parce que .spec.pushBuiltImage est défini sur true, KMM pousse les images résultantes de Build/Sign dans les dépôts définis. 

apiVersion: kmm.sigs.x-k8s.io/v1beta1
kind: PreflightValidationOCP
metadata:
 name: preflight
spec:
 releaseImage: quay.io/openshift-release-dev/ocp-release@sha256:22e149142517dfccb47be828f012659b1ccf71d26620e6f62468c264a7ce7863
 pushBuiltImage: true

Legal Notice

Copyright © 2024 Red Hat, Inc.

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered 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 and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. 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 an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.