Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

La mise à niveau

Red Hat OpenShift Service on AWS 4

Comprendre les options de mise à niveau pour Red Hat OpenShift Service sur AWS

Red Hat OpenShift Documentation Team

Résumé

Ce document fournit des informations sur la mise à niveau de Red Hat OpenShift Service sur les clusters AWS (ROSA).

Chapitre 1. Amélioration de ROSA avec des clusters HCP
Copier lien

1.1. Améliorer les options pour ROSA avec les clusters HCP
Copier lien

Dans OpenShift, mettre à niveau signifie fournir un nouveau composant avec un logiciel mis à jour et l’utiliser pour remplacer un composant existant qui a un logiciel obsolète.

Il est possible de contrôler l’impact des mises à niveau sur votre charge de travail en contrôlant les parties du cluster mises à niveau, par exemple:

Améliorer uniquement l’avion de contrôle hébergé
Cela initie la mise à niveau de l’avion de contrôle hébergé. Cela n’a pas d’impact sur vos nœuds ouvriers.
Améliorer les nœuds dans une piscine de machines
Cela initie un remplacement par laminage des nœuds dans le pool de machines spécifié, et affecte temporairement les nœuds du travailleur sur ce pool de machines. Il est également possible de mettre à niveau plusieurs pools de machines simultanément.
Important

Il est impossible de mettre à niveau le plan de contrôle hébergé en même temps qu’une mise à niveau du pool de machines.

Important

Afin de maintenir la compatibilité entre les nœuds du cluster, les nœuds dans les pools de machines ne peuvent pas utiliser une version plus récente que le plan de contrôle hébergé. Cela signifie que le plan de contrôle hébergé doit toujours être mis à niveau vers une version donnée avant que tous les pools de machines ne soient mis à niveau vers la même version.

En outre, vous pouvez contrôler le temps nécessaire à la mise à niveau d’un pool de machines et l’impact d’une mise à niveau sur votre charge de travail, en modifiant les valeurs --max-surge et --max-disponibles pour chaque pool de machines. Ces options contrôlent le nombre de nœuds qui peuvent être mis à niveau simultanément sur un pool de machines, et si une mise à niveau prévoit des nœuds excédentaires ou rend certains nœuds existants indisponibles ou les deux, par exemple:

  • Afin de prioriser la disponibilité de la charge de travail élevée, vous pouvez fournir des nœuds excédentaires au lieu de rendre les nœuds existants indisponibles en définissant une valeur plus élevée pour --max-surge et --max-indisponible à 0.
  • Afin de prioriser les coûts d’infrastructure plus bas, vous pouvez rendre certains nœuds existants indisponibles et éviter de provisionner les nœuds excédentaires en définissant une valeur plus élevée pour --max-indisponible et --max-surge à 0.
  • Afin de prioriser la vitesse de mise à niveau en mettant à niveau simultanément plusieurs nœuds, vous pouvez fournir des nœuds excédentaires et permettre à certains nœuds existants d’être rendus indisponibles en configurant des valeurs modérées pour --max-surge et --max-indisponible.

Consultez la référence ROSA CLI pour le pool de machines d’édition rosa pour plus d’informations sur ces paramètres et leur utilisation.

Ressources supplémentaires

1.2. Les politiques et la planification du cycle de vie
Copier lien

Afin de planifier une mise à niveau, passez en revue le service Red Hat OpenShift sur le cycle de vie de la mise à jour AWS.

La page du cycle de vie comprend les définitions de la version, les exigences de support et de mise à niveau, les informations sur la politique d’installation et les dates du cycle de vie.

Les mises à niveau sont initiées manuellement ou programmées automatiquement. Les ingénieurs de fiabilité du site Red Hat (SRE) surveillent les progrès de la mise à niveau et corrigent les problèmes rencontrés.

Note

Lorsque votre plan de contrôle n’est pas actuellement activé en multi-architecture, le processus de mise à niveau migrera d’abord le cluster vers une image multiarchitecture, puis appliquera la mise à niveau de la version. Les clusters multi-architecture sont capables d’exécuter des charges de travail basées sur x86 et Arm. Les clusters créés après le 25 juillet 2024 sont multi-architecture activés par défaut.

Il est possible de mettre à niveau manuellement le plan de contrôle hébergé d’un ROSA avec le cluster HCP à l’aide du ROSA CLI. Cette méthode programme le plan de contrôle pour une mise à niveau si une version plus récente est disponible, soit immédiatement, soit à un moment futur spécifié.

