Utiliser kube-dns

Standard

---

Cette page explique comment Google Kubernetes Engine (GKE) met en œuvre la découverte des services à l'aide de kube-dns, le fournisseur DNS par défaut des clusters GKE.

Pour les clusters Autopilot, vous ne pouvez pas modifier la configuration kube-dns par défaut.

Architecture

Lorsque vous créez un cluster, GKE déploie automatiquement les pods kube-dns dans l'espace de noms kube-system. Les pods accèdent au déploiement kube-dns via un service correspondant qui regroupe les pods kube-dns et leur attribue une adresse IP unique (ClusterIP). Par défaut, tous les pods d'un cluster utilisent ce service pour résoudre les requêtes DNS. Le schéma suivant illustre la relation entre les pods et le service kube-dns.

kube-dns s'adapte pour répondre aux demandes DNS du cluster. Ce scaling est contrôlé par kube-dns-autoscaler, un pod déployé par défaut dans tous les clusters GKE. kube-dns-autoscaler ajuste le nombre d'instances dupliquées dans le déploiement kube-dns en fonction du nombre de nœuds et de cœurs du cluster.

kube-dns accepte jusqu'à 1 000 points de terminaison par service sans interface graphique.

Configuration du DNS de pod

L'agent kubelet qui s'exécute sur chaque nœud configure le paramètre etc/resolv.conf du pod pour utiliser l'adresse ClusterIP du service kube-dns. L'exemple de configuration suivant montre que l'adresse IP du service kube-dns est 10.0.0.10. Cette adresse IP est différente dans les autres clusters.

nameserver 10.0.0.10
search default.svc.cluster.local svc.cluster.local cluster.local c.my-project-id.internal google.internal
options ndots:5

kube-dns est le serveur de noms primaire pour le domaine du cluster (cluster.local) et il résout les noms externes. Les noms courts qui ne sont pas complets, tels que myservice, sont d'abord complétés par des chemins de recherche locaux.

Remarque : Dans les clusters GKE Autopilot, dans les versions 1.27 et ultérieures, la plage d'adresses IP de service par défaut est une plage gérée par Google :34.118.224.0/20 et le service kube-dns reçoit 34.118.x.10 par défaut (x étant compris dans la plage 224-239).

Ajouter des résolveurs personnalisés aux domaines de simulation

Vous pouvez modifier le fichier ConfigMap de kube-dns afin de définir des domaines de simulation dans une infrastructure DNS au sein de vos clusters.

Les domaines de simulation vous permettent de configurer des résolveurs personnalisés par domaine afin que kube-dns transfère les requêtes DNS à des serveurs DNS spécifiques en amont lors de la résolution de ces domaines.

Remarque : Lorsque vous configurez un résolveur personnalisé pour un domaine de simulation, tel que example.com, kube-dns transfère toutes les requêtes de résolution de noms aux serveurs définis, y compris **example.com et *.example.com

.

L'exemple de fichier manifeste ConfigMap suivant pour kube-dns inclut une configuration stubDomains qui définit des résolveurs personnalisés pour le domaine example.com.

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    addonmanager.kubernetes.io/mode: EnsureExists
  name: kube-dns
  namespace: kube-system
data:
  stubDomains: |
    {
      "example.com": [
        "8.8.8.8",
        "8.8.4.4",
        "1.1.1.1",
        "1.0.0.1"
      ]
    }

Exécutez la commande suivante pour ouvrir un éditeur de texte :

kubectl edit configmap kube-dns -n kube-system

Remplacez le contenu du fichier par le fichier manifeste, puis quittez l'éditeur de texte pour appliquer le fichier manifeste au cluster.

Serveurs de noms en amont

Si vous modifiez le fichier ConfigMap pour que kube-dns inclue upstreamNameservers, kube-dns transfère toutes les requêtes DNS, à l'exception de *.cluster.local, vers ces serveurs. Cela comprend metadata.internal et *.google.internal, qui ne peuvent pas être résolus par le serveur en amont.

Si vous activez la fédération d'identité de charge de travail pour GKE ou toute charge de travail qui repose sur la résolution metadata.internal, pour conserver la résolution de nom *.internal, ajoutez un stubDomain dans le ConfigMap.

data:
  stubDomains: |
    {
      "internal": [
        "169.254.169.254"
      ]
    }
  upstreamNameservers: |
    ["8.8.8.8"]

Problèmes connus

Limite de domaine de recherche

