LocalDNS configureren in Azure Kubernetes Service (AKS)

Van toepassing op: ✔️ AKS Automatic ✔️ AKS Standard

Voor de meeste productieworkloads is AKS Automatic de aanbevolen, productieklare standaardoptie voor AKS. LocalDNS is vooraf geconfigureerd in automatische AKS-clusters. In AKS Standard is localDNS-gedrag afhankelijk van de Kubernetes-versie en het bestaande LocalDNS-profiel van de knooppuntgroep.

LocalDNS is een functie in AKS die de prestaties en tolerantie van DNS-resolutie verbetert voor workloads die in uw cluster worden uitgevoerd. Door een DNS-proxy uit te voeren op elk knooppunt, vermindert LocalDNS de latentie van DNS-query's, verbetert de betrouwbaarheid tijdens tijdelijke netwerkonderbrekingen en biedt geavanceerde besturingselementen voor caching en doorsturen wanneer u aanpassingen nodig hebt.

Als u wilt weten wat LocalDNS is, inclusief architectuurdetails en belangrijke mogelijkheden, raadpleegt u DNS-resolutie in Azure Kubernetes Service (AKS).

Gedrag van AKS Automatic en AKS Standard LocalDNS

Compatibiliteitscontroles voor de modus Preferred

Vanaf Kubernetes 1.37 wijst AKS Standard de modus toe Preferred aan in aanmerking komende knooppuntgroepen zonder een expliciet LocalDNS-profiel wanneer deze pools worden gemaakt of bijgewerkt. AKS behoudt expliciet geconfigureerde profielen.

Voordat U LocalDNS Preferred in de modus inschakelt, controleert AKS de volgende compatibiliteitsvereisten. Als niet aan een vereiste wordt voldaan, blijft LocalDNS uitgeschakeld.

Zodra AKS LocalDNS inschakelt in Preferred de modus, blijft deze ingeschakeld tijdens volgende updates van niet-gerelateerde knooppuntgroepen. Als u dit wilt uitschakelen, stelt u de LocalDNS mode expliciet in op Disabled.

Aanbevolen procedures voor LocalDNS-configuratie

Houd rekening met de volgende aanbevolen procedures bij het implementeren van LocalDNS in uw AKS-clusters:

• Begin met een minimale configuratie: begin met een eenvoudige configuratie die gebruikmaakt van de modus om de Preferred syntaxis van de LocalDNS-configuratie te valideren voordat u naar Required de modus gaat. De Preferred modus valideert uw configuratie zonder LocalDNS in te schakelen, zodat u configuratiefouten vroegtijdig kunt ondervangen zonder dat dit van invloed is op uw cluster.
• Implementeer de juiste cachestrategieën: Cache-instellingen configureren op basis van uw workloadkenmerken:
  • Gebruik kortere cacheDurationInSeconds waarden voor het regelmatig wijzigen van records. Als u dit doet, is het belangrijk om te weten dat cacheDurationInSeconds fungeert als een limiet voor de DNS-record TTL, maar dit niet verhoogt. Het resulterende TTL is het kleinst van wat wordt geretourneerd vanuit upstream of wat is ingesteld in de cache-plugin.
  • Voor stabiele records gebruikt u langere cacheduur om DNS-query's te verminderen.
  • Maak serveStale beschikbaar met de juiste instellingen om de service te onderhouden tijdens DNS-storingen.
  • Caching met LocalDNS werkt op basis van best effort en garandeert geen verlopen antwoorden. De cache is onderverdeeld in 256 shards en met een standaard maximum van 10.000 vermeldingen, zodat elke shard ongeveer 39 vermeldingen kan bevatten. Wanneer een shard vol is en er een nieuwe vermelding moet worden toegevoegd, wordt een van de bestaande vermeldingen willekeurig gekozen om te worden verwijderd. Er is geen voorkeur voor oudere of verlopen vermeldingen. Als gevolg hiervan is een verouderde record mogelijk niet altijd beschikbaar, met name onder een groot queryvolume.
