Sdílet prostřednictvím

Přizpůsobení CoreDNS pomocí služby Azure Kubernetes Service

Azure Kubernetes Service (AKS) používá projekt CoreDNS pro správu a řešení DNS clusteru pro clustery verze 1.12.x a vyšší. Další informace o přizpůsobení CoreDNS a Kubernetes najdete v oficiální upstreamové dokumentaci.

AKS je spravovaná služba, takže nemůžete upravit hlavní konfiguraci coreDNS ( CoreFile). Místo toho použijete objekt ConfigMap Kubernetes k přepsání výchozího nastavení. Pokud chcete zobrazit výchozí ConfigMapy AKS CoreDNS, použijte tento příkaz kubectl get configmaps --namespace=kube-system coredns -o yaml.

V tomto článku se dozvíte, jak používat ConfigMaps k základnímu přizpůsobení CoreDNS v AKS. Tento přístup se liší od konfigurace CoreDNS v jiných kontextech, jako je CoreFile.

Poznámka:

Dříve se kube-dns používal ke správě a rozlišení DNS clusteru, ale nyní je zastaralý. kube-dns nabízí různé možnosti přizpůsobení prostřednictvím mapy konfigurace Kubernetes. CoreDNS není zpětně kompatibilní s kube-dns. Všechna vlastní nastavení, která jste použili dříve, se musí aktualizovat pro CoreDNS.

Než začnete

  • Tento článek předpokládá, že máte existující cluster AKS. Pokud potřebujete cluster AKS, můžete ho vytvořit pomocí Azure CLI, Azure PowerShellu nebo webu Azure Portal.
  • Ověřte verzi CoreDNS, kterou používáte. Hodnoty konfigurace se můžou mezi verzemi měnit.
  • Při vytváření konfigurací, jako jsou příklady níže, musí vaše názvy v datové části končit na .server nebo .override. Tato konvence vytváření názvů je definována ve výchozím objektu ConfigMap AKS CoreDNS, který můžete zobrazit pomocí kubectl get configmaps --namespace=kube-system coredns -o yaml příkazu.

Podpora modulů plug-in

Podporují se všechny integrované moduly plug-in CoreDNS. Nepodporují se žádné doplňky nebo moduly plug-in třetích stran.

Přepsání DNS

CoreDNS můžete přizpůsobit pomocí AKS pro dynamické přepisování DNS jmen.

  1. Vytvořte soubor s názvem corednsms.yaml a vložte následující ukázkovou konfiguraci. Nezapomeňte nahradit <domain to be rewritten> vlastním plně kvalifikovaným názvem domény.

    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
    }

    Důležité

    Pokud přesměrujete na server DNS, například IP adresu služby CoreDNS, musí být tento server DNS schopný přeložit přepsaný název domény.

  2. Pomocí příkazu vytvořte objekt ConfigMap kubectl apply configmap a zadejte název manifestu YAML.

    kubectl apply -f corednsms.yaml

  3. Pomocí kubectl get configmaps ověřte, že byla aplikována vlastní přizpůsobení a zadejte svůj coredns-custom ConfigMap.

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

  4. Pokud chcete znovu načíst ConfigMap a umožnit plánovači Kubernetes restartovat CoreDNS bez výpadků, proveďte postupný restart pomocí kubectl rollout restart.

    kubectl -n kube-system rollout restart deployment coredns

Vlastní přesměrovávající server

Pokud potřebujete zadat předávaný server pro síťový provoz, můžete vytvořit objekt ConfigMap pro přizpůsobení DNS.

  1. Vytvořte soubor s názvem corednsms.yaml a vložte následující ukázkovou konfiguraci. Nezapomeňte nahradit forward název a adresu hodnotami pro vaše vlastní prostředí.

    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. Pomocí příkazu vytvořte objekt ConfigMap kubectl apply configmap a zadejte název manifestu YAML.

    kubectl apply -f corednsms.yaml

  3. Pokud chcete znovu načíst ConfigMap a umožnit plánovači Kubernetes restartovat CoreDNS bez výpadků, proveďte postupný restart pomocí kubectl rollout restart.

    kubectl -n kube-system rollout restart deployment coredns

