Rozwiązywanie problemów z błędami rozpoznawania nazw DNS występującymi wewnątrz zasobnika, ale nie w węźle roboczym

Artykuł
11/20/2024

W tym artykule omówiono sposób rozwiązywania problemów z błędami rozpoznawania nazw domen (DNS), które występują z poziomu 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 do wyszukiwania DNS.
Narzędzie wiersza polecenia systemctl .

Tło

W przypadku rozpoznawania nazw 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 jest uruchomiony zasobnik. Plik resolv.conf ( /run/systemd/resolve/resolv.conf) jest aktualizowany na podstawie ustawień DNS sieci wirtualnej, w której jest uruchomiony węzeł roboczy.

Lista kontrolna rozwiązywania problemów

Aby rozwiązać problemy z systemem DNS z poziomu zasobnika, skorzystaj z instrukcji w poniższych sekcjach.

Krok 1. Rozwiązywanie problemów z systemem DNS z zasobnika

Polecenia kubectl umożliwiają rozwiązywanie problemów 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 uż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 uwzględniane. Ponadto uzyskaj 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 16.

Aby wyświetlić więcej informacji o debugowaniu, 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 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
```
Gdy zasobnik testowy jest uruchomiony, 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

host Użyj polecenia , aby określić, czy żądania DNS są kierowane do nadrzędnego serwera:

$ 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 określić, czy rozpoznawanie nazw DNS działa prawidłowo. 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ą podczas jawnego określania nadrzędnego serwera DNS, sprawdź następujące warunki:

Sprawdź niestandardową ConfigMap dla 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 Customize CoreDNS with Azure Kubernetes Service (Dostosowywanie usługi CoreDNS za pomocą usługi Azure Kubernetes Service).
Sprawdź, czy zasady sieciowe blokują ruch na porcie UDP (User Datagram Protocol) 53 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 systemowych). Jeśli tak, sprawdź, czy sieciowa grupa zabezpieczeń jest skojarzona z pulą węzłów systemu blokującą ruch na porcie UDP 53.
Sprawdź, czy sieć wirtualna została niedawno zaktualizowana, aby dodać nowe serwery 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 uruchomione ponownie.
- Usługa sieciowa w węźle została ponownie uruchomiona.
Aby aktualizacja w ustawieniach DNS zaczęły obowiązywać, należy ponownie uruchomić usługę sieciową w węźle i zasobników 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 te kroki:
  1. Utwórz połączenie protokołu Secure Shell (SSH) z węzłami. Aby uzyskać więcej informacji, zobacz Nawiązywanie połączenia przy użyciu protokołu SSH z węzłami klastra usługi Azure Kubernetes Service w celu konserwacji lub rozwiązywania problemów.
  2. Z poziomu węzła uruchom ponownie usługę sieciową:
```
systemctl restart systemd-networkd
```
  3. Sprawdź, czy ustawienia są aktualizowane:
```
cat /run/systemd/resolve/resolv.conf
```
  4. 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ąpi jedna z następujących sekwencji:

Węzeł usługi 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 nie jest osią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 narzędzia rozpoznawania można znaleźć w folderze /run/systemd/resolve/resolve.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 wymienionej. (Używana strategia polega na wypróbowaniu najpierw serwera nazw. Jeśli upłynął limit czasu zapytania, spróbuj utworzyć następny serwer nazw i kontynuować, aż lista serwerów nazw zostanie wyczerpana. Następnie zapytanie nadal próbuje nawiązać połączenie z serwerami nazw do momentu utworzenia maksymalnej liczby ponownych prób).

CoreDNS używa wtyczki przesyłania dalej do wysyłania żądań do nadrzędnych serwerów DNS. Ta wtyczka używa algorytmu losowego do wybrania 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>

We wtyczce forward CoreDNS policy określa zasady, które mają być używane do wyboru serwerów nadrzędnych. Zasady są zdefiniowane w poniższej tabeli.

Nazwa zasady	Opis
`random`	Zasady implementujące losowy wybór serwera nadrzędnego. Jest to zasada domyślna.
`round_robin`	Zasady, które wybierają hosty w oparciu o kolejność okrężną.
`sequential`	Zasady, które wybierają hosty w oparciu o kolejność sekwencyjną.

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 dla żą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 wybrać losowo nadrzędny serwer. 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żyć 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, 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