Ingress-Fehler: ERRIODEG

Virtual Private Cloud Klassische Infrastruktur Satellite

Erfahren Sie, wie Sie ERRIODEG Fehler beheben können, wenn sich der Ingress Operator in einem gestörten Zustand befindet.

Mit dem Befehl ibmcloud oc ingress status-report ignored-errors add können Sie der Liste ignorierter Fehler einen Fehler hinzufügen. Ignorierte Fehler werden weiterhin in der Ausgabe des Befehls ibmcloud oc ingress status-report get angezeigt, aber bei der Berechnung des Ingress-Gesamtstatus ignoriert.

Wenn Sie den Status der Ingress-Komponenten Ihres Clusters überprüfen, indem Sie den Befehl ibmcloud oc ingress status-report get ausführen, wird ein Fehler ähnlich dem folgenden angezeigt.

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

Der Ingress-Operator überprüft den Zustand der Ingress-Controller und wechselt in einen verminderten Status, wenn die Prüfungen fehlschlagen.

Stellen Sie sicher, dass Ihre Knoten nicht überlastet sind. Überlastete Knoten können dazu führen, dass die Zustandsprüfungen des Ingress-Operators fehlschlagen.

Um zu überprüfen, ob Sie über ausreichende CPU- und Speicherreserven verfügen, führen Sie den folgenden Befehl aus.

kubectl top nodes

Informieren Sie sich über die ClusterOperatoringress und führen Sie die Schritte entsprechend der Fehlermeldung durch.

Überprüfen Sie den Status von ingress ClusterOperator. Wenn False in der Spalte DEGRADED angezeigt wird, warten Sie 10 bis 15 Minuten, um festzustellen, ob die Warnung zum Ingress-Status verschwindet. Ist dies nicht der Fall, fahren Sie mit den Schritten zur Fehlerbehebung auf der Basis der Nachricht in der Spalte MESSAGE fort.

oc get clusteroperator ingress

Mindestens eine Statusbedingung gibt 'Nicht verfügbar' an: DeploymentAvailable=False

  1. Stellen Sie sicher, dass Ihr Cluster mindestens zwei Worker enthält. Weitere Informationen finden Sie unter Workerknoten zu klassischen Clustern hinzufügen oder Workerknoten zu VPC-Clustern hinzufügen.
  2. Stellen Sie sicher, dass Ihre Cluster-Worker in einwandfreiem Zustand sind. Andernfalls können Ingress-Controller-Pods nicht geplant werden. Weitere Informationen finden Sie unter Status des Workerknotens.

Mindestens eine Statusbedingung gibt 'Nicht verfügbar' an: LoadBalancerReady=False

  1. Nur VPC: Stellen Sie sicher, dass das LBaaS-Instanzkontingent nicht erreicht wurde. Weitere Informationen finden Sie unter Kontingente und Servicegrenzwerte und im ibmcloud is load-balancers -Befehl.
  2. Stellen Sie sicher, dass Ihre Cluster-Master in einwandfreiem Zustand sind. Weitere Informationen finden Sie unter Masterstatus überprüfen.
  3. Aktualisieren Sie Ihre Cluster-Master mit dem ibmcloud oc cluster master refresh -Befehl.

