7.6. Dépannage des problèmes de l'opérateur


Les opérateurs sont une méthode de conditionnement, de déploiement et de gestion d'une application OpenShift Container Platform. Ils agissent comme une extension de l'équipe d'ingénieurs du fournisseur de logiciels, en surveillant un environnement OpenShift Container Platform 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 automatiquement aux pannes et ne pas prendre de raccourcis, comme sauter un processus de sauvegarde du logiciel pour gagner du temps.

OpenShift Container Platform 4.12 inclut un ensemble d'opérateurs par défaut qui sont nécessaires au bon fonctionnement du cluster. Ces opérateurs par défaut sont gérés par l'opérateur de version de cluster (CVO).

En tant qu'administrateur de cluster, vous pouvez installer des opérateurs d'application à partir de l'OperatorHub en utilisant la console web d'OpenShift Container Platform ou le CLI. Vous pouvez ensuite abonner l'opérateur à un ou plusieurs espaces de noms pour le mettre à la disposition des développeurs sur votre cluster. Les opérateurs d'application sont gérés par Operator Lifecycle Manager (OLM).

Si vous rencontrez des problèmes avec l'opérateur, vérifiez l'état de l'abonnement à l'opérateur. Vérifiez l'état des pods de l'opérateur dans le cluster et rassemblez les journaux de l'opérateur pour établir un diagnostic.

7.6.1. Types de conditions d'abonnement de l'opérateur

Les abonnements peuvent signaler les types de conditions suivants :

Tableau 7.2. Types de conditions d'abonnement
ConditionDescription

CatalogSourcesUnhealthy

Une partie ou la totalité des sources du catalogue à utiliser pour la résolution sont malsaines.

InstallPlanMissing

Il manque un plan d'installation pour un abonnement.

InstallPlanPending

Un plan d'installation pour un abonnement est en attente d'installation.

InstallPlanFailed

Un plan d'installation pour un abonnement a échoué.

ResolutionFailed

La résolution des dépendances pour un abonnement a échoué.

Note

Les opérateurs de cluster OpenShift Container Platform par défaut sont gérés par l'opérateur de version de cluster (CVO) et n'ont pas d'objet Subscription. Les opérateurs d'application sont gérés par Operator Lifecycle Manager (OLM) et ont un objet Subscription.

7.6.2. Visualisation de l'état de l'abonnement de l'opérateur à l'aide de la CLI

Vous pouvez consulter l'état de l'abonnement de l'opérateur à l'aide de l'interface de ligne de commande.

Conditions préalables

  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
  • Vous avez installé l'OpenShift CLI (oc).

Procédure

  1. Liste des abonnements des opérateurs :

    $ oc get subs -n <operator_namespace>
  2. Utilisez la commande oc describe pour inspecter une ressource Subscription:

    oc describe sub <subscription_name> -n <operator_namespace>
  3. Dans la sortie de la commande, recherchez la section Conditions pour connaître l'état des types de conditions d'abonnement de l'opérateur. Dans l'exemple suivant, le type de condition CatalogSourcesUnhealthy a le statut false car toutes les sources de catalogue disponibles sont saines :

    Exemple de sortie

    Conditions:
       Last Transition Time:  2019-07-29T13:42:57Z
       Message:               all available catalogsources are healthy
       Reason:                AllCatalogSourcesHealthy
       Status:                False
       Type:                  CatalogSourcesUnhealthy

Note

Les opérateurs de cluster OpenShift Container Platform par défaut sont gérés par l'opérateur de version de cluster (CVO) et n'ont pas d'objet Subscription. Les opérateurs d'application sont gérés par Operator Lifecycle Manager (OLM) et ont un objet Subscription.

7.6.3. Visualisation de l'état de la source du catalogue de l'opérateur à l'aide de la CLI

Vous pouvez consulter l'état d'une source du catalogue de l'opérateur à l'aide de l'interface de ligne de commande.

Conditions préalables

  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
  • Vous avez installé l'OpenShift CLI (oc).

Procédure

  1. Listez les sources de catalogue dans un espace de noms. Par 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

    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

  2. La commande oc describe permet d'obtenir plus de détails et de connaître l'état d'une source de catalogue :

    $ oc describe catalogsource example-catalog -n openshift-marketplace

    Exemple de sortie

    Name:         example-catalog
    Namespace:    openshift-marketplace
    ...
    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

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

  3. Listez les pods de l'espace de noms dans lequel votre source de catalogue a été créée :

    $ oc get pods -n openshift-marketplace

    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

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

  4. Utilisez la commande oc describe pour inspecter un pod et obtenir des informations plus détaillées :

    $ oc describe pod example-catalog-bwt8z -n openshift-marketplace

    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

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

