Personnaliser CoreDNS avec Azure Kubernetes Service

Article
10/31/2024

AKS (Azure Kubernetes Service) utilise le projet CoreDNS pour la gestion et la résolution DNS de cluster avec tous les clusters de version 1.12.x et supérieures. Pour plus d’informations sur la personnalisation de CoreDNS et sur Kubernetes, consultez la documentation officielle en amont.

AKS étant un service managé, vous ne pouvez pas modifier la configuration principale pour CoreDNS (fichier CoreFile). Au lieu de cela, vous utilisez un fichier ConfigMap Kubernetes pour remplacer les paramètres par défaut. Pour afficher les ConfigMaps CoreDNS AKS par défaut, utilisez la commande kubectl get configmaps --namespace=kube-system coredns -o yaml.

Cet article vous montre comment utiliser les ConfigMaps pour les options de personnalisation de base de CoreDNS dans AKS. Cette approche diffère de la configuration de CoreDNS dans d’autres contextes comme l’utilisation de CoreFile.

Notes

Auparavant, kube-dns était utilisé pour la gestion et la résolution DNS du cluster, mais il est maintenant déconseillé. kube-dns proposait différentes options de personnalisation via une carte de configuration Kubernetes. CoreDNS n’est pas rétrocompatible avec kube-dns. Les personnalisations que vous avez utilisées précédemment doivent être mises à jour pour CoreDNS.

Avant de commencer

Cet article suppose que vous avez un cluster AKS existant. Si vous avez besoin d’un cluster AKS, vous pouvez en créer un en utilisant Azure CLI, Azure PowerShell ou le Portail Azure.
Vérifiez la version de CoreDNS que vous exécutez. Les valeurs de configuration peuvent changer d’une version à l’autre.
Quand vous créez des configurations semblables aux exemples ci-dessous, les noms dans la section data doivent se terminer par .server ou .override. La convention d’affectation de noms est définie dans la ConfigMap CoreDNS AKS par défaut, que vous pouvez voir à l’aide de la commande kubectl get configmaps --namespace=kube-system coredns -o yaml.

Prise en charge des plug-ins

Tous les plug-ins CoreDNS intégrés sont pris en charge. Aucun module complémentaire/plug-in tiers n’est pris en charge.

Réécriture DNS

Vous pouvez personnaliser CoreDNS avec AKS pour effectuer des réécritures de noms DNS à la volée.

Créez un fichier nommé corednsms.yaml et collez l’exemple de configuration suivant. Veillez à remplacer <domain to be rewritten> par votre propre nom de domaine complet.

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
    }

Important

Si vous redirigez vers un serveur DNS, tel que l’adresse IP du service CoreDNS, ce serveur DNS doit être en mesure de résoudre le nom de domaine réécrit.

Créez la ConfigMap à l’aide de la commande kubectl apply configmap et spécifiez le nom de votre manifeste YAML.
```
kubectl apply -f corednsms.yaml
```
Vérifiez que les personnalisations ont été appliquées à l’aide de kubectl get configmaps et spécifiez votre ConfigMap coredns-custom.
```
kubectl get configmaps --namespace=kube-system coredns-custom -o yaml
```
Pour recharger le ConfigMap et autoriser Kubernetes Scheduler à redémarrer CoreDNS sans temps d’arrêt, effectuez un redémarrage continu à l’aide de kubectl rollout restart.
```
kubectl -n kube-system rollout restart deployment coredns
```

Serveur de transfert personnalisé

Si vous avez besoin de spécifier un serveur de transfert pour votre trafic réseau, vous pouvez créer un ConfigMap pour personnaliser le DNS.

Créez un fichier nommé corednsms.yaml et collez l’exemple de configuration suivant. Veillez à remplacer le nom forward et l’adresse par les valeurs de votre propre environnement.

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
    }

Créez la ConfigMap à l’aide de la commande kubectl apply configmap et spécifiez le nom de votre manifeste YAML.
```
kubectl apply -f corednsms.yaml
```
Pour recharger le ConfigMap et autoriser Kubernetes Scheduler à redémarrer CoreDNS sans temps d’arrêt, effectuez un redémarrage continu à l’aide de kubectl rollout restart.
```
kubectl -n kube-system rollout restart deployment coredns
```

Utiliser des domaines personnalisés

Vous pouvez décider de configurer des domaines personnalisés qui ne peuvent être résolus qu’en interne. Par exemple, vous pouvez souhaiter résoudre le domaine personnalisé puglife.local, qui n’est pas un domaine de niveau supérieur valide. Sans un ConfigMap de domaine personnalisé, le cluster AKS ne peut pas résoudre l’adresse.

