Risolvere i problemi di connessione a un'app ospitata in un cluster del servizio Azure Kubernetes

Articolo
11/19/2024

Negli ambienti cloud dinamici correnti, garantire una perfetta connettività alle applicazioni ospitate nei cluster servizio Azure Kubernetes del servizio Azure Kubernetes è fondamentale per garantire prestazioni ottimali e un'esperienza utente. Questo articolo illustra come risolvere e risolvere i problemi di connettività causati da vari fattori, tra cui problemi sul lato applicazione, criteri di rete, regole del gruppo di sicurezza di rete o altri.

Note

Per risolvere i problemi comuni quando si tenta di connettersi al server API del servizio Azure Kubernetes, vedere Risoluzione di base dei problemi di connessione del cluster con il server API.

Prerequisiti

Lo strumento URL client (cURL) o uno strumento da riga di comando simile.
Lo strumento da riga di comando apt-get per la gestione dei pacchetti.
Strumento da riga di comando Netcat (nc) per le connessioni TCP.
Lo strumento Kubernetes kubectl o uno strumento simile per connettersi al cluster. Per installare kubectl usando l'interfaccia della riga di comando di Azure, eseguire il comando az aks install-cli .

Fattori da considerare

Questa sezione illustra i passaggi per la risoluzione dei problemi da eseguire se si verificano problemi quando si tenta di connettersi all'applicazione ospitata in un cluster del servizio Azure Kubernetes.

In qualsiasi scenario di rete, gli amministratori devono considerare i fattori importanti seguenti durante la risoluzione dei problemi:

Qual è l'origine e la destinazione per una richiesta?
Quali sono gli hop tra l'origine e la destinazione?
Qual è il flusso di richiesta-risposta?
Quali hop hanno livelli di sicurezza aggiuntivi sopra, ad esempio gli elementi seguenti:
- Firewall
- Gruppo di sicurezza di rete
- Criteri di rete

Quando si controlla ogni componente, ottenere e analizzare i codici di risposta HTTP. Questi codici sono utili per identificare la natura del problema e sono particolarmente utili negli scenari in cui l'applicazione risponde alle richieste HTTP.

Se altri passaggi per la risoluzione dei problemi non forniscono alcun risultato finale, acquisire pacchetti dal client e dal server. Le acquisizioni di pacchetti sono utili anche quando il traffico non HTTP è coinvolto tra il client e il server. Per altre informazioni su come raccogliere acquisizioni di pacchetti per l'ambiente del servizio Azure Kubernetes, vedere gli articoli seguenti nella guida alla raccolta dati:

Acquisire un dump TCP da un nodo Linux in un cluster del servizio Azure Kubernetes.
Acquisire un dump TCP da un nodo Windows in un cluster del servizio Azure Kubernetes.
Acquisire pacchetti TCP da un pod in un cluster del servizio Azure Kubernetes.

Conoscere come ottenere i codici di risposta HTTP e acquisire pacchetti semplifica la risoluzione di un problema di connettività di rete.

Flusso di rete di base per le applicazioni nel servizio Azure Kubernetes

In generale, quando le applicazioni vengono esposte usando il tipo di servizio Azure Load Balancer, il flusso di richiesta per accedervi è il seguente:

Pod del servizio di bilanciamento >> >> del carico del servizio Azure Kubernetes per il nome >> DNS del >> servizio Azure Kubernetes

Esistono altre situazioni in cui potrebbero essere coinvolti componenti aggiuntivi. Ad esempio:

L'ingresso NGINX gestito con la funzionalità del componente aggiuntivo di routing dell'applicazione è abilitato.
Il gateway applicazione viene usato tramite il controller di ingresso (AGIC) gateway applicazione anziché Azure Load Balancer.
Frontdoor di Azure e Gestione API possono essere usati sopra il servizio di bilanciamento del carico.
Il processo usa un servizio di bilanciamento del carico interno.
La connessione potrebbe non terminare nel pod e nell'URL richiesto. Questo può dipendere dal fatto che il pod possa connettersi a un'altra entità, ad esempio un database o qualsiasi altro servizio nello stesso cluster.