Note

Le plan de contrôle ne prend en charge que les pools de machines dans deux versions mineures de Y-stream. À titre d’exemple, un ROSA avec cluster HCP avec plan de contrôle utilisant la version 4.15.z prend en charge les pools de machines avec les versions 4.13.z et 4.14.z, mais le plan de contrôle ne prend pas en charge les pools de machines en utilisant la version 4.12.z.

Conditions préalables

  • La dernière version de la ROSA CLI a été installée et configurée.
  • Aucune mise à niveau de pool de machines n’est en cours ou prévue pour avoir lieu en même temps que la mise à niveau du plan de contrôle hébergé.

Procédure

  1. Contrôlez la version actuelle de votre cluster en exécutant la commande suivante: 

    $ rosa describe cluster --cluster=<cluster_name_or_id>
    1
    Copy to Clipboard Toggle word wrap
    1
    &lt;cluster_name_or_id&gt; par le nom du cluster ou l’ID du cluster.

  2. Énumérez les versions vers lesquelles vous pouvez mettre à niveau votre plan de contrôle en exécutant la commande suivante: 

    $ rosa list upgrade --cluster=<cluster_name_or_id>
    Copy to Clipboard Toggle word wrap

    La commande renvoie une liste de mises à jour disponibles, y compris la version recommandée.

    Exemple de sortie

    VERSION  NOTES
4.14.8   recommended
4.14.7
4.14.6
    Copy to Clipboard Toggle word wrap

  3. Améliorez le plan de contrôle hébergé du cluster en exécutant la commande suivante: 

    $ rosa upgrade cluster -c <cluster_name_or_id> --control-plane [--schedule-date=<yyyy-mm-dd> --schedule-time=<HH:mm>] --version <version_number>
    Copy to Clipboard Toggle word wrap

    • Afin de programmer une mise à niveau immédiate vers la version spécifiée, exécutez la commande suivante: 

      $ rosa upgrade cluster -c <cluster_name_or_id> --control-plane --version <version_number>
      Copy to Clipboard Toggle word wrap

      L’avion de contrôle hébergé est programmé pour une mise à niveau immédiate.

    • Afin de programmer une mise à niveau vers la version spécifiée à une date ultérieure, exécutez la commande suivante: 

      $ rosa upgrade cluster -c <cluster_name_or_id> --control-plane --schedule-date=<yyyy-mm-dd> --schedule-time=<HH:mm> --version=<version_number>
      Copy to Clipboard Toggle word wrap

      Le plan de contrôle hébergé est prévu pour une mise à niveau à l’heure spécifiée dans le Temps Universel Coordonné (UTC).

Résolution de problèmes

  • Il arrive qu’une mise à niveau programmée ne démarre pas. Consultez Mise à niveau de maintenance annulée pour plus d’informations.

1.4. Amélioration des pools de machines avec le ROSA CLI
Copier lien

Il est possible de mettre à niveau manuellement un ou plusieurs pools de machines dans un ROSA avec le cluster HCP en utilisant le ROSA CLI. Cette méthode programme le pool de machines spécifié pour une mise à niveau si une version plus récente est disponible, soit immédiatement, soit à un moment futur spécifié.

Note

Le plan de contrôle ne prend en charge que les pools de machines dans deux versions mineures de Y-stream. À titre d’exemple, un ROSA avec cluster HCP avec plan de contrôle utilisant la version 4.15.z prend en charge les pools de machines avec les versions 4.13.z et 4.14.z, mais le plan de contrôle ne prend pas en charge les pools de machines en utilisant la version 4.12.z.

Conditions préalables

  • La dernière version de la ROSA CLI a été installée et configurée.
  • Aucune mise à niveau pour le plan de contrôle hébergé n’est en cours sur le cluster, ou devrait se produire en même temps que la mise à niveau du pool de machines.
Note

Les configurations de pool de machines telles que le temps de vidange des nœuds, max-indisponible et max-surge peuvent affecter le timing et le succès des mises à niveau.

