Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

Le soutien

Red Hat OpenShift Service on AWS 4

Le service Red Hat OpenShift sur AWS Support.

Red Hat OpenShift Documentation Team

Résumé

Fournit des outils d’administrateurs de clusters pour collecter des données pour votre cluster, la surveillance et le dépannage.

Chapitre 1. Aperçu du support
Copier lien

Le Red Hat offre aux administrateurs de cluster des outils de collecte de données pour votre cluster, la surveillance et le dépannage.

1.1. Bénéficiez d’un soutien
Copier lien

Bénéficiez d’un soutien : visitez le portail client Red Hat pour examiner les articles de base de connaissances, soumettre un dossier d’assistance et examiner la documentation et les ressources supplémentaires sur les produits.

1.2. Les problèmes de surveillance sanitaire à distance
Copier lien

Les problèmes de surveillance de la santé à distance: Red Hat OpenShift Service sur AWS collecte les données de télémétrie et de configuration de votre cluster et les signale à Red Hat en utilisant le client télémètre et l’opérateur Insights. Le Red Hat utilise ces données pour comprendre et résoudre les problèmes dans le cluster connecté. Le service Red Hat OpenShift sur AWS collecte des données et surveille la santé en utilisant les éléments suivants:

  • Le client télémétrie rassemble et télécharge les valeurs métriques sur Red Hat toutes les quatre minutes et trente secondes. Le Red Hat utilise ces données pour:

    • Contrôlez les clusters.
    • Déployer Red Hat OpenShift Service sur les mises à jour AWS.
    • Améliorez l’expérience de mise à niveau.

  • Insight Operator: Par défaut, Red Hat OpenShift Service sur AWS installe et active l’opérateur Insight, qui signale l’état de la configuration et de la défaillance des composants toutes les deux heures. L’opérateur Insight aide à:

    • Identifier les problèmes potentiels des clusters de manière proactive.
    • Fournir une solution et une action préventive dans Red Hat OpenShift Cluster Manager.

Il est possible d’examiner les informations de télémétrie.

Lorsque vous avez activé des rapports sur la santé à distance, utilisez Insights pour identifier les problèmes. En option, vous pouvez désactiver les rapports de santé à distance.

1.3. Collectez des données sur votre cluster
Copier lien

Collectez des données sur votre cluster : Red Hat recommande de recueillir vos informations de débogage lors de l’ouverture d’un dossier de support. Cela aide Red Hat Support à effectuer une analyse des causes profondes. L’administrateur de cluster peut utiliser ce qui suit pour recueillir des données sur votre cluster:

  • L’outil must-collectther : Utilisez l’outil must-collectther pour collecter des informations sur votre cluster et pour déboguer les problèmes.
  • Sosreport: Utilisez l’outil sosreport pour collecter les détails de configuration, les informations système et les données de diagnostic à des fins de débogage.
  • ID cluster: Obtenez l’identifiant unique pour votre cluster, lorsque vous fournissez des informations à Red Hat Support.
  • Journaux de journal de nœuds de cluster: Rassemblez des journaux d’unités journalisées et des journaux dans /var/log sur des nœuds de cluster individuels pour résoudre les problèmes liés au nœud.
  • Fournir une trace de paquet réseau à partir d’un service Red Hat OpenShift spécifique sur le nœud de cluster AWS ou un conteneur à Red Hat Support pour aider à résoudre les problèmes liés au réseau.

1.4. Dépannage des problèmes
Copier lien

L’administrateur de cluster peut surveiller et résoudre le service Red Hat OpenShift suivant sur les problèmes de composants AWS:

  • Les problèmes liés aux nœuds : Un administrateur de cluster peut vérifier et résoudre les problèmes liés aux nœuds en examinant l’état, l’utilisation des ressources et la configuration d’un nœud. Demandez ce qui suit:

    • Le statut de Kubelet sur un nœud.
    • Journaux de journal des nœuds de cluster.

  • Les problèmes de l’opérateur : Un administrateur de cluster peut faire ce qui suit pour résoudre les problèmes de l’opérateur:

    • Contrôlez l’état de l’abonnement de l’opérateur.
    • Contrôlez la santé de la pod de l’opérateur.
    • Collectez les journaux de l’opérateur.

  • Les problèmes de pod: Un administrateur de cluster peut résoudre les problèmes liés aux pod en examinant l’état d’une pod et en complétant les éléments suivants:

    • Examinez les journaux des pod et des conteneurs.
    • Démarrez les gousses de débogage avec l’accès root.

  • Les problèmes de source à image : Un administrateur de cluster peut observer les étapes S2I pour déterminer où dans le processus S2I une défaillance s’est produite. Collectez les éléments suivants pour résoudre les problèmes de Source-à-Image (S2I):

    • Données de diagnostic source à image.
    • Données diagnostiques d’application pour enquêter sur l’échec de l’application.

  • Les problèmes de stockage: Une erreur de stockage multi-attache se produit lorsque le volume de montage sur un nouveau nœud n’est pas possible parce que le nœud raté ne peut pas démonter le volume attaché. L’administrateur de cluster peut faire ce qui suit pour résoudre les problèmes de stockage multi-attachés:

    • Activer plusieurs pièces jointes en utilisant des volumes RWX.
    • Récupérer ou supprimer le nœud échoué lors de l’utilisation d’un volume RWO.

  • Les problèmes de surveillance : Un administrateur de cluster peut suivre les procédures sur la page de dépannage pour la surveillance. Lorsque les métriques de vos projets définis par l’utilisateur ne sont pas disponibles ou si Prometheus consomme beaucoup d’espace disque, vérifiez ce qui suit:

    • Examinez pourquoi les métriques définies par l’utilisateur ne sont pas disponibles.
    • Déterminez pourquoi Prometheus consomme beaucoup d’espace disque.
  • Les questions d’OpenShift CLI (oc) : enquêtez sur les problèmes d’OpenShift CLI (oc) en augmentant le niveau de journal.

Chapitre 2. Gestion de vos ressources de cluster
Copier lien

Il est possible d’appliquer des options de configuration globales dans Red Hat OpenShift Service sur AWS. Les opérateurs appliquent ces paramètres de configuration à travers le cluster.

2.1. Interagir avec vos ressources de cluster
Copier lien

Il est possible d’interagir avec les ressources du cluster en utilisant l’outil OpenShift CLI (oc) dans Red Hat OpenShift Service sur AWS. Les ressources de cluster que vous voyez après l’exécution de la commande oc api-ressources peuvent être modifiées.

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle d’administrateur dédié.
  • Accès à la console web ou vous avez installé l’outil oc CLI.

Procédure

  1. Afin de voir quels opérateurs de configuration ont été appliqués, exécutez la commande suivante: 

    $ oc api-resources -o name | grep config.openshift.io
    Copy to Clipboard Toggle word wrap

  2. Afin de voir quelles ressources de cluster vous pouvez configurer, exécutez la commande suivante: 

    $ oc explain <resource_name>.config.openshift.io
    Copy to Clipboard Toggle word wrap

  3. Afin de voir la configuration des objets de définition de ressource personnalisée (CRD) dans le cluster, exécutez la commande suivante: 

    $ oc get <resource_name>.config -o yaml
    Copy to Clipboard Toggle word wrap

  4. Afin de modifier la configuration de la ressource du cluster, exécutez la commande suivante: 

    $ oc edit <resource_name>.config -o yaml
    Copy to Clipboard Toggle word wrap

Chapitre 3. Accès approuvé
Copier lien

L’ingénierie de fiabilité du site Red Hat (SRE) ne nécessite généralement pas un accès élevé aux systèmes dans le cadre des opérations normales pour gérer et prendre en charge le service OpenShift Red Hat sur les clusters AWS. L’accès élevé donne à SRE les niveaux d’accès d’un rôle de cluster-admin. Consultez les rôles de cluster pour plus d’informations.

Dans le cas peu probable où SRE a besoin d’un accès élevé aux systèmes, vous pouvez utiliser l’interface Accès approuvé pour examiner et approuver ou refuser l’accès à ces systèmes.

Les demandes d’accès élevées aux clusters sur Red Hat OpenShift Service sur les clusters AWS et les comptes cloud correspondants peuvent être créées par SRE soit en réponse à un ticket de support initié par le client, soit en réponse aux alertes reçues par SRE dans le cadre du processus de réponse aux incidents standard.

Lorsque l’accès approuvé est activé et qu’un SRE crée une demande d’accès, les propriétaires de clusters reçoivent une notification par courriel les informant d’une nouvelle demande d’accès. La notification par courriel contient un lien permettant au propriétaire du cluster d’approuver ou de refuser rapidement la demande d’accès. Il faut répondre en temps opportun, sinon il y a un risque pour votre SLA pour Red Hat OpenShift Service sur AWS.

  • Lorsque les clients ont besoin d’utilisateurs supplémentaires qui ne sont pas le propriétaire du cluster pour recevoir l’e-mail, ils peuvent ajouter des contacts de cluster de notification.
  • Les demandes d’accès en attente sont disponibles dans la console hybride Cloud de la liste des clusters ou de l’onglet Demandes d’accès dans l’aperçu du cluster spécifique.
Note

Le refus d’une demande d’accès vous oblige à remplir le champ Justification. Dans ce cas, SRE ne peut pas agir directement sur les ressources liées à l’incident. Les clients peuvent toujours utiliser le support client pour aider à enquêter et à résoudre tous les problèmes.

Le service Red Hat OpenShift sur AWS Approved Access n’est pas activé par défaut. Afin d’activer l’accès approuvé pour votre service Red Hat OpenShift sur les clusters AWS, vous devez créer un ticket d’assistance.

Procédure

  1. Connectez-vous à la page Assistance clientèle du portail client Red Hat.
  2. Cliquez sur Obtenez le support.

  3. Dans l’onglet Cas de la page Support Client:

    1. Facultatif: Changez le compte pré-rempli et les détails du propriétaire si nécessaire.
    2. Choisissez la catégorie Configuration et cliquez sur Continuer.

  4. Entrez les informations suivantes:

    1. Dans le champ Produit, sélectionnez Red Hat OpenShift Service sur AWS.
    2. Dans le champ d’instruction Problème, entrez Activer la protection d’accès ROSA.
    3. Cliquez sur Voir plus d’options.
  5. Choisissez OpenShift Cluster ID dans la liste déroulante.

  6. Complétez les champs obligatoires restants dans le formulaire:

    1. Et vous, qu’est-ce que vous vivez? À quoi vous attendez-vous d’arriver?

      1. Complétez l’accès approuvé.

    2. Définissez la valeur ou l’impact pour vous ou l’entreprise.

      1. Complétez l’accès approuvé.
    3. Cliquez sur Continuer.
  7. Choisissez Severity comme 4 (faible) et cliquez sur Continuer.
  8. Aperçu des détails de l’affaire et cliquez sur Soumettre.

Les propriétaires de clusters recevront une notification par courriel lorsque Red Hat Site Reliability Engineering (SRE) demandera l’accès à leur cluster avec un lien pour examiner la demande dans la console hybride Cloud.

Procédure

  1. Cliquez sur le lien dans l’e-mail pour vous amener à la console hybride Cloud.

  2. Dans la boîte de dialogue Détails de la demande d’accès, cliquez sur Approuver ou refuser sous Décision.

    Note

    Le refus d’une demande d’accès vous oblige à remplir le champ Justification. Dans ce cas, SRE ne peut pas agir directement sur les ressources liées à l’incident. Les clients peuvent toujours utiliser le support client pour aider à enquêter et à résoudre tous les problèmes.

  3. Cliquez sur Save.

Examinez les demandes d’accès pour votre Red Hat OpenShift Service sur les clusters AWS de la console hybride Cloud.

Procédure

  1. Accédez à OpenShift Cluster Manager et sélectionnez Cluster List.
  2. Cliquez sur le nom du cluster pour examiner la demande d’accès.
  3. Choisissez l’onglet Demandes d’accès pour énumérer tous les états.
  4. Choisissez Ouvrir sous Actions pour l’état en attente.

  5. Dans la boîte de dialogue Détails de la demande d’accès, cliquez sur Approuver ou refuser sous Décision.

    Note

    Le refus d’une demande d’accès vous oblige à remplir le champ Justification. Dans ce cas, SRE ne peut pas agir directement sur les ressources liées à l’incident. Les clients peuvent toujours utiliser le support client pour aider à enquêter et à résoudre tous les problèmes.

  6. Cliquez sur Save.

Chapitre 4. L’obtention d’un soutien
Copier lien

4.1. L’obtention d’un soutien
Copier lien

En cas de difficulté avec une procédure décrite dans cette documentation, ou avec Red Hat OpenShift Service sur AWS en général, visitez le portail client Red Hat.

Depuis le portail client, vous pouvez:

  • Cherchez ou parcourez la base de connaissances Red Hat des articles et solutions relatifs aux produits Red Hat.
  • Envoyez une affaire de soutien à Red Hat Support.
  • Accédez à d’autres documents produits.

Afin d’identifier les problèmes avec votre cluster, vous pouvez utiliser Insights dans OpenShift Cluster Manager. Insights fournit des détails sur les problèmes et, si disponible, des informations sur la façon de résoudre un problème.

Lorsque vous avez une suggestion d’améliorer cette documentation ou que vous avez trouvé une erreur, soumettez un problème Jira pour le composant de documentation le plus pertinent. Fournir des détails spécifiques, tels que le nom de la section et le service Red Hat OpenShift sur la version AWS.

4.2. À propos de la base de connaissances Red Hat
Copier lien

La base de connaissances Red Hat fournit un contenu riche visant à vous aider à tirer le meilleur parti des produits et technologies de Red Hat. La base de connaissances Red Hat se compose d’articles, de documentation de produit et de vidéos décrivant les meilleures pratiques sur l’installation, la configuration et l’utilisation des produits Red Hat. En outre, vous pouvez rechercher des solutions à des problèmes connus, chacun fournissant des descriptions concises des causes profondes et des étapes correctives.

4.3. La recherche de la base de connaissances Red Hat
Copier lien

Dans le cas d’un service Red Hat OpenShift sur AWS, vous pouvez effectuer une recherche initiale pour déterminer si une solution existe déjà dans la base de connaissances Red Hat.

Conditions préalables

  • Il y a un compte Red Hat Customer Portal.

Procédure

  1. Connectez-vous au portail client Red Hat.
  2. Cliquez sur Rechercher.

  3. Dans le champ de recherche, entrez des mots clés et des chaînes relatives au problème, y compris:

    • Le service OpenShift Red Hat sur les composants AWS (tels que etc.)
    • La procédure connexe (comme l’installation)
    • Avertissements, messages d’erreur et autres sorties liées à des défaillances explicites
  4. Cliquez sur la touche Entrer.
  5. Facultatif: Sélectionnez le service Red Hat OpenShift sur le filtre produit AWS.
  6. Facultatif: Sélectionnez le filtre de type de contenu de Documentation.

4.4. Dépôt d’une affaire de soutien
Copier lien

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle d’administrateur dédié.
  • L’OpenShift CLI (oc) a été installé.
  • Accès au Red Hat OpenShift Cluster Manager.

Procédure

  1. Connectez-vous à la page Assistance clientèle du portail client Red Hat.
  2. Cliquez sur Obtenez le support.

  3. Dans l’onglet Cas de la page Support Client:

    1. Facultatif: Changez le compte pré-rempli et les détails du propriétaire si nécessaire.
    2. Choisissez la catégorie appropriée pour votre problème, tels que Bug ou Défaut, et cliquez sur Continuer.

  4. Entrez les informations suivantes:

    1. Dans le champ Sommaire, entrez un résumé concis mais descriptif des problèmes et d’autres détails sur les symptômes ressentis, ainsi que vos attentes.
    2. Choisissez Red Hat OpenShift Service sur AWS dans le menu déroulant Produit.
  5. Examinez la liste des solutions proposées à la base de connaissances Red Hat pour une correspondance potentielle avec le problème signalé. Lorsque les articles proposés ne traitent pas le problème, cliquez sur Continuer.
  6. Examinez la liste mise à jour des solutions proposées à la base de connaissances Red Hat pour une correspondance potentielle avec le problème signalé. La liste est affinée au fur et à mesure que vous fournissez plus d’informations lors du processus de création de cas. Lorsque les articles proposés ne traitent pas le problème, cliquez sur Continuer.
  7. Assurez-vous que les informations de compte présentées sont comme prévu, et si ce n’est pas le cas, modifier en conséquence.

  8. Assurez-vous que le service Red Hat OpenShift autorempli sur AWS Cluster ID est correct. Dans le cas contraire, obtenez manuellement votre identifiant de cluster.

    • Afin d’obtenir manuellement votre identifiant de cluster à l’aide du service Red Hat OpenShift sur la console web AWS:

      1. Accédez à Home → Aperçu.
      2. Cherchez la valeur dans le champ ID du cluster de la section Détails.

    • Alternativement, il est possible d’ouvrir un nouveau cas de support via le Red Hat OpenShift Service sur la console web AWS et de faire remplir automatiquement votre identifiant de cluster.

      1. De la barre d’outils, accédez à (?) Aide → Ouvrir le cas de support.
      2. La valeur Cluster ID est remplie automatiquement.

    • Afin d’obtenir votre identifiant de cluster à l’aide de l’OpenShift CLI (oc), exécutez la commande suivante: 

      $ oc get clusterversion -o jsonpath='{.items[].spec.clusterID}{"\n"}'
      Copy to Clipboard Toggle word wrap

  9. Complétez les questions suivantes où vous êtes invité, puis cliquez sur Continuer:

    • Et vous, qu’est-ce que vous vivez? À quoi vous attendez-vous d’arriver?
    • Définissez la valeur ou l’impact pour vous ou l’entreprise.
    • D’où faites-vous l’expérience de ce comportement? Dans quel environnement?
    • À quel moment ce comportement se produit-il? La fréquence? À plusieurs reprises? À certains moments?
  10. Téléchargez les fichiers de données de diagnostic pertinents et cliquez sur Continuer.
  11. Entrez les détails pertinents de la gestion des cas et cliquez sur Continuer.
  12. Aperçu des détails de l’affaire et cliquez sur Soumettre.

5.1. À propos de la surveillance à distance de la santé
Copier lien

Le service OpenShift Red Hat sur AWS recueille des données de télémétrie et de configuration sur votre cluster et les signale à Red Hat en utilisant le client télémètre et l’opérateur Insights. Les données fournies à Red Hat permettent les avantages décrits dans ce document.

Le cluster qui rapporte les données à Red Hat via Telemetry et Insights Operator est considéré comme un cluster connecté.

La télémétrie est le terme utilisé par Red Hat pour décrire les informations envoyées à Red Hat par le Service OpenShift Red Hat sur AWS Telemeter Client. Des attributs légers sont envoyés de clusters connectés à Red Hat pour permettre l’automatisation de la gestion des abonnements, surveiller l’état de santé des clusters, aider avec le support et améliorer l’expérience client.

L’opérateur Insights rassemble Red Hat OpenShift Service sur les données de configuration AWS et l’envoie à Red Hat. Les données sont utilisées pour produire des informations sur les problèmes potentiels auxquels un cluster pourrait être exposé. Ces informations sont communiquées aux administrateurs de clusters sur OpenShift Cluster Manager.

De plus amples renseignements sont fournis dans ce document sur ces deux processus.

Avantages de l’opérateur de télémétrie et d’information

La télémétrie et l’opérateur Insights permettent aux utilisateurs finaux de bénéficier des avantages suivants:

  • Amélioration de l’identification et de la résolution des problèmes. Les événements qui peuvent sembler normaux à un utilisateur final peuvent être observés par Red Hat d’un point de vue plus large à travers une flotte de clusters. Certains problèmes peuvent être identifiés plus rapidement de ce point de vue et résolus sans qu’un utilisateur final ait besoin d’ouvrir une affaire de soutien ou de déposer un problème Jira.
  • Gestion avancée des versions. Le service OpenShift Red Hat sur AWS offre les canaux de sortie candidats, rapides et stables, qui vous permettent de choisir une stratégie de mise à jour. La graduation d’une version rapide à stable dépend du taux de réussite des mises à jour et des événements observés lors des mises à jour. Grâce aux informations fournies par les clusters connectés, Red Hat peut améliorer la qualité des versions sur des canaux stables et réagir plus rapidement aux problèmes rencontrés dans les canaux rapides.
  • Hiérarchisation ciblée des nouvelles fonctionnalités et fonctionnalités. Les données recueillies fournissent des informations sur les zones de Red Hat OpenShift Service sur AWS les plus utilisées. Grâce à ces informations, Red Hat peut se concentrer sur le développement des nouvelles fonctionnalités et fonctionnalités qui ont le plus d’impact pour nos clients.
  • Expérience de support rationalisée. Lors de la création d’un ticket d’assistance sur le portail client Red Hat, vous pouvez fournir un identifiant de cluster pour un cluster connecté. Cela permet à Red Hat d’offrir une expérience de support simplifiée qui est spécifique à votre cluster, en utilisant les informations connectées. Ce document fournit plus d’informations sur cette expérience de support améliorée.
  • Analyse prédictive. Les informations affichées pour votre cluster sur OpenShift Cluster Manager sont activées par les informations recueillies à partir de clusters connectés. « Red Hat investit dans l’application de l’apprentissage en profondeur, de l’apprentissage automatique et de l’automatisation de l’intelligence artificielle pour aider à identifier les problèmes auxquels Red Hat OpenShift Service sur les clusters AWS sont exposés.

Dans Red Hat OpenShift Service sur AWS, les rapports de santé à distance sont toujours activés. Il ne faut pas s’en retirer.

5.1.1. À propos de la télémétrie
Copier lien

La télémétrie envoie un sous-ensemble soigneusement choisi des mesures de surveillance des clusters à Red Hat. Le client télémètre obtient les valeurs métriques toutes les quatre minutes et trente secondes et télécharge les données sur Red Hat. Ces métriques sont décrites dans ce document.

