Udostępnij za pośrednictwem

Dostosowywanie serwera CoreDNS w usłudze Azure Kubernetes Service

Usługa Azure Kubernetes Service (AKS) używa projektu CoreDNS do zarządzania i rozpoznawania DNS we wszystkich klastrach w wersji 1.12.x i wyższych. Aby uzyskać więcej informacji na temat dostosowywania coreDNS i platformy Kubernetes, zobacz oficjalną dokumentację nadrzędną.

Usługa AKS jest usługą zarządzaną, więc nie można modyfikować głównej konfiguracji coreDNS (a CoreFile). Zamiast tego należy użyć narzędzia Kubernetes ConfigMap , aby zastąpić ustawienia domyślne. Aby wyświetlić domyślne obiekty ConfigMaps usługi AKS CoreDNS, użyj kubectl get configmaps --namespace=kube-system coredns -o yaml polecenia .

W tym artykule pokazano, jak używać ConfigMaps do podstawowych opcji dostosowywania CoreDNS w AKS. Takie podejście różni się od konfigurowania sieci CoreDNS w innych kontekstach, takich jak CoreFile.

Uwaga

Wcześniej usługa kube-dns była używana do zarządzania i rozpoznawania nazw DNS klastra, ale jest teraz przestarzała. kube-dns oferował różne opcje dostosowywania przez mapę konfiguracji Kubernetes. CoreDNS nie jest wstecznie kompatybilny z kube-dns. Wszystkie użyte wcześniej dostosowania muszą zostać zaktualizowane dla usługi CoreDNS.

Zanim rozpoczniesz

  • W tym artykule przyjmuje się, że posiadasz już istniejący klaster AKS. Jeśli potrzebujesz klastra usługi AKS, możesz go utworzyć przy użyciu interfejsu wiersza polecenia platformy Azure, programu Azure PowerShell lub witryny Azure Portal.
  • Sprawdź używaną wersję serwera CoreDNS. Wartości konfiguracji mogą ulec zmianie między wersjami.
  • Podczas tworzenia konfiguracji, takich jak w poniższych przykładach, nazwy w sekcji danych muszą kończyć się wartością .server lub .override. Ta konwencja nazewnictwa jest definiowana w domyślnej konfiguracji AKS CoreDNS ConfigMap, którą można wyświetlić za pomocą kubectl get configmaps --namespace=kube-system coredns -o yaml polecenia .

Obsługa wtyczek

Obsługiwane są wszystkie wbudowane wtyczki CoreDNS. Nie są obsługiwane żadne dodatki/wtyczki innych firm.

Przepisz DNS

Możesz dostosować nazwę CoreDNS za pomocą usługi AKS, aby wykonać ponowne zapisywanie nazw DNS na bieżąco.

  1. Utwórz plik o nazwie corednsms.yaml i wklej następującą przykładową konfigurację. Pamiętaj, aby zastąpić <domain to be rewritten> na własną w pełni kwalifikowaną nazwę domeny.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  test.server: |
    <domain to be rewritten>.com:53 {
    log
    errors
    rewrite stop {
      name regex (.*)\.<domain to be rewritten>\.com {1}.default.svc.cluster.local
      answer name (.*)\.default\.svc\.cluster\.local {1}.<domain to be rewritten>.com
    }
    forward . /etc/resolv.conf # you can redirect this to a specific DNS server such as 10.0.0.10, but that server must be able to resolve the rewritten domain name
    }

    Ważne

    Jeśli nastąpi przekierowanie do serwera DNS, takiego jak adres IP usługi CoreDNS, serwer DNS musi być w stanie rozpoznać przepisaną nazwę domeny.

  2. Utwórz ConfigMap przy użyciu kubectl apply configmap polecenia i określ nazwę manifestu YAML.

    kubectl apply -f corednsms.yaml

  3. Zweryfikuj, czy dostosowania zostały zastosowane przy użyciu kubectl get configmaps, i określ swoją ConfigMap coredns-custom.

    kubectl get configmaps --namespace=kube-system coredns-custom -o yaml

  4. Aby ponownie załadować narzędzie ConfigMap i włączyć harmonogram Kubernetes w celu ponownego uruchomienia usługi CoreDNS bez przestoju, wykonaj ponowne uruchomienie stopniowe przy użyciu polecenia kubectl rollout restart.

    kubectl -n kube-system rollout restart deployment coredns

