Résolution DNS dans Azure Kubernetes Service (AKS)

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

La résolution DNS (Domain Name System) est un composant essentiel dans Azure Kubernetes Service (AKS), ce qui permet aux pods et aux services de communiquer à l’aide de noms lisibles par l’homme au lieu d’adresses IP. AKS fournit des services DNS intégrés pour garantir une résolution de noms transparente pour les ressources de cluster internes et les points de terminaison externes. Comprendre le fonctionnement du DNS dans AKS aide les opérateurs de cluster et les développeurs à garantir une connectivité fiable, optimiser les performances et résoudre efficacement les problèmes de mise en réseau.

AKS Automatic est l’option par défaut recommandée, prête pour la production, pour la plupart des charges de travail sur AKS. Les clusters automatiques AKS sont préconfigurés avec LocalDNS pour améliorer les performances DNS, réduire la pression conntrack et augmenter la résilience sans nécessiter de configuration supplémentaire.

Remarque

À compter de Kubernetes 1.37, AKS Standard applique le Preferred mode LocalDNS par défaut aux pools de nœuds éligibles qui n’ont pas de profil LocalDNS configuré explicitement. En Preferred mode, AKS active LocalDNS uniquement si le pool de nœuds et le cluster passent les vérifications de compatibilité requises. Si les vérifications échouent, LocalDNS reste désactivé. Les profils configurés explicitement sont prioritaires sur cette valeur par défaut. Par conséquent, un pool de nœuds défini Disabled de manière explicite reste désactivé. Pour empêcher l’activation de LocalDNS, définissez explicitement le mode LocalDNS sur Désactivé. Pour obtenir des instructions, consultez Désactiver LocalDNS sur un pool de nœuds.

Pour plus d’informations sur AKS Automatic, consultez Présentation d’AKS Automatic ?

CoreDNS dans Azure Kubernetes Service

CoreDNS est le service DNS par défaut dans AKS. Elle fournit la résolution de noms interne et la découverte de services pour les charges de travail exécutées dans le cluster. Il s’exécute sous la forme d’un ensemble de pods dans le namespace kube-system et est étroitement intégré au réseau Kubernetes.

Lorsqu’un pod dans AKS émet une requête DNS, par exemple la résolution du nom d’un autre service, la requête est envoyée aux pods CoreDNS. Ces pods traitent la requête et retournent l’adresse IP appropriée ou transfèrent la requête à un serveur DNS en amont pour les domaines externes.

Cette architecture garantit un équilibre entre la flexibilité et la sécurité opérationnelle dans un environnement managé. Pour plus d’informations sur la personnalisation de CoreDNS dans AKS, reportez-vous au guide de personnalisation CoreDNS.

Lorsque LocalDNS est actif, le chemin de résolution dépend du dnsPolicy pod (Default ou ClusterFirst) et de la configuration du bloc de serveur LocalDNS. Par exemple, lorsqu’un pod utilise dnsPolicy: Default, les requêtes DNS externes prennent le chemin suivant :

Workload -> LocalDNS -> upstream DNS server

LocalDNS s’exécute en tant qu’unité systemd sur le nœud, de sorte qu’il reçoit la requête avant CoreDNS. cluster.local les requêtes sont transférées à CoreDNS, et les requêtes externes sont transférées vers CoreDNS ou directement vers le serveur DNS du réseau virtuel (VNet). Pour connaître le comportement de transfert exact pour chaque stratégie DNS et la configuration par défaut, consultez les blocs serveur pour LocalDNS.

Les serveurs DNS de réseau virtuel personnalisés doivent accepter à la fois les requêtes UDP et TCP DNS à partir de nœuds AKS. Avec PreferUDP, LocalDNS effectue une nouvelle tentative via TCP lorsqu’une réponse UDP est tronquée.

Pour obtenir des informations sur le projet CoreDNS, consultez la page du projet en amont CoreDNS.

LocalDNS dans Azure Kubernetes Service

Remarque

Cet article fournit une vue d’ensemble de ce que LocalDNS est et de ses avantages dans AKS.

Pour AKS Automatic, LocalDNS est préconfiguré.

Pour AKS Standard, consultez le guide pratique localDNS pour obtenir des conseils sur l’activation et la configuration de LocalDNS.

Aperçu

LocalDNS est une fonctionnalité avancée dans Azure Kubernetes Service (AKS) qui déploie un proxy DNS (Domain Name System) sur chaque nœud pour fournir une résolution DNS hautement résiliente et à faible latence. En gérant les requêtes DNS localement, ce proxy réduit le trafic vers les pods de module complémentaire CoreDNS, ce qui améliore la fiabilité et les performances DNS globales dans le cluster. LocalDNS est particulièrement utile dans les grands clusters ou environnements avec des volumes de requêtes DNS élevés, où la résolution DNS centralisée peut devenir un goulot d’étranglement.

