Service Discovery

Ce document fournit une présentation de la détection de services basée sur le DNS de Kubernetes et de son utilisation avec Kf.

Quand utiliser la détection de services Kubernetes avec Kf

La détection de services Kubernetes peut être utilisée par les applications qui doivent localiser les services externes de manière cohérente, indépendamment de l'endroit où l'application est déployée. Par exemple, une équipe peut souhaiter utiliser dans sa configuration un URI commun qui pointe toujours vers la passerelle SMTP locale, afin de dissocier le code de l'environnement dans lequel il est exécuté.

La détection de services aide les équipes applicatives de différentes manières :

  • Elle réduit la quantité de configurations par environnement.
  • Elle dissocie les applications client et serveur.
  • Elle autorise le transfert des applications vers de nouveaux environnements.

Vous pouvez utiliser la détection de services Kubernetes dans les cas suivants :

  • Les applications utilisent les configurations DNS de leur conteneur pour résoudre les hôtes.
  • Les applications sont déployées avec leurs services externes dans le même cluster ou espace de noms Kubernetes.
  • Les services externes possèdent un service Kubernetes associé. Kf crée ces services pour chaque application.
  • Les règles de réseau Kubernetes NetworkPolicies autorisent le trafic entre une application et le service Kubernetes avec lequel elle doit communiquer. Kf crée ces règles dans chaque espace Kf.

Vous ne devriez pas utiliser la détection de services Kubernetes dans les cas suivants :

  • Les applications doivent basculer entre plusieurs clusters.
  • Vous remplacez le résolveur DNS utilisé par votre application.
  • Les applications nécessitent des types spécifiques d'équilibrage de charge.

Fonctionnement de la détection de services Kubernetes

La détection de services Kubernetes fonctionne en modifiant la configuration DNS des conteneurs exécutés sur un nœud Kubernetes. Lorsqu'une application recherche un nom de domaine non qualifié, le résolveur DNS local tente d'abord de résoudre le nom au sein du cluster local.

Les domaines ne comportant pas plusieurs parties seront résolus par rapport aux noms des services Kubernetes dans l'espace de noms du conteneur. Chaque application Kf crée un service Kubernetes portant le même nom. Si deux applications Kf ping et pong ont été déployées dans le même espace Kf, ping peut utiliser l'URL http://pong pour envoyer du trafic vers l'autre service.

Les domaines ne comportant qu'un seul point seront résolus avec les services Kubernetes de l'espace de noms Kubernetes portant le même nom que le libellé qui figure après le point. Par exemple, s'il existe une base de données PostgreSQL avec un service customers dans l'espace de noms database, une application d'un autre espace de noms peut la résoudre à l'aide de postgres://customers.database.

Utiliser la détection de services avec Kf

La détection de services basée sur le DNS de Kubernetes peut être utilisée dans toute application Kf. Chaque application Kf crée un service Kubernetes du même nom, et chaque espace Kf crée un espace de noms Kubernetes portant le même nom.

  • Référez-vous à une application Kf dans l'espace actuel à l'aide de protocol://app-name.
  • Référez-vous à une application Kf dans un autre espace à l'aide de protocol://app-name.space-name.
  • Référez-vous à une application Kf dans l'espace actuel et en écoute sur un port personnalisé à l'aide de protocol://app-name:port.
  • Référez-vous à une application Kf dans un autre espace et en écoute sur un port personnalisé à l'aide de protocol://app-name.space-name:port.

Bonnes pratiques

Les applications qui seront la cible de la détection de services basée sur le DNS doivent faire l'objet de vérifications d'état fréquentes afin de s'assurer qu'elles sont ajoutées et retirées rapidement du pool d'hôtes acceptant des connexions.

Les applications utilisant la détection de services basée sur le DNS ne doivent pas mettre en cache les adresses IP des services résolus, car leur stabilité n'est pas garantie.

Si des services spécifiques à l'environnement existent en dehors du cluster, ils peuvent être résolus à l'aide du DNS Kubernetes si vous configurez les services Kubernetes ExternalName. Ces services Kubernetes offrent les mêmes capacités de résolution, mais renvoient un enregistrement CNAME pour rediriger les requêtes vers une autorité externe.

Comparaison avec Eureka

Eureka est un équilibreur de charge Open Source côté client créé par Netflix. Il est couramment utilisé dans le cadre de l'agent de service Spring Cloud Services. Eureka a été conçu comme un équilibreur de charge régional et un mécanisme de détection de services pour les services exécutés dans un environnement entraînant des perturbations fréquentes des charges de travail et conduisant à l'instabilité des adresses IP.

Eureka a été conçu suivant un modèle client/serveur. Les clients s'enregistrent auprès du serveur pour indiquer à quels noms ils souhaitent être associés et ils envoient régulièrement au serveur des pulsations. Le serveur autorise tous les clients connectés à résoudre les noms.

En général, dans Kubernetes, il est recommandé d'utiliser le DNS de Kubernetes plutôt qu'Eureka pour les raisons suivantes :

  • Le DNS fonctionne avec tous les langages de programmation et applications, sans nécessiter de bibliothèques.
  • La vérification d'état existante pour votre application est réutilisée, ce qui permet de réduire les combinaisons d'erreurs.
  • Kubernetes gère le serveur DNS, ce qui réduit le nombre de dépendances sur lesquelles vous devez vous appuyer.
  • Le DNS de Kubernetes respecte les mêmes règles et contraintes RBAC que le reste de Kubernetes.

Dans certains contextes, le déploiement d'un serveur Eureka peut être bénéfique :

  • Vous avez besoin de la détection de services entre Kubernetes et des applications basées sur des VM.
  • Vous avez besoin d'un équilibrage de charge basé sur le client.
  • Vous avez besoin de vérifications d'état indépendantes.

Étape suivante