Niestandardowy serwer przekazywania dalej

Jeśli musisz określić serwer przekazywania dla ruchu sieciowego, możesz utworzyć ConfigMap, aby dostosować system DNS.

  1. Utwórz plik o nazwie corednsms.yaml i wklej następującą przykładową konfigurację. Pamiętaj, aby zastąpić forward nazwę i adres wartościami własnego środowiska.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  test.server: | # you may select any name here, but it must end with the .server file extension
    <domain to be rewritten>.com:53 {
        forward foo.com 1.1.1.1
    }

  2. Utwórz ConfigMap przy użyciu kubectl apply configmap polecenia i określ nazwę manifestu YAML.

    kubectl apply -f corednsms.yaml

  3. Aby ponownie załadować narzędzie ConfigMap i włączyć harmonogram Kubernetes w celu ponownego uruchomienia usługi CoreDNS bez przestoju, wykonaj ponowne uruchomienie stopniowe przy użyciu polecenia kubectl rollout restart.

    kubectl -n kube-system rollout restart deployment coredns

Używanie domen niestandardowych

Możesz skonfigurować domeny niestandardowe, które można rozwiązać tylko wewnątrz sieci. Na przykład możesz rozwiązać problem z domeną niestandardową puglife.local, która nie jest prawidłową domeną najwyższego poziomu. Bez niestandardowej domeny ConfigMap klaster usługi AKS nie może rozpoznać adresu.

  1. Utwórz nowy plik o nazwie corednsms.yaml i wklej następującą przykładową konfigurację. Pamiętaj, aby zaktualizować domenę niestandardową i adres IP przy użyciu wartości dla własnego środowiska.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  puglife.server: | # you may select any name here, but it must end with the .server file extension
    puglife.local:53 {
        errors
        cache 30
        forward . 192.11.0.1  # this is my test/dev DNS server
    }

  2. Utwórz ConfigMap przy użyciu kubectl apply configmap polecenia i określ nazwę manifestu YAML.

    kubectl apply -f corednsms.yaml

  3. Aby ponownie załadować narzędzie ConfigMap i włączyć harmonogram Kubernetes w celu ponownego uruchomienia usługi CoreDNS bez przestoju, wykonaj ponowne uruchomienie stopniowe przy użyciu polecenia kubectl rollout restart.

    kubectl -n kube-system rollout restart deployment coredns

Domeny stub

CoreDNS można również użyć do konfigurowania domen stub.

  1. Utwórz plik o nazwie corednsms.yaml i wklej następującą przykładową konfigurację. Pamiętaj, aby zaktualizować niestandardowe domeny i adresy IP na wartości odpowiadające Twojemu środowisku.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  test.server: | # you may select any name here, but it must end with the .server file extension
    abc.com:53 {
     errors
     cache 30
     forward . 1.2.3.4
    }
    my.cluster.local:53 {
        errors
        cache 30
        forward . 2.3.4.5
    }

  2. Utwórz ConfigMap przy użyciu kubectl apply configmap polecenia i określ nazwę manifestu YAML.

    kubectl apply -f corednsms.yaml

  3. Aby ponownie załadować narzędzie ConfigMap i włączyć harmonogram Kubernetes w celu ponownego uruchomienia usługi CoreDNS bez przestoju, wykonaj ponowne uruchomienie stopniowe przy użyciu polecenia kubectl rollout restart.

    kubectl -n kube-system rollout restart deployment coredns

Wtyczka hostów

Wszystkie wbudowane wtyczki są obsługiwane, więc wtyczka CoreDNS hostów jest również dostępna do dostosowywania /etc/hosts.

  1. Utwórz plik o nazwie corednsms.yaml i wklej następującą przykładową konfigurację. Upewnij się, że zaktualizujesz adresy IP i nazwy hostów, używając wartości dla własnego środowiska.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom # this is the name of the configmap you can overwrite with your changes
  namespace: kube-system