Použití vlastních domén

Možná budete chtít nakonfigurovat vlastní domény, které se dají vyřešit jenom interně. Například můžete chtít vyřešit vlastní doménu puglife.local, což není platná doména nejvyšší úrovně. Bez objektu ConfigMap vlastní domény nemůže AKS cluster tuto adresu vyřešit.

  1. Vytvořte nový soubor s názvem corednsms.yaml a vložte následující ukázkovou konfiguraci. Nezapomeňte aktualizovat vlastní doménu a IP adresu hodnotami pro vaše vlastní prostředí.

    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. Pomocí příkazu vytvořte objekt ConfigMap kubectl apply configmap a zadejte název manifestu YAML.

    kubectl apply -f corednsms.yaml

  3. Pokud chcete znovu načíst ConfigMap a umožnit plánovači Kubernetes restartovat CoreDNS bez výpadků, proveďte postupný restart pomocí kubectl rollout restart.

    kubectl -n kube-system rollout restart deployment coredns

Domény stub

CoreDNS lze také použít ke konfiguraci domén stub.

  1. Vytvořte soubor s názvem corednsms.yaml a vložte následující ukázkovou konfiguraci. Nezapomeňte aktualizovat vlastní domény a IP adresy hodnotami pro vaše vlastní prostředí.

    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. Pomocí příkazu vytvořte objekt ConfigMap kubectl apply configmap a zadejte název manifestu YAML.

    kubectl apply -f corednsms.yaml

  3. Pokud chcete znovu načíst ConfigMap a umožnit plánovači Kubernetes restartovat CoreDNS bez výpadků, proveďte postupný restart pomocí kubectl rollout restart.

    kubectl -n kube-system rollout restart deployment coredns

Hostitelský plugin

Všechny integrované pluginy jsou podporovány, takže plugin CoreDNS hostitelů je k dispozici i pro úpravu /etc/hosts.

  1. Vytvořte soubor s názvem corednsms.yaml a vložte následující ukázkovou konfiguraci. Nezapomeňte aktualizovat IP adresy a názvy hostitelů hodnotami pro vaše vlastní prostředí.

    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. Pomocí příkazu vytvořte objekt ConfigMap kubectl apply configmap a zadejte název manifestu YAML.

    kubectl apply -f corednsms.yaml

  3. Pokud chcete znovu načíst ConfigMap a umožnit plánovači Kubernetes restartovat CoreDNS bez výpadků, proveďte postupný restart pomocí kubectl rollout restart.

    kubectl -n kube-system rollout restart deployment coredns

Neplatné doplnění vyhledávací domény pro internal.cloudapp.net a reddog.microsoft.com

Azure DNS nakonfiguruje výchozí doménu vyhledávání <vnetId>.<region>.internal.cloudapp.net ve virtuálních sítích pomocí Azure DNS a nefunkční zástupce reddog.microsoft.com ve virtuálních sítích používajících vlastní DNS servery (další podrobnosti najdete v dokumentaci k rozlišení názvů prostředků). Kubernetes nakonfiguruje nastavení DNS podů s ndots: 5 tak, aby správně podporovalo překlad názvů hostitelů služby clusteru. Tyto dvě konfigurace se kombinují tak, že výsledkem jsou neplatné dotazy na dokončení domén, které nikdy nejsou úspěšně odeslány na nadřazené názvové servery, zatímco systém prochází seznamem domén vyhledávání. Tyto neplatné dotazy způsobují zpoždění řešení názvů a můžou zvýšit zatížení nadřazených serverů DNS.

