À propos de la détection de services

Ce document explique comment la détection de services dans Google Kubernetes Engine (GKE) simplifie la gestion des applications et comment étendre la détection de services au-delà d'un seul cluster à l'aide des portées Cloud DNS, des services multiclusters (MCS) et de Annuaire des services.

Ce document s'adresse aux utilisateurs, aux développeurs, aux administrateurs et aux architectes GKE. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

Avant de lire ce document, assurez-vous de comprendre les concepts suivants :

Présentation

La découverte des services est un mécanisme qui permet aux services et aux applications de se trouver et de communiquer entre eux de manière dynamique, sans coder en dur les adresses IP ni les configurations de points de terminaison. La découverte de services permet de s'assurer que les applications ont toujours accès aux adresses IP des pods à jour, même lorsque les pods sont replanifiés ou que de nouveaux pods sont ajoutés. GKE propose plusieurs façons d'implémenter la découverte des services, y compris kube-dns, les déploiements kube-dns personnalisés et Cloud DNS. Vous pouvez optimiser davantage les performances DNS avec NodeLocal DNSCache.

Avantages de la détection de services

La découverte de services offre les avantages suivants :

  • Gestion simplifiée des applications : la détection de services élimine la nécessité de coder en dur les adresses IP dans les configurations de vos applications. Les applications communiquent à l'aide de noms de services logiques, qui sont automatiquement résolus en adresses IP de pod correctes. Cette approche simplifie la configuration, en particulier dans les environnements dynamiques où les adresses IP des pods peuvent changer en raison du scaling ou de la reprogrammation.
  • Évolutivité et résilience simplifiées : la détection de services simplifie l'évolutivité en dissociant les consommateurs de services des adresses IP des pods, qui changent fréquemment. Lorsque votre application évolue, ou si des pods échouent et sont remplacés, Kubernetes met automatiquement à jour les pods disponibles pour recevoir le trafic d'un service donné. La découverte de services permet de s'assurer que les requêtes adressées au nom de service stable ne sont dirigées que vers des pods opérationnels. Votre application peut ainsi évoluer ou se rétablir en cas de défaillance sans intervention manuelle ni reconfiguration du client.
  • Haute disponibilité : GKE utilise l'équilibrage de charge avec la détection de services pour assurer la haute disponibilité et améliorer la réactivité de vos applications, même en cas de forte charge.

Équilibrage de charge avec la détection de services

GKE assure la haute disponibilité de vos applications en combinant différents niveaux d'équilibrage de charge avec la détection de services.

  • Services internes : pour les services accessibles uniquement dans le cluster, le plan de données de GKE (kube-proxy ou Cilium) fait office d'équilibreur de charge. Il répartit équitablement le trafic entrant sur plusieurs pods sains, ce qui évite la surcharge et contribue à assurer une haute disponibilité.
  • Services externes : pour les services qui doivent être accessibles depuis l'extérieur du cluster, GKE provisionne des équilibreurs de charge Google Cloud . Ces équilibreurs de charge incluent des équilibreurs de charge externes Google Cloud pour l'accès à l'Internet public et des équilibreurs de charge internes Google Cloud pour l'accès au sein de votre réseau Virtual Private Cloud. Ces équilibreurs de charge répartissent le trafic entre les nœuds de votre cluster. Le plan de données de chaque nœud achemine ensuite le trafic vers les pods appropriés.

Dans les scénarios internes et externes, la détection de services met à jour en continu la liste des pods disponibles pour chaque service. Cette mise à jour continue permet de s'assurer que le plan de données (pour les services internes) et les équilibreurs de charge Google Cloud (pour les services externes) ne dirigent le trafic que vers des instances saines.

Cas d'utilisation pour la détection de services