data:
    test.override: | # you may select any name here, but it must end with the .override file extension
          hosts { 
              10.0.0.1 example1.org
              10.0.0.2 example2.org
              10.0.0.3 example3.org
              fallthrough
          }

  2. Utwórz ConfigMap przy użyciu kubectl apply configmap polecenia i określ nazwę manifestu YAML.

    kubectl apply -f corednsms.yaml

  3. Aby ponownie załadować narzędzie ConfigMap i włączyć harmonogram Kubernetes w celu ponownego uruchomienia usługi CoreDNS bez przestoju, wykonaj ponowne uruchomienie stopniowe przy użyciu polecenia kubectl rollout restart.

    kubectl -n kube-system rollout restart deployment coredns

Nieprawidłowe ukończenie domeny wyszukiwania dla internal.cloudapp.net i reddog.microsoft.com

Usługa Azure DNS konfiguruje domyślną domenę wyszukiwania <vnetId>.<region>.internal.cloudapp.net w sieciach wirtualnych przy użyciu usługi Azure DNS i niefunkcjonalny zastępczy wpis reddog.microsoft.com w sieciach wirtualnych przy użyciu niestandardowych serwerów DNS (więcej szczegółów znajdziesz w dokumentacji rozpoznawania nazw zasobów). Platforma Kubernetes konfiguruje ustawienia dns zasobnika, ndots: 5 aby prawidłowo obsługiwać rozpoznawanie nazw hostów usługi klastra. Te dwie konfiguracje łączą się, aby powodować nieprawidłowe zapytania dotyczące uzupełnienia domeny wyszukiwania, które nigdy nie są pomyślnie wysyłane do nadrzędnych serwerów nazw, podczas przetwarzania przez listę wyszukiwania domen przez system. Te nieprawidłowe zapytania powodują opóźnienia rozpoznawania nazw i mogą powodować dodatkowe obciążenie na nadrzędnych serwerach DNS.

Począwszy od wersji 20241025 AKS, AKS konfiguruje CoreDNS, aby odpowiedzieć kodem NXDOMAIN w następujących dwóch przypadkach, aby zapobiec przesłaniu tych nieprawidłowych zapytań uzupełniania domeny wyszukiwania do nadrzędnego DNS:

  • Każde zapytanie dotyczące domeny głównej lub poddomeny .reddog.microsoft.com
  • Każde zapytanie dotyczące poddomeny, internal.cloudapp.net która ma siedem lub więcej etykiet w nazwie domeny.
    • Ta konfiguracja pozwala nadal skutecznie rozpoznawać maszyny wirtualne na podstawie nazwy hosta. Na przykład usługa CoreDNS wysyła aks12345.myvnetid.myregion.internal.cloudapp.net (6 etykiet) do usługi Azure DNS, ale odrzuca mcr.microsoft.com.myvnetid.myregion.internal.cloudapp.net (8 etykiet)

Ten blok jest implementowany w domyślnym bloku serwera w Corefile'u klastra. W razie potrzeby tę konfigurację odrzucenia można wyłączyć, tworząc niestandardowe bloki serwera dla odpowiedniej domeny z włączoną wtyczką przesyłania dalej:

  1. Utwórz plik o nazwie corednsms.yaml i wklej następującą przykładową konfigurację. Upewnij się, że zaktualizujesz adresy IP i nazwy hostów, używając wartości dla własnego środowiska.

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom # this is the name of the configmap you can overwrite with your changes
  namespace: kube-system
data:
    override-block.server:
       internal.cloudapp.net:53 {
           errors
           cache 30
           forward . /etc/resolv.conf
       }
       reddog.microsoft.com:53 {
           errors
           cache 30
           forward . /etc/resolv.conf
       }

  2. Utwórz ConfigMap przy użyciu kubectl apply configmap polecenia i określ nazwę manifestu YAML.

    kubectl apply -f corednsms.yaml

  3. Aby ponownie załadować narzędzie ConfigMap i włączyć harmonogram Kubernetes w celu ponownego uruchomienia usługi CoreDNS bez przestoju, wykonaj ponowne uruchomienie stopniowe przy użyciu polecenia kubectl rollout restart.

    kubectl -n kube-system rollout restart deployment coredns

Rozwiązywanie problemów

Ogólne kroki rozwiązywania problemów z siecią CoreDNS, takie jak sprawdzanie punktów końcowych lub rozpoznawania, zobacz Debugowanie rozpoznawania nazw DNS.

