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 :
Condition | Description |
---|---|
| Une partie ou la totalité des sources du catalogue à utiliser pour la résolution sont malsaines. |
| Il manque un plan d'installation pour un abonnement. |
| Un plan d'installation pour un abonnement est en attente d'installation. |
| Un plan d'installation pour un abonnement a échoué. |
| La résolution des dépendances pour un abonnement a échoué. |
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
Liste des abonnements des opérateurs :
$ oc get subs -n <operator_namespace>
Utilisez la commande
oc describe
pour inspecter une ressourceSubscription
:oc describe sub <subscription_name> -n <operator_namespace>
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 conditionCatalogSourcesUnhealthy
a le statutfalse
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
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
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
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.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
estImagePullBackOff
. Ce statut indique qu'il y a un problème lors de l'extraction de l'image d'index de la source de catalogue.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.
Ressources supplémentaires
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
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
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>
Produire un résumé détaillé de la nacelle de l'opérateur :
oc describe pod <operator_pod_name> -n <operator_namespace>
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.
Démarrer un pod de débogage pour le nœud :
$ oc debug node/my-node
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
NoteLes 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 utilisantssh core@<node>.<cluster_name>.<base_domain>
à la place.Liste les détails des conteneurs du nœud, y compris l'état et les ID de pods associés :
# crictl ps
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
- 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
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>
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>
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.Liste des pods sur chaque nœud du plan de contrôle :
$ ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl pods
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>
Liste des conteneurs liés à un module opérateur :
ssh core@<master-node>.<cluster_name>.<base_domain> sudo crictl ps --pod=<operator_pod_id>
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>
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>
NoteLes 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 commandesoc
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érationsoc
seront impactées. Dans de telles situations, il est possible d'accéder aux nœuds en utilisantssh 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.
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.
-
Modifications de la clé SSH dans le paramètre
Lorsque le MCO détecte des modifications dans le fichier
/etc/containers/registries.conf
, telles que l'ajout ou la modification d'un objetImageDigestMirrorSet
ouImageTagMirrorSet
, 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
.
-
L'ajout d'un registre avec le jeu de paramètres
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.
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.
Voir le deuxième site NOTE
dans la rubrique Désactiver le redémarrage automatique de l'opérateur de configuration de la machine.
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 :
-
Connectez-vous à la console web de OpenShift Container Platform en tant qu'utilisateur ayant le rôle
cluster-admin
. -
Cliquez sur Compute
MachineConfigPools. - Sur la page MachineConfigPools, cliquez sur master ou worker, en fonction des nœuds pour lesquels vous souhaitez interrompre le redémarrage.
- Sur la page master ou worker, cliquez sur YAML.
Dans le YAML, mettez à jour le champ
spec.paused
en le remplaçant partrue
.Exemple d'objet MachineConfigPool
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfigPool ... spec: ... paused: true 1
- 1
- Mettez à jour le champ
spec.paused
entrue
pour interrompre le redémarrage.
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.
ImportantSi 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.
-
Connectez-vous à la console web de OpenShift Container Platform en tant qu'utilisateur ayant le rôle
Interrompre le processus de redémarrage automatique :
-
Connectez-vous à la console web de OpenShift Container Platform en tant qu'utilisateur ayant le rôle
cluster-admin
. -
Cliquez sur Compute
MachineConfigPools. - Sur la page MachineConfigPools, cliquez sur master ou worker, en fonction des nœuds pour lesquels vous souhaitez interrompre le redémarrage.
- Sur la page master ou worker, cliquez sur YAML.
Dans le YAML, mettez à jour le champ
spec.paused
en le remplaçant parfalse
.Exemple d'objet MachineConfigPool
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfigPool ... spec: ... paused: false 1
- 1
- Mettre à jour le champ
spec.paused
enfalse
pour permettre le redémarrage.
NoteEn débloquant un MCP, le MCO applique tous les changements interrompus et redémarre Red Hat Enterprise Linux CoreOS (RHCOS) si nécessaire.
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.
-
Connectez-vous à la console web de OpenShift Container Platform en tant qu'utilisateur ayant le rôle
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.
Voir le deuxième site NOTE
dans la rubrique Désactiver le redémarrage automatique de l'opérateur de configuration de la machine.
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 :
Mettre à jour la ressource personnalisée
MachineConfigPool
pour définir le champspec.paused
entrue
.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
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
esttrue
et le MCP est en pause.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.
ImportantSi 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 :
Mettre à jour la ressource personnalisée
MachineConfigPool
pour définir le champspec.paused
enfalse
.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
NoteEn débloquant un MCP, le MCO applique tous les changements interrompus et redémarre Red Hat Enterprise Linux CoreOS (RHCOS) si nécessaire.
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
estfalse
et le MCP est désactivé.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
Obtenir les noms des objets
Subscription
etClusterServiceVersion
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
Supprimer l'abonnement :
oc delete subscription <subscription_name> -n <namespace> $ oc delete subscription <subscription_name> -n <namespace>
Supprimer la version du service de cluster :
$ oc delete csv <csv_name> -n <namespace>
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
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.
Supprimer la carte de configuration :
oc delete configmap <configmap_name> -n openshift-marketplace
- 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>