Freigeben über

Behandeln von Verbindungsproblemen mit einer App, die in einem AKS-Cluster gehostet wird

  • Artikel

In aktuellen dynamischen Cloudumgebungen ist die Gewährleistung einer nahtlosen Verbindung mit Anwendungen, die in Azure Kubernetes Service (AKS)-Clustern gehostet werden, entscheidend für die Aufrechterhaltung der optimalen Leistung und Benutzererfahrung. In diesem Artikel wird beschrieben, wie Sie Konnektivitätsprobleme behandeln und beheben, die durch verschiedene Faktoren verursacht werden, einschließlich anwendungsseitiger Probleme, Netzwerkrichtlinien, Netzwerksicherheitsgruppenregeln (Network Security Group, NSG) oder anderen.

Notiz

Informationen zum Beheben häufig auftretender Probleme beim Herstellen einer Verbindung mit dem AKS-API-Server finden Sie unter Grundlegende Problembehandlung von Clusterverbindungsproblemen mit dem API-Server.

Voraussetzungen

Faktoren, die Sie berücksichtigen sollten

In diesem Abschnitt werden die Schritte zur Problembehandlung behandelt, die ausgeführt werden müssen, wenn Sie Probleme haben, wenn Sie versuchen, eine Verbindung mit der Anwendung herzustellen, die in einem AKS-Cluster gehostet wird.

In jedem Netzwerkszenario sollten Administratoren bei der Problembehandlung die folgenden wichtigen Faktoren berücksichtigen:

  • Was ist die Quelle und das Ziel für eine Anforderung?

  • Was sind die Hops zwischen der Quelle und dem Ziel?

  • Was ist der Anforderungsantwortfluss?

  • Welche Hops über zusätzliche Sicherheitsebenen verfügen, z. B. die folgenden Elemente:

    • Firewall
    • Netzwerksicherheitsgruppe (NSG)
    • Netzwerkrichtlinie

Wenn Sie jede Komponente überprüfen, rufen Sie HTTP-Antwortcodes ab und analysieren sie. Diese Codes sind nützlich, um die Art des Problems zu identifizieren und besonders hilfreich in Szenarien, in denen die Anwendung auf HTTP-Anforderungen reagiert.

Wenn andere Schritte zur Problembehandlung kein abschließendes Ergebnis liefern, nehmen Sie Paketerfassungen vom Client und Server ab. Paketerfassungen sind auch hilfreich, wenn nicht-HTTP-Datenverkehr zwischen Client und Server beteiligt ist. Weitere Informationen zum Sammeln von Paketerfassungen für die AKS-Umgebung finden Sie in den folgenden Artikeln im Leitfaden zur Datensammlung:

Wenn Sie wissen, wie Sie die HTTP-Antwortcodes abrufen und Paketerfassungen übernehmen, ist es einfacher, ein Netzwerkverbindungsproblem zu beheben.

Grundlegender Netzwerkfluss für Anwendungen auf AKS

Wenn Anwendungen mit dem Azure Load Balancer-Diensttyp verfügbar gemacht werden, lautet der Anforderungsfluss für den Zugriff auf diese Anwendungen wie folgt:

Client-DNS-Name >> >> AKS Load Balancer IP-Adresse >> AKS-Knoten >> Pods

Es gibt andere mögliche Situationen, in denen zusätzliche Komponenten beteiligt sein können. Zum Beispiel:

  • Der verwaltete NGINX-Ingress mit dem Add-On-Feature für das Anwendungsrouting ist aktiviert.
  • Das Anwendungsgateway wird über den Application Gateway Ingress Controller (AGIC) anstelle von Azure Load Balancer verwendet.
  • Azure Front Door und API Management können über dem Lastenausgleich verwendet werden.
  • Der Prozess verwendet einen internen Lastenausgleich.
  • Die Verbindung endet möglicherweise nicht am Pod und der angeforderten URL. Dies kann davon abhängen, ob der Pod eine Verbindung mit einer anderen Entität herstellen kann, z. B. einer Datenbank oder einem anderen Dienst im selben Cluster.

Es ist wichtig, den Anforderungsfluss für die Anwendung zu verstehen.

Ein grundlegender Anforderungsfluss zu Anwendungen in einem AKS-Cluster würde dem Fluss ähneln, der im folgenden Diagramm dargestellt wird.

Diagramm eines grundlegenden Anforderungsflusses zu Anwendungen auf einem Azure Kubernetes Service (A K S)-Cluster.