Voici des cas d'utilisation courants pour la détection de services :

  • Architecture de microservices : dans une architecture de microservices, les applications se composent souvent de nombreux services plus petits et indépendants qui doivent interagir. La découverte de services permet à ces applications de se trouver et d'échanger des informations, même lorsque le cluster évolue.
  • Activer les déploiements sans temps d'arrêt et améliorer la résilience : la découverte de services facilite les mises à jour sans temps d'arrêt pour les applications, y compris les déploiements contrôlés et Canary. Il automatise la découverte de nouvelles versions de service et y transfère le trafic, ce qui permet de réduire les temps d'arrêt lors du déploiement et d'assurer une transition fluide pour les utilisateurs. La découverte de services améliore également la résilience. Lorsqu'un pod échoue dans GKE, un nouveau pod est déployé. La découverte de services enregistre le nouveau pod et y redirige le trafic, ce qui permet de minimiser les temps d'arrêt des applications.

Fonctionnement de la détection de services

Dans GKE, les applications sont souvent constituées de plusieurs pods qui doivent se trouver et communiquer entre eux. La découverte de services offre cette fonctionnalité à l'aide du système de noms de domaine (DNS). De la même manière que vous utilisez le DNS pour trouver des sites Web sur Internet, les pods d'un cluster GKE utilisent le DNS pour localiser les services et s'y connecter à l'aide de leurs noms de service. Cette approche permet aux pods d'interagir efficacement, où qu'ils s'exécutent dans le cluster, et permet aux applications de communiquer à l'aide de noms de service cohérents plutôt que d'adresses IP instables.

Comment les pods effectuent la résolution DNS

Les pods d'un cluster GKE résolvent les noms DNS des services et des autres pods en utilisant une combinaison d'enregistrements DNS générés automatiquement et de leur configuration DNS locale.

Noms DNS des services

Lorsque vous créez un service Kubernetes, GKE lui attribue automatiquement un nom DNS. Ce nom suit un format prévisible que n'importe quel pod du cluster peut utiliser pour accéder au service :

<service-name>.<namespace>.svc.cluster.local

Le domaine de cluster par défaut est cluster.local, mais vous pouvez le personnaliser lorsque vous créez le cluster. Par exemple, un service nommé my-web-app dans l'espace de noms par défaut aurait le nom DNS my-web-app.default.svc.cluster.local.

Le rôle de /etc/resolv.conf

Pour résoudre ces noms DNS, les pods s'appuient sur leur fichier /etc/resolv.conf. Ce fichier de configuration indique au pod le serveur de noms auquel envoyer ses requêtes DNS. L'adresse IP du serveur de noms listé dans ce fichier dépend des fonctionnalités DNS spécifiques activées sur votre cluster GKE. Le tableau suivant indique l'adresse IP du serveur de noms utilisée par un pod, en fonction de votre configuration :

Cloud DNS pour GKE NodeLocal DNSCache Valeur du serveur de noms `/etc/resolv.conf`
Activé Activé `169.254.20.10`
Activé Désactivé `169.254.169.254`
Désactivé Activé Adresse IP du service `kube-dns`
Désactivé Désactivé Adresse IP du service `kube-dns`

Cette configuration permet de s'assurer que les requêtes DNS du pod sont dirigées vers le bon composant :

  • NodeLocal DNSCache : permet des recherches locales rapides sur le nœud.
  • Adresse IP du serveur de métadonnées (169.254.169.254) : utilisée lorsque Cloud DNS pour GKE est activé sans NodeLocal DNSCache. Les requêtes DNS sont dirigées vers cette adresse IP, que Cloud DNS utilise pour intercepter et traiter les requêtes DNS.
  • kube-dns Adresse IP du service : utilisée pour la résolution standard dans le cluster lorsque Cloud DNS pour GKE est désactivé.

Architecture DNS dans GKE