Lorsque LocalDNS est activé, AKS déploie un cache DNS local en tant que systemd service sur chaque nœud. Les pods sur le nœud envoient leurs requêtes DNS à ce cache local, ce qui permet une résolution plus rapide en réduisant les tronçons réseau. Cette approche réduit conntrack également l’utilisation des tables, ce qui réduit le risque d’épuisement des tables. En outre, si le DNS en amont devient indisponible, LocalDNS peut continuer à traiter les réponses mises en cache pendant une durée configurable, ce qui permet de maintenir la connectivité des pods et la fiabilité du service.

Diagramme montrant l’architecture LocalDNS.

LocalDNS et AKS Automatic

AkS Automatic préconfigure LocalDNS dans le cadre de ses valeurs par défaut prêtes pour la production. Vous n’avez pas besoin d’exécuter une commande d’activation distincte sur des clusters automatiques AKS.

Utilisez cet article pour comprendre le fonctionnement de LocalDNS et pourquoi il améliore le comportement DNS pour les charges de travail AKS. Si vous avez besoin des étapes d’activation et de configuration pour AKS Standard, utilisez le guide pratique localDNS.

Fonctionnalités clés

  • Latence de résolution DNS réduite : chaque nœud AKS exécute un service LocalDNS systemd . Les charges de travail exécutées sur le nœud envoient des requêtes DNS à ce service, qui les résolvent localement, ce qui réduit les tronçons réseau et accélère les recherches DNS.
  • Comportement DNS personnalisable : Utilisez kubeDNSOverrides et vnetDNSOverrides contrôlez le comportement DNS dans le cluster.
  • Évitez les courses conntrack et l’épuisement des tables conntrack : les pods envoient des requêtes DNS au service LocalDNS sur le même nœud sans créer de nouvelles conntrack entrées de table. Ignorer le suivi des connexions permet de réduire les courses conntrack et évite les entrées DNS UDP (User Datagram Protocol) de remplir des tables conntrack. Cette optimisation empêche la suppression et le rejet des connexions causées par l’épuisement des tables conntrack et les conditions de concurrence.
  • Connexion mise à niveau vers TCP : la connexion du localdns cache au service CoreDNS du cluster utilise le protocole TCP (Transmission Control Protocol). TCP permet le rééquilibrage des connexions et supprime les conntrack entrées de table lorsque le serveur ferme la connexion (contrairement aux connexions UDP, qui ont un délai d’expiration par défaut de 30 secondes). Les applications n’ont pas besoin de modifications, car le service écoute toujours le localdns trafic UDP.
  • Mise en cache : vous pouvez configurer le plugin de cache LocalDNS avec serveStale et les paramètres de durée de vie (TTL). Définissez les paramètres serveStale, serveStaleDurationInSeconds et cacheDurationInSeconds pour assurer la résilience DNS, même en cas de panne du DNS en amont.
  • Contrôle de protocole : définissez le protocole de requête DNS préféré, tel que PreferUDP ou ForceTCP, pour chaque domaine. PreferUDP n’est pas une instruction pour utiliser UDP exclusivement. Le programme de résolution peut réessayer ou revenir sur TCP. Par conséquent, les serveurs DNS personnalisés et les contrôles réseau en amont doivent prendre en charge le port UDP et TCP 53.

Autres avantages et considérations

Avantages Considérations
Meilleure scalabilité : réduit la charge sur les pods CoreDNS centralisés Surcharge minimale des ressources : utilise une petite quantité d’UC et de mémoire sur chaque nœud
Intégration transparente : ne nécessite pas de modifications apportées aux connexions d’application existantes Modifications de configuration : les mises à jour nécessitent des mises à niveau d’image de nœud, ce qui peut entraîner des interruptions temporaires
Bloquer les domaines de recherche non valides : empêche les requêtes DNS non valides au niveau du nœud Planification de la disponibilité : Teams utilisant AKS Standard doit évaluer si les performances et la résilience DNS justifient l’activation de LocalDNS

Comportement AKS Automatic et AKS Standard

Mode de cluster Comportement localDNS
AKS Automatic Préconfiguré
AKS Standard, Kubernetes 1.31 à 1.36 Configuré explicitement par pool de nœuds
AKS Standard, Kubernetes 1.37 et versions ultérieures Par défaut, les pools de nœuds admissibles sont définis sur Preferred lorsqu’aucun profil LocalDNS explicite n’est défini. LocalDNS est activé uniquement lorsque les vérifications de compatibilité passent. Les profils explicites, y compris Disabled, sont conservés.

En utilisant LocalDNS, vous bénéficiez d’une résolution DNS plus rapide et plus fiable pour vos charges de travail, réduisez le risque de pannes liées au DNS et contrôlez davantage le trafic DNS dans votre environnement AKS.

Contenu connexe

  • Dernière mise à jour :