Ce flux de données est utilisé par Red Hat pour surveiller les clusters en temps réel et pour réagir au besoin aux problèmes qui affectent nos clients. Il permet également à Red Hat de déployer le service OpenShift Red Hat sur les mises à niveau AWS vers les clients afin de minimiser l’impact du service et d’améliorer continuellement l’expérience de mise à niveau.

Ces informations de débogage sont à la disposition des équipes de soutien et d’ingénierie Red Hat avec les mêmes restrictions que l’accès aux données signalées par le biais de cas de soutien. Les informations sur les clusters connectés sont utilisées par Red Hat pour aider à rendre le service OpenShift de Red Hat sur AWS meilleur et plus intuitif à utiliser.

5.1.1.1. Informations collectées par Télémétrie
Copier lien

Les informations suivantes sont collectées par Télémétrie:

5.1.1.1.1. Information du système
Copier lien
  • Informations de version, y compris le service Red Hat OpenShift sur la version du cluster AWS et les détails de mise à jour installés qui sont utilisés pour déterminer la disponibilité de la version de mise à jour
  • Actualiser les informations, y compris le nombre de mises à jour disponibles par cluster, le canal et le référentiel d’images utilisés pour une mise à jour, mettre à jour les informations de progression et le nombre d’erreurs qui se produisent dans une mise à jour
  • L’identifiant aléatoire unique qui est généré lors d’une installation
  • Les détails de configuration qui aident Red Hat Support à fournir un support bénéfique pour les clients, y compris la configuration des nœuds au niveau de l’infrastructure cloud, les noms d’hôte, les adresses IP, les noms de pod Kubernetes, les espaces de noms et les services
  • Le Red Hat OpenShift Service sur les composants de framework AWS installés dans un cluster et leur état et statut
  • Événements pour tous les espaces de noms listés comme "objets liés" pour un opérateur dégradé
  • Informations sur les logiciels dégradés
  • Informations sur la validité des certificats
  • Le nom de la plateforme fournisseur sur laquelle Red Hat OpenShift Service est déployé sur AWS et l’emplacement du centre de données
5.1.1.1.2. Informations de dimensionnement
Copier lien
  • Dimensionnement des informations sur les clusters, les types de machines et les machines, y compris le nombre de cœurs CPU et la quantité de RAM utilisée pour chaque
  • Le nombre de membres etcd et le nombre d’objets stockés dans le cluster etcd
  • Le nombre de créations d’applications par type de stratégie de construction
5.1.1.1.3. Informations d’utilisation
Copier lien
  • Informations d’utilisation sur les composants, les fonctionnalités et les extensions
  • Détails d’utilisation sur les aperçus technologiques et les configurations non prises en charge

La télémétrie ne collecte pas d’informations d’identification telles que les noms d’utilisateur ou les mots de passe. Le Red Hat n’a pas l’intention de recueillir des renseignements personnels. Lorsque Red Hat découvre que des renseignements personnels ont été reçus par inadvertance, Red Hat supprimera ces informations. Dans la mesure où toute donnée de télémétrie constitue des données personnelles, veuillez consulter la Déclaration de confidentialité Red Hat pour plus d’informations sur les pratiques de confidentialité de Red Hat.

5.1.1.2. La télémétrie de l’utilisateur
Copier lien

Le Red Hat recueille des données utilisateur anonymisées à partir de votre navigateur. Ces données anonymes incluent les pages, les fonctionnalités et les types de ressources que l’utilisateur de tous les clusters utilisant la télémétrie activée.

Autres considérations:

  • Les événements utilisateurs sont regroupés sous la forme d’un hachage SHA-1.
  • L’adresse IP de l’utilisateur est enregistrée en tant que 0.0.0.0.
  • Les noms d’utilisateur et les adresses IP ne sont jamais enregistrés sous forme de valeurs distinctes.

5.1.2. À propos de l’opérateur Insights
Copier lien

L’opérateur Insights recueille périodiquement l’état de défaillance de la configuration et des composants et, par défaut, rapporte les données toutes les deux heures à Red Hat. Ces informations permettent à Red Hat d’évaluer les données de configuration et d’échec plus profondes que celles rapportées par Télémétrie.

Les utilisateurs de Red Hat OpenShift Service sur AWS peuvent afficher le rapport de chaque cluster dans le service Insights Advisor sur Red Hat Hybrid Cloud Console. En cas d’identification de problèmes, Insights fournit de plus amples détails et, le cas échéant, des étapes sur la façon de résoudre un problème.

L’opérateur Insights ne collecte pas d’informations d’identification, telles que les noms d’utilisateur, les mots de passe ou les certificats. Consultez Red Hat Insights Data &amp; Application Security pour obtenir des informations sur la collecte et les contrôles de données de Red Hat Insights.

Le Red Hat utilise toutes les informations sur les clusters connectés pour:

  • Identifier les problèmes potentiels de cluster et fournir une solution et des actions préventives dans le service Insights Advisor sur Red Hat Hybrid Cloud Console
  • Améliorez Red Hat OpenShift Service sur AWS en fournissant des informations agrégées et critiques aux équipes de produits et de support
  • Faites du Red Hat OpenShift Service sur AWS plus intuitif
5.1.2.1. Informations collectées par l’opérateur Insights
Copier lien

Les informations suivantes sont collectées par l’opérateur Insights:

  • Informations générales sur votre cluster et ses composants pour identifier les problèmes spécifiques à votre service OpenShift Red Hat sur la version et l’environnement AWS.
  • Fichiers de configuration, tels que la configuration du registre d’images, de votre cluster pour déterminer les paramètres et les problèmes qui sont spécifiques aux paramètres que vous définissez.
  • Erreurs qui se produisent dans les composants du cluster.
  • Informations d’avancement des mises à jour en cours d’exécution, et l’état de toute mise à jour des composants.
  • Détails de la plate-forme sur laquelle Red Hat OpenShift Service est déployé sur AWS et de la région dans laquelle le cluster est situé
  • Les informations sur la charge de travail des clusters transformées en valeurs discrètes de l’algorithme Secure Hash (SHA), ce qui permet à Red Hat d’évaluer les charges de travail pour la sécurité et les vulnérabilités des versions sans divulguer des détails sensibles.

  • Informations sur la charge de travail sur le système d’exploitation et l’environnement d’exécution, y compris les types d’exécution, les noms et les versions, que vous pouvez éventuellement activer via la porte de fonctionnalités InsightsRuntimeExtractor. Ces données permettent à Red Hat de mieux comprendre comment vous utilisez le service OpenShift Red Hat sur les conteneurs AWS afin que nous puissions vous aider de manière proactive à prendre des décisions d’investissement afin d’assurer une utilisation optimale.

    Important

    InsightsRuntimeExtractor est une fonctionnalité d’aperçu technologique seulement. Les fonctionnalités d’aperçu technologique ne sont pas prises en charge avec les accords de niveau de service de production de Red Hat (SLA) et pourraient ne pas être fonctionnellement complètes. Le Red Hat ne recommande pas de les utiliser en production. Ces fonctionnalités offrent un accès précoce aux fonctionnalités du produit à venir, permettant aux clients de tester les fonctionnalités et de fournir des commentaires pendant le processus de développement.

    En savoir plus sur la portée du support des fonctionnalités de Red Hat Technology Preview, voir la portée du support des fonctionnalités d’aperçu de la technologie.

  • Lorsqu’un opérateur signale un problème, des informations sont recueillies sur le service OpenShift Red Hat de base sur les pods AWS dans les projets openshift-* et kube-*. Cela inclut l’état, la ressource, le contexte de sécurité, les informations de volume, et plus encore.

Le client télémètre collecte des données de séries chronologiques sélectionnées à partir de l’API Prometheus. Les données des séries chronologiques sont téléchargées sur api.openshift.com toutes les quatre minutes et trente secondes pour le traitement.

L’opérateur Insights recueille des données sélectionnées à partir de l’API Kubernetes et de l’API Prometheus dans une archive. L’archive est téléchargée sur OpenShift Cluster Manager toutes les deux heures pour le traitement. L’opérateur Insights télécharge également la dernière analyse Insights à partir d’OpenShift Cluster Manager. Ceci est utilisé pour peupler le statut Insights pop-up qui est inclus dans la page Aperçu dans le Red Hat OpenShift Service sur la console web AWS.

L’ensemble de la communication avec Red Hat se produit sur des canaux cryptés en utilisant Transport Layer Security (TLS) et l’authentification mutuelle des certificats. L’ensemble des données est cryptée en transit et au repos.

L’accès aux systèmes qui gèrent les données client est contrôlé par l’authentification multi-facteurs et des contrôles d’autorisation stricts. L’accès est accordé sur la base du besoin de savoir et est limité aux opérations requises.

Flux de données de l’opérateur

Telemetry and Insights Operator data flow

L’information recueillie pour permettre la surveillance à distance de la santé est détaillée dans Information recueillie par Télémétrie et Informations collectées par l’opérateur Insights.

Comme décrit plus loin dans les sections précédentes du présent document, Red Hat recueille des données sur votre utilisation du(s) Produit(s) Red Hat à des fins telles que la fourniture d’assistance et de mises à niveau, l’optimisation des performances ou de la configuration, la minimisation des impacts sur le service, l’identification et la correction des menaces, le dépannage, l’amélioration des offres et de l’expérience utilisateur, la réponse aux problèmes et aux fins de facturation, le cas échéant.

Garanties de collecte

Le Red Hat utilise des mesures techniques et organisationnelles conçues pour protéger les données de télémétrie et de configuration.

Le partage

Il est possible que Red Hat partage les données collectées par Telemetry et l’opérateur Insights en interne au sein de Red Hat afin d’améliorer votre expérience utilisateur. Il est possible que Red Hat partage des données de télémétrie et de configuration avec ses partenaires commerciaux sous une forme agrégée qui n’identifie pas les clients pour aider les partenaires à mieux comprendre leurs marchés et l’utilisation des offres Red Hat par leurs clients ou à assurer une intégration réussie des produits soutenus conjointement par ces partenaires.

Des tiers

Il se peut que Red Hat engage certains tiers pour aider à la collecte, à l’analyse et au stockage des données de télémétrie et de configuration.

Contrôle de l’utilisateur/activation et désactivation de la télémétrie et de la collecte de données de configuration

En tant qu’administrateur, vous pouvez passer en revue les métriques collectées par Telemetry et l’Insights Operator.

5.2.1. Affichage des données collectées par Telemetry
Copier lien

Les données des séries chronologiques du cluster et des composants peuvent être affichées par Telemetry.

Conditions préalables

  • La plate-forme OpenShift Container Platform CLI (oc) a été installée.
  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle d’administrateur dédié.

Procédure

  1. Connectez-vous à un cluster.
  2. Exécutez la commande suivante, qui interroge le service Prometheus d’un cluster et retourne l’ensemble complet de données de séries chronologiques capturées par Telemetry:
Note

L’exemple suivant contient certaines valeurs spécifiques au service Red Hat OpenShift sur AWS sur AWS. 

$ curl -G -k -H "Authorization: Bearer $(oc whoami -t)" \
https://$(oc get route prometheus-k8s-federate -n \
openshift-monitoring -o jsonpath="{.spec.host}")/federate \
--data-urlencode 'match[]={__name__=~"cluster:usage:.*"}' \
--data-urlencode 'match[]={__name__="count:up0"}' \
--data-urlencode 'match[]={__name__="count:up1"}' \
--data-urlencode 'match[]={__name__="cluster_version"}' \
--data-urlencode 'match[]={__name__="cluster_version_available_updates"}' \
--data-urlencode 'match[]={__name__="cluster_version_capability"}' \
--data-urlencode 'match[]={__name__="cluster_operator_up"}' \
--data-urlencode 'match[]={__name__="cluster_operator_conditions"}' \
--data-urlencode 'match[]={__name__="cluster_version_payload"}' \
--data-urlencode 'match[]={__name__="cluster_installer"}' \
--data-urlencode 'match[]={__name__="cluster_infrastructure_provider"}' \
--data-urlencode 'match[]={__name__="cluster_feature_set"}' \
--data-urlencode 'match[]={__name__="instance:etcd_object_counts:sum"}' \
--data-urlencode 'match[]={__name__="ALERTS",alertstate="firing"}' \
--data-urlencode 'match[]={__name__="code:apiserver_request_total:rate:sum"}' \
--data-urlencode 'match[]={__name__="cluster:capacity_cpu_cores:sum"}' \
--data-urlencode 'match[]={__name__="cluster:capacity_memory_bytes:sum"}' \
--data-urlencode 'match[]={__name__="cluster:cpu_usage_cores:sum"}' \
--data-urlencode 'match[]={__name__="cluster:memory_usage_bytes:sum"}' \
--data-urlencode 'match[]={__name__="openshift:cpu_usage_cores:sum"}' \
--data-urlencode 'match[]={__name__="openshift:memory_usage_bytes:sum"}' \
--data-urlencode 'match[]={__name__="workload:cpu_usage_cores:sum"}' \
--data-urlencode 'match[]={__name__="workload:memory_usage_bytes:sum"}' \
--data-urlencode 'match[]={__name__="cluster:virt_platform_nodes:sum"}' \
--data-urlencode 'match[]={__name__="cluster:node_instance_type_count:sum"}' \
--data-urlencode 'match[]={__name__="cnv:vmi_status_running:count"}' \
--data-urlencode 'match[]={__name__="cluster:vmi_request_cpu_cores:sum"}' \
--data-urlencode 'match[]={__name__="node_role_os_version_machine:cpu_capacity_cores:sum"}' \
--data-urlencode 'match[]={__name__="node_role_os_version_machine:cpu_capacity_sockets:sum"}' \
--data-urlencode 'match[]={__name__="subscription_sync_total"}' \
--data-urlencode 'match[]={__name__="olm_resolution_duration_seconds"}' \
--data-urlencode 'match[]={__name__="csv_succeeded"}' \
--data-urlencode 'match[]={__name__="csv_abnormal"}' \
--data-urlencode 'match[]={__name__="cluster:kube_persistentvolumeclaim_resource_requests_storage_bytes:provisioner:sum"}' \
--data-urlencode 'match[]={__name__="cluster:kubelet_volume_stats_used_bytes:provisioner:sum"}' \
--data-urlencode 'match[]={__name__="ceph_cluster_total_bytes"}' \
--data-urlencode 'match[]={__name__="ceph_cluster_total_used_raw_bytes"}' \
--data-urlencode 'match[]={__name__="ceph_health_status"}' \
--data-urlencode 'match[]={__name__="odf_system_raw_capacity_total_bytes"}' \
--data-urlencode 'match[]={__name__="odf_system_raw_capacity_used_bytes"}' \
--data-urlencode 'match[]={__name__="odf_system_health_status"}' \
--data-urlencode 'match[]={__name__="job:ceph_osd_metadata:count"}' \
--data-urlencode 'match[]={__name__="job:kube_pv:count"}' \
--data-urlencode 'match[]={__name__="job:odf_system_pvs:count"}' \
--data-urlencode 'match[]={__name__="job:ceph_pools_iops:total"}' \
--data-urlencode 'match[]={__name__="job:ceph_pools_iops_bytes:total"}' \
--data-urlencode 'match[]={__name__="job:ceph_versions_running:count"}' \
--data-urlencode 'match[]={__name__="job:noobaa_total_unhealthy_buckets:sum"}' \
--data-urlencode 'match[]={__name__="job:noobaa_bucket_count:sum"}' \
--data-urlencode 'match[]={__name__="job:noobaa_total_object_count:sum"}' \
--data-urlencode 'match[]={__name__="odf_system_bucket_count", system_type="OCS", system_vendor="Red Hat"}' \
--data-urlencode 'match[]={__name__="odf_system_objects_total", system_type="OCS", system_vendor="Red Hat"}' \
--data-urlencode 'match[]={__name__="noobaa_accounts_num"}' \
--data-urlencode 'match[]={__name__="noobaa_total_usage"}' \
--data-urlencode 'match[]={__name__="console_url"}' \
--data-urlencode 'match[]={__name__="cluster:ovnkube_master_egress_routing_via_host:max"}' \
--data-urlencode 'match[]={__name__="cluster:network_attachment_definition_instances:max"}' \
--data-urlencode 'match[]={__name__="cluster:network_attachment_definition_enabled_instance_up:max"}' \
--data-urlencode 'match[]={__name__="cluster:ingress_controller_aws_nlb_active:sum"}' \
--data-urlencode 'match[]={__name__="cluster:route_metrics_controller_routes_per_shard:min"}' \
--data-urlencode 'match[]={__name__="cluster:route_metrics_controller_routes_per_shard:max"}' \
--data-urlencode 'match[]={__name__="cluster:route_metrics_controller_routes_per_shard:avg"}' \
--data-urlencode 'match[]={__name__="cluster:route_metrics_controller_routes_per_shard:median"}' \
--data-urlencode 'match[]={__name__="cluster:openshift_route_info:tls_termination:sum"}' \
--data-urlencode 'match[]={__name__="insightsclient_request_send_total"}' \
--data-urlencode 'match[]={__name__="cam_app_workload_migrations"}' \
--data-urlencode 'match[]={__name__="cluster:apiserver_current_inflight_requests:sum:max_over_time:2m"}' \
--data-urlencode 'match[]={__name__="cluster:alertmanager_integrations:max"}' \
--data-urlencode 'match[]={__name__="cluster:telemetry_selected_series:count"}' \
--data-urlencode 'match[]={__name__="openshift:prometheus_tsdb_head_series:sum"}' \
--data-urlencode 'match[]={__name__="openshift:prometheus_tsdb_head_samples_appended_total:sum"}' \
--data-urlencode 'match[]={__name__="monitoring:container_memory_working_set_bytes:sum"}' \
--data-urlencode 'match[]={__name__="namespace_job:scrape_series_added:topk3_sum1h"}' \
--data-urlencode 'match[]={__name__="namespace_job:scrape_samples_post_metric_relabeling:topk3"}' \
--data-urlencode 'match[]={__name__="monitoring:haproxy_server_http_responses_total:sum"}' \
--data-urlencode 'match[]={__name__="rhmi_status"}' \
--data-urlencode 'match[]={__name__="status:upgrading:version:rhoam_state:max"}' \
--data-urlencode 'match[]={__name__="state:rhoam_critical_alerts:max"}' \
--data-urlencode 'match[]={__name__="state:rhoam_warning_alerts:max"}' \
--data-urlencode 'match[]={__name__="rhoam_7d_slo_percentile:max"}' \
--data-urlencode 'match[]={__name__="rhoam_7d_slo_remaining_error_budget:max"}' \
--data-urlencode 'match[]={__name__="cluster_legacy_scheduler_policy"}' \
--data-urlencode 'match[]={__name__="cluster_master_schedulable"}' \
--data-urlencode 'match[]={__name__="che_workspace_status"}' \
--data-urlencode 'match[]={__name__="che_workspace_started_total"}' \
--data-urlencode 'match[]={__name__="che_workspace_failure_total"}' \
--data-urlencode 'match[]={__name__="che_workspace_start_time_seconds_sum"}' \
--data-urlencode 'match[]={__name__="che_workspace_start_time_seconds_count"}' \
--data-urlencode 'match[]={__name__="cco_credentials_mode"}' \
--data-urlencode 'match[]={__name__="cluster:kube_persistentvolume_plugin_type_counts:sum"}' \
--data-urlencode 'match[]={__name__="visual_web_terminal_sessions_total"}' \
--data-urlencode 'match[]={__name__="acm_managed_cluster_info"}' \
--data-urlencode 'match[]={__name__="cluster:vsphere_vcenter_info:sum"}' \
--data-urlencode 'match[]={__name__="cluster:vsphere_esxi_version_total:sum"}' \
--data-urlencode 'match[]={__name__="cluster:vsphere_node_hw_version_total:sum"}' \
--data-urlencode 'match[]={__name__="openshift:build_by_strategy:sum"}' \
--data-urlencode 'match[]={__name__="rhods_aggregate_availability"}' \
--data-urlencode 'match[]={__name__="rhods_total_users"}' \
--data-urlencode 'match[]={__name__="instance:etcd_disk_wal_fsync_duration_seconds:histogram_quantile",quantile="0.99"}' \
--data-urlencode 'match[]={__name__="instance:etcd_mvcc_db_total_size_in_bytes:sum"}' \
--data-urlencode 'match[]={__name__="instance:etcd_network_peer_round_trip_time_seconds:histogram_quantile",quantile="0.99"}' \
--data-urlencode 'match[]={__name__="instance:etcd_mvcc_db_total_size_in_use_in_bytes:sum"}' \
--data-urlencode 'match[]={__name__="instance:etcd_disk_backend_commit_duration_seconds:histogram_quantile",quantile="0.99"}' \
--data-urlencode 'match[]={__name__="jaeger_operator_instances_storage_types"}' \
--data-urlencode 'match[]={__name__="jaeger_operator_instances_strategies"}' \
--data-urlencode 'match[]={__name__="jaeger_operator_instances_agent_strategies"}' \
--data-urlencode 'match[]={__name__="appsvcs:cores_by_product:sum"}' \
--data-urlencode 'match[]={__name__="nto_custom_profiles:count"}' \
--data-urlencode 'match[]={__name__="openshift_csi_share_configmap"}' \
--data-urlencode 'match[]={__name__="openshift_csi_share_secret"}' \
--data-urlencode 'match[]={__name__="openshift_csi_share_mount_failures_total"}' \
--data-urlencode 'match[]={__name__="openshift_csi_share_mount_requests_total"}' \
--data-urlencode 'match[]={__name__="cluster:velero_backup_total:max"}' \
--data-urlencode 'match[]={__name__="cluster:velero_restore_total:max"}' \
--data-urlencode 'match[]={__name__="eo_es_storage_info"}' \
--data-urlencode 'match[]={__name__="eo_es_redundancy_policy_info"}' \
--data-urlencode 'match[]={__name__="eo_es_defined_delete_namespaces_total"}' \
--data-urlencode 'match[]={__name__="eo_es_misconfigured_memory_resources_info"}' \
--data-urlencode 'match[]={__name__="cluster:eo_es_data_nodes_total:max"}' \
--data-urlencode 'match[]={__name__="cluster:eo_es_documents_created_total:sum"}' \
--data-urlencode 'match[]={__name__="cluster:eo_es_documents_deleted_total:sum"}' \
--data-urlencode 'match[]={__name__="pod:eo_es_shards_total:max"}' \
--data-urlencode 'match[]={__name__="eo_es_cluster_management_state_info"}' \
--data-urlencode 'match[]={__name__="imageregistry:imagestreamtags_count:sum"}' \
--data-urlencode 'match[]={__name__="imageregistry:operations_count:sum"}' \
--data-urlencode 'match[]={__name__="log_logging_info"}' \
--data-urlencode 'match[]={__name__="log_collector_error_count_total"}' \
--data-urlencode 'match[]={__name__="log_forwarder_pipeline_info"}' \
--data-urlencode 'match[]={__name__="log_forwarder_input_info"}' \
--data-urlencode 'match[]={__name__="log_forwarder_output_info"}' \
--data-urlencode 'match[]={__name__="cluster:log_collected_bytes_total:sum"}' \
--data-urlencode 'match[]={__name__="cluster:log_logged_bytes_total:sum"}' \
--data-urlencode 'match[]={__name__="cluster:kata_monitor_running_shim_count:sum"}' \
--data-urlencode 'match[]={__name__="platform:hypershift_hostedclusters:max"}' \
--data-urlencode 'match[]={__name__="platform:hypershift_nodepools:max"}' \
--data-urlencode 'match[]={__name__="namespace:noobaa_unhealthy_bucket_claims:max"}' \
--data-urlencode 'match[]={__name__="namespace:noobaa_buckets_claims:max"}' \
--data-urlencode 'match[]={__name__="namespace:noobaa_unhealthy_namespace_resources:max"}' \
--data-urlencode 'match[]={__name__="namespace:noobaa_namespace_resources:max"}' \
--data-urlencode 'match[]={__name__="namespace:noobaa_unhealthy_namespace_buckets:max"}' \
--data-urlencode 'match[]={__name__="namespace:noobaa_namespace_buckets:max"}' \
--data-urlencode 'match[]={__name__="namespace:noobaa_accounts:max"}' \
--data-urlencode 'match[]={__name__="namespace:noobaa_usage:max"}' \
--data-urlencode 'match[]={__name__="namespace:noobaa_system_health_status:max"}' \
--data-urlencode 'match[]={__name__="ocs_advanced_feature_usage"}' \
--data-urlencode 'match[]={__name__="os_image_url_override:sum"}' \
--data-urlencode 'match[]={__name__="openshift:openshift_network_operator_ipsec_state:info"}'
Copy to Clipboard Toggle word wrap

