Configurer LocalDNS dans Azure Kubernetes Service (AKS)

S’applique à : ✔️ AKS Automatic ✔️ AKS Standard

Pour la plupart des charges de travail de production, AKS Automatic est l’option par défaut recommandée pour un environnement de production sur AKS. LocalDNS est préconfiguré dans les clusters automatiques AKS. Dans AKS Standard, vous pouvez activer et configurer LocalDNS par pool de nœuds.

LocalDNS est une fonctionnalité d’AKS qui améliore les performances de résolution DNS et la résilience des charges de travail exécutées dans votre cluster. En exécutant un proxy DNS sur chaque nœud, LocalDNS réduit la latence des requêtes DNS, améliore la fiabilité pendant les interruptions réseau temporaires et fournit des contrôles de mise en cache et de transfert avancés lorsque vous avez besoin de personnalisation.

Pour savoir ce que localDNS est, y compris les détails de l’architecture et les fonctionnalités clés, consultez Résolution DNS dans Azure Kubernetes Service (AKS).

Comportement AKS Automatic et AKS Standard LocalDNS

Comportement AKS Automatic AKS Standard
Disponibilité localDNS Préconfiguré par défaut Optional
Action classique Valider et surveiller les valeurs par défaut, personnaliser uniquement si nécessaire Activer, configurer et paramétrer par pool de nœuds
Conseils en matière de production Option par défaut recommandée, prête pour la production, pour la plupart des charges de travail AKS Utiliser quand vous avez besoin d’un contrôle manuel total de la configuration du cluster

Meilleures pratiques pour la configuration localDNS

Lors de l’implémentation de LocalDNS dans vos clusters AKS, tenez compte des meilleures pratiques suivantes :

  • Commencez par une configuration minimale : commencez par une configuration simple qui utilise le Preferred mode pour valider votre syntaxe de configuration LocalDNS avant de passer au Required mode. Le Preferred mode valide votre configuration sans activer LocalDNS, ce qui vous permet d’intercepter les erreurs de configuration tôt sans impacter votre cluster.
  • Implémentez des stratégies de mise en cache appropriées : configurez les paramètres de cache en fonction des caractéristiques de votre charge de travail :
    • Pour les enregistrements fréquemment modifiés, utilisez des valeurs plus cacheDurationInSeconds courtes. Dans ce cas, il est important de noter que cacheDurationInSeconds agit comme une limite sur la durée de vie de l’enregistrement DNS, mais ne l’augmente pas. La durée de vie résultante (TTL) est la plus petite entre celle retournée de l'amont et celle définie dans le plug-in de cache.
    • Pour les enregistrements stables, utilisez des durées de cache plus longues pour réduire les requêtes DNS.
    • Configurez serveStale avec les paramètres appropriés pour maintenir le service pendant les pannes DNS.
    • La mise en cache avec LocalDNS fonctionne de manière optimale et ne garantit pas les réponses obsolètes. Le cache est divisé en 256 partitions et avec un maximum par défaut de 10 000 entrées, ce qui permet à chaque partition de contenir environ 39 entrées. Lorsqu'un fragment est plein et qu'une nouvelle entrée doit être ajoutée, l'une des entrées existantes est choisie au hasard pour être supprimée. Il n’existe aucune préférence pour les entrées anciennes ou pour celles expirées. Par conséquent, un enregistrement obsolète peut ne pas toujours être disponible, en particulier sous un volume de requêtes élevé.
  • Surveiller les performances DNS : après avoir activé LocalDNS, surveillez les performances DNS de votre application à l’aide de :
    • Métriques de performances des applications.
    • Métriques de nœud pour détecter la réduction de la pression réseau.
    • Entrées de journal lorsque queryLogging est réglé sur Log.
  • Suivez le principe des privilèges minimum : lors de la configuration des règles de transfert DNS, autorisez uniquement l’accès aux serveurs et domaines DNS requis.
  • Test avant le déploiement de production : testez toujours la configuration LocalDNS dans un environnement hors production avant de le déployer sur des clusters de production.
  • Utilisez l’infrastructure en tant que code (IaC) : stockez votre fichier localdnsconfig.json dans votre référentiel d’infrastructure et incluez-le dans vos modèles de déploiement AKS.
  • Configuration réseau pour le transfert TCP : lorsque vous utilisez TCP pour le transfert DNS vers VnetDNS, assurez-vous que vos groupes de sécurité réseau (NSG), vos pare-feu ou appliances virtuelles réseau (NVA) ne bloquent pas le trafic TCP entre les serveurs CoreDNS/LocalDNS et VnetDNS.
  • Évitez d’activer NodeLocal DNSCache et LocalDNS : il n’est pas recommandé d’activer à la fois le DNSCache NodeLocal Kubernetes en amont et LocalDNS dans votre pool de nœuds. Bien qu’AKS ne bloque pas cette configuration, tout le trafic DNS est acheminé via LocalDNS, ce qui peut entraîner un comportement inattendu ou des avantages réduits de NodeLocal DNSCache.
  • N’imposez pas de limite de connexion TCP sur le serveur DNS personnalisé en amont avant d’activer LocalDNS : lorsque vous activez LocalDNS sur un pool de nœuds, chaque nœud ouvre des connexions TCP de longue durée à partir de son proxy DNS local vers le programme de résolution en amont, au lieu des échanges UDP courts utilisés précédemment. Si votre serveur DNS personnalisé (tel que BIND, Unbound, Windows DNS ou une appliance tierce) est configuré avec une limite fixe sur les connexions clientES TCP simultanées, ou si vous avez ajusté cette limite en fonction du trafic pré-LocalDNS, les nouvelles connexions TCP à partir de LocalDNS peuvent être rejetées, ce qui provoque des échecs de résolution DNS au niveau du cluster. Conservez toute limite de connexions TCP à une valeur suffisamment élevée avant d’activer LocalDNS, validez le nombre de connexions TCP en régime permanent sur vos nœuds AKS après l’activation, puis n’ajustez la limite qu’ensuite, en prévoyant une marge pour la montée en charge des nœuds, les mises à niveau et les réinitialisations d’image.