Procédure

  1. Contrôlez la version actuelle de votre cluster en exécutant la commande suivante: 

    $ rosa describe cluster --cluster=<cluster_name_or_id>
    1
    Copy to Clipboard Toggle word wrap
    1
    &lt;cluster_name_or_id&gt; par le nom du cluster ou l’ID du cluster.

    Exemple de sortie

    OpenShift Version:     4.14.0
    Copy to Clipboard Toggle word wrap

  2. Énumérez les versions vers lesquelles vous pouvez mettre à niveau vos pools de machines en exécutant la commande suivante: 

    $ rosa list upgrade --cluster <cluster-name> --machinepool <machinepool_name>
    Copy to Clipboard Toggle word wrap

    La commande renvoie une liste de mises à jour disponibles, y compris la version recommandée.

    Exemple de sortie

    VERSION  NOTES
4.14.5   recommended
4.14.4
4.14.3
    Copy to Clipboard Toggle word wrap

    Important

    Il ne faut pas mettre à niveau votre pool de machines vers une version supérieure à celle de votre plan de contrôle. Lorsque vous souhaitez passer à une version supérieure, mettez à niveau d’abord le plan de contrôle vers cette version.

  3. Contrôlez le comportement de mise à niveau des pools de machines que vous avez l’intention de mettre à niveau en exécutant la commande suivante: 

    $ rosa describe machinepool --cluster=<cluster_name_or_id> <machinepool_name>
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    Replicas: 5
Node drain grace period:   30 minutes

Management upgrade:
- Type: Replace
- Max surge: 20%
- Max unavailable: 20%
    Copy to Clipboard Toggle word wrap

    Dans l’exemple, ces paramètres permettent au pool de machine de fournir un nœud excédentaire (max-surge de 20% des répliques) et d’avoir jusqu’à un nœud indisponible (max-indisponible de 20% des répliques) lors d’une mise à niveau. Ce pool de machines peut donc mettre à niveau deux nœuds à la fois, en approvisionnant un nouveau nœud au-delà du nombre de répliques, et en rendant un nœud indisponible et en le remplaçant. Les mises à niveau des nœuds peuvent être retardées jusqu’à 30 minutes (période de 30 minutes) si nécessaire pour protéger les charges de travail qui ont un budget de perturbation de pod.

  4. Améliorez un pool de machines en exécutant la commande suivante: 

    $ rosa upgrade machinepool -c <cluster_name> <machinepool_name> [--schedule-date=<yyyy-mm-dd> --schedule-time=<HH:mm>] --version <version_number>
    Copy to Clipboard Toggle word wrap

    En même temps, vous pouvez mettre à niveau plusieurs pools de machines en exécutant cette commande pour chaque pool de machines que vous souhaitez mettre à niveau.

    • Afin de programmer la mise à niveau immédiate d’un pool de machines, exécutez la commande suivante: 

      $ rosa upgrade machinepool -c <cluster_name> <machinepool_name> --version <version_number>
      Copy to Clipboard Toggle word wrap

      Le pool de machines est prévu pour une mise à niveau immédiate, ce qui déclenche un remplacement roulant de tous les nœuds dans le pool de machines spécifié.

    • Afin de planifier une mise à niveau pour démarrer à un moment futur, exécutez la commande suivante: 

      $ rosa upgrade machinepool -c <cluster_name> <machinepool_name> --schedule-date=<yyyy-mm-dd> --schedule-time=<HH:mm> --version <version_number>
      Copy to Clipboard Toggle word wrap

      Le pool de machines devrait commencer une mise à niveau à l’heure et à la date spécifiées dans le Temps Universel Coordonné (UTC). Cela initiera un remplacement par laminage de tous les nœuds dans le pool de machines spécifié, à partir du moment spécifié.

B) Utilisez l’une des méthodes suivantes pour mettre à niveau les clusters ROSA (architecture classique):

  • Démarrez une mise à jour immédiate unique ou planifiez une mise à niveau unique pour une date ou une heure ultérieures.
  • Démarrez une mise à jour immédiate unique ou planifiez une mise à niveau unique pour une date ou une heure ultérieures; ou programmez une fenêtre de mise à niveau automatique pour les mises à niveau récurrentes automatiques chaque fois qu’une nouvelle version z est disponible.

2.1. Les politiques et la planification du cycle de vie
Copier lien

Afin de planifier une mise à niveau, passez en revue le service Red Hat OpenShift sur le cycle de vie de la mise à jour AWS. La page du cycle de vie comprend les définitions de la version, les exigences de support et de mise à niveau, les informations sur la politique d’installation et les dates du cycle de vie.