Od verze AKS v20241025 nakonfiguruje AKS CoreDNS tak, aby reagoval s NXDOMAIN v následujících dvou případech, aby zabránilo přeposílání těchto neplatných dotazů na dokončování domény vyhledávání do upstreamového DNS:

  • Jakýkoli dotaz na kořenovou doménu nebo subdoménu .reddog.microsoft.com
  • Jakýkoli dotaz na subdoménu internal.cloudapp.net , která má v názvu domény sedm nebo více popisků.
    • Tato konfigurace umožňuje, aby rozpoznávání virtuálních počítačů podle názvu hostitele bylo i nadále úspěšné. CoreDNS například odesílá aks12345.myvnetid.myregion.internal.cloudapp.net (6 popisků) do Azure DNS, ale odmítne mcr.microsoft.com.myvnetid.myregion.internal.cloudapp.net (8 popisků).

Tento blok se implementuje ve výchozím bloku serveru v souboru Corefile pro cluster. V případě potřeby je možné tuto konfiguraci zamítnutí zakázat vytvořením vlastních bloků serveru pro příslušnou doménu s povoleným modulem plug-in pro předávání:

  1. Vytvořte soubor s názvem corednsms.yaml a vložte následující ukázkovou konfiguraci. Nezapomeňte aktualizovat IP adresy a názvy hostitelů hodnotami pro vaše vlastní prostředí.

    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. Pomocí příkazu vytvořte objekt ConfigMap kubectl apply configmap a zadejte název manifestu YAML.

    kubectl apply -f corednsms.yaml

  3. Pokud chcete znovu načíst ConfigMap a umožnit plánovači Kubernetes restartovat CoreDNS bez výpadků, proveďte postupný restart pomocí kubectl rollout restart.

    kubectl -n kube-system rollout restart deployment coredns

Řešení problémů

Obecné kroky řešení potíží se službou CoreDNS, jako je kontrola koncových bodů nebo překladu, najdete v tématu Ladění překladu DNS.

Konfigurace horizontálního škálování podů CoreDNS

Náhlé špičky provozu DNS v clusterech AKS jsou běžným výskytem kvůli elasticitě, kterou AKS poskytuje pro úlohy. Tyto špičky můžou vést ke zvýšení spotřeby paměti pody CoreDNS. V některých případech může tato zvýšená spotřeba paměti způsobit Out of memory problémy. Aby se tento problém zkrátil, clustery AKS automaticky škálují pody CoreDNS, aby se snížilo využití paměti na pod. Výchozí nastavení této logiky automatického škálování jsou uložena v objektu coredns-autoscaler ConfigMap. Můžete ale pozorovat, že výchozí automatické škálování podů CoreDNS není vždy dostatečně agresivní, aby se zabránilo Out of memory problémům s pody CoreDNS. V tomto případě můžete přímo upravit coredns-autoscaler objekt ConfigMap. Upozorňujeme, že jednoduše zvýšení počtu podů CoreDNS bez vyřešení původní příčiny Out of memory problému může poskytnout pouze dočasnou opravu. Pokud v uzlech, na kterých běží pody CoreDNS, není k dispozici dostatek paměti, zvýšení počtu podů CoreDNS nepomůže. Možná budete muset prozkoumat další a implementovat vhodná řešení, jako je optimalizace využití prostředků, úprava požadavků na prostředky a omezení nebo přidání další paměti do uzlů.

CoreDNS používá pro automatické škálování podů horizontální proporcionální autoscaler clusteru. Konfigurační coredns-autoscaler mapu je možné upravit tak, aby konfigurovala logiku škálování pro počet podů CoreDNS. Objekt coredns-autoscaler ConfigMap aktuálně podporuje dvě různé hodnoty klíče ConfigMap: linear a ladder které odpovídají dvěma podporovaným režimům řízení. Kontroler linear poskytuje počet replik v rozsahu [min,max] ekvivalentní max( ceil( cores * 1/coresPerReplica ) , ceil( nodes * 1/nodesPerReplica ) ). ladder Kontroler vypočítá počet replik konzultacem se dvěma různými krokovými funkcemi, jednou pro škálování jádra a druhou pro škálování uzlu, a tím maximální hodnotu dvou replik. Další informace o režimech ovládacích prvků a formátu ConfigMap najdete v upstreamové dokumentaci.

Důležité

