Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
W tym artykule omówiono sposób tworzenia przepływu pracy rozwiązywania problemów w celu rozwiązania problemów z rozwiązaniem problemów z systemem nazw domen (DNS) w usłudze Microsoft Azure Kubernetes Service (AKS).
Wymagania wstępne
Narzędzie wiersza polecenia kubectl Kubernetes
Uwaga: Aby zainstalować narzędzie kubectl przy użyciu interfejsu wiersza polecenia platformy Azure, uruchom polecenie az aks install-cli.
Narzędzie wiersza polecenia dig do wyszukiwania DNS
Narzędzie wiersza polecenia grep do wyszukiwania tekstu
Analizator pakietów sieciowych Wireshark
Lista kontrolna rozwiązywania problemów
Rozwiązywanie problemów z systemem DNS w usłudze AKS jest zwykle złożonym procesem. Możesz łatwo zgubić się w wielu różnych krokach, nie widząc jasnej ścieżki do przodu. Aby ułatwić i bardziej efektywny proces, użyj metody "naukowej", aby zorganizować pracę:
Krok 1. Zbierz fakty.
Krok 2. Opracowanie hipotezy.
Krok 3. Tworzenie i implementowanie planu działania.
Krok 4. Obserwuj wyniki i wyciągaj wnioski.
Krok 5. Powtórz w razie potrzeby.
Rozwiązywanie problemów krok 1. Zbieranie faktów
Aby lepiej zrozumieć kontekst problemu, zbierz fakty dotyczące konkretnego problemu DNS. Korzystając z następujących pytań bazowych jako punktu początkowego, możesz opisać charakter problemu, rozpoznać objawy i zidentyfikować zakres problemu.
| Pytanie | Możliwe odpowiedzi |
|---|---|
| Gdzie zawodzi rozdzielanie DNS? |
|
| Jakiego rodzaju błąd DNS otrzymujesz? |
|
| Jak często występują błędy DNS? |
|
| Których rekordów dotyczy problem? |
|
| Czy istnieją jakieś niestandardowe konfiguracje DNS? |
|
| Jakiego rodzaju problemy z wydajnością wpływają na węzły? |
|
| Jakiego rodzaju problemy z wydajnością wpływają na zasobniki CoreDNS? |
|
| Co powoduje opóźnienie DNS? | Zapytania DNS, które zajmują zbyt dużo czasu, aby otrzymać odpowiedź (więcej niż pięć sekund) |
Aby uzyskać lepsze odpowiedzi na te pytania, wykonaj trzyczęściowy proces.
Część 1. Generowanie testów na różnych poziomach, które odtwarzają problem
Proces rozpoznawania nazw DNS dla zasobników w usłudze AKS obejmuje wiele warstw. Przejrzyj te warstwy, aby wyizolować problem. Typowe są następujące warstwy:
- Zasobniki CoreDNS
- Usługa CoreDNS
- Węzły
- DNS sieci wirtualnej
Aby rozpocząć proces, uruchom testy z kapsuły testowej na każdą warstwę.
Przetestuj rozwiązywanie nazw DNS na poziomie pod CoreDNS
Wdróż zasobnik testowy, aby uruchomić zapytania testowe DNS, uruchamiając następujące polecenie:
cat <<EOF | kubectl apply --filename - apiVersion: v1 kind: Pod metadata: name: aks-test spec: containers: - name: aks-test image: debian:stable command: ["/bin/sh"] args: ["-c", "apt-get update && apt-get install -y dnsutils && while true; do sleep 1000; done"] EOFPobierz adresy IP zasobników CoreDNS, uruchamiając następujące polecenie kubectl get :
kubectl get pod --namespace kube-system --selector k8s-app=kube-dns --output widePołącz się z zasobnikiem testowym przy użyciu polecenia
kubectl exec -it aks-test -- bashi przetestuj rozpoznawanie nazw DNS dla każdego adresu IP zasobnika CoreDNS, uruchamiając następujące polecenia.# Placeholder values FQDN="<fully-qualified-domain-name>" # For example, "db.contoso.com" DNS_SERVER="<coredns-pod-ip-address>" # Test loop for i in $(seq 1 1 10) do echo "host= $(dig +short ${FQDN} @${DNS_SERVER})" sleep 1 done
Aby uzyskać więcej informacji na temat rozwiązywania problemów z rozpoznawaniem nazw DNS na poziomie zasobnika, zobacz Rozwiązywanie problemów z błędami rozpoznawania nazw DNS w zasobniku.
Przetestuj rozpoznawanie nazw DNS na poziomie usługi CoreDNS
Pobierz adres IP usługi CoreDNS, uruchamiając następujące
kubectl getpolecenie:kubectl get service kube-dns --namespace kube-systemNa zasobniku testowym uruchom następujące polecenia względem adresu IP usługi CoreDNS:
# Placeholder values FQDN="<fully-qualified-domain-name>" # For example, "db.contoso.com" DNS_SERVER="<kubedns-service-ip-address>" # Test loop for i in $(seq 1 1 10) do echo "host= $(dig +short ${FQDN} @${DNS_SERVER})" sleep 1 done
Testuj rozwiązywanie nazw DNS na poziomie węzła
Połącz się z węzłem.
Uruchom następujące
greppolecenie, aby pobrać listę nadrzędnych serwerów DNS skonfigurowanych:grep ^nameserver /etc/resolv.confUruchom następujące polecenia tekstowe dla każdego systemu DNS skonfigurowanego w węźle:
# Placeholder values FQDN="<fully-qualified-domain-name>" # For example, "db.contoso.com" DNS_SERVER="<dns-server-in-node-configuration>" # Test loop for i in $(seq 1 1 10) do echo "host= $(dig +short ${FQDN} @${DNS_SERVER})" sleep 1 done
Testowanie rozwiązywania nazw DNS na poziomie sieci wirtualnej DNS
Sprawdź konfigurację serwera DNS sieci wirtualnej i ustal, czy serwery mogą rozpoznać dany rekord.
Część 2. Przegląd kondycji i wydajności zasobników i węzłów CoreDNS
Przegląd kondycji i wydajności zasobników CoreDNS
Możesz użyć poleceń kubectl do sprawdzenia kondycji i wydajności zasobników CoreDNS. W tym celu wykonaj następujące kroki:
Sprawdź, czy zasobniki CoreDNS są uruchomione:
kubectl get pods -l k8s-app=kube-dns -n kube-systemSprawdź, czy zasobniki CoreDNS są nadmiernie przeciążone.
kubectl top pods -n kube-system -l k8s-app=kube-dnsNAME CPU(cores) MEMORY(bytes) coredns-dc97c5f55-424f7 3m 23Mi coredns-dc97c5f55-wbh4q 3m 25MiPobierz węzły hostujące zasobniki CoreDNS:
kubectl get pods -n kube-system -l k8s-app=kube-dns -o jsonpath='{.items[*].spec.nodeName}'Sprawdź, czy węzły nie są nadmiernie wykorzystywane.
kubectl top nodesSprawdź dzienniki podów CoreDNS.
kubectl logs -l k8s-app=kube-dns -n kube-system
Uwaga / Notatka
Aby uzyskać więcej informacji o debugowaniu, włącz szczegółowe logi w CoreDNS. Aby to zrobić, zobacz Rozwiązywanie problemów z dostosowywaniem coreDNS w usłudze AKS.
Przegląd kondycji i wydajności węzłów
Możesz najpierw zauważyć problemy z wydajnością rozpoznawania nazw DNS jako sporadyczne błędy, takie jak przekroczenia limitu czasu. Główne przyczyny tego problemu obejmują wyczerpanie zasobów i ograniczenie I/O na węzłach hostujących zasobniki CoreDNS lub zasobników klienta.
Aby sprawdzić, czy występuje wyczerpanie zasobów lub ograniczanie operacji we/wy, uruchom następujące polecenie kubectl describe wraz z poleceniem grep na węzłach. Ta seria poleceń umożliwia przeglądanie liczby żądań i porównywanie ich z limitem dla każdego zasobu. Jeśli wartość procentowa limitu dla zasobu przekracza 100 procent, ten zasób jest nadmiernie obciążony.
kubectl describe node | grep -A5 '^Name:\|^Allocated resources:' | grep -v '.kubernetes.io\|^Roles:\|Labels:'
Poniższy fragment kodu przedstawia przykładowe dane wyjściowe z tego polecenia:
Name: aks-nodepool1-17046773-vmss00000m
--
Allocated resources:
(Total limits might be more than 100 percent.)
Resource Requests Limits
-------- -------- ------
cpu 250m (13 percent) 40m (2 percent)
memory 420Mi (9 percent) 1762Mi (41 percent)
--
Name: aks-nodepool1-17046773-vmss00000n
--
Allocated resources:
(Total limits might be more than 100 percent.)
Resource Requests Limits
-------- -------- ------
cpu 612m (32 percent) 8532m (449 percent)
memory 804Mi (18 percent) 6044Mi (140 percent)
--
Name: aks-nodepool1-17046773-vmss00000o
--
Allocated resources:
(Total limits might be more than 100 percent.)
Resource Requests Limits
-------- -------- ------
cpu 250m (13 percent) 40m (2 percent)
memory 420Mi (9 percent) 1762Mi (41 percent)
--
Name: aks-ubuntu-16984727-vmss000008
--
Allocated resources:
(Total limits might be more than 100 percent.)
Resource Requests Limits
-------- -------- ------
cpu 250m (13 percent) 40m (2 percent)
memory 420Mi (19 percent) 1762Mi (82 percent)
Aby uzyskać lepszy obraz użycia zasobów na poziomie zasobnika i węzła, możesz również użyć usługi Container Insights i innych narzędzi natywnych dla chmury na platformie Azure. Aby uzyskać więcej informacji, zobacz Monitorowanie klastrów Kubernetes przy użyciu usług platformy Azure i narzędzi natywnych dla chmury.
Część 3. Analizowanie ruchu DNS i przeglądanie wydajności rozpoznawania nazw DNS
Analizowanie ruchu DNS może pomóc zrozumieć, jak klaster usługi AKS obsługuje zapytania DNS. Najlepiej odtworzyć problem na zasobniku testowym, jednocześnie przechwytując ruch z tego zasobnika oraz z każdego z zasobników CoreDNS.
Istnieją dwa główne sposoby analizowania ruchu DNS:
- Korzystanie z narzędzi analizy DNS w czasie rzeczywistym, takich jak Inspektor Gadżet, do analizowania ruchu DNS w czasie rzeczywistym.
- Używanie narzędzi do przechwytywania ruchu, takich jak Retina Capture i Dumpy, w celu zbierania ruchu DNS i analizowania go za pomocą analizatora pakietów sieciowych, takiego jak Wireshark.
Oba podejścia mają na celu zrozumienie kondycji i wydajności odpowiedzi DNS przy użyciu kodów odpowiedzi DNS, czasów odpowiedzi i innych metryk. Wybierz ten, który najlepiej odpowiada Twoim potrzebom.
Analiza ruchu DNS w czasie rzeczywistym
Gadżet inspektora służy do analizowania ruchu DNS w czasie rzeczywistym. Aby zainstalować Inspektor Gadget w klastrze, zapoznaj się z Jak zainstalować Inspektor Gadget w klastrze AKS.
Aby śledzić ruch DNS we wszystkich przestrzeniach nazw, użyj następującego polecenia:
# Get the version of Gadget
GADGET_VERSION=$(kubectl gadget version | grep Server | awk '{print $3}')
# Run the trace_dns gadget
kubectl gadget run trace_dns:$GADGET_VERSION --all-namespaces --fields "src,dst,name,qr,qtype,id,rcode,latency_ns"
Gdzie --fields to rozdzielona przecinkami lista pól do wyświetlenia. Poniższa lista zawiera opis pól używanych w poleceniu :
-
src: źródło żądania z informacjami o platformie Kubernetes (<kind>/<namespace>/<name>:<port>). -
dst: miejsce docelowe żądania z informacjami o platformie Kubernetes (<kind>/<namespace>/<name>:<port>). -
name: nazwa żądania DNS. -
qr: flaga zapytania/odpowiedzi. -
qtype: typ żądania DNS. -
id: identyfikator żądania DNS, który jest używany do dopasowania żądania i odpowiedzi. -
rcode: kod odpowiedzi żądania DNS. -
latency_ns: opóźnienie żądania DNS.
Dane wyjściowe polecenia wyglądają następująco:
SRC DST NAME QR QTYPE ID RCODE LATENCY_NS
p/default/aks-test:33141 p/kube-system/coredns-57d886c994-r2… db.contoso.com. Q A c215 0ns
p/kube-system/coredns-57d886c994-r2… 168.63.129.16:53 db.contoso.com. Q A 323c 0ns
168.63.129.16:53 p/kube-system/coredns-57d886c994-r2… db.contoso.com. R A 323c NameErr… 13.64ms
p/kube-system/coredns-57d886c994-r2… p/default/aks-test:33141 db.contoso.com. R A c215 NameErr… 0ns
p/default/aks-test:56921 p/kube-system/coredns-57d886c994-r2… db.contoso.com. Q A 6574 0ns
p/kube-system/coredns-57d886c994-r2… p/default/aks-test:56921 db.contoso.com. R A 6574 NameErr… 0ns
Za pomocą ID pola można określić, czy zapytanie ma odpowiedź. Pole RCODE zawiera kod odpowiedzi żądania DNS. W LATENCY_NS polu przedstawiono opóźnienie żądania DNS w nanosekundach. Te pola mogą ułatwić zrozumienie kondycji i wydajności odpowiedzi DNS.
Aby uzyskać więcej informacji na temat analizy DNS w czasie rzeczywistym, zobacz Rozwiązywanie problemów z błędami DNS w klastrze usługi AKS w czasie rzeczywistym.
Przechwytywanie ruchu DNS
W tej sekcji pokazano, jak używać Dumpy do zbierania przechwytywanego ruchu DNS z każdego podu CoreDNS oraz podu DNS klienta (w tym przypadku pod aks-test).
Aby zebrać przechwyty z podu testowego klienta, uruchom następujące polecenie:
kubectl dumpy capture pod aks-test -f "-i any port 53" --name dns-cap1-aks-test
Aby zebrać zrzuty dla zasobników CoreDNS, uruchom następujące polecenie Dumpy:
kubectl dumpy capture deploy coredns \
-n kube-system \
-f "-i any port 53" \
--name dns-cap1-coredns
W idealnym przypadku powinieneś uruchamiać przechwytywanie podczas ponownego występowania problemu. To wymaganie oznacza, że różne przechwytywanie może być uruchamiane przez różne czasy, w zależności od częstotliwości odtwarzania problemu. Aby zebrać przechwyty, uruchom następujące polecenia:
mkdir dns-captures
kubectl dumpy export dns-cap1-aks-test ./dns-captures
kubectl dumpy export dns-cap1-coredns ./dns-captures -n kube-system
Aby usunąć zasobniki Dumpy, uruchom następujące polecenie Dumpy:
kubectl dumpy delete dns-cap1-coredns -n kube-system
kubectl dumpy delete dns-cap1-aks-test
Aby scalić wszystkie przechwytywane zasobniki CoreDNS, użyj narzędzia wiersza polecenia mergecap do scalania plików przechwytywania. Narzędzie mergecap jest dołączone do narzędzia analizatora pakietów sieciowych Wireshark. Uruchom następujące polecenie mergecap:
mergecap -w coredns-cap1.pcap dns-cap1-coredns-<coredns-pod-name-1>.pcap dns-cap1-coredns-<coredns-pod-name-2>.pcap [...]
Analiza pakietów DNS dla pojedynczego podu CoreDNS
Po wygenerowaniu i scaleniu plików przechwytywania ruchu można przeprowadzić analizę pakietów DNS plików przechwytywania w narzędziu Wireshark. Wykonaj następujące kroki, aby wyświetlić analizę pakietów dla ruchu pojedynczego poda CoreDNS.
Wybierz Start, wpisz Wireshark, a następnie wybierz Wireshark w wynikach wyszukiwania.
W oknie Wireshark wybierz menu Plik , a następnie wybierz pozycję Otwórz.
Przejdź do folderu zawierającego pliki przechwytywania, wybierz dns-cap1-db-check-<db-check-pod-name>.pcap (plik przechwytywania po stronie klienta dla pojedynczego zasobnika CoreDNS), a następnie wybierz przycisk Otwórz.
Wybierz menu Statystyki , a następnie wybierz pozycję DNS. Zostanie wyświetlone okno dialogowe Wireshark — DNS i wyświetli analizę ruchu DNS. Zawartość okna dialogowego jest wyświetlana w poniższej tabeli.
Temat/element Liczba Średnia Minimalna wartość Maksymalna wartość Częstotliwość (ms) Procent Przepustowość chwilowa Nagły start — Łączna liczba pakietów 1066 0.0017 100% 0.1200 0,000 — kod rcode 1066 0.0017 100.00% 0.1200 0,000 Błąd serwera 17 0.0000 1.59% 0.0100 99.332 Brak takiej nazwy 353 0.0006 33.11% 0.0400 0,000 Brak błędów 696 0.0011 65.29% 0,0800 0,000 — opcodes 1066 0.0017 100.00% 0.1200 0,000 Zapytanie standardowe 1066 0.0017 100.00% 0.1200 0,000 — Zapytanie/odpowiedź 1066 0.0017 100.00% 0.1200 0,000 Odpowiedź 531 0.0009 49.81% 0.0600 0,000 Zapytanie 535 0.0009 50.19% 0.0600 0,000 — Typ zapytania 1066 0.0017 100.00% 0.1200 0,000 AAAA 167 0.0003 15.67% 0.0200 0,000 A 899 0.0015 84.33% 0.1000 0,000 } Klasa 1066 0.0017 100.00% 0.1200 0,000 W 1066 0.0017 100.00% 0,1200 0,000 Statystyki serwisu 0 0.0000 100% - - czas odpowiedzi żądania (msec) 531 184.42 0.067000 6308.503906 0.0009 0.0600 0,000 nr niepożądanych odpowiedzi 0 0.0000 - - nr retransmisji 0 0.0000 - - — Statystyki odpowiedzi 0 0.0000 100% - - nr pytania 1062 1.00 1 1 0.0017 0,1200 0,000 nr organów 1062 0.82 0 1 0.0017 0.1200 0,000 nr odpowiedzi 1062 0,15 0 1 0.0017 0.1200 0,000 nr dodatkowych 1062 0,00 0 0 0.0017 0.1200 0,000 — Statystyki zapytań 0 0.0000 100% - - Qname Len 535 32,99 14 66 0.0009 0.0600 0,000 } Statystyki etykiet 0 0.0000 - - 4. poziom lub więcej 365 0.0006 0.0400 0,000 Trzeci poziom 170 0.0003 0.0200 0,000 Drugi poziom 0 0.0000 - - Pierwszy poziom 0 0.0000 - - Rozmiar ładunku 1066 92.87 32 194 0.0017 100% 0.1200 0,000
Okno dialogowe Analiza DNS w narzędziu Wireshark zawiera łącznie 1066 pakietów. Z tych pakietów 17 (1,59 procent) spowodowało awarię serwera. Ponadto maksymalny czas odpowiedzi wynosił 6308 milisekund (6,3 sekundy) i nie odebrano odpowiedzi dla 0,38 procent zapytań. (Ta suma została obliczona przez odjęcie 49,81 procent pakietów zawierających odpowiedzi z 50,19 procent pakietów zawierających zapytania).
Jeśli wprowadzisz (dns.flags.response == 0) && ! dns.response_in jako filtr wyświetlania w narzędziu Wireshark, ten filtr wyświetla zapytania DNS, które nie otrzymały odpowiedzi, jak pokazano w poniższej tabeli.
| Nie. | Czas | Źródło | Destynacja | Protokół | Długość | Informacje |
|---|---|---|---|---|---|---|
| 225 | 2024-04-01 16:50:40.000520 | 10.0.0.21 | 172.16.0.10 | System Nazw Domenowych (DNS) | 80 | Standardowe zapytanie 0x2c67 AAAA db.contoso.com |
| 426 | 2024-04-01 16:52:47.419907 | 10.0.0.21 | 172.16.0.10 | System Nazw Domenowych (DNS) | 132 | Standardowe zapytanie 0x8038 A db.contoso.com.iosffyoulcwehgo1g3egb3m4oc.jx.internal.cloudapp.net |
| 693 | 2024-04-01 16:55:23.105558 | 10.0.0.21 | 172.16.0.10 | System Nazw Domenowych (DNS) | 132 | Standardowe zapytanie 0xbcb0 A db.contoso.com.iosffyoulcwehgo1g3egb3m4oc.jx.internal.cloudapp.net |
| 768 | 2024-04-01 16:56:06.512464 | 10.0.0.21 | 172.16.0.10 | System Nazw Domenowych (DNS) | 80 | Standardowe zapytanie 0xe330 A db.contoso.com |
Ponadto na pasku stanu Wireshark jest wyświetlany tekst Pakiety: 1066 — Wyświetlane: 4 (0,4%). Te informacje oznaczają, że cztery z 1066 pakietów lub 0,4% to zapytania DNS, które nigdy nie otrzymały odpowiedzi. Ta wartość procentowa jest zasadniczo zgodna z sumą 0,38 procent obliczoną wcześniej.
Jeśli zmienisz filtr wyświetlania na dns.time >= 5, filtr wyświetli pakiety odpowiedzi zapytania, które zajęły pięć sekund lub więcej do odebrania, jak pokazano w zaktualizowanej tabeli.
| Nie. | Czas | Źródło | Destynacja | Protokół | Długość | Informacje | SourcePort | Dodatkowe RRS | czas odpowiedzi DNS |
|---|---|---|---|---|---|---|---|---|---|
| 213 | 2024-04-01 16:50:32.644592 | 172.16.0.10 | 10.0.0.21 | System Nazw Domenowych (DNS) | 132 | Standardowe zapytanie 0x9312 Awaria serwera przy db.contoso.com.iosffyoulcwehgo1g3egb3m4oc.jx.internal.cloudapp.net | 53 | 0 | 6.229941 |
| 320 | 2024-04-01 16:51:55.053896 | 172.16.0.10 | 10.0.0.21 | System Nazw Domenowych (DNS) | 80 | Błąd serwera 0xe5ce podczas zapytania standardowego A db.contoso.com | 53 | 0 | 6.065555 |
| 328 | 2024-04-01 16:51:55.113619 | 172.16.0.10 | 10.0.0.21 | System Nazw Domenowych (DNS) | 132 | Zapytanie standardowe 0x6681 Błąd serwera A db.contoso.com.iosffyoulcwehgo1g3egb3m4oc.jx.internal.cloudapp.net | 53 | 0 | 6.029641 |
| 335 | 2024-04-01 16:52:02.553811 | 172.16.0.10 | 10.0.0.21 | System Nazw Domenowych (DNS) | 80 | Zapytanie standardowe 0x6cf6 Awaria serwera A db.contoso.com | 53 | 0 | 6,500504 |
| 541 | 2024-04-01 16:53:53.423838 | 172.16.0.10 | 10.0.0.21 | System Nazw Domenowych (DNS) | 80 | Awaria serwera 0x07b3 przy zapytaniu AAAA dla db.contoso.com | 53 | 0 | 6.022195 |
| 553 | 2024-04-01 16:54:05.165234 | 172.16.0.10 | 10.0.0.21 | System Nazw Domenowych (DNS) | 132 | Standardowe zapytanie 0x1ea0 Błąd serwera — db.contoso.com.iosffyoulcwehgo1g3egb3m4oc.jx.internal.cloudapp.net | 53 | 0 | 6.007022 |
| 774 | 2024-04-01 16:56:17.553531 | 172.16.0.10 | 10.0.0.21 | System Nazw Domenowych (DNS) | 80 | Standardowe zapytanie 0xa20f Niepowodzenie serwera AAAA db.contoso.com | 53 | 0 | 6.014926 |
| 891 | 2024-04-01 16:56:44.442334 | 172.16.0.10 | 10.0.0.21 | System Nazw Domenowych (DNS) | 132 | Standardowe zapytanie 0xa279 Błąd serwera db.contoso.com.iosffyoulcwehgo1g3egb3m4oc.jx.internal.cloudapp.net | 53 | 0 | 6.044552 |
Po zmianie filtru wyświetlania pasek stanu zostanie zaktualizowany, aby wyświetlić tekst Pakiety: 1066 — Wyświetlane: 8 (0,8%). W związku z tym osiem z 1066 pakietów lub 0,8 procent było odpowiedziAMI DNS, które zajęły pięć sekund lub więcej do odebrania. Jednak w przypadku większości klientów domyślna wartość limitu czasu dns powinna wynosić pięć sekund. To oczekiwanie oznacza, że chociaż zasobniki CoreDNS przetworzyły i dostarczyły osiem odpowiedzi, klient zakończył już sesję, wyświetlając komunikat o błędzie "czas oczekiwania przekroczony". Kolumna Informacje w filtrowanych wynikach pokazuje, że wszystkie osiem pakietów spowodowało awarię serwera.
Analiza pakietów DNS dla wszystkich podów CoreDNS
W narzędziu Wireshark otwórz plik przechwytywania połączonych wcześniej zasobników CoreDNS (coredns-cap1.pcap), a następnie otwórz analizę DNS zgodnie z opisem w poprzedniej sekcji. Zostanie wyświetlone okno dialogowe Wireshark z poniższą tabelą.
| Temat/element | Liczba | Średnia | Minimalna wartość | Maksymalna wartość | Częstotliwość (ms) | Procent | Przepustowość chwilowa | Nagły start |
|---|---|---|---|---|---|---|---|---|
| — Łączna liczba pakietów | 4540233 | 7.3387 | 100% | 84.7800 | 592.950 | |||
| — kod rcode | 4540233 | 7.3387 | 100.00% | 84.7800 | 592.950 | |||
| Błąd serwera | 121781 | 0.1968 | 2.68% | 8.4600 | 599.143 | |||
| Brak takiej nazwy | 574658 | 0.9289 | 12.66% | 10,9800 | 592.950 | |||
| Brak błędów | 3843794 | 6.2130 | 84.66% | 73.2500 | 592.950 | |||
| — opcodes | 4540233 | 7.3387 | 100.00% | 84.7800 | 592.950 | |||
| Zapytanie standardowe | 4540233 | 7.3387 | 100.00% | 84.7800 | 592.950 | |||
| — Zapytanie/odpowiedź | 4540233 | 7.3387 | 100.00% | 84.7800 | 592.950 | |||
| Odpowiedź | 2135116 | 3.4512 | 47.03% | 39.0400 | 581.680 | |||
| Zapytanie | 2405117 | 3.8876 | 52.97% | 49.1400 | 592.950 | |||
| — Typ zapytania | 4540233 | 7.3387 | 100.00% | 84.7800 | 592.950 | |||
| SRV | 3647 | 0.0059 | 0.08% | 0.1800 | 586.638 | |||
| Na PST | 554630 | 0.8965 | 12.22% | 11.5400 | 592.950 | |||
| NS | 15918 | 0.0257 | 0,35% | 0.7200 | 308.225 | |||
| MX | 393016 | 0.6353 | 8.66% | 7.9700 | 426.930 | |||
| AAAA | 384032 | 0.6207 | 8.46% | 8.4700 | 438.155 | |||
| A | 3188990 | 5.1546 | 70.24% | 57,9600 | 592.950 | |||
| } Klasa | 4540233 | 7.3387 | 100.00% | 84.7800 | 592.950 | |||
| W | 4540233 | 7.3387 | 100.00% | 84.7800 | 592.950 | |||
| Statystyki serwisu | 0 | 0.0000 | 100% | - | - | |||
| czas odpowiedzi żądania (msec) | 2109677 | 277.18 | 0.020000 | 12000.532227 | 3.4100 | 38.0100 | 581.680 | |
| nr niepożądanych odpowiedzi | 25402 | 0.0411 | 5.1400 | 587,832 | ||||
| nr retransmisji | 37 | 0.0001 | 0,0300 | 275.702 | ||||
| — Statystyki odpowiedzi | 0 | 0.0000 | 100% | - | - | |||
| nr pytania | 4244830 | 1.00 | 1 | 1 | 6.8612 | 77.0500 | 581.680 | |
| nr organów | 4244830 | 0.39 | 0 | 11 | 6,8612 | 77.0500 | 581.680 | |
| nr odpowiedzi | 4244830 | 1.60 | 0 | 22 | 6,8612 | 77.0500 | 581.680 | |
| nr dodatkowych | 4244830 | 0.29 | 0 | 26 | 6.8612 | 77.0500 | 581.680 | |
| — Statystyki zapytań | 0 | 0.0000 | 100% | - | - | |||
| Qname Len | 2405117 | 20.42 | 2 | 113 | 3.8876 | 49.1400 | 592.950 | |
| } Statystyki etykiet | 0 | 0.0000 | - | - | ||||
| 4. poziom lub więcej | 836034 | 1.3513 | 16.1900 | 592.950 | ||||
| Trzeci poziom | 1159513 | 1.8742 | 23.8900 | 592.950 | ||||
| Drugi poziom | 374182 | 0.6048 | 8.7800 | 592.955 | ||||
| Pierwszy poziom | 35388 | 0.0572 | 0.9200 | 294.492 | ||||
| Rozmiar ładunku | 4540233 | 89.87 | 17 | 1128 | 7.3387 | 100% | 84.7800 | 592.950 |
Okno dialogowe wskazuje, że w sumie było około 4,5 miliona (4540 233) pakietów, z których 2,68 procent spowodowało awarię serwera. Różnica w procentach pakietów zapytań i odpowiedzi pokazuje, że 5,94 procent zapytań (52,97 procent minus 47,03 procent) nie otrzymało odpowiedzi. Maksymalny czas odpowiedzi wynosił 12 sekund (12 000,532227 milisekund).
Jeśli zastosujesz filtr wyświetlania dla odpowiedzi na zapytania, które zajęły co najmniej pięć sekund (dns.time >= 5), większość pakietów w wynikach filtru wskaże, że wystąpił błąd serwera. Jest to prawdopodobnie spowodowane błędem "upłynął limit czasu" klienta.
Poniższa tabela zawiera podsumowanie wyników przechwytywania.
| Kryteria przeglądu dotyczące przechwytywania | Tak | Nie. |
|---|---|---|
| Różnica między zapytaniami DNS a odpowiedziami przekracza dwa procent | ☑ | ☐ |
| Opóźnienie DNS wynosi więcej niż jedną sekundę | ☑ | ☐ |
Rozwiązywanie problemów krok 2. Opracowywanie hipotezy
Ta sekcja kategoryzuje typowe typy problemów, aby ułatwić zawężenie potencjalnych problemów i zidentyfikowanie składników, które mogą wymagać korekt. Takie podejście określa podstawę tworzenia ukierunkowanego planu działania w celu skutecznego łagodzenia i rozwiązywania tych problemów.
Typowe kody odpowiedzi DNS
Poniższa tabela zawiera podsumowanie najpopularniejszych kodów powrotnych DNS.
| Kod powrotny DNS | Komunikat zwrotny DNS | Opis |
|---|---|---|
RCODE:0 |
NOERROR |
Zapytanie DNS zakończyło się pomyślnie. |
RCODE:1 |
FORMERR |
Istnieje błąd formatu zapytania DNS. |
RCODE:2 |
SERVFAIL |
Serwer nie ukończył żądania DNS. |
RCODE:3 |
NXDOMAIN |
Nazwa domeny nie istnieje. |
RCODE:5 |
REFUSED |
Serwer odmówił odpowiedzi na zapytanie. |
RCODE:8 |
NOTAUTH |
Serwer nie jest autorytatywny dla strefy. |
Ogólne typy problemów
W poniższej tabeli wymieniono kategorie typów problemów, które ułatwiają podzielenie objawów problemu.
| Typ problemu | Opis |
|---|---|
| Wydajność | Problemy z wydajnością rozpoznawania nazw DNS mogą powodować sporadyczne błędy, takie jak błędy "przekroczono limit czasu" z perspektywy klienta. Te problemy mogą wystąpić, ponieważ węzły doświadczają wyczerpania zasobów lub ograniczania I/O. Ponadto ograniczenia dotyczące zasobów obliczeniowych w zasobnikach CoreDNS mogą powodować opóźnienie rozwiązywania problemów. Jeśli opóźnienie usługi CoreDNS jest duże lub zwiększa się wraz z upływem czasu, może to wskazywać na problem z obciążeniem. Jeśli wystąpienia CoreDNS są przeciążone, mogą wystąpić problemy z rozpoznawaniem nazw DNS i opóźnieniami lub mogą wystąpić problemy z działaniem obciążeń roboczych oraz usługami wewnętrznymi Kubernetes. |
| Konfiguracja | Problemy z konfiguracją mogą powodować nieprawidłowe rozpoznawanie nazw DNS. W takim przypadku mogą wystąpić błędy NXDOMAIN lub "przekroczono limit czasu". Nieprawidłowe konfiguracje mogą wystąpić w sieci CoreDNS, węzłach, kubernetes, routingu, sieci wirtualnej DNS, prywatnych strefach DNS, zaporach, serwerach proxy itd. |
| Łączność sieciowa | Problemy z łącznością sieciową mogą mieć wpływ na łączność między zasobnikami (ruch wschód-zachód) lub łączność zasobników i węzłów z zasobami zewnętrznymi (ruch północno-południowy). Ten scenariusz może spowodować błędy "przekroczenia limitu czasu". Problemy z łącznością mogą wystąpić, jeśli punkty końcowe usługi CoreDNS nie są aktualne (na przykład z powodu problemów z serwerem kube-proxy, problemów z routingiem, utraty pakietów itd.). Zależność zasobów zewnętrznych w połączeniu z problemami z łącznością (na przykład zależność od niestandardowych serwerów DNS lub zewnętrznych serwerów DNS) może również przyczynić się do problemu. |
Wymagane dane wejściowe
Przed sformułowaniem hipotezy prawdopodobnych przyczyn problemu podsumuj wyniki z poprzednich kroków przepływu pracy rozwiązywania problemów.
Wyniki można zebrać przy użyciu poniższych tabel.
Wyniki szablonu kwestionariusza odniesienia
| Pytanie | Możliwe odpowiedzi |
|---|---|
| Gdzie zawodzi rozdzielanie DNS? | ☐ Strączek ☐ Węzeł ☐ Pod i węzeł |
| Jaki typ błędu DNS otrzymujesz? | ☐ Przekroczono limit czasu ☐ NXDOMAIN ☐ Inny błąd DNS |
| Jak często występują błędy DNS? | ☐ Zawsze ☐ Sporadycznie ☐ W określonym wzorcu |
| Których rekordów dotyczy problem? | ☐ Określona domena ☐ Dowolna domena |
| Czy istnieją jakieś niestandardowe konfiguracje DNS? | ☐ Niestandardowe serwery DNS w sieci wirtualnej ☐ Niestandardowa konfiguracja podstawowej sieciDNS |
Wyniki testów na różnych poziomach
| Wyniki testu rozwiązywania | Działa | Nieudane |
|---|---|---|
| Od rozwiązania "pod" do usługi CoreDNS | ☐ | ☐ |
| Z zasobnika do adresu IP zasobnika CoreDNS | ☐ | ☐ |
| Od podu do wewnętrznego systemu DNS platformy Azure | ☐ | ☐ |
| Od poda do sieci wirtualnej DNS | ☐ | ☐ |
| Z węzła do wewnętrznego systemu DNS platformy Azure | ☐ | ☐ |
| Z węzła do sieci wirtualnej DNS | ☐ | ☐ |
Wyniki kondycji i wydajności węzłów i zasobników CoreDNS
| Wyniki przeglądu wydajności | Zdrowy | Niezdrowy |
|---|---|---|
| Wydajność węzłów | ☐ | ☐ |
| Wydajność zasobników CoreDNS | ☐ | ☐ |
Wyniki analizy ruchu sieciowego i wydajności rozpoznawania nazw DNS
| Kryteria przeglądowe dotyczące przechwytywania | Tak | Nie. |
|---|---|---|
| Różnica między zapytaniami DNS a odpowiedziami przekracza dwa procent | ☐ | ☐ |
| Opóźnienie DNS wynosi więcej niż jedną sekundę | ☐ | ☐ |
Mapuj wymagane dane wejściowe na typy problemów
Aby opracować pierwszą hipotezę, zamapuj wszystkie wyniki z wymaganych danych wejściowych na co najmniej jeden typ problemu. Analizując te wyniki w kontekście typów problemów, można opracować hipotezy dotyczące potencjalnych głównych przyczyn problemów z rozpoznawaniem nazw DNS. Następnie możesz utworzyć plan działania ukierunkowanego badania i rozwiązywania problemów.
Wskaźniki mapowania typu błędu
Jeśli wyniki testu pokazują błędy rozpoznawania nazw DNS w usłudze CoreDNS lub zawierają błędy "przekroczono limit czasu" podczas próby uzyskania dostępu do określonych punktów końcowych, mogą istnieć problemy z konfiguracją lub łącznością.
Wskazania dotyczące niedoboru zasobów obliczeniowych na poziomie podu lub węzła CoreDNS mogą sugerować problemy z wydajnością.
Przechwytywanie DNS, które wykazuje znaczną niezgodność między zapytaniami DNS a odpowiedziami DNS, może wskazywać, że pakiety są tracone. Ten scenariusz sugeruje, że występują problemy z łącznością lub wydajnością.
Obecność niestandardowych konfiguracji na poziomie sieci wirtualnej lub na poziomie platformy Kubernetes może zawierać konfiguracje, które nie działają z usługami AKS i CoreDNS zgodnie z oczekiwaniami.
Rozwiązywanie problemów krok 3. Tworzenie i implementowanie planu działania
Teraz należy mieć wystarczającą ilość informacji, aby utworzyć i wdrożyć plan działania. W poniższych sekcjach znajdują się dodatkowe zalecenia dotyczące formułowania planu dla określonych typów problemów.
Problemy z wydajnością
Jeśli masz do czynienia z problemami z wydajnością rozpoznawania nazw DNS, przejrzyj i zaimplementuj następujące najlepsze rozwiązania i wskazówki.
| Najlepsze rozwiązanie | Wskazówki |
|---|---|
| Skonfiguruj dedykowaną pulę węzłów systemowych spełniającą minimalne wymagania dotyczące rozmiaru. | Zarządzanie pulami węzłów systemowych w usłudze Azure Kubernetes Service (AKS) |
| Aby uniknąć ograniczania operacji we/wy dysku, użyj węzłów, które mają tymczasowe dyski systemu operacyjnego. | Domyślny rozmiar dysku systemu operacyjnego i problem z usługą GitHub 1373 w usłudze Azure AKS |
| Postępuj zgodnie z najlepszymi rozwiązaniami dotyczącymi zarządzania zasobami w przypadku obciążeń w węzłach. | Najlepsze rozwiązania dla deweloperów aplikacji w zakresie zarządzania zasobami w usłudze Azure Kubernetes Service (AKS) |
Jeśli wydajność dns nadal nie jest wystarczająco dobra po wprowadzeniu tych zmian, rozważ użycie lokalnego systemu DNS węzła.
Problemy z konfiguracją
W zależności od składnika należy przejrzeć i zrozumieć implikacje określonej konfiguracji. Aby uzyskać szczegółowe informacje o konfiguracji, zapoznaj się z następującą listą dokumentacji dotyczącej składników:
- Opcje konfiguracji dns rozwiązania Kubernetes
- Niestandardowe opcje konfiguracji usługi AKS CoreDNS
- Brak łącza sieci wirtualnej w prywatnych strefach DNS
Problemy z łącznością sieciową
Usterki, które obejmują interfejs sieci kontenera (CNI) lub inne składniki platformy Kubernetes lub systemu operacyjnego, zwykle wymagają interwencji pomocy technicznej usługi AKS lub grupy produktów AKS.
Problemy z infrastrukturą, takie jak awarie sprzętu lub problemy z funkcją hypervisor, mogą wymagać współpracy ze strony zespołów pomocy technicznej infrastruktury. Alternatywnie te problemy mogą mieć funkcje samonaprawiania.
Rozwiązywanie problemów krok 4. Obserwowanie wyników i wyciąganie wniosków
Obserwuj wyniki wdrożenia planu działania. W tym momencie plan działania powinien być w stanie rozwiązać lub złagodzić problem.
Rozwiązywanie problemów— krok 5. Powtórz w razie potrzeby
Jeśli te kroki rozwiązywania problemów nie rozwiążą problemu, powtórz kroki rozwiązywania problemów zgodnie z potrzebami.
Zastrzeżenie dotyczące informacji pochodzących od stron trzecich
Produkty innych firm omówione w tym artykule są produkowane przez firmy, które są niezależne od firmy Microsoft. Firma Microsoft nie udziela żadnych gwarancji, dorozumianych ani żadnego innego rodzaju, w odniesieniu do wydajności lub niezawodności tych produktów.
Wyłączenie odpowiedzialności za kontakty z osobami trzecimi
Firma Microsoft udostępnia informacje dotyczące sposobu kontaktowania się z innymi firmami, aby ułatwić uzyskanie dodatkowych informacji w tym temacie. 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.