Konfigurera LocalDNS i Azure Kubernetes Service (AKS)

Gäller för: ✔️ AKS Automatic ✔️ AKS Standard

För de flesta produktionsarbetsbelastningar är AKS Automatic den rekommenderade produktionsklara standardinställningen för AKS. LocalDNS är förkonfigurerat i AKS-automatiska kluster. I AKS Standard kan du aktivera och konfigurera LocalDNS per nodpool.

LocalDNS är en funktion i AKS som förbättrar DNS-matchningsprestanda och återhämtning för arbetsbelastningar som körs i klustret. Genom att köra en DNS-proxy på varje nod minskar LocalDNS svarstiden för DNS-frågor, förbättrar tillförlitligheten vid tillfälliga nätverksstörningar och tillhandahåller avancerade kontroller för cachelagring och vidarebefordran när du behöver anpassning.

Information om vad LocalDNS är, inklusive arkitekturinformation och viktiga funktioner, finns i DNS-matchning i Azure Kubernetes Service (AKS).

AKS Automatic- och AKS Standard-LocalDNS-beteende

Metodtips för LocalDNS-konfiguration

När du implementerar LocalDNS i dina AKS-kluster bör du överväga följande metodtips:

• Börja med en minimal konfiguration: Börja med en enkel konfiguration som använder Preferred läget för att verifiera din LocalDNS-konfigurationssyntax innan du går över till Required läge. Läget Preferred verifierar konfigurationen utan att aktivera LocalDNS, så att du kan fånga konfigurationsfel tidigt utan att påverka klustret.
• Implementera lämpliga cachelagringsstrategier: Konfigurera cacheinställningar baserat på dina arbetsbelastningsegenskaper:
  • Använd kortare cacheDurationInSeconds värden för poster som ändras ofta. När du gör det är det viktigt att observera att cacheDurationInSeconds fungerar som ett tak för DNS-postens TTL men inte ökar den. Den resulterande TTL:en är den mindre av det som returneras från uppströms eller vad som anges i cache-plugin-programmet.
  • Använd längre cachevaraktighet för stabila uppgifter för att minska DNS-frågor.
  • Aktivera serveStale med lämpliga inställningar för att underhålla tjänsten under DNS-avbrott.
  • Cachelagring med LocalDNS fungerar på bästa sätt och garanterar inte inaktuella svar. Cacheminnet är uppdelat i 256 shards och med ett standardvärde på högst 10 000 poster, vilket gör att varje shard kan innehålla cirka 39 poster. När en shard är full och en ny post måste läggas till, väljs en av de befintliga posterna slumpmässigt för att avlägsnas. Det finns ingen prioritering för äldre eller förfallna poster. Därför kanske en inaktuell uppgift inte alltid är tillgänglig, särskilt under hög frågevolym.
• Övervaka DNS-prestanda: När du har aktiverat LocalDNS övervakar du programmets DNS-prestanda med hjälp av:
  • Prestandamått för program.
  • Nodmått för att identifiera minskat nätverkstryck.
  • Loggposter när queryLogging är inställt på Log.
