Share via

Rozwiązywanie problemów z połączeniem z aplikacją hostowaną w klastrze usługi AKS

  • Artykuł

Problemy z połączeniem z klastrem usługi Microsoft Azure Kubernetes Service (AKS) mogą oznaczać różne rzeczy. W niektórych przypadkach może to oznaczać, że dotyczy to połączenia z serwerem interfejsu API (na przykład przy użyciu narzędzia kubectl). W innych przypadkach może to oznaczać, że typowe problemy z połączeniem mają wpływ na aplikację hostowaną w klastrze usługi AKS. W tym artykule omówiono sposób rozwiązywania problemów z połączeniem klastra usługi AKS.

Uwaga

Aby rozwiązać typowe problemy podczas próby nawiązania połączenia z serwerem interfejsu API usługi AKS, zobacz Podstawowe rozwiązywanie problemów z połączeniem klastra z serwerem interfejsu API.

Wymagania wstępne

Czynniki, które należy wziąć pod uwagę

W tej sekcji opisano kroki rozwiązywania problemów, które należy wykonać, jeśli występują problemy podczas próby nawiązania połączenia z aplikacją hostowaną w klastrze usługi AKS.

W każdym scenariuszu sieci administratorzy powinni wziąć pod uwagę następujące ważne czynniki podczas rozwiązywania problemów:

  • Jakie jest źródło i miejsce docelowe żądania?

  • Jakie są przeskoki między źródłem a miejscem docelowym?

  • Jaki jest przepływ żądania i odpowiedzi?

  • Które przeskoki mają dodatkowe warstwy zabezpieczeń na górze, takie jak następujące elementy:

    • Zapory
    • Sieciowa grupa zabezpieczeń
    • Zasady sieci

Po sprawdzeniu każdego składnika pobierz i przeanalizuj kody odpowiedzi HTTP. Te kody są przydatne do identyfikowania charakteru problemu i są szczególnie przydatne w scenariuszach, w których aplikacja odpowiada na żądania HTTP.

Jeśli inne kroki rozwiązywania problemów nie zapewniają żadnego jednoznacznego wyniku, wykonaj przechwytywanie pakietów z klienta i serwera. Przechwytywanie pakietów jest również przydatne, gdy między klientem a serwerem jest zaangażowany ruch inny niż HTTP. Aby uzyskać więcej informacji o sposobie zbierania przechwytywania pakietów dla środowiska usługi AKS, zobacz następujące artykuły w przewodniku zbierania danych:

Znajomość sposobu pobierania kodów odpowiedzi HTTP i przechwytywania pakietów ułatwia rozwiązywanie problemu z łącznością sieciową.

Podstawowy przepływ sieci dla aplikacji w usłudze AKS

Ogólnie rzecz biorąc, przepływ żądania uzyskiwania dostępu do aplikacji hostowanych w klastrze usługi AKS jest następujący:

Nazwa DNS klienta >> usługi AKS load balancer adres >> IP zasobników >> węzłów AKS >>

Istnieją inne możliwe sytuacje, w których mogą być zaangażowane dodatkowe składniki. Przykład:

  • Brama aplikacji jest używana za pośrednictwem kontrolera ruchu przychodzącego Application Gateway (AGIC) zamiast Azure Load Balancer.
  • Usługa Azure Front Door i API Management mogą być używane na szczycie modułu równoważenia obciążenia.
  • Proces używa wewnętrznego modułu równoważenia obciążenia.
  • Połączenie może nie zakończyć się w zasobniku i żądanym adresie URL. Może to zależeć od tego, czy zasobnik może nawiązać połączenie z inną jednostką, taką jak baza danych lub dowolna inna usługa w tym samym klastrze.

Ważne jest, aby zrozumieć przepływ żądań dla aplikacji.

Podstawowy przepływ żądań do aplikacji w klastrze usługi AKS będzie podobny do przepływu przedstawionego na poniższym diagramie.

Diagram podstawowego przepływu żądań do aplikacji w klastrze Azure Kubernetes Service (A K S).