Insights analyse à plusieurs reprises les données que Insights Operator envoie. Les utilisateurs de Red Hat OpenShift Service sur AWS peuvent afficher le rapport dans le service Insights Advisor sur Red Hat Hybrid Cloud Console.

Grâce à Insights Advisor, vous pouvez évaluer et surveiller l’état de santé de votre service OpenShift Red Hat sur les clusters AWS. « que vous soyez préoccupé par les clusters individuels ou par l’ensemble de votre infrastructure, il est important d’être conscient de l’exposition de votre infrastructure de cluster à des problèmes qui peuvent affecter la disponibilité des services, la tolérance aux pannes, les performances ou la sécurité.

En utilisant les données de cluster collectées par l’opérateur Insights, Insights compare ces données à plusieurs reprises à une bibliothèque de recommandations. Chaque recommandation est un ensemble de conditions de cluster-environnement qui peuvent laisser Red Hat OpenShift Service sur les clusters AWS en danger. Les résultats de l’analyse Insights sont disponibles dans le service Insights Advisor sur Red Hat Hybrid Cloud Console. Dans la console, vous pouvez effectuer les actions suivantes:

  • Consultez les clusters touchés par une recommandation spécifique.
  • Faites appel à des capacités de filtrage robustes pour affiner vos résultats à ces recommandations.
  • Apprenez-en davantage sur les recommandations individuelles, les détails sur les risques qu’ils présentent et obtenez des résolutions adaptées à vos clusters individuels.
  • Communiquer les résultats avec d’autres parties prenantes.

5.3.2. Comprendre Insights Recommandations du conseiller
Copier lien

Insight Advisor regroupe des informations sur divers états de cluster et configurations de composants qui peuvent affecter négativement la disponibilité du service, la tolérance aux pannes, les performances ou la sécurité de vos clusters. Cet ensemble d’informations est appelé une recommandation dans Insights Advisor et comprend les informations suivantes:

  • Description concise de la recommandation
  • Ajouté: Lorsque la recommandation a été publiée dans l’archive Insights Advisor
  • Catégorie: Si le problème a le potentiel d’affecter négativement la disponibilité du service, la tolérance aux pannes, les performances ou la sécurité
  • Le risque total : une valeur dérivée de la probabilité que la condition affecte négativement votre infrastructure et de l’impact sur les opérations si cela devait se produire.
  • Clusters: Une liste de clusters sur lesquels une recommandation est détectée
  • Description: Un bref résumé de la question, y compris comment il affecte vos clusters
  • Lien vers les sujets associés: Plus d’informations de Red Hat sur le problème

5.3.3. Affichage des problèmes potentiels avec votre cluster
Copier lien

Cette section décrit comment afficher le rapport Insights dans Insights Advisor sur OpenShift Cluster Manager.

Il est à noter que Insights analyse à plusieurs reprises votre cluster et montre les derniers résultats. Ces résultats peuvent changer, par exemple, si vous corrigez un problème ou qu’un nouveau problème a été détecté.

Conditions préalables

  • Le cluster est enregistré sur OpenShift Cluster Manager.
  • Les rapports de santé à distance sont activés, ce qui est le défaut.
  • Connectez-vous à OpenShift Cluster Manager.

Procédure

  1. Accédez au conseiller → Recommandations sur OpenShift Cluster Manager.

    En fonction du résultat, Insights Advisor affiche l’un des éléments suivants:

    • Aucune recommandation correspondante n’a été trouvée, si Insights n’a identifié aucun problème.
    • Liste des problèmes que Insights a détectés, regroupés par risque (faible, modéré, important et critique).
    • Aucun cluster encore, si Insights n’a pas encore analysé le cluster. L’analyse commence peu de temps après que le cluster a été installé, enregistré et connecté à Internet.

  2. En cas de problème, cliquez sur l’icône &gt; devant l’entrée pour plus de détails.

    En fonction du problème, les détails peuvent également contenir un lien vers plus d’informations de Red Hat sur le problème.

La vue Recommandations, par défaut, affiche uniquement les recommandations détectées sur vos clusters. Cependant, vous pouvez consulter toutes les recommandations dans l’archive du conseiller.

Conditions préalables

  • Les rapports de santé à distance sont activés, ce qui est le défaut.
  • Le cluster est enregistré sur Red Hat Hybrid Cloud Console.
  • Connectez-vous à OpenShift Cluster Manager.

Procédure

  1. Accédez au conseiller → Recommandations sur OpenShift Cluster Manager.

  2. Cliquez sur les icônes X à côté des filtres Clusters impactés et État.

    Désormais, vous pouvez parcourir toutes les recommandations potentielles pour votre cluster.

5.3.5. Filtres de recommandation de conseiller
Copier lien

Le service de conseillers Insights peut renvoyer un grand nombre de recommandations. Afin de vous concentrer sur vos recommandations les plus critiques, vous pouvez appliquer des filtres à la liste des recommandations du conseiller pour supprimer les recommandations à faible priorité.

Les filtres sont définis pour afficher uniquement les recommandations activées qui ont un impact sur un ou plusieurs clusters. Afin d’afficher toutes les recommandations ou de les désactiver dans la bibliothèque Insights, vous pouvez personnaliser les filtres.

Afin d’appliquer un filtre, sélectionnez un type de filtre, puis définissez sa valeur en fonction des options disponibles dans la liste déroulante. Il est possible d’appliquer plusieurs filtres à la liste des recommandations.

Les types de filtres suivants peuvent être définis:

  • Le nom : Rechercher une recommandation par nom.
  • Le risque total : Sélectionnez une ou plusieurs valeurs critiques, importantes, modérées et basses indiquant la probabilité et la gravité d’un impact négatif sur un groupe.
  • Impact : Sélectionnez une ou plusieurs valeurs critiques, élevées, moyennes et basses indiquant l’impact potentiel sur la continuité des opérations en grappes.
  • La probabilité: Sélectionnez une ou plusieurs valeurs critiques, élevées, moyennes et basses indiquant le potentiel d’un impact négatif sur un groupe si la recommandation se concrétise.
  • Catégorie: Sélectionnez une ou plusieurs catégories parmi la disponibilité du service, la performance, la tolérance par défaut, la sécurité et les meilleures pratiques pour concentrer votre attention.
  • État : Cliquez sur un bouton radio pour afficher les recommandations activées (par défaut), les recommandations désactivées ou toutes les recommandations.
  • Clusters impactés : Définir le filtre pour montrer les recommandations qui ont actuellement un impact sur un ou plusieurs clusters, des recommandations non impactantes ou toutes les recommandations.
  • Le risque de changement: Sélectionnez une ou plusieurs valeurs parmi les valeurs élevées, modérées, faibles et très faibles indiquant le risque que la mise en œuvre de la résolution pourrait avoir sur les opérations de cluster.
5.3.5.1. Filtrer Insights Recommandations des conseillers
Copier lien

En tant que service Red Hat OpenShift sur AWS cluster Manager, vous pouvez filtrer les recommandations affichées dans la liste des recommandations. En appliquant des filtres, vous pouvez réduire le nombre de recommandations signalées et vous concentrer sur vos recommandations les plus prioritaires.

La procédure suivante montre comment définir et supprimer les filtres de catégorie; cependant, la procédure est applicable à l’un des types de filtres et aux valeurs respectives.

Conditions préalables

Connectez-vous à OpenShift Cluster Manager Hybrid Cloud Console.

Procédure

  1. Allez sur Red Hat Hybrid Cloud Console → OpenShift → Recommandations de conseiller.
  2. Dans la liste déroulante principale, type de filtre, sélectionnez le type de filtre de catégorie.
  3. Développez la liste déroulante de la valeur du filtre et sélectionnez la case à cocher à côté de chaque catégorie de recommandation que vous souhaitez afficher. Laissez les cases à cocher pour les catégories inutiles.
  4. Facultatif: Ajoutez des filtres supplémentaires pour affiner davantage la liste.

Les recommandations des catégories sélectionnées ne sont affichées que dans la liste.

La vérification

  • Après avoir appliqué des filtres, vous pouvez consulter la liste des recommandations mises à jour. Les filtres appliqués sont ajoutés à côté des filtres par défaut.

Il est possible d’appliquer plusieurs filtres à la liste des recommandations. Lorsque vous êtes prêt, vous pouvez les supprimer individuellement ou complètement les réinitialiser.

Éliminer les filtres individuellement

  • Cliquez sur l’icône X à côté de chaque filtre, y compris les filtres par défaut, pour les supprimer individuellement.

La suppression de tous les filtres non par défaut

  • Cliquez sur Réinitialiser les filtres pour supprimer uniquement les filtres que vous avez appliqués, laissant les filtres par défaut en place.

5.3.6. Désactivation Insights Recommandations du conseiller
Copier lien

Il est possible de désactiver les recommandations spécifiques qui affectent vos clusters, de sorte qu’elles n’apparaissent plus dans vos rapports. Il est possible de désactiver une recommandation pour un seul cluster ou tous vos clusters.

Note

La désactivation d’une recommandation pour tous vos clusters s’applique également à tous les futurs clusters.

Conditions préalables

  • Les rapports de santé à distance sont activés, ce qui est le défaut.
  • Le cluster est enregistré sur OpenShift Cluster Manager.
  • Connectez-vous à OpenShift Cluster Manager.

Procédure

  1. Accédez au conseiller → Recommandations sur OpenShift Cluster Manager.
  2. Facultatif: Utilisez les filtres Clusters impactés et État au besoin.

  3. Désactiver une alerte en utilisant l’une des méthodes suivantes:

    • Désactiver une alerte:

      1. Cliquez sur le menu Options pour cette alerte, puis cliquez sur Désactiver la recommandation.
      2. Entrez une note de justification et cliquez sur Enregistrer.

    • Afficher les clusters affectés par cette alerte avant de désactiver l’alerte:

      1. Cliquez sur le nom de la recommandation pour désactiver. Il vous est redirigé vers la page de recommandation unique.
      2. Examiner la liste des clusters de la section des clusters touchés.
      3. Cliquez sur Actions → Désactiver la recommandation pour désactiver l’alerte pour tous vos clusters.
      4. Entrez une note de justification et cliquez sur Enregistrer.

Lorsqu’une recommandation est désactivée pour tous les clusters, vous ne voyez plus la recommandation dans Insights Advisor. Il est possible de changer ce comportement.

Conditions préalables

  • Les rapports de santé à distance sont activés, ce qui est le défaut.
  • Le cluster est enregistré sur OpenShift Cluster Manager.
  • Connectez-vous à OpenShift Cluster Manager.

Procédure

  1. Accédez au conseiller → Recommandations sur OpenShift Cluster Manager.

  2. Filtrer les recommandations à afficher sur les recommandations des handicapés:

    1. Dans le menu déroulant Statut, sélectionnez État.
    2. Dans le menu déroulant Filtrer par état, sélectionnez Désactiver.
    3. Facultatif: Effacer le filtre impacté des clusters.
  3. Localisez la recommandation à activer.
  4. Cliquez sur le menu Options, puis cliquez sur Activer la recommandation.

5.3.8. Affichage de l’état Insights dans la console Web
Copier lien

Insights analyse à plusieurs reprises votre cluster et vous pouvez afficher l’état des problèmes potentiels identifiés de votre cluster dans le Red Hat OpenShift Service sur la console web AWS. Cet état indique le nombre de problèmes dans les différentes catégories et, pour plus de détails, des liens vers les rapports dans OpenShift Cluster Manager.

Conditions préalables

  • Le cluster est enregistré dans OpenShift Cluster Manager.
  • Les rapports de santé à distance sont activés, ce qui est le défaut.
  • Connectez-vous au service Red Hat OpenShift sur la console web AWS.

Procédure

  1. Accédez à Home → Aperçu dans le service Red Hat OpenShift sur la console web AWS.

  2. Cliquez sur Insights sur la carte Statut.

    La fenêtre contextuelle répertorie les problèmes potentiels regroupés par risque. Cliquez sur les catégories individuelles ou affichez toutes les recommandations dans Insights Advisor pour afficher plus de détails.

5.4. En utilisant l’opérateur Insights
Copier lien

L’opérateur Insights recueille périodiquement l’état de défaillance de la configuration et des composants et, par défaut, rapporte les données toutes les deux heures à Red Hat. Ces informations permettent à Red Hat d’évaluer les données de configuration et d’échec plus profondes que celles rapportées par Télémétrie. Les utilisateurs de Red Hat OpenShift Service sur AWS peuvent afficher le rapport dans le service Insights Advisor sur Red Hat Hybrid Cloud Console.

5.4.1. Comprendre Insights Alertes des opérateurs
Copier lien

L’opérateur Insights déclare les alertes par l’intermédiaire du système de surveillance Prometheus au Alertmanager. Ces alertes peuvent être affichées dans l’interface utilisateur d’alerte dans le service OpenShift Red Hat sur la console web AWS en utilisant l’une des méthodes suivantes:

  • Dans la perspective Administrateur, cliquez sur Observer → Alerter.
  • Dans la perspective Développeur, cliquez sur Observer → &lt;project_name&gt; → Alertes.

Actuellement, Insights Operator envoie les alertes suivantes lorsque les conditions sont remplies:

Expand
Tableau 5.1. Alertes de l’opérateur
AlerteDescription

InsightsDisabled

Insight Operator est désactivé.

Accès à SimpleContentNotAvailable

L’accès au contenu simple n’est pas activé dans Red Hat Subscription Management.

InsightsRecommandationActive

Insights a une recommandation active pour le cluster.

Les administrateurs de cluster peuvent configurer l’opérateur Insight pour obfusquer les données de l’opérateur de validation du déploiement (DVO), si l’opérateur est installé. Lorsque la valeur load_names est ajoutée à l’objet ConfigMap, les noms de charge de travail - plutôt que les UID - sont affichés dans Insights for Openshift, ce qui les rend plus reconnaissables pour les administrateurs de clusters.

Conditions préalables

  • Les rapports de santé à distance sont activés, ce qui est le défaut.
  • Connectez-vous au service Red Hat OpenShift sur la console web AWS avec le rôle "cluster-admin".
  • L’objet Insight-config ConfigMap existe dans l’espace de noms openshift-insights.
  • Le cluster est autogéré et l’opérateur de validation du déploiement est installé.

Procédure

  1. Allez dans Charges de travail → ConfigMaps et sélectionnez Project: openshift-insights.
  2. Cliquez sur l’objet Insight-config ConfigMap pour l’ouvrir.
  3. Cliquez sur Actions et sélectionnez Modifier ConfigMap.
  4. Cliquez sur le bouton YAML view radio.

  5. Dans le fichier, définissez l’attribut obfuscation avec la valeur workload_names. 

    apiVersion: v1
kind: ConfigMap
# ...
data:
  config.yaml: |
    dataReporting:
      obfuscation:
        - workload_names
# ...
    Copy to Clipboard Toggle word wrap
  6. Cliquez sur Save. La page de détails Insight-config config-map s’ouvre.
  7. Assurez-vous que la valeur de l’attribut d’obfuscation config.yaml est définie sur - workload_names.

Chapitre 6. Collecte de données sur votre cluster
Copier lien

Lors de l’ouverture d’un cas de support, il est utile de fournir des informations de débogage sur votre cluster à Red Hat Support.

Il est recommandé de fournir:

6.1. À propos de l’outil must-collectther
Copier lien

La commande oc adm must-collectther CLI recueille les informations de votre cluster qui sont très probablement nécessaires pour le débogage des problèmes, y compris:

  • Définitions des ressources
  • Journaux de service

La commande oc adm must-collectther utilise l’image du plugin par défaut et écrit dans ./must-collectther.local.

Alternativement, vous pouvez collecter des informations spécifiques en exécutant la commande avec les arguments appropriés comme décrit dans les sections suivantes:

  • Afin de recueillir des données relatives à une ou plusieurs fonctionnalités spécifiques, utilisez l’argument --image avec une image, comme indiqué dans une section suivante.

    À titre d’exemple: 

    $ oc adm must-gather \
  --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.18.0
    Copy to Clipboard Toggle word wrap

  • Afin de collecter les journaux d’audit, utilisez l’argument -- /usr/bin/collect_audit_logs, comme décrit dans une section suivante.

    À titre d’exemple: 

    $ oc adm must-gather -- /usr/bin/gather_audit_logs
    Copy to Clipboard Toggle word wrap
    Note

    Les journaux d’audit ne sont pas recueillis dans le cadre de l’ensemble d’informations par défaut pour réduire la taille des fichiers.

Lorsque vous exécutez oc adm must-collectther, un nouveau pod avec un nom aléatoire est créé dans un nouveau projet sur le cluster. Les données sont collectées sur ce pod et enregistrées dans un nouveau répertoire qui commence par must-collectther.local dans le répertoire de travail actuel.

À titre d’exemple: 

NAMESPACE                      NAME                 READY   STATUS      RESTARTS      AGE
...
openshift-must-gather-5drcj    must-gather-bklx4    2/2     Running     0             72s
openshift-must-gather-5drcj    must-gather-s8sdh    2/2     Running     0             72s
...
Copy to Clipboard Toggle word wrap

En option, vous pouvez exécuter la commande oc adm must-collectther dans un espace de noms spécifique en utilisant l’option --run-namespace.

À titre d’exemple: 

$ oc adm must-gather --run-namespace <namespace> \
  --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.18.0
Copy to Clipboard Toggle word wrap

Il est possible de recueillir des informations de débogage sur votre cluster à l’aide de la commande oc adm must-collectther CLI.

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle cluster-admin.
  • L’OpenShift CLI (oc) est installé.

Procédure

  1. Accédez au répertoire dans lequel vous souhaitez stocker les données must-gather.

  2. Exécutez la commande oc adm must-collectther: 

    $ oc adm must-gather
    Copy to Clipboard Toggle word wrap
    Note

    Comme cette commande sélectionne un nœud de plan de contrôle aléatoire par défaut, le pod peut être programmé dans un nœud de plan de contrôle qui est dans l’état NotReady et SchedulingDisabled.

    1. En cas d’échec de cette commande, par exemple, si vous ne pouvez pas programmer un pod sur votre cluster, utilisez la commande d’inspection oc adm pour recueillir des informations pour des ressources particulières.

      Note

      Contactez Red Hat Support pour obtenir les ressources recommandées.

  3. Créez un fichier compressé à partir du répertoire must-collectther qui vient d’être créé dans votre répertoire de travail. À titre d’exemple, sur un ordinateur qui utilise un système d’exploitation Linux, exécutez la commande suivante: 

    $ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/
    1
    Copy to Clipboard Toggle word wrap
    1
    Assurez-vous de remplacer must-collectther-local.5421342344627712289/ par le nom de répertoire réel.
  4. Joindre le fichier compressé à votre dossier d’assistance sur la page Assistance clientèle du portail client Red Hat.

6.1.2. Drapeaux à collectionner
Copier lien

Les drapeaux listés dans le tableau suivant sont disponibles à utiliser avec la commande oc adm must-collectther.

Expand
Tableau 6.1. Le Red Hat OpenShift Service sur les drapeaux AWS pour oc adm must-collectther
DrapeauCommande d’exempleDescription

--toutes les images

ajouter au panier OC adm must-collectther --all-images=false

Collectez des données à collecter à l’aide de l’image par défaut pour tous les opérateurs du cluster qui sont annotés avec operators.openshift.io/must-collect-image.

--dest-dir

ajouter au panier OC adm must-collectther --dest-dir='&lt;directory_name&gt;'

Définissez un répertoire spécifique sur la machine locale où les données recueillies sont écrites.

--host-network

ajouter au panier OC adm must-collectther --host-network=false

