Rozwiązywanie problemów z błędami rozpoznawania nazw DNS z wewnątrz zasobnika, ale nie z węzła procesu roboczego
W tym artykule omówiono sposób rozwiązywania problemów z błędami rozpoznawania systemu nazw domen (DNS), które występują z wewnątrz zasobnika, ale nie z węzła procesu roboczego, podczas próby nawiązania połączenia wychodzącego 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 wiersza polecenia hosta dla wyszukiwań DNS.
Narzędzie wiersza polecenia systemctl .
Tło
W przypadku rozpoznawania nazw DNS zasobniki wysyłają żądania do zasobników CoreDNS w kube-system
przestrzeni nazw.
Jeśli zapytanie DNS dotyczy składnika wewnętrznego, takiego jak nazwa usługi, zasobnik CoreDNS odpowiada samodzielnie. Jeśli jednak żądanie dotyczy domeny zewnętrznej, zasobnik CoreDNS wysyła żądanie do nadrzędnego serwera DNS.
Nadrzędne serwery DNS są uzyskiwane na podstawie pliku resolv.conf węzła procesu roboczego, w którym działa zasobnik. Plik resolv.conf (/run/systemd/resolve/resolv.conf) jest aktualizowany na podstawie ustawień DNS sieci wirtualnej, w której działa węzeł roboczy.
Lista kontrolna rozwiązywania problemów
Aby rozwiązać problemy z systemem DNS z zasobnika, skorzystaj z instrukcji w poniższych sekcjach.
Krok 1. Rozwiązywanie problemów z systemem DNS z zasobnika
Za pomocą poleceń kubectl można rozwiązywać problemy z systemem DNS z zasobnika, jak pokazano w poniższych krokach:
Sprawdź, czy zasobniki CoreDNS są uruchomione:
kubectl get pods -l k8s-app=kube-dns -n kube-system
Sprawdź, czy zasobniki CoreDNS są nadmiernie nieużywane:
$ kubectl top pods -n kube-system -l k8s-app=kube-dns NAME CPU(cores) MEMORY(bytes) coredns-dc97c5f55-424f7 3m 23Mi coredns-dc97c5f55-wbh4q 3m 25Mi
Sprawdź, czy węzły hostujące zasobniki CoreDNS nie są nadmiernie nieużywane. Ponadto pobierz węzły hostujące zasobniki CoreDNS:
kubectl get pods -n kube-system -l k8s-app=kube-dns -o jsonpath='{.items[*].spec.nodeName}'
Sprawdź użycie tych węzłów:
kubectl top nodes
Sprawdź dzienniki zasobników CoreDNS:
kubectl logs -l k8s-app=kube-dns -n kube-system
Uwaga
Aby wyświetlić więcej informacji debugowania, włącz pełne dzienniki w usłudze CoreDNS. Aby włączyć pełne rejestrowanie w usłudze CoreDNS, zobacz Rozwiązywanie problemów z dostosowaniami usługi CoreDNS w usłudze AKS.
Krok 2. Tworzenie zasobnika testowego do uruchamiania poleceń
Jeśli rozpoznawanie nazw DNS kończy się niepowodzeniem, wykonaj następujące kroki:
Uruchom zasobnik testowy w tej samej przestrzeni nazw co problematyczny zasobnik.
Uruchom zasobnik testowy w klastrze:
kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable
Po uruchomieniu zasobnika testowego uzyskasz dostęp do zasobnika.
Uruchom następujące polecenia, aby zainstalować wymagane pakiety:
apt-get update -y apt-get install dnsutils -y
Sprawdź, czy plik resolv.conf ma poprawne wpisy:
cat /etc/resolv.conf search default.svc.cluster.local svc.cluster.local cluster.local 00idcnmrrm4edot5s2or1onxsc.bx.internal.cloudapp.net nameserver 10.0.0.10 options ndots:5
Użyj polecenia ,
host
aby określić, 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
Sprawdź nadrzędny serwer DNS z zasobnika, aby ustalić, czy rozpoznawanie nazw DNS działa poprawnie. Na przykład w przypadku usługi Azure DNS uruchom następujące polecenie nslookup :
$ nslookup microsoft.com 168.63.129.16 Server: 168.63.129.16 Address: 168.63.129.16#53 ... ... Address: 20.81.111.85
Krok 3. Sprawdzanie, czy żądania DNS działają, gdy nadrzędny serwer DNS jest jawnie określony
Jeśli żądania DNS z zasobników działają po jawnej określeniu nadrzędnego serwera DNS, sprawdź następujące warunki:
Sprawdź niestandardową mapę konfiguracji dla usługi CoreDNS:
kubectl describe cm coredns-custom -n kube-system
Jeśli istnieje niestandardowa mapa konfiguracji, sprawdź, czy konfiguracja jest poprawna. Aby uzyskać więcej informacji, zobacz Dostosowywanie usługi CoreDNS przy użyciu Azure Kubernetes Service.
Sprawdź, czy zasady sieciowe blokują ruch na porcie 53 protokołu UDP (User Datagram Protocol) do zasobników CoreDNS w
kube-system
przestrzeni nazw.Sprawdź, czy zasobniki CoreDNS znajdują się w innej puli węzłów (pula węzłów systemu). Jeśli tak jest, sprawdź, czy sieciowa grupa zabezpieczeń jest skojarzona z pulą węzłów systemowych, która blokuje ruch na porcie UDP 53.
Sprawdź, czy sieć wirtualna została ostatnio zaktualizowana w celu dodania nowych serwerów DNS.
Jeśli wystąpiła aktualizacja sieci wirtualnej, sprawdź, czy wystąpiło również jedno z następujących zdarzeń:
- Węzły zostały ponownie uruchomione.
- Usługa sieciowa w węźle została ponownie uruchomiona.
Aby aktualizacja ustawień DNS weszła w życie, należy ponownie uruchomić usługę sieciową w węźle i zasobnikach CoreDNS. Aby ponownie uruchomić usługę sieciową lub zasobniki, użyj jednej z następujących metod:
Uruchom ponownie węzeł.
Skalowanie nowych węzłów. (Nowe węzły będą miały zaktualizowaną konfigurację).
Uruchom ponownie usługę sieciową w węzłach, a następnie uruchom ponownie zasobniki CoreDNS. Wykonaj następujące czynności:
Nawiązywanie połączenia secure shell (SSH) z węzłami. Aby uzyskać więcej informacji, zobacz Nawiązywanie połączenia z węzłami klastra Azure Kubernetes Service (AKS) w celu konserwacji lub rozwiązywania problemów.
W węźle uruchom ponownie usługę sieciową:
systemctl restart systemd-networkd
Sprawdź, czy ustawienia zostały zaktualizowane:
cat /run/systemd/resolve/resolv.conf
Po ponownym uruchomieniu usługi sieciowej użyj narzędzia kubectl, aby ponownie uruchomić zasobniki CoreDNS:
kubectl delete pods -l k8s-app=kube-dns -n kube-system
Sprawdź, czy w ustawieniach DNS sieci wirtualnej określono więcej niż jeden serwer DNS.
Jeśli w sieci wirtualnej usługi AKS określono wiele serwerów DNS, występuje jedna z następujących sekwencji:
Węzeł AKS wysyła żądanie do nadrzędnego serwera DNS w ramach serii. W tej sekwencji żądanie jest wysyłane do pierwszego serwera DNS skonfigurowanego w sieci wirtualnej (jeśli serwery DNS są osiągalne i uruchomione). Jeśli pierwszy serwer DNS jest nieosiągalny i nie odpowiada, żądanie jest wysyłane do następnego serwera DNS.
Węzły usługi AKS używają polecenia rozpoznawania nazw do wysyłania żądań do serwerów DNS. Plik konfiguracji tego programu rozpoznawania można znaleźć na stronie /run/systemd/resolve/resolv.conf w węzłach usługi AKS.
Czy istnieje wiele serwerów? W takim przypadku biblioteka rozpoznawania nazw wysyła do nich zapytania w kolejności, w jakiej się znajduje. (Używana strategia polega najpierw na wypróbowaniu serwera nazw. Jeśli zapytanie przekroczy limit czasu, spróbuj użyć następnego serwera nazw i kontynuuj do momentu wyczerpania listy serwerów nazw. Następnie zapytanie będzie nadal próbować nawiązać połączenie z serwerami nazw, dopóki nie zostanie wykonana maksymalna liczba ponownych prób).
Usługa CoreDNS używa wtyczki przesyłania dalej do wysyłania żądań do nadrzędnych serwerów DNS. Ta wtyczka używa losowego algorytmu do wybierania nadrzędnego serwera DNS. W tej sekwencji żądanie może przejść do dowolnego z serwerów DNS wymienionych w sieci wirtualnej. Na przykład mogą zostać wyświetlone następujące dane wyjściowe:
$ kubectl describe cm coredns -n kube-system Name: coredns Namespace: kube-system Labels: addonmanager.kubernetes.io/mode=Reconcile k8s-app=kube-dns kubernetes.io/cluster-service=true Annotations: <none> Data ==== Corefile: ---- .:53 { errors ready health kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa } prometheus :9153 forward . /etc/resolv.conf # Here! cache 30 loop reload loadbalance import custom/*.override } import custom/*.server BinaryData ==== Events: <none>
W wtyczce CoreDNS
forward
określa zasady używanepolicy
do wybierania serwerów nadrzędnych. Zasady są zdefiniowane w poniższej tabeli.Nazwa zasad Opis random
Zasady implementujące losowy wybór nadrzędny. Te zasady są domyślne. round_robin
Zasady, które wybierają hosty na podstawie kolejności działania okrężnego. sequential
Zasady, które wybierają hosty na podstawie kolejności sekwencyjnej. Jeśli sieć wirtualna usługi AKS zawiera wiele serwerów DNS, żądania z węzła USŁUGI AKS mogą przejść do pierwszego serwera DNS. Jednak żądania z zasobnika mogą przejść do drugiego serwera DNS.
Przyczyna: Wiele miejsc docelowych żądań DNS
Jeśli określono dwa niestandardowe serwery DNS, a trzeci serwer DNS jest określony jako Azure DNS (168.63.129.16), węzeł wyśle żądania do pierwszego niestandardowego serwera DNS, jeśli jest uruchomiony i osiągalny. W tej konfiguracji węzeł może rozpoznać domenę niestandardową. Jednak niektóre żądania DNS z zasobnika mogą być kierowane do usługi Azure DNS. Dzieje się tak, ponieważ usługa CoreDNS może losowo wybrać serwer nadrzędny. W tym scenariuszu nie można rozpoznać domeny niestandardowej. W związku z tym żądanie DNS kończy się niepowodzeniem.
Rozwiązanie: Usuwanie usługi Azure DNS z ustawień sieci wirtualnej
Zalecamy, aby nie łączyć usługi Azure DNS z niestandardowymi serwerami DNS w ustawieniach sieci wirtualnej. Jeśli chcesz używać niestandardowych serwerów DNS, dodaj tylko niestandardowe serwery DNS w ustawieniach sieci wirtualnej. Następnie skonfiguruj usługę Azure DNS w ustawieniach usługi przesyłania dalej niestandardowych serwerów DNS.
Aby uzyskać więcej informacji, zobacz Rozpoznawanie nazw, które używa własnego serwera DNS.
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.
Opinia
https://aka.ms/ContentUserFeedback.
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź:Prześlij i wyświetl opinię dla