Problembehandlung im Innenbereich

Bei der Problembehandlung von Konnektivitätsproblemen kann es sich um viele Prüfungen handeln, aber der Inside-Out-Ansatz kann dazu beitragen, die Quelle des Problems zu finden und den Engpass zu identifizieren. Bei diesem Ansatz beginnen Sie mit dem Pod selbst und überprüfen, ob die Anwendung auf die IP-Adresse des Pods reagiert. Überprüfen Sie dann jede Komponente, um den Endclient zu aktivieren.

Schritt 1: Überprüfen, ob der Pod ausgeführt wird und die App oder der Container innerhalb des Pods ordnungsgemäß reagiert

Führen Sie einen der folgenden Kubectl-Get-Befehle aus, um zu ermitteln, ob der Pod ausgeführt wird:

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

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

Was geschieht, wenn der Pod nicht ausgeführt wird? Überprüfen Sie in diesem Fall die Pod-Ereignisse mithilfe des Kubectl-Beschreibungsbefehls :

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

Wenn sich der Pod nicht in einem Ready Oder Zustand befindet oder Running es mehrmals neu gestartet wurde, überprüfen Sie die kubectl describe Ausgabe. Die Ereignisse zeigen alle Probleme auf, die verhindern, dass Sie den Pod starten können. Oder wenn der Pod gestartet wurde, ist die Anwendung innerhalb des Pods möglicherweise fehlgeschlagen, sodass der Pod neu gestartet wird. Problembehandlung für den Pod entsprechend , um sicherzustellen, dass er sich in einem geeigneten Zustand befindet.

Wenn der Pod ausgeführt wird, kann es auch hilfreich sein, die Protokolle der Container zu überprüfen, die sich innerhalb des Pods befinden. Führen Sie die folgende Reihe von Kubectl-Protokollbefehlen aus:

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

Wird der Pod ausgeführt? Testen Sie in diesem Fall die Konnektivität, indem Sie einen Test pod im Cluster starten. Über den Test pod können Sie direkt auf die POD-IP-Adresse der Anwendung zugreifen und überprüfen, ob die Anwendung ordnungsgemäß reagiert. Führen Sie die Kubectl-Ausführung und cURL apt-getbefehle wie folgt aus:

# 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>

Für Anwendungen, die auf andere Protokolle lauschen, können Sie relevante Tools innerhalb des Test pods wie das Netcat-Tool installieren und dann die Verbindung mit dem Anwendungs pod überprüfen, indem Sie den folgenden Befehl ausführen:

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

Weitere Befehle zur Problembehandlung von Pods finden Sie unter Debuggen ausgeführter Pods.

Schritt 2: Überprüfen, ob die Anwendung vom Dienst aus erreichbar ist

Bei Szenarien, in denen die Anwendung innerhalb des Pods ausgeführt wird, können Sie sich hauptsächlich auf die Problembehandlung konzentrieren, wie der Pod verfügbar gemacht wird.

Wird der Pod als Dienst verfügbar gemacht? Überprüfen Sie in diesem Fall die Dienstereignisse. Überprüfen Sie außerdem, ob die Pod-IP-Adresse und der Anwendungsport als Endpunkt in der Dienstbeschreibung verfügbar sind:

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

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

Überprüfen Sie, ob die IP-Adresse des Pods als Endpunkt im Dienst vorhanden ist, wie im folgenden Beispiel gezeigt:

$ 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

Wenn die Endpunkte nicht auf die richtige POD-IP-Adresse verweisen, überprüfen Sie die Und für den Pod und den Dienst.If the endpoints aren't pointing to the correct pod IP address, verify the Labels and Selectors for the service.

Sind die Endpunkte im Dienst richtig? Wenn ja, greifen Sie auf den Dienst zu, und überprüfen Sie, ob die Anwendung erreichbar ist.

Zugreifen auf den ClusterIP-Dienst

Für den ClusterIP Dienst können Sie einen Test pod im Cluster starten und auf die Dienst-IP-Adresse zugreifen:

Diagramm der Verwendung eines Test pods in einem Azure Kubernetes Service (A K S)-Cluster für den Zugriff auf die Cluster-I P-Adresse. 

# 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>

Für Anwendungen, die auf andere Protokolle lauschen, können Sie relevante Tools innerhalb des Test pods wie das Netcat-Tool installieren und dann die Verbindung mit dem Anwendungs pod überprüfen, indem Sie den folgenden Befehl ausführen:

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

