Lorsque qu’une application cesse de répondre, l’un des premiers diagnostics consiste souvent à penser : « c’est un problème de DNS ». Bien que ce soit souvent le cas, la véritable origine peut également résider dans le système de Service Discovery. Bien que ces deux mécanismes aident à localiser des ressources sur un réseau, leurs fonctions sont très différentes et ils opèrent à des niveaux distincts de l’infrastructure.
L’avènement de Kubernetes, Docker, des microservices et du cloud natif a conduit à une coexistence constante de ces deux concepts, générant souvent une confusion, même parmi des administrateurs systèmes expérimentés. En réalité, DNS et Service Discovery ne se font pas concurrence ; ils se complètent.
Les clés de DNS et Service Discovery en 20 secondes
- DNS traduit les noms de domaine en adresses IP pour localiser les serveurs.
- Service Discovery permet à des applications de trouver automatiquement d’autres applications.
- Les environnements cloud changent continuellement d’IP, rendant le DNS traditionnel insuffisant.
- Kubernetes combine ces deux mécanismes pour offrir une infrastructure dynamique et résiliente.
Si l’article précédent sur les CDN et la mise en cache expliquait comment accélérer l’accès au contenu, DNS et Service Discovery résolvent une autre problématique : comment localiser précisément les services lorsque l’infrastructure évolue en permanence.
DNS : l’annuaire téléphonique d’Internet
Le système de noms de domaine (DNS) existe depuis les premiers jours d’Internet et reste l’un de ses piliers fondamentaux.
Sa fonction est de convertir des noms faciles à mémoriser, tels que :
- google.com
- github.com
- stackoverflow.com
en adresses IP que les ordinateurs utilisent réellement pour communiquer.
Par exemple, lorsqu’un utilisateur tape :
www.exemple.comson équipement interroge le serveur DNS pour connaître l’adresse IP associée.
La réponse pourrait être :
203.0.113.10Dès lors, le navigateur sait où envoyer la requête.
Tout ce processus se réalise en quelques millisecondes et demeure presque invisible pour l’utilisateur.
Sans DNS, il faudrait mémoriser l’adresse IP de chaque site web que l’on visite.
Le problème : les applications modernes ne sont plus des serveurs statiques
Pendant de nombreuses années, les serveurs évoluaient très peu.
Une entreprise installait un serveur physique ou une machine virtuelle, conservant la même adresse IP pendant des mois, voire des années.
Dans ce contexte, DNS fonctionnait parfaitement.
Mais l’architecture moderne est totalement différente.
Aujourd’hui, une application peut être constituée de dizaines ou centaines de petits services indépendants.
- Conteneurs Docker
- Pods de Kubernetes
- Machines virtuelles
- Fonctions serverless
- Instances cloud apparaissant et disparaissant automatiquement
Dans cet environnement, les adresses IP changent en permanence.
C’est ici qu’intervient le Service Discovery.
Qu’est-ce que le Service Discovery ?
Le Service Discovery permet à une application de localiser automatiquement une autre application sans connaître son adresse IP préalable.
Au lieu de demander :
Où est 10.25.17.84 ?on pose la question :
Où est le service de paiement ?Ainsi, si un conteneur disparaît et que Kubernetes en crée un autre avec une IP totalement différente, le reste des services continue de fonctionner sans modification de configuration.
Les applications ne connaissent que le nom logique du service.
Le système de découverte s’occupe du reste.
Un exemple simple
Imaginons un site e-commerce basé sur des microservices.
Il est composé de :
- Service utilisateur
- Service produit
- Service commandes
- Service paiement
- Service notifications
Lorsqu’un client passe une commande, le service de commandes doit communiquer avec le service de paiement.
Si l’on utilisait directement une adresse IP, un redémarrage du conteneur toute interruption de communication.
Hier :
Service de paiement
192.168.10.25Service de paiement
192.168.10.61
L’IP a changé.
Sans Service Discovery, il faudrait mettre à jour manuellement toutes les applications qui utilisent ce service.
Avec Service Discovery, il suffit de demander :
Où est le Service de paiement ?Le système répond automatiquement avec la nouvelle localisation.
Pour l’application, rien n’a changé.
Kubernetes automatise tout le processus
Kubernetes intègre le Service Discovery de manière native.
Lorsque vous créez une ressource Service, un nom DNS interne est automatiquement généré, comme :
payment-service.default.svc.cluster.localLes applications font simplement leurs requêtes en utilisant :
http://payment-serviceIl n’est pas nécessaire de connaître :
- combien de Pods existent,
- leurs adresses IP,
- celui qui a été récemment redémarré,
- celui qui a été remplacé.
Kubernetes maintient ces informations à jour automatiquement.
En cas de défaillance d’un Pod, le trafic bascule vers un autre disponible sans que l’application cliente ait besoin d’intervenir.
Cette combinaison de DNS interne et de Service Discovery constitue l’un des piliers de Kubernetes.
DNS et Service Discovery répondent à des problématiques différentes
Bien qu’ils aident tous deux à localiser des ressources, ils opèrent à des niveaux distincts.
| DNS | Service Discovery |
|---|---|
| Localise des serveurs. | Localise des applications ou des services. |
| Traduit les noms de domaine en IP. | Trouve automatiquement des instances disponibles. |
| Conçu pour une infrastructure relativement stable. | Optimisé pour des environnements dynamiques et cloud native. |
| Utilisé par des utilisateurs et des applications externes. | Principalement employé entre microservices. |
| Modifications peu fréquentes. | Mises à jour en continu. |
La différence peut se résumer ainsi :
DNS aide les personnes à trouver des serveurs.
Service Discovery aide les applications à se localiser entre elles.
Un exemple concret : Netflix
Lorsqu’un utilisateur tape :
www.netflix.comla première étape consiste à résoudre ce domaine via DNS.
Une fois la requête arrivée dans l’infrastructure de Netflix, un tout autre processus commence.
Des dizaines de services internes commencent à communiquer entre eux :
- authentification,
- profils,
- recommandations,
- catalogue,
- facturation,
- reproduction,
- monitoring.
Ces composants n’utilisent généralement pas de noms publics.
Ils exploitent plutôt des systèmes de Service Discovery pour localiser en temps réel les instances disponibles de chaque microservice.
Pour l’utilisateur, tout semble être une seule application.
En interne, des centaines de services répartis dans plusieurs centres de données peuvent intervenir simultanément.
Service Discovery ne remplace pas le DNS
Une idée répandue est de penser que Kubernetes a remplacé le DNS traditionnel.
Ce n’est pas le cas.
Ce que fait Kubernetes, c’est utiliser le DNS comme mécanisme pour implémenter une partie du Service Discovery interne.
En réalité, les deux fonctionnent ensemble.
Le flux habituel est le suivant :
- L’utilisateur utilise DNS pour localiser l’application.
- La requête arrive dans le cluster.
- À l’intérieur du cluster, les microservices utilisent Service Discovery pour s’auto-localiser.
- Kubernetes met automatiquement à jour les routes quand de nouvelles instances apparaissent ou disparaissent.
L’infrastructure cloud a besoin des deux
Les applications modernes ne fonctionnent plus sur quelques serveurs statiques.
L’élasticité automatique, le déploiement continu, les conteneurs et l’orchestration font que les adresses IP changent constamment.
DNS reste indispensable pour accéder aux applications et services depuis Internet.
Service Discovery permet à ces applications de continuer à fonctionner correctement même lorsque l’infrastructure change des centaines de fois par jour.
C’est pourquoi des technologies comme Kubernetes, Consul, Istio, Linkerd ou AWS Cloud Map intègrent des mécanismes avancés de découverte de services.
Ils ne remplacent pas le DNS.
Ils le complètent.
Dans la pratique, toute architecture cloud native moderne nécessite la synergie de ces deux mécanismes pour assurer haute disponibilité, scalabilité et résilience.
Questions fréquentes
DNS et Service Discovery, c’est pareil ?
Non. Le DNS traduit des noms de domaine en adresses IP, tandis que le Service Discovery permet de localiser automatiquement des applications ou microservices dont la localisation peut évoluer en permanence.
Pourquoi Kubernetes utilise-t-il les deux ?
Parce que le DNS fournit des noms stables pour accéder aux services, tandis que Kubernetes met à jour automatiquement quels Pods sains répondent derrière ces noms.
Une application peut-elle se passer de Service Discovery, uniquement avec DNS ?
Oui, surtout dans des infrastructures traditionnelles où les adresses IP changent peu. Dans une architecture basée sur les microservices, cette gestion manuelle devient rapidement ingérable.
Quelles autres solutions de Service Discovery existent au-delà de Kubernetes ?
Parmi les plus répandues, on trouve HashiCorp Consul, AWS Cloud Map, Eureka de Netflix, ainsi que les mécanismes intégrés dans des plateformes comme Kubernetes ou OpenShift.
