Debug di Ingress

Virtual Private Cloud Classic infrastructure

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 Ingress- NGINX (nginx.ingress.kubernetes.io/<annotation>) non sono supportate né per il controller Ingress né per la risorsa Ingress nella versione 4 di Red Hat OpenShift. Se desideri personalizzare le regole di routing per le app in un cluster che esegue la versione 4 di " Red Hat OpenShift ", puoi utilizzare le annotazioni " HAProxy " specifiche per il percorso, che hanno il 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 la distribuzione 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 consentiti 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: Verifica lo stato di funzionamento del controller Ingress

Verificare che l’operatore Ingress e il controller Ingress siano in buono stato. I controller Ingress sono gestiti dall'operatore Ingress. Il controller Ingress inoltra le richieste ai pod relativi a quell’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, si noti 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).

Passaggio 3: Eseguire il comando ping sul sottodominio Ingress e sull'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 il bilanciatore di carico del controller Ingress sia raggiungibile dal controllo di integrità di Ingress.

    • Classico: se si utilizzano le politiche di rete pre-DNAT di Calico o un altro firewall personalizzato per bloccare il traffico da e verso il proprio cluster, compreso il tutorial sulla creazione di una politica pre-DNAT " Calico ", allora:

      • È necessario consentire l'accesso in entrata agli indirizzi IP dei propri ALB sulla porta 443, proveniente dai worker del cluster (poiché è da lì che proviene il controllo di integrità)
      • È inoltre necessario consentire l'accesso in uscita dai worker del cluster agli indirizzi IP dell'ALB sulla porta 443

    • VPC: Se hai personalizzato uno qualsiasi dei gruppi di sicurezza VPC per il tuo cluster o le ACL di rete VPC per le tue sottoreti.

      • È necessario assicurarsi che i gruppi di sicurezza VPC e le ACL di rete consentano l'accesso in entrata agli indirizzi IP del bilanciatore di carico Ingress VPC ( LBaaS ) sulla porta 443, proveniente dai worker del cluster (poiché è da lì che proviene il controllo di integrità)
      • È inoltre necessario assicurarsi che i gruppi di sicurezza VPC e gli ACL di rete consentano l'accesso in uscita dai worker del cluster agli indirizzi LBaaS sulla porta 443
      • Nel fare ciò, tieni presente che gli indirizzi del tuo VPC LBaaS (supponendo che tu stia utilizzando l'ALB, che è l'impostazione predefinita) potrebbero cambiare.

  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 dispone di un indirizzo IP esterno (versione classica) o di un nome host (VPC), consultare la sezione " 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 con il sottodominio Ingress fornito da IBM per il 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 configurato, tramite il tuo provider DNS, il collegamento tra il dominio personalizzato e il sottodominio fornito da IBM o l'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
    ```