Wenn der vorherige Befehl keine entsprechende Antwort zurückgibt, überprüfen Sie die Dienstereignisse auf Fehler.

Zugreifen auf den LoadBalancer-Dienst

Für den LoadBalancer Dienst können Sie von außerhalb des Clusters auf die IP-Adresse des Lastenausgleichs zugreifen.

Diagramm eines Testbenutzers, der von außerhalb eines Azure Kubernetes Service (A K S)-Clusters auf die I P-Adresse des Lastenausgleichs zugreift. 

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

Für Anwendungen, die auf andere Protokolle lauschen, können Sie relevante Tools innerhalb des Test pods wie das Netcat-Tool installieren und dann die Verbindung mit dem Anwendungs pod überprüfen, indem Sie den folgenden Befehl ausführen:

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

Gibt die IP-Adresse des LoadBalancer Diensts eine richtige Antwort zurück? Wenn dies nicht der Fehler ist, führen Sie die folgenden Schritte aus:

  1. Überprüfen Sie die Ereignisse des Diensts.

  2. Überprüfen Sie, ob die Netzwerksicherheitsgruppen (Network Security Groups, NSGs), die den AKS-Knoten und dem AKS-Subnetz zugeordnet sind, den eingehenden Datenverkehr im Dienstport zulassen.

Weitere Befehle zur Problembehandlung von Diensten finden Sie unter Debugdienste.

Szenarien, die einen Eingangsschritt anstelle eines Diensts verwenden

Für Szenarien, in denen die Anwendung mithilfe einer Ingress Ressource verfügbar gemacht wird, ähnelt der Datenverkehrsfluss der folgenden Entwicklung:

Client-DNS-Name >> >> Load Balancer oder Anwendungsgateway-IP-Adresse >> Ingress-Controller-Pods innerhalb des Clusterdiensts >> oder -pods

Diagramm des Netzwerkdatenverkehrsflusses, wenn eine App innerhalb eines Azure Kubernetes Service (A K S)-Clusters mithilfe einer Eingangsressource verfügbar gemacht wird.

Sie können auch hier den inside-out-Ansatz der Problembehandlung anwenden. Sie können auch die Ressource "Ingress kubernetes" und die Details des Eingangscontrollers überprüfen, um weitere Informationen zu erhalten:

$ 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

Dieses Beispiel enthält eine Ingress Ressource, die:

  • Lauscht auf dem myapp.com Host.
  • Es sind zwei Path Zeichenfolgen konfiguriert.
  • Routes to two Services in the back end.

Überprüfen Sie, ob die Back-End-Dienste ausgeführt werden, und reagieren Sie auf den Port, der in der Beschreibung des Eingangs erwähnt wird:

$ 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

Überprüfen Sie die Protokolle für die Eingangscontroller-Pods, wenn ein Fehler auftritt:

$ 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

Was geschieht, wenn der Client Anforderungen an den Eingangshostnamen oder die IP-Adresse anfordert, aber keine Einträge in den Protokollen des Eingangscontroller-Pods angezeigt werden? In diesem Fall erreichen die Anforderungen möglicherweise nicht den Cluster, und der Benutzer erhält möglicherweise eine Connection Timed Out Fehlermeldung.

Eine weitere Möglichkeit besteht darin, dass die Komponenten über den Eingangs pods, z. B. Load Balancer oder Application Gateway, die Anforderungen nicht ordnungsgemäß an den Cluster weiterleiten. Wenn dies zutrifft, können Sie die Back-End-Konfiguration dieser Ressourcen überprüfen.

Wenn Sie eine Connection Timed Out Fehlermeldung erhalten, überprüfen Sie die Netzwerksicherheitsgruppe, die den AKS-Knoten zugeordnet ist. Überprüfen Sie auch das AKS-Subnetz. Möglicherweise wird der Datenverkehr vom Lastenausgleichsmodul oder Anwendungsgateway zu den AKS-Knoten blockiert.

Weitere Informationen zur Problembehandlung beim Eingangsausgang (z. B. Nginx Ingress) finden Sie unter "Ingress-nginx-Problembehandlung".

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.

Haftungsausschluss für Kontaktinformationen von Drittanbietern

Die Kontaktinformationen zu den in diesem Artikel erwähnten Drittanbietern sollen Ihnen helfen, zusätzliche Informationen zu diesem Thema zu finden. Diese Kontaktinformationen können ohne vorherige Ankündigung geändert werden. Sie werden von Microsoft ohne jede Gewähr weitergegeben.