Créez un fichier nommé corednsms.yaml et collez l’exemple de configuration suivant. Veillez à mettre à jour le domaine personnalisé et l’adresse IP avec les valeurs de votre propre environnement.

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
    }

Créez la ConfigMap à l’aide de la commande kubectl apply configmap et spécifiez le nom de votre manifeste YAML.
```
kubectl apply -f corednsms.yaml
```
Pour recharger le ConfigMap et autoriser Kubernetes Scheduler à redémarrer CoreDNS sans temps d’arrêt, effectuez un redémarrage continu à l’aide de kubectl rollout restart.
```
kubectl -n kube-system rollout restart deployment coredns 
```

Domaines de stub

CoreDNS peut aussi être utilisé pour configurer des domaines de stub.

Créez un fichier nommé corednsms.yaml et collez l’exemple de configuration suivant. Veillez à mettre à jour les domaines personnalisés et les adresses IP avec les valeurs de votre propre environnement.

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
    }

Créez la ConfigMap à l’aide de la commande kubectl apply configmap et spécifiez le nom de votre manifeste YAML.
```
kubectl apply -f corednsms.yaml
```
Pour recharger le ConfigMap et autoriser Kubernetes Scheduler à redémarrer CoreDNS sans temps d’arrêt, effectuez un redémarrage continu à l’aide de kubectl rollout restart.
```
kubectl -n kube-system rollout restart deployment coredns
```

Plug-in Hosts

Tous les plug-ins intégrés sont pris en charge, de sorte que le plug-in d’hôtes CoreDNS est également disponible pour la personnalisation de /etc/hosts.

Créez un fichier nommé corednsms.yaml et collez l’exemple de configuration suivant. Veillez à mettre à jour les adresses IP et les noms d’hôte avec les valeurs de votre propre environnement.

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
          }

Créez la ConfigMap à l’aide de la commande kubectl apply configmap et spécifiez le nom de votre manifeste YAML.
```
kubectl apply -f corednsms.yaml
```
Pour recharger le ConfigMap et autoriser Kubernetes Scheduler à redémarrer CoreDNS sans temps d’arrêt, effectuez un redémarrage continu à l’aide de kubectl rollout restart.
```
kubectl -n kube-system rollout restart deployment coredns
```

Complétions de domaine de recherche non valides pour internal.cloudapp.net et reddog.microsoft.com

Azure DNS configure un domaine de recherche par défaut <vnetId>.<region>.internal.cloudapp.net dans des réseaux virtuels avec Azure DNS, et un stub non fonctionnel reddog.microsoft.com dans des réseaux virtuels avec des serveurs DNS personnalisés (consultez la documentation sur la résolution de noms pour les ressources pour plus d’informations). Kubernetes configure les paramètres DNS des pods avec ndots: 5 pour prendre en charge de manière appropriée la résolution du nom d’hôte du service de cluster. Ces deux configurations se combinent pour aboutir à des requêtes de complétion de domaine de recherche non valides qui ne sont jamais envoyées aux serveurs de noms en amont quand le système traite la liste de recherche de domaine. Ces requêtes non valides entraînent des retards de résolution de noms et peuvent placer une charge supplémentaire sur les serveurs DNS en amont.

À compter de la version AKS v20241025, AKS configure CoreDNS pour répondre avec NXDOMAIN dans les deux cas suivants afin d’empêcher le transfert de ces requêtes de complétion de domaine de recherche non valides au DNS en amont :

Toute requête concernant le domaine racine ou un sous-domaine de reddog.microsoft.com.
Toute requête concernant un sous-domaine de internal.cloudapp.net qui a sept étiquettes ou plus dans le nom de domaine.
- Cette configuration permet à la résolution des machines virtuelles par nom d’hôte de réussir. Par exemple, CoreDNS envoie aks12345.myvnetid.myregion.internal.cloudapp.net (6 étiquettes) à Azure DNS, mais rejette mcr.microsoft.com.myvnetid.myregion.internal.cloudapp.net (8 étiquettes)

Ce bloc est implémenté dans le bloc de serveur par défaut dans le Corefile du cluster. Si nécessaire, cette configuration de rejet peut être désactivée en créant des blocs de serveur personnalisés pour le domaine approprié avec un plug-in de transfert activé :

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
       }

