Debug di Ingress

Virtual Private Cloud Infrastruttura classica

Hai reso accessibile la tua app creando una risorsa Ingress per essa nel tuo cluster. Tuttavia, quando provi a stabilire una connessione alla tua applicazione tramite il dominio secondario Ingress o gli indirizzi IP dell'ALB, la connessione non riesce 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 " Scrittore " o " Responsabile "

Passo 1: Controlla la tua distribuzione dell'applicazione

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.

Passo 2: controlla i messaggi di errore nella distribuzione Ingress e nei log dei pod ALB

Inizia controllando l'eventuale presenza di messaggi di errore negli eventi di distribuzione di risorse Ingress o nei log dei pod ALB. Questi messaggi di errore possono aiutarti a individuare le cause alla base dei malfunzionamenti e a eseguire un'ulteriore analisi dei problemi della tua configurazione di Ingress nelle sezioni seguenti.

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

kubectl describe ingress <myingress>

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 gli ALB basati su Ingress- NGINX, consultare la documentazione sulla configurazione delle risorse Ingress o quella sulle annotazioni. Per gli ALB basati su Traefik, consultare la documentazione sulla configurazione delle risorse Ingress o quella sulla configurazione dell'Ingress Controller.

NAME:             myingress
Namespace:        default
Address:          169.xx.xxx.xxx,169.xx.xxx.xxx
Default backend:  <default>
Rules:
    Host                                             Path  Backends
    ----                                             ----  --------
    mycluster-<hash>-0000.us-south.containers.appdomain.cloud
    /tea      myservice1:80 (<none>)
    /coffee   myservice2:80 (<none>)
Annotations:                                         <none>
Events:
  Type    Reason  Age                From                      Message
  ----    ------  ----               ----                      -------
  Normal  Sync    26s (x8 over 19m)  nginx-ingress-controller  Scheduled for sync
  Normal  Sync    26s (x8 over 19m)  nginx-ingress-controller  Scheduled for sync

Controlla lo stato dei tuoi pod ALB.

Ottieni i pod ALB che sono in esecuzione nel tuo cluster.

    kubectl get pods -n kube-system | grep alb
    ```
2. Assicurati che tutti i pod siano in esecuzione controllando la colonna **STATUS**.

3. Se un pod non ha uno stato `Running` , puoi disabilitare e riabilitare l'ALB. Nei comandi seguenti, sostituire `<ALB_ID>` con l'ID dell'ALB del pod. Ad esempio, se il pod che non è in esecuzione ha il nome `public-crb2f60e9735254ac8b20b9c1e38b649a5-alb1-5d6d86fbbc-kxj6z`, l'ID ALB è `public-crb2f60e9735254ac8b20b9c1e38b649a5-alb1`.
    * Cluster classici:
        ```sh {: pre}
        ibmcloud ks ingress alb disable --alb <ALB_ID> -c <cluster_name_or_ID>
        ```
        ```sh {: pre}
        ibmcloud ks ingress alb enable classic --alb <ALB_ID> -c <cluster_name_or_ID>
        ```
    * Cluster VPC:
        ```sh {: pre}
        ibmcloud ks ingress alb disable --alb <ALB_ID> -c <cluster_name_or_ID>
        ```
        ```sh {: pre}
        ibmcloud ks ingress alb enable vpc-gen2 --alb <ALB_ID> -c <cluster_name_or_ID>
        ```

Verifica i log del tuo ALB.

Ottieni gli ID dei pod ALB che sono in esecuzione nel tuo cluster.

    kubectl get pods -n kube-system | grep alb
    ```
1. Per gli ALB basati su Ingress ( NGINX ), recupera i log del container `nginx-ingress` su ciascun pod dell'ALB. Per gli ALB basati su Traefik, recupera i log del container `traefik` su ciascun pod dell'ALB.
```sh {: pre}
    kubectl logs <ingress_pod_ID> <nginx-ingress/traefik> -n kube-system
    ```
1. Ricerca messaggi di errore nei log dell'ALB.

Passo 3: esegui il ping del dominio secondario ALB e degli indirizzi IP pubblici

Controlla la disponibilità del tuo dominio secondario Ingress e degli indirizzi IP pubblici di ALB. Inoltre, assicurati che il servizio IBM NS1 possa accedere ai tuoi ALB per eseguire i controlli di integrità.

Ottieni gli indirizzi IP (classici) o il nome host (VPC) su cui sono in ascolto i tuoi ALB pubblici.

ibmcloud ks ingress alb ls --cluster <cluster_name_or_ID>

Output di esempio per un cluster multizona classico con nodi di lavoro a dal10 e dal13:

ALB ID                                            Enabled   Status     Type      ALB IP          Zone    Build                          ALB VLAN ID   NLB Version
private-cr24a9f2caf6554648836337d240064935-alb1   false     disabled   private   -               dal13   ingress:1.1.2_2507_iks   2294021       -
private-cr24a9f2caf6554648836337d240064935-alb2   false     disabled   private   -               dal10   ingress:1.1.2_2507_iks   2234947       -
public-cr24a9f2caf6554648836337d240064935-alb1    true      enabled    public    169.62.196.238  dal13   ingress:1.1.2_2507_iks   2294019       -
public-cr24a9f2caf6554648836337d240064935-alb2    true      enabled    public    169.46.52.222   dal10   ingress:1.1.2_2507_iks   2234945       -

Se un ALB pubblico non ha un indirizzo IP (classico) o un nome host (VPC), consultare la sezione " L'ALB di ingresso non viene distribuito in una zona ".

Verifica che i tuoi indirizzi IP ALB siano raggiungibili dal controllo di integrità ALB.
- 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 Kubernetes e dagli indirizzi IP di IBM NS1 agli indirizzi IP degli ALB, in modo che il piano di controllo di Kubernetes possa verificare lo stato degli ALB. Ad esempio, se si utilizzano i criteri Calico, creare un criterio pre-DNAT Calico per consentire l'accesso in entrata agli indirizzi IP dell'ALB da IBM NS1 'indirizzi IP di origine sulla porta 80 e le sottoreti del piano di controllo per la regione in cui si trova il cluster.
- VPC: Se si dispone di un gruppo di sicurezza personalizzato sulle istanze VPC LBaaS (LoadBalancer-as-a-Service) per l'ingresso del cluster, assicurarsi che le regole del gruppo di sicurezza consentano il traffico necessario per il controllo dello stato di salute dalle istanze Kubernetes di indirizzi IP del piano di controllo alla porta 443.

Controlla l'integrità dei tuoi IP ALB (classici) o del nome host (VPC).

Eseguire un ping all'indirizzo IP (metodo classico) o al nome host (VPC) di ciascun ALB pubblico per verificare che ogni ALB sia in grado di ricevere correttamente i pacchetti. Se stai utilizzando gli ALB privati, puoi eseguire il ping dei loro indirizzi IP (classici) o del nome host (VPC) solo dalla rete privata.

    ping <ALB_IP>
    ```
    * Se la CLI restituisce un timeout e hai un firewall personalizzato che protegge i tuoi nodi di lavoro, assicurati di consentire ICMP nel tuo firewall.
    * Se non hai un firewall o il tuo firewall non blocca i ping e i ping continuano ad andare in timeout, [controlla lo stato dei tuoi pod ALB](#check_pods).

* Solo cluster multizona: puoi utilizzare il controllo di integrità MZLB per determinare lo stato dei tuoi IP ALB (classici) o del tuo nome host (VPC). Il seguente comando HTTP cURL utilizza l'host `albhealth`, che è configurato da IBM Cloud Kubernetes Service per restituire lo stato `healthy` o `unhealthy` per un IP ALB.
```sh {: pre}
    curl -X GET http://<ALB_IP>/ -H "Host: albhealth.<ingress_subdomain>"
    ```
    Comando di esempio:
    ```sh {: pre}
    curl -X GET http://169.62.196.238/ -H "Host: albhealth.mycluster-<hash>-0000.us-south.containers.appdomain.cloud"
    ```
    Output di esempio
    ```sh {: screen}
    healthy
    ```
     Se uno o più degli IP restituiscono `unhealthy`, [controlla lo stato dei tuoi pod ALB](#check_pods).

Ottieni il dominio secondario Ingress fornito da IBM.

ibmcloud ks 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

Assicurati che gli IP (classici) o il nome host (VPC) per ciascun ALB pubblico che hai ottenuto nel passo 1 di questa sezione siano registrati presso il dominio secondario Ingress fornito da IBM del tuo cluster. Ad esempio, in un cluster multizona classico, l'IP ALB pubblico in ciascuna zona dove hai dei nodi di lavoro deve essere registrato sotto lo stesso dominio secondario.
```
kubectl get ingress -o wide
```
Output di esempio
```
NAME                HOSTS                                                    ADDRESS                        PORTS     AGE
myingressresource   mycluster-<hash>-0000.us-south.containers.appdomain.cloud      169.46.52.222,169.62.196.238   80        1h
```

Passo 4: controlla le associazioni di dominio e la configurazione della risorsa Ingress

Se utilizzi un dominio personalizzato, verifica di aver utilizzato il tuo provider DNS per associare il dominio personalizzato al dominio secondario fornito da IBM oppure all'indirizzo IP pubblico di ALB. Nota: l'utilizzo di un CNAME è preferito perché IBM fornisce dei controlli dell'integrità automatici sul dominio secondario IBM e rimuove gli eventuali IP malfunzionanti dalla risposta DNS.

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.46.52.222
    mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.62.196.238
    ```