Les canaux de mise à jour vous permettent de choisir la version mineure Red Hat OpenShift Container Platform pour mettre à jour vos clusters. Le Red Hat OpenShift Service sur AWS prend en charge les mises à jour uniquement via le canal stable. Afin d’en savoir plus sur les canaux de mise à jour et les versions d’OpenShift, consultez Comprendre les canaux de mise à jour et les versions.

2.2. Amélioration d’un cluster ROSA Classic
Copier lien

Il faut mettre à niveau les clusters ROSA (architecture classique) à l’aide de la console ROSA CLI (rosa) ou OpenShift Cluster Manager.

Note

L’heure de démarrage réelle de la mise à niveau du cluster sera d’une heure à compter du calendrier de mise à niveau. De plus, la durée de la mise à jour peut varier en fonction de votre configuration de charge de travail.

Lorsqu’un cluster ROSA (architecture classique) qui utilise AWS Security Token Services (STS) est mis à niveau, le ROSA CLI vérifie les stratégies de compte et de rôle de l’opérateur pour le cluster choisi sont compatibles avec la version cible de la mise à niveau. Lorsque les stratégies sont compatibles, le CLI met automatiquement à niveau le cluster. Lorsque les stratégies ne sont pas compatibles avec la version de mise à niveau choisie, le CLI met automatiquement à niveau les stratégies IAM avant de mettre à niveau le cluster. Lors de la planification de la mise à niveau, vous donnez une reconnaissance administrative pour confirmer que vous avez examiné les changements impliqués dans la mise à niveau, si nécessaire.

Les mises à niveau sont initiées manuellement (une seule fois) ou programmées automatiquement (récurrence). Les ingénieurs de fiabilité du site Red Hat (SRE) surveillent les progrès de la mise à niveau et vous avisent de prendre des mesures correctives ou de remédier aux problèmes rencontrés.

L’opérateur de versions de cluster (CVO) est le composant principal qui orchestre et facilite le processus de mise à jour OpenShift Container Platform.

L’opérateur de mise à niveau géré (MUO) gère la planification, la surveillance et les notifications des mises à niveau de cluster ROSA (architecture classique). Le MUO orchestre les mises à niveau automatisées des clusters en s’assurant que les conditions de fonctionnement sont remplies avant et après la mise à niveau d’un cluster géré.

2.2.1.1. La mise à niveau du cluster est programmée
Copier lien

Il est possible de programmer des mises à niveau de cluster en définissant l’heure prévue. C’est à ce moment-là que la préparation de la mise à niveau du cluster commence par des contrôles de santé préalables et la création de capacités de calcul supplémentaires. La mise à niveau réelle du cluster commence dans une heure à compter de l’heure prévue. Lorsque la mise à niveau du cluster démarre, vous recevez une notification par e-mail.

Le contrôle présanté (PHC) offre une protection supplémentaire pour s’assurer que la mise à jour prévue se déroule comme prévu et s’exécute dans les deux scénarios suivants:

  • Lorsqu’une mise à niveau est prévue plus de 2 heures à compter de l’heure actuelle, le SSP s’exécute et l’utilisateur est avisé en cas de défaillance. Ce CSP est dans la nouvelle phase de la mise à niveau.
  • Lorsque la mise à niveau est immédiate ou dans les 2 heures, le CSP s’exécute juste avant le début de la mise à niveau. Ce CSP est en phase d’amélioration de la mise à niveau. Cela signifie que PHC est toujours exécuté au moins une fois pendant la phase de mise à niveau, mais peut également être exécuté à l’avance si la mise à niveau est prévue plus de 2 heures à partir de l’heure actuelle.

Dans la commande ROSA CLI (rosa), vous pouvez observer l’état de la mise à niveau du cluster en exécutant la mise à niveau --cluster=&lt;nom du cluster|cluster_id&gt;.