Créez la ConfigMap à l’aide de la commande kubectl apply configmap et spécifiez le nom de votre manifeste YAML.
```
kubectl apply -f corednsms.yaml
```
Pour recharger le ConfigMap et autoriser Kubernetes Scheduler à redémarrer CoreDNS sans temps d’arrêt, effectuez un redémarrage continu à l’aide de kubectl rollout restart.
```
kubectl -n kube-system rollout restart deployment coredns
```

Résolution des problèmes

Pour connaître les étapes de dépannage générales de CoreDNS, telles que la vérification des points de terminaison ou de la résolution, consultez Déboguer la résolution DNS.

Configurer la mise à l’échelle des pods CoreDNS

Les pics soudains de trafic DNS au sein des clusters AKS sont fréquents en raison de l’élasticité qu’AKS fournit pour les charges de travail. Ces pics peuvent entraîner une augmentation de la consommation de mémoire par les pods CoreDNS. Dans certains cas, cette augmentation de la consommation de mémoire peut entraîner des problèmes Out of memory. Pour préempter ce problème, les clusters AKS mettent automatiquement à l’échelle les pods CoreDNS pour réduire l’utilisation de la mémoire par pod. Les paramètres par défaut de cette logique de mise à l’échelle automatique sont stockés dans le ConfigMap coredns-autoscaler. Toutefois, vous pouvez observer que la mise à l’échelle automatique par défaut des pods CoreDNS n’est pas toujours assez agressive pour éviter les problèmes Out of memory pour vos pods CoreDNS. Dans ce cas, vous pouvez modifier directement le ConfigMap coredns-autoscaler. Notez que le simple fait d’augmenter le nombre de pods CoreDNS sans traiter la cause racine du problème Out of memory ne peut fournir qu’un correctif temporaire. S’il n’y a pas suffisamment de mémoire disponible sur les nœuds sur lesquels les pods CoreDNS s’exécutent, l’augmentation du nombre de pods CoreDNS n’aidera pas. Vous devrez peut-être examiner plus en détail et implémenter des solutions appropriées, telles que l’optimisation de l’utilisation des ressources, l’ajustement des demandes et des limites de ressources ou l’ajout de mémoire supplémentaire aux nœuds.

CoreDNS utilise la mise à l’échelle automatique proportionnelle de cluster horizontale pour la mise à l’échelle automatique des pods. Le ConfigMap coredns-autoscaler peut être modifié pour configurer la logique de mise à l’échelle pour le nombre de pods CoreDNS. Le ConfigMap coredns-autoscaler prend actuellement en charge deux valeurs de clé ConfigMap différentes : linear et ladder qui correspondent à deux modes de contrôle pris en charge. Le contrôleur linear génère un nombre de réplicas dans la plage [min,max] équivalent à max( ceil( cores * 1/coresPerReplica ) , ceil( nodes * 1/nodesPerReplica ) ). Le contrôleur ladder calcule le nombre de réplicas en consultant deux fonctions d’étape différentes, l’une pour la mise à l’échelle du cœur et l’autre pour la mise à l’échelle des nœuds, ce qui donne le maximum des deux valeurs de réplica. Pour plus d’informations sur les modes de contrôle et le format ConfigMap, consultez la documentation en amont.

Important

Un minimum de deux réplicas de pod CoreDNS par cluster est recommandé. La configuration d’un minimum d’un réplica de pod CoreDNS peut entraîner des défaillances pendant les opérations nécessitant un drainage de nœud, comme les opérations de mise à niveau du cluster.

Pour récupérer le ConfigMap coredns-autoscaler, vous pouvez exécuter la commande kubectl get configmap coredns-autoscaler -n kube-system -o yaml qui retourne le code suivant :

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

Activer la journalisation des requêtes DNS

Ajoutez la configuration suivante à votre ConfigMap coredns-custom :

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

Appliquez les modifications de configuration et forcez CoreDNS à recharger la ConfigMap à l’aide des commandes suivantes :

# Apply configuration changes
kubectl apply -f corednsms.yaml

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

Affichez la journalisation du débogage CoreDNS à l’aide de la commande kubectl logs.
```
kubectl logs --namespace kube-system -l k8s-app=kube-dns
```

Étapes suivantes

Cet article vous a présenté quelques exemples de scénarios de personnalisation de CoreDNS. Pour obtenir des informations sur le projet CoreDNS, consultez la page du projet en amont CoreDNS.

Pour en savoir plus sur les principaux concepts de réseau, consultez Concepts de réseau pour les applications dans AKS.

Partager via