Doporučuje se minimálně 2 repliky podů CoreDNS na cluster. Konfigurace minimálně 1 repliky podu CoreDNS může způsobit selhání během operací, které vyžadují vyprazdňování uzlů, jako jsou operace upgradu clusteru.

Chcete-li načíst coredns-autoscaler objekt ConfigMap, můžete spustit kubectl get configmap coredns-autoscaler -n kube-system -o yaml příkaz, který vrátí následující příkaz:

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: "..."

Chování vertikálního automatického škálování podů v CoreDNS

CoreDNS je základní doplněk spravovaný službou AKS a ve výchozím nastavení je povolený. Aby se zachovala dostupnost služby CoreDNS, CoreDNS udržuje používání původních poskytnutých požadavků/limitů při povolení funkce automatického škálování doplňku, aby se zabránilo restartování podu CoreDNS, což způsobuje nedostupnost služby.

U doplňku CoreDNS spravovaného službou AKS jsou výchozí požadavky nebo limity procesoru nastavené na 100 m /3 jader a požadavky na paměť/limity na 70Mi/500Mi. Na základě těchto výchozích hodnot je poměr požadavků na limit procesoru přibližně 1:30 a pro paměť přibližně 1/7. Pokud jsou doporučené požadavky na CPU 500 m, VPA upraví limity CPU na 15, aby zachoval tento poměr. Podobně platí, že pokud jsou doporučené požadavky na paměť 700Mi, VPA upraví limit paměti na 5 000Mi.

VPA nastaví omezení procesoru a paměti CoreDNS na velké hodnoty na základě doporučeného požadavku procesoru a paměti VPA a poměru mezi požadavkem a limitem, jak je definováno AKS. Tyto úpravy jsou užitečné pro zpracování více požadavků během špičky. Nevýhodou je, že CoreDNS může spotřebovávat veškerý prostředek procesoru a paměti, který je k dispozici na uzlu v době špičky služby.

Je obtížné nastavit jednu ideální hodnotu požadavků na procesor a paměť/ omezení tak, aby splňovala požadavky velkého clusteru i malého clusteru najednou. Když povolíte optimalizované škálování doplňků, máte flexibilitu přizpůsobit požadavky na procesor a paměť CoreDNS nebo použít VPA k automatickému škálování CoreDNS tak, aby splňovaly konkrétní požadavky na cluster. Tady je několik scénářů, které je potřeba vzít v úvahu:

  • Zvažujete, jestli je VPA vhodná pro vaši službu CoreDNS a chcete zobrazit pouze doporučení VPA. Pokud nechcete, aby nástroj VPA automaticky aktualizoval pody, můžete zakázat funkci VPA pro CoreDNS povolením režimu aktualizace VPA na Vypnuto. Přizpůsobte konfiguraci prostředků v nasazení a nastavte požadavky na procesor/paměť na požadovanou hodnotu.
  • Zvažujete použití VPA, ale chcete omezit poměr požadavků na limit, takže VPA najednou neztěžuje limit procesoru a paměti na velké hodnoty. Můžete přizpůsobit prostředky v nasazení a aktualizovat hodnoty požadavků a omezení pro CPU a paměť, abyste udrželi poměr požadavku k limitu na 1/2 nebo 1/3.
  • Pokud zásada kontejneru VPA nastaví maximální povolenou hodnotu pro CPU a paměť, doporučené žádosti o prostředky tyto limity nepřekročí. Přizpůsobení konfigurace prostředků umožňuje zvýšit nebo snížit hodnoty maxAllowed a ovládat doporučení VPA (Vertikální automatické škálování prostředků).

Další informace najdete v tématu Povolení automatického škálování doplňků v clusteru AKS (Preview).

Povolení protokolování dotazů DNS

  1. Do objektu ConfigMap pro coredns-custom přidejte následující konfiguraci:

    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. Použijte změny konfigurace a vynuťte, aby CoreDNS k opětovnému načtení ConfigMap použil následující příkazy:

    # Apply configuration changes
kubectl apply -f corednsms.yaml

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

  3. Zobrazte ladicí protokolování CoreDNS za použití příkazu kubectl logs.

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