Skonfiguruj poziome skalowanie zasobników CoreDNS

Nagłe skoki ruchu DNS w klastrach usługi AKS są typowym wystąpieniem ze względu na elastyczność zapewnianą przez usługę AKS dla obciążeń. Te nagłe wzrosty mogą prowadzić do wzrostu zużycia pamięci przez pody CoreDNS. W niektórych przypadkach zwiększone zużycie pamięci może powodować Out of memory problemy. Aby wyprzedać ten problem, klastry usługi AKS automatycznie skalują zasobniki CoreDNS w celu zmniejszenia użycia pamięci na zasobnik. Domyślne ustawienia tej logiki automatycznego skalowania są przechowywane w coredns-autoscaler ConfigMap. Można jednak zauważyć, że domyślne automatyczne skalowanie zasobników CoreDNS nie zawsze jest wystarczająco agresywne, aby zapobiec Out of memory problemom z zasobnikami CoreDNS. W takim przypadku można bezpośrednio zmodyfikować coredns-autoscaler ConfigMap. Należy pamiętać, że po prostu zwiększenie liczby zasobników CoreDNS bez rozwiązywania głównej przyczyny problemu Out of memory może zapewnić tylko tymczasową poprawkę. Jeśli w węzłach, w których są uruchomione zasobniki CoreDNS, za mało pamięci, zwiększenie liczby zasobników CoreDNS nie pomoże. Może być konieczne dokładniejsze zbadanie oraz wdrożenie odpowiednich rozwiązań, takich jak optymalizacja użycia zasobów, dostosowanie żądań zasobów i limitów, lub dodanie większej pamięci do węzłów.

CoreDNS używa poziomego, proporcjonalnego autoskalera klastra do automatycznego skalowania zasobników. coredns-autoscaler ConfigMap można edytować, aby skonfigurować logikę skalowania dla liczby zasobników CoreDNS. Narzędzie coredns-autoscaler ConfigMap obsługuje obecnie dwie różne wartości klucza ConfigMap: linear i ladder odpowiadające dwóm obsługiwanym trybom sterowania. Kontroler linear zwraca liczbę replik w zakresie [min,max] odpowiadającym max( ceil( cores * 1/coresPerReplica ) , ceil( nodes * 1/nodesPerReplica ) ). Kontroler ladder oblicza liczbę replik, konsultując dwie różne funkcje kroków, jedną dla skalowania rdzeni, a drugą dla skalowania węzłów, co daje maksymalną wartość dwóch replik. Aby uzyskać więcej informacji na temat trybów sterowania i formatu ConfigMap, zapoznaj się z dokumentacją nadrzędną.

Ważne

Zaleca się posiadanie co najmniej 2 replik zasobników CoreDNS na klaster. Skonfigurowanie co najmniej 1 repliki zasobnika CoreDNS może spowodować awarie podczas operacji wymagających opróżniania węzłów, takich jak operacje uaktualniania klastra.

Aby pobrać coredns-autoscaler ConfigMap, możesz uruchomić polecenie kubectl get configmap coredns-autoscaler -n kube-system -o yaml, które zwróci następujące wyniki:

apiVersion: v1
data:
  ladder: '{"coresToReplicas":[[1,2],[512,3],[1024,4],[2048,5]],"nodesToReplicas":[[1,2],[8,3],[16,4],[32,5]]}'
kind: ConfigMap
metadata:
  name: coredns-autoscaler
  namespace: kube-system
  resourceVersion: "..."
  creationTimestamp: "..."

Zachowanie pionowego automatycznego skalowania zasobników CoreDNS

CoreDNS to podstawowy dodatek zarządzany przez usługę AKS i domyślnie włączony. Aby zachować dostępność usługi CoreDNS, CoreDNS utrzymuje użycie oryginalnych podanych żądań/limitów zasobów podczas włączania funkcji automatycznego skalowania dodatku, aby zapobiec procesowi ponownego uruchomienia podu CoreDNS, co powoduje niedostępność usługi.

