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

Artykuł
04/12/2024

W tym artykule omówiono sposób rozwiązywania podstawowych problemów z połączeniami wychodzącymi z klastra usługi Microsoft Azure Kubernetes Service (AKS).

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 wiersza polecenia hosta dla wyszukiwań DNS.
Narzędzie wiersza polecenia Netcat (nc) dla połączeń TCP.
Narzędzie wiersza polecenia traceroute do drukowania śledzenia pakietów routingu do hosta sieciowego.

Scenariusze dotyczące ruchu wychodzącego w Azure Kubernetes Service

W każdym scenariuszu sieci należy wziąć pod uwagę następujące czynniki podczas rozwiązywania problemów:

Źródło i miejsce docelowe żądania.
Przeskoki między źródłem a miejscem docelowym.
Przepływ żądania i odpowiedzi.
Przeskoki, które są rozszerzane przez dodatkowe warstwy zabezpieczeń, takie jak następujące warstwy:
- 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. Kody 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:

Jeśli wiesz, jak uzyskać kody odpowiedzi HTTP i przechwycić pakiety, łatwiej jest rozwiązać problem z łącznością sieciową.

Ruch pochodzący z klastra usługi AKS, niezależnie od tego, czy pochodzi z zasobnika, czy węzła roboczego, jest uznawany za ruch wychodzący z klastra. Co zrobić, jeśli wystąpił problem z przepływem wychodzącym dla klastra usługi AKS? Przed rozpoczęciem rozwiązywania problemów najpierw zapoznaj się z naturą przepływu żądania i odpowiedzi.

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 (używającej komunikacji równorzędnej sieci wirtualnej)
Ruch do środowiska lokalnego za pośrednictwem połączenia sieci VPN lub połączenia usługi Azure ExpressRoute
Ruch poza siecią usługi AKS (publiczny ruch wychodzący)

W tym dokumencie opisano podstawowe kroki rozwiązywania problemów wpływających na łączność wychodzącą:

W klastrze
W sieciach wirtualnych
Do świata zewnętrznego (ruch publiczny)

Podczas rozwiązywania problemów z ruchem wychodzącym w usłudze AKS ważne jest również, aby wiedzieć, czym jest urządzenie wychodzące (czyli urządzenie, przez które przechodzi ruch). W tym miejscu urządzenie wychodzące może być jednym z następujących składników:

Azure Load Balancer
Azure Firewall lub zapora niestandardowa
Brama tłumaczenia adresów sieciowych (NAT)
Serwer proxy

Przepływ może się również różnić 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.

Ruch wewnętrzny

Podstawowy przepływ żądań dla ruchu wewnętrznego z klastra usługi AKS będzie podobny do przepływu przedstawionego na poniższym diagramie.

Ruch zewnętrzny za pośrednictwem Azure Load Balancer

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

Ruch zewnętrzny za pośrednictwem Azure Firewall lub serwera proxy

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

Zamiast zapory użytkownik może chcieć dodać serwer proxy. Użytkownik może też chcieć skonfigurować bramę TRANSLATOR 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.

Lista kontrolna rozwiązywania problemów

Aby uzyskać podstawowe informacje na temat 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 nawiązać połączenie z punktem końcowym 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 dotrzeć do 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, czy tożsamość zarządzana ma wymagane uprawnienia usługi AKS do wprowadzania zmian w sieci w zasobach platformy Azure.

Sprawdzanie, czy rozpoznawanie nazw DNS powiodło się dla punktu końcowego

Z poziomu zasobnika można uruchomić odnośnik DNS do punktu końcowego.

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

Uwaga

Jeśli rozpoznawanie nazw DNS lub ruch wychodzący nie zezwala na zainstalowanie niezbędnych pakietów sieciowych, możesz użyć rishasi/ubuntu-netutil:1.0 obrazu platformy Docker. Na tym obrazie wymagane pakiety są już zainstalowane.

Oto przykładowa procedura sprawdzania rozpoznawania nazw DNS:

Uruchom zasobnik testowy w tej samej przestrzeni nazw co problematyczny zasobnik:
```
kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable
```
Po uruchomieniu zasobnika testowego uzyskasz dostęp do zasobnika.

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

apt-get update -y
apt-get install dnsutils -y
apt-get install curl -y
apt-get install netcat -y

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

$ nslookup microsoft.com
Server:         10.0.0.10
Address:        10.0.0.10#53
...
...
Name:   microsoft.com
Address: 20.53.203.50

Wypróbuj rozpoznawanie nazw DNS bezpośrednio 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

Uruchom polecenie , host aby sprawdzić, czy żądania DNS są kierowane do serwera nadrzędnego:

$ host -a microsoft.com
Trying "microsoft.com.default.svc.cluster.local"
Trying "microsoft.com.svc.cluster.local"
Trying "microsoft.com.cluster.local"
Trying "microsoft.com.00idcnmrrm4edot5s2or1onxsc.bx.internal.cloudapp.net"
Trying "microsoft.com"
Trying "microsoft.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62884
;; flags: qr rd ra; QUERY: 1, ANSWER: 27, AUTHORITY: 0, ADDITIONAL: 5

;; QUESTION SECTION:
;microsoft.com.                 IN      ANY

;; ANSWER SECTION:
microsoft.com.          30      IN      NS      ns1-39.azure-dns.com.
...
...
ns4-39.azure-dns.info.  30      IN      A       13.107.206.39

Received 2121 bytes from 10.0.0.10#53 in 232 ms

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:1809' --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

Należy również sprawdzić, czy punkt końcowy jest osiągalny z węzła. Następnie sprawdź ustawienia DNS w węźle. Wykonaj następujące czynności:

Nawiąż połączenie z węzłami klastra Azure Kubernetes Service (AKS) w celu 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 ustalić, czy są dodawane oczekiwane serwery nazw:
```
cat /etc/resolv.conf
cat /run/systemd/resolve/resolv.conf
```

W jednym nietypowym scenariuszu obejmującym rozpoznawanie nazw DNS zapytania DNS otrzymują poprawną odpowiedź z węzła, ale nie z zasobnika. W tym scenariuszu możesz rozważyć sprawdzenie błędów rozpoznawania nazw DNS z wewnątrz zasobnika, ale nie z węzła procesu roboczego.

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

Sprawdź, czy klaster może dotrzeć do punktu końcowego za pośrednictwem sieci

Aby ustalić, czy można uzyskać dostęp do punktu końcowego za pośrednictwem sieci z klastra, wykonaj następujące kroki:

Sprawdź trasę do punktu końcowego, aby ustalić, czy w określonej operacji wystąpił limit czasu:

kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable
apt-get install -y traceroute && apt-get install netcat -y
traceroute -T microsoft.com -m 50 -p 443

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

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.

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.

Share via