Exécutez des pods must-collectther comme hostNetwork: true. Pertinent si une commande et une image spécifiques doivent capturer des données de niveau hôte.

--image

adm OC must-collectther --image=[&lt;plugin_image&gt;]

Indiquez une image de plugin must-gather à exécuter. Dans le cas contraire, Red Hat OpenShift Service sur l’image must-collectther par défaut d’AWS est utilisée.

--image-stream

ajouter au panier OC adm must-collectther --image-stream=[&lt;image_stream&gt;]

Indiquez un '&lt;image_stream&gt;' à l’aide d’un espace de noms ou d’une valeur name:tag contenant une image de plugin must-gather à exécuter.

--nom de node

ajouter au panier OC adm must-collectther --node-name='&lt;node&gt;'

Définissez un nœud spécifique à utiliser. Dans le cas contraire, un maître aléatoire est utilisé par défaut.

--sélecteur de nœuds

adm OC must-collectther --node-selector='&lt;node_selector_name&gt;'

Définissez un sélecteur de nœud spécifique à utiliser. Ce n’est pertinent que lorsque vous spécifiez une commande et une image qui doivent capturer des données sur un ensemble de nœuds de cluster simultanément.

--run-namespace

ajouter au panier OC adm must-collectther --run-namespace='&lt;namespace&gt;'

Il s’agit d’un espace de noms privilégié où les pods must-collectther devraient s’exécuter. Dans le cas contraire, un espace de noms temporaire est généré.

--depuis

ajouter au panier OC adm must-collectther --depuis=&lt;time&gt;

Les journaux de retour sont seulement plus récents que la durée spécifiée. Défaut à tous les journaux. Les plugins sont encouragés mais ne sont pas nécessaires pour soutenir cela. Il n’y en a qu’un depuis ou depuis.

--depuis le temps

adm OC must-collectther --depuis-time=&lt;date_and_time&gt;'

Les journaux de retour seulement après une date et une heure spécifiques, exprimés en format (RFC3339). Défaut à tous les journaux. Les plugins sont encouragés mais ne sont pas nécessaires pour soutenir cela. Il n’y en a qu’un depuis ou depuis.

--source-dir

ajouter au panier OC adm must-collectther --source-dir='/&lt;directory_name&gt;/'

Définissez le répertoire spécifique sur le pod où vous copiez les données recueillies.

--timeout

adm OC must-collectther --timeout=&lt;time&gt;'

La durée de collecte des données avant l’expiration, exprimée en secondes, minutes ou heures, par exemple 3s, 5m ou 2h. Le temps spécifié doit être supérieur à zéro. Défaut à 10 minutes s’il n’est pas spécifié.

--volume-pourcentage

adm OC must-massage --volume-pourcentage=&lt;pourcentage&gt;

Indiquez le pourcentage maximal du volume alloué de pod qui peut être utilisé pour la collecte obligatoire. En cas de dépassement de cette limite, le must-collectther cesse de recueillir, mais toujours des copies recueillies. Défaut à 30% si elle n’est pas spécifiée.

Il est possible de collecter des informations de débogage sur des fonctionnalités spécifiques en utilisant la commande oc adm must-collectther CLI avec l’argument --image ou --image-stream. L’outil must-collectther prend en charge plusieurs images, de sorte que vous pouvez collecter des données sur plus d’une fonctionnalité en exécutant une seule commande.

Expand
Tableau 6.2. Images à collectionner supportées
ImageBut

Registry.redhat.io/container-native-virtualization/cnv-must-collectther-rhel9:v4.18.0

Collecte de données pour OpenShift Virtualization.

Registry.redhat.io/openshift-serverless-1/svls-must-collectther-rhel8

Collecte de données pour OpenShift Serverless.

Registry.redhat.io/openshift-service-mesh/istio-must-collectther-rhel8:&lt;installed_version_service_mesh&gt;

Collecte de données pour Red Hat OpenShift Service Mesh.

Registry.redhat.io/rhmtc/openshift-migration-must-collectther-rhel8:v&lt;installed_version_migration_toolkit&gt;

Collecte de données pour la boîte à outils de migration pour conteneurs.

Registry.redhat.io/openshift-logging/cluster-logging-rhel9-operator:v&lt;installed_version_logging&gt;

Collecte de données pour l’enregistrement.

à propos de Quay.io/netobserv/must-collectther

Collecte de données pour l’opérateur d’observation du réseau.

Registry.redhat.io/openshift-gitops-1/must-collectther-rhel8:v&lt;installed_version_GitOps&gt;

Collecte de données pour Red Hat OpenShift GitOps.

Registry.redhat.io/openshift4/ose-secrets-store-csi-mustgather-rhel9:v&lt;installé_version_secret_store&gt;

Collecte de données pour l’opérateur de conducteur CSI Store Secrets Store.

Note

Afin de déterminer la dernière version d’un service Red Hat OpenShift sur l’image du composant AWS, consultez la page Web OpenShift Operator Cycles sur le portail client Red Hat.

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle cluster-admin.
  • L’OpenShift CLI (oc) est installé.

Procédure

  1. Accédez au répertoire dans lequel vous souhaitez stocker les données must-gather.

  2. Exécutez la commande oc adm must-collectther avec un ou plusieurs arguments --image ou --image-stream.

    Note
    • Ajoutez l’argument --image-stream=openshift/must-collectther pour collecter les données par défaut en plus des caractéristiques spécifiques.

    À titre d’exemple, la commande suivante recueille à la fois les données du cluster par défaut et les informations spécifiques à OpenShift Virtualization: 

    $ oc adm must-gather \
  --image-stream=openshift/must-gather \
    1 
    
  --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.18.0
    2
    Copy to Clipboard Toggle word wrap
    1
    Le service par défaut Red Hat OpenShift sur AWS must-collectther image
    2
    L’image incontournable pour OpenShift Virtualization

    Il est possible d’utiliser l’outil must-collectther avec des arguments supplémentaires pour recueillir des données spécifiquement liées à OpenShift Logging et à l’opérateur de journalisation Red Hat OpenShift dans votre cluster. Dans OpenShift Logging, exécutez la commande suivante: 

    $ oc adm must-gather --image=$(oc -n openshift-logging get deployment.apps/cluster-logging-operator \
  -o jsonpath='{.spec.template.spec.containers[?(@.name == "cluster-logging-operator")].image}')
    Copy to Clipboard Toggle word wrap

    Exemple 6.1. Exemple de sortie must-collectther pour OpenShift Logging

    ├── cluster-logging
│  ├── clo
│  │  ├── cluster-logging-operator-74dd5994f-6ttgt
│  │  ├── clusterlogforwarder_cr
│  │  ├── cr
│  │  ├── csv
│  │  ├── deployment
│  │  └── logforwarding_cr
│  ├── collector
│  │  ├── fluentd-2tr64
│  ├── eo
│  │  ├── csv
│  │  ├── deployment
│  │  └── elasticsearch-operator-7dc7d97b9d-jb4r4
│  ├── es
│  │  ├── cluster-elasticsearch
│  │  │  ├── aliases
│  │  │  ├── health
│  │  │  ├── indices
│  │  │  ├── latest_documents.json
│  │  │  ├── nodes
│  │  │  ├── nodes_stats.json
│  │  │  └── thread_pool
│  │  ├── cr
│  │  ├── elasticsearch-cdm-lp8l38m0-1-794d6dd989-4jxms
│  │  └── logs
│  │     ├── elasticsearch-cdm-lp8l38m0-1-794d6dd989-4jxms
│  ├── install
│  │  ├── co_logs
│  │  ├── install_plan
│  │  ├── olmo_logs
│  │  └── subscription
│  └── kibana
│     ├── cr
│     ├── kibana-9d69668d4-2rkvz
├── cluster-scoped-resources
│  └── core
│     ├── nodes
│     │  ├── ip-10-0-146-180.eu-west-1.compute.internal.yaml
│     └── persistentvolumes
│        ├── pvc-0a8d65d9-54aa-4c44-9ecc-33d9381e41c1.yaml
├── event-filter.html
├── gather-debug.log
└── namespaces
   ├── openshift-logging
   │  ├── apps
   │  │  ├── daemonsets.yaml
   │  │  ├── deployments.yaml
   │  │  ├── replicasets.yaml
   │  │  └── statefulsets.yaml
   │  ├── batch
   │  │  ├── cronjobs.yaml
   │  │  └── jobs.yaml
   │  ├── core
   │  │  ├── configmaps.yaml
   │  │  ├── endpoints.yaml
   │  │  ├── events
   │  │  │  ├── elasticsearch-im-app-1596020400-gm6nl.1626341a296c16a1.yaml
   │  │  │  ├── elasticsearch-im-audit-1596020400-9l9n4.1626341a2af81bbd.yaml
   │  │  │  ├── elasticsearch-im-infra-1596020400-v98tk.1626341a2d821069.yaml
   │  │  │  ├── elasticsearch-im-app-1596020400-cc5vc.1626341a3019b238.yaml
   │  │  │  ├── elasticsearch-im-audit-1596020400-s8d5s.1626341a31f7b315.yaml
   │  │  │  ├── elasticsearch-im-infra-1596020400-7mgv8.1626341a35ea59ed.yaml
   │  │  ├── events.yaml
   │  │  ├── persistentvolumeclaims.yaml
   │  │  ├── pods.yaml
   │  │  ├── replicationcontrollers.yaml
   │  │  ├── secrets.yaml
   │  │  └── services.yaml
   │  ├── openshift-logging.yaml
   │  ├── pods
   │  │  ├── cluster-logging-operator-74dd5994f-6ttgt
   │  │  │  ├── cluster-logging-operator
   │  │  │  │  └── cluster-logging-operator
   │  │  │  │     └── logs
   │  │  │  │        ├── current.log
   │  │  │  │        ├── previous.insecure.log
   │  │  │  │        └── previous.log
   │  │  │  └── cluster-logging-operator-74dd5994f-6ttgt.yaml
   │  │  ├── cluster-logging-operator-registry-6df49d7d4-mxxff
   │  │  │  ├── cluster-logging-operator-registry
   │  │  │  │  └── cluster-logging-operator-registry
   │  │  │  │     └── logs
   │  │  │  │        ├── current.log
   │  │  │  │        ├── previous.insecure.log
   │  │  │  │        └── previous.log
   │  │  │  ├── cluster-logging-operator-registry-6df49d7d4-mxxff.yaml
   │  │  │  └── mutate-csv-and-generate-sqlite-db
   │  │  │     └── mutate-csv-and-generate-sqlite-db
   │  │  │        └── logs
   │  │  │           ├── current.log
   │  │  │           ├── previous.insecure.log
   │  │  │           └── previous.log
   │  │  ├── elasticsearch-cdm-lp8l38m0-1-794d6dd989-4jxms
   │  │  ├── elasticsearch-im-app-1596030300-bpgcx
   │  │  │  ├── elasticsearch-im-app-1596030300-bpgcx.yaml
   │  │  │  └── indexmanagement
   │  │  │     └── indexmanagement
   │  │  │        └── logs
   │  │  │           ├── current.log
   │  │  │           ├── previous.insecure.log
   │  │  │           └── previous.log
   │  │  ├── fluentd-2tr64
   │  │  │  ├── fluentd
   │  │  │  │  └── fluentd
   │  │  │  │     └── logs
   │  │  │  │        ├── current.log
   │  │  │  │        ├── previous.insecure.log
   │  │  │  │        └── previous.log
   │  │  │  ├── fluentd-2tr64.yaml
   │  │  │  └── fluentd-init
   │  │  │     └── fluentd-init
   │  │  │        └── logs
   │  │  │           ├── current.log
   │  │  │           ├── previous.insecure.log
   │  │  │           └── previous.log
   │  │  ├── kibana-9d69668d4-2rkvz
   │  │  │  ├── kibana
   │  │  │  │  └── kibana
   │  │  │  │     └── logs
   │  │  │  │        ├── current.log
   │  │  │  │        ├── previous.insecure.log
   │  │  │  │        └── previous.log
   │  │  │  ├── kibana-9d69668d4-2rkvz.yaml
   │  │  │  └── kibana-proxy
   │  │  │     └── kibana-proxy
   │  │  │        └── logs
   │  │  │           ├── current.log
   │  │  │           ├── previous.insecure.log
   │  │  │           └── previous.log
   │  └── route.openshift.io
   │     └── routes.yaml
   └── openshift-operators-redhat
      ├── ...
    Copy to Clipboard Toggle word wrap

  3. Exécutez la commande oc adm must-collectther avec un ou plusieurs arguments --image ou --image-stream. À titre d’exemple, la commande suivante recueille à la fois les données de cluster par défaut et les informations spécifiques à KubeVirt: 

    $ oc adm must-gather \
 --image-stream=openshift/must-gather \
    1 
    
 --image=quay.io/kubevirt/must-gather
    2
    Copy to Clipboard Toggle word wrap
    1
    Le service par défaut Red Hat OpenShift sur AWS must-collectther image
    2
    L’image incontournable pour KubeVirt

  4. Créez un fichier compressé à partir du répertoire must-collectther qui vient d’être créé dans votre répertoire de travail. À titre d’exemple, sur un ordinateur qui utilise un système d’exploitation Linux, exécutez la commande suivante: 

    $ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/
    1
    Copy to Clipboard Toggle word wrap
    1
    Assurez-vous de remplacer must-collectther-local.5421342344627712289/ par le nom de répertoire réel.
  5. Joindre le fichier compressé à votre dossier d’assistance sur la page Assistance clientèle du portail client Red Hat.

6.1.4. Collecte des journaux de réseau
Copier lien

Il est possible de recueillir des journaux réseau sur tous les nœuds d’un cluster.

Procédure

  1. Exécutez la commande oc adm must-collectther avec -- collect_network_logs: 

    $ oc adm must-gather -- gather_network_logs
    Copy to Clipboard Toggle word wrap
    Note

    L’outil must-collectther collecte par défaut les bases de données OVN nbdb et sbdb à partir de tous les nœuds du cluster. Ajout de l’option --collect_network_logs pour inclure des journaux supplémentaires qui contiennent des transactions OVN-Kubernetes pour la base de données OVN nbdb.

  2. Créez un fichier compressé à partir du répertoire must-collectther qui vient d’être créé dans votre répertoire de travail. À titre d’exemple, sur un ordinateur qui utilise un système d’exploitation Linux, exécutez la commande suivante: 

    $ tar cvaf must-gather.tar.gz must-gather.local.472290403699006248
    1
    Copy to Clipboard Toggle word wrap
    1
    Il suffit de remplacer must-collectther-local.472290403699006248 par le nom du répertoire.
  3. Joindre le fichier compressé à votre dossier d’assistance sur la page Assistance clientèle du portail client Red Hat.

6.1.5. Changement de la limite de stockage de must-collectther
Copier lien

Lors de l’utilisation de la commande oc adm must-collectther pour collecter des données, le stockage maximum par défaut pour l’information est de 30% de la capacité de stockage du conteneur. Après que la limite de 30% est atteinte, le conteneur est tué et le processus de collecte s’arrête. Les informations déjà collectées sont téléchargées dans votre stockage local. Afin d’exécuter à nouveau la commande must-collectther, vous avez besoin soit d’un conteneur avec plus de capacité de stockage, soit d’ajuster le pourcentage de volume maximal.

Lorsque le conteneur atteint la limite de stockage, un message d’erreur similaire à l’exemple suivant est généré.

Exemple de sortie

Disk usage exceeds the volume percentage of 30% for mounted directory. Exiting...
Copy to Clipboard Toggle word wrap

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle cluster-admin.
  • L’OpenShift CLI (oc) est installé.

Procédure

  • Exécutez la commande oc adm must-collectther avec l’indicateur volume-pourcentage. La nouvelle valeur ne peut pas dépasser 100. 

    $ oc adm must-gather --volume-percentage <storage_percentage>
    Copy to Clipboard Toggle word wrap

6.2. L’obtention de votre identifiant de cluster
Copier lien

Lorsque vous fournissez des informations à Red Hat Support, il est utile de fournir l’identifiant unique pour votre cluster. Le cluster ID peut être rempli automatiquement en utilisant le service Red Hat OpenShift sur la console web AWS. En outre, vous pouvez obtenir manuellement votre identifiant de cluster à l’aide de la console Web ou de l’OpenShift CLI (oc).

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle d’administrateur dédié.
  • Accès à la console Web ou à l’OpenShift CLI (oc) installé.

Procédure

  • Afin d’obtenir manuellement votre identifiant de cluster à l’aide d’OpenShift Cluster Manager:

    1. Accédez à la liste des clusters.
    2. Cliquez sur le nom du cluster pour lequel vous devez ouvrir un dossier de support.
    3. Cherchez la valeur dans le champ ID du cluster de la section Détails de l’onglet Aperçu.

  • D’ouvrir un cas de support et d’avoir votre identifiant de cluster autorempli à l’aide de la console web:

    1. De la barre d’outils, accédez à (?) Aidez et sélectionnez Partager les commentaires dans la liste.
    2. Cliquez sur Ouvrir un cas d’assistance dans la fenêtre de votre expérience.

  • Afin d’obtenir manuellement votre identifiant de cluster à l’aide de la console web:

    1. Accédez à Home → Aperçu.
    2. La valeur est disponible dans le champ ID du cluster de la section Détails.

  • Afin d’obtenir votre identifiant de cluster à l’aide de l’OpenShift CLI (oc), exécutez la commande suivante: 

    $ oc get clusterversion -o jsonpath='{.items[].spec.clusterID}{"\n"}'
    Copy to Clipboard Toggle word wrap

6.3. Journal de journal des nœuds de cluster de requêtes
Copier lien

Il est possible de recueillir des journaux d’unités et d’autres journaux dans /var/log sur des nœuds de cluster individuels.

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle cluster-admin.
  • L’OpenShift CLI (oc) a été installé.

Procédure

  1. Interrogez les journaux d’unités de kubelet de Red Hat OpenShift Service sur les nœuds de cluster AWS. L’exemple suivant des requêtes de contrôle des nœuds de plan seulement: 

    $ oc adm node-logs --role=master -u kubelet
    1
    Copy to Clipboard Toggle word wrap
    1
    Le cas échéant, remplacer le kubelet pour interroger d’autres journaux d’unités.

  2. Collectez les journaux à partir de sous-répertoires spécifiques sous /var/log/ sur les nœuds de cluster.

    1. Consultez la liste des journaux contenus dans un sous-répertoire /var/log/. L’exemple suivant répertorie les fichiers dans /var/log/openshift-apiserver/ sur tous les nœuds de plan de contrôle: 

      $ oc adm node-logs --role=master --path=openshift-apiserver
      Copy to Clipboard Toggle word wrap

    2. Inspecter un journal spécifique dans un sous-répertoire /var/log/. L’exemple suivant de sortie /var/log/openshift-apiserver/audit.log contenu à partir de tous les nœuds de plan de contrôle: 

      $ oc adm node-logs --role=master --path=openshift-apiserver/audit.log
      Copy to Clipboard Toggle word wrap

6.4. Les méthodes de trace du réseau
Copier lien

La collecte de traces de réseau, sous la forme d’enregistrements de capture de paquets, peut aider Red Hat Support à résoudre les problèmes de réseau.

Le service OpenShift Red Hat sur AWS prend en charge deux façons d’effectuer une trace réseau. Consultez le tableau suivant et choisissez la méthode qui répond à vos besoins.

Expand
Tableau 6.3. Les méthodes prises en charge pour la collecte d’une trace de réseau
La méthodeAvantages et capacités

Collecte d’une trace du réseau hôte

Effectuer une capture de paquets pendant une durée que vous spécifiez sur un ou plusieurs nœuds en même temps. Les fichiers de capture de paquets sont transférés des nœuds à la machine cliente lorsque la durée spécifiée est atteinte.

Il est possible de dépanner la raison pour laquelle une action spécifique déclenche des problèmes de communication réseau. Exécutez la capture de paquets, effectuez l’action qui déclenche le problème et utilisez les journaux pour diagnostiquer le problème.

Collecte d’une trace réseau à partir d’un service Red Hat OpenShift sur un nœud ou un conteneur AWS

Effectuer une capture de paquets sur un nœud ou un conteneur. Exécutez la commande tcpdump de manière interactive, de sorte que vous pouvez contrôler la durée de la capture de paquets.

Il est possible de démarrer manuellement la capture de paquets, de déclencher le problème de communication réseau, puis d’arrêter manuellement la capture de paquets.

Cette méthode utilise la commande chat et la redirection shell pour copier les données de capture de paquets du nœud ou du conteneur vers la machine cliente.

6.5. Collecte d’une trace du réseau hôte
Copier lien

Le dépannage d’un problème lié au réseau est parfois simplifié en traçant la communication réseau et en capturant des paquets sur plusieurs nœuds en même temps.

Il est possible d’utiliser une combinaison de la commande oc adm must-collectther et de l’image du conteneur register.redhat.io/openshift4/network-tools-rhel8 pour collecter des captures de paquets à partir de nœuds. L’analyse des captures de paquets peut vous aider à résoudre les problèmes de communication réseau.

La commande oc adm must-collectther est utilisée pour exécuter la commande tcpdump dans des pods sur des nœuds spécifiques. La commande tcpdump enregistre les captures de paquets dans les pods. Lorsque la commande tcpdump sort, la commande oc adm must-collectther transfère les fichiers avec les captures de paquets des pods à votre machine cliente.

Astuce

La commande d’échantillon dans la procédure suivante démontre l’exécution d’une capture de paquet avec la commande tcpdump. Cependant, vous pouvez exécuter n’importe quelle commande dans l’image conteneur spécifiée dans l’argument --image pour recueillir des informations de dépannage à partir de plusieurs nœuds en même temps.

Conditions préalables

  • En tant qu’utilisateur, vous êtes connecté à Red Hat OpenShift Service sur AWS avec le rôle de cluster-admin.
  • L’OpenShift CLI (oc) a été installé.