Le nombre de domaines de recherche DNS pour /etc/resolv.conf est limité à 6. Si vous définissez plus de 6 domaines de recherche, l'avertissement suivant s'affiche lorsque vous exécutez la commande kubectl describe pod :

Search Line limits were exceeded, some search paths have been omitted, the applied search line is: default.svc.cluster.local svc.cluster.local cluster.local c.<project ID>.internal google.internal

Cet avertissement est consigné dans Cloud Logging dans la section des journaux de conteneurs.

Pour résoudre ce problème, supprimez les chemins de recherche supplémentaires de la configuration.

Tenir compte de la limite upstreamNameservers

Kubernetes impose une limite de trois valeurs upstreamNameservers au maximum. Si vous définissez plus de trois upstreamNameservers, l'erreur suivante s'affiche dans Cloud Logging dans les journaux de déploiement kube-dns :

Invalid configuration: upstreamNameserver cannot have more than three entries (value was &TypeMeta{Kind:,APIVersion:,}), ignoring update

Dans ce cas, kube-dns se comporte comme s'il n'avait pas configuré upstreamNameservers. Pour résoudre ce problème, supprimez les upstreamNameservers supplémentaires de la configuration.

Limitations de performances avec kube-dns

Si vous rencontrez des problèmes de latence élevée avec les résolutions DNS ou des échecs de résolution DNS avec le fournisseur kube-dns par défaut, cela peut être dû aux raisons suivantes :

• Vous effectuez des résolutions DNS fréquentes dans votre charge de travail
• Vous déployeé une densité de pods plus élevée par nœud.
• Vous exécutez kube-dns sur des VM Spot ou préemptives, ce qui peut entraîner des suppressions inattendues de nœuds et des problèmes de résolution DNS ultérieurs.

Pour améliorer les durées des résolutions DNS, vous pouvez choisir l'une des options suivantes :

• Évitez d'exécuter des composants système critiques tels que kube-dns sur des VM Spot ou préemptives. L'utilisation de VM Spot ou préemptives pour le DNS peut entraîner des défaillances et perturber votre cluster.
• Conformément aux bonnes pratiques, créez au moins un pool de nœuds composé de VM standards (non Spot ou préemptives) pour héberger les composants système critiques tels que kube-dns. Pour vous assurer que les charges de travail critiques ne sont programmées que sur le pool de nœuds fiable et les empêche de s'exécuter sur des VM Spot ou préemptives, vous pouvez utiliser des rejets et des tolérances pour les VM Spot.
• Activez NodeLocal DNSCache.
• Augmentez la capacité de kube-dns.
• Assurez-vous que votre application utilise des fonctions basées sur dns.resolve* plutôt que sur dns.lookup, car dns.lookup est synchrone. Les fonctions dns.resolve* effectuent toujours une requête DNS asynchrone sur le réseau.

Remarque : Lors des mises à niveau du cluster GKE, des échecs de résolution DNS peuvent survenir en raison de mises à niveau simultanées des composants du plan de contrôle, y compris kube-dns. Cela peut se produire, que NodeLocal DNSCache soit activé ou non. En règle générale, seul un faible pourcentage de nœuds (environ 10 %) est affecté à un moment donné. Pour minimiser les perturbations, nous vous recommandons vivement de tester soigneusement les mises à niveau de cluster dans un environnement hors production avant de les appliquer à vos clusters de production.

Enregistrements DNS des services

kube-dns ne crée des enregistrements DNS que pour les services qui possèdent des points de terminaison.

Valeur TTL élevée provenant de serveurs DNS en amont

Si kube-dns reçoit une réponse DNS d'un résolveur DNS en amont avec une valeur TTL élevée ou "infinie", il conserve cette valeur TTL pour l'entrée DNS dans le cache. L'entrée n'expire jamais et peut créer un écart entre cette entrée et l'adresse IP réelle pour le nom TTL.

GKE résout ce problème dans les versions de plan de contrôle suivantes en définissant une valeur TTL maximale sur 30 secondes pour toute réponse DNS dont la valeur TTL est supérieure à 30 secondes :

• 1.21.14-gke.9100
• 1.22.15-gke.2100
• 1.23.13-gke.500
• 1.24.7-gke.500
• 1.25.2-gke.500 (et versions ultérieures)

Ce comportement est semblable à celui de NodeLocal DNSCache.

Étapes suivantes

• Consultez la présentation des services DNS de cluster dans GKE.
• Consultez la page DNS pour les services et les pods pour obtenir une présentation générale de l'utilisation du DNS dans les clusters Kubernetes.