• Följ principen för lägsta behörighet: När du konfigurerar REGLER för DNS-vidarebefordran tillåter du endast åtkomst till de DNS-servrar och domäner som krävs.
• Test före produktionsdistribution: Testa alltid LocalDNS-konfigurationen i en icke-produktionsmiljö innan du distribuerar den till produktionskluster.
• Använd Infrastruktur som kod (IaC): Lagra din localdnsconfig.json-fil på infrastrukturlagringsplatsen och inkludera den i dina AKS-distributionsmallar.
• Nätverkskonfiguration för TCP-vidarebefordran: När du använder TCP för DNS-vidarebefordran till VnetDNS ska du se till att nätverkssäkerhetsgrupper (NSG: er), brandväggar eller virtuella nätverksinstallationer (NVA) inte blockerar TCP-trafik mellan CoreDNS/LocalDNS- och VnetDNS-servrar.
• Undvik att aktivera både NodeLocal DNSCache och LocalDNS: Vi rekommenderar inte att du aktiverar både den överordnade Kubernetes NodeLocal DNSCache och LocalDNS i nodpoolen. Även om AKS inte blockerar den här konfigurationen dirigeras all DNS-trafik via LocalDNS, vilket kan leda till oväntat beteende eller minskade fördelar med NodeLocal DNSCache.
• Inför inte ett TCP-anslutningstak på den överordnade anpassade DNS-servern innan du aktiverar LocalDNS: När du aktiverar LocalDNS på en nodpool öppnar varje nod långlivade TCP-anslutningar från sin lokala DNS-proxy till den överordnade matcharen i stället för de korta UDP-utbyten som användes tidigare. Om din anpassade DNS-server (till exempel BIND, Obundna, Windows DNS eller en tredjepartsinstallation) har konfigurerats med en fast gräns för samtidiga TCP-klientanslutningar, eller om du har justerat den gränsen baserat på pre-LocalDNS-trafik, kan de nya TCP-anslutningarna från LocalDNS avvisas, vilket orsakar klusteromfattande DNS-matchningsfel. Låt TCP-anslutningsgränsen vara generös innan du aktiverar LocalDNS, verifiera antalet TCP-anslutningar i stabilt tillstånd från AKS-noderna efter aktiveringen och justera endast gränsen efteråt med utrymme för utskalning av noder, uppgraderingar och nyskapningar.

Förutsättningar

AKS Automatiska kluster inkluderar LocalDNS förkonfigurerat. Kraven i det här avsnittet gäller främst när du aktiverar eller anpassar LocalDNS-beteende, vilket är vanligast i AKS Standard och avancerade anpassningsscenarier.

• Du måste ha ett befintligt AKS-kluster med Kubernetes version 1.31 och senare för att kunna använda LocalDNS. Om du behöver ett AKS-kluster kan du skapa ett med hjälp av Azure CLI, Azure PowerShell eller Azure-portalen.
• Den här artikeln kräver Azure CLI version 2.80.0 och senare. Om du använder Azure Cloud Shell är den senaste versionen redan installerad.
• LocalDNS stöds endast i nodpooler som kör Azure Linux eller Ubuntu 22.04 och senare.
• SKU:n för den virtuella datorn (VM) som används för nodpoolen måste ha minst 4 vCPU:er (kärnor) för att stödja LocalDNS.

Aktivera eller anpassa LocalDNS i ett AKS-kluster

Du konfigurerar LocalDNS på nodpoolsnivå i AKS, så att du kan skräddarsy beteende efter arbetsbelastning och miljö.

I AKS Automatic är LocalDNS redan förkonfigurerat, så det här avsnittet är främst för anpassning.

I AKS Standard använder du det här avsnittet för att aktivera och konfigurera LocalDNS.

Aktivera LocalDNS i en nodpool

Det här steget gäller vanligtvis för AKS Standard. AKS Automatic innehåller redan LocalDNS förkonfigurerat.

Om du vill aktivera LocalDNS när nodpoolen skapas använder du följande kommando med din anpassade konfigurationsfil:

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

Om du vill aktivera LocalDNS i en befintlig nodpool använder du följande kommando med din anpassade konfigurationsfil:

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

Inaktivera LocalDNS i en nodpool

Att inaktivera LocalDNS är en avancerad åtgärd och rekommenderas vanligtvis inte för standardvärden för AUTOMATISK AKS-produktion om du inte har ett verifierat undantag.

Om du vill inaktivera LocalDNS för en nodpool måste du uppdatera localdnsconfig.json-filen genom att ange mode egenskapen till Disabled. Den här ändringen instruerar AKS att inaktivera den lokala DNS-proxyn på alla noder i den angivna poolen, vilket återställer DNS-matchning till standardklusterbeteendet. När du har uppdaterat konfigurationsfilen tillämpar du den på nodpoolen med hjälp av Azure CLI för att säkerställa att ändringen börjar gälla.

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

Verifiera LocalDNS-åtgärden

I AKS Automatic bekräftar verifieringen att den förkonfigurerade LocalDNS-baslinjen är aktiv för dina arbetsbelastningar. I AKS Standard bekräftar verifieringen utrullningen av LocalDNS.

När LocalDNS har aktiverats kan du verifiera åtgärden genom att köra DNS-frågor från poddar i den angivna nodpoolen SERVER och granska fältet i svaren för att bekräfta att LocalDNS-adresser returneras (169.254.10.10 eller 169.254.10.11).