Procédure

  1. Exécutez une capture de paquets à partir du réseau hôte sur certains nœuds en exécutant la commande suivante: 

    $ oc adm must-gather \
    --dest-dir /tmp/captures \// <.>
    --source-dir '/tmp/tcpdump/' \// <.>
    --image registry.redhat.io/openshift4/network-tools-rhel8:latest \// <.>
    --node-selector 'node-role.kubernetes.io/worker' \// <.>
    --host-network=true \// <.>
    --timeout 30s \// <.>
    -- \
    tcpdump -i any \// <.>
    -w /tmp/tcpdump/%Y-%m-%dT%H:%M:%S.pcap -W 1 -G 300
    Copy to Clipboard Toggle word wrap

    &Lt;.&gt; l’argument --dest-dir spécifie que oc adm must-collectther stocke les captures de paquets dans des répertoires relatifs à /tmp/captures sur la machine cliente. &lt;.&gt; Lorsque tcpdump est exécuté dans le pod debug que oc adm must-collectther démarre, l’argument --source-dir spécifie que les captures de paquets sont temporairement stockées dans le répertoire /tmp/tcpdump sur le pod. &lt;.&gt; Le --image argument spécifie une image de conteneur qui inclut la commande tcpdump. &lt;.&gt; L’argument --node-selector et la valeur d’exemple spécifient pour effectuer les captures de paquets sur les nœuds de travail. Comme alternative, vous pouvez spécifier l’argument --node-name à la place pour exécuter la capture de paquets sur un seul nœud. En omettant à la fois l’argument --node-selector et l’argument --node-name, les captures de paquets sont effectuées sur tous les nœuds. &lt;.&gt; L’argument --host-network=true est requis pour que les captures de paquets soient effectuées sur les interfaces réseau du nœud. &lt;.&gt; L’argument --timeout et la valeur spécifient pour exécuter le pod debug pendant 30 secondes. Lorsque vous ne spécifiez pas l’argument --timeout et une durée, le pod debug s’exécute pendant 10 minutes. &lt;.&gt; L’argument -i pour la commande tcpdump spécifie pour capturer des paquets sur toutes les interfaces réseau. Comme alternative, vous pouvez spécifier un nom d’interface réseau.

  2. Effectuez l’action, telle que l’accès à une application Web, qui déclenche le problème de communication réseau tandis que la trace réseau capture des paquets.

  3. Examinez les fichiers de capture de paquets que oc adm doit recueillir transférés des pods à votre machine cliente: 

    tmp/captures
├── event-filter.html
├── ip-10-0-192-217-ec2-internal
    1 
    
│   └── registry-redhat-io-openshift4-network-tools-rhel8-sha256-bca...
│       └── 2022-01-13T19:31:31.pcap
├── ip-10-0-201-178-ec2-internal
    2 
    
│   └── registry-redhat-io-openshift4-network-tools-rhel8-sha256-bca...
│       └── 2022-01-13T19:31:30.pcap
├── ip-...
└── timestamp
    Copy to Clipboard Toggle word wrap
    1 2
    Les captures de paquets sont stockées dans des répertoires qui identifient le nom d’hôte, le conteneur et le nom de fichier. Dans le cas où vous n’avez pas spécifié l’argument --node-selector, le niveau de répertoire du nom d’hôte n’est pas présent.

Lors de l’enquête sur le réseau potentiel Red Hat OpenShift Service sur les problèmes AWS, Red Hat Support peut demander une trace de paquet réseau à partir d’un service Red Hat OpenShift spécifique sur le nœud de cluster AWS ou à partir d’un conteneur spécifique. La méthode recommandée pour capturer une trace réseau dans Red Hat OpenShift Service sur AWS est via un pod debug.

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle cluster-admin.
  • L’OpenShift CLI (oc) a été installé.
  • Il existe une pièce d’identité de l’affaire Red Hat Support.

Procédure

  1. D’obtenir une liste de nœuds de cluster: 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

  2. Entrez dans une session de débogage sur le nœud cible. Cette étape instancie un pod debug appelé &lt;node_name&gt;-debug: 

    $ oc debug node/my-cluster-node
    Copy to Clipboard Toggle word wrap

  3. Définissez /host comme le répertoire racine dans le shell debug. Le pod debug monte le système de fichiers racine de l’hôte dans /host dans le pod. En changeant le répertoire root en /host, vous pouvez exécuter des binaires contenus dans les chemins exécutables de l’hôte: 

    # chroot /host
    Copy to Clipboard Toggle word wrap

  4. À partir de la console d’environnement chroot, obtenez les noms de l’interface du nœud: 

    # ip ad
    Copy to Clipboard Toggle word wrap

  5. Démarrez un conteneur de boîte à outils, qui comprend les binaires et les plugins requis pour exécuter sosreport: 

    # toolbox
    Copy to Clipboard Toggle word wrap
    Note

    Lorsqu’un pod de boîte à outils existant est déjà en cours d’exécution, la commande toolbox affiche déjà «toolbox-». Essayer de commencer… Afin d’éviter les problèmes de tcpdump, supprimez le conteneur de boîte à outils en cours d’exécution avec podman rm toolbox- et créez un nouveau conteneur de boîte à outils.

  6. Initier une session tcpdump sur le nœud de cluster et rediriger la sortie vers un fichier de capture. Cet exemple utilise ens5 comme nom de l’interface: 

    $ tcpdump -nn -s 0 -i ens5 -w /host/var/tmp/my-cluster-node_$(date +%d_%m_%Y-%H_%M_%S-%Z).pcap
    1
    Copy to Clipboard Toggle word wrap
    1
    Le chemin du fichier de capture tcpdump est en dehors de l’environnement chroot parce que le conteneur de boîte à outils monte le répertoire racine de l’hôte à /host.

  7. Lorsqu’une capture tcpdump est requise pour un conteneur spécifique sur le nœud, suivez ces étapes.

    1. Déterminez l’identifiant du conteneur cible. La commande chroot host précède la commande crictl dans cette étape car le conteneur de boîte à outils monte le répertoire racine de l’hôte à /host: 

      # chroot /host crictl ps
      Copy to Clipboard Toggle word wrap

    2. Déterminez l’ID de processus du conteneur. Dans cet exemple, l’ID du conteneur est a7fe32346b120: 

      # chroot /host crictl inspect --output yaml a7fe32346b120 | grep 'pid' | awk '{print $2}'
      Copy to Clipboard Toggle word wrap

    3. Initier une session tcpdump sur le conteneur et rediriger la sortie vers un fichier de capture. Cet exemple utilise 49628 comme ID de processus du conteneur et ens5 comme nom d’interface. La commande nsenter entre l’espace de noms d’un processus cible et exécute une commande dans son espace de noms. parce que le processus cible dans cet exemple est l’ID de processus d’un conteneur, la commande tcpdump est exécutée dans l’espace de noms du conteneur à partir de l’hôte: 

      # nsenter -n -t 49628 -- tcpdump -nn -i ens5 -w /host/var/tmp/my-cluster-node-my-container_$(date +%d_%m_%Y-%H_%M_%S-%Z).pcap
      1
      Copy to Clipboard Toggle word wrap
      1
      Le chemin du fichier de capture tcpdump est en dehors de l’environnement chroot parce que le conteneur de boîte à outils monte le répertoire racine de l’hôte à /host.

  8. Fournissez le fichier de capture tcpdump à Red Hat Support pour analyse, en utilisant l’une des méthodes suivantes.

    • Envoyez le fichier dans une affaire de support Red Hat existante.

      1. Concaténer l’archive sosreport en exécutant la commande oc debug node/&lt;node_name&gt; et rediriger la sortie vers un fichier. Cette commande suppose que vous avez quitté la session de débogage précédente: 

        $ oc debug node/my-cluster-node -- bash -c 'cat /host/var/tmp/my-tcpdump-capture-file.pcap' > /tmp/my-tcpdump-capture-file.pcap
        1
        Copy to Clipboard Toggle word wrap
        1
        Le conteneur de débogage monte le répertoire racine de l’hôte à /host. Faites référence au chemin absolu à partir du répertoire racine du conteneur de débogage, y compris /host, lorsque vous spécifiez les fichiers cibles pour la concaténation.
      2. Accédez à un cas d’assistance existant dans la page d’assistance client du portail client Red Hat.
      3. Choisissez Attach fichiers et suivez les instructions pour télécharger le fichier.

6.7. Fournir des données diagnostiques à Red Hat Support
Copier lien

Lorsque vous enquêtez sur Red Hat OpenShift Service sur les problèmes AWS, Red Hat Support peut vous demander de télécharger des données de diagnostic dans un cas de support. Les fichiers peuvent être téléchargés dans un cas d’assistance via le portail client Red Hat.

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle cluster-admin.
  • L’OpenShift CLI (oc) a été installé.
  • Il existe une pièce d’identité de l’affaire Red Hat Support.

Procédure

  • Envoyer des données de diagnostic dans un cas de support Red Hat existant via le portail client Red Hat.

    1. Concaté un fichier de diagnostic contenu sur un service Red Hat OpenShift sur le nœud AWS en utilisant la commande oc debug node/&lt;node_name&gt; et rediriger la sortie vers un fichier. L’exemple suivant copie /host/var/tmp/my-diagnostic-data.tar.gz d’un conteneur debug vers /var/tmp/my-diagnostic-data.tar.gz: 

      $ oc debug node/my-cluster-node -- bash -c 'cat /host/var/tmp/my-diagnostic-data.tar.gz' > /var/tmp/my-diagnostic-data.tar.gz
      1
      Copy to Clipboard Toggle word wrap
      1
      Le conteneur de débogage monte le répertoire racine de l’hôte à /host. Faites référence au chemin absolu à partir du répertoire racine du conteneur de débogage, y compris /host, lorsque vous spécifiez les fichiers cibles pour la concaténation.
    2. Accédez à un cas d’assistance existant dans la page d’assistance client du portail client Red Hat.
    3. Choisissez Attach fichiers et suivez les instructions pour télécharger le fichier.

6.8. À propos de toolbox
Copier lien

la boîte à outils est un outil qui démarre un conteneur sur un système Red Hat Enterprise Linux CoreOS (RHCOS). L’outil est principalement utilisé pour démarrer un conteneur qui comprend les binaires et les plugins nécessaires pour exécuter des commandes telles que sosreport.

Le but principal d’un conteneur de boîte à outils est de recueillir des informations diagnostiques et de les fournir à Red Hat Support. Cependant, si des outils de diagnostic supplémentaires sont nécessaires, vous pouvez ajouter des paquets RPM ou exécuter une image qui est une alternative à l’image des outils de support standard.

Installation de paquets dans un conteneur de boîte à outils

L’exécution par défaut de la commande toolbox démarre un conteneur avec l’image Registry.redhat.io/rhel9/support-tools:dernière image. Cette image contient les outils de support les plus fréquemment utilisés. Lorsque vous avez besoin de collecter des données spécifiques aux nœuds qui nécessitent un outil de support qui ne fait pas partie de l’image, vous pouvez installer des paquets supplémentaires.

Conditions préalables

  • Accès à un nœud avec la commande oc debug node/&lt;node_name&gt;.
  • En tant qu’utilisateur, vous pouvez accéder à votre système avec des privilèges root.

Procédure

  1. Définissez /host comme le répertoire racine dans le shell debug. Le pod debug monte le système de fichiers racine de l’hôte dans /host dans le pod. En changeant le répertoire root en /host, vous pouvez exécuter des binaires contenus dans les chemins exécutables de l’hôte: 

    # chroot /host
    Copy to Clipboard Toggle word wrap

  2. Démarrez le conteneur de boîte à outils: 

    # toolbox
    Copy to Clipboard Toggle word wrap

  3. Installez le paquet supplémentaire, tel que wget: 

    # dnf install -y <package_name>
    Copy to Clipboard Toggle word wrap
Démarrage d’une image alternative avec boîte à outils

L’exécution par défaut de la commande toolbox démarre un conteneur avec l’image Registry.redhat.io/rhel9/support-tools:dernière image.

Note

Démarrez une image alternative en créant un fichier .toolboxrc et en spécifiant l’image à exécuter. Cependant, l’exécution d’une ancienne version de l’image des outils de support, telle que Registry.redhat.io/rhel8/support-tools:lastest, n’est pas prise en charge sur Red Hat OpenShift Service sur AWS 4.

Conditions préalables

  • Accès à un nœud avec la commande oc debug node/&lt;node_name&gt;.
  • En tant qu’utilisateur, vous pouvez accéder à votre système avec des privilèges root.

Procédure

  1. Définissez /host comme le répertoire racine dans le shell debug. Le pod debug monte le système de fichiers racine de l’hôte dans /host dans le pod. En changeant le répertoire root en /host, vous pouvez exécuter des binaires contenus dans les chemins exécutables de l’hôte: 

    # chroot /host
    Copy to Clipboard Toggle word wrap

  2. Facultatif: Si vous devez utiliser une image alternative au lieu de l’image par défaut, créez un fichier .toolboxrc dans le répertoire d’accueil pour l’ID d’utilisateur racine, et spécifiez les métadonnées de l’image: 

    REGISTRY=quay.io
    1 
    
IMAGE=fedora/fedora:latest
    2 
    
TOOLBOX_NAME=toolbox-fedora-latest
    3
    Copy to Clipboard Toggle word wrap
    1
    Facultatif: spécifiez un registre de conteneurs alternatif.
    2
    Indiquez une image alternative pour démarrer.
    3
    Facultatif: Spécifiez un nom alternatif pour le conteneur de boîte à outils.

  3. Démarrez un conteneur de boîte à outils en entrant la commande suivante: 

    # toolbox
    Copy to Clipboard Toggle word wrap
    Note

    Lorsqu’un pod de boîte à outils existant est déjà en cours d’exécution, la commande toolbox affiche déjà «toolbox-». Essayer de commencer… Afin d’éviter les problèmes avec les plugins sosreport, supprimez le conteneur de boîte à outils en cours d’exécution avec podman rm toolbox-, puis créez un nouveau conteneur de boîte à outils.

Chapitre 7. Cahier des charges des clusters
Copier lien

Il est possible d’obtenir un résumé de Red Hat OpenShift Service sur les spécifications du cluster AWS en interrogeant la ressource clusterversion.

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle d’administrateur dédié.
  • L’OpenShift CLI (oc) a été installé.

Procédure

  1. La version du cluster de requêtes, la disponibilité, la disponibilité et l’état général: 

    $ oc get clusterversion
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.13.8    True        False         8h      Cluster version is 4.13.8
    Copy to Clipboard Toggle word wrap

  2. Demandez un résumé détaillé des spécifications du cluster, de la disponibilité des mises à jour et de l’historique des mises à jour: 

    $ oc describe clusterversion
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    Name:         version
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  config.openshift.io/v1
Kind:         ClusterVersion
# ...
    Image:    quay.io/openshift-release-dev/ocp-release@sha256:a956488d295fe5a59c8663a4d9992b9b5d0950f510a7387dbbfb8d20fc5970ce
    URL:      https://access.redhat.com/errata/RHSA-2023:4456
    Version:  4.13.8
  History:
    Completion Time:    2023-08-17T13:20:21Z
    Image:              quay.io/openshift-release-dev/ocp-release@sha256:a956488d295fe5a59c8663a4d9992b9b5d0950f510a7387dbbfb8d20fc5970ce
    Started Time:       2023-08-17T12:59:45Z
    State:              Completed
    Verified:           false
    Version:            4.13.8
# ...
    Copy to Clipboard Toggle word wrap

Chapitre 8. Résolution de problèmes
Copier lien

8.1.1. Dépannage d’installation
Copier lien

Afficher les journaux d’installation:

  • Exécutez la commande suivante, en remplaçant &lt;cluster_name&gt; par le nom de votre cluster: 

    $ rosa logs install --cluster=<cluster_name>
    Copy to Clipboard Toggle word wrap

  • Afin de regarder les journaux, incluez le drapeau --watch: 

    $ rosa logs install --cluster=<cluster_name> --watch
    Copy to Clipboard Toggle word wrap

Afficher les journaux de désinstallation:

  • Exécutez la commande suivante, en remplaçant &lt;cluster_name&gt; par le nom de votre cluster: 

    $ rosa logs uninstall --cluster=<cluster_name>
    Copy to Clipboard Toggle word wrap

  • Afin de regarder les journaux, incluez le drapeau --watch: 

    $ rosa logs uninstall --cluster=<cluster_name> --watch
    Copy to Clipboard Toggle word wrap

Exécutez la commande suivante pour vérifier si votre compte AWS dispose des autorisations correctes. Cette commande vérifie les autorisations uniquement pour les clusters qui n’utilisent pas AWS Security Token Service (STS): 

$ rosa verify permissions
Copy to Clipboard Toggle word wrap

En cas d’erreur, double vérification pour vous assurer qu’un SCP n’est pas appliqué à votre compte AWS. Dans le cas où vous êtes tenu d’utiliser un SCP, consultez les Exigences Red Hat pour les abonnements au cloud client pour plus de détails sur le SCP minimum requis.

8.1.1.3. Contrôlez votre compte AWS et votre quota
Copier lien

Exécutez la commande suivante pour vérifier que vous avez le quota disponible sur votre compte AWS: 

$ rosa verify quota
Copy to Clipboard Toggle word wrap

Les quotas AWS changent en fonction de la région. Assurez-vous de vérifier votre quota pour la région AWS correcte. Lorsque vous devez augmenter votre quota, accédez à votre console AWS et demandez une augmentation de quota pour le service qui a échoué.

8.1.1.4. Courriels de notification AWS
Copier lien

Lors de la création d’un cluster, le service Red Hat OpenShift sur le service AWS crée de petites instances dans toutes les régions prises en charge. Cette vérification garantit que le compte AWS utilisé peut être déployé dans chaque région prise en charge.

Dans le cas des comptes AWS qui n’utilisent pas toutes les régions prises en charge, AWS peut envoyer un ou plusieurs courriels confirmant que « Votre demande d’accès aux ressources AWS a été validée ». En règle générale, l’expéditeur de ce courriel est aws-verification@amazon.com.

Il s’agit d’un comportement attendu puisque le service OpenShift Red Hat sur le service AWS valide la configuration de votre compte AWS.

8.2. Dépannage ROSA avec des installations de cluster HCP
Copier lien

Consultez les sections suivantes pour obtenir de l’aide pour l’installation de ROSA avec des clusters HCP.

Lorsque le ROSA avec le cluster HCP est dans l’état d’installation pendant plus de 30 minutes et n’est pas devenu prêt, assurez-vous que l’environnement de compte AWS est préparé pour les configurations de cluster requises. Lorsque l’environnement de compte AWS est correctement préparé pour les configurations de cluster requises, essayez de supprimer et de recréer le cluster. En cas de problème persistant, contactez le support.

Dans ROSA avec les clusters HCP, le service Red Hat OpenShift sur le serveur AWS OAuth est hébergé dans le compte AWS du service Red Hat tandis que le service de console Web est publié à l’aide du contrôleur d’entrée par défaut du cluster dans le compte AWS du cluster. Lorsque vous pouvez vous connecter à votre cluster à l’aide de l’OpenShift CLI (oc) mais que vous ne pouvez pas accéder au service Red Hat OpenShift sur la console web AWS, vérifiez que les critères suivants sont satisfaits:

  • Les charges de travail de la console sont en cours d’exécution.
  • L’équilibreur de charge du contrôleur d’entrée par défaut est actif.
  • Accès à la console à partir d’une machine qui dispose d’une connectivité réseau au réseau VPC du cluster.

Les clusters ROSA avec HCP retournent un statut prêt lorsque l’avion de contrôle hébergé dans le Red Hat OpenShift Service sur le compte de service AWS devient prêt. Les charges de travail de la console de cluster sont déployées sur les nœuds de travail du cluster. Le Red Hat OpenShift Service sur la console web AWS ne sera pas disponible et accessible tant que les nœuds de travail n’auront pas rejoint le cluster et les charges de travail de la console ne seront pas en cours d’exécution.

Lorsque votre ROSA avec le cluster HCP est prêt, mais que vous ne pouvez pas accéder au Red Hat OpenShift Service sur la console web AWS pour le cluster, attendez que les nœuds de travail rejoignent le cluster et réessayez d’accéder à la console.

Connectez-vous à la ROSA avec le cluster HCP ou utilisez la commande rosascript Machinepool dans la rosa CLI regarder les nœuds.

La console du cluster privé est privée par défaut. Lors de l’installation du cluster, le contrôleur Ingress par défaut géré par l’opérateur Ingress d’OpenShift est configuré avec un balanceur de charge réseau AWS interne (NLB).

Lorsque votre ROSA privé avec le cluster HCP affiche un statut prêt, mais que vous ne pouvez pas accéder au Red Hat OpenShift Service sur la console Web AWS pour le cluster, essayez d’accéder à la console cluster à partir du cluster VPC ou à partir d’un réseau connecté au VPC.

8.3. Dépannage du réseau
Copier lien

Ce document décrit comment résoudre les erreurs de réseau.

Le Red Hat OpenShift Service sur les clusters AWS créés avec la version 4 déploie AWS Network Load Balancers (NLB) par défaut pour le contrôleur d’entrée par défaut. Dans le cas d’une NLB privée, la préservation de l’adresse IP cliente de la NLB pourrait entraîner l’abandon des connexions là où la source et la destination sont le même hôte. Consultez la documentation d’AWS sur la façon de dépanner votre balanceur de charge réseau. Cette préservation de l’adresse IP a l’implication que toute charge de travail client cohabitant sur le même nœud avec les gousses de routeur peut ne pas être en mesure d’envoyer du trafic au NLB privé devant le routeur contrôleur d’entrée.

Afin d’atténuer cet impact, les clients devraient rééchelonner leurs charges de travail sur des nœuds distincts de ceux où les gousses de routeur sont programmées. Alternativement, les clients devraient compter sur la pod interne et les réseaux de services pour accéder à d’autres charges de travail co-localisées dans le même cluster.

8.4. La vérification de la santé des nœuds
Copier lien

Examiner l’état de santé des nœuds en grappe, les statistiques de consommation des ressources et les journaux des nœuds. En outre, interrogez l’état du kubelet sur les nœuds individuels.

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle d’administrateur dédié.
  • L’OpenShift CLI (oc) a été installé.