Prerequisites

Les clusters automatiques AKS incluent localDNS préconfigurés. Les prérequis de cette section s’appliquent principalement lorsque vous activez ou personnalisez le comportement LocalDNS, qui est le plus courant dans les scénarios de personnalisation AKS Standard et avancés.

  • Vous devez disposer d’un cluster AKS existant avec Kubernetes versions 1.31 et ultérieures pour utiliser LocalDNS. Si vous avez besoin d’un cluster AKS, vous pouvez en créer un à l’aide de Azure CLI, Azure PowerShell ou du portail Azure.
  • Cet article nécessite Azure CLI version 2.80.0 et ultérieure. Si vous utilisez Azure Cloud Shell, la dernière version est déjà installée.
  • LocalDNS est pris en charge uniquement sur les pools de nœuds exécutant Azure Linux ou Ubuntu 22.04 et versions ultérieures.
  • La référence SKU de machine virtuelle utilisée pour votre pool de nœuds doit avoir au moins 4 processeurs virtuels (cœurs) pour prendre en charge LocalDNS.
  • LocalDNS n’est pas compatible avec les stratégies de filtre de noms de domaine complets (FQDN) appliquées dans Advanced Container Networking Services (ACNS).

Activer ou personnaliser LocalDNS sur un cluster AKS

Vous configurez LocalDNS au niveau du pool de nœuds dans AKS, afin de pouvoir adapter le comportement par charge de travail et environnement.

Dans AKS Automatic, LocalDNS est déjà préconfiguré. Cette section est donc principalement destinée à la personnalisation.

Dans AKS Standard, utilisez cette section pour activer et configurer LocalDNS.

Activer LocalDNS sur un pool de nœuds

Remarque

Si vous utilisez l’approvisionnement automatique de nœud (NAP), consultez la configuration localDNS pour obtenir des instructions sur l’activation de LocalDNS avec NAP.

Cette étape s’applique généralement à AKS Standard. AKS Automatic inclut déjà localDNS préconfiguré.

Pour activer LocalDNS lors de la création du pool de nœuds, utilisez la commande suivante avec votre fichier de configuration personnalisé :

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

