Podstawowe rozwiązywanie problemów z połączeniami wychodzącymi z klastra usługi AKS

Artykuł
12/18/2024

W tym artykule omówiono sposób rozwiązywania podstawowych problemów dotyczących połączeń wychodzących z klastra usługi Microsoft Azure Kubernetes Service (AKS) i identyfikowania wadliwych składników.

Wymagania wstępne

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.
Narzędzie wiersza polecenia apt-get do obsługi pakietów.
Narzędzie Adres URL klienta (cURL) lub podobne narzędzie wiersza polecenia.
Narzędzie nslookup wiersza polecenia (dnsutils) do sprawdzania rozpoznawania nazw DNS.

Scenariusze dotyczące ruchu wychodzącego w usłudze Azure Kubernetes Service

Ruch pochodzący z klastra usługi AKS , niezależnie od tego, czy pochodzi z zasobnika, czy węzła roboczego, jest uważany za ruch wychodzący z klastra. Co zrobić, jeśli w przepływie wychodzącym klastra usługi AKS występuje problem? Przed rozwiązaniem problemów najpierw przyjrzyj się scenariuszom przepływu ruchu wychodzącego.

Ruch wychodzący z klastra usługi AKS można sklasyfikować w następujących kategoriach:

Ruch do zasobnika lub usługi w tym samym klastrze (ruch wewnętrzny).
Ruch do urządzenia lub punktu końcowego w tej samej sieci wirtualnej lub innej sieci wirtualnej korzystającej z komunikacji równorzędnej sieci wirtualnych.
Ruch do środowiska lokalnego za pośrednictwem połączenia sieci VPN lub połączenia usługi Azure ExpressRoute.
Ruch poza siecią usługi AKS za pośrednictwem usługi Azure Load Balancer (publiczny ruch wychodzący).
Ruch poza siecią usługi AKS za pośrednictwem usługi Azure Firewall lub serwera proxy (publiczny ruch wychodzący).

Ruch wewnętrzny

Podstawowy przepływ żądań dla ruchu wewnętrznego z klastra usługi AKS przypomina przepływ przedstawiony na poniższym diagramie.

Publiczny ruch wychodzący za pośrednictwem usługi Azure Load Balancer

Jeśli ruch jest przeznaczony dla miejsca docelowego w Internecie, domyślną metodą jest wysłanie ruchu za pośrednictwem usługi Azure Load Balancer.

Publiczny ruch wychodzący za pośrednictwem usługi Azure Firewall lub serwera proxy

W niektórych przypadkach ruch wychodzący musi być filtrowany i może wymagać usługi Azure Firewall.

Użytkownik może chcieć dodać serwer proxy zamiast zapory lub skonfigurować bramę translatora adresów sieciowych dla ruchu wychodzącego. Podstawowy przepływ pozostaje taki sam, jak pokazano na diagramie.

Ważne jest, aby zrozumieć charakter przepływu ruchu wychodzącego dla klastra, aby można było kontynuować rozwiązywanie problemów.

Zagadnienia dotyczące rozwiązywania problemów

Sprawdzanie urządzenia wychodzącego

Podczas rozwiązywania problemów z ruchem wychodzącym w usłudze AKS ważne jest, aby wiedzieć, co to jest urządzenie wychodzące (czyli urządzenie, za pośrednictwem którego ruch przechodzi). W tym miejscu urządzenie wychodzące może być jednym z następujących składników:

Azure Load Balancer
Usługa Azure Firewall lub niestandardowa zapora
Brama translatora adresów sieciowych (NAT)
Serwer proxy

Przepływ może również różnić się w zależności od miejsca docelowego. Na przykład ruch wewnętrzny (czyli w klastrze) nie przechodzi przez urządzenie wychodzące. Ruch wewnętrzny będzie używać tylko sieci klastra. W przypadku publicznego ruchu wychodzącego ustal, czy urządzenie wychodzące przechodzi przez urządzenie, i sprawdź to urządzenie.

Sprawdzanie każdego przeskoku w przepływie ruchu

Po zidentyfikowaniu urządzenia wychodzącego sprawdź następujące czynniki:

Źródło i miejsce docelowe żądania.
Przeskoki między źródłem a miejscem docelowym.
Przepływ żądania-odpowiedź.
Przeskoki, które są ulepszone przez dodatkowe warstwy zabezpieczeń, takie jak następujące warstwy:
- Firewall
- Sieciowa grupa zabezpieczeń
- Zasady sieciowe