È importante comprendere il flusso di richiesta per l'applicazione.

Un flusso di richiesta di base alle applicazioni in un cluster del servizio Azure Kubernetes sarà simile al flusso illustrato nel diagramma seguente.

Risoluzione dei problemi all'interno dell'esterno

La risoluzione dei problemi di connettività potrebbe comportare molti controlli, ma l'approccio interno può aiutare a trovare l'origine del problema e identificare il collo di bottiglia. In questo approccio si inizia dal pod stesso, verificando se l'applicazione risponde all'indirizzo IP del pod. Controllare quindi ogni componente a sua volta fino al client finale.

Passaggio 1: Verificare se il pod è in esecuzione e l'app o il contenitore all'interno del pod risponde correttamente

Per determinare se il pod è in esecuzione, eseguire uno dei comandi kubectl get seguenti:

# List pods in the specified namespace.
kubectl get pods -n <namespace-name>

# List pods in all namespaces.
kubectl get pods -A

Cosa accade se il pod non è in esecuzione? In questo caso, controllare gli eventi del pod usando il comando kubectl describe :

kubectl describe pod <pod-name> -n <namespace-name>

Se il pod non è in Ready uno stato o Running o è stato riavviato più volte, controllare l'output kubectl describe . Gli eventi visualizzeranno eventuali problemi che impediscono di avviare il pod. In alternativa, se il pod è stato avviato, l'applicazione all'interno del pod potrebbe avere avuto esito negativo, causando il riavvio del pod. Risolvere i problemi del pod di conseguenza per assicurarsi che si tratti di uno stato appropriato.

Se il pod è in esecuzione, può anche essere utile controllare i log dei contenitori all'interno del pod. Eseguire la serie seguente di comandi kubectl logs :

kubectl logs <pod-name> -n <namespace-name>

# Check logs for an individual container in a multicontainer pod.
kubectl logs <pod-name> -n <namespace-name> -c <container-name>

# Dump pod logs (stdout) for a previous container instance.
kubectl logs <pod-name> --previous                      

# Dump pod container logs (stdout, multicontainer case) for a previous container instance.
kubectl logs <pod-name> -c <container-name> --previous

Il pod è in esecuzione? In questo caso, testare la connettività avviando un pod di test nel cluster. Dal pod di test è possibile accedere direttamente all'indirizzo IP del pod dell'applicazione e verificare se l'applicazione risponde correttamente. Eseguire i comandi kubectl run, apt-get, e cURL come indicato di seguito:

# Start a test pod in the cluster:
kubectl run -it --rm aks-ssh --image=debian:stable

# After the test pod is running, you will gain access to the pod.
# Then you can run the following commands:
apt-get update -y && apt-get install dnsutils -y && apt-get install curl -y && apt-get install netcat-traditional -y

# After the packages are installed, test the connectivity to the application pod:
curl -Iv http://<pod-ip-address>:<port>

Per le applicazioni in ascolto su altri protocolli, è possibile installare gli strumenti pertinenti all'interno del pod di test come lo strumento netcat e quindi controllare la connettività al pod dell'applicazione eseguendo il comando seguente:

# After the packages are installed, test the connectivity to the application pod using netcat/nc command:
nc -z -v <pod-ip-address> <port>

Per altri comandi per la risoluzione dei problemi relativi ai pod, vedere Eseguire il debug dei pod in esecuzione.

Passaggio 2: Verificare se l'applicazione è raggiungibile dal servizio

Per gli scenari in cui l'applicazione all'interno del pod è in esecuzione, è possibile concentrarsi principalmente sulla risoluzione dei problemi relativi all'esposizione del pod.