7.6.4. Interrogation de l'état de la nacelle de l'opérateur

Vous pouvez dresser la liste des Operator Pods au sein d'un cluster et de leur statut. Vous pouvez également obtenir un résumé détaillé des Operator Pods.

Conditions préalables

  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
  • Your API service is still functional.
  • Vous avez installé l'OpenShift CLI (oc).

Procédure

  1. Liste des opérateurs en cours d'exécution dans la grappe. La sortie comprend la version de l'opérateur, la disponibilité et les informations sur le temps de fonctionnement :

    $ oc get clusteroperators
  2. Liste des pods de l'opérateur en cours d'exécution dans l'espace de noms de l'opérateur, ainsi que l'état du pod, les redémarrages et l'âge :

    oc get pod -n <operator_namespace>
  3. Produire un résumé détaillé de la nacelle de l'opérateur :

    oc describe pod <operator_pod_name> -n <operator_namespace>
  4. Si un problème lié à l'opérateur est spécifique à un nœud, demander l'état du conteneur de l'opérateur sur ce nœud.

    1. Démarrer un pod de débogage pour le nœud :

      $ oc debug node/my-node
    2. Définissez /host comme répertoire racine dans le shell de débogage. Le pod de débogage monte le système de fichiers racine de l'hôte dans /host au sein du pod. En changeant le répertoire racine en /host, vous pouvez exécuter les binaires contenus dans les chemins d'exécution de l'hôte :

      # chroot /host
      Note

      Les nœuds de cluster OpenShift Container Platform 4.12 exécutant Red Hat Enterprise Linux CoreOS (RHCOS) sont immuables et s'appuient sur les opérateurs pour appliquer les changements de cluster. L'accès aux nœuds de cluster à l'aide de SSH n'est pas recommandé et les nœuds seront altérés en tant que accessed. Cependant, si l'API OpenShift Container Platform n'est pas disponible, ou si le kubelet ne fonctionne pas correctement sur le nœud cible, les opérations oc seront impactées. Dans de telles situations, il est possible d'accéder aux nœuds en utilisant ssh core@<node>.<cluster_name>.<base_domain> à la place.

    3. Liste les détails des conteneurs du nœud, y compris l'état et les ID de pods associés :

      # crictl ps
    4. Répertorie les informations relatives à un conteneur d'opérateur spécifique sur le nœud. L'exemple suivant répertorie les informations relatives au conteneur network-operator:

      # crictl ps --name network-operator
    5. Quitter le shell de débogage.

7.6.5. Journal de bord de l'opérateur de collecte

Si vous rencontrez des problèmes avec l'opérateur, vous pouvez obtenir des informations de diagnostic détaillées à partir des journaux de pods de l'opérateur.

Conditions préalables

  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
  • Your API service is still functional.
  • Vous avez installé l'OpenShift CLI (oc).
  • Vous disposez des noms de domaine complets du plan de contrôle ou des machines du plan de contrôle.

Procédure

  1. Liste des pods de l'opérateur qui sont en cours d'exécution dans l'espace de noms de l'opérateur, ainsi que l'état du pod, les redémarrages et l'âge :

    oc get pods -n <operator_namespace>
  2. Examiner les journaux d'un module d'opérateur :

    oc logs pod/<nom_du_pod> -n <espace_de_noms_de_l'opérateur>

    Si un module Opérateur a plusieurs conteneurs, la commande précédente produira une erreur qui inclura le nom de chaque conteneur. Interroger les journaux d'un conteneur individuel :

    oc logs pod/<operator_pod_name> -c <container_name> -n <operator_namespace> -c <container_name> -n <operator_namespace>
  3. Si l'API n'est pas fonctionnelle, examinez les journaux des pods et des conteneurs de l'opérateur sur chaque nœud du plan de contrôle en utilisant plutôt SSH. Remplacez <master-node>.<cluster_name>.<base_domain> par les valeurs appropriées.

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

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl pods
    2. Pour tout pod opérateur n'affichant pas l'état Ready, inspectez l'état du pod en détail. Remplacez <operator_pod_id> par l'ID du pod opérateur figurant dans la sortie de la commande précédente :

      ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspectp <operator_pod_id>
    3. Liste des conteneurs liés à un module opérateur :

      ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps --pod=<operator_pod_id>
    4. Pour tout conteneur d'opérateur n'affichant pas l'état Ready, inspectez l'état du conteneur en détail. Remplacez <container_id> par un identifiant de conteneur figurant dans le résultat de la commande précédente :

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl inspect <container_id>
    5. Examinez les journaux des conteneurs de l'opérateur qui n'affichent pas l'état Ready. Remplacez <container_id> par un ID de conteneur figurant dans la sortie de la commande précédente :

      $ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl logs -f <container_id>
      Note

      Les nœuds de cluster OpenShift Container Platform 4.12 exécutant Red Hat Enterprise Linux CoreOS (RHCOS) sont immuables et dépendent des opérateurs pour appliquer les changements de cluster. L'accès aux nœuds de cluster à l'aide de SSH n'est pas recommandé et les nœuds seront altérés comme accessed. Avant d'essayer de collecter des données de diagnostic via SSH, vérifiez si les données collectées en exécutant oc adm must gather et d'autres commandes oc sont suffisantes. Cependant, si l'API OpenShift Container Platform n'est pas disponible, ou si le kubelet ne fonctionne pas correctement sur le nœud cible, les opérations oc seront impactées. Dans de telles situations, il est possible d'accéder aux nœuds en utilisant ssh core@<node>.<cluster_name>.<base_domain>.