Aby zidentyfikować problematyczny przeskok, sprawdź kody odpowiedzi przed i po nim. Aby sprawdzić, czy pakiety docierają prawidłowo do określonego przeskoku, możesz kontynuować przechwytywanie pakietów.

Sprawdzanie kodów odpowiedzi HTTP

Podczas sprawdzania poszczególnych składników pobierz i przeanalizuj kody odpowiedzi HTTP. Te kody są przydatne do identyfikowania charakteru problemu. Kody są szczególnie przydatne w scenariuszach, w których aplikacja odpowiada na żądania HTTP.

Przechwytywanie pakietów z klienta i serwera

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:

Listy kontrolne rozwiązywania problemów

Aby uzyskać podstawowe informacje dotyczące rozwiązywania problemów z ruchem wychodzącym z klastra usługi AKS, wykonaj następujące kroki:

Upewnij się, że rozpoznawanie systemu nazw domen (DNS) dla punktu końcowego działa poprawnie.
Upewnij się, że możesz uzyskać dostęp do punktu końcowego za pośrednictwem adresu IP.
Upewnij się, że możesz uzyskać dostęp do punktu końcowego z innego źródła.
Upewnij się, że punkt końcowy działa.
Sprawdź, czy klaster może uzyskać dostęp do dowolnego innego zewnętrznego punktu końcowego.
Sprawdź, czy zasady sieciowe blokują ruch.
Sprawdź, czy sieciowa grupa zabezpieczeń blokuje ruch.
Sprawdź, czy zapora lub serwer proxy blokuje ruch.
Sprawdź, czy jednostka usługi AKS lub tożsamość zarządzana mają wymagane uprawnienia usługi AKS, aby wprowadzić zmiany sieci w zasobach platformy Azure.

Uwaga 16.

Zakłada, że podczas rozwiązywania problemów podstawowych nie ma siatki usług. Jeśli używasz siatki usług, takiej jak Istio, generuje nietypowe wyniki dla ruchu opartego na protokole TCP.

Sprawdzanie, czy zasobnik i węzeł mogą uzyskać dostęp do punktu końcowego

Z poziomu zasobnika możesz uruchomić wyszukiwanie DNS w punkcie końcowym.

Co zrobić, jeśli nie można uruchomić polecenia kubectl exec , aby nawiązać połączenie z zasobnikiem i zainstalować pakiet NARZĘDZI DNS? W takiej sytuacji można uruchomić zasobnik testowy w tej samej przestrzeni nazw co problematyczny zasobnik, a następnie uruchomić testy.

Uwaga 16.

Jeśli ruch rozpoznawania lub ruchu wychodzącego DNS nie umożliwia zainstalowania niezbędnych pakietów sieciowych, możesz użyć obrazu platformy rishasi/ubuntu-netutil:1.0 Docker. Na tej ilustracji wymagane pakiety są już zainstalowane.

Przykładowa procedura sprawdzania rozpoznawania nazw DNS zasobnika systemu Linux

Uruchom zasobnik testowy w tej samej przestrzeni nazw co problematyczny zasobnik:

kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "linux"}}}'

Po uruchomieniu zasobnika testowego uzyskasz dostęp do zasobnika.

Uruchom następujące apt-get polecenia, aby zainstalować inne pakiety narzędzi:

# Update and install tool packages
apt-get update && apt-get install -y dnsutils curl

Po zainstalowaniu pakietów uruchom polecenie nslookup , aby przetestować rozpoznawanie nazw DNS w punkcie końcowym:

$ nslookup microsoft.com # Microsoft.com is used as an example
Server:         <server>
Address:        <server IP address>#53
...
...
Name:   microsoft.com
Address: 20.53.203.50

Spróbuj bezpośrednio użyć rozpoznawania nazw DNS z nadrzędnego serwera DNS. W tym przykładzie użyto usługi Azure DNS:

$ nslookup microsoft.com 168.63.129.16
Server:         168.63.129.16
Address:        168.63.129.16#53
...
...
Address: 20.81.111.85

Czasami występuje problem z samym punktem końcowym, a nie klastrem DNS. W takich przypadkach należy wziąć pod uwagę następujące kontrole:

Sprawdź, czy żądany port jest otwarty na hoście zdalnym:
```
curl -Ivm5 telnet://microsoft.com:443
```
Sprawdź kod odpowiedzi HTTP:
```
curl -Ivm5 https://microsoft.com
```
Sprawdź, czy możesz nawiązać połączenie z dowolnym innym punktem końcowym:
```
curl -Ivm5 https://kubernetes.io
```

Aby sprawdzić, czy punkt końcowy jest osiągalny z węzła, w którym znajduje się problematyczny zasobnik, a następnie sprawdź ustawienia DNS, wykonaj następujące kroki:

Wprowadź węzeł, w którym znajduje się problematyczny zasobnik za pośrednictwem zasobnika debugowania. Aby uzyskać więcej informacji o tym, jak to zrobić, zobacz Connect to Azure Kubernetes Service (AKS) cluster nodes for maintenance or troubleshooting (Nawiązywanie połączenia z węzłami klastra usługi Azure Kubernetes Service (AKS) na potrzeby konserwacji lub rozwiązywania problemów.

Przetestuj rozpoznawanie nazw DNS w punkcie końcowym:

$ nslookup  microsoft.com
Server:         168.63.129.16
Address:        168.63.129.16#53

Non-authoritative answer:
Name:   microsoft.com
Address: 20.112.52.29
Name:   microsoft.com
Address: 20.81.111.85
Name:   microsoft.com
Address: 20.84.181.62
Name:   microsoft.com
Address: 20.103.85.33
Name:   microsoft.com
Address: 20.53.203.50

Sprawdź plik resolv.conf, aby określić, czy są dodawane oczekiwane serwery nazw:
```
cat /etc/resolv.conf
cat /run/systemd/resolve/resolv.conf
```

Przykładowa procedura sprawdzania rozpoznawania nazw DNS zasobnika systemu Windows

Uruchom zasobnik testowy w puli węzłów systemu Windows:

# For a Windows environment, use the Resolve-DnsName cmdlet.
kubectl run dnsutil-win --image='mcr.microsoft.com/windows/servercore:ltsc2022' --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "windows"}}}' -- powershell "Start-Sleep -s 3600"

Uruchom polecenie kubectl exec, aby nawiązać połączenie z zasobnikiem przy użyciu programu PowerShell:
```
kubectl exec -it dnsutil-win -- powershell
```

Uruchom polecenie cmdlet Resolve-DnsName w programie PowerShell, aby sprawdzić, czy rozpoznawanie nazw DNS działa dla punktu końcowego:

PS C:\> Resolve-DnsName www.microsoft.com 

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
www.microsoft.com              CNAME  20    Answer     www.microsoft.com-c-3.edgekey.net
www.microsoft.com-c-3.edgekey. CNAME  20    Answer     www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net
net
www.microsoft.com-c-3.edgekey. CNAME  20    Answer     e13678.dscb.akamaiedge.net
net.globalredir.akadns.net

Name       : e13678.dscb.akamaiedge.net 
QueryType  : AAAA
TTL        : 20
Section    : Answer
IP6Address : 2600:1408:c400:484::356e   


Name       : e13678.dscb.akamaiedge.net 
QueryType  : AAAA
TTL        : 20
Section    : Answer
IP6Address : 2600:1408:c400:496::356e 


Name       : e13678.dscb.akamaiedge.net
QueryType  : A
TTL        : 12
Section    : Answer
IP4Address : 23.200.197.152

W jednym z nietypowych scenariuszy obejmujących rozpoznawanie nazw DNS zapytania DNS uzyskują poprawną odpowiedź z węzła, ale kończą się niepowodzeniem z zasobnika. W tym scenariuszu można rozważyć sprawdzenie błędów rozpoznawania nazw DNS z poziomu zasobnika, ale nie z węzła roboczego. Jeśli chcesz sprawdzić rozpoznawanie nazw DNS dla punktu końcowego w klastrze, możesz rozważyć sprawdzenie stanu rozpoznawania nazw DNS w klastrze.

Jeśli rozpoznawanie nazw DNS zakończy się pomyślnie, przejdź do testów sieciowych. W przeciwnym razie sprawdź konfigurację DNS klastra.

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.

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.

Udostępnij za pośrednictwem