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

  • Artikel
  • 9 Minuten Lesedauer

Verbindungsprobleme mit einem Microsoft Azure Kubernetes Service (AKS)-Cluster können unterschiedliche Dinge bedeuten. In einigen Fällen kann dies bedeuten, dass die Verbindung mit dem API-Server beeinträchtigt wird (z. B. mit kubectl). In anderen Fällen kann dies bedeuten, dass häufige Verbindungsprobleme sich auf eine Anwendung auswirken, die auf dem AKS-Cluster gehostet wird. In diesem Artikel wird die Behandlung von AKS-Clusterverbindungsproblemen erläutert.

Hinweis

Informationen zur Behandlung häufiger Probleme beim Herstellen einer Verbindung mit dem AKS-API-Server finden Sie unter Grundlegende Problembehandlung bei Clusterverbindungsproblemen mit dem API-Server.

Voraussetzungen

Zu berücksichtigenden Faktoren

In diesem Abschnitt werden die Schritte zur Problembehandlung behandelt, die sie ausführen müssen, wenn Sie versuchen, eine Verbindung mit der Anwendung herzustellen, die auf 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 Quelle und Ziel?

  • Was ist der Anforderungsantwortfluss?

  • Welche Hops haben zusätzliche Sicherheitsebenen oben, z. B. die folgenden Elemente:

    • Firewall
    • Netzwerksicherheitsgruppe (NSG)
    • Netzwerkrichtlinie

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

Wenn andere Schritte zur Problembehandlung kein schlüssiges Ergebnis liefern, führen Sie Paketerfassungen vom Client und Server aus. Paketerfassungen sind auch nützlich, 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 durchführen, ist es einfacher, ein Problem mit der Netzwerkkonnektivität zu beheben.

Grundlegender Netzwerkfluss für Anwendungen auf AKS

Im Allgemeinen lautet der Anforderungsfluss für den Zugriff auf Anwendungen, die auf einem AKS-Cluster gehostet werden, wie folgt:

Client >> DNS-Name >> IP-Adresse des AKS-Lastenausgleichs >> AKS-Knoten >> Pods

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

  • 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 Lastenausgleichsmodul 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 einfacher Anforderungsfluss an Anwendungen in einem AKS-Cluster würde dem Fluss ähneln, der im folgenden Diagramm dargestellt ist.

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

Problembehandlung im Innenbereich

Die Problembehandlung bei Konnektivitätsproblemen kann viele Überprüfungen umfassen, aber der Inside-Out-Ansatz kann dazu beitragen, die Ursache 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 nacheinander auf dem Endclient.

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

Um festzustellen, ob der Pod ausgeführt wird, führen Sie einen der folgenden Kubectl-Befehle aus :

# 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 Befehls "kubectl describe ":

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

Wenn sich der Pod nicht in einem Ready Zustand befindet oder Running mehrfach neu gestartet wurde, überprüfen Sie die kubectl describe Ausgabe. Die Ereignisse zeigen alle Probleme an, die verhindern, dass Sie den Pod starten können. Wenn der Pod gestartet wurde, ist die Anwendung im Pod möglicherweise fehlgeschlagen, wodurch der Pod neu gestartet wird. Beheben Sie eine entsprechende Problembehandlung für den Pod , um sicherzustellen, dass er sich in einem geeigneten Zustand befindet.

Wenn der Pod ausgeführt wird, kann es auch hilfreich sein, die Protokolle der Pods und der Darin befindlichen Container zu überprüfen. Führen Sie die folgenden Kubectl-Protokollbefehle 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 IP-Adresse des Anwendungsblocks zugreifen und überprüfen, ob die Anwendung ordnungsgemäß reagiert. Führen Sie die Kubectl-Ausführungapt-get und cURL befehle wie folgt aus:

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

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

Für Anwendungen, die auf andere Protokolle lauschen, können Sie relevante Tools im Test-Pod installieren und dann die Konnektivität mit dem Anwendungs-Pod überprüfen.

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

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

In Szenarien, in denen die Anwendung innerhalb des Pod 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 Pod 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 den Labels und Selectors für den Pod und den Dienst.

Sind die Endpunkte im Dienst korrekt? 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
  
# 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>

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 Lastenausgleichsgeräts zugreifen.

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

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

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

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

  2. Stellen Sie sicher, dass die Netzwerksicherheitsgruppen (Network Security Groups, NSGs), die den AKS-Knoten und dem AKS-Subnetz zugeordnet sind, den eingehenden Datenverkehr am Dienstport zulassen.

Weitere Befehle zur Problembehandlung für Dienste finden Sie unter Debugdienste.

Szenarien, in denen ein Ingress anstelle eines Diensts verwendet wird

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

Client >> DNS-Name >> Lastenausgleichs- oder Anwendungsgateway-IP-Adresse >> Ingress-Pods innerhalb des Clusters >> Service oder Pods

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

Auch hier können Sie den Inside-Out-Ansatz der Problembehandlung anwenden. Sie können auch die Details des Ein- und Aussteuerungscontrollers ü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.
  • Routen zu zwei Services im Back-End.

Stellen Sie sicher, dass 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 Ingresscontroller-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 Hostnamen oder die IP-Adresse des Absenders stellt, aber keine Einträge in den Protokollen des Eingangscontroller-Pod 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 auf den Ingress-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. Es könnte den Datenverkehr vom Lastenausgleichs- oder Anwendungsgateway zu den AKS-Knoten blockieren.

Weitere Informationen zur Problembehandlung bei Ingress (z. B. Nginx Ingress) finden Sie unter ingress-nginx troubleshooting.

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.

Haftungsausschluss für Kontaktinformationen von Drittanbietern

Microsoft stellt Kontaktinformationen von Drittanbietern bereit, damit Sie weitere Informationen zu diesem Thema finden können. Diese Kontaktinformationen können ohne vorherige Ankündigung geändert werden. Microsoft garantiert nicht die Genauigkeit von Kontaktinformationen von Drittanbietern.