Debug di Ingress

Cloud privato virtuale Infrastruttura classica

Hai reso accessibile la tua app creando una risorsa Ingress per essa nel tuo cluster. Tuttavia, quando si tenta di connettersi all'app tramite il sottodominio Ingress o l'indirizzo IP del controller Ingress, la connessione fallisce o va in timeout.

La procedura nelle successive sezioni può aiutarti ad eseguire il debug della tua impostazione Ingress.

Prima di iniziare, assicurati di disporre delle seguenti politiche di accesso IBM Cloud IAM per IBM Cloud Kubernetes Service: - Ruolo di accesso alla piattaforma come redattore o amministratore per il cluster - Ruolo di accesso al servizio " Autore " o " Responsabile "

Vedi una pagina Applicazione non è disponibile quando provi ad accedere al dominio secondario della tua applicazione? Verifica la distribuzione dell'app e la configurazione delle risorse Ingress e Route. Vedi una pagina Timeout connessione? Controlla l'integrità dei pod del controller Ingress.

Passaggio 1: Verifica la distribuzione dell'app e la configurazione delle risorse Ingress e Route

Inizia controllando l'eventuale presenza di errori nella tua distribuzione dell'applicazione e la tua distribuzione della risorsa Ingress. I messaggi di errore nelle tue distribuzioni possono aiutarti a trovare le cause principali dei malfunzionamenti e di eseguire un ulteriore debug della tua configurazione Ingress nelle sezioni successive.

  1. Prima di eseguire il debug di Ingress, consulta innanzitutto Debug delle distribuzioni dell'applicazione. I problemi di Ingress sono spesso causati da problemi sottostanti nella tua distribuzione dell'applicazione oppure nel servizio ClusterIP che espone la tua applicazione. Ad esempio, la tua etichetta dell'applicazione e il selettore del servizio potrebbero non corrispondere oppure le porte di destinazione della tua applicazione e del servizio potrebbero non corrispondere.

  2. Controlla la tua distribuzione della risorsa Ingress e cerca eventuali avvertenze o messaggi di errore.

    oc describe ingress <ingress_resource_name>

    Nella sezione Events dell'output, potresti vedere dei messaggi di avvertenza relativi a valori non validi nella tua risorsa Ingress o in specifiche annotazioni che hai utilizzato. Per quanto riguarda le annotazioni, si noti che le annotazioni " IBM Cloud Kubernetes Service " (ingress.bluemix.net/<annotation>) e "Ingress- NGINX " (nginx.ingress.kubernetes.io/<annotation>) non sono supportate per il controller Ingress né per la risorsa Ingress nella versione 4 di Red Hat OpenShift. Se si vogliono personalizzare le regole di instradamento per le applicazioni in un cluster che esegue Red Hat OpenShift versione 4, si possono usare annotazioni HAProxy specifiche per le rotte, che sono nel formato haproxy.router.openshift.io/<annotation> o 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>

  3. Controlla l'implementazione della risorsa Route e verifica la presenza di avvisi o messaggi di errore.

    oc describe route <myroute>

    Nelle sezioni "Stato" ed "Eventi" dell'output potrebbero comparire messaggi di avviso relativi a valori non validi nella risorsa Route o in alcune annotazioni utilizzate.

    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>

  4. Verificare la presenza di avvisi o messaggi di errore negli eventi a livello di cluster.

    oc get events

    In alcuni casi, a livello di cluster vengono generati eventi di avviso o di errore relativi alle risorse Ingress. Tieni presente che gli eventi hanno un ambito limitato al namespace.

    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

  5. Controlla il file di configurazione della risorsa Ingress o Route.

    oc get ingress -o yaml

    1. Assicurati di definire un host in una sola risorsa Ingress. Se un host è definito in più risorse Ingress, il controller Ingress potrebbe non inoltrare correttamente il traffico e potresti riscontrare degli errori.

    2. Controlla che il dominio secondario e il certificato TLS siano corretti. Per individuare il sottodominio Ingress fornito da IBM e il certificato TLS, esegui il comando ibmcloud oc cluster get --cluster <cluster_name_or_ID>.

    3. Assicurati che la tua applicazione sia in ascolto sullo stesso percorso configurato nella sezione percorso del tuo Ingress.

    4. Modifica il tuo YAML di configurazione delle risorse come necessario. Quando chiudi l'editor, le tue modifiche vengono salvate e applicate automaticamente.

        oc edit ingress <myingressresource>
    ```

  6. Verifica se hai raggiunto il numero massimo di bilanciatori di carico VPC consentito per account. Controlla la documentazione delle quote VPC per le quote di risorse VPC in tutti i tuoi cluster VPC nel tuo VPC.

Fase 2: Verificare lo stato di funzionamento del controller Ingress

Verificare che l'operatore Ingress e il controller Ingress siano operativi. I controller Ingress sono gestiti dall'operatore Ingress. Il controller Ingress inoltra le richieste ai pod relativi a quella specifica app esclusivamente in base alle regole definite nella risorsa Ingress e implementate dal controller Ingress.

  1. Verifica lo stato del tuo operatore Ingress controllando la risorsa personalizzata IngressController. In Red Hat OpenShift su IBM Cloud, l'operatore Ingress è gestito dalla piattaforma e i suoi pod non sono accessibili direttamente. Verifica invece lo stato di funzionamento dell'operatore tramite lo stato delle risorse dell' IngressController.
    1. Descrivere l' IngressController e predefinito e consultare la sezione "Condizioni" per verificare la presenza di eventuali voci relative allo stato " False " o " Unknown " e i relativi messaggi.
        oc describe ingresscontroller/default -n openshift-ingress-operator
    ```
