Découverte de services via DNS interne (CoreDNS)

Comment les Pods trouvent-ils les Services ?

Nous avons établi que les Services fournissent une adresse IP stable (la ClusterIP) et agissent comme un point d'entrée unique pour un ensemble de Pods. C'est une amélioration considérable par rapport à la tentative d'utiliser les adresses IP éphémères des Pods. Cependant, une question demeure : comment un Pod client découvre-t-il l'adresse ClusterIP du Service qu'il souhaite contacter ?

Mémoriser ou coder en dur les adresses ClusterIP dans la configuration des applications clientes serait une mauvaise pratique. Les ClusterIPs, bien que plus stables que les IP de Pods, pourraient théoriquement changer si un Service est supprimé puis recréé. De plus, utiliser des adresses IP rend la configuration moins lisible et plus difficile à gérer.

Kubernetes résout ce problème de découverte de services (Service Discovery) en intégrant son propre système DNS interne au cluster. Ce système permet aux Pods de trouver les Services en utilisant simplement leurs noms, de la même manière que nous utilisons des noms de domaine comme `www.google.com` sur Internet au lieu de mémoriser leurs adresses IP.

CoreDNS : le résolveur DNS du cluster

La plupart des installations Kubernetes modernes utilisent CoreDNS comme serveur DNS interne. CoreDNS est un serveur DNS flexible et extensible, lui-même déployé comme un `Deployment` (avec plusieurs réplicas pour la haute disponibilité) dans le namespace `kube-system`. Il est exposé via un `Service` de type `ClusterIP`, généralement nommé `kube-dns` (pour des raisons de compatibilité historique).

Comment les Pods utilisent-ils ce service DNS ? Lorsqu'un Pod est démarré, le Kubelet sur le noeud configure automatiquement le fichier `/etc/resolv.conf` à l'intérieur de chaque conteneur du Pod. Ce fichier est configuré pour :

1. Pointer vers l'adresse ClusterIP du Service `kube-dns` comme serveur de noms (`nameserver`).
2. Inclure des chemins de recherche (`search`) appropriés qui facilitent la résolution des noms courts au sein du cluster.

Cela signifie que toute requête DNS effectuée depuis un Pod sera automatiquement dirigée vers le serveur CoreDNS du cluster.

Création automatique des enregistrements DNS

La magie opère car CoreDNS surveille l'API Server de Kubernetes. Lorsqu'un nouveau Service est créé dans le cluster, CoreDNS crée automatiquement des enregistrements DNS correspondants.

• Pour chaque Service (de type `ClusterIP`, `NodePort`, ou `LoadBalancer`), un enregistrement DNS `A` est créé. Cet enregistrement associe un nom de domaine interne au Service à son adresse ClusterIP.
• Pour les ports nommés définis dans un Service, des enregistrements DNS `SRV` peuvent également être créés, permettant de découvrir non seulement l'IP mais aussi le numéro de port associé à un nom symbolique.

Par exemple, si vous créez un Service nommé `mon-backend` dans le namespace `production`, CoreDNS créera un enregistrement `A` qui fait correspondre un nom comme `mon-backend.production.svc.cluster.local` à l'adresse ClusterIP attribuée à ce Service.

Schéma de nommage et résolution DNS

Le nom de domaine complet (FQDN) d'un Service dans Kubernetes suit généralement le format :

`..svc.`

• `` : Le nom que vous avez donné à l'objet Service (`metadata.name`).
• `` : Le Namespace dans lequel le Service a été créé.
• `svc` : Un sous-domaine fixe indiquant qu'il s'agit d'un Service.
• `` : Le suffixe de domaine configuré pour le cluster (par défaut, c'est souvent `cluster.local`).

Grâce aux chemins de recherche configurés dans `/etc/resolv.conf` des Pods, la résolution est simplifiée :

• Un Pod essayant d'accéder à un Service dans le même Namespace peut simplement utiliser le nom court du Service : `mon-backend`. Le résolveur DNS essaiera automatiquement d'ajouter `.production.svc.cluster.local` (si le Pod est dans le namespace `production`) et trouvera l'enregistrement `A`.
• Un Pod essayant d'accéder à un Service dans un Namespace différent (par exemple, `frontend` accédant à `mon-backend` dans `production`) doit utiliser le nom du Service suivi du nom du Namespace : `mon-backend.production`. Le résolveur essaiera alors `mon-backend.production.svc.cluster.local`.

Ce mécanisme permet aux applications de se référer aux services dont elles dépendent par des noms stables et lisibles, sans jamais avoir besoin de connaître les adresses ClusterIP sous-jacentes.

Exemple : Une application frontend dans le namespace `web` veut contacter le service backend `user-api` dans le namespace `api`. Elle utilisera simplement l'URL `http://user-api.api:8080`. Le DNS interne résoudra `user-api.api` en la ClusterIP du service `user-api`, et la requête HTTP sera envoyée à cette IP sur le port 8080.

Conclusion : la découverte simplifiée grâce au DNS

Le système DNS interne, généralement propulsé par CoreDNS, est un composant essentiel et souvent transparent de l'architecture réseau de Kubernetes. Il résout le problème fondamental de la découverte de services dans un environnement où les adresses IP des Pods sont dynamiques.

En attribuant des noms DNS stables aux Services et en configurant automatiquement les Pods pour utiliser le DNS du cluster, Kubernetes permet une communication inter-services fiable et découplée. Les développeurs peuvent se concentrer sur l'utilisation de noms de services logiques, laissant Kubernetes gérer la complexité de la résolution d'adresses et du routage sous-jacent.

Cette découverte basée sur le DNS est l'une des pierres angulaires qui rendent possible la construction d'architectures microservices robustes et évolutives sur Kubernetes.