Kontrollera att följande villkor är uppfyllda innan du kör verifieringsstegen:

1. Du har kubectl installerat och konfigurerat för åtkomst till ditt AKS-kluster.
2. Ditt användarkonto har tillräcklig behörighet för att skapa och köra kommandon i pods.
3. Nodpoolen där du vill verifiera LocalDNS är i tillståndet Klar .
4. BusyBox-avbildningen (busybox:1.28) är tillgänglig från dina klusternoder.

Valideringsexempel:

1. Skapa en felsökningspodd i nodpoolen där LocalDNS är aktiverat:

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

2. När podden har körts kör du följande kommando för att kontrollera DNS-matchningen:

   kubectl exec -it dnstest -- nslookup kubernetes.default
   

   Kontrollera utdata. Om localDNS fungerar korrekt bör du se ett svar med serveradressen 169.254.10.10 eller 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
   

Konfigurera LocalDNS

LocalDNS använder en JSON-baserad konfigurationsfil localdnsconfig.json för att definiera DNS-matchningsbeteende för varje nodpool. Med den här filen kan du ange driftlägen, serverblock för olika DNS-domäner och plugin-inställningar som cachelagring, vidarebefordran och loggning.

Standardkonfiguration för LocalDNS

I AKS Automatic är LocalDNS förkonfigurerat. Använd endast anpassning när du har ett specifikt krav.

I AKS Standard är den här standardkonfigurationen en bra startpunkt.

När du anpassar LocalDNS använder du följande konfigurationsformat som mall. Du kan definiera extra serverblock efter behov, men om du lägger till egenskaper på toppnivå som inte stöds eller inte är standard i konfigurationen resulterar det i valideringsfel.

{
  "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"
    }
  }
}

Konfigurera mode för LocalDNS

LocalDNS kan aktiveras i tre möjliga lägen som definierar omfattningen av tillämpningen av LocalDNS för arbetsbelastningen:

• Required: LocalDNS tillämpas på nodpoolen om alla krav uppfylls. Om kraven inte uppfylls misslyckas distributionen.
• Disabled: Inaktiverar den lokala DNS-funktionen, så DNS-frågor inte löses upp lokalt på noden.
• Preferred: AKS verifierar att din LocalDNS-konfiguration är syntaktiskt korrekt men inte aktiverar LocalDNS på noderna. Om du använder det här läget utlöses dock fortfarande en nodåterimeringsåtgärd, så du kan testa konfigurationen för fel utan att påverka DNS-matchningen i klustret.

För produktionsarbetsbelastningar i AKS Automatic behåller du det förkonfigurerade LocalDNS-beteendet såvida du inte har ett verifierat behov av att anpassa.

I följande tabell sammanfattas LocalDNS-beteendet för varje läge och Kubernetes-version:

Serverblock för LocalDNS

Standardkonfigurationen gäller för frågor från poddar som använder dnsPolicy:default (under vnetDNSOverrides) och poddar som använder dnsPolicy:ClusterFirst (under kubeDNSOverrides). Inom varje finns det två standardserverblock definierade: . och cluster.local.

• . representerar alla externa DNS-frågor från poddar som försöker lösa offentliga eller icke-klusterdomäner (till exempel microsoft.com).
• cluster.local representerar alla interna Kubernetes-tjänstidentifieringsfrågor från poddar som försöker matcha Kubernetes-tjänstnamn eller interna klusterresurser. Dessa frågor dirigeras via CoreDNS för lösning i klustret.

Plugin-program som stöds för LocalDNS-konfiguration

Konfigurationsverifieringsregler

När du skapar din LocalDNS-konfiguration bör du vara medveten om dessa verifieringsregler för att undvika distributionsfel:

• Rotzonsbegränsningar (.) : Under vnetDNSOverridesforwardDestination kan rotzonen inte vara ClusterCoreDNS.
• Begränsningar för cluster.local-zonen: Under både vnetDNSOverrides och kubeDNSOverridesforwardDestination kan cluster.local inte vara VnetDNS.
• Protokoll- och serveStale-kompatibilitet: När protocol är inställt på ForceTCP, serveStale kan inte anges till Verify. Använd Immediate i stället.