Procédure

  • Énumérez le nom, le statut et le rôle de tous les nœuds du cluster: 

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

  • De résumer l’utilisation du CPU et de la mémoire pour chaque nœud dans le cluster: 

    $ oc adm top nodes
    Copy to Clipboard Toggle word wrap

  • De résumer l’utilisation du CPU et de la mémoire pour un nœud spécifique: 

    $ oc adm top node my-node
    Copy to Clipboard Toggle word wrap

8.5. Dépannage des problèmes de l’opérateur
Copier lien

Les opérateurs sont une méthode d’emballage, de déploiement et de gestion d’un service OpenShift Red Hat sur l’application AWS. Ils agissent comme une extension de l’équipe d’ingénierie du fournisseur de logiciels, en surveillant un service OpenShift Red Hat sur l’environnement AWS et en utilisant son état actuel pour prendre des décisions en temps réel. Les opérateurs sont conçus pour gérer les mises à niveau de manière transparente, réagir aux pannes automatiquement et ne pas prendre de raccourcis, comme sauter un processus de sauvegarde logiciel pour gagner du temps.

Le service OpenShift Red Hat sur AWS 4 inclut un ensemble par défaut d’opérateurs qui sont nécessaires au bon fonctionnement du cluster. Ces opérateurs par défaut sont gérés par l’opérateur de versions de cluster (CVO).

En tant qu’administrateur de cluster, vous pouvez installer des opérateurs d’applications depuis OperatorHub à l’aide du service Red Hat OpenShift sur la console web AWS ou le CLI. Ensuite, vous pouvez abonner l’Opérateur à un ou plusieurs espaces de noms pour le rendre disponible pour les développeurs de votre cluster. Les opérateurs d’applications sont gérés par Operator Lifecycle Manager (OLM).

Lorsque vous rencontrez des problèmes d’opérateur, vérifiez l’état de l’abonnement de l’opérateur. Consultez la santé de la pod de l’opérateur à travers le cluster et rassemblez les journaux de l’opérateur pour le diagnostic.

8.5.1. Conditions d’abonnement à l’opérateur
Copier lien

Les abonnements peuvent signaler les types d’état suivants:

Expand
Tableau 8.1. Conditions d’abonnement
État de l’étatDescription

CatalogueSourcesUnsanté

Certaines ou toutes les sources de catalogue à utiliser en résolution sont malsaines.

InstallPlanMissing

Il manque un plan d’installation pour un abonnement.

InstallPlanPending

Le plan d’installation d’un abonnement est en attente d’installation.

InstallPlanFailed

Le plan d’installation d’un abonnement a échoué.

La RésolutionFailed

La résolution de dépendance pour un abonnement a échoué.

Note

Les opérateurs de clusters AWS sont gérés par l’opérateur de version CVO (Cluster Version Operator) et n’ont pas d’objet d’abonnement. Les opérateurs d’applications sont gérés par Operator Lifecycle Manager (OLM) et ils ont un objet d’abonnement.

En utilisant le CLI, vous pouvez voir l’état de l’abonnement à l’opérateur.

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle d’administrateur dédié.
  • L’OpenShift CLI (oc) a été installé.

Procédure

  1. Abonnements à l’opérateur de liste: 

    $ oc get subs -n <operator_namespace>
    Copy to Clipboard Toggle word wrap

  2. Consultez la commande de description d’oc pour inspecter une ressource d’abonnement: 

    $ oc describe sub <subscription_name> -n <operator_namespace>
    Copy to Clipboard Toggle word wrap

  3. Dans la sortie de commande, trouvez la section Conditions pour l’état des types de condition d’abonnement Opérateur. Dans l’exemple suivant, le type de condition de CatalogSourcesUnsanté a un statut de faux parce que toutes les sources de catalogue disponibles sont saines:

    Exemple de sortie

    Name:         cluster-logging
Namespace:    openshift-logging
Labels:       operators.coreos.com/cluster-logging.openshift-logging=
Annotations:  <none>
API Version:  operators.coreos.com/v1alpha1
Kind:         Subscription
# ...
Conditions:
   Last Transition Time:  2019-07-29T13:42:57Z
   Message:               all available catalogsources are healthy
   Reason:                AllCatalogSourcesHealthy
   Status:                False
   Type:                  CatalogSourcesUnhealthy
# ...
    Copy to Clipboard Toggle word wrap

Note

Les opérateurs de clusters AWS sont gérés par l’opérateur de version CVO (Cluster Version Operator) et n’ont pas d’objet d’abonnement. Les opérateurs d’applications sont gérés par Operator Lifecycle Manager (OLM) et ils ont un objet d’abonnement.

Il est possible d’afficher l’état d’une source de catalogue de l’opérateur à l’aide du CLI.

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle d’administrateur dédié.
  • L’OpenShift CLI (oc) a été installé.

Procédure

  1. Énumérez les sources du catalogue dans un espace de noms. À titre d’exemple, vous pouvez vérifier l’espace de noms openshift-marketplace, qui est utilisé pour les sources de catalogue à l’échelle du cluster: 

    $ oc get catalogsources -n openshift-marketplace
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME                  DISPLAY               TYPE   PUBLISHER   AGE
certified-operators   Certified Operators   grpc   Red Hat     55m
community-operators   Community Operators   grpc   Red Hat     55m
example-catalog       Example Catalog       grpc   Example Org 2m25s
redhat-marketplace    Red Hat Marketplace   grpc   Red Hat     55m
redhat-operators      Red Hat Operators     grpc   Red Hat     55m
    Copy to Clipboard Toggle word wrap

  2. La commande oc described permet d’obtenir plus de détails et d’état sur une source de catalogue: 

    $ oc describe catalogsource example-catalog -n openshift-marketplace
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    Name:         example-catalog
Namespace:    openshift-marketplace
Labels:       <none>
Annotations:  operatorframework.io/managed-by: marketplace-operator
              target.workload.openshift.io/management: {"effect": "PreferredDuringScheduling"}
API Version:  operators.coreos.com/v1alpha1
Kind:         CatalogSource
# ...
Status:
  Connection State:
    Address:              example-catalog.openshift-marketplace.svc:50051
    Last Connect:         2021-09-09T17:07:35Z
    Last Observed State:  TRANSIENT_FAILURE
  Registry Service:
    Created At:         2021-09-09T17:05:45Z
    Port:               50051
    Protocol:           grpc
    Service Name:       example-catalog
    Service Namespace:  openshift-marketplace
# ...
    Copy to Clipboard Toggle word wrap

    Dans l’exemple précédent, le dernier état observé est TRANSIENT_FAILURE. Cet état indique qu’il y a un problème à établir une connexion pour la source du catalogue.

  3. Énumérez les pods dans l’espace de noms où votre source de catalogue a été créée: 

    $ oc get pods -n openshift-marketplace
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME                                    READY   STATUS             RESTARTS   AGE
certified-operators-cv9nn               1/1     Running            0          36m
community-operators-6v8lp               1/1     Running            0          36m
marketplace-operator-86bfc75f9b-jkgbc   1/1     Running            0          42m
example-catalog-bwt8z                   0/1     ImagePullBackOff   0          3m55s
redhat-marketplace-57p8c                1/1     Running            0          36m
redhat-operators-smxx8                  1/1     Running            0          36m
    Copy to Clipboard Toggle word wrap

    Lorsqu’une source de catalogue est créée dans un espace de noms, un pod pour la source du catalogue est créé dans cet espace de noms. Dans l’exemple précédent, l’état de la pod example-catalog-bwt8z est ImagePullBackOff. Ce statut indique qu’il y a un problème à tirer l’image de l’index de la source du catalogue.

  4. Consultez la commande de description d’oc pour inspecter un pod pour obtenir des informations plus détaillées: 

    $ oc describe pod example-catalog-bwt8z -n openshift-marketplace
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    Name:         example-catalog-bwt8z
Namespace:    openshift-marketplace
Priority:     0
Node:         ci-ln-jyryyg2-f76d1-ggdbq-worker-b-vsxjd/10.0.128.2
...
Events:
  Type     Reason          Age                From               Message
  ----     ------          ----               ----               -------
  Normal   Scheduled       48s                default-scheduler  Successfully assigned openshift-marketplace/example-catalog-bwt8z to ci-ln-jyryyf2-f76d1-fgdbq-worker-b-vsxjd
  Normal   AddedInterface  47s                multus             Add eth0 [10.131.0.40/23] from openshift-sdn
  Normal   BackOff         20s (x2 over 46s)  kubelet            Back-off pulling image "quay.io/example-org/example-catalog:v1"
  Warning  Failed          20s (x2 over 46s)  kubelet            Error: ImagePullBackOff
  Normal   Pulling         8s (x3 over 47s)   kubelet            Pulling image "quay.io/example-org/example-catalog:v1"
  Warning  Failed          8s (x3 over 47s)   kubelet            Failed to pull image "quay.io/example-org/example-catalog:v1": rpc error: code = Unknown desc = reading manifest v1 in quay.io/example-org/example-catalog: unauthorized: access to the requested resource is not authorized
  Warning  Failed          8s (x3 over 47s)   kubelet            Error: ErrImagePull
    Copy to Clipboard Toggle word wrap

    Dans l’exemple précédent, les messages d’erreur indiquent que l’image d’index de la source du catalogue ne parvient pas à tirer avec succès en raison d’un problème d’autorisation. À titre d’exemple, l’image d’index peut être stockée dans un registre qui nécessite des identifiants de connexion.

8.5.4. État de la pod de l’opérateur d’interrogation
Copier lien

Il est possible de répertorier les pods d’opérateur dans un cluster et leur statut. Il est également possible de recueillir un résumé détaillé de la pod de l’opérateur.

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle d’administrateur dédié.
  • Le service API est toujours fonctionnel.
  • L’OpenShift CLI (oc) a été installé.

Procédure

  1. Liste Opérateurs fonctionnant dans le cluster. La sortie comprend la version de l’opérateur, la disponibilité et les informations de disponibilité: 

    $ oc get clusteroperators
    Copy to Clipboard Toggle word wrap

  2. Liste Les pods d’opérateur s’exécutant dans l’espace de noms de l’opérateur, plus le statut du pod, le redémarrage et l’âge: 

    $ oc get pod -n <operator_namespace>
    Copy to Clipboard Toggle word wrap

  3. Afficher un résumé détaillé de la pod de l’opérateur: 

    $ oc describe pod <operator_pod_name> -n <operator_namespace>
    Copy to Clipboard Toggle word wrap

8.5.5. Collecte des journaux de l’opérateur
Copier lien

Lorsque vous rencontrez des problèmes d’opérateur, vous pouvez recueillir des informations de diagnostic détaillées à partir des journaux de pod de l’opérateur.

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle d’administrateur dédié.
  • Le service API est toujours fonctionnel.
  • L’OpenShift CLI (oc) a été installé.
  • Les noms de domaine entièrement qualifiés des machines de plan de contrôle ou de contrôle sont disponibles.

Procédure

  1. Énumérez les pods d’opérateur qui s’exécutent dans l’espace de noms de l’opérateur, ainsi que le statut, le redémarrage et l’âge du pod: 

    $ oc get pods -n <operator_namespace>
    Copy to Clipboard Toggle word wrap

  2. Journaux d’examen pour une pod d’opérateur: 

    $ oc logs pod/<pod_name> -n <operator_namespace>
    Copy to Clipboard Toggle word wrap

    Dans le cas où une pod d’opérateur a plusieurs conteneurs, la commande précédente produira une erreur qui inclut le nom de chaque conteneur. Journal de requête à partir d’un conteneur individuel: 

    $ oc logs pod/<operator_pod_name> -c <container_name> -n <operator_namespace>
    Copy to Clipboard Toggle word wrap

  3. Lorsque l’API n’est pas fonctionnelle, examinez la pod et le conteneur de l’opérateur sur chaque nœud de plan de contrôle en utilisant SSH à la place. &lt;master-node&gt;.&lt;cluster_name&gt;.&lt;base_domain&gt; par des valeurs appropriées.

    1. Liste des gousses sur chaque nœud de plan de contrôle: 

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl pods
      Copy to Clipboard Toggle word wrap

    2. Dans le cas de n’importe quelle gousse d’opérateur qui ne montre pas d’état prêt, inspectez en détail l’état de la gousse. &lt;operator_pod_id&gt; par l’ID du pod de l’opérateur listé dans la sortie de la commande précédente: 

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspectp <operator_pod_id>
      Copy to Clipboard Toggle word wrap

    3. Liste des conteneurs liés à une pod d’opérateur: 

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps --pod=<operator_pod_id>
      Copy to Clipboard Toggle word wrap

    4. Dans le cas d’un conteneur de l’opérateur qui ne montre pas d’état prêt, inspectez en détail l’état du conteneur. &lt;container_id&gt; par un identifiant de conteneur listé dans la sortie de la commande précédente: 

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspect <container_id>
      Copy to Clipboard Toggle word wrap

    5. Examinez les journaux pour tous les conteneurs de l’opérateur qui ne montrent pas d’état prêt. &lt;container_id&gt; par un identifiant de conteneur listé dans la sortie de la commande précédente: 

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>
      Copy to Clipboard Toggle word wrap
      Note

      Le service OpenShift Red Hat sur les nœuds de cluster AWS 4 exécutant Red Hat Enterprise Linux CoreOS (RHCOS) est immuable et compte sur les opérateurs pour appliquer des modifications de cluster. L’accès aux nœuds de cluster en utilisant SSH n’est pas recommandé. Avant d’essayer de recueillir des données diagnostiques sur SSH, vérifiez si les données recueillies en exécutant oc adm doivent recueillir et si d’autres commandes oc sont suffisantes à la place. Cependant, si le service OpenShift Red Hat sur AWS API n’est pas disponible, ou si le kubelet ne fonctionne pas correctement sur le nœud cible, les opérations oc seront affectées. Dans de telles situations, il est possible d’accéder à des nœuds en utilisant ssh core@&lt;node&gt;.&lt;cluster_name&gt;.&lt;base_domain&gt;.

8.6. Enquêtant sur les questions relatives aux pod
Copier lien

Le Red Hat OpenShift Service sur AWS exploite le concept Kubernetes d’un pod, qui est un ou plusieurs conteneurs déployés ensemble sur un hôte. Le pod est la plus petite unité de calcul pouvant être définie, déployée et gérée sur Red Hat OpenShift Service sur AWS 4.

Après qu’un pod est défini, il est assigné à courir sur un nœud jusqu’à la sortie de ses conteneurs, ou jusqu’à ce qu’il soit retiré. En fonction de la stratégie et du code de sortie, les pods sont soit supprimés après la sortie, soit conservés afin que leurs journaux puissent être consultés.

La première chose à vérifier quand des problèmes de pod se posent est le statut de la gousse. En cas de défaillance explicite de la gousse, observez l’état d’erreur de la gousse pour identifier des problèmes spécifiques de réseau d’image, de conteneur ou de pod. Concentrez la collecte de données diagnostiques en fonction de l’état d’erreur. Examinez les messages d’événements pod, ainsi que les informations de journal des pod et des conteneurs. Diagnostiquez les problèmes de manière dynamique en accédant à des Pods en cours d’exécution sur la ligne de commande, ou démarrez un pod debug avec un accès root basé sur la configuration de déploiement d’un pod problématique.

8.6.1. Comprendre les états d’erreur de pod
Copier lien

Les échecs de pod renvoient des erreurs explicites qui peuvent être observées dans le champ d’état dans la sortie de oc get pods. L’erreur de Pod indique les défaillances liées à l’image, au conteneur et au réseau de conteneurs.

Le tableau suivant fournit une liste d’états d’erreur de pod ainsi que leurs descriptions.

Expand
Tableau 8.2. Les états d’erreur de pod
État d’erreur de podDescription

ErrImagePull

Erreur de récupération d’image générique.

ErrImagePullBackOff

La récupération d’image a échoué et est désactivée.

ErrInvalidImageName

Le nom de l’image spécifié était invalide.

ErrImageInspect

L’inspection d’images n’a pas réussi.

ErrImageNeverPull

Le PullPolicy est défini sur NeverPullImage et l’image cible n’est pas présente localement sur l’hôte.

ErrRegistryIndisponible

Lors de la tentative de récupérer une image à partir d’un registre, une erreur HTTP a été rencontrée.

ErrContainerNotFound

Le conteneur spécifié n’est pas présent ou n’est pas géré par le kubelet, à l’intérieur de la gousse déclarée.

ErrRunInitContainer

L’initialisation du conteneur a échoué.

ErrRunContainer

Aucun des conteneurs de la gousse n’a commencé avec succès.

ErrKillContainer

Aucun des conteneurs de la gousse n’a été tué avec succès.

ErrCrashLoopBackOff

Le conteneur s’est terminé. Le kubelet ne tentera pas de le redémarrer.

ErrVerifyNonRoot

Le conteneur ou l’image a tenté de fonctionner avec des privilèges root.

ErrCreatePodSandbox

La création de pod sandbox n’a pas réussi.

ErrConfigPodSandbox

La configuration du bac à sable pod n’a pas été obtenue.

ErrKillPodSandbox

Le bac à sable de gousse ne s’est pas arrêté avec succès.

ErrSetupNetwork

L’initialisation du réseau a échoué.

ErrTeardownNetwork

La terminaison du réseau a échoué.

8.6.2. Examen du statut de la gousse
Copier lien

Il est possible d’interroger l’état de la pod et les états d’erreur. Il est également possible d’interroger la configuration de déploiement associée d’un pod et d’examiner la disponibilité de l’image de base.

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle d’administrateur dédié.
  • L’OpenShift CLI (oc) a été installé.
  • le skopeo est installé.

Procédure

  1. Basculer dans un projet: 

    $ oc project <project_name>
    Copy to Clipboard Toggle word wrap

  2. Liste des pods fonctionnant dans l’espace de noms, ainsi que l’état des pod, les états d’erreur, les redémarrages et l’âge: 

    $ oc get pods
    Copy to Clipboard Toggle word wrap

  3. Déterminer si l’espace de noms est géré par une configuration de déploiement: 

    $ oc status
    Copy to Clipboard Toggle word wrap

    Lorsque l’espace de noms est géré par une configuration de déploiement, la sortie inclut le nom de configuration de déploiement et une référence d’image de base.

  4. Inspecter l’image de base référencée dans la sortie de la commande précédente: 

    $ skopeo inspect docker://<image_reference>
    Copy to Clipboard Toggle word wrap

  5. Lorsque la référence de l’image de base n’est pas correcte, mettez à jour la référence dans la configuration de déploiement: 

    $ oc edit deployment/my-deployment
    Copy to Clipboard Toggle word wrap

  6. Lorsque la configuration du déploiement change à la sortie, la configuration se redéploie automatiquement. Consultez l’état de la pod au fur et à mesure que le déploiement progresse, afin de déterminer si le problème a été résolu: 

    $ oc get pods -w
    Copy to Clipboard Toggle word wrap

  7. Examiner les événements dans l’espace de noms pour obtenir des informations diagnostiques relatives aux défaillances de pod: 

    $ oc get events
    Copy to Clipboard Toggle word wrap

8.6.3. Inspection de la gousse et des bûches de conteneurs
Copier lien

Il est possible d’inspecter les journaux des pod et des conteneurs pour détecter les avertissements et les messages d’erreur liés à des pannes explicites de pod. En fonction de la politique et du code de sortie, les journaux de pod et de conteneur restent disponibles après la fin des pods.

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle d’administrateur dédié.
  • Le service API est toujours fonctionnel.
  • L’OpenShift CLI (oc) a été installé.

Procédure

  1. Journaux de requêtes pour un pod spécifique: 

    $ oc logs <pod_name>
    Copy to Clipboard Toggle word wrap

  2. Journaux de requête pour un conteneur spécifique à l’intérieur d’un pod: 

    $ oc logs <pod_name> -c <container_name>
    Copy to Clipboard Toggle word wrap

    Les journaux récupérés à l’aide des commandes oc logs précédentes sont composés de messages envoyés à stdout dans des pods ou des conteneurs.

  3. Inspecter les journaux contenus dans /var/log/ dans un pod.

    1. Liste des fichiers journaux et sous-répertoires contenus dans /var/log dans un pod: 

      $ oc exec <pod_name>  -- ls -alh /var/log
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      total 124K
drwxr-xr-x. 1 root root   33 Aug 11 11:23 .
drwxr-xr-x. 1 root root   28 Sep  6  2022 ..
-rw-rw----. 1 root utmp    0 Jul 10 10:31 btmp
-rw-r--r--. 1 root root  33K Jul 17 10:07 dnf.librepo.log
-rw-r--r--. 1 root root  69K Jul 17 10:07 dnf.log
-rw-r--r--. 1 root root 8.8K Jul 17 10:07 dnf.rpm.log
-rw-r--r--. 1 root root  480 Jul 17 10:07 hawkey.log
-rw-rw-r--. 1 root utmp    0 Jul 10 10:31 lastlog
drwx------. 2 root root   23 Aug 11 11:14 openshift-apiserver
drwx------. 2 root root    6 Jul 10 10:31 private
drwxr-xr-x. 1 root root   22 Mar  9 08:05 rhsm
-rw-rw-r--. 1 root utmp    0 Jul 10 10:31 wtmp
      Copy to Clipboard Toggle word wrap

    2. Interrogez un fichier journal spécifique contenu dans /var/log dans un pod: 

      $ oc exec <pod_name> cat /var/log/<path_to_log>
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      2023-07-10T10:29:38+0000 INFO --- logging initialized ---
2023-07-10T10:29:38+0000 DDEBUG timer: config: 13 ms
2023-07-10T10:29:38+0000 DEBUG Loaded plugins: builddep, changelog, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, groups-manager, needs-restarting, playground, product-id, repoclosure, repodiff, repograph, repomanage, reposync, subscription-manager, uploadprofile
2023-07-10T10:29:38+0000 INFO Updating Subscription Management repositories.
2023-07-10T10:29:38+0000 INFO Unable to read consumer identity
2023-07-10T10:29:38+0000 INFO Subscription Manager is operating in container mode.
2023-07-10T10:29:38+0000 INFO
      Copy to Clipboard Toggle word wrap

    3. Liste des fichiers journaux et sous-répertoires contenus dans /var/log dans un conteneur spécifique: 

      $ oc exec <pod_name> -c <container_name> ls /var/log
      Copy to Clipboard Toggle word wrap

    4. Interrogez un fichier journal spécifique contenu dans /var/log dans un conteneur spécifique: 

      $ oc exec <pod_name> -c <container_name> cat /var/log/<path_to_log>
      Copy to Clipboard Toggle word wrap