GKE fournit une architecture flexible pour la détection de services, principalement en utilisant le DNS. Les composants suivants fonctionnent ensemble pour résoudre les requêtes DNS dans votre cluster :

  • kube-dns : fournisseur DNS par défaut dans les clusters GKE Standard. Il s'exécute en tant que déploiement géré de pods dans l'espace de noms kube-system et surveille l'API Kubernetes pour détecter les nouveaux services et créer les enregistrements DNS nécessaires.
  • Cloud DNS : service DNS entièrement géré de Google Cloud. Il offre une alternative fiable et hautement évolutive à kube-dns et constitue le fournisseur DNS par défaut pour les clusters GKE Autopilot.
  • NodeLocal DNSCache : module complémentaire GKE qui améliore les performances de recherche DNS. Il exécute un cache DNS sur chaque nœud de votre cluster, en fonctionnant avec kube-dns ou Cloud DNS pour répondre aux requêtes DNS localement. Cela réduit la latence et la charge sur le fournisseur DNS central du cluster. Pour les clusters GKE Autopilot, NodeLocal DNSCache est activé par défaut et ne peut pas être remplacé.
  • Déploiement kube-dns personnalisé : déploiement qui vous permet de déployer et de gérer votre propre instance de kube-dns, ce qui vous offre plus de contrôle sur la configuration et les ressources de kube-dns.

Choisir votre fournisseur DNS

Le tableau suivant récapitule les fournisseurs DNS disponibles dans GKE, y compris leurs fonctionnalités et le moment où choisir chacun d'eux :

Fournisseur Fonctionnalités Quand choisir
`kube-dns` Résolution DNS dans le cluster pour les services et les pods. Tous les clusters ayant des besoins réseau standards. La nouvelle version de `kube-dns` convient aux clusters de petite et de grande envergure.
Cloud DNS Fonctionnalités DNS avancées (zones privées, gestion du trafic, équilibrage de charge mondial) et intégration à d'autres services Google Cloud . Exposer des services en externe, des environnements multiclusters ou des clusters avec des taux de requêtes DNS élevés (RPS).
Déploiement `kube-dns` personnalisé Contrôle supplémentaire sur la configuration et l'allocation des ressources, et possibilité d'utiliser d'autres fournisseurs DNS. Clusters à grande échelle ou besoins DNS spécifiques nécessitant un scaling plus agressif ou un contrôle précis de l'allocation des ressources.

Découverte des services en dehors d'un cluster

Vous pouvez étendre la détection de services au-delà d'un seul cluster GKE à l'aide des méthodes suivantes :

Champ d'application Cloud DNS

Les clusters qui utilisent Cloud DNS pour les services DNS de cluster peuvent s'exécuter dans l'un des trois champs d'application disponibles :

  • Champ d'application du cluster : il s'agit du comportement par défaut de Cloud DNS. Dans ce mode, Cloud DNS fonctionne de la même manière que kube-dns en fournissant une résolution DNS exclusivement pour les ressources qui se trouvent dans le cluster. Les enregistrements DNS ne peuvent être résolus qu'à partir du cluster et respectent le schéma de service Kubernetes standard : <svc>.<ns>.svc.cluster.local.
  • Champ d'application VPC additif : cette fonctionnalité facultative étend le champ d'application du cluster en permettant la résolution des services sans adresse IP de cluster à partir d'autres ressources du même réseau VPC, telles que des VM Compute Engine ou des clients sur site qui se connectent à l'aide de Cloud VPN ou Cloud Interconnect.
  • À l'échelle du VPC : avec cette configuration, les enregistrements DNS des services de cluster peuvent être résolus dans l'ensemble du réseau VPC. Cette approche signifie que tout client se trouvant dans le même VPC ou y étant connecté (via Cloud VPN ou Cloud Interconnect) peut résoudre directement les noms de service.

Pour en savoir plus sur le champ d'application DNS à l'échelle d'un VPC, consultez la page Utiliser Cloud DNS pour GKE.

Services multicluster

Les services multiclusters (MCS) permettent la détection de services et la gestion du trafic sur plusieurs clusters GKE. MCS vous permet de créer des applications qui s'étendent sur plusieurs clusters tout en conservant une expérience de service unifiée.

MCS utilise la détection de services basée sur DNS pour connecter les services entre les clusters. Lorsque vous créez une instance MCS, elle génère des enregistrements DNS au format <svc>.<ns>.svc.clusterset.local. Ces enregistrements sont résolus en adresses IP des points de terminaison du service dans chaque cluster participant.

Lorsqu'un client d'un cluster accède à un MCS, les requêtes sont acheminées vers le point de terminaison disponible le plus proche dans l'un des clusters participants. Cette distribution du trafic est gérée par kube-proxy (ou Cilium dans GKE Dataplane V2) sur chaque nœud, ce qui permet d'assurer une communication et un équilibrage de charge efficaces dans les clusters.