* **Record A indirizzo IP pubblico**: controlla che il tuo dominio personalizzato sia associato all'indirizzo IP pubblico portatile dell'ALB nel record A. Gli IP devono corrispondere agli IP ALB pubblici che hai ottenuto nel passo 1 della [sezione precedente](#ping).
```sh {: pre}
    host www.my-domain.com
    ```
    Output di esempio
    ```sh {: screen}
    www.my-domain.com has address 169.46.52.222
    www.my-domain.com has address 169.62.196.238
    ```

Controlla i file di configurazione delle risorse Ingress per il tuo cluster.
```
kubectl get ingress -o yaml
```
1. Assicurati di definire un host in una sola risorsa Ingress. Se un host è definito in più risorse Ingress, l'ALB 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 ks 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. Se la tua applicazione è configurata per essere in ascolto sul percorso root, utilizza / come percorso. Se il traffico in entrata su questo percorso deve essere reindirizzato verso un percorso diverso su cui la tua app è in ascolto, utilizza l'annotazione "rewrite paths " per Ingress: NGINX. Per Traefik, utilizzare il middleware “ ReplacePath ”.
4. Modifica il tuo YAML di configurazione delle risorse come necessario. Quando chiudi l'editor, le tue modifiche vengono salvate e applicate automaticamente.
```
    kubectl edit ingress <myingressresource>
    ```
```

Rimozione di un ALB dal DNS per il debug in Classic

Se non puoi accedere alla tua applicazione tramite uno specifico IP ALB, puoi rimuovere temporaneamente l'ALB dalla produzione disabilitandone la registrazione DNS. Puoi quindi utilizzare l'indirizzo IP dell'ALB per eseguire i test di debug su detto ALB.

Supponiamo ad esempio che hai un cluster multizona in 2 zone e 2 ALB pubblici hanno gli indirizzi IP 169.46.52.222 e 169.62.196.238. Anche se il controllo dell'integrità sta restituendo uno stato di integro per l'ALB della seconda zona, la tua applicazione non è raggiungibile direttamente per suo tramite. Decidi di rimuovere l'indirizzo IP di tale ALB, 169.62.196.238, dalla produzione per l'esecuzione del debug. l'IP ALB della prima zona, 169.46.52.222, viene registrato con il tuo dominio e continua a instradare il traffico mentre tu esegui il debug dell'ALB della seconda zona.

Utilizza il seguente comando per rimuovere l'indirizzo IP dal nome di dominio. Il comando di aggiornamento sostituisce completamente gli indirizzi IP registrati, quindi nel comando è necessario specificare solo gli indirizzi IP funzionanti:
```
ibmcloud ks ingress domain update --cluster <cluster_name> --domain <cluster domain> --ip 169.46.52.222
```
Verifica che l'indirizzo IP dell'ALB sia stato rimosso dalla registrazione DNS del tuo dominio controllando il server IBM NS1. Nota: l'aggiornamento della registrazione DNS potrebbe impiegare alcuni minuti.
```
host mycluster-<hash>-0000.us-south.containers.appdomain.cloud dns1.p02.nsone.net
```
Output di esempio che conferma che solo l'IP ALB integro, 169.46.52.222, rimane nella registrazione DNS e che l'IP ALB non integro, 169.62.196.238, è stato rimosso:
```
mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.46.52.222
```
Ora che l'IP ALB è stato rimosso dalla produzione, puoi servirtene per eseguire i test di debug sulla tua applicazione. Per eseguire un test delle comunicazioni alla tua applicazione tramite questo IP, puoi eseguire il seguente comando cURL, sostituendo i valori di esempio con i tuoi valori:
```
curl -X GET --resolve mycluster-<hash>-0000.us-south.containers.appdomain.cloud:443:169.62.196.238 https://mycluster-<hash>-0000.us-south.containers.appdomain.cloud/
```
- Se tutto è configurato correttamente, ottieni la risposta prevista dalla tua applicazione.
- Se in risposta ottieni un errore, ci potrebbe essere un errore nella tua applicazione oppure in una configurazione che si applica solo a questo specifico ALB. Controlla il codice della tua app, i file di configurazione delle risorse Ingress (per **Ingress- NGINX **) o la documentazione sulla configurazione di Ingress Controller per Traefik, nonché qualsiasi altra configurazione che hai applicato esclusivamente a questo ALB.

Una volta terminato il debug, ripristina la registrazione DNS dell'ALB utilizzando il seguente comando:

ibmcloud ks ingress domain update --cluster <cluster_name> --domain <cluster domain> --ip 169.46.52.222 --ip 169.62.196.238

Verifica che l'indirizzo IP dell'ALB sia stato ripristinato nella registrazione DNS del tuo dominio controllando il server IBM NS1. Nota: l'aggiornamento della registrazione DNS potrebbe impiegare alcuni minuti.

host mycluster-<hash>-0000.us-south.containers.appdomain.cloud dns1.p02.nsone.net

Output di esempio

mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.46.52.222
mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.62.196.238