Les étapes de haut niveau qui se produisent lors de la mise à jour du cluster ROSA (architecture classique) sont les suivantes:

  1. La planification de la mise à niveau à l’avance déclenche le PreHealthCheck et informe les utilisateurs de toute défaillance qu’ils peuvent ensuite résoudre avant le début de la mise à niveau.

  2. Avant le début de la mise à niveau du cluster, un examen de santé du cluster est effectué par le MUO. Lorsque le MUO identifie un problème qui nécessite des mesures correctives, vous en serez avisé. Certains exemples des contrôles de santé en grappes effectués par MUO comprennent:

    • Identifier les budgets de perturbation de Pod (PDB) qui peuvent potentiellement bloquer ou retarder la mise à jour des nœuds.
    • Assurer la disponibilité et la santé des opérateurs de grappes.
    • Faire en sorte que les alertes critiques des clusters ne tirent pas.

  3. Dans le cluster, un nœud de calcul temporaire est créé pour permettre la planification des gousses drainées pendant la mise à jour.

    Note

    La création temporaire de nœuds de calcul ne se produit pas toujours. À titre d’exemple, s’il n’y a pas de pool de machine ouvrier, le nœud de calcul temporaire ne sera pas créé. Cela peut se produire lorsqu’un administrateur de cluster supprime le pool de machines de travail existant et crée un autre pool de machines de travail avec un nom ou un type d’instance différent.

  4. La version cluster est définie sur la version cible.

    Note

    Dans certaines situations, un chemin de mise à niveau peut devenir indisponible depuis le moment où la mise à jour du cluster a été demandée, mais avant qu’elle ne soit terminée. Dans de tels cas, la mise à niveau est automatiquement annulée et une notification est envoyée. Il faut choisir une autre version cible pour demander la mise à niveau.

  5. Au cours de la mise à niveau, les composants du plan de contrôle sont mis à jour vers la nouvelle version.
  6. Ensuite, les opérateurs de clusters individuels effectuent des tâches de mise à jour sur leur domaine du cluster.

  7. Enfin, l’AGC met à jour la configuration du système et le système d’exploitation de chaque nœud. Au cours de cette étape, chaque nœud est redémarré après avoir vidé avec succès les charges de travail exécutées sur le nœud.

    1. Lors de la mise à jour de chaque nœud, les charges de travail sont épuisées, honorant les PDB. Les charges de travail avec des PDB qui ne permettent pas les perturbations bloquent essentiellement le drainage du nœud, ce qui augmente le temps écoulé pour la mise à jour du cluster.
    2. Lors de la mise à jour de chaque nœud dans le cluster, la mise à jour du cluster attend jusqu’à l’heure spécifiée par la période de grâce de drain du nœud pour permettre de drainer en toute sécurité les charges de travail. En atteignant la période de grâce de drain du nœud, le nœud est vidé de force pour permettre à la mise à niveau du cluster de progresser. Avant d’initier la mise à niveau, vous ne pouvez pas configurer la période de grâce de drain du nœud et vous ne pouvez pas la modifier après le début de la mise à niveau du cluster.
    3. Lorsque les nœuds de cluster sont mis à jour, l’AGC sélectionne un nœud à la fois par pool de configuration de machine en fonction de leur âge, en commençant par le plus ancien.

2.2.2. Amélioration avec le ROSA CLI
Copier lien

Il est possible d’utiliser le ROSA CLI (rosa) pour mettre à niveau un cluster Red Hat OpenShift Service sur AWS (ROSA) immédiatement dans une heure ou à l’avenir.

Conditions préalables

  • L’installation et la configuration du dernier CLI ROSA sur votre hôte d’installation.
  • Le service OpenShift de Red Hat sur AWS est dans un état prêt.