Rozwiązywanie problemów wewnątrz

Rozwiązywanie problemów z łącznością może obejmować wiele testów, ale podejście do wewnątrz może pomóc znaleźć źródło problemu i zidentyfikować wąskie gardło. W tym podejściu rozpoczynasz od samego zasobnika, sprawdzając, czy aplikacja odpowiada na adres IP zasobnika. Następnie sprawdź każdy składnik z kolei do klienta końcowego.

Krok 1. Sprawdzanie, czy zasobnik jest uruchomiony, a aplikacja lub kontener wewnątrz zasobnika odpowiada poprawnie

Aby określić, czy zasobnik jest uruchomiony, uruchom jedno z następujących poleceń kubectl get :

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

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

Co zrobić, jeśli zasobnik nie jest uruchomiony? W takim przypadku sprawdź zdarzenia zasobnika za pomocą polecenia kubectl describe :

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

Jeśli zasobnik nie jest w Ready stanie lub Running jest wielokrotnie ponownie uruchamiany, sprawdź dane wyjściowe kubectl describe . Zdarzenia ujawnią wszelkie problemy, które uniemożliwiają uruchomienie zasobnika. Jeśli zasobnik został uruchomiony, aplikacja wewnątrz zasobnika mogła zakończyć się niepowodzeniem, co spowodowało ponowne uruchomienie zasobnika. Rozwiąż odpowiednie problemy z zasobnikiem , aby upewnić się, że jest w odpowiednim stanie.

Jeśli zasobnik jest uruchomiony, warto również sprawdzić dzienniki zasobników i kontenerów znajdujących się w nich. Uruchom następującą serię poleceń dzienników kubectl :

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

Czy zasobnik jest uruchomiony? W takim przypadku przetestuj łączność, uruchamiając zasobnik testowy w klastrze. Z zasobnika testowego możesz bezpośrednio uzyskać dostęp do adresu IP zasobnika aplikacji i sprawdzić, czy aplikacja odpowiada poprawnie. Uruchom polecenia kubectl run, apt-get, i cURL w następujący sposób:

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

W przypadku aplikacji, które nasłuchują innych protokołów, można zainstalować odpowiednie narzędzia wewnątrz zasobnika testowego, a następnie sprawdzić łączność z zasobnikiem aplikacji.

Aby uzyskać więcej poleceń rozwiązywania problemów z zasobnikami, zobacz Debugowanie uruchomionych zasobników.

Krok 2. Sprawdzanie, czy aplikacja jest osiągalna z usługi

W przypadku scenariuszy, w których aplikacja wewnątrz zasobnika jest uruchomiona, możesz skupić się głównie na rozwiązywaniu problemów z sposobem uwidoczniania zasobnika.

Czy zasobnik jest uwidoczniany jako usługa? W tym przypadku sprawdź zdarzenia usługi. Sprawdź również, czy adres IP zasobnika i port aplikacji są dostępne jako punkt końcowy w opisie usługi:

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

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

Sprawdź, czy adres IP zasobnika jest obecny jako punkt końcowy w usłudze, jak w poniższym przykładzie:

$ 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

Jeśli punkty końcowe nie wskazują poprawnego adresu IP zasobnika, sprawdź Labels wartości i Selectors zasobnika i usługi.

Czy punkty końcowe w usłudze są poprawne? Jeśli tak, uzyskaj dostęp do usługi i sprawdź, czy aplikacja jest osiągalna.

Uzyskiwanie dostępu do usługi ClusterIP

ClusterIP W przypadku usługi możesz uruchomić zasobnik testowy w klastrze i uzyskać dostęp do adresu IP usługi:

Diagram przedstawiający używanie zasobnika testowego w klastrze Azure Kubernetes Service (A K S) w celu uzyskania dostępu do adresu P klastra. 

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

Jeśli poprzednie polecenie nie zwraca odpowiedniej odpowiedzi, sprawdź zdarzenia usługi pod kątem błędów.

Uzyskiwanie dostępu do usługi LoadBalancer

