Une introduction au service DNS Kubernetes

introduction

Le système de noms de domaine (DNS) est un système permettant d'associer divers types d'informations - telles que les adresses IP - à des noms faciles à retenir. Par défaut, la plupart des clusters Kubernetes configurent automatiquement un service DNS interne afin de fournir un mécanisme léger pour la découverte de services. La découverte de services intégrée facilite la recherche et la communication entre les applications sur les clusters Kubernetes, même lorsque des pods et des services sont en cours de création, de suppression et de transfert entre les nœuds.

Les détails d'implémentation du service DNS de Kubernetes ont été modifiés dans les versions récentes de Kubernetes. Dans cet article, nous examinerons les versionskube-dns etCoreDNS du service DNS Kubernetes. Nous examinerons leur fonctionnement et les enregistrements DNS générés par Kubernetes.

Pour avoir une compréhension plus approfondie du DNS avant de commencer, veuillez lireAn Introduction to DNS Terminology, Components, and Concepts. Pour tous les sujets Kubernetes que vous ne connaissez peut-être pas, vous pouvez lireAn Introduction to Kubernetes.

Qu'est-ce que le service DNS Kubernetes fournit?

Avant Kubernetes version 1.11, le service DNS de Kubernetes était basé surkube-dns. La version 1.11 a introduitCoreDNS pour résoudre certains problèmes de sécurité et de stabilité avec kube-dns.

Quel que soit le logiciel gérant les enregistrements DNS réels, les deux implémentations fonctionnent de la même manière:

Un service nommékube-dns et un ou plusieurs pods sont créés.
Le servicekube-dns écoute les événementsservice etendpoint de l'API Kubernetes et met à jour ses enregistrements DNS si nécessaire. Ces événements sont déclenchés lorsque vous créez, mettez à jour ou supprimez des services Kubernetes et leurs pods associés.
kubelet définit l’option/etc/resolv.confnameserver de chaque nouveau pod sur l’IP du cluster du servicekube-dns, avec les optionssearch appropriées pour permettre l’utilisation de noms d’hôte plus courts:

resolv.conf
```
nameserver 10.32.0.10
search namespace.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
```
Les applications exécutées dans des conteneurs peuvent ensuite résoudre les noms d'hôte tels queexample-service.namespace en adresses IP de cluster correctes.

Exemple d'enregistrements DNS Kubernetes

L'enregistrement DNS completAd'un service Kubernetes ressemblera à l'exemple suivant:

service.namespace.svc.cluster.local

Un pod aurait un enregistrement dans ce format, reflétant l'adresse IP réelle du pod:

10.32.0.125.namespace.pod.cluster.local

De plus, les enregistrementsSRV sont créés pour les ports nommés d'un service Kubernetes:

_port-name._protocol.service.namespace.svc.cluster.local

Le résultat de tout cela est un mécanisme de découverte de service intégré basé sur DNS, dans lequel votre application ou microservice peut cibler un nom d'hôte simple et cohérent pour accéder à d'autres services ou pods sur le cluster.

Rechercher des domaines et résoudre les noms d'hôte plus courts

En raison des suffixes de domaine de recherche répertoriés dans le fichierresolv.conf, vous n'aurez souvent pas besoin d'utiliser le nom d'hôte complet pour contacter un autre service. Si vous adressez un service dans le même espace de noms, vous pouvez simplement utiliser le nom du service pour le contacter:

other-service

Si le service est dans un espace de noms différent, ajoutez-le à la requête:

other-service.other-namespace

Si vous ciblez un pod, vous devez utiliser au moins les éléments suivants:

pod-ip.other-namespace.pod

Comme nous l'avons vu dans le fichier par défautresolv.conf, seuls les suffixes.svc sont automatiquement complétés, alors assurez-vous de tout spécifier jusqu'à.pod.

Maintenant que nous connaissons les utilisations pratiques du service DNS de Kubernetes, voyons quelques détails sur les deux implémentations.

Kubernetes DNS Details d'implémentation