Pour activer LocalDNS sur un pool de nœuds existant, utilisez la commande suivante avec votre fichier de configuration personnalisé :

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

Important

L’activation de LocalDNS sur un pool de nœuds lance une opération de réinitialisation sur tous les nœuds de ce pool. Ce processus peut entraîner une interruption temporaire des charges de travail en cours d’exécution et peut entraîner un temps d’arrêt de l’application s’il n’est pas correctement géré. Vous devez planifier les interruptions de service potentielles et vous assurer que les applications sont configurées pour la haute disponibilité ou disposer de budgets d’interruption appropriés avant d’activer ce paramètre.

Désactiver LocalDNS sur un pool de nœuds

Remarque

Si vous utilisez l’approvisionnement automatique de nœud (NAP), consultez la configuration localDNS pour obtenir des instructions sur la désactivation de LocalDNS avec NAP.

La désactivation de LocalDNS est une opération avancée et n’est généralement pas recommandée pour les valeurs par défaut de production automatique AKS, sauf si vous avez une exception validée.

Pour désactiver LocalDNS pour un pool de nœuds, vous devez mettre à jour votre fichier localdnsconfig.json en configurant la propriété mode sur Disabled. Cette modification indique à AKS de désactiver le proxy DNS local sur tous les nœuds du pool spécifié, en rétablissant la résolution DNS par défaut. Après avoir mis à jour le fichier de configuration, appliquez-le au pool de nœuds à l’aide de la Azure CLI pour vous assurer que la modification prend effet.

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

Vérifier l’opération LocalDNS

Dans AKS Automatic, la vérification confirme que la base de référence LocalDNS préconfigurée est active pour vos charges de travail. Dans AKS Standard, la vérification confirme votre déploiement LocalDNS.

Une fois localDNS activé, vous pouvez vérifier son opération en exécutant des requêtes DNS à partir de pods dans le pool de nœuds spécifié et en inspectant le SERVER champ dans les réponses pour confirmer que les adresses LocalDNS sont retournées (169.254.10.10 ou 169.254.10.11).

Avant d’exécuter les étapes de validation, vérifiez que les conditions suivantes sont remplies :

  1. Vous avez installé et configuré kubectl pour accéder à votre cluster AKS.
  2. Votre compte d’utilisateur dispose des autorisations suffisantes pour créer et exécuter des pods.
  3. Le pool de nœuds dans lequel vous souhaitez valider LocalDNS est dans un état Prêt .
  4. L’image BusyBox (busybox:1.28) est accessible à partir de vos nœuds de cluster.

Exemple de validation :

  1. Créez un pod de débogage dans le pool de nœuds où LocalDNS est activé :

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

  2. Une fois le pod en cours d’exécution, exécutez la commande suivante pour vérifier la résolution DNS :

    kubectl exec -it dnstest -- nslookup kubernetes.default

    Vérifiez la sortie. Si localDNS fonctionne correctement, vous devez voir une réponse avec l’adresse du serveur 169.254.10.10 ou 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

Configurer DNS local

Remarque

Si vous utilisez l’approvisionnement automatique de nœud (NAP), consultez la configuration localDNS pour obtenir des instructions sur la configuration de LocalDNS avec NAP.

LocalDNS utilise un fichier de configuration JSON localdnsconfig.json pour définir le comportement de résolution DNS pour chaque pool de nœuds. Ce fichier vous permet de spécifier des modes opérationnels, des blocs de serveur pour différents domaines DNS et des paramètres de plug-in tels que la mise en cache, le transfert et la journalisation.

Configuration localDNS par défaut

Dans AKS Automatic, LocalDNS est préconfiguré. Utilisez la personnalisation uniquement lorsque vous avez une exigence spécifique.

Dans AKS Standard, cette configuration par défaut est un bon point de départ.

Lors de la personnalisation de LocalDNS, utilisez le format de configuration suivant comme modèle. Vous pouvez définir des blocs de serveur supplémentaires si nécessaire, mais l’ajout de propriétés de niveau supérieur non standard ou non prises en charge à la configuration entraîne des échecs de validation.

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

Configurer le mode pour LocalDNS