Procédure

  1. Afin de vérifier la version actuelle de votre cluster, entrez la commande suivante: 

    $ rosa describe cluster --cluster=<cluster_name|cluster_id>
    1
    Copy to Clipboard Toggle word wrap
    1
    &lt;cluster_name|cluster_id&gt; par le nom du cluster ou l’ID du cluster.

  2. Afin de vérifier qu’une mise à niveau est disponible, entrez la commande suivante: 

    $ rosa list upgrade --cluster=<cluster_name|cluster_id>
    Copy to Clipboard Toggle word wrap

    La commande renvoie une liste de versions vers lesquelles le cluster peut être mis à niveau, y compris une version recommandée. La recommandation est basée sur les risques de mise à jour conditionnelle. Chaque risque connu peut s’appliquer à tous les clusters ou seuls clusters correspondant à certaines conditions. Consultez les notes de sortie OpenShift pour évaluer, valider et déterminer la version appropriée à mettre à niveau.

  3. Afin de mettre à niveau le cluster vers une version spécifiée immédiatement dans l’heure suivante, entrez la commande suivante: 

    $ rosa upgrade cluster --cluster=<cluster_name|cluster_id> --version <version-id>
    Copy to Clipboard Toggle word wrap
    Note

    Lorsque vous mettez à niveau un cluster AWS Security Token Service (STS), cette commande démarre un processus interactif de mise à niveau des rôles/politiques IAM qui vérifie les stratégies de compte et de rôle de l’opérateur pour le cluster choisi sont compatibles avec la version cible de la mise à niveau. Lorsque les stratégies ne sont pas compatibles avec la version de mise à niveau choisie, le CLI les met automatiquement à niveau en mode automatique.

    Le cluster est prévu pour une mise à niveau immédiate comme indiqué par l’heure prévue. La mise à niveau commencera dans une heure à compter de l’heure prévue.

  4. Alternativement, pour mettre à niveau le cluster à une heure ultérieure en UTC, entrez la commande suivante: 

    $ rosa upgrade cluster --cluster=<cluster_name|cluster_id>   \
          --version <version-id>   \
          --schedule-date yyyy-mm-dd \
          --schedule-time HH:mm
    Copy to Clipboard Toggle word wrap

  5. Afin de personnaliser le délai de grâce pour chaque nœud à vider pendant la mise à niveau du cluster, entrez la commande suivante: 

    $ rosa upgrade cluster --cluster=<cluster_name|cluster_id>   \
          --version <version-id>   \
          --node-drain-grace-period 15 minutes
    Copy to Clipboard Toggle word wrap

  6. En entrant la commande suivante, vous pouvez afficher l’état de la mise à niveau, qui affiche à la fois l’état (programmé ou démarré) et l’heure prévue. 

    $ rosa list upgrade --cluster=<cluster_name|cluster_id>
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    VERSION  NOTES
4.15.14  recommended - scheduled for 2024-06-02 15:00 UTC
4.15.13
    Copy to Clipboard Toggle word wrap

Des notifications par e-mail vous confirmeront la planification, le début et l’achèvement de la mise à niveau du cluster.

Résolution de problèmes

  • Il arrive qu’une mise à niveau programmée ne déclenche pas. Consultez Mise à niveau de maintenance annulée pour plus d’informations.

Il est possible d’utiliser la console ROSA CLI (rosa) ou OpenShift Cluster Manager pour supprimer une mise à niveau programmée. Cette procédure utilise le ROSA CLI.

Procédure

  1. La mise à jour du cluster n’a pas commencé à utiliser la commande suivante: 

    $ rosa list upgrades --cluster=<cluster_name|cluster_id>
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    VERSION  NOTES
4.15.14  recommended - scheduled for 2024-06-02 15:00 UTC
4.15.13
    Copy to Clipboard Toggle word wrap

  2. Effacer une mise à jour planifiée en exécutant la commande suivante: 

    $ rosa delete upgrade --cluster=<cluster_name|cluster_id>
    Copy to Clipboard Toggle word wrap

  3. Confirmez la suppression en saisissant Oui à l’invite de confirmation.

    Exemple de sortie

    I: Successfully canceled scheduled upgrade on cluster 'my-cluster'
    Copy to Clipboard Toggle word wrap

Il vous sera envoyé une notification par e-mail confirmant que la mise à niveau prévue a été annulée.

2.2.4. Amélioration avec la console OpenShift Cluster Manager
Copier lien

En utilisant la console OpenShift Cluster Manager, vous pouvez planifier manuellement les mises à niveau d’un cluster ROSA manuellement, soit une fois, soit sur un calendrier récurrent.