7.6.6. Désactivation du redémarrage automatique de Machine Config Operator

Lorsque des changements de configuration sont effectués par l'opérateur de configuration de la machine (MCO), Red Hat Enterprise Linux CoreOS (RHCOS) doit redémarrer pour que les changements prennent effet. Que le changement de configuration soit automatique ou manuel, un nœud RHCOS redémarre automatiquement à moins qu'il ne soit mis en pause.

Note

Les modifications suivantes ne déclenchent pas de redémarrage du nœud :

  • Lorsque le MCO détecte l'un des changements suivants, il applique la mise à jour sans vidanger ou redémarrer le nœud :

    • Modifications de la clé SSH dans le paramètre spec.config.passwd.users.sshAuthorizedKeys de la configuration d'une machine.
    • Changements apportés au secret de tirage global ou au secret de tirage dans l'espace de noms openshift-config.
    • Rotation automatique de l'autorité de certification /etc/kubernetes/kubelet-ca.crt par l'opérateur du serveur API Kubernetes.
  • Lorsque le MCO détecte des modifications dans le fichier /etc/containers/registries.conf, telles que l'ajout ou la modification d'un objet ImageDigestMirrorSet ou ImageTagMirrorSet, il draine les nœuds correspondants, applique les modifications et désenregistre les nœuds :

    • L'ajout d'un registre avec le jeu de paramètres pull-from-mirror = "digest-only" pour chaque miroir.
    • L'ajout d'un miroir avec le paramètre pull-from-mirror = "digest-only" défini dans un registre.
    • L'ajout d'éléments à la liste unqualified-search-registries.

Pour éviter les perturbations indésirables, vous pouvez modifier le pool de configuration de la machine (MCP) afin d'empêcher le redémarrage automatique après que l'opérateur a apporté des modifications à la configuration de la machine.

Note

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

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

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

De nouveaux certificats CA sont générés à 292 jours de la date d'installation et supprimés à 365 jours de cette date. Pour déterminer la prochaine rotation automatique des certificats d'AC, consultez la section Comprendre le renouvellement automatique des certificats d'AC dans Red Hat OpenShift 4.

7.6.6.1. Désactivation du redémarrage automatique de l'opérateur Machine Config à l'aide de la console

Pour éviter les perturbations indésirables dues aux changements effectués par le Machine Config Operator (MCO), vous pouvez utiliser la console web d'OpenShift Container Platform pour modifier le pool de configuration de la machine (MCP) afin d'empêcher le MCO d'effectuer des changements sur les nœuds de ce pool. Cela évite les redémarrages qui feraient normalement partie du processus de mise à jour du MCO.

Note

Conditions préalables

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

Procédure