LocalDNS peut être activé dans trois modes possibles qui définissent l’étendue de l’application de LocalDNS pour la charge de travail :

  • Required: LocalDNS est appliqué au pool de nœuds si tous les prérequis sont satisfaits. Si la configuration requise n’est pas remplie, le déploiement échoue.
  • Disabled: désactive la fonctionnalité DNS locale, de sorte que les requêtes DNS ne sont pas résolues localement sur le nœud.
  • Preferred: AKS valide que votre configuration LocalDNS est correcte de manière syntactique, mais n’active pas LocalDNS sur les nœuds. Toutefois, l’application de ce mode déclenche toujours une opération de reimageage de nœud. Vous pouvez donc tester votre configuration pour les erreurs sans affecter la résolution DNS dans votre cluster.

Pour les charges de travail de production dans AKS Automatic, conservez le comportement LocalDNS préconfiguré, sauf si vous avez besoin de personnaliser.

Le tableau suivant récapitule le comportement LocalDNS pour chaque mode et version de Kubernetes :

Version de Kubernetes Préféré Obligatoire Handicapé
Antérieure à la version 1.31 Non prise en charge Non prise en charge Non prise en charge
1.31 et versions ultérieures Configuration validée, non installée Installé et appliqué Configuration validée, non installée

Remarque

Le Preferred mode sert actuellement de mode de validation uniquement. Dans une prochaine version de Kubernetes, ce mode passera à l’activation automatique de LocalDNS. Pour les déploiements de production aujourd’hui, utilisez Required le mode pour activer LocalDNS.

Blocs de serveur pour LocalDNS

La configuration par défaut s’applique aux requêtes provenant de pods à l’aide de dnsPolicy:default (sous vnetDNSOverrides) et de pods à l’aide de dnsPolicy:ClusterFirst (sous kubeDNSOverrides). Dans chacun d’eux, il existe deux blocs de serveur par défaut définis : . et cluster.local.

  • .représente toutes les requêtes DNS externes provenant de pods qui tentent de résoudre les domaines publics ou non de cluster (par exemple). microsoft.com
  • cluster.local représente toutes les requêtes de découverte de service Kubernetes internes à partir de pods qui tentent de résoudre les noms de service Kubernetes ou les ressources de cluster internes. Ces requêtes sont routées via CoreDNS pour la résolution au sein du cluster.

Plug-ins pris en charge pour la configuration localDNS

Plug-in Descriptif Par défaut Entrées autorisées
queryLogging Définissez le niveau de journalisation pour les requêtes DNS. Error Error Log
protocol Définit le protocole utilisé pour les requêtes DNS (préférence UDP/TCP). ForceTCP pour cluster.local, sinon PreferUDP PreferUDP ForceTCP
forwardDestination Spécifie le serveur DNS vers lequel transférer des requêtes. ClusterCoreDNS pour le trafic cluster.local et kubeDNS, sinon VnetDNS VnetDNS ClusterCoreDNS
forwardPolicy Détermine la stratégie à utiliser lors de la sélection du serveur DNS en amont. Sequential Random RoundRobin Sequential
maxConcurrent Nombre maximal de requêtes DNS simultanées gérées par LocalDNS. 1000 Nombre entier
cacheDurationInSeconds Durée de vie maximale (durée de vie) en secondes pour laquelle les réponses DNS sont mises en cache. 3600 Nombre entier
serveStaleDurationInSeconds Durée (en secondes) pour traiter les réponses DNS obsolètes si l’amont n’est pas disponible. 3600 Nombre entier
serveStale Stratégie pour fournir des réponses DNS obsolètes pendant des pannes en amont. Immediate Verify Immediate Disabled

Règles de validation de configuration

Lors de la création de votre configuration LocalDNS, tenez compte de ces règles de validation pour éviter les échecs de déploiement :

  • Restrictions de zone racine (.) : Sous vnetDNSOverrides, la forwardDestination zone racine ne peut pas être ClusterCoreDNS.
  • Restrictions de zone cluster.local : sous les deux vnetDNSOverrides et kubeDNSOverrides, la forwardDestination de cluster.local ne peut pas être VnetDNS.
  • Protocole et compatibilité serveStale : Quand protocol est défini sur ForceTCP, serveStale ne peut pas être défini sur Verify. Utilisez Immediate à la place.