2. Elenca tutte le risorse di `IngressController` per verificare che nessuna si trovi in uno stato di degrado.
```sh {: pre}
    oc get ingresscontrollers -n openshift-ingress-operator
    ```
  2. Controlla lo stato e i log dei pod del controller Ingress.
    1. Recupera i pod dei controller Ingress in esecuzione nel tuo cluster.
        oc get pods -n openshift-ingress
    ```
2. Assicurati che tutti i pod di `router-default` e i pod dei controller Ingress in qualsiasi altra zona siano in esecuzione controllando la colonna **STATUS**. Se si dispone di un cluster multizona, tenere presente che il servizio del controller Ingress nella prima zona in cui sono presenti i nodi worker è sempre denominato `router-default`, mentre i servizi del controller Ingress nelle zone aggiunte successivamente al cluster hanno nomi del tipo `router-dal12`.

3. Se un pod non ha uno stato `Running`, puoi eliminarlo per riavviarlo.
```sh {: pre}
    oc delete pod <pod> -n openshift-ingress
    ```
4. Ottieni i log per ciascun pod e cerca i messaggi di errore nei log.
```sh {: pre}
    oc logs <pod> -n openshift-ingress
    ```
  3. Verificare la presenza di eventi ed errori su ciascun servizio del controller Ingress.
    1. Elenca i servizi nello spazio dei nomi openshift-ingress.
        oc get svc -n openshift-ingress
    ```
    Output di esempio per un cluster multizona con nodi di lavoro in `dal10` e `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. Descrivi ciascun servizio di controller di Ingress e verifica la presenza di messaggi nella sezione " `Events` " dell'output.
```sh {: pre}
    oc describe svc router-default -n openshift-ingress
    ```
    Ad esempio, nei cluster VPC, potrebbe comparire un messaggio di errore del tipo “ `The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is offline` ”. Per ulteriori informazioni, consulta [Cluster VPC: perché la mia applicazione non può connettersi tramite il programma di bilanciamento del carico?](/docs/openshift?topic=openshift-vpc_ts_lb).

Fase 3: Eseguire il ping del sottodominio Ingress e dell'indirizzo IP pubblico del controller Ingress

Controlla la disponibilità degli indirizzi IP pubblici del controller Ingress e verifica le mappature dei tuoi sottodomini. Inoltre, assicurati che il piano di controllo di Red Hat OpenShift possa accedere ai tuoi controller Ingress per verificarne lo stato di funzionamento.

  1. Verifica che i tuoi servizi di controller Ingress siano raggiungibili dal controllo di integrità del controller Ingress.

    • IPv4 C lassico: se si utilizzano i criteri di rete pre-DNAT di Calico o un altro firewall personalizzato per bloccare il traffico in entrata al cluster, è necessario consentire l'accesso in entrata sulla porta 80 o 443 dal piano di controllo di Red Hat OpenShift e dagli indirizzi IP di IBM NS1 agli indirizzi IP dei servizi del controllore di Ingress, in modo che il piano di controllo di Red Hat OpenShift possa verificare lo stato dei controllori di Ingress. Ad esempio, se si utilizzano i criteri Calico, creare un criterio pre-DNAT Calico per consentire l'accesso in entrata ai controller di Ingress da IBM NS1 'indirizzi IP di origine utilizzati per verificare lo stato dei controller di Ingress sulla porta 80 e le sottoreti del piano di controllo per la regione in cui si trova il cluster. Continua con il passaggio successivo per ottenere gli indirizzi IP del servizio controller Ingress.

    • VPC: If you have a custom security group on the VPC LBaaS (LoadBalancer-as-a-Service) instances for the cluster ingress, ensure that the security group rules allow the necessary health-check traffic from the Kubernetes indirizzi IP del piano di controllo to port 443.

  2. Recupera gli indirizzi IP esterni su cui sono in ascolto i servizi del controller Ingress. Se si dispone di un cluster multizona, tenere presente che il servizio del controller Ingress nella prima zona in cui sono presenti i nodi worker è sempre denominato router-default, mentre i servizi del controller Ingress nelle zone aggiunte successivamente al cluster hanno nomi del tipo router-dal12. Nei cluster VPC, gli indirizzi IP esterni si trovano dietro un nome host assegnato dal programma di bilanciamento del carico VPC, come aabb1122-us-south.lb.appdomain.cloud.

    oc get svc -n openshift-ingress

    Output di esempio per un cluster multizona classico con nodi di lavoro a dal10 e 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

    Se un controller Ingress non ha alcun indirizzo IP esterno (classico) o nome host (VPC), vedi Versione 4: perché il controller Ingress non viene distribuito in una zona?.

  3. Verifica lo stato dei tuoi pod dei controller Ingress (classici) o del nome host (VPC).

    • Cluster classici: controlla lo stato dei tuoi pod del controller Ingress.
    • Cluster VPC: i servizi router nei cluster multizona vengono creati con un percorso /healthz, in modo da poter verificare lo stato di integrità di ciascun indirizzo IP del servizio. Il seguente comando HTTP cURL utilizza il percorso /healthz , che restituisce lo stato ok per un indirizzo IP funzionante.
    curl -X GET http://<router_svc_IP_or_hostname>/healthz -H "Host:router-default.<ingress_subdomain>"

    Se uno o più indirizzi IP non restituiscono " ok", controlla lo stato dei pod del controller Ingress.

  4. Ottieni il dominio secondario Ingress fornito da IBM.

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

    Output di esempio

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

  5. Assicurati che l'indirizzo IP del controller Ingress sia registrato nel sottodominio Ingress fornito da IBM del tuo cluster. Ad esempio, in un cluster multizona, l'IP pubblico del controller Ingress in ciascuna zona in cui sono presenti nodi di lavoro deve essere registrato sotto lo stesso sottodominio.

    host <ingress_subdomain>

    Output di esempio

    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

  6. Se utilizzi un dominio personalizzato, verifica di aver utilizzato il tuo provider DNS per associare il dominio personalizzato al sottodominio fornito da IBM o all'indirizzo IP pubblico del controller Ingress.

    • Dominio secondario fornito da IBM: controlla che il tuo dominio personalizzato sia associato al dominio secondario fornito da IBM del cluster nel record CNAME (Canonical Name).
        host www.my-domain.com
    ```
    Output di esempio
    ```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
    ```
* **Record A dell'indirizzo IP pubblico**: verificare che il dominio personalizzato sia associato all'indirizzo IP pubblico portatile del controller Ingress nel record A.
```sh {: pre}
    host www.my-domain.com
    ```
    Output di esempio
    ```sh {: screen}
    www.my-domain.com has address 169.XX.XX.XXX
    www.my-domain.com has address 169.XX.XX.XXX
    ```