8.6.4. Accès aux gousses en cours d’exécution
Copier lien

Il est possible de passer en revue dynamiquement les pods en ouvrant un shell à l’intérieur d’un pod ou en obtenant un accès réseau par le biais du transfert de port.

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle d’administrateur dédié.
  • Le service API est toujours fonctionnel.
  • L’OpenShift CLI (oc) a été installé.

Procédure

  1. Basculez dans le projet qui contient le pod auquel vous souhaitez accéder. Ceci est nécessaire parce que la commande oc rsh n’accepte pas l’option -n namespace: 

    $ oc project <namespace>
    Copy to Clipboard Toggle word wrap

  2. Démarrez une coque distante dans un pod: 

    $ oc rsh <pod_name>
    1
    Copy to Clipboard Toggle word wrap
    1
    Dans le cas où un pod a plusieurs conteneurs, oc rsh par défaut au premier conteneur, sauf si -c &lt;container_name&gt; est spécifié.

  3. Démarrez une coque distante dans un conteneur spécifique à l’intérieur d’un pod: 

    $ oc rsh -c <container_name> pod/<pod_name>
    Copy to Clipboard Toggle word wrap

  4. Créer une session de transfert de port vers un port sur un pod: 

    $ oc port-forward <pod_name> <host_port>:<pod_port>
    1
    Copy to Clipboard Toggle word wrap
    1
    Entrez Ctrl+C pour annuler la session de transfert de port.

8.6.5. Démarrage des gousses de débogage avec accès root
Copier lien

Il est possible de démarrer un pod debug avec un accès root, en fonction de la configuration de déploiement ou de déploiement d’un pod problématique. Les utilisateurs de Pod fonctionnent généralement avec des privilèges non-root, mais l’exécution de dosettes de dépannage avec des privilèges racine temporaires peut être utile lors de l’enquête sur les problèmes.

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle d’administrateur dédié.
  • Le service API est toujours fonctionnel.
  • L’OpenShift CLI (oc) a été installé.

Procédure

  1. Démarrez un pod debug avec un accès root, basé sur un déploiement.

    1. Obtenir le nom de déploiement d’un projet: 

      $ oc get deployment -n <project_name>
      Copy to Clipboard Toggle word wrap

    2. Démarrez un pod debug avec des privilèges root, en fonction du déploiement: 

      $ oc debug deployment/my-deployment --as-root -n <project_name>
      Copy to Clipboard Toggle word wrap

  2. Démarrez un pod debug avec un accès root, basé sur une configuration de déploiement.

    1. Obtenir le nom de configuration de déploiement d’un projet: 

      $ oc get deploymentconfigs -n <project_name>
      Copy to Clipboard Toggle word wrap

    2. Démarrez un pod debug avec des privilèges root, en fonction de la configuration de déploiement: 

      $ oc debug deploymentconfig/my-deployment-configuration --as-root -n <project_name>
      Copy to Clipboard Toggle word wrap
Note

Il est possible d’ajouter -- &lt;command&gt; aux commandes oc debug précédentes pour exécuter des commandes individuelles dans un pod debug, au lieu d’exécuter un shell interactif.

Il est possible de copier des fichiers vers et à partir d’un pod pour tester les modifications de configuration ou recueillir des informations de diagnostic.

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle d’administrateur dédié.
  • Le service API est toujours fonctionnel.
  • L’OpenShift CLI (oc) a été installé.

Procédure

  1. Copiez un fichier dans un pod: 

    $ oc cp <local_path> <pod_name>:/<path> -c <container_name>
    1
    Copy to Clipboard Toggle word wrap
    1
    Le premier conteneur dans un pod est sélectionné si l’option -c n’est pas spécifiée.

  2. Copiez un fichier à partir d’un pod: 

    $ oc cp <pod_name>:/<path>  -c <container_name> <local_path>
    1
    Copy to Clipboard Toggle word wrap
    1
    Le premier conteneur dans un pod est sélectionné si l’option -c n’est pas spécifiée.
    Note

    Afin que oc cp fonctionne, le binaire goudron doit être disponible dans le conteneur.

8.7. Dépannage du processus Source-à-Image
Copier lien

8.7.1. Les stratégies pour le dépannage Source-à-Image
Copier lien

Utilisez Source-to-Image (S2I) pour construire des images de conteneurs reproductibles au format Docker. Créez des images prêtes à l’emploi en injectant du code source de l’application dans une image conteneur et en assemblant une nouvelle image. La nouvelle image intègre l’image de base (le constructeur) et la source construite.

Afin de déterminer où se produit une défaillance dans le processus S2I, vous pouvez observer l’état des pods relatifs à chacune des étapes S2I suivantes:

  1. Au cours de l’étape de configuration de la construction, un module de construction est utilisé pour créer une image conteneur d’application à partir d’une image de base et d’un code source de l’application.
  2. Au cours de la phase de configuration de déploiement, un pod de déploiement est utilisé pour déployer des pods d’application à partir de l’image du conteneur de l’application qui a été construit dans l’étape de configuration de construction. Le module de déploiement déploie également d’autres ressources telles que les services et les itinéraires. La configuration de déploiement commence après le succès de la configuration de construction.
  3. Après que la pod de déploiement a commencé les pods d’application, des défaillances d’application peuvent se produire dans les pods d’application en cours d’exécution. À titre d’exemple, une application peut ne pas se comporter comme prévu même si les pods d’application sont dans un état d’exécution. Dans ce scénario, vous pouvez accéder aux pods d’application en cours d’exécution pour enquêter sur les échecs de l’application dans un pod.

Lors du dépannage des problèmes S2I, suivez cette stratégie:

  1. Contrôlez l’état de la construction, du déploiement et de la pod d’application
  2. Déterminer l’étape du processus S2I où le problème s’est produit
  3. Journaux de révision correspondant à l’étape échouée

8.7.2. Collecte de données diagnostiques Source-à-Image
Copier lien

L’outil S2I exécute un pod de build et un pod de déploiement en séquence. Le pod de déploiement est responsable du déploiement des pods d’application en fonction de l’image du conteneur d’application créée au stade de la construction. Contrôlez la construction, le déploiement et l’état de la pod d’application pour déterminer où se produit une défaillance dans le processus S2I. Ensuite, concentrez la collecte de données diagnostiques en conséquence.

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle d’administrateur dédié.
  • Le service API est toujours fonctionnel.
  • L’OpenShift CLI (oc) a été installé.

Procédure

  1. Attention à l’état de la gousse tout au long du processus S2I pour déterminer à quel stade une défaillance se produit: 

    $ oc get pods -w
    1
    Copy to Clipboard Toggle word wrap
    1
    Utilisez -w pour surveiller les pods pour détecter les modifications jusqu’à ce que vous quittez la commande en utilisant Ctrl+C.

  2. Examinez les journaux d’un pod échoué pour détecter les erreurs.

    • En cas d’échec de la gousse de construction, consultez les journaux de la gousse de construction: 

      $ oc logs -f pod/<application_name>-<build_number>-build
      Copy to Clipboard Toggle word wrap
      Note

      Alternativement, vous pouvez consulter les journaux de la configuration de construction en utilisant oc logs -f bc/&lt;application_name&gt;. Les journaux de configuration de la configuration de construction incluent les journaux à partir du groupe de construction.

    • En cas d’échec du module de déploiement, consultez les journaux de la pod de déploiement: 

      $ oc logs -f pod/<application_name>-<build_number>-deploy
      Copy to Clipboard Toggle word wrap
      Note

      Alternativement, vous pouvez consulter les journaux de la configuration de déploiement en utilisant oc logs -f dc/&lt;application_name&gt;. Cette sortie se connecte à partir de la pod de déploiement jusqu’à ce que la pod de déploiement se termine avec succès. La commande sort les journaux à partir des pods de l’application si vous l’exécutez une fois que la pod de déploiement est terminée. Après la fin d’un module de déploiement, ses journaux peuvent toujours être accessibles en exécutant oc logs -f pod/&lt;application_name&gt;-&lt;build_number&gt;-deploy.

    • En cas d’échec d’un pod d’application ou si une demande ne se comporte pas comme prévu dans un pod d’application en cours d’exécution, examinez les journaux de la pod de la demande: 

      $ oc logs -f pod/<application_name>-<build_number>-<random_string>
      Copy to Clipboard Toggle word wrap

Les échecs d’application peuvent se produire dans les pods d’application en cours d’exécution. Dans ces situations, vous pouvez récupérer des informations diagnostiques avec ces stratégies:

  • Examiner les événements relatifs aux pods de demande.
  • Examinez les journaux des pods de l’application, y compris les fichiers journaux spécifiques à l’application qui ne sont pas recueillis par le cadre de journalisation OpenShift.
  • Essayez la fonctionnalité de l’application de manière interactive et exécutez des outils de diagnostic dans un conteneur d’application.

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle d’administrateur dédié.
  • L’OpenShift CLI (oc) a été installé.

Procédure

  1. Liste des événements relatifs à un pod d’application spécifique. L’exemple suivant récupère les événements pour un pod d’application nommé my-app-1-akdlg: 

    $ oc describe pod/my-app-1-akdlg
    Copy to Clipboard Toggle word wrap

  2. Consulter les journaux d’un pod d’application: 

    $ oc logs -f pod/my-app-1-akdlg
    Copy to Clipboard Toggle word wrap

  3. Interrogez des journaux spécifiques dans un pod d’application en cours d’exécution. Les journaux qui sont envoyés à stdout sont collectés par le framework OpenShift Logging et sont inclus dans la sortie de la commande précédente. La requête suivante n’est requise que pour les journaux qui ne sont pas envoyés à stdout.

    1. Lorsqu’un journal d’application peut être consulté sans privilèges root dans un pod, concaténer le fichier journal comme suit: 

      $ oc exec my-app-1-akdlg -- cat /var/log/my-application.log
      Copy to Clipboard Toggle word wrap

    2. Lorsque l’accès root est nécessaire pour afficher un journal de l’application, vous pouvez démarrer un conteneur de débogage avec des privilèges root, puis afficher le fichier journal à partir du conteneur. Démarrez le conteneur de débogage à partir de l’objet DeploymentConfig du projet. Les utilisateurs de Pod fonctionnent généralement avec des privilèges non-root, mais l’exécution de modules de dépannage avec des privilèges racine temporaires peut être utile lors de l’enquête sur les problèmes: 

      $ oc debug dc/my-deployment-configuration --as-root -- cat /var/log/my-application.log
      Copy to Clipboard Toggle word wrap
      Note

      Il est possible d’accéder à un shell interactif avec un accès root dans le pod debug si vous exécutez oc debug dc/&lt;deployment_configuration&gt; --as-root sans ajouter -- &lt;command&gt;.

  4. Tester la fonctionnalité de l’application de manière interactive et exécuter des outils de diagnostic, dans un conteneur d’application avec une coque interactive.

    1. Démarrez un shell interactif sur le conteneur de l’application: 

      $ oc exec -it my-app-1-akdlg /bin/bash
      Copy to Clipboard Toggle word wrap
    2. Tester la fonctionnalité de l’application de manière interactive à partir de l’intérieur de la coque. À titre d’exemple, vous pouvez exécuter la commande point d’entrée du conteneur et observer les résultats. Ensuite, testez les modifications de la ligne de commande directement, avant de mettre à jour le code source et de reconstruire le conteneur de l’application via le processus S2I.

    3. Exécutez les binaires de diagnostic disponibles dans le conteneur.

      Note

      Les privilèges racine sont nécessaires pour exécuter certains binaires de diagnostic. Dans ces situations, vous pouvez démarrer un pod debug avec un accès root, basé sur l’objet DeploymentConfig d’un pod problématique, en exécutant oc debug dc/&lt;deployment_configuration&gt; --as-root. Ensuite, vous pouvez exécuter des binaires diagnostiques comme racine à partir de l’intérieur de la gousse de débogage.

8.8. Dépannage des problèmes de stockage
Copier lien

8.8.1. La résolution d’erreurs multi-attachées
Copier lien

Lorsqu’un nœud s’écrase ou s’arrête brusquement, le volume de ReadWriteOnce (RWO) attaché est censé être démonté à partir du nœud afin qu’il puisse être utilisé par une gousse programmée sur un autre nœud.

Cependant, le montage sur un nouveau nœud n’est pas possible car le nœud défaillant est incapable de démonter le volume fixé.

L’erreur multi-attachée est signalée:

Exemple de sortie

Unable to attach or mount volumes: unmounted volumes=[sso-mysql-pvol], unattached volumes=[sso-mysql-pvol default-token-x4rzc]: timed out waiting for the condition
Multi-Attach error for volume "pvc-8837384d-69d7-40b2-b2e6-5df86943eef9" Volume is already used by pod(s) sso-mysql-1-ns6b4
Copy to Clipboard Toggle word wrap

Procédure

Afin de résoudre le problème multi-attachés, utilisez l’une des solutions suivantes:

  • Activer plusieurs pièces jointes en utilisant des volumes RWX.

    Dans la plupart des solutions de stockage, vous pouvez utiliser des volumes de ReadWriteMany (RWX) pour éviter les erreurs d’attachement multiples.

  • Récupérer ou supprimer le nœud échoué lors de l’utilisation d’un volume RWO.

    Dans le cas d’un stockage qui ne prend pas en charge RWX, tels que VMware vSphere, les volumes RWO doivent être utilisés à la place. Cependant, les volumes RWO ne peuvent pas être montés sur plusieurs nœuds.

    Lorsque vous rencontrez un message d’erreur multi-attaché avec un volume RWO, forcez à supprimer le pod sur un nœud d’arrêt ou un nœud planté pour éviter la perte de données dans les charges de travail critiques, par exemple lorsque des volumes persistants dynamiques sont attachés. 

    $ oc delete pod <old_pod> --force=true --grace-period=0
    Copy to Clipboard Toggle word wrap

    Cette commande supprime les volumes bloqués lors de l’arrêt ou des nœuds écrasés après six minutes.

8.9. Enquête sur les questions de surveillance
Copier lien

Le service OpenShift Red Hat sur AWS inclut une pile de surveillance préconfigurée, préinstallée et auto-mise à jour qui fournit la surveillance des composants de la plate-forme de base. Dans Red Hat OpenShift Service sur AWS 4, les administrateurs de clusters peuvent optionnellement activer la surveillance des projets définis par l’utilisateur.

B) Utilisez ces procédures si les problèmes suivants se posent:

  • Les métriques sont indisponibles.
  • « Prometheus consomme beaucoup d’espace disque.
  • L’alerte KubePersistentVolumeFillingUp tire pour Prometheus.

Les ressources ServiceMonitor vous permettent de déterminer comment utiliser les métriques exposées par un service dans des projets définis par l’utilisateur. Suivez les étapes décrites dans cette procédure si vous avez créé une ressource ServiceMonitor mais ne pouvez pas voir les mesures correspondantes dans l’interface utilisateur de Metrics.

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle d’administrateur dédié.
  • L’OpenShift CLI (oc) a été installé.
  • La surveillance est activée et configurée pour les projets définis par l’utilisateur.
  • Création d’une ressource ServiceMonitor.

Procédure

  1. Assurez-vous que les étiquettes correspondantes correspondent aux configurations de ressources ServiceMonitor et ServiceMonitor.

    1. D’obtenir l’étiquette définie dans le service. L’exemple suivant interroge le service prometheus-example-app dans le projet ns1: 

      $ oc -n ns1 get service prometheus-example-app -o yaml
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

        labels:
    app: prometheus-example-app
      Copy to Clipboard Toggle word wrap

    2. Assurez-vous que la définition de matchLabels dans la configuration de la ressource ServiceMonitor correspond à la sortie de l’étiquette à l’étape précédente. L’exemple suivant interroge le moniteur de service prometheus-example-monitor dans le projet ns1: 

      $ oc -n ns1 get servicemonitor prometheus-example-monitor -o yaml
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      apiVersion: v1
kind: ServiceMonitor
metadata:
  name: prometheus-example-monitor
  namespace: ns1
spec:
  endpoints:
  - interval: 30s
    port: web
    scheme: http
  selector:
    matchLabels:
      app: prometheus-example-app
      Copy to Clipboard Toggle word wrap

      Note

      En tant que développeur, vous pouvez vérifier les étiquettes de service et de ressources ServiceMonitor avec les autorisations pour le projet.

  2. Inspecter les logs de l’opérateur Prometheus dans le cadre du projet de surveillance de la charge de travail ouverte de l’utilisateur.

    1. Énumérez les pods dans le projet openshift-user-workload-monitoring: 

      $ oc -n openshift-user-workload-monitoring get pods
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      NAME                                   READY   STATUS    RESTARTS   AGE
prometheus-operator-776fcbbd56-2nbfm   2/2     Running   0          132m
prometheus-user-workload-0             5/5     Running   1          132m
prometheus-user-workload-1             5/5     Running   1          132m
thanos-ruler-user-workload-0           3/3     Running   0          132m
thanos-ruler-user-workload-1           3/3     Running   0          132m
      Copy to Clipboard Toggle word wrap

    2. D’obtenir les billes à partir du conteneur protéréheus-operator dans la pod de promesseheus-operator. Dans l’exemple suivant, le pod est appelé prometheus-operator-776fcbbd56-2nbfm: 

      $ oc -n openshift-user-workload-monitoring logs prometheus-operator-776fcbbd56-2nbfm -c prometheus-operator
      Copy to Clipboard Toggle word wrap

      En cas de problème avec le moniteur de service, les journaux peuvent inclure une erreur similaire à cet exemple: 

      level=warn ts=2020-08-10T11:48:20.906739623Z caller=operator.go:1829 component=prometheusoperator msg="skipping servicemonitor" error="it accesses file system via bearer token file which Prometheus specification prohibits" servicemonitor=eagle/eagle namespace=openshift-user-workload-monitoring prometheus=user-workload
      Copy to Clipboard Toggle word wrap

  3. Consultez l’état cible de votre point de terminaison sur la page cible Metrics dans le service OpenShift Red Hat sur l’interface utilisateur de la console Web AWS.

    1. Connectez-vous au service Red Hat OpenShift sur la console web AWS et accédez à Observer → Targets dans la perspective de l’administrateur.
    2. Localisez le point de terminaison des métriques dans la liste, et examinez l’état de la cible dans la colonne État.
    3. Dans le cas où l’état est en panne, cliquez sur l’URL du point de terminaison pour afficher plus d’informations sur la page Détails de la cible pour cette cible de mesures.

  4. Configurez la journalisation du niveau de débogage pour l’opérateur Prometheus dans le projet openshift-user-workload-monitoring.

    1. Éditer l’objet ConfigMap de l’utilisateur-workload-monitoring-config dans le projet openshift-user-workload-monitoring: 

      $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
      Copy to Clipboard Toggle word wrap

    2. Ajouter logLevel: débogage pour proteheusOperator sous data/config.yaml pour définir le niveau de journal à déboguer: 

      apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    prometheusOperator:
      logLevel: debug
# ...
      Copy to Clipboard Toggle word wrap
    3. Enregistrez le fichier pour appliquer les modifications. Le pod de promesse-opérateur affecté est automatiquement redéployé.

    4. Confirmez que le niveau de journal de débogage a été appliqué au déploiement protéréheus-operator dans le projet openshift-user-workload-monitoring: 

      $ oc -n openshift-user-workload-monitoring get deploy prometheus-operator -o yaml |  grep "log-level"
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

              - --log-level=debug
      Copy to Clipboard Toggle word wrap

      L’enregistrement de niveau de débogage affichera tous les appels effectués par l’opérateur Prometheus.

    5. Assurez-vous que le pod protéréheus-operator est en cours d’exécution: 

      $ oc -n openshift-user-workload-monitoring get pods
      Copy to Clipboard Toggle word wrap
      Note

      Lorsqu’une valeur de niveau de journal Prometheus Operator non reconnue est incluse dans la carte de configuration, le pod prometheus-operator pourrait ne pas redémarrer avec succès.

    6. Consultez les journaux de débogage pour voir si l’opérateur Prometheus utilise la ressource ServiceMonitor. Examinez les journaux pour d’autres erreurs connexes.

Les développeurs peuvent créer des étiquettes pour définir des attributs pour les métriques sous la forme de paires clé-valeur. Le nombre de paires de valeurs clés potentielles correspond au nombre de valeurs possibles pour un attribut. L’attribut qui a un nombre illimité de valeurs potentielles s’appelle un attribut non lié. A titre d’exemple, un attribut customer_id est non lié parce qu’il a un nombre infini de valeurs possibles.

Chaque paire clé-valeur assignée a une série chronologique unique. L’utilisation de nombreux attributs non liés dans les étiquettes peut entraîner une augmentation exponentielle du nombre de séries chronologiques créées. Cela peut avoir un impact sur les performances de Prometheus et peut consommer beaucoup d’espace disque.

Lorsque Prometheus consomme beaucoup de disque, vous pouvez utiliser les mesures suivantes:

  • Consultez l’état de la base de données des séries chronologiques (TSDB) à l’aide de l’API HTTP Prometheus pour plus d’informations sur les étiquettes qui créent le plus de données de séries chronologiques. Cela nécessite des privilèges d’administrateur de cluster.
  • Consultez le nombre d’échantillons d’éraflures qui sont collectés.

  • Diminuer le nombre de séries chronologiques uniques qui sont créées en réduisant le nombre d’attributs non liés qui sont attribués à des métriques définies par l’utilisateur.

    Note

    L’utilisation d’attributs liés à un ensemble limité de valeurs possibles réduit le nombre de combinaisons de paires clé-valeur potentielles.

  • Appliquer des limites sur le nombre d’échantillons pouvant être grattés sur des projets définis par l’utilisateur. Cela nécessite des privilèges d’administrateur de cluster.

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle d’administrateur dédié.
  • L’OpenShift CLI (oc) a été installé.

