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

Artykuł
11/19/2024

W bieżących dynamicznych środowiskach w chmurze zapewnienie bezproblemowej łączności z aplikacjami hostowanymi w klastrach usługi Azure Kubernetes Service (AKS) ma kluczowe znaczenie dla utrzymania optymalnej wydajności i środowiska użytkownika. W tym artykule opisano sposób rozwiązywania i rozwiązywania problemów z łącznością spowodowanych przez różne czynniki, w tym problemy po stronie aplikacji, zasady sieciowe, reguły sieciowej grupy zabezpieczeń lub inne.

Uwaga 16.

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

Narzędzie Adres URL klienta (cURL) lub podobne narzędzie wiersza polecenia.
Narzędzie wiersza polecenia apt-get do obsługi pakietów.
Narzędzie wiersza polecenia Netcat (nc) dla połączeń TCP.
Narzędzie Kubernetes kubectl lub podobne narzędzie do nawiązywania połączenia z klastrem. Aby zainstalować narzędzie kubectl przy użyciu interfejsu wiersza polecenia platformy Azure, uruchom polecenie az aks install-cli.

Czynniki do rozważenia

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-odpowiedź?
Które przeskoki mają dodatkowe warstwy zabezpieczeń, takie jak następujące elementy:
- Firewall
- Sieciowa grupa zabezpieczeń
- Zasady sieciowe

Podczas sprawdzania poszczególnych składników 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ą żadnych jednoznacznych wyników, 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 na temat zbierania przechwytywania pakietów dla środowiska usługi AKS, zobacz następujące artykuły w przewodniku zbierania danych:

Przechwyć zrzut TCP z węzła systemu Linux w klastrze usługi AKS.
Przechwyć zrzut TCP z węzła systemu Windows w klastrze usługi AKS.
Przechwyć pakiety TCP z zasobnika w klastrze usługi AKS.

Wiedza na temat pobierania kodów odpowiedzi HTTP i przechwytywania pakietów ułatwia rozwiązywanie problemów z łącznością sieciową.

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

Ogólnie rzecz biorąc, gdy aplikacje są uwidocznione przy użyciu typu usługi Azure Load Balancer, przepływ żądania w celu uzyskania do nich dostępu jest następujący:

Zasobniki węzłów >> usługi AKS o nazwie >> DNS klienta >> usługi AKS >>

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

Zarządzany ruch przychodzący NGINX z włączoną funkcją dodatku routingu aplikacji.
Brama aplikacji jest używana za pośrednictwem kontrolera ruchu przychodzącego usługi Application Gateway (AGIC) zamiast usługi Azure Load Balancer.
Usługi Azure Front Door i API Management mogą być używane na podstawie modułu równoważenia obciążenia.
Proces używa wewnętrznego modułu równoważenia obciążenia.
Połączenie może nie kończyć się zasobnikem i żądanym adresem URL. Może to zależeć od tego, czy zasobnik może łączyć się z inną jednostką, taką jak baza danych, czy jakakolwiek 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 przypomina przepływ przedstawiony na poniższym diagramie.

Rozwiązywanie problemów wewnętrznych

Rozwiązywanie problemów z łącznością może obejmować wiele kontroli, ale podejście wewnętrzne może pomóc znaleźć źródło problemu i zidentyfikować wąskie gardło. W tym podejściu zaczynasz od samego zasobnika, sprawdzając, czy aplikacja odpowiada na adres IP zasobnika. Następnie sprawdź poszczególne składniki pod kątem klienta końcowego.

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

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 przy użyciu polecenia kubectl describe :

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

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

Jeśli zasobnik jest uruchomiony, może być również przydatne sprawdzenie dzienników kontenerów, które znajdują się wewnątrz zasobnika. 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 uzyskać bezpośredni dostęp do adresu IP zasobnika aplikacji i sprawdzić, czy aplikacja odpowiada poprawnie. Uruchom polecenie kubectl run, apt-geti 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 && 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>

W przypadku aplikacji, które nasłuchują innych protokołów, można zainstalować odpowiednie narzędzia wewnątrz zasobnika testowego, takiego jak narzędzie netcat, a następnie sprawdzić łączność z zasobnikem aplikacji, uruchamiając następujące polecenie:

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

Aby uzyskać więcej poleceń do 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żna skoncentrować się głównie na rozwiązywaniu problemów z uwidacznianiem zasobnika.

Czy zasobnik jest udostępniany jako usługa? W takim 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 i Selectors dla 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:

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

# After the packages are installed, test the connectivity to the application pod using netcat/nc command:
nc -z -v <pod-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żna uzyskać dostęp do adresu IP modułu równoważenia obciążenia spoza klastra.

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

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

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

Sprawdź zdarzenia usługi.
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ń do 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 przy użyciu Ingress zasobu, przepływ ruchu przypomina następujący postęp:

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

W tym miejscu możesz również zastosować wewnętrzne podejście do rozwiązywania problemów. Aby uzyskać więcej informacji, możesz również sprawdzić zasób kubernetes ruchu przychodzącego i kontroler ruchu 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 myapp.com hoście.
Ma skonfigurowane dwa Path ciągi.
Trasy do dwóch Services na zapleczu.

Sprawdź, czy usługi zaplecza są uruchomione i odpowiadają 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 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.

Inną możliwością jest to, że składniki na zasobnikach przychodzących, takich jak moduł równoważenia obciążenia lub usługa Application Gateway, nie są prawidłowo przekierowywane do klastra. Jeśli to prawda, możesz sprawdzić konfigurację zaplecza tych zasobów.

Jeśli zostanie wyświetlony komunikat o błędzie, sprawdź sieciową grupę Connection Timed Out 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 (na przykład ruchu przychodzącego 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 na temat platformy Azure.

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

Firma Microsoft udostępnia informacje kontaktowe innych firm, aby uzyskać dodatkowe informacje na temat tego tematu. Informacje te mogą zostać zmienione bez powiadomienia. Firma Microsoft nie gwarantuje dokładności informacji kontaktowych innych firm.

Udostępnij za pośrednictwem