Bevor Sie den Ingress debuggen können, machen Sie sich mit den Informationen im Abschnitt App-Bereitstellungen debuggen vertraut. Ingress-Probleme sind häufig auf Probleme in Ihrer App-Bereitstellung oder in dem ClusterIP-Service zurückzuführen, über den Ihre App zugänglich gemacht wird. Es kann z. B. sein, dass Ihre App-Bezeichnung und der Serviceselektor nicht übereinstimmen oder für App und Service unterschiedliche Zielports verwendet werden.

Überprüfen Sie Ihre Ingress-Ressourcenbereitstellung und suchen Sie nach Warnungen und Fehlernachrichten.

oc describe ingress <ingress_resource_name>

Im Abschnitt Events der Ausgabe sehen Sie möglicherweise Nachrichten zu ungültigen Werten in Ihrer Ingress-Ressource oder in bestimmten Annotationen, die Sie verwendet haben. Beachten Sie bei Anmerkungen, dass die Anmerkungen IBM Cloud Kubernetes Service (ingress.bluemix.net/<annotation>) und Ingress- NGINX (nginx.ingress.kubernetes.io/<annotation>) für den Ingress-Controller oder die Ingress-Ressource in der Version 4 von Red Hat OpenShift nicht unterstützt werden. Wenn Sie Routing-Regeln für Anwendungen in einem Cluster anpassen möchten, auf dem Red Hat OpenShift Version 4 läuft, können Sie routenspezifische HAProxy Anmerkungen verwenden, die das Format haproxy.router.openshift.io/<annotation> oder router.openshift.io/<annotation> haben.

NAME:             myingress
Namespace:        default
Address:          169.xx.xxx.xxx,169.xx.xxx.xxx
Default backend:  default-http-backend:80 (<none>)
Rules:
    Host                                             Path  Backends
    ----                                             ----  --------
    mycluster-<hash>-0000.us-south.containers.appdomain.cloud
    /tea      myservice1:80 (<none>)
    /coffee   myservice2:80 (<none>)
Annotations:  <none>
Events:       <none>

Überprüfen Sie die Bereitstellung Ihrer Route-Ressource und achten Sie auf Warnungen oder Fehlermeldungen.

oc describe route <myroute>

In den Abschnitten Status und Ereignisse der Ausgabe werden möglicherweise Warnmeldungen zu ungültigen Werten in Ihrer Route-Ressource oder in bestimmten von Ihnen verwendeten Annotationen angezeigt.

Name:         myroute
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  route.openshift.io/v1
Kind:         Route
Metadata:
  Creation Timestamp:  2026-07-01T10:18:43Z
  Generation:          1
  Owner References:
    API Version:     networking.k8s.io/v1
    Controller:      true
    Kind:            Ingress
    Name:            coffee-ingress
    UID:             e7a18dd4-402d-461c-a41f-c4750b6d2032
  Resource Version:  178601
  UID:               17c623e6-e9ef-4179-a3ad-af8ea311f2e5
Spec:
  Host:  mycluster-<hash>-0000.us-south.containers.appdomain.cloud
  Path:  /
  Port:
    Target Port:  http
  Tls:
    Certificate:  ...
    Insecure Edge Termination Policy:  Redirect
    Key: ...
    Termination:  edge
  To:
    Kind:           Service
    Name:           myservice1
    Weight:         100
  Wildcard Policy:  None
Status:
  Ingress:
    Conditions:
      Last Transition Time:     2026-07-01T10:18:43Z
      Status:                   True
      Type:                     Admitted
    Host:                       mycluster-<hash>-0000.us-south.containers.appdomain.cloud
    Router Canonical Hostname:  router-default.mycluster-<hash>-0000.us-south.containers.appdomain.cloud
    Router Name:                default
    Wildcard Policy:            None
Events:  <none>

Überprüfen Sie die Ereignisse auf Cluster-Ebene auf Warnungen oder Fehlermeldungen.

oc get events

In einigen Fällen werden Warn- oder Fehlerereignisse im Zusammenhang mit Ingress-Ressourcen auf Cluster-Ebene ausgegeben. Beachten Sie, dass Ereignisse auf den Namensraum beschränkt sind.

LAST SEEN   TYPE      REASON                          OBJECT             MESSAGE
2m40s       Warning   IncompleteIngressToRouteRules   ingress/myingress  Incomplete ingress to route rules detected: Invalid or missing TLS secret for rule host "mycluster-<hash>-0000.us-south.containers.appdomain.cloud" at index 0, path index 0

Überprüfen Sie die Konfigurationsdatei der Ingress- oder Route-Ressource.

oc get ingress -o yaml

1. Stellen Sie sicher, dass Sie einen Host in nur einer Ingress-Ressource definieren. Wenn ein Host in mehreren Ingress-Ressourcen definiert ist, leitet der Ingress-Controller den Datenverkehr möglicherweise nicht ordnungsgemäß weiter und es können Fehler auftreten.

2. Prüfen Sie, ob die Unterdomäne und das TLS-Zertifikat korrekt sind. Um die von IBM bereitgestellte Ingress-Unterdomäne und das TLS-Zertifikat zu suchen, führen Sie ibmcloud oc cluster get --cluster <cluster_name_or_ID> aus.

