Freigeben über

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

  • Artikel

Verbindungsprobleme mit einem AKS-Cluster (Microsoft Azure Kubernetes Service) können unterschiedliche Bedeutungen haben. In einigen Fällen kann dies bedeuten, dass die Verbindung mit dem API-Server betroffen ist (z. B. durch Verwendung von kubectl). In anderen Fällen kann dies bedeuten, dass sich häufige Verbindungsprobleme auf eine Anwendung auswirken, die im AKS-Cluster gehostet wird. In diesem Artikel wird erläutert, wie Sie Probleme mit der AKS-Clusterverbindung beheben.

Hinweis

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

Voraussetzungen

Zu berücksichtigende Faktoren

In diesem Abschnitt werden Die Schritte zur Problembehandlung behandelt, die sie ausführen müssen, wenn Beim Versuch, eine Verbindung mit der Anwendung herzustellen, die in einem AKS-Cluster gehostet wird, Probleme auftreten.

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

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

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

  • Was ist der Anforderungs-Antwort-Flow?

  • Welche Hops verfügen über zusätzliche Sicherheitsebenen, 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 sind besonders hilfreich in Szenarien, in denen die Anwendung auf HTTP-Anforderungen antwortet.

Wenn andere Schritte zur Problembehandlung kein schlüssiges Ergebnis liefern, nehmen Sie Paketerfassungen vom Client und Server ab. 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 Die HTTP-Antwortcodes abgerufen und Paketerfassungen erfasst werden, können Sie ein Netzwerkkonnektivitätsproblem leichter beheben.

Grundlegender Netzwerkfluss für Anwendungen in AKS

Im Allgemeinen sieht der Anforderungsablauf für den Zugriff auf Anwendungen, die in einem AKS-Cluster gehostet werden, wie folgt aus:

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

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

  • Das Anwendungsgateway wird über den Application Gateway Eingangscontroller (AGIC) anstelle von Azure Load Balancer verwendet.
  • Azure Front Door und API Management können zusätzlich zum 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. mit 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 ähnelt dem Flow, der im folgenden Diagramm dargestellt ist.

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

Problembehandlung für inside-out

Die Behandlung von Konnektivitätsproblemen kann viele Überprüfungen umfassen, aber der Inside-out-Ansatz kann dabei helfen, die Ursache des Problems zu finden und den Engpass zu identifizieren. Bei diesem Ansatz beginnen Sie am Pod selbst und überprüfen, ob die Anwendung auf die IP-Adresse des Pods reagiert. Überprüfen Sie dann, ob jede Komponente bis zum Endclient angezeigt wird.

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 Podereignisse mithilfe des Befehls kubectl describe :

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

Wenn sich der Pod nicht im Ready Zustand oder Running befindet oder mehrmals neu gestartet wurde, überprüfen Sie die kubectl describe Ausgabe. Die Ereignisse zeigen alle Probleme auf, die Sie daran hindern, den Pod zu starten. Wenn der Pod gestartet wurde, ist die Anwendung innerhalb des Pods möglicherweise fehlgeschlagen, was dazu führt, dass der Pod neu gestartet wird. Behandeln Sie die 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 enthaltenen Container zu überprüfen. Führen Sie die folgenden Kubectl-Protokolle-Befehle 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 Testpod im Cluster starten. Über den Testpod können Sie direkt auf die Pod-IP-Adresse der Anwendung zugreifen und überprüfen, ob die Anwendung richtig reagiert. Führen Sie die Befehle kubectl run, apt-getund cURL 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

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

Für Anwendungen, die an anderen Protokollen lauschen, können Sie relevante Tools innerhalb des Testpods installieren und dann die Konnektivität mit dem Anwendungspod überprüfen.

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

In Szenarien, in denen die Anwendung im 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 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 und LabelsSelectors 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 Testpod im Cluster starten und auf die Dienst-IP-Adresse zugreifen:

Diagramm der Verwendung eines Testpods in einem Azure Kubernetes Service-Cluster (A K S) für den Zugriff auf die Ip-Adresse des Clusters. 

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

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-Clusters (KS) auf die IP-Adresse des Lastenausgleichs 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 (NSGs), die den AKS-Knoten und dem AKS-Subnetz zugeordnet sind, den eingehenden Datenverkehr am Dienstport zulassen.

Weitere Befehle zur Problembehandlung bei Diensten finden Sie unter Debuggen von Diensten.

Szenarien, in denen ein Eingang 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 >>>> : Lastenausgleich oder Ip-Adresse >> der Anwendungsgateway-Eingangspods innerhalb des Clusterdiensts >> oder der Pods

Diagramm des Netzwerkdatenverkehrsflusses, wenn eine App in einem Azure Kubernetes Service-Cluster (KS) mithilfe einer Eingangsressource verfügbar gemacht wird.

Sie können auch hier den Inside-Out-Ansatz der Problembehandlung anwenden. Weitere Informationen finden Sie auch in den Details des Eingangs- und Eingangscontrollers:

$ 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.
  • Verfügt über zwei Path konfigurierte Zeichenfolgen.
  • Routen zu zwei Services im Back-End.

Überprüfen Sie, ob die Back-End-Dienste ausgeführt werden, und reagieren Sie auf den Port, der in der Eingangsbeschreibung 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 Eingangscontrollerpods, wenn ein Fehler vorliegt:

$ 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 stellt, aber keine Einträge in den Protokollen des Eingangscontrollerpods 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 Eingangspods, 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 kann sein, dass der Datenverkehr vom Lastenausgleich oder Anwendungsgateway zu den AKS-Knoten blockiert wird.

Weitere Informationen zur Problembehandlung bei eingehenden Daten (z. B. Nginx Ingress) finden Sie unter ingress-nginx troubleshooting( 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.