Il pod è esposto come servizio? In questo caso, controllare gli eventi del servizio. Controllare anche se l'indirizzo IP del pod e la porta dell'applicazione sono disponibili come endpoint nella descrizione del servizio:

# Check the service details.
kubectl get svc -n <namespace-name>

# Describe the service.
kubectl describe svc <service-name> -n <namespace-name>

Controllare se l'indirizzo IP del pod è presente come endpoint nel servizio, come nell'esempio seguente:

$ kubectl get pods -o wide  # Check the pod's IP address.
NAME            READY   STATUS        RESTARTS   AGE   IP            NODE                                
my-pod          1/1     Running       0          12m   10.244.0.15   aks-agentpool-000000-vmss000000  

$ kubectl describe service my-cluster-ip-service  # Check the endpoints in the service.
Name:              my-cluster-ip-service
Namespace:         default
Selector:          app=my-pod
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.0.174.133
IPs:               10.0.174.133
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.244.0.15:80     # <--- Here

$ kubectl get endpoints  # Check the endpoints directly for verification.
NAME                      ENDPOINTS           AGE
my-cluster-ip-service     10.244.0.15:80      14m

Se gli endpoint non puntano all'indirizzo IP del pod corretto, verificare e Labels Selectors per il pod e il servizio.

Gli endpoint nel servizio sono corretti? In tal caso, accedere al servizio e verificare se l'applicazione è raggiungibile.

Accedere al servizio ClusterIP

Per il ClusterIP servizio, è possibile avviare un pod di test nel cluster e accedere all'indirizzo IP del servizio:

# Start a test pod in the cluster:
kubectl run -it --rm aks-ssh --image=debian:stable
  
# After the test pod is running, you will gain access to the pod.
# Then, you can run the following commands:
apt-get update -y && apt-get install dnsutils -y && apt-get install curl -y && apt-get install netcat-traditional -y
  
# After the packages are installed, test the connectivity to the service:
curl -Iv http://<service-ip-address>:<port>

# After the packages are installed, test the connectivity to the application pod using netcat/nc command:
nc -z -v <pod-ip-address> <port>

Se il comando precedente non restituisce una risposta appropriata, verificare la presenza di eventuali errori negli eventi del servizio.

Accedere al servizio LoadBalancer

Per il LoadBalancer servizio, è possibile accedere all'indirizzo IP del servizio di bilanciamento del carico dall'esterno del cluster.

curl -Iv http://<service-ip-address>:<port>

nc -z -v <pod-ip-address> <port>

L'indirizzo IP del LoadBalancer servizio restituisce una risposta corretta? In caso contrario, seguire questa procedura:

Verificare gli eventi del servizio.
Verificare che i gruppi di sicurezza di rete (NSG) associati ai nodi del servizio Azure Kubernetes e alla subnet del servizio Azure Kubernetes consentano il traffico in ingresso sulla porta del servizio.

Per altri comandi per la risoluzione dei problemi dei servizi, vedere Eseguire il debug dei servizi.

Scenari che usano un ingresso anziché un servizio

Per gli scenari in cui l'applicazione viene esposta usando una Ingress risorsa, il flusso del traffico è simile alla progressione seguente:

Nome >> DNS client >> Servizio di bilanciamento del carico o pod >> del controller di ingresso del gateway applicazione all'interno del servizio o dei pod del cluster >>

È anche possibile applicare l'approccio interno alla risoluzione dei problemi. È anche possibile controllare i dettagli della risorsa kubernetes in ingresso e del controller di ingresso per altre informazioni:

$ kubectl get ing -n <namespace-of-ingress>  # Checking the ingress details and events.
NAME                         CLASS    HOSTS                ADDRESS       PORTS     AGE
hello-world-ingress          <none>   myapp.com            20.84.x.x     80, 443   7d22h

$ kubectl describe ing -n <namespace-of-ingress> hello-world-ingress
Name:             hello-world-ingress
Namespace:        <namespace-of-ingress>
Address:          20.84.x.x
Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>)
TLS:
  tls-secret terminates myapp.com
Rules:
  Host                Path  Backends
  ----                ----  --------
  myapp.com
                      /blog   blog-service:80 (10.244.0.35:80)
                      /store  store-service:80 (10.244.0.33:80)

Annotations:          cert-manager.io/cluster-issuer: letsencrypt
                      kubernetes.io/ingress.class: nginx
                      nginx.ingress.kubernetes.io/rewrite-target: /$1
                      nginx.ingress.kubernetes.io/use-regex: true
Events:
  Type    Reason  Age    From                      Message
  ----    ------  ----   ----                      -------
  Normal  Sync    5m41s  nginx-ingress-controller  Scheduled for sync
  Normal  Sync    5m41s  nginx-ingress-controller  Scheduled for sync

Questo esempio contiene una Ingress risorsa che:

È in ascolto sull'host myapp.com .
Dispone di due Path stringhe configurate.
Indirizza a due Services nel back-end.

Verificare che i servizi back-end siano in esecuzione e rispondere alla porta indicata nella descrizione in ingresso:

$ kubectl get svc -n <namespace-of-ingress>
NAMESPACE       NAME                                     TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                      
ingress-basic   blog-service                             ClusterIP      10.0.155.154   <none>        80/TCP                       
ingress-basic   store-service                            ClusterIP      10.0.61.185    <none>        80/TCP             
ingress-basic   nginx-ingress-ingress-nginx-controller   LoadBalancer   10.0.122.148   20.84.x.x     80:30217/TCP,443:32464/TCP

Verificare i log per i pod del controller in ingresso in caso di errore:

$ kubectl get pods -n <namespace-of-ingress>  # Get the ingress controller pods.
NAME                                                     READY   STATUS    RESTARTS   AGE
aks-helloworld-one-56c7b8d79d-6zktl                      1/1     Running   0          31h
aks-helloworld-two-58bbb47f58-rrcv7                      1/1     Running   0          31h
nginx-ingress-ingress-nginx-controller-9d8d5c57d-9vn8q   1/1     Running   0          31h
nginx-ingress-ingress-nginx-controller-9d8d5c57d-grzdr   1/1     Running   0          31h

$ # Check logs from the pods.
$ kubectl logs -n ingress-basic nginx-ingress-ingress-nginx-controller-9d8d5c57d-9vn8q

Cosa accade se il client effettua richieste al nome host o all'indirizzo IP in ingresso, ma non vengono visualizzate voci nei log del pod del controller in ingresso? In questo caso, le richieste potrebbero non raggiungere il cluster e l'utente potrebbe ricevere un Connection Timed Out messaggio di errore.

Un'altra possibilità è che i componenti sopra i pod in ingresso, ad esempio Load Balancer o gateway applicazione, non instradano correttamente le richieste al cluster. In questo caso, è possibile controllare la configurazione back-end di queste risorse.

Se viene visualizzato un Connection Timed Out messaggio di errore, controllare il gruppo di sicurezza di rete associato ai nodi del servizio Azure Kubernetes. Controllare anche la subnet del servizio Azure Kubernetes. Potrebbe bloccare il traffico dal servizio di bilanciamento del carico o dal gateway applicazione ai nodi del servizio Azure Kubernetes.

Per altre informazioni su come risolvere i problemi di ingresso (ad esempio Nginx Ingress), vedere risoluzione dei problemi di ingresso in ingresso-nginx.

Contattaci per ricevere assistenza

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.

Dichiarazione di non responsabilità di contatti di terze parti

Microsoft fornisce informazioni di contatto di terze parti per aiutarti a trovare ulteriori informazioni su questo argomento. Queste informazioni di contatto sono soggette a modifica senza preavviso. Microsoft non garantisce l'accuratezza delle informazioni di contatto di terze parti.

Condividi tramite