3. Stellen Sie sicher, dass Ihre App denselben Pfad überwacht, der im Abschnitt path von Ingress konfiguriert ist.

4. Bearbeiten Sie die YAML-Datei für die Ressourcenkonfiguration nach Bedarf. Wenn Sie den Editor schließen, werden Ihre Änderungen gespeichert und automatisch angewendet.

    oc edit ingress <myingressresource>
    ```

Überprüfen Sie, ob die maximal zulässige Anzahl an VPC-Lastausgleichsfunktionen pro Konto erreicht wurde. Überprüfen Sie die Dokumentation zu VPC-Kontingenten auf VPC-Ressourcenkontingente in allen VPC-Clustern in Ihrer VPC.

1. Beschreiben Sie die Standardeinstellungen und IngressController überprüfen Sie den Abschnitt Bedingungen auf Einträge zum Status Unknown oder False sowie die dazugehörigen Meldungen.

    oc describe ingresscontroller/default -n openshift-ingress-operator
    ```
2. Listen Sie alle Ressourcen `IngressController` auf, um sicherzustellen, dass sich keine davon in einem beeinträchtigten Zustand befindet.
```sh {: pre}
    oc get ingresscontrollers -n openshift-ingress-operator
    ```

1. Rufen Sie die Pods des Ingress-Controllers ab, die in Ihrem Cluster aktiv sind.

    oc get pods -n openshift-ingress
    ```
2. Stellen Sie sicher, dass alle `router-default`-Pods und Pods für Ingress-Controller in allen anderen Zonen ausgeführt werden, indem Sie die Spalte **STATUS** überprüfen. Wenn Sie über einen Cluster mit mehreren Zonen verfügen, beachten Sie, dass der Ingress-Controllerservice in der ersten Zone, in der Sie über Workerknoten verfügen, immer den Namen `router-default` hat und Ingress-Controllerservices in den Zonen, die Sie später Ihrem Cluster hinzufügen, Namen wie `router-dal12` haben.

3. Wenn sich ein Pod nicht im Status `Running` befindet, können Sie den Pod löschen, um ihn erneut zu starten.
```sh {: pre}
    oc delete pod <pod> -n openshift-ingress
    ```
4. Rufen Sie die Protokolle für jeden Pod ab und suchen Sie in den Protokollen nach Fehlernachrichten.
```sh {: pre}
    oc logs <pod> -n openshift-ingress
    ```

1. Listen Sie die Services in Ihrem Namensbereich openshift-ingress auf.

    oc get svc -n openshift-ingress
    ```
    Beispielausgabe für einen Mehrzonencluster mit Workerknoten in `dal10` und `dal13`:
    ```sh {: screen}
    NAME                                         TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                      AGE
    router-dal13                                 LoadBalancer   172.21.47.119   169.XX.XX.XX   80:32318/TCP,443:30915/TCP   26d
    router-default                               LoadBalancer   172.21.47.119   169.XX.XX.XX   80:32637/TCP,443:31719/TCP   26d
    router-internal-default                      ClusterIP      172.21.51.30    <none>         80/TCP,443/TCP,1936/TCP      26d
    ```
2. Beschreiben Sie jeden Ingress-Controllerservice und suchen Sie nach Nachrichten im Abschnitt `Events` der Ausgabe.
```sh {: pre}
    oc describe svc router-default -n openshift-ingress
    ```
    Möglicherweise wird in VPC-Clustern eine Fehlernachricht wie `The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is offline` angezeigt. Weitere Informationen finden Sie in [VPC-Clusters: Warum kann meine App keine Verbindung über die Lastausgleichsfunktion herstellen?](/docs/openshift?topic=openshift-vpc_ts_lb).

Bestätigen Sie, dass Ihre Ingress-Controllerservices über die Statusprüfung des Ingress-Controllers erreichbar sind.

• Klassisch: Wenn Sie Netzwerkrichtlinien vor der DNAT-Weiterleitung ( Calico ) oder eine andere benutzerdefinierte Firewall verwenden, um eingehenden Datenverkehr zu Ihrem Cluster zu blockieren, müssen Sie den eingehenden Zugriff auf Port 80 oder 443 von den IP-Adressen der Steuerungsebene Red Hat OpenShift sowie von den IP-Adressen IBM und NS1 ( IPv4 ) zu den IP-Adressen Ihrer Ingress-Controller-Dienste zulassen, damit die Steuerungsebene Red Hat OpenShift den Zustand Ihrer Ingress-Controller überprüfen kann. Wenn Sie beispielsweise Calico-Richtlinien verwenden, erstellen Sie eine Calico-Pre-DNAT-Richtlinie, um eingehenden Zugriff auf Ihre Ingress-Controller von den Quell-IP-Adressen IBM und NS1 zuzulassen, die zur Überprüfung des Zustands Ihrer Ingress-Controller auf Port 80 sowie der Control-Plane-Subnetze der Region verwendet werden, in der sich Ihr Cluster befindet. Fahren Sie mit dem nächsten Schritt fort, um die IP-Adressen des Ingress-Controllerservice abzurufen.