Procédure

  1. Connectez-vous à OpenShift Cluster Manager.
  2. Choisissez un cluster à mettre à niveau.
  3. Cliquez sur l’onglet Paramètres.

  4. Dans le volet Stratégie de mise à jour, sélectionnez le type de mise à jour que vous souhaitez:

    • Dans le cas de mises à jour individuelles, vous pouvez demander la mise à jour immédiatement (pour commencer dans une heure) ou à un moment ultérieur.

    • Dans le cas des mises à jour récurrentes, sélectionnez une date et une heure récurrentes pour démarrer automatiquement la mise à jour vers la dernière version x.y.Z (z-stream) disponible.

      Important

      Les mises à jour récurrentes ne s’appliquent qu’aux mises à jour z-stream. Les mises à jour mineures de version ou de flux y doivent être effectuées manuellement. Il vous sera notifié lorsqu’une nouvelle mise à jour y-stream sera disponible.

  5. Facultatif: Dans le volet drainant le nœud, sélectionnez un intervalle de délai de grâce de la liste. Le délai de grâce permet aux nœuds de drainer gracieusement avant de forcer l’expulsion de la gousse. La valeur par défaut est de 1 heure.

    Important

    Après le début du processus de mise à niveau, vous ne pouvez pas modifier le délai de grâce de drain du nœud.

  6. Dans le volet Stratégie de mise à jour, cliquez sur Enregistrer pour appliquer votre stratégie de mise à jour.

  7. Dans le volet État de mise à jour, examinez l’information disponible et cliquez sur Mise à jour.

    Note

    Le bouton Mise à jour n’est activé que lorsqu’une mise à jour est disponible.

  8. La boîte de dialogue Mise à jour du cluster s’ouvre. Les mises à niveau de cluster recommandées apparaissent dans le volet Sélectionner la version. Choisissez la version à laquelle vous souhaitez mettre à niveau votre cluster, puis cliquez sur Suivant.

  9. Facultatif: Pour les clusters ROSA qui utilisent AWS Security Token Service (STS), les rôles de l’opérateur au niveau du compte et du cluster peuvent devoir être mis à jour, en fonction de la version cible sélectionnée.

    1. Dans le ROSA CLI, exécutez la commande rosa list-roles pour répertorier et vérifier que les rôles de compte sont compatibles avec la version mineure cible choisie pour la mise à niveau. Dans le cas où les rôles ne sont pas compatibles, exécutez la commande rosa des rôles de compte pour mettre à niveau les rôles de compte vers la dernière version d’OpenShift.
    2. Dans le ROSA CLI, exécutez la commande opérateur-rôles rosa pour répertorier et vérifier que les rôles d’opérateur associés au cluster sont compatibles avec la version mineure cible choisie pour la mise à niveau. Dans le cas contraire, exécutez la commande des opérateurs de mise à niveau rosa pour mettre à niveau les rôles de l’opérateur du cluster vers la dernière version OpenShift.
    3. Lorsque vous sélectionnez une version de mise à jour qui nécessite l’approbation, fournissez la reconnaissance d’un administrateur en tapant Acknowledge dans le champ fourni, et cliquez sur Suivant.

  10. Dans la boîte de dialogue Planifier la mise à jour, programmez la mise à niveau de votre cluster.

    • Afin de mettre à niveau en moins d’une heure, sélectionnez Mise à jour maintenant et cliquez sur Suivant.
    • Afin de mettre à niveau ultérieurement, sélectionnez Planifier une heure différente et définissez une heure et une date pour votre mise à niveau. Cliquez sur Suivant pour passer à la boîte de dialogue de confirmation.
  11. Après avoir examiné la version et le résumé du calendrier, sélectionnez Confirmer la mise à jour.
  12. Cliquez sur Fermer pour sortir de la boîte de dialogue Mise à jour du cluster.

Le cluster est prévu pour une mise à niveau vers la version cible. Cette action peut prendre jusqu’à une heure, en fonction du calendrier de mise à niveau sélectionné et de votre configuration de charge de travail, telles que les budgets de perturbation des pod.

L’état s’affiche dans le volet État de mise à jour.

Résolution de problèmes

  • Il arrive qu’une mise à niveau programmée ne déclenche pas. Consultez Mise à niveau de maintenance annulée pour plus d’informations.

La console OpenShift Cluster Manager vous permet de supprimer une mise à niveau programmée.

Procédure

  1. Connectez-vous à OpenShift Cluster Manager.
  2. Choisissez le cluster avec la mise à niveau prévue.
  3. Cliquez sur l’onglet Paramètres.
  4. Dans le volet État de mise à jour, cliquez sur Annuler cette mise à jour.
  5. Consultez les détails de la mise à jour dans la boîte de dialogue Annuler la mise à jour et cliquez sur Annuler cette mise à jour.

Il vous sera envoyé une notification par e-mail confirmant que la mise à niveau prévue a été annulée.

Legal Notice
Copier lien

Copyright © 2025 Red Hat

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.

Retour au début
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. Découvrez nos récentes mises à jour.

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 le Blog 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.

Theme

© 2025 Red Hat