W przypadku dodatku AKS managed CoreDNS domyślne żądania/limity procesora CPU są ustawiane na 100 m /3 rdzeni, a żądania/limity pamięci na 70Mi/500Mi. Na podstawie tych wartości domyślnych współczynnik żądań do limitu dla procesora CPU wynosi około 1:30, a w przypadku pamięci wynosi około 1/7. Jeśli zalecane żądania procesora CPU wynoszą 500 m, VPA dostosowuje limity procesora CPU do 15 m, aby zachować ten współczynnik. Podobnie, jeśli zalecane żądania pamięci to 700Mi, VPA dostosowuje limit pamięci do 5000Mi.

VPA ustawia limity procesora i pamięci dla CoreDNS na duże wartości, na podstawie zalecanych wartości żądań CPU/pamięci VPA oraz współczynnika określonego przez AKS dla stosunku żądanie-do-limitu. Te korekty są korzystne dla obsługi wielu żądań w godzinach szczytu usługi. Wadą jest to, że CoreDNS może zużywać wszystkie dostępne zasoby CPU i pamięci na węźle w czasie szczytowego obciążenia.

Trudno jest ustawić pojedynczą idealną wartość żądań procesora CPU i pamięci/limitów, aby spełnić wymagania zarówno dużego klastra, jak i małego klastra w tym samym czasie. Dzięki włączeniu zoptymalizowanego skalowania dodatków masz elastyczność dostosowywania żądań/limitów procesora CoreDNS i pamięci lub używania usługi VPA do automatycznego skalowania sieci CoreDNS w celu spełnienia określonych wymagań klastra. Poniżej przedstawiono kilka scenariuszy, które należy wziąć pod uwagę:

  • Rozważasz, czy usługa VPA jest odpowiednia dla usługi CoreDNS i chcesz wyświetlić tylko zalecenia dotyczące vpa. Możesz wyłączyć VPA dla CoreDNS, włączając tryb aktualizacji VPA do pozycji Wyłączone, jeśli nie chcesz, aby VPA automatycznie aktualizowało pody. Dostosuj konfigurację zasobu we wdrożeniu , aby ustawić żądań/limitów procesora CPU/pamięci na preferowaną wartość.
  • Rozważasz użycie funkcji VPA, ale chcesz ograniczyć współczynnik żądań do limitu, dzięki czemu vpA nie będzie w tym samym czasie ograniczać limitu procesora CPU i pamięci do dużych wartości. Zasoby można dostosować w procesie wdrażania i zaktualizować wartość żądań CPU oraz pamięci/limitów, aby stosunek żądań do limitów wynosił 1/2 lub 1/3.
  • Jeśli zasady kontenera VPA ustawiają maksymalne dozwolone wartości dla CPU i pamięci, zalecane żądania zasobów nie przekroczą tych limitów. Dostosowanie konfiguracji zasobów umożliwia zwiększenie lub zmniejszenie wartości maxAllowed i kontrolowanie zaleceń VPA.

Aby uzyskać więcej informacji, zobacz Włączanie automatycznego skalowania dodatków w klastrze usługi AKS (wersja zapoznawcza).

Włączanie rejestrowania zapytań DNS

  1. Dodaj następującą konfigurację do ConfigMap coredns-custom:

    apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  log.override: | # you may select any name here, but it must end with the .override file extension
        log

  2. Zastosuj zmiany konfiguracji i wymuś ponowne załadowanie ConfigMap za pomocą następujących poleceń:

    # Apply configuration changes
kubectl apply -f corednsms.yaml

# Force CoreDNS to reload the ConfigMap
kubectl -n kube-system rollout restart deployment coredns

  3. Wyświetl rejestrowanie debugowania CoreDNS przy użyciu polecenia kubectl logs.

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

Rozwiązywanie problemów z nierównomiernością ruchu w zasobnikach CoreDNS

Można zauważyć, że co najmniej jeden zasobnik CoreDNS pokazuje znacznie wyższe użycie procesora CPU i obsługuje więcej zapytań DNS niż inne, mimo że wiele zasobników CoreDNS jest uruchomionych w klastrze usługi AKS. Jest to znany problem w rozwiązaniu Kubernetes i może prowadzić do przeciążenia i awarii jednego z zasobników CoreDNS.