Mindestens eine andere Statusbedingung gibt einen verminderten Status an: CanaryChecksSucceeding=False

  1. Rufen Sie Ihren Red Hat OpenShift-Cluster auf.

  2. Stellen Sie sicher, dass die richtige LoadBalancer-Serviceadresse für Ihre Ingress-Unterdomäne registriert ist.

    1. Führen Sie den ibmcloud oc cluster get -Befehl aus, um Ihre Ingress-Unterdomäne anzuzeigen.
    2. Führen Sie den ibmcloud oc nlb-dns get -Befehl aus, um die registrierten Adressen anzuzeigen.
    3. Führen Sie den Befehl oc get services -n openshift-ingress aus, um die tatsächlichen Adressen der Lastausgleichsfunktion abzurufen.
    4. Vergleichen Sie die registrierten und tatsächlichen Adressen und aktualisieren Sie die Unterdomäne, wenn sie sich unterscheidet. VPC: Führen Sie den ibmcloud oc nlb-dns replace -Befehl zum Ersetzen der aktuellen Adresse aus. Classic(Klassisch): Entfernen Sie die derzeit registrierten Adressen, indem Sie den ibmcloud oc nlb-dns rm classic -Befehl ausführen, und fügen Sie dann die neuen Adressen mit dem ibmcloud oc nlb-dns add -Befehl hinzu. Satellite: Die konkreten Adressen hängen von Ihrer Konfiguration ab: Wenn Sie Ihre Worker-Knoten über einen externen Load Balancer bereitstellen, registrieren Sie die Adressen des Load Balancers; andernfalls registrieren Sie die IP-Adressen, die dem Dienst „ router-external-default “ im Namespace „ openshift-ingress “ zugewiesen sind (verwenden Sie den Befehl „ oc get services -n openshift-ingress router-external-default -o yaml “, um die Adressen abzurufen). Entfernen Sie die derzeit registrierten Adressen, indem Sie den ibmcloud oc nlb-dns rm classic -Befehl ausführen, und fügen Sie anschließend die neuen Adressen mit dem ibmcloud oc nlb-dns add -Befehl hinzu.

  3. Nur VPC: Der Datenverkehr der Canary-Statusprüfung stammt von einem der Workerknoten Ihres Clusters.

    • Der Datenverkehr für die Statusprüfung stammt von einem der Workerknoten Ihres Clusters. Bei Clustern mit öffentlichem Serviceendpunkt wird der Datenverkehr an die öffentliche variable IP-Adresse der Instanz von VPC Load Balancer weitergeleitet. Daher muss allen Workerteilnetzen ein Public Gateway zugeordnet sein. Bei Clustern mit nur privaten Serviceendpunkten wird der Datenverkehr an die VPC-Teilnetz-IP-Adresse der VPC-Lastausgleichsfunktion weitergeleitet. Daher ist kein Public Gateway erforderlich. Für Cluster mit öffentlichem Serviceendpunkt:
      1. Führen Sie ibmcloud is public-gateways aus, um Ihre öffentlichen Gateways anzuzeigen.
      2. Führen Sie ibmcloud is subnets aus, um Ihre Teilnetze anzuzeigen.
      3. Führen Sie für jedes Teilnetz den Befehl ibmcloud is subnet <subnet-id> aus, um zu prüfen, wann ein öffentliches Gateway vorhanden ist.
        1. Wenn Ihrem Teilnetz kein öffentliches Gateway zugeordnet ist, müssen Sie ein solches anhängen. Weitere Informationen finden Sie unter Öffentliche Gateways erstellen.
    • Wenn sich Ihre VPC-Lastausgleichsfunktionen in einem anderen Teilnetz als den Workerknoten Ihres Clusters befinden, müssen Sie die Sicherheitsgruppe aktualisieren, die dem Teilnetz der VPC-Lastausgleichsfunktion zugeordnet ist, um eingehenden Datenverkehr von den Workerteilnetzen zuzulassen.
    • Weitere Informationen finden Sie unter Erstellen eines Red Hat OpenShift-Clusters in Ihrer virtuellen privaten Cloud, Konfigurieren von VPC-Teilnetzen und Erstellen und Verwalten von VPC-Sicherheitsgruppen.

  4. Stellen Sie sicher, dass keine Firewall-Regeln den Canary-Datenverkehr oder den DNS-Datenverkehr über UDP und TCP blockieren. VPC: Der Canary-Datenverkehr stammt von einem der Worker-Knoten, fließt durch einen VPC- Public Gateway n und gelangt zur öffentlichen Seite der VPC-Load-Balancer-Instanz. Konfigurieren Sie Ihre VPC-Sicherheitsgruppen, um diese Kommunikation zuzulassen. Weitere Informationen finden Sie unter Verstehen von standardmäßig sicheren Cluster-VPC-Netzwerken und Erstellen und Verwalten von VPC-Sicherheitsgruppen. Klassisch: Der Canary-Verkehr geht von der öffentlichen IP-Adresse eines der Worker Nodes aus und erreicht die öffentliche IP-Adresse Ihres klassischen Load Balancers. Konfigurieren Sie Ihre Netzrichtlinien, um diese Kommunikation zuzulassen. Weitere Informationen finden Sie unter Steuerung des Datenverkehrs mit Netzwerkrichtlinien auf klassischen Clustern.

Nächste Schritte

  1. Warten Sie 30 Minuten, führen Sie dann den Befehl oc get clusteroperator ingress aus und überprüfen Sie die Spalte MESSAGE erneut.
  2. Wenn eine andere Fehlernachricht angezeigt wird, wiederholen Sie die Fehlerbehebungsschritte.
  3. Wenn das Problem weiterhin auftritt, wenden Sie sich bitte an den Support. Öffnen Sie einen Supportfall. Stellen Sie in den Falldetails sicher, dass alle relevanten Protokolldateien, Fehlernachrichten oder Befehlsausgaben enthalten sind.