Pour suspendre ou annuler le redémarrage automatique de la mise à jour du MCO :

  • Interrompre le processus de redémarrage automatique :

    1. Connectez-vous à la console web de OpenShift Container Platform en tant qu'utilisateur ayant le rôle cluster-admin.
    2. Cliquez sur Compute MachineConfigPools.
    3. Sur la page MachineConfigPools, cliquez sur master ou worker, en fonction des nœuds pour lesquels vous souhaitez interrompre le redémarrage.
    4. Sur la page master ou worker, cliquez sur YAML.
    5. Dans le YAML, mettez à jour le champ spec.paused en le remplaçant par true.

      Exemple d'objet MachineConfigPool

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
       ...
      spec:
       ...
        paused: true 1

      1
      Mettez à jour le champ spec.paused en true pour interrompre le redémarrage.
    6. Pour vérifier que le MCP est en pause, revenez à la page MachineConfigPools.

      Sur la page MachineConfigPools, la colonne Paused indique True pour le GPE que vous avez modifié.

      Si le GPE a des modifications en attente alors qu'il est en pause, la colonne Updated est False et Updating est False. Lorsque Updated est True et Updating est False, il n'y a pas de modifications en attente.

      Important

      Si des modifications sont en attente (lorsque les colonnes Updated et Updating sont toutes deux False), il est recommandé de programmer une fenêtre de maintenance pour un redémarrage le plus tôt possible. Suivez les étapes suivantes pour interrompre le processus de redémarrage automatique afin d'appliquer les modifications qui ont été mises en attente depuis le dernier redémarrage.

  • Interrompre le processus de redémarrage automatique :

    1. Connectez-vous à la console web de OpenShift Container Platform en tant qu'utilisateur ayant le rôle cluster-admin.
    2. Cliquez sur Compute MachineConfigPools.
    3. Sur la page MachineConfigPools, cliquez sur master ou worker, en fonction des nœuds pour lesquels vous souhaitez interrompre le redémarrage.
    4. Sur la page master ou worker, cliquez sur YAML.
    5. Dans le YAML, mettez à jour le champ spec.paused en le remplaçant par false.

      Exemple d'objet MachineConfigPool

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
       ...
      spec:
       ...
        paused: false 1

      1
      Mettre à jour le champ spec.paused en false pour permettre le redémarrage.
      Note

      En débloquant un MCP, le MCO applique tous les changements interrompus et redémarre Red Hat Enterprise Linux CoreOS (RHCOS) si nécessaire.

    6. Pour vérifier que le MCP est en pause, revenez à la page MachineConfigPools.

      Sur la page MachineConfigPools, la colonne Paused indique False pour le GPE que vous avez modifié.

      Si le GPE applique des modifications en cours, la colonne Updated est False et la colonne Updating est True. Lorsque Updated est True et Updating est False, il n'y a plus de modifications en cours.

7.6.6.2. Désactivation du redémarrage automatique du Machine Config Operator à l'aide de la CLI

Pour éviter les perturbations indésirables dues aux changements effectués par le Machine Config Operator (MCO), vous pouvez modifier le pool de configuration de la machine (MCP) à l'aide de la CLI d'OpenShift (oc) afin d'empêcher le MCO d'effectuer des changements sur les nœuds de ce pool. Cela évite les redémarrages qui feraient normalement partie du processus de mise à jour du MCO.

Note

Conditions préalables

  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
  • Vous avez installé l'OpenShift CLI (oc).

Procédure

Pour suspendre ou annuler le redémarrage automatique de la mise à jour du MCO :

  • Interrompre le processus de redémarrage automatique :

    1. Mettre à jour la ressource personnalisée MachineConfigPool pour définir le champ spec.paused en true.

      Nœuds du plan de contrôle (maître)

      $ oc patch --type=merge --patch='{"spec":{"paused":true}}' machineconfigpool/master

      Nœuds de travail

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

    2. Vérifiez que le MCP est en pause :

      Nœuds du plan de contrôle (maître)

      $ oc get machineconfigpool/master --template='{{.spec.paused}}'

      Nœuds de travail

      $ oc get machineconfigpool/worker --template='{{.spec.paused}}'

      Exemple de sortie

      true

      Le champ spec.paused est true et le MCP est en pause.

    3. Déterminer si le MCP a des modifications en attente :

      # oc get machineconfigpool

      Exemple de sortie

      NAME     CONFIG                                             UPDATED   UPDATING
      master   rendered-master-33cf0a1254318755d7b48002c597bf91   True      False
      worker   rendered-worker-e405a5bdb0db1295acea08bcca33fa60   False     False

      Si la colonne UPDATED est False et UPDATING est False, des modifications sont en attente. Si UPDATED est True et UPDATING est False, il n'y a pas de modifications en attente. Dans l'exemple précédent, le nœud de travailleur a des modifications en attente. Le nœud du plan de contrôle n'a pas de modifications en attente.

      Important

      Si des modifications sont en attente (lorsque les colonnes Updated et Updating sont toutes deux False), il est recommandé de programmer une fenêtre de maintenance pour un redémarrage le plus tôt possible. Suivez les étapes suivantes pour interrompre le processus de redémarrage automatique afin d'appliquer les modifications qui ont été mises en attente depuis le dernier redémarrage.

  • Interrompre le processus de redémarrage automatique :

    1. Mettre à jour la ressource personnalisée MachineConfigPool pour définir le champ spec.paused en false.

      Nœuds du plan de contrôle (maître)

      $ oc patch --type=merge --patch='{"spec":{"paused":false}}' machineconfigpool/master

      Nœuds de travail

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

      Note

      En débloquant un MCP, le MCO applique tous les changements interrompus et redémarre Red Hat Enterprise Linux CoreOS (RHCOS) si nécessaire.

    2. Vérifiez que le MCP est désactivé :

      Nœuds du plan de contrôle (maître)

      $ oc get machineconfigpool/master --template='{{.spec.paused}}'

      Nœuds de travail

      $ oc get machineconfigpool/worker --template='{{.spec.paused}}'

      Exemple de sortie

      false

      Le champ spec.paused est false et le MCP est désactivé.

    3. Déterminer si le MCP a des modifications en attente :

      $ oc get machineconfigpool

      Exemple de sortie

      NAME     CONFIG                                   UPDATED  UPDATING
      master   rendered-master-546383f80705bd5aeaba93   True     False
      worker   rendered-worker-b4c51bb33ccaae6fc4a6a5   False    True

      Si le GPE applique des modifications en cours, la colonne UPDATED est False et la colonne UPDATING est True. Lorsque UPDATED est True et UPDATING est False, il n'y a plus de modifications en cours. Dans l'exemple précédent, le MCO met à jour le nœud de travailleur.