• DNS-prestaties bewaken: controleer na het inschakelen van LocalDNS de DNS-prestaties van uw toepassing met behulp van:
  • Metrische gegevens over toepassingsprestaties.
  • Metrische knooppuntgegevens om verminderde netwerkdruk te detecteren.
  • Logboekvermeldingen bij het instellen van queryLogging naar Log.
• Volg het principe met minimale bevoegdheden: bij het configureren van regels voor dns-doorsturen, staat u alleen toegang toe tot de vereiste DNS-servers en -domeinen.
• Testen vóór productie-implementatie: Test altijd de LocalDNS-configuratie in een niet-productieomgeving voordat deze wordt geïmplementeerd in productieclusters.
• Infrastructuur als code (IaC) gebruiken: sla uw localdnsconfig.json bestand op in uw infrastructuuropslagplaats en neem het op in uw AKS-implementatiesjablonen.
• Netwerkconfiguratie voor tcp-doorsturen: wanneer u TCP gebruikt voor DNS-doorsturen naar VnetDNS, moet u ervoor zorgen dat uw netwerkbeveiligingsgroepen (NSG's), firewalls of netwerk-VM's (Netwerk-VM's) TCP-verkeer tussen CoreDNS-/LocalDNS- en VnetDNS-servers niet blokkeren.
• Schakel niet zowel NodeLocal DNSCache als LocalDNS in: het wordt niet aanbevolen om zowel de upstream Kubernetes NodeLocal DNSCache als LocalDNS in uw knooppuntgroep in te schakelen. Hoewel deze configuratie niet wordt geblokkeerd door AKS, wordt al het DNS-verkeer gerouteerd via LocalDNS, wat kan leiden tot onverwacht gedrag of verminderde voordelen van NodeLocal DNSCache.
• Leg geen TCP-verbindingslimiet op voor de upstream aangepaste DNS-server voordat u LocalDNS inschakelt: Wanneer u LocalDNS inschakelt in een knooppuntgroep, opent elk knooppunt langlopende TCP-verbindingen van de lokale DNS-proxy naar de upstream-resolver, in plaats van de korte UDP-uitwisselingen die eerder zijn gebruikt. Als uw aangepaste DNS-server (zoals BIND, Niet-afhankelijk, Windows DNS of een apparaat van derden) is geconfigureerd met een vaste limiet voor gelijktijdige TCP-clientverbindingen, of als u die limiet hebt aangepast op basis van pre-LocalDNS-verkeer, kunnen de nieuwe TCP-verbindingen van LocalDNS worden geweigerd, waardoor dns-omzettingsfouten in het hele cluster optreden. Laat een TCP-verbindingslimiet op de ruime standaardwaarde staan voordat u LocalDNS inschakelt, controleer het aantal TCP-verbindingen in stabiele toestand van uw AKS-knooppunten nadat u LocalDNS hebt ingeschakeld, en pas de limiet daarna alleen aan met voldoende marge voor het uitschalen van knooppunten, upgrades en herinstallaties.

Vereiste voorwaarden

AKS Automatic-clusters zijn vooraf geconfigureerd met LocalDNS. De vereisten in deze sectie zijn voornamelijk van toepassing wanneer u LocalDNS-gedrag inschakelt of aanpast, wat het meest voorkomt in AKS Standard- en geavanceerde aanpassingsscenario's.

• U moet een bestaand AKS-cluster hebben met Kubernetes-versies 1.31 en hoger om LocalDNS te kunnen gebruiken. Als u een AKS-cluster nodig hebt, kunt u er een maken met Azure CLI, Azure PowerShell of de Azure portal.
• Voor dit artikel is Azure CLI versie 2.80.0 en hoger vereist. Als u Azure Cloud Shell gebruikt, is de nieuwste versie al geïnstalleerd.
• LocalDNS wordt alleen ondersteund in knooppuntgroepen met Azure Linux of Ubuntu 22.04 en hoger.
• De SKU van de virtuele machine (VM) die voor uw knooppuntgroep wordt gebruikt, moet ten minste 4 vCPU's (cores) hebben om LocalDNS te ondersteunen.

LocalDNS in- of aanpassen op een AKS-cluster

U configureert LocalDNS op het niveau van de knooppuntgroep in AKS, zodat u het gedrag kunt aanpassen per workload en omgeving.

In AKS Automatic is LocalDNS al vooraf geconfigureerd, dus deze sectie is voornamelijk bedoeld voor aanpassing.

In AKS Standard gebruikt u deze sectie om LocalDNS in te schakelen en te configureren.

Aangepaste DNS valideren voordat LocalDNS wordt ingeschakeld

Als uw virtuele netwerk gebruikmaakt van aangepaste DNS-servers, test u beide DNS-transporten vanaf een AKS-knooppunt voordat u LocalDNS inschakelt:

dig +udp @<custom-dns-ip> <fqdn>
dig +tcp @<custom-dns-ip> <fqdn>

Beide opdrachten moeten een geldig antwoord retourneren. Als UDP slaagt maar er bij TCP een time-out optreedt, schakel LocalDNS dan niet in totdat TCP-poort 53 is toegestaan over het volledige netwerkpad en de aangepaste DNS-server is geconfigureerd om TCP-query’s te accepteren.

LocalDNS inschakelen in een knooppuntgroep

Deze stap is doorgaans van toepassing op AKS Standard. AKS Automatic bevat al LocalDNS vooraf geconfigureerd.

Als u LocalDNS wilt inschakelen tijdens het maken van een knooppuntgroep, gebruikt u de volgende opdracht met uw aangepaste configuratiebestand:

az aks nodepool add --name mynodepool1 --cluster-name myAKSCluster --resource-group myResourceGroup --localdns-config ./localdnsconfig.json

Als u LocalDNS wilt inschakelen voor een bestaande knooppuntgroep, gebruikt u de volgende opdracht met uw aangepaste configuratiebestand:

az aks nodepool update --name mynodepool1 --cluster-name myAKSCluster --resource-group myResourceGroup --localdns-config ./localdnsconfig.json

LocalDNS uitschakelen in een knooppuntgroep

Het uitschakelen van LocalDNS is een geavanceerde bewerking en wordt over het algemeen niet aanbevolen voor de standaardinstellingen voor automatische productie van AKS, tenzij u een gevalideerde uitzondering hebt.

Als u LocalDNS wilt uitschakelen voor een knooppuntgroep, moet u uw localdnsconfig.json bestand bijwerken door de mode eigenschap in te stellen op Disabled. Met deze wijziging wordt AKS geïnstrueerd om de lokale DNS-proxy uit te schakelen op alle knooppunten in de opgegeven pool, waardoor de DNS-resolutie wordt teruggezet naar het standaardclustergedrag. Nadat u het configuratiebestand hebt bijgewerkt, past u het toe op de knooppuntgroep met behulp van de Azure CLI om ervoor te zorgen dat de wijziging van kracht wordt.

az aks nodepool update --name mynodepool1 --cluster-name myAKSCluster --resource-group myResourceGroup --localdns-config ./localdnsconfig.json

LocalDNS-bewerking controleren

In AKS Automatic bevestigt verificatie dat de vooraf geconfigureerde LocalDNS-basislijn actief is voor uw workloads. In AKS Standard bevestigt verificatie uw LocalDNS-implementatie.

Zodra LocalDNS is ingeschakeld, kunt u de bewerking controleren door DNS-query's uit te voeren vanuit pods in de opgegeven knooppuntgroep en het SERVER veld in de antwoorden te inspecteren om te bevestigen dat LocalDNS-adressen worden geretourneerd (169.254.10.10 of 169.254.10.11).

Voordat u de validatiestappen uitvoert, moet u ervoor zorgen dat aan de volgende voorwaarden wordt voldaan:

1. U hebt kubectl geïnstalleerd en geconfigureerd om toegang te krijgen tot uw AKS-cluster.
2. Uw gebruikersaccount heeft voldoende machtigingen om pods te maken en uit te proberen.
3. De knooppuntgroep waarin u LocalDNS wilt valideren, heeft de status Gereed .
4. De afbeelding van BusyBox (busybox:1.28) is toegankelijk vanuit uw clusterknooppunten.

Validatievoorbeeld:

1. Maak een foutopsporingspod in de knooppuntgroep waarvoor LocalDNS is ingeschakeld:

   kubectl run dnstest --image=busybox:1.28 -- sleep 3600
   

2. Zodra de pod actief is, voert u de volgende opdracht uit om de DNS-resolutie te controleren.

   kubectl exec -it dnstest -- nslookup kubernetes.default
   

   Controleer de uitvoer. Als localDNS correct werkt, ziet u een antwoord met het serveradres 169.254.10.10 of 169.254.10.11:

   Server:    169.254.10.10
   Address 1: 169.254.10.10
   
   Name:      kubernetes.default
   Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local
   

LocalDNS configureren

LocalDNS maakt gebruik van een op JSON gebaseerd configuratiebestand localdnsconfig.json om het gedrag van DNS-omzetting voor elke knooppuntgroep te definiëren. Met dit bestand kunt u operationele modi, serverblokken opgeven voor verschillende DNS-domeinen en instellingen voor invoegtoepassingen, zoals caching, doorsturen en logboekregistratie.

Standaardconfiguratie localDNS

In AKS Automatic is LocalDNS vooraf geconfigureerd. Gebruik aanpassingen alleen als u een specifieke vereiste hebt.

In AKS Standard is deze standaardconfiguratie een goed uitgangspunt.

Bij het aanpassen van LocalDNS gebruikt u de volgende configuratie-indeling als uw sjabloon. U kunt indien nodig extra serverblokken definiëren, maar het toevoegen van niet-ondersteunde of niet-standaard eigenschappen op het hoogste niveau aan de configuratie resulteert in validatiefouten.

{
  "mode": "Required",
  "vnetDNSOverrides": {
    ".": {
      "queryLogging": "Error",
      "protocol": "PreferUDP",
      "forwardDestination": "VnetDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    },
    "cluster.local": {
      "queryLogging": "Error",
      "protocol": "ForceTCP",
      "forwardDestination": "ClusterCoreDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    }
  },
  "kubeDNSOverrides": {
    ".": {
      "queryLogging": "Error",
      "protocol": "PreferUDP",
      "forwardDestination": "ClusterCoreDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    },
    "cluster.local": {
      "queryLogging": "Error",
      "protocol": "ForceTCP",
      "forwardDestination": "ClusterCoreDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    }
  }
}

mode configureren voor LocalDNS

LocalDNS kan worden ingeschakeld in drie mogelijke modi waarmee de mate van afdwinging van LocalDNS voor de workload wordt gedefinieerd:

• Required: LocalDNS wordt toegepast op de knooppuntgroep als aan alle voorwaarden is voldaan. Als niet aan de vereisten wordt voldaan, mislukt de implementatie.
• Disabled: Schakelt de lokale DNS-functie uit, zodat DNS-query's niet lokaal worden omgezet op het knooppunt.
• Preferred: AKS valideert dat uw LocalDNS-configuratie syntactisch juist is, maar localDNS niet inschakelt op de knooppunten. Als u deze modus toepast, wordt echter nog steeds een bewerking voor het opnieuw instellen van knooppunten geactiveerd, zodat u uw configuratie kunt testen op fouten zonder dat dit van invloed is op de DNS-omzetting in uw cluster.

Voor productieworkloads in AKS Automatic moet u het vooraf geconfigureerde LocalDNS-gedrag behouden, tenzij u een gevalideerde noodzaak hebt om aan te passen.

De volgende tabel bevat een overzicht van localDNS-gedrag voor elke modus en Kubernetes-versie:

Serverblokken voor LocalDNS

De standaardconfiguratie is van toepassing op query's van pods met behulp van dnsPolicy:default (onder vnetDNSOverrides) en pods met behulp van dnsPolicy:ClusterFirst (onder kubeDNSOverrides). Binnen elk zijn er twee standaardserverblokken gedefinieerd: . en cluster.local.

• . vertegenwoordigt alle externe DNS-query's van pods die openbare of niet-clusterdomeinen proberen op te lossen (bijvoorbeeld microsoft.com).
• cluster.local vertegenwoordigt alle interne Kubernetes-servicedetectiequery's van pods die kubernetes-servicenamen of interne clusterbronnen proberen op te lossen. Deze query's worden gerouteerd via CoreDNS voor oplossing binnen het cluster.

Ondersteunde invoegtoepassingen voor LocalDNS-configuratie

Configuratievalidatieregels

Wanneer u uw LocalDNS-configuratie maakt, moet u rekening houden met deze validatieregels om implementatiefouten te voorkomen:

• Beperkingen voor de hoofdzone (.): Onder vnetDNSOverrides, de forwardDestination voor de hoofdzone kan niet zijn ClusterCoreDNS.
• Beperkingen voor de cluster.local-zone: Onder zowel vnetDNSOverrides als kubeDNSOverrides kan de forwardDestination voor cluster.local niet VnetDNS zijn.
• Compatibiliteit van protocol en serveStale: Wanneer protocol is ingesteld op ForceTCP, serveStale kan niet worden ingesteld op Verify. Gebruik in plaats daarvan Immediate.

Een aangepast serverblok maken in LocalDNS

CoreDNS verwerkt query's naar een specifiek serverblok op basis van een exacte overeenkomst voor het ondergevraagde domein en niet op gedeeltelijke matchen. Als u aangepaste serverblokken nodig hebt, kunt u deze toevoegen aan uw LocalDNS-configuratie door een bestand met de naam localdnsconfig.json te maken met de toegevoegde configuraties.

Als u bijvoorbeeld specifieke DNS-behoeften hebt bij het openen van microsoft.com, kunt u het volgende serverblok gebruiken:

"microsoft.com": {
  "queryLogging": "Error",
  "protocol": "ForceTCP",
  "forwardDestination": "ClusterCoreDNS",
  "forwardPolicy": "Sequential",
  "maxConcurrent": 1000,
  "cacheDurationInSeconds": 3600,
  "serveStaleDurationInSeconds": 3600,
  "serveStale": "Immediate"
}

LocalDNS bewaken

In AKS Automatic is LocalDNS vooraf geconfigureerd, dus begin met basislijnvalidatie en monitorgedrag voordat u aangepaste afstemming toepast.

LocalDNS maakt prometheus-metrische gegevens beschikbaar die u kunt gebruiken voor bewaking en waarschuwingen. Metrische gegevens worden weergegeven op poort 9253 van het IP-adres van het knooppunt.

Voorbeeld van een scrape-configuratie voor Azure beheerde Prometheus-invoegtoepassing als een DaemonSet:

kind: ConfigMap
apiVersion: v1
metadata:
  name: ama-metrics-prometheus-config-node
  namespace: kube-system
data:
  prometheus-config: |-
    global:
      scrape_interval: 1m
    scrape_configs:
    - job_name: localdns-metrics
      scrape_interval: 1m
      scheme: http
      metrics_path: /metrics
      relabel_configs:
      - source_labels: [__metrics_path__]
        regex: (.*)
        target_label: metrics_path
      - source_labels: [__address__]
        replacement: '$NODE_NAME'
        target_label: instance
      static_configs:
      - targets: ['$NODE_IP:9253']

Problemen met LocalDNS oplossen

DNS-query's naar specifieke domeinen mislukken

Als DNS-query's naar specifieke domeinen mislukken nadat LocalDNS is ingeschakeld:

1. Controleer of u domeinspecifieke overschrijvingen hebt in uw localdnsconfig.json die mogelijk verkeerd zijn geconfigureerd.

2. Probeer tijdelijk domeinspecifieke overschrijvingen te verwijderen en alleen de . standaardconfiguratie te gebruiken.

3. Controleer of het probleem zich voordoet met zowel UDP (User Datagram Protocol) als Transmission Control Protocol (TCP) door de protocol instelling aan te passen.

4. Controleer de CoreDNS-logboeken op time-outs voor de LocalDNS-adressen 169.254.10.10:53 of 169.254.10.11:53. Test vanaf een betrokken knooppunt de upstream aangepaste DNS-server afzonderlijk via UDP en TCP:

   dig +udp @<custom-dns-ip> <fqdn>
   dig +tcp @<custom-dns-ip> <fqdn>
   

   Als UDP slaagt, maar TCP mislukt, controleert u of:

   • De aangepaste DNS-server luistert op TCP-poort 53.
   • NSG's en firewalls staan TCP-poort 53 toe vanuit het subnet van het AKS-knooppunt.
   • NVA’s en routes zorgen er niet voor dat TCP-DNS-verkeer wordt gedropt of asymmetrisch wordt gerouteerd.

   Als u LocalDNS wilt uitschakelen voor een betrokken knooppuntgroep, werkt u de LocalDNS-modus bij naar Disabled. Het wijzigen van een ingeschakelde pool in Disabled activeert het opnieuw image’en van een knooppunt als onderdeel van de update. Voor een permanente oplossing moet u ervoor zorgen dat de aangepaste DNS-server en het netwerkpad ONDERSTEUNING bieden voor DNS via zowel UDP als TCP op poort 53.

VNet DNS-servers voor LocalDNS bijwerken

Wanneer u aangepaste DNS-servers rechtstreeks in de VNet-configuratie bijwerkt (met behulp van de Azure-portal of CLI), worden deze wijzigingen niet automatisch toegepast op de AKS-clusterknooppunten. Bij het bijwerken van de DNS-instellingen op VNet-niveau wordt alleen de netwerkresourceprovider (NRP) geïnformeerd, maar niet de AKS-resourceprovider. Als gevolg hiervan blijven AKS-knooppunten de vorige DNS-serverinstellingen gebruiken totdat u verdere actie onderneemt.

Om ervoor te zorgen dat AKS-knooppunten de nieuwe DNS-serverinstellingen van het VNet ophalen:

1. Werk indien nodig de DNS-configuratie van het VNet bij met behulp van azure Portal of API's.

2. Gebruik de AKS-resourceprovider om de knooppuntgroep te herconfigureeren, zodat de bijgewerkte DNS-instellingen worden toegepast en behouden.

   az aks nodepool upgrade --resource-group myResourceGroup --cluster-name myAKSCluster --name mynodepool --node-image-only
   

Dit proces zorgt ervoor dat de AKS-resourceprovider op de hoogte is van de DNS-wijzigingen en deze toepast op alle knooppunten in de knooppuntgroep.

Cilium-netwerkbeleid bijwerken om DNS-omzetting met LocalDNS toe te staan

Als u Cilium-netwerkbeleid in uw cluster implementeert, moet u het uitgaand verkeer van pods expliciet naar de LOCALDNS-IP-adressen toestaan.

Netwerkbeleid dwingt een standaardverkenningsmodel af voor bestemmingen die niet zijn opgegeven, zodat DNS-verkeer naar LocalDNS wordt geblokkeerd, tenzij dit expliciet is toegestaan.

• Op Azure CNI Powered by Cilium <=v1.16 met k8s <=1,31, kan dit worden bereikt door een CIDR-beleid.
• Op Azure CNI Powered by Cilium >=v1.17 en K8s >=1.32, kan een Cilium Network Policy die uitgaand verkeer naar hostentiteiten toestaat worden gebruikt.

Voor een Cilium-netwerkbeleid dat verkeer in alle versies toestaat, zie Wordt AKS Local DNS ondersteund door Azure CNI Powered by Cilium?

Verwante onderwerpen

• Wat is AKS Automatic?
• Een automatisch AKS-cluster maken
• LocalDNS in Azure Kubernetes Service (conceptueel)
• Problemen met LocalDNS in AKS oplossen
• Handleiding voor het aanpassen van CoreDNS
• Upstreamprojectpagina van CoreDNS
• Netwerkconcepten voor toepassingen in AKS-