Erreur d'entrée : ERRIODEG

Cloud privé virtuel Infrastructure classique Satellite

Apprenez à résoudre les erreurs ERRIODEG lorsque l'opérateur d'entrée est dans un état dégradé.

Vous pouvez utiliser la commande ibmcloud oc ingress status-report ignored-errors add pour ajouter une erreur à la liste des erreurs ignorées. Les erreurs ignorées apparaissent toujours dans la sortie de la commande ibmcloud oc ingress status-report get, mais sont ignorées lors du calcul du statut Ingress global.

Lorsque vous vérifiez le statut des composants Ingress de votre cluster en exécutant la commande ibmcloud oc ingress status-report get, vous voyez une erreur similaire à la suivante.

The Ingress Operator is in a degraded state (ERRIODEG).

L'opérateur Ingress vérifie l'état de santé des contrôleurs Ingress et passe à l'état dégradé lorsque les vérifications échouent.

Vérifiez que vos nœuds ne sont pas surchargés. Des nœuds surchargés peuvent entraîner l'échec des contrôles d'intégrité de l'Ingress Operator.

Pour vérifier si vous disposez d'une marge suffisante en termes de CPU et de mémoire, exécutez la commande suivante.

kubectl top nodes

Consultez les détails de l'erreur ClusterOperatoringress et suivez les étapes indiquées en fonction du message d'erreur.

Vérifiez le statut de l'opérateur ingress ClusterOperator. Si vous voyez False dans la colonne DEGRADED, attendez 10 à 15 minutes pour voir si l'avertissement de statut Ingress disparaît. Si ce n'est pas le cas, passez aux étapes de traitement des incidents en fonction du message de la colonne MESSAGE.

oc get clusteroperator ingress

Une ou plusieurs conditions de statut indiquent qu'il n'est pas disponible: DeploymentAvailable=False

  1. Vérifiez que votre cluster comporte au moins deux noeuds worker. Pour plus d'informations, voir Ajout de noeuds worker à des clusters classiques ou Ajout de noeuds worker à des clusters de VPC.
  2. Vérifiez que vos noeuds worker de cluster sont sains, sinon les pods de contrôleur Ingress ne peuvent pas être planifiés. Pour plus d'informations, voir Etats du noeud worker.

Une ou plusieurs conditions de statut indiquent qu'il n'est pas disponible: LoadBalancerReady=False

  1. VPC uniquement: Vérifiez que vous n'avez pas atteint votre quota d'instance LBaaS. Pour plus d'informations, voir Quotas and service limits et la commande ibmcloud is load-balancers .
  2. Vérifiez que les maîtres de votre cluster sont sains. Pour plus d'informations, voir Examen de la santé du maître.
  3. Actualisez vos maîtres de cluster en exécutant la ibmcloud oc cluster master refresh commande .

Une ou plusieurs autres conditions d'état indiquent un état dégradé: CanaryChecksSucceeding=False

  1. Accédez à votre cluster Red Hat OpenShift.

  2. Vérifiez que l'adresse de service LoadBalancer correcte est enregistrée pour votre sous-domaine Ingress.

    1. Exécutez la ibmcloud oc cluster get commande pour voir votre sous-domaine Ingress.
    2. Exécutez la commande ibmcloud oc nlb-dns get pour afficher les adresses enregistrées.
    3. Exécutez la commande oc get services -n openshift-ingress pour obtenir les adresses d'équilibreur de charge réelles.
    4. Comparez les adresses enregistrées et réelles et mettez à jour le sous-domaine s'il est différent. VPC: Exécutez la commande ibmcloud oc nlb-dns replace pour remplacer l'adresse en cours. Classique: Supprimez les adresses actuellement enregistrées en exécutant la commande ibmcloud oc nlb-dns rm classic , puis ajoutez les nouvelles adresses à l'aide de la commande ibmcloud oc nlb-dns add . Satellite: Les adresses réelles dépendent de votre configuration : si vous exposez vos nœuds de travail via un équilibreur de charge externe, enregistrez les adresses de cet équilibreur; sinon, enregistrez les adresses IP attribuées au service « router-external-default » dans l'espace de noms « openshift-ingress » (utilisez la commande « oc get services -n openshift-ingress router-external-default -o yaml » pour récupérer ces adresses). Supprimez les adresses actuellement enregistrées en exécutant la commande ibmcloud oc nlb-dns rm classic , puis ajoutez les nouvelles adresses à l'aide de la commande ibmcloud oc nlb-dns add .

  3. VPC uniquement: le trafic de diagnostic d'intégrité canary provient de l'un des noeuds worker de votre cluster.

    • Le trafic de diagnostic d'intégrité provient de l'un des noeuds worker de votre cluster. Dans le cas de clusters avec un noeud final de service public, le trafic est dirigé vers l'adresse IP flottante publique de l'instance d'équilibreur de charge VPC. Par conséquent, une Public Gateway doit être connectée à tous les sous-réseaux worker. Dans le cas de clusters avec uniquement des noeuds finaux de service privés, le trafic est dirigé vers l'adresse IP de sous-réseau VPC de l'équilibreur de charge VPC. Par conséquent, une Public Gateway n'est pas requise. Pour les clusters avec un noeud final de service public:
      1. Exécutez ibmcloud is public-gateways pour voir vos passerelles publiques.
      2. Exécutez le ibmcloud is subnets pour voir vos sous-réseaux.
      3. Pour chaque sous-réseau, exécutez la commande ibmcloud is subnet <subnet-id> pour vérifier chaque fois qu'elle possède une passerelle publique.
        1. Si aucune passerelle publique n'est connectée à votre sous-réseau, vous devez en connecter une. Pour plus d'informations, voir Création de passerelles publiques
    • Si vos équilibreurs de charge VPC se trouvent sur un sous-réseau autre que les noeuds worker de votre cluster, vous devez mettre à jour le groupe de sécurité connecté au sous-réseau d'équilibreur de charge VPC pour autoriser le trafic entrant des sous-réseaux worker.
    • Pour plus d'informations, voir Création d'un cluster Red Hat OpenShift dans votre cloud privé virtuel, Configuration de sous-réseaux VPC et Création et gestion de groupes de sécurité VPC.

  4. Assurez-vous qu'aucune règle de pare-feu ne bloque le trafic canary ou le trafic DNS sur UDP et TCP. VPC: le trafic canary provient de l’un des nœuds de travail, transite par un VPC Public Gateway et arrive sur le côté public de l’instance du répartiteur de charge VPC. Configurez vos groupes de sécurité VPC pour autoriser cette communication. Pour plus d'informations, voir Comprendre la mise en réseau sécurisée par défaut des clusters VPC et Créer et gérer des groupes de sécurité VPC. Classique: le trafic canarien provient de l'adresse IP publique de l'un des nœuds de travail et arrive à l'adresse IP publique de vos équilibreurs de charge classiques. Configurez vos règles réseau pour autoriser cette communication. Pour plus d'informations, voir Contrôle du trafic avec les stratégies réseau sur les clusters classiques.

Etapes suivantes

  1. Attendez 30 minutes, puis exécutez la commande oc get clusteroperator ingress et vérifiez à nouveau la colonne MESSAGE.
  2. Si vous voyez un message d'erreur différent, répétez les étapes de traitement des incidents.
  3. Si le problème persiste, contactez l'assistance. Ouverture d'un cas de support. Dans les détails du cas, veillez à inclure les fichiers journaux, les messages d'erreur ou les sorties de commande appropriés.