Skapa ett anpassat serverblock i LocalDNS

CoreDNS matchar frågor till ett specifikt serverblock baserat på en exakt matchning för domän som efterfrågas och inte på partiella matchningar. Om du behöver anpassade serverblock kan du lägga till dem i din LocalDNS-konfiguration genom att skapa en fil med namnet localdnsconfig.json med de tillagda konfigurationerna.

Om du till exempel har specifika DNS-behov vid åtkomst till microsoft.com kan du använda följande serverblock:

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

Övervaka LocalDNS

I AKS Automatic är LocalDNS förkonfigurerat, så börja med baslinjeverifiering och övervakningsbeteende innan du tillämpar anpassad justering.

LocalDNS exponerar Prometheus-mått som du kan använda för övervakning och aviseringar. Mätvärden exponeras på port 9253 på nodens IP-adress.

Exempel på scrape-konfiguration för tillägget Azure Managed Prometheus som en 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']

Felsöka lokal DNS

DNS-frågor till specifika domäner misslyckas

Om DNS-frågor till specifika domäner misslyckas efter aktivering av LocalDNS:

1. Kontrollera om du har domänspecifika åsidosättningar i localdnsconfig.json som kan vara felkonfigurerade.
2. Prova tillfälligt att ta bort domänspecifika åsidosättningar och endast använda standardkonfigurationen . .
3. Kontrollera om problemet uppstår med både UDP (User Datagram Protocol) och Transmission Control Protocol (TCP) genom att protocol justera inställningen.

Uppdatera VNet DNS-servrar för LocalDNS

När du uppdaterar anpassade DNS-servrar direkt i VNet-konfigurationen (med hjälp av Azure-portalen eller CLI) tillämpar AKS-klusternoderna inte ändringarna automatiskt. Uppdatering av DNS-inställningar på VNet-nivå informerar endast nätverksresursprovidern (NRP), men meddelar inte AKS-resursprovidern. Därför fortsätter AKS-noder att använda de tidigare DNS-serverinställningarna tills du vidtar ytterligare åtgärder.

Så här kontrollerar du att AKS-noder hämtar de nya VNet DNS-serverinställningarna:

1. Uppdatera DNS-konfigurationen för det virtuella nätverket med hjälp av Azure-portalen eller API:er efter behov.

2. Använd AKS-resursprovidern för att återskapa nodpoolen, vilket säkerställer att de uppdaterade DNS-inställningarna tillämpas och behålls:

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

Den här processen säkerställer att AKS-resursprovidern är medveten om DNS-ändringarna och tillämpar dem på alla noder i nodpoolen.

Uppdatera Cilium-nätverksprinciper för att tillåta DNS-matchning med LocalDNS

Om du distribuerar Cilium-nätverksprinciper i klustret måste du uttryckligen tillåta poddutgående till LocalDNS IP-adresser.

Nätverksprinciper framtvingar en standardnekande modell för mål som inte har angetts, så DNS-trafik till LocalDNS blockeras om den inte uttryckligen tillåts.

• På Azure CNI som drivs av Cilium <=v1.16 med k8s <=1.31 kan detta uppnås med en CIDR-baserad princip.
• På Azure CNI som drivs av Cilium >=v1.17 med K8s >=1.32 kan en Cilium-nätverksprincip som tillåter utgående trafik till värdenheter användas.

Följande Cilium-nätverksprincip kan användas för att tillåta trafik mellan alla versioner:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "allow-azure-dns-egress"
  namespace: default
spec:
  endpointSelector:
    matchLabels: {} # This selects ALL pods in the namespace
  egress:
    - toCIDR:
        - 169.254.10.0/24
      toPorts:
        - ports:
            - port: "53"
              protocol: UDP
            - port: "53"
              protocol: TCP
    - toEntities:
        - host
      toPorts:
        - ports:
            - port: "53"
              protocol: UDP
            - port: "53"
              protocol: TCP

Relaterat innehåll

• Vad är AKS Automatic?
• Skapa ett AKS-automatiskt kluster
• LocalDNS i Azure Kubernetes Service (konceptuell)
• Felsöka LocalDNS-problem i AKS
• Anpassningsguide för CoreDNS
• CoreDNS överordnad projektsida
• Nätverksbegrepp för program i AKS