Udostępnij za pośrednictwem

Rozwiązywanie problemów z błędami rozpoznawania nazw DNS wewnątrz poda, ale nie z węzła roboczego

W tym artykule omówiono sposób rozwiązywania problemów z błędami rozpoznawania nazw domen (DNS), które występują wewnątrz poda (zasobnika), ale nie z węzła roboczego, podczas próby nawiązania połączenia wychodzącego z klastra usługi Microsoft Azure Kubernetes Service (AKS).

Wymagania wstępne

Kontekst

W przypadku rozwiązywania DNS, pody wysyłają żądania do podó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 roboczego, w którym jest uruchomiony pod. 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 w podzie, postępuj zgodnie z instrukcjami w poniższych sekcjach.

Krok 1: Rozwiązywanie problemów z systemem DNS wewnątrz podu

Możesz używać poleceń kubectl do rozwiązywania problemów z DNS z wnętrza podu, jak pokazano w poniższych krokach:

  1. Sprawdź, czy zasobniki CoreDNS są uruchomione:

    kubectl get pods -l k8s-app=kube-dns -n kube-system

  2. 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

  3. Sprawdź, czy węzły hostujące zasobniki CoreDNS nie są nadmiernie wykorzystywane. 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}'

  4. Sprawdź użycie tych węzłów:

    kubectl top nodes

  5. Sprawdź dzienniki podów CoreDNS.

    kubectl logs -l k8s-app=kube-dns -n kube-system

Uwaga / Notatka

Aby wyświetlić więcej informacji o debugowaniu, włącz szczegółowe dzienniki w usłudze CoreDNS. Aby włączyć szczegółowe 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:

  1. Uruchom zasobnik testowy w tej samej przestrzeni nazw co problematyczny zasobnik.

  2. Uruchom zasobnik testowy w klastrze:

    kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable

    Gdy testowy pod jest uruchomiony, uzyskasz dostęp do poda.

  3. Uruchom następujące polecenia, aby zainstalować wymagane pakiety:

    apt-get update -y
apt-get install dnsutils -y

  4. 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

  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

  6. Sprawdź serwer DNS nadrzędny z poziomu poda, aby określić, czy rozwiązywanie 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:

  1. 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).

  2. Sprawdź, czy zasady sieciowe blokują ruch na porcie UDP (User Datagram Protocol) 53 do zasobników CoreDNS w kube-system przestrzeni nazw.

  3. 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.

  4. 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ęła obowiązywać, należy ponownie uruchomić usługę sieciową na węźle oraz pody CoreDNS. Aby ponownie uruchomić usługę sieciową lub pod-y, 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

  5. 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 resolver 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 resolvera wysyła do nich zapytania w kolejności wymienionej. (Używana strategia polega na wypróbowaniu najpierw serwera nazw. Jeśli upłynie limit czasu zapytania, spróbuj skorzystać z następnego serwera nazw i kontynuuj, aż lista serwerów zostanie wyczerpana. Następnie zapytanie będzie dalej próbować połączyć się z serwerami nazw, aż do osiągnięcia maksymalnej liczby prób ponownych połączeń).

    • 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 poda 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 pody mogą być kierowane do Azure DNS. Dzieje się tak, ponieważ usługa CoreDNS może wybrać losowo nadrzędny serwer. W tym scenariuszu nie można rozwiązać 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 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.