Debug di Ingress

Virtual Private Cloud Infrastruttura classica

Si espone l'applicazione creando una risorsa Ingress per l'applicazione nel 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 Editor o Administrator per il cluster
Ruolo di accesso al servizio Writer o Manager

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 ti possono aiutare a trovare le cause principali dei malfunzionamenti e a eseguire un ulteriore debug della tua impostazione di Ingress nelle sezioni successive.

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. Controlla la documentazione relativa alla configurazione delle risorse Ingress oppure la documentazione relativa alle annotazioni.

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:
    custom-port:        protocol=http port=7490; protocol=https port=4431
    location-modifier:  modifier='~' serviceName=myservice1;modifier='^~' serviceName=myservice2
Events:
    Type     Reason             Age   From                                                            Message
    ----     ------             ----  ----                                                            -------
    Normal   Success            1m    public-cr87c198fcf4bd458ca61402bb4c7e945a-alb1-258623678-gvf9n  Successfully applied ingress resource.
    Warning  TLSSecretNotFound  1m    public-cr87c198fcf4bd458ca61402bb4c7e945a-alb1-258623678-gvf9n  Failed to apply ingress resource.
    Normal   Success            59s   public-cr87c198fcf4bd458ca61402bb4c7e945a-alb1-258623678-gvf9n  Successfully applied ingress resource.
    Warning  AnnotationError    40s   public-cr87c198fcf4bd458ca61402bb4c7e945a-alb1-258623678-gvf9n  Failed to apply ingress.bluemix.net/custom-port annotation. Error annotation format error : One of the mandatory fields not valid/missing for annotation ingress.bluemix.net/custom-port
    Normal   Success            40s   public-cr87c198fcf4bd458ca61402bb4c7e945a-alb1-258623678-gvf9n  Successfully applied ingress resource.
    Warning  AnnotationError    2s    public-cr87c198fcf4bd458ca61402bb4c7e945a-alb1-258623678-gvf9n  Failed to apply ingress.bluemix.net/custom-port annotation. Invalid port 7490. Annotation can't use ports 7481 - 7490
    Normal   Success            2s    public-cr87c198fcf4bd458ca61402bb4c7e945a-alb1-258623678-gvf9n  Successfully applied ingress resource.

Controlla lo stato dei tuoi pod ALB.
1. 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:
```
ibmcloud ks ingress alb disable --alb <ALB_ID> -c <cluster_name_or_ID>
```
```
ibmcloud ks ingress alb enable classic --alb <ALB_ID> -c <cluster_name_or_ID>
```
  - Cluster VPC:
```
ibmcloud ks ingress alb disable --alb <ALB_ID> -c <cluster_name_or_ID>
```
```
ibmcloud ks ingress alb enable vpc-gen2 --alb <ALB_ID> -c <cluster_name_or_ID>
```
Verifica i log del tuo ALB.
1. Ottieni gli ID dei pod ALB che sono in esecuzione nel tuo cluster.
```
kubectl get pods -n kube-system | grep alb
```
2. Ottieni i log per il contenitore nginx-ingress su ciascun pod ALB.
```
kubectl logs <ingress_pod_ID> nginx-ingress -n kube-system
```
3. 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, assicuratevi che il bilanciatore di carico multizona di Akamai possa accedere ai vostri ALB per controllarli.

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 hostname (VPC), vedere ALB in ingresso non distribuito in una zona.

Verifica che i tuoi indirizzi IP ALB siano raggiungibili dal controllo di integrità ALB.
- Classic: se utilizzi le politiche di rete pre - DNAT Calico o un altro firewall personalizzato per bloccare il traffico in entrata al tuo cluster, devi consentire l'accesso in entrata sulla porta 80 o 443 dal piano di controllo Kubernetes e gli indirizzi IP IPv4 di Akamai agli indirizzi IP degli ALB in modo che il piano di controllo Kubernetes possa controllare l'integrità dei tuoi ALB. Ad esempio, se utilizzi le politiche Calico, creare una politica pre - DNAT Calico per consentire l'accesso in entrata ai tuoi indirizzi IP ALB da Indirizzi IP di origine Akamai sulla porta 80 e 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 il ping dell'indirizzo IP (classico) o dell'hostname (VPC) di ogni ALB pubblico per assicurarsi 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.
- 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.
```
curl -X GET http://<ALB_IP>/ -H "Host: albhealth.<ingress_subdomain>"
```
  Comando di esempio:
```
curl -X GET http://169.62.196.238/ -H "Host: albhealth.mycluster-<hash>-0000.us-south.containers.appdomain.cloud"
```
  Output di esempio
```
healthy
```
  Se uno o più degli IP restituiscono unhealthy, controlla lo stato dei tuoi pod ALB.

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
```
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.
```
host www.my-domain.com
```
  Output di esempio
```
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 trovare il sottodominio di Ingress e il certificato TLS forniti da IBM, eseguire 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 a questo percorso deve essere instradato a un percorso differente su cui la tua applicazione è in ascolto, utilizza l'annotazione di percorsi di riscrittura.
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

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.

Ottieni il nome dell'ALB con l'indirizzo IP irraggiungibile.

ibmcloud ks ingress alb ls --cluster <cluster_name> | grep <ALB_IP>

Ad esempio, l'IP irraggiungibile 169.62.196.238 appartiene all'ALB public-cr24a9f2caf6554648836337d240064935-alb1:

ALB ID                                            Enabled   Status     Type      ALB IP           Zone    Build                          ALB VLAN ID   NLB Version
public-cr24a9f2caf6554648836337d240064935-alb1    false     disabled   private   169.62.196.238   dal13   ingress:1.1.2_2507_iks   2294021       -

Utilizzando il nome ALB dal passo precedente, ottieni i nomi dei pod ALB. Il seguente comando utilizza il nome ALB di esempio dal passo precedente:

kubectl get pods -n kube-system | grep public-cr24a9f2caf6554648836337d240064935-alb1

Output di esempio

public-cr24a9f2caf6554648836337d240064935-alb1-7f78686c9d-8rvtq   2/2       Running   0          24m
public-cr24a9f2caf6554648836337d240064935-alb1-7f78686c9d-trqxc   2/2       Running   0          24m

Disabilita il controllo dell'integrità che viene eseguito per tutti i pod ALB. Ripeti questa procedura per ciascun pod ALB che hai ottenuto nel passo precedente. I comandi e l'output di esempio in questi passi utilizzano il primo pod, public-cr24a9f2caf6554648836337d240064935-alb1-7f78686c9d-8rvtq.
1. Accedi al pod ALB e controlla la riga server_name nel file di configurazione NGINX.
```
kubectl exec -ti public-cr24a9f2caf6554648836337d240064935-alb1-7f78686c9d-8rvtq -n kube-system -c nginx-ingress -- grep server_name /etc/nginx/conf.d/kube-system-alb-health.conf
```
  L'output di esempio conferma che il pod ALB è configurato con il sottodominio di controllo sanitario corretto, albhealth.<domain>:
```
server_name albhealth.mycluster-<hash>-0000.us-south.containers.appdomain.cloud;
```
2. Per rimuovere l'IP disabilitando il controllo dell'integrità, inserisci # davanti al server_name. Quando l'host virtuale albhealth.mycluster-<hash>-0000.us-south.containers.appdomain.cloud è disabilitato per l'ALB, il controllo automatico dello stato di salute rimuove automaticamente l'IP dalla risposta DNS.
```
kubectl exec -ti public-cr24a9f2caf6554648836337d240064935-alb1-7f78686c9d-8rvtq -n kube-system -c nginx-ingress -- sed -i -e 's*server_name*#server_name*g' /etc/nginx/conf.d/kube-system-alb-health.conf
```
3. Verifica che la modifica sia stata applicata.
```
kubectl exec -ti public-cr24a9f2caf6554648836337d240064935-alb1-7f78686c9d-8rvtq -n kube-system -c nginx-ingress -- grep server_name /etc/nginx/conf.d/kube-system-alb-health.conf
```
  Output di esempio
```
#server_name albhealth.mycluster-<hash>-0000.us-south.containers.appdomain.cloud
```
4. Per rimuovere l'IP dalla registrazione DNS, ricarica la configurazione NGINX.
```
kubectl exec -ti public-cr24a9f2caf6554648836337d240064935-alb1-7f78686c9d-8rvtq -n kube-system -c nginx-ingress -- nginx -s reload
```
5. Ripeti questa procedura per ciascun pod ALB.

Ora, quando provi ad eseguire il cURL dell'host albhealth per controllare l'integrità dell'IP ALB, il controllo non riesce.

curl -X GET http://169.62.196.238/ -H "Host: albhealth.mycluster-<hash>-0000.us-south.containers.appdomain.cloud"

Output:

<html>
    <head>
        <title>404 Not Found</title>
    </head>
    <body bgcolor="white"><center>
        <h1>404 Not Found</h1>
    </body>
</html>

Verificare che l'indirizzo IP ALB sia stato rimosso dalla registrazione DNS del dominio controllando il server Akamai. Nota: l'aggiornamento della registrazione DNS potrebbe impiegare alcuni minuti.
```
host mycluster-<hash>-0000.us-south.containers.appdomain.cloud ada.ns.Akamai.com
```
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 tuo codice dell'applicazione, i tuoi file di configurazione delle risorse Ingress o qualsiasi altra configurazione che hai applicato solo a questo ALB.
Dopo aver terminato il debug, ripristina il controllo dell'integrità sui pod ALB. Ripeti questa procedura per ciascun pod ALB.
1. Accedi al pod ALB e rimuovi # dal server_name.
```
kubectl exec -ti <pod_name> -n kube-system -c nginx-ingress -- sed -i -e 's*#server_name*server_name*g' /etc/nginx/conf.d/kube-system-alb-health.conf
```
2. Ricarica la configurazione NGINX in modo che sia applicato il ripristino del controllo dell'integrità.
```
kubectl exec -ti <pod_name> -n kube-system -c nginx-ingress -- nginx -s reload
```
Ora, quando esegui il cURL dell'host albhealth per controllare l'integrità dell'IP ALB, il controllo restituisce healthy.
```
curl -X GET http://169.62.196.238/ -H "Host: albhealth.mycluster-<hash>-0000.us-south.containers.appdomain.cloud"
```

Verificare che l'indirizzo IP ALB sia stato ripristinato nella registrazione DNS del dominio controllando il server Akamai. Nota: l'aggiornamento della registrazione DNS potrebbe impiegare alcuni minuti.

host mycluster-<hash>-0000.us-south.containers.appdomain.cloud ada.ns.Akamai.com

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