Řešení potíží s nevyvážeností provozu podů CoreDNS

Můžete si všimnout, že jeden nebo dva pody CoreDNS vykazují výrazně vyšší využití procesoru a zpracovávají více dotazů DNS než jiné, i když ve vašem clusteru AKS běží několik podů CoreDNS. Jedná se o známý problém v Kubernetes a může vést k přetížení a chybovému ukončení jednoho z podů CoreDNS.

Tato nerovnoměrná distribuce dotazů DNS je primárně způsobena omezeními vyrovnávání zatížení UDP v Kubernetes. Platforma používá k distribuci provozu UDP pětici (zdrojová IP adresa, zdrojový port, cílová IP adresa, cílový port, protokol), takže pokud aplikace znovu použije stejný zdrojový port pro dotazy DNS, všechny dotazy z tohoto klienta budou směrovány do stejného podu CoreDNS, což vede k tomu, že jeden pod zpracovává nepřiměřený objem provozu.

Některé aplikace navíc používají sdružování připojení a znovu používají připojení DNS. Toto chování může dále soustředit dotazy DNS na jeden pod CoreDNS, což zvyšuje nerovnováhu a zvyšuje riziko přetížení a potenciálních chybových ukončení.

Kontrola distribuce provozu podu CoreDNS

Než začnete, postupujte podle kroků v části Povolení protokolování dotazů DNS výše a zachyťte požadované protokoly dotazů DNS z podů CoreDNS. Jakmile je tato možnost povolená, spusťte následující příkazy:

  1. Spuštěním následujícího příkazu získejte názvy všech podů CoreDNS v clusteru:

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

  2. Projděte si protokoly pro každý pod CoreDNS a analyzujte vzory dotazů DNS:

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

  3. Vyhledejte opakované IP adresy a porty klienta, které se zobrazují jenom v protokolech jednoho podu CoreDNS. To znamená, že dotazy DNS z určitých klientů se nedistribuují rovnoměrně.

    Příklad položky protokolu:

    [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: IP adresa klienta, která vytváří dotaz DNS
    • 5556: Zdrojový port klienta
    • 42621: ID dotazu

    Pokud se stejná IP adresa klienta a port opakovaně zobrazují jenom v protokolech jednoho podu, potvrdí se tím nerovnováha provozu.

Pokud si všimnete této nerovnováhy, mohla by vaše aplikace znovu používat zdrojové porty UDP nebo sdružovat jejich připojení. V závislosti na původní příčině můžete provést následující akce pro zmírnění rizik:

  • Příčinou opakovaného použití zdrojového portu UDP:

    Opakované použití zdrojového portu UDP nastane, když klientská aplikace odesílá více dotazů DNS ze stejného zdrojového portu UDP. Pokud se jedná o problém, aktualizujte své aplikace nebo klienty DNS tak, aby pro každý dotaz DNS náhodně vybraly zdrojové porty, což pomáhá rovnoměrněji distribuovat požadavky mezi pody.

  • Způsobeno sdružováním připojení:
    Pooly připojení jsou mechanismy, které aplikace používají ke znovu využití stávajících síťových připojení místo vytváření nového připojení pro každý požadavek. I když se tím zvýší efektivita, může to vést ke všem dotazům DNS z aplikace odesílané přes stejné připojení, a tím směrovat do stejného podu CoreDNS. Pokud chcete tento problém zmírnit, upravte zpracování připojení DNS vaší aplikace snížením počtu TTL připojení (Time to Live) nebo náhodným vytvořením připojení, abyste zajistili, že dotazy nejsou soustředěné na jeden pod CoreDNS.

Tyto změny můžou pomoct dosáhnout vyváženější distribuce dotazů DNS a snížit riziko přetížení jednotlivých podů.

Další kroky

Tento článek ukázal několik ukázkových scénářů pro přizpůsobení CoreDNS. Informace o projektu CoreDNS najdete na stránce upstreamového projektu CoreDNS.

Další informace o základních konceptech sítě najdete v tématu Koncepty sítě pro aplikace v AKS.