Avant de procéder au débogage d'Ingress, consultez d'abord la rubrique Débogage des déploiements d'application. Les problèmes Ingress sont souvent provoqués par des problèmes sous-jacents dans votre déploiement d'application ou dans le service ClusterIP qui expose votre application. Par exemple, votre libellé d'application et votre sélecteur de service risquent de ne pas correspondre, ou vos ports cible d'application et de service risquent de ne pas correspondre.

Vérifiez le déploiement de votre ressource Ingress et recherchez les messages d'avertissement et d'erreur.

oc describe ingress <ingress_resource_name>

Dans la section Events de la sortie, vous pourrez voir des messages d'avertissement signalant des valeurs non valides dans votre ressource Ingress ou dans certaines annotations que vous avez utilisées. En ce qui concerne les annotations, veuillez noter que les annotations IBM Cloud Kubernetes Service (ingress.bluemix.net/<annotation>) et Ingress- NGINX (nginx.ingress.kubernetes.io/<annotation>) ne sont pas prises en charge pour le contrôleur Ingress ni pour la ressource Ingress dans la version 4 d’ Red Hat OpenShift. Si vous souhaitez personnaliser les règles de routage pour les applications d'un cluster qui utilise Red Hat OpenShift version 4, vous pouvez utiliser des annotations HAProxy spécifiques aux itinéraires, qui se présentent sous la forme haproxy.router.openshift.io/<annotation> ou router.openshift.io/<annotation>.

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>

Vérifiez le déploiement de votre ressource Route et recherchez d'éventuels avertissements ou messages d'erreur.

oc describe route <myroute>

Dans les sections Statut et Événements du résultat, vous pouvez voir s'afficher des messages d'avertissement concernant des valeurs non valides dans votre ressource Route ou dans certaines annotations que vous avez utilisées.

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>

Vérifiez les événements au niveau du cluster pour voir s'il y a des avertissements ou des messages d'erreur.

oc get events

Dans certains cas, des événements d'avertissement ou d'erreur liés aux ressources Ingress sont générés au niveau du cluster. N'oubliez pas que les événements sont limités à un espace de noms.

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

Vérifiez le fichier de configuration de la ressource Ingress ou Route.

oc get ingress -o yaml

1. Veillez à définir un hôte dans une seule ressource Ingress. Si un hôte est défini dans plusieurs ressources Ingress, le contrôleur Ingress risque de ne pas acheminer le trafic correctement et vous pourrez obtenir des erreurs.

2. Vérifiez que le sous-domaine et le certificat TLS sont corrects. Pour trouver le sous-domaine Ingress et le certificat TLS IBM, exécutez ibmcloud oc cluster get --cluster <cluster_name_or_ID>.

3. Assurez-vous que votre application est en mode écoute sur le même chemin que celui qui est configuré dans la section path de votre ressource Ingress.

4. Editez le fichier YAML de configuration de votre ressource selon les besoins. Lorsque vous fermez l'éditeur, vos modifications sont sauvegardées et automatiquement appliquées.

    oc edit ingress <myingressresource>
    ```

Vérifiez si vous avez atteint le nombre maximum d'équilibreurs de charge VPC autorisés par compte. Vérifiez les quotas de ressources Documentation des quotas VPC for VPC sur tous les clusters VPC de votre PC.

1. Décrivez les paramètres par défaut IngressController et consultez la section Conditions pour identifier les entrées de statut Unknown ou False ainsi que leurs messages.

    oc describe ingresscontroller/default -n openshift-ingress-operator
    ```
2. Répertoriez toutes les ressources `IngressController` afin de vérifier qu'aucune ne se trouve dans un état dégradé.
```sh {: pre}
    oc get ingresscontrollers -n openshift-ingress-operator
    ```

1. Obtenez les pods de contrôleur Ingress qui sont en cours d'exécution dans votre cluster.

    oc get pods -n openshift-ingress
    ```
2. Assurez-vous que tous `router-default` les pods et pods pour les contrôleurs d'entrée Ingress de n'importe quelle autre zone sont en cours d'exécution en vérifiant la colonne **STATUT**. Si vous disposez d'un cluster à zones multiples, notez que le service de contrôleur d'entrée dans la première zone où vous avez des nœuds worker est toujours nommé `router-default`, et que les services de contrôleur d'entrée dans les zones que vous ajoutez ultérieurement à votre cluster ont des noms tels que `router-dal12`.

3. Si un pod n'a pas pour statut `Running`, vous pouvez le supprimer pour le redémarrer.
```sh {: pre}
    oc delete pod <pod> -n openshift-ingress
    ```
4. Obtenez les journaux de chaque pod et examinez les éventuels messages d'erreur qu'ils contiennent.
```sh {: pre}
    oc logs <pod> -n openshift-ingress
    ```

1. Répertoriez les services de l'espace de noms openshift-ingress.

    oc get svc -n openshift-ingress
    ```
    Exemple de sortie d'un cluster multizone avec des noeuds worker dans les zones `dal10` et `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. Décrivez chaque service de contrôleur Ingress et recherchez les messages dans la section `Events` de la sortie.