Annuaire des services pour GKE

L'annuaire des services pour GKE fournit un registre unifié pour la découverte de services dans vos déploiements Kubernetes et non Kubernetes. L'annuaire des services peut enregistrer des services GKE et non-GKE dans un seul registre.

L'annuaire des services est particulièrement utile si vous souhaitez :

  • un registre unique permettant aux applications Kubernetes et non-Kubernetes de se détecter ;
  • un outil de découverte des services géré ;
  • La possibilité de stocker des métadonnées sur votre service auxquelles d'autres clients peuvent accéder.
  • La possibilité de définir des autorisations d'accès par service. Les services de l'Annuaire des services peuvent être résolus à l'aide de DNS, HTTP et gRPC. L'annuaire des services est intégré à Cloud DNS et peut remplir les enregistrements Cloud DNS correspondant aux services de l'annuaire.

Pour en savoir plus, consultez Configurer l'annuaire des services pour GKE.

Optimiser les performances DNS et bonnes pratiques

Pour assurer détection de services fiable et efficace, en particulier dans les clusters à grande échelle ou à trafic élevé, tenez compte des bonnes pratiques et des stratégies d'optimisation suivantes.

Optimiser les performances avec NodeLocal DNSCache

Pour les clusters à haute densité de pods ou les applications qui génèrent un volume élevé de requêtes DNS, vous pouvez améliorer la vitesse de résolution DNS en activant NodeLocal DNSCache. NodeLocal DNSCache est un module complémentaire GKE qui exécute un cache DNS sur chaque nœud de votre cluster. Lorsqu'un pod effectue une requête DNS, celle-ci est envoyée au cache qui se trouve sur le même nœud. Cette approche permet de réduire la latence et le trafic réseau.

Pour savoir comment activer et configurer cette fonctionnalité, consultez Configurer NodeLocal DNSCache.

Faire évoluer votre fournisseur DNS

Si vous utilisez kube-dns et que vous rencontrez des délais d'attente intermittents, en particulier pendant les périodes de trafic élevé, vous devrez peut-être ajuster le nombre de répliques kube-dns. kube-dns-autoscaler ajuste le nombre de répliques en fonction du nombre de nœuds et de cœurs du cluster. Ses paramètres peuvent être ajustés pour déployer plus de répliques plus rapidement.

Pour obtenir des instructions détaillées, consultez Scaling up kube-dns.

Bonnes pratiques générales

  • Sélectionnez le fournisseur DNS approprié : choisissez votre fournisseur DNS en fonction des besoins de votre cluster. Cloud DNS est recommandé pour les charges de travail à RPS élevé, les environnements multiclasses et lorsque vous avez besoin d'une intégration à votre réseau VPC plus étendu. La nouvelle version de kube-dns convient à un large éventail de clusters, des plus petits aux plus grands, qui ont des besoins standards de détection de services dans le cluster.
  • Évitez les VM Spot ou préemptives pour kube-dns : contribuez à assurer la stabilité du service DNS de votre cluster en n'exécutant pas de composants système critiques tels que kube-dns sur des VM Spot ou préemptives. Les arrêts inattendus de nœuds peuvent entraîner des problèmes de résolution DNS.
  • Utilisez des noms de service clairs et descriptifs : adoptez des conventions d'attribution de noms cohérentes et significatives pour vos services afin de faciliter la lecture et la maintenance des configurations d'application.
  • Organisez vos services avec des espaces de noms : utilisez les espaces de noms Kubernetes pour regrouper les services associés. Cette approche permet d'éviter les conflits de nommage et d'améliorer l'organisation des ressources du cluster.
  • Surveillez et validez le DNS : surveillez régulièrement les métriques et les journaux DNS pour identifier les problèmes potentiels avant qu'ils n'affectent vos applications. Testez régulièrement la résolution DNS depuis vos pods pour vous assurer que la détection de services fonctionne comme prévu.

Étapes suivantes