Comme indiqué dans la section précédente, Kubernetes version 1.11 a introduit un nouveau logiciel pour gérer le servicekube-dns. La motivation de ce changement était d'accroître les performances et la sécurité du service. Voyons d'abord l'implémentation d'origine dekube-dns.

kube-dns

Le servicekube-dns antérieur à Kubernetes 1.11 est composé de trois conteneurs s'exécutant dans un podkube-dns dans l'espace de nomskube-system. Les trois conteneurs sont:

kube-dns: un conteneur qui exécuteSkyDNS, qui effectue la résolution des requêtes DNS
dnsmasq: un résolveur DNS léger populaire et un cache qui met en cache les réponses de SkyDNS
sidecar: un conteneur side-car qui gère les rapports de métriques et répond aux vérifications de l'état du service

Des vulnérabilités de sécurité dans Dnsmasq et des problèmes de performances avec SkyDNS ont conduit à la création d'un système de remplacement, CoreDNS.

CoreDNS

Depuis Kubernetes 1.11, un nouveau service DNS Kubernetes,CoreDNS a été promu à la disponibilité générale. Cela signifie qu’il est prêt à être utilisé en production et qu’il constituera le service DNS de cluster par défaut pour de nombreux outils d’installation et fournisseurs Kubernetes gérés.

CoreDNS est un processus unique, écrit en Go, qui couvre toutes les fonctionnalités du système précédent. Un seul conteneur résout et met en cache les requêtes DNS, répond aux vérifications de l'état et fournit des métriques.

En plus de résoudre les problèmes liés aux performances et à la sécurité, CoreDNS corrige quelques autres bugs mineurs et ajoute de nouvelles fonctionnalités:

Certains problèmes d'incompatibilités entre l'utilisation de stubDomains et des services externes ont été résolus
CoreDNS peut améliorer l'équilibrage de la charge basé sur le DNS basé sur le DNS en randomisant l'ordre dans lequel il renvoie certains enregistrements.
Une fonctionnalité appeléeautopath peut améliorer les temps de réponse DNS lors de la résolution des noms d'hôte externes, en étant plus intelligente dans l'itération de chacun des suffixes de domaine de recherche répertoriés dansresolv.conf
Avec kube-dns,10.32.0.125.namespace.pod.cluster.local se résoudrait toujours en10.32.0.125, même si le pod n’existe pas réellement. CoreDNS a un mode «pods vérifié» qui ne sera résolu que si un pod existe avec la bonne adresse IP et dans le bon espace de noms.

Pour plus d'informations sur CoreDNS et en quoi il diffère de kube-dns, vous pouvez lirethe Kubernetes CoreDNS GA announcement.

Options de configuration supplémentaires

Les opérateurs Kubernetes souhaitent souvent personnaliser la façon dont leurs pods et conteneurs résolvent certains domaines personnalisés, ou doivent ajuster les serveurs de noms en amont ou les suffixes de domaine de recherche configurés dansresolv.conf. Vous pouvez le faire avec l'optiondnsConfig de la spécification de votre pod:

example_pod.yaml

apiVersion: v1
kind: Pod
metadata:
  namespace: example
  name: custom-dns
spec:
  containers:
    - name: example
      image: nginx
  dnsPolicy: "None"
  dnsConfig:
    nameservers:
      - 203.0.113.44
    searches:
      - custom.dns.local

La mise à jour de cette configuration réécrira lesresolv.conf d'un pod pour activer les modifications. La configuration correspond directement aux options standard deresolv.conf, de sorte que la configuration ci-dessus créerait un fichier avec les lignesnameserver 203.0.113.44 etsearch custom.dns.local.

Conclusion

Dans cet article, nous avons présenté les bases du service DNS de Kubernetes aux développeurs, présenté quelques exemples d’enregistrements DNS pour les services et les pods, expliqué comment le système est implémenté sur différentes versions de Kubernetes et mis en évidence certaines options de configuration supplémentaires disponibles pour personnaliser la configuration de vos pods. résoudre les requêtes DNS.

Pour plus d'informations sur le service DNS Kubernetes, reportez-vous àthe official Kubernetes DNS for Services and Pods documentation.

TOC