```sh {: pre}
    oc describe svc router-default -n openshift-ingress
    ```
    Par exemple, dans les clusters de VPC, il se peut qu'un message d'erreur tel que `The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is offline` s'affiche. Pour plus d'informations, voir [Clusters VPC : pourquoi mon application ne peut-elle pas se connecter via l'équilibreur de charge ?](/docs/openshift?topic=openshift-vpc_ts_lb).

Vérifiez que les services de votre contrôleur d'entrée sont accessibles par le contrôle de santé du contrôleur d'entrée.

• Classic: Si vous utilisez les politiques réseau pré-DNAT d’ Calico ou un autre pare-feu personnalisé pour bloquer le trafic entrant vers votre cluster, vous devez autoriser l’accès entrant sur les ports 80 ou 443 depuis le plan de contrôle Red Hat OpenShift et les adresses IP IBM NS1 's IPv4 vers les adresses IP de vos services de contrôleur Ingress afin que le plan de contrôle Red Hat OpenShift puisse vérifier l’état de santé de vos contrôleurs Ingress. Par exemple, si vous utilisez des politiques Calico, créez une politique Calico pré-DNAT pour autoriser l’accès entrant à vos contrôleurs Ingress depuis les adresses IP sources IBM NS1, qui sont utilisées pour vérifier l’état de vos contrôleurs Ingress sur le port 80, ainsi que depuis les sous-réseaux du plan de contrôle de la région où se trouve votre cluster. Passez à l'étape suivante pour obtenir les adresses IP du service de contrôleur Ingress.

• VPC: si vous disposez d’un groupe de sécurité personnalisé sur les instances VPC LBaaS ( LoadBalancer-as-a-Service ) pour l’entrée du cluster, assurez-vous que les règles du groupe de sécurité autorisent le trafic nécessaire aux contrôles d’intégrité provenant des adresses IP du plan de contrôleKubernetes vers le port 443.

Obtenez les adresses IP externes sur lesquelles les services du contrôleur Ingress sont en mode écoute. Si vous disposez d'un cluster à zones multiples, notez que le service de contrôleur d'entrée dans la première zone où vous avez des nœuds worker est toujours nommé router-default, et que les services de contrôleur d'entrée dans les zones que vous ajoutez ultérieurement à votre cluster ont des noms tels que router-dal12. Dans les clusters de VPC, les adresses IP externes se trouvent derrière un nom d'hôte qui est affecté par l'équilibreur de charge VPC, par exemple, aabb1122-us-south.lb.appdomain.cloud.

oc get svc -n openshift-ingress

Exemple de sortie d'un cluster multizone classique avec des noeuds worker dans les zones dal10 et 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

Si un contrôleur d'entrée n'a pas d'adresse IP externe (classique) ou de nom d'hôte (VPC), voir Version 4 : Pourquoi le contrôleur Ingress se déploie-il dans une zone ?.

Vérifiez la santé de vos pods de contrôleur Ingress (classique) ou d'un nom d'hôte (VPC).

• Clusters Classic : Vérifiez le statut de vos pods de contrôleur Ingress.
• Clusters VPC : les services de routeur dans les clusters multizones sont créés avec un chemin /healthz qui vous permet de vérifier la santé de chaque adresse IP de service. La commande cURL HTTP suivante utilise le chemin /healthz, qui renvoie le statut ok pour une adresse IP saine.

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

Si une ou plusieurs adresses IP ne renvoient pas ok, Vérifier le statut de vos pods de contrôleur Ingress.

Obtenez le sous-domaine Ingress fourni par IBM.

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

Exemple de sortie

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

Vérifiez que l'adresse IP du contrôleur d'entrée est enregistrée avec le sous-domaine Ingress de votre cluster IBM Par exemple, dans un cluster multizone, l'adresse IP du contrôleur d'entrée public dans chaque zone où vous avez des nœuds worker doit être enregistrée sous le même sous-domaine.

host <ingress_subdomain>

Exemple de sortie

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

Si vous utilisez un domaine personnalisé, vérifiez que vous avez utilisé votre fournisseur DNS pour mapper le domaine personnalisé vers le sous-domaine fourni par IBMou l'adresse IP publique du contrôleur Ingress.

• CNAME de sous-domaine fourni par IBM : vérifiez que votre domaine personnalisé est mappé au sous-domaine fourni par IBM du cluster dans l'enregistrement CNAME (Canonical Name record).

    host www.my-domain.com
    ```
    Exemple de sortie
    ```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
    ```
* **Adresse IP publique Un enregistrement** : Vérifiez que votre domaine personnalisé est mappé sur l'adresse IP publique portable du contrôleur Ingress dans l'enregistrement A.
```sh {: pre}
    host www.my-domain.com
    ```
    Exemple de sortie
    ```sh {: screen}
    www.my-domain.com has address 169.XX.XX.XXX
    www.my-domain.com has address 169.XX.XX.XXX
    ```