Ta nierówna dystrybucja zapytań DNS jest spowodowana głównie ograniczeniami równoważenia obciążenia UDP na platformie Kubernetes. Platforma używa skrótu z pięcioma krotkami (źródłowy adres IP, port źródłowy, docelowy adres IP, port docelowy, protokół) do dystrybucji ruchu UDP, więc jeśli aplikacja ponownie używa tego samego portu źródłowego dla zapytań DNS, wszystkie zapytania z tego klienta będą kierowane do tego samego zasobnika CoreDNS, co powoduje nieproporcjonalną obsługę ruchu przez jeden zasobnik.

Ponadto niektóre aplikacje używają buforowania połączeń i ponownego użycia połączeń DNS. To zachowanie może dodatkowo skoncentrować zapytania DNS na jednym zasobniku CoreDNS, pogłębiając nierównowagę i zwiększając ryzyko przeciążenia i potencjalnych awarii.

Sprawdzanie dystrybucji ruchu dla poodu CoreDNS

Przed rozpoczęciem wykonaj kroki opisane w powyższej sekcji Włączanie rejestrowania zapytań DNS , aby przechwytywać wymagane dzienniki zapytań DNS z zasobników CoreDNS. Po włączeniu tej opcji uruchom następujące polecenia:

  1. Uruchom następujące polecenie, aby pobrać nazwy wszystkich zasobników CoreDNS w klastrze:

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

  2. Przejrzyj dzienniki dla każdego zasobnika CoreDNS, aby analizować wzorce zapytań DNS:

    kubectl logs --namespace kube-system <coredns-pod1>
kubectl logs --namespace kube-system <coredns-pod2>
# Repeat on all CoreDNS pods

  3. Poszukaj powtarzających się adresów IP i portów klienta, które są wyświetlane tylko w dziennikach pojedynczego zasobnika CoreDNS. Oznacza to, że zapytania DNS z niektórych klientów nie są równomiernie dystrybuowane.

    Przykładowy wpis dziennika:

    [INFO] 10.244.0.247:5556 - 42621 "A IN myservice.default.svc.cluster.local. udp 28" NOERROR qr,aa,rd 106 0.000141s
    • 10.244.0.247: Adres IP klienta tworzący zapytanie DNS
    • 5556: Port źródłowy klienta
    • 42621: Identyfikator zapytania

    Jeśli ten sam adres IP klienta i port są wielokrotnie widoczne w dziennikach tylko jednego zasobnika, potwierdza to dysproporcję ruchu.

Jeśli zauważysz tę dysproporcję, aplikacja może ponownie używać portów źródłowych UDP lub przydzielać ich połączenia. Na podstawie głównej przyczyny można wykonać następujące działania zaradcze:

  • Spowodowane ponownym użyciem portu źródłowego UDP:

    Ponowne użycie portu źródłowego UDP występuje, gdy aplikacja kliencka wysyła wiele zapytań DNS z tego samego portu źródłowego UDP. Jeśli jest to problem, zaktualizuj aplikacje lub klientów DNS w celu losowania portów źródłowych dla każdego zapytania DNS, co ułatwia równomierne dystrybuowanie żądań między zasobnikami.

  • Spowodowane przez buforowanie połączeń:
    Pule połączeń to mechanizmy używane przez aplikacje do ponownego używania istniejących połączeń sieciowych zamiast tworzenia nowego połączenia dla każdego żądania. Chociaż poprawia to wydajność, może to spowodować wysłanie wszystkich zapytań DNS z aplikacji za pośrednictwem tego samego połączenia, a tym samym przekierowanie do tego samego zasobnika CoreDNS. Aby rozwiązać ten problem, dostosuj obsługę połączeń DNS aplikacji, zmniejszając czas życia połączeń (TTL) lub losowe tworzenie połączeń, zapewniając, że zapytania nie będą koncentrować się na jednym zasobniku CoreDNS.

Te zmiany mogą pomóc w osiągnięciu bardziej zrównoważonej dystrybucji zapytań DNS i zmniejszyć ryzyko przeciążenia poszczególnych zasobników.

Następne kroki

W tym artykule przedstawiono przykładowe scenariusze dostosowywania coreDNS. Aby uzyskać informacje na temat projektu CoreDNS, zobacz stronę projektu nadrzędnego CoreDNS.

Aby dowiedzieć się więcej na temat podstawowych pojęć dotyczących sieci, zobacz Pojęcia dotyczące sieci dla aplikacji w usłudze AKS.