7.6.7. Actualisation des abonnements défaillants

Dans Operator Lifecycle Manager (OLM), si vous vous abonnez à un opérateur qui fait référence à des images qui ne sont pas accessibles sur votre réseau, vous pouvez trouver des travaux dans l'espace de noms openshift-marketplace qui échouent avec les erreurs suivantes :

Exemple de sortie

ImagePullBackOff for
Back-off pulling image "example.com/openshift4/ose-elasticsearch-operator-bundle@sha256:6d2587129c846ec28d384540322b40b05833e7e00b25cca584e004af9a1d292e"

Exemple de sortie

rpc error: code = Unknown desc = error pinging docker registry example.com: Get "https://example.com/v2/": dial tcp: lookup example.com on 10.0.0.1:53: no such host

En conséquence, l'abonnement est bloqué dans cet état d'échec et l'opérateur est incapable d'installer ou de mettre à niveau.

Vous pouvez actualiser un abonnement défaillant en supprimant l'abonnement, la version du service de cluster (CSV) et d'autres objets connexes. Après avoir recréé l'abonnement, OLM réinstalle la version correcte de l'opérateur.

Conditions préalables

  • Vous avez un abonnement défaillant qui ne parvient pas à extraire une image de paquet inaccessible.
  • Vous avez confirmé que l'image correcte de la liasse est accessible.

Procédure

  1. Obtenir les noms des objets Subscription et ClusterServiceVersion de l'espace de noms dans lequel l'opérateur est installé :

    $ oc get sub,csv -n <namespace>

    Exemple de sortie

    NAME                                                       PACKAGE                  SOURCE             CHANNEL
    subscription.operators.coreos.com/elasticsearch-operator   elasticsearch-operator   redhat-operators   5.0
    
    NAME                                                                         DISPLAY                            VERSION    REPLACES   PHASE
    clusterserviceversion.operators.coreos.com/elasticsearch-operator.5.0.0-65   OpenShift Elasticsearch Operator   5.0.0-65              Succeeded

  2. Supprimer l'abonnement :

    oc delete subscription <subscription_name> -n <namespace> $ oc delete subscription <subscription_name> -n <namespace>
  3. Supprimer la version du service de cluster :

    $ oc delete csv <csv_name> -n <namespace>
  4. Récupère les noms de tous les travaux défaillants et des cartes de configuration correspondantes dans l'espace de noms openshift-marketplace:

    $ oc get job,configmap -n openshift-marketplace

    Exemple de sortie

    NAME                                                                        COMPLETIONS   DURATION   AGE
    job.batch/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb   1/1           26s        9m30s
    
    NAME                                                                        DATA   AGE
    configmap/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb   3      9m30s

  5. Supprimer le travail :

    oc delete job <job_name> -n openshift-marketplace

    Cela permet de s'assurer que les pods qui tentent d'extraire l'image inaccessible ne sont pas recréés.

  6. Supprimer la carte de configuration :

    oc delete configmap <configmap_name> -n openshift-marketplace
  7. Réinstallez l'opérateur en utilisant OperatorHub dans la console web.

Vérification

  • Vérifiez que l'opérateur a été réinstallé avec succès :

    $ oc get sub,csv,installplan -n <namespace>
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.