Procédure

  1. Dans la perspective de l’administrateur, accédez à Observer → Metrics.

  2. Entrez une requête Prometheus Query Language (PromQL) dans le champ Expression. Les requêtes d’exemple suivantes aident à identifier les métriques de haute cardinalité qui pourraient entraîner une consommation élevée d’espace disque:

    • En exécutant la requête suivante, vous pouvez identifier les dix emplois qui ont le plus grand nombre d’échantillons de raclette: 

      topk(10, max by(namespace, job) (topk by(namespace, job) (1, scrape_samples_post_metric_relabeling)))
      Copy to Clipboard Toggle word wrap

    • En exécutant la requête suivante, vous pouvez identifier les séries chronologiques en identifiant les dix emplois qui ont créé le plus de données de séries chronologiques au cours de la dernière heure: 

      topk(10, sum by(namespace, job) (sum_over_time(scrape_series_added[1h])))
      Copy to Clipboard Toggle word wrap

  3. Étudier le nombre de valeurs d’étiquettes non liées attribuées aux mesures dont le nombre d’échantillons de griffes est plus élevé que prévu:

    • Lorsque les métriques se rapportent à un projet défini par l’utilisateur, examinez les paires clés-valeur attribuées à votre charge de travail. Ceux-ci sont mis en œuvre par l’intermédiaire des bibliothèques clientes Prometheus au niveau de l’application. Essayez de limiter le nombre d’attributs non liés référencés dans vos étiquettes.
    • Lorsque les métriques se rapportent à un service de base Red Hat OpenShift sur le projet AWS, créez un cas de support Red Hat sur le portail client Red Hat.

  4. Examinez le statut TSDB à l’aide de l’API HTTP Prometheus en suivant ces étapes lorsqu’il est connecté en tant qu’administrateur dédié:

    1. Accédez à l’URL de route de l’API Prometheus en exécutant la commande suivante: 

      $ HOST=$(oc -n openshift-monitoring get route prometheus-k8s -ojsonpath={.status.ingress[].host})
      Copy to Clipboard Toggle word wrap

    2. Extraire un jeton d’authentification en exécutant la commande suivante: 

      $ TOKEN=$(oc whoami -t)
      Copy to Clipboard Toggle word wrap

    3. Interrogez le statut TSDB pour Prometheus en exécutant la commande suivante: 

      $ curl -H "Authorization: Bearer $TOKEN" -k "https://$HOST/api/v1/status/tsdb"
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      "status": "success","data":{"headStats":{"numSeries":507473,
"numLabelPairs":19832,"chunkCount":946298,"minTime":1712253600010,
"maxTime":1712257935346},"seriesCountByMetricName":
[{"name":"etcd_request_duration_seconds_bucket","value":51840},
{"name":"apiserver_request_sli_duration_seconds_bucket","value":47718},
...
      Copy to Clipboard Toggle word wrap

8.10. Diagnostic des problèmes d’OpenShift CLI (oc)
Copier lien

8.10.1. Comprendre les niveaux de log OpenShift CLI (oc)
Copier lien

Avec OpenShift CLI (oc), vous pouvez créer des applications et gérer Red Hat OpenShift Service sur des projets AWS à partir d’un terminal.

En cas de problèmes spécifiques à la commande oc, augmentez le niveau de log d’oc à la demande d’API de sortie, à la réponse API et aux détails de requête de curl générés par la commande. Cela fournit une vue granulaire de l’opération sous-jacente d’une commande oc particulière, qui à son tour pourrait fournir un aperçu de la nature d’une défaillance.

les niveaux de log OC varient de 1 à 10. Le tableau suivant fournit une liste des niveaux de log oc, ainsi que leurs descriptions.

Expand
Tableau 8.3. Les niveaux de journal OpenShift CLI (oc)
Journal de niveauDescription

1 à 5

Aucun enregistrement supplémentaire à Stderr.

6

Loger les requêtes de l’API à stderr.

7

Enregistrez les requêtes API et les en-têtes à stderr.

8

Enregistrez les requêtes API, les en-têtes et le corps, ainsi que les en-têtes de réponse API et le corps à stderr.

9

Enregistrez les requêtes API, les en-têtes et le corps, les en-têtes de réponse API et le corps, ainsi que les requêtes de curl à stderr.

10

Enregistrez les requêtes API, les en-têtes et le corps, les en-têtes de réponse API et le corps, ainsi que les requêtes de curl à stderr, dans les détails verbeux.

8.10.2. Indiquer les niveaux de journal OpenShift CLI (oc)
Copier lien

Il est possible d’enquêter sur les problèmes OpenShift CLI (oc) en augmentant le niveau de journal de la commande.

Le service OpenShift Red Hat sur le jeton de session actuel de l’utilisateur AWS est généralement inclus dans les requêtes de curl enregistrées lorsque cela est nécessaire. En outre, vous pouvez obtenir le jeton de session de l’utilisateur actuel manuellement, pour être utilisé lors du test d’aspects du processus sous-jacent d’une commande oc étape par étape.

Conditions préalables

  • Installez le OpenShift CLI (oc).

Procédure

  • Indiquez le niveau d’oc log lors de l’exécution d’une commande oc: 

    $ oc <command> --loglevel <log_level>
    Copy to Clipboard Toggle word wrap

    là où:

    &lt;commande&gt;
    Indique la commande que vous exécutez.
    &lt;log_level&gt;
    Indique le niveau de journal à appliquer à la commande.

  • Afin d’obtenir le jeton de session de l’utilisateur actuel, exécutez la commande suivante: 

    $ oc whoami -t
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    sha256~RCV3Qcn7H-OEfqCGVI0CvnZ6...
    Copy to Clipboard Toggle word wrap

8.11. Dépannage des jetons expirés
Copier lien

8.11.1. Dépannage des jetons d’accès hors ligne expirés
Copier lien

Lorsque vous utilisez le service Red Hat OpenShift sur AWS (ROSA) CLI, rosa et votre jeton d’accès hors ligne api.openshift.com expire, un message d’erreur apparaît. Cela se produit lorsque sso.redhat.com invalide le jeton.

Exemple de sortie

Can't get tokens ....
Can't get access tokens ....
Copy to Clipboard Toggle word wrap

Procédure

  • Générez un nouveau jeton d’accès hors ligne à l’URL suivante. Chaque fois que vous visitez l’URL, un nouveau jeton d’accès hors ligne est généré.

    • Le service OpenShift de Red Hat sur AWS (ROSA) : https://console.redhat.com/openshift/token/rosa

8.12. Dépannage des rôles IAM
Copier lien

Il se peut que vous receviez une erreur lorsque vous essayez de créer un cluster à l’aide du service Red Hat OpenShift sur AWS (ROSA) CLI, rosa.

Exemple de sortie

E: Failed to create cluster: The sts_user_role is not linked to account '1oNl'. Please create a user role and link it to the account.
Copy to Clipboard Toggle word wrap

Cette erreur signifie que le rôle IAM de rôle utilisateur n’est pas lié à votre compte AWS. La cause la plus probable de cette erreur est qu’un autre utilisateur de votre organisation Red Hat a créé le rôle Ocm-role IAM. Il faut créer votre rôle IAM de rôle utilisateur.

Note

Après que tout utilisateur ait mis en place une ressource IAM ocm-role liée à un compte Red Hat, tout utilisateur ultérieur souhaitant créer un cluster dans cette organisation Red Hat doit avoir un rôle IAM utilisateur pour fournir un cluster.

Procédure

  • Évaluez l’état de vos rôles ocm-role et user-role avec les commandes suivantes: 

    $ rosa list ocm-role
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    I: Fetching ocm roles
ROLE NAME                           ROLE ARN                                          LINKED  ADMIN
ManagedOpenShift-OCM-Role-1158  arn:aws:iam::2066:role/ManagedOpenShift-OCM-Role-1158   No      No
    Copy to Clipboard Toggle word wrap 

    $ rosa list user-role
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    I: Fetching user roles
ROLE NAME                                   ROLE ARN                                        LINKED
ManagedOpenShift-User.osdocs-Role  arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role  Yes
    Copy to Clipboard Toggle word wrap

Avec les résultats de ces commandes, vous pouvez créer et relier les ressources IAM manquantes.

8.12.1.1. Création d’un rôle Ocm-role IAM
Copier lien

Créez vos rôles Ocm-role IAM à l’aide de l’interface de ligne de commande (CLI).

Conditions préalables

  • Il y a un compte AWS.
  • Dans l’organisation OpenShift Cluster Manager, vous avez les privilèges d’administrateur d’organisation Red Hat.
  • Les autorisations requises pour installer les rôles AWS à l’échelle du compte sont requises.
  • Dans votre installation, vous avez installé et configuré le dernier service Red Hat OpenShift sur AWS (ROSA) CLI, rosa.

Procédure

  • Afin de créer un rôle Ocm-role IAM avec des privilèges de base, exécutez la commande suivante: 

    $ rosa create ocm-role
    Copy to Clipboard Toggle word wrap

  • Afin de créer un rôle Ocm-role IAM avec les privilèges d’administrateur, exécutez la commande suivante: 

    $ rosa create ocm-role --admin
    Copy to Clipboard Toggle word wrap

    Cette commande vous permet de créer le rôle en spécifiant des attributs spécifiques. L’exemple suivant montre le "mode automatique" sélectionné, ce qui permet au ROSA CLI (rosa) de créer vos rôles et stratégies d’opérateur. Consultez « Méthodes de création de rôles à l’échelle du compte » pour plus d’informations.

Exemple de sortie

I: Creating ocm role
? Role prefix: ManagedOpenShift
1 

? Enable admin capabilities for the OCM role (optional): No
2 

? Permissions boundary ARN (optional):
3 

? Role Path (optional):
4 

? Role creation mode: auto
5 

I: Creating role using 'arn:aws:iam::<ARN>:user/<UserName>'
? Create the 'ManagedOpenShift-OCM-Role-182' role? Yes
6 

I: Created role 'ManagedOpenShift-OCM-Role-182' with ARN  'arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182'
I: Linking OCM role
? OCM Role ARN: arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182
7 

? Link the 'arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182' role with organization '<AWS ARN>'? Yes
8 

I: Successfully linked role-arn 'arn:aws:iam::<ARN>:role/ManagedOpenShift-OCM-Role-182' with organization account '<AWS ARN>'
Copy to Clipboard Toggle word wrap

1
Il s’agit d’une valeur préfixée pour toutes les ressources AWS créées. Dans cet exemple, ManagedOpenShift prépend toutes les ressources AWS.
2
Choisissez si vous voulez que ce rôle ait les autorisations d’administration supplémentaires.
Note

L’option --admin n’a pas été consultée.

3
Le nom de ressource Amazon (ARN) de la politique pour définir les limites d’autorisation.
4
Indiquez un chemin IAM pour le nom d’utilisateur.
5
Choisissez la méthode pour créer vos rôles AWS. En utilisant l’auto, le ROSA CLI génère et relie les rôles et les politiques. En mode automatique, vous recevez des invitations différentes pour créer les rôles AWS.
6
La méthode automatique vous demande si vous souhaitez créer un rôle ocm spécifique en utilisant votre préfixe.
7
Confirmez que vous souhaitez associer votre rôle IAM à votre OpenShift Cluster Manager.
8
Relie le rôle créé à votre organisation AWS.
8.12.1.2. Création d’un rôle IAM de rôle utilisateur
Copier lien

Il est possible de créer vos rôles IAM à l’aide de l’interface ligne de commande (CLI).

Conditions préalables

  • Il y a un compte AWS.
  • Dans votre installation, vous avez installé et configuré le dernier service Red Hat OpenShift sur AWS (ROSA) CLI, rosa.

Procédure

  • Afin de créer un rôle IAM de rôle utilisateur avec des privilèges de base, exécutez la commande suivante: 

    $ rosa create user-role
    Copy to Clipboard Toggle word wrap

    Cette commande vous permet de créer le rôle en spécifiant des attributs spécifiques. L’exemple suivant montre le "mode automatique" sélectionné, ce qui permet au ROSA CLI (rosa) de créer vos rôles et stratégies d’opérateur. Consultez « Comprendre les modes de déploiement automatique et manuel » pour plus d’informations.

Exemple de sortie

I: Creating User role
? Role prefix: ManagedOpenShift
1 

? Permissions boundary ARN (optional):
2 

? Role Path (optional):
3 

? Role creation mode: auto
4 

I: Creating ocm user role using 'arn:aws:iam::2066:user'
? Create the 'ManagedOpenShift-User.osdocs-Role' role? Yes
5 

I: Created role 'ManagedOpenShift-User.osdocs-Role' with ARN 'arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role'
I: Linking User role
? User Role ARN: arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role
? Link the 'arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role' role with account '1AGE'? Yes
6 

I: Successfully linked role ARN 'arn:aws:iam::2066:role/ManagedOpenShift-User.osdocs-Role' with account '1AGE'
Copy to Clipboard Toggle word wrap

1
Il s’agit d’une valeur préfixée pour toutes les ressources AWS créées. Dans cet exemple, ManagedOpenShift prépend toutes les ressources AWS.
2
Le nom de ressource Amazon (ARN) de la politique pour définir les limites d’autorisation.
3
Indiquez un chemin IAM pour le nom d’utilisateur.
4
Choisissez la méthode pour créer vos rôles AWS. En utilisant l’auto, le ROSA CLI génère et relie les rôles et les politiques. En mode automatique, vous recevez des invitations différentes pour créer les rôles AWS.
5
La méthode automatique vous demande si vous souhaitez créer un rôle utilisateur spécifique en utilisant votre préfixe.
6
Relie le rôle créé à votre organisation AWS.
8.12.1.3. Associer votre compte AWS aux rôles IAM
Copier lien

Il est possible d’associer ou de lier votre compte AWS aux rôles IAM existants en utilisant le service Red Hat OpenShift sur AWS (ROSA) CLI, rosa.

Conditions préalables

  • Il y a un compte AWS.
  • Les autorisations requises pour installer les rôles AWS à l’échelle du compte sont requises. Consultez les « Ressources supplémentaires » de cette section pour plus d’informations.
  • L’installation et la configuration des derniers CLI AWS (aws) et ROSA (rosa) sur votre hôte d’installation.

  • « vous avez créé les rôles ocm-role et user-role IAM, mais vous ne les avez pas encore liés à votre compte AWS. Il est possible de vérifier si vos rôles IAM sont déjà liés en exécutant les commandes suivantes: 

    $ rosa list ocm-role
    Copy to Clipboard Toggle word wrap 
    $ rosa list user-role
    Copy to Clipboard Toggle word wrap

    Lorsque Oui est affiché dans la colonne Linked pour les deux rôles, vous avez déjà lié les rôles à un compte AWS.

Procédure

  1. À partir du CLI, liez votre ressource ocm-role à votre organisation Red Hat en utilisant votre nom de ressource Amazon (ARN):

    Note

    Il faut avoir les privilèges d’administrateur de l’organisation Red Hat pour exécuter la commande rosa link. Après avoir lié la ressource ocm-role à votre compte AWS, elle est visible pour tous les utilisateurs de l’organisation. 

    $ rosa link ocm-role --role-arn <arn>
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    I: Linking OCM role
? Link the '<AWS ACCOUNT ID>` role with organization '<ORG ID>'? Yes
I: Successfully linked role-arn '<AWS ACCOUNT ID>' with organization account '<ORG ID>'
    Copy to Clipboard Toggle word wrap

  2. À partir du CLI, liez votre ressource de rôle utilisateur à votre compte d’utilisateur Red Hat en utilisant votre nom de ressource Amazon (ARN): 

    $ rosa link user-role --role-arn <arn>
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    I: Linking User role
? Link the 'arn:aws:iam::<ARN>:role/ManagedOpenShift-User-Role-125' role with organization '<AWS ID>'? Yes
I: Successfully linked role-arn 'arn:aws:iam::<ARN>:role/ManagedOpenShift-User-Role-125' with organization account '<AWS ID>'
    Copy to Clipboard Toggle word wrap

Il est possible d’associer plusieurs comptes AWS à votre organisation Red Hat. L’association de plusieurs comptes vous permet de créer des clusters Red Hat OpenShift Service sur AWS (ROSA) sur l’un des comptes AWS associés de votre organisation Red Hat.

Avec cette fonctionnalité, vous pouvez créer des clusters dans différentes régions AWS en utilisant plusieurs profils AWS en tant qu’environnements liés à la région.

Conditions préalables

  • Il y a un compte AWS.
  • Il est possible d’utiliser OpenShift Cluster Manager pour créer des clusters.
  • Les autorisations requises pour installer les rôles AWS à l’échelle du compte sont requises.
  • L’installation et la configuration des derniers CLI AWS (aws) et ROSA (rosa) sur votre hôte d’installation.
  • C’est vous qui avez créé vos rôles Ocm-role et user-role IAM.

Procédure

Afin d’associer un compte AWS supplémentaire, créez d’abord un profil dans votre configuration AWS locale. Ensuite, associez le compte à votre organisation Red Hat en créant les rôles ocm-rôle, utilisateur et compte dans le compte AWS supplémentaire.

Afin de créer les rôles dans une région supplémentaire, spécifiez le paramètre --profile &lt;aws-profile&gt; lors de l’exécution de la rosa créer des commandes et remplacer &lt;aws_profile&gt; par le nom de profil de compte supplémentaire:

  • De spécifier un profil de compte AWS lors de la création d’un rôle OpenShift Cluster Manager: 

    $ rosa create --profile <aws_profile> ocm-role
    Copy to Clipboard Toggle word wrap

  • De spécifier un profil de compte AWS lors de la création d’un rôle utilisateur: 

    $ rosa create --profile <aws_profile> user-role
    Copy to Clipboard Toggle word wrap

  • De spécifier un profil de compte AWS lors de la création des rôles de compte: 

    $ rosa create --profile <aws_profile> account-roles
    Copy to Clipboard Toggle word wrap
Note

Dans le cas où vous ne spécifiez pas un profil, le profil AWS par défaut est utilisé.

8.13. Dépannage des déploiements de clusters
Copier lien

Ce document décrit comment résoudre les erreurs de déploiement de clusters.

8.13.1. L’obtention d’informations sur un cluster échoué
Copier lien

En cas d’échec d’un déploiement de cluster, le cluster est placé dans un état d’erreur.

Procédure

  • Exécutez la commande suivante pour obtenir plus d’informations: 

    $ rosa describe cluster -c <my_cluster_name> --debug
    Copy to Clipboard Toggle word wrap

En cas d’échec d’une action de création de cluster, vous pouvez recevoir le message d’erreur suivant.

Exemple de sortie

Failed to create cluster: Unable to create cluster spec: Failed to get access keys for user 'osdCcsAdmin': NoSuchEntity: The user with name osdCcsAdmin cannot be found.
Copy to Clipboard Toggle word wrap

Procédure

Afin de résoudre ce problème:

  1. Effacer la pile: 

    $ rosa init --delete
    Copy to Clipboard Toggle word wrap

  2. Commencez à réinitialiser votre compte: 

    $ rosa init
    Copy to Clipboard Toggle word wrap

Dans le cas où vous n’avez pas créé d’équilibreur de charge dans votre compte AWS, il est possible que le rôle lié au service d’équilibrage de charge Elastic (ELB) n’existe pas encore. Il se peut que vous receviez l’erreur suivante: 

Error: Error creating network Load Balancer: AccessDenied: User: arn:aws:sts::xxxxxxxxxxxx:assumed-role/ManagedOpenShift-Installer-Role/xxxxxxxxxxxxxxxxxxx is not authorized to perform: iam:CreateServiceLinkedRole on resource: arn:aws:iam::xxxxxxxxxxxx:role/aws-service-role/elasticloadbalancing.amazonaws.com/AWSServiceRoleForElasticLoadBalancing"
Copy to Clipboard Toggle word wrap

Procédure

  • Afin de résoudre ce problème, assurez-vous que le rôle existe sur votre compte AWS. Dans le cas contraire, créez ce rôle avec la commande suivante: 

    aws iam get-role --role-name "AWSServiceRoleForElasticLoadBalancing" || aws iam create-service-linked-role --aws-service-name "elasticloadbalancing.amazonaws.com"
    Copy to Clipboard Toggle word wrap
    Note

    Cette commande ne doit être exécutée qu’une fois par compte.

Dans des cas spécifiques, l’erreur suivante apparaît dans OpenShift Cluster Manager si vous tentez de supprimer votre cluster. 

Error deleting cluster
CLUSTERS-MGMT-400: Failed to delete cluster <hash>: sts_user_role is not linked to your account. sts_ocm_role is linked to your organization <org number> which requires sts_user_role to be linked to your Red Hat account <account ID>.Please create a user role and link it to the account: User Account <account ID> is not authorized to perform STS cluster operations

Operation ID: b0572d6e-fe54-499b-8c97-46bf6890011c
Copy to Clipboard Toggle word wrap

Lorsque vous essayez de supprimer votre cluster du CLI, l’erreur suivante apparaît. 

E: Failed to delete cluster <hash>: sts_user_role is not linked to your account. sts_ocm_role is linked to your organization <org_number> which requires sts_user_role to be linked to your Red Hat account <account_id>.Please create a user role and link it to the account: User Account <account ID> is not authorized to perform STS cluster operations
Copy to Clipboard Toggle word wrap

Cette erreur se produit lorsque le rôle utilisateur est déconnecté ou supprimé.

Procédure

  1. Exécutez la commande suivante pour créer la ressource IAM user-role: 

    $ rosa create user-role
    Copy to Clipboard Toggle word wrap

  2. Après avoir vu que le rôle a été créé, vous pouvez supprimer le cluster. Ce qui suit confirme que le rôle a été créé et lié: 

    I: Successfully linked role ARN <user role ARN> with account <account ID>
    Copy to Clipboard Toggle word wrap

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