• VPC: Wenn Sie eine benutzerdefinierte Sicherheitsgruppe für die VPC- LBaaS-Instanzen ( LoadBalancer-as-a-Service ) für den Cluster-Ingress eingerichtet haben, stellen Sie sicher, dass die Regeln der Sicherheitsgruppe den erforderlichen Health-Check-Datenverkehr von den IP-Adressen der Kubernetes-Steuerungsebene zu Port 443 zulassen.

Rufen Sie die externen IP-Adressen ab, an denen die Ingress-Controllerservices empfangsbereit sind. Wenn Sie über einen Cluster mit mehreren Zonen verfügen, beachten Sie, dass der Ingress-Controllerservice in der ersten Zone, in der Sie über Workerknoten verfügen, immer den Namen router-default hat und Ingress-Controllerservices in den Zonen, die Sie später Ihrem Cluster hinzufügen, Namen wie router-dal12 haben. Die externen IP-Adressen befinden sich in VPC-Clustern hinter einem Hostnamen, der von der VPC-Lastausgleichsfunktion zugewiesen wird; zum Beispiel aabb1122-us-south.lb.appdomain.cloud.

oc get svc -n openshift-ingress

Beispielausgabe für einen klassischen Mehrzonencluster mit Workerknoten in dal10 und dal13:

NAME                                         TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                      AGE
router-dal13                                 LoadBalancer   172.21.47.119   169.XX.XX.XX   80:32318/TCP,443:30915/TCP   26d
router-default                               LoadBalancer   172.21.47.119   169.XX.XX.XX   80:32637/TCP,443:31719/TCP   26d
router-internal-default                      ClusterIP      172.21.51.30    <none>         80/TCP,443/TCP,1936/TCP      26d

Wenn ein Ingress-Controller keine externe IP-Adresse (klassisch) oder keinen Hostnamen (VPC) hat, lesen Sie Version 4: Warum wird der Ingress-Controller nicht in einer Zone bereitgestellt?.

Überprüfen Sie den Status Ihrer Ingress-Controllerpods (klassisch) oder Hostnamen (VPC).

• Klassische Cluster: Überprüfen Sie den Status Ihrer Ingress-Controllerpods.
• VPC-Cluster: Router-Services in Multi-Zonen-Clustern werden mit einem /healthz-Pfad erstellt, damit Sie den Zustand jeder Service-IP-Adresse überprüfen können. Der folgende HTTP-cURL-Befehl verwendet den Pfad /healthz, der den Status ok für eine gesunde IP zurückgibt.

curl -X GET http://<router_svc_IP_or_hostname>/healthz -H "Host:router-default.<ingress_subdomain>"

Wenn eine oder mehrere IP-Adressen nicht ok zurückgeben, überprüfen Sie den Status der Ingress-Controllerpods.

Rufen Sie die von IBM bereitgestellte Ingress-Unterdomäne ab.

ibmcloud oc cluster get --cluster <cluster_name_or_ID> | grep Ingress

Beispielausgabe

Ingress Subdomain:      mycluster-<hash>-0000.us-south.containers.appdomain.cloud
Ingress Secret:         mycluster-<hash>-0000

Stellen Sie sicher, dass die IP-Adresse des Ingress-Controllers in der von IBM bereitgestellten Ingress-Unterdomäne Ihres Clusters registriert ist. In einem Cluster mit mehreren Zonen muss beispielsweise die öffentliche Ingress-Controller-IP in jeder Zone, in der Sie über einen Workerknoten verfügen, unter derselben Unterdomäne registriert sein.

host <ingress_subdomain>

Beispielausgabe

mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.XX.XX.XXX
mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.XX.XXX.XX

Wenn Sie eine angepasste Domäne verwenden, stellen Sie sicher, dass Sie Ihren DNS-Provider verwendet haben, um die angepasste Domäne der von IBM bereitgestellten Unterdomäne oder der öffentlichen IP-Adresse des Ingress-Controllers zuzuordnen.

• Von IBM bereitgestellte Unterdomäne - CNAME: Überprüfen Sie, ob Ihre angepasste Domäne der von IBM bereitgestellten Unterdomäne des Clusters im CNAME-Datensatz (kanonischer Name) zugeordnet ist.

    host www.my-domain.com
    ```
    Beispielausgabe
    ```sh {: screen}
    www.my-domain.com is an alias for mycluster-<hash>-0000.us-south.containers.appdomain.cloud
    mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.XX.XX.XXX
    mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.XX.XX.XXX
    ```
* **A-Datensatz für öffentliche IP-Adresse**: Überprüfen Sie, ob Ihre angepasste Domäne der portierbaren öffentlichen IP-Adresse des Ingress-Controllers im A-Datensatz zugeordnet ist.
```sh {: pre}
    host www.my-domain.com
    ```
    Beispielausgabe
    ```sh {: screen}
    www.my-domain.com has address 169.XX.XX.XXX
    www.my-domain.com has address 169.XX.XX.XXX
    ```