Remarque

Ces règles de validation sont appliquées pendant le déploiement de la configuration. Le fait de les violer entraîne l’échec de la validation de la configuration LocalDNS.

Créer un bloc de serveur personnalisé dans LocalDNS

CoreDNS correspond aux requêtes à un bloc de serveur spécifique en fonction d’une correspondance exacte pour le domaine interrogé et non sur les correspondances partielles. Si vous avez besoin de blocs de serveur personnalisés, vous pouvez les ajouter à votre configuration LocalDNS en créant un fichier appelé localdnsconfig.json avec les configurations ajoutées.

Par exemple, si vous avez des besoins DNS spécifiques lors de l’accès à microsoft.com, vous pouvez utiliser le bloc de serveur suivant :

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

Surveiller LocalDNS

Dans AKS Automatic, LocalDNS est préconfiguré. Commencez par la validation de la ligne de base et surveillez le comportement avant d’appliquer le réglage personnalisé.

LocalDNS expose les métriques Prometheus que vous pouvez utiliser pour la surveillance et les alertes. Les métriques sont exposées sur le port 9253 de l’adresse IP du nœud.

Exemple de configuration de collecte pour le module complémentaire Azure Managed Prometheus en tant que 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']

Résoudre les problèmes de localDNS

Les requêtes DNS vers des domaines spécifiques échouent

Si les requêtes DNS vers des domaines spécifiques échouent après l’activation de LocalDNS :

  1. Vérifiez si vous avez des substitutions spécifiques au domaine dans votre localdnsconfig.json qui pourraient être mal configurées.
  2. Essayez temporairement de supprimer des remplacements spécifiques au domaine et d’utiliser uniquement la configuration par défaut . .
  3. Vérifiez si le problème se produit avec UDP (User Datagram Protocol) et TCP (Transmission Control Protocol) en ajustant le protocol paramètre.

Mettre à jour les serveurs DNS de réseau virtuel pour LocalDNS

Lorsque vous mettez à jour des serveurs DNS personnalisés directement dans la configuration du réseau virtuel (à l'aide du portail Azure ou de l'interface CLI), les nœuds de cluster AKS n'appliquent pas automatiquement ces modifications. La mise à jour des paramètres DNS au niveau du réseau virtuel informe uniquement le fournisseur de ressources réseau (NRP), mais n’informe pas le fournisseur de ressources AKS. Par conséquent, les nœuds AKS continuent d’utiliser les paramètres de serveur DNS précédents jusqu’à ce que vous preniez d’autres mesures.

Pour vous assurer que les nœuds AKS récupèrent les nouveaux paramètres du serveur DNS de réseau virtuel :

  1. Mettez à jour la configuration DNS du réseau virtuel à l’aide du portail Azure ou des API si nécessaire.

  2. Utilisez le fournisseur de ressources AKS pour réimager le pool de nœuds, en veillant à ce que les paramètres DNS mis à jour soient appliqués et conservés :

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

Ce processus garantit que le fournisseur de ressources AKS est conscient des modifications DNS et les applique à tous les nœuds du pool de nœuds.

Mettre à jour les stratégies réseau Cilium pour autoriser la résolution DNS avec LocalDNS

Si vous déployez des stratégies réseau Cilium dans votre cluster, vous devez explicitement autoriser l'egress des pods vers les adresses IP LocalDNS.

Les stratégies réseau appliquent un modèle de refus par défaut pour les destinations qui ne sont pas spécifiées. Par conséquent, le trafic DNS vers LocalDNS est bloqué, sauf s’il est explicitement autorisé.

  • Sur Azure CNI alimenté par Cilium <=v1.16 avec k8s <=1.31, cela peut être obtenu par une stratégie basée sur CIDR.
  • Sur Azure CNI alimenté par Cilium >=v1.17 avec K8s >=1.32, il est possible d’utiliser une stratégie réseau Cilium autorisant le trafic sortant vers les entités hôtes.

La stratégie réseau Cilium suivante peut être utilisée pour autoriser le trafic entre toutes les versions :

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

Contenu connexe

  • Last updated on