Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

2.2. Amélioration d’un cluster ROSA Classic

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=<nom du cluster|cluster_id>.

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.

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