LoadBalancer W przypadku usługi możesz uzyskać dostęp do adresu IP modułu równoważenia obciążenia spoza klastra.

Diagram użytkownika testowego uzyskującego dostęp do adresu P modułu równoważenia obciążenia spoza klastra Azure Kubernetes Service (A K S). 

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

LoadBalancer Czy adres IP usługi zwraca poprawną odpowiedź? Jeśli tak się nie stanie, wykonaj następujące kroki:

  1. Sprawdź zdarzenia usługi.

  2. Sprawdź, czy sieciowe grupy zabezpieczeń skojarzone z węzłami usługi AKS i podsiecią usługi AKS zezwalają na ruch przychodzący na porcie usługi.

Aby uzyskać więcej poleceń rozwiązywania problemów z usługami, zobacz Debugowanie usług.

Scenariusze korzystające z ruchu przychodzącego zamiast usługi

W przypadku scenariuszy, w których aplikacja jest uwidoczniona Ingress przy użyciu zasobu, przepływ ruchu przypomina następujący postęp:

Nazwa >> DNS klienta >> Moduł równoważenia obciążenia lub zasobniki ruchu przychodzącego bramy >> aplikacji w usłudze lub zasobnikach klastra >>

Diagram przepływu ruchu sieciowego, gdy aplikacja wewnątrz klastra Azure Kubernetes Service (A K S) jest uwidoczniona przy użyciu zasobu ruchu przychodzącego.

Tutaj możesz również zastosować podejście do rozwiązywania problemów wewnątrz. Aby uzyskać więcej informacji, możesz również sprawdzić szczegóły kontrolera ruchu przychodzącego i przychodzącego:

$ 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

Ten przykład zawiera Ingress zasób, który:

  • Nasłuchuje na hoście myapp.com .
  • Ma skonfigurowane dwa Path ciągi.
  • Kieruje do dwóch Services na zapleczu.

Sprawdź, czy usługi zaplecza są uruchomione, i odpowiedz na port wymieniony w opisie ruchu przychodzącego:

$ 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

Sprawdź dzienniki dla zasobników kontrolera ruchu przychodzącego, jeśli wystąpił błąd:

$ 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

Co zrobić, jeśli klient wysyła żądania do nazwy hosta ruchu przychodzącego lub adresu IP, ale w dziennikach zasobnika kontrolera ruchu przychodzącego nie są widoczne żadne wpisy? W takim przypadku żądania mogą nie docierać do klastra, a użytkownik może otrzymać Connection Timed Out komunikat o błędzie.

Inna możliwość polega na tym, że składniki znajdujące się na szczycie zasobników ruchu przychodzącego, takie jak Load Balancer lub Application Gateway, nie są prawidłowo routingiem żądań do klastra. Jeśli jest to prawda, możesz sprawdzić konfigurację zaplecza tych zasobów.

Jeśli zostanie wyświetlony Connection Timed Out komunikat o błędzie, sprawdź sieciową grupę zabezpieczeń skojarzoną z węzłami usługi AKS. Sprawdź również podsieć usługi AKS. Może to blokować ruch z modułu równoważenia obciążenia lub bramy aplikacji do węzłów usługi AKS.

Aby uzyskać więcej informacji na temat rozwiązywania problemów z ruchem przychodzącym (takim jak ruch przychodzący Nginx), zobacz rozwiązywanie problemów z ruchem przychodzącym nginx.

Skontaktuj się z nami, aby uzyskać pomoc

Jeśli masz pytania lub potrzebujesz pomocy, utwórz wniosek o pomoc techniczną lub zadaj pytanie w społeczności wsparcia dla platformy Azure. Możesz również przesłać opinię o produkcie do społeczności opinii platformy Azure.

Wyłączenie odpowiedzialności za kontakty z osobami trzecimi

Firma Microsoft udostępnia informacje kontaktowe innych firm, które ułatwiają znalezienie dodatkowych informacji na ten temat. Informacje te mogą zostać zmienione bez powiadomienia. Firma Microsoft nie gwarantuje dokładności informacji kontaktowych innych firm.