Condividi tramite

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

  • Articolo

I problemi di connessione a un cluster microsoft servizio Azure Kubernetes (servizio Azure Kubernetes) possono essere diversi. In alcuni casi, potrebbe significare che la connessione al server API è interessata (ad esempio, usando kubectl). In altri casi, potrebbe significare che i problemi di connessione comuni interessano un'applicazione ospitata nel cluster del servizio Azure Kubernetes. Questo articolo illustra come risolvere i problemi di connessione del cluster del servizio Azure Kubernetes.

Nota

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

Prerequisiti

  • Lo strumento URL client (cURL) o uno strumento da riga di comando simile.

  • Strumento da riga di comando apt-get per la gestione dei pacchetti.

  • 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 in caso di 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 richiesta-risposta?

  • Quali hop hanno livelli di sicurezza aggiuntivi nella parte superiore, ad esempio gli elementi seguenti:

    • Firewall
    • Gruppo di sicurezza di rete (NSG)
    • 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 risultati conclusivi, eseguire acquisizioni di 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 le acquisizioni di pacchetti per l'ambiente del servizio Azure Kubernetes, vedere gli articoli seguenti nella guida alla raccolta dati:

Sapere 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, il flusso di richiesta per l'accesso alle applicazioni ospitate in un cluster del servizio Azure Kubernetes è il seguente:

Pod dell'indirizzo IP del >>>> servizio di bilanciamento del carico del servizio Azure Kubernetes del nome >> DNS client >>

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

  • Il gateway applicazione viene usato tramite il gateway applicazione Ingress Controller (AGIC) anziché Azure Load Balancer.
  • È possibile usare Frontdoor di Azure e Gestione API in cima al servizio di bilanciamento del carico.
  • Il processo usa un servizio di bilanciamento del carico interno.
  • La connessione potrebbe non terminare in corrispondenza del pod e dell'URL richiesto. Ciò 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 per le applicazioni in un cluster del servizio Azure Kubernetes sarebbe simile al flusso illustrato nel diagramma seguente.

Diagramma di un flusso di richiesta di base alle applicazioni in un cluster servizio Azure Kubernetes (A K S).

Risoluzione dei problemi interni

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

Passaggio 1: Controllare 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 succede 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 uno Ready stato o Running o è stato riavviato più volte, controllare l'output kubectl describe . Gli eventi riveleranno eventuali problemi che impediscono di avviare il pod. In alternativa, se il pod è stato avviato, l'applicazione all'interno del pod potrebbe non riuscire, causando il riavvio del pod. Risolvere i problemi del pod di conseguenza per assicurarsi che sia in uno stato appropriato.

Se il pod è in esecuzione, può anche essere utile controllare i log dei pod e dei contenitori che si trovano al loro interno. 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-gete 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

# 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 e quindi controllare la connettività al pod dell'applicazione.

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 alla modalità di 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 LabelsSelectors 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:

Diagramma dell'uso di un pod di test in un cluster servizio Azure Kubernetes (A K S) per accedere all'indirizzo I P del cluster. 

# 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
  
# After the packages are installed, test the connectivity to the service:
curl -Iv http://<service-ip-address>:<port>

Se il comando precedente non restituisce una risposta appropriata, verificare la presenza di 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.

Diagramma di un utente di test che accede all'indirizzo I P del servizio di bilanciamento del carico dall'esterno di un cluster servizio Azure Kubernetes (A K S). 

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

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

  1. Verificare gli eventi del servizio.

  2. Verificare che i gruppi di sicurezza di rete 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 relativi ai servizi, vedere Servizi di debug.

Scenari che usano un ingresso anziché un servizio

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

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

Diagramma del flusso del traffico di rete quando un'app all'interno di un cluster servizio Azure Kubernetes (A K S) viene esposta usando una risorsa in ingresso.

È anche possibile applicare l'approccio inside-out per la risoluzione dei problemi qui. Per altre informazioni, è anche possibile controllare i dettagli del controller in ingresso e in ingresso:

$ 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:

  • Ascolta l'host myapp.com .
  • Ha due Path stringhe configurate.
  • Route 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 di ingresso se si verifica un 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 di ingresso? In questo caso, le richieste potrebbero non raggiungere il cluster e l'utente potrebbe ricevere un messaggio di Connection Timed Out 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. Se questo è vero, è possibile controllare la configurazione back-end di queste risorse.

Se viene visualizzato un messaggio di Connection Timed Out 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-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.