À 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 champs d'application Cloud DNS, des services multiclusters (MCS) et de l'annuaire des services.

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

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 point de terminaison. La découverte des services permet de s'assurer que les applications ont toujours accès aux adresses IP de pod à jour, même lorsque les pods sont reprogrammé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 des services offre les avantages suivants :

  • Gestion des applications simplifiée : la détection de services élimine le besoin de coder en dur les adresses IP dans les configurations de votre application. Les applications communiquent à l'aide de noms de service 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 de pod peuvent changer en raison du scaling ou de la reprogrammation.
  • Scaling et résilience simplifiés : la détection de services simplifie le scaling en dissociant les consommateurs de services des adresses IP de pod, qui changent fréquemment. Lorsque votre application évolue ou que 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 des services permet de s'assurer que les requêtes adressées au nom de service stable ne sont dirigées que vers des pods sains, ce qui permet à votre application de faire l'objet d'un scaling ou de se remettre d'une défaillance sans intervention manuelle ni reconfiguration du client.
  • Haute disponibilité : GKE utilise l'équilibrage de charge avec détection de services pour garantir une haute disponibilité et améliorer la réactivité de vos applications, même en cas de charge élevée.

Équilibrage de charge avec la détection de services

GKE contribue à assurer une haute disponibilité pour 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 le trafic entrant de manière uniforme 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 Google Cloud équilibreurs de charge. 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 de cloud privé virtuel. 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 (pour les services externes) ne dirigent le trafic que vers des instances saines. Google Cloud

Cas d'utilisation de 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 indépendants plus petits qui doivent interagir. La découverte des 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 des services facilite les mises à jour sans temps d'arrêt pour les applications, y compris les déploiements contrôlés et les déploiements Canary. Elle 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 pendant le déploiement et d'assurer une transition fluide pour les utilisateurs. La découverte des services améliore également la résilience. Lorsqu'un pod échoue dans GKE, un nouveau pod est déployé, et la découverte des services enregistre le nouveau pod et y redirige le trafic, ce qui permet de réduire les temps d'arrêt des applications.

Fonctionnement de la détection de services

Dans GKE, les applications se composent souvent de plusieurs pods qui doivent se trouver et communiquer entre eux. La découverte des services fournit cette fonctionnalité à l'aide du système de noms de domaine (DNS). Comme 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, quel que soit l'endroit où 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 d'autres pods en combinant des enregistrements DNS générés automatiquement et 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.

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ée 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 : fournit 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 gérer les requêtes DNS.
  • Adresse IP du service kube-dns : 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 à l'aide du DNS. Les composants suivants fonctionnent ensemble pour résoudre les requêtes DNS dans votre cluster :

  • kube-dns: fournisseur DNS par défaut dans le cluster pour 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 afin de créer les enregistrements DNS nécessaires.
  • Cloud DNS : service DNS entièrement géré de Google. Google CloudIl offre une alternative hautement évolutive et fiable à kube-dns et est 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 collaboration avec kube-dns ou Cloud DNS pour traiter les requêtes DNS localement, ce qui 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 offre plus de contrôle sur la configuration et les ressources kube-dns.

Sélectionner votre fournisseur DNS

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

Fournisseur Fonctionnalités Quand la choisir
`kube-dns` Résolution DNS dans le cluster pour les services et les pods. Tous les clusters ayant des besoins de mise en réseau standards. La nouvelle version de `kube-dns` convient aux clusters à petite et grande échelle.
Cloud DNS Fonctionnalités DNS avancées (zones privées, direction du trafic, équilibrage de charge mondial) et intégration à d'autres Google Cloud services. Exposition externe des services, environnements multiclusters ou pour clusters avec des taux de requêtes DNS élevés (RPS).
Déploiement `kube-dns` personnalisé Contrôle supplémentaire sur la configuration, l'allocation des ressources et la 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 en utilisant les méthodes suivantes :

Champ d'application Cloud DNS

Les clusters qui utilisent Cloud DNS pour les services DNS de cluster peuvent fonctionner 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 manière équivalente à 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 que depuis le 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.
  • Champ d'application 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 multiclusters

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

Les MCS exploitent la détection de services basée sur le DNS pour connecter des 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 GKE Dataplane V2) sur chaque nœud, ce qui contribue à assurer une communication et un équilibrage de charge efficaces entre les clusters.

Annuaire des services pour GKE

L'annuaire des services pour GKE fournit un registre unifié pour la découverte des services dans vos déploiements Kubernetes et non-Kubernetes. 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étection de 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 la page Configurer l'annuaire des services pour GKE.

Optimiser les performances DNS et bonnes pratiques

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

Optimiser les performances avec NodeLocal DNSCache

Pour les clusters à forte densité de pods ou les applications qui génèrent un volume élevé de requêtes DNS, vous pouvez améliorer la 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 réduit la latence et le trafic réseau.

Pour en savoir plus sur l'activation et la configuration de cette fonctionnalité, consultez la page 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 faire évoluer 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, et ses paramètres peuvent être ajustés pour déployer plus de répliques plus tôt.

Pour obtenir des instructions détaillées, consultez Configurer un déploiement kube-dns personnalisé.

Bonnes pratiques générales

  • Sélectionner le fournisseur DNS approprié : choisissez votre fournisseur DNS en fonction de vos besoins de cluster. Cloud DNS est recommandé pour les charges de travail à RPS élevé, les environnements multiclusters et lorsque vous avez besoin d'une intégration à votre réseau VPC plus large. La nouvelle version de kube-dns convient à un large éventail de clusters, des petits aux grands, qui ont des besoins standards de détection de services dans le cluster.
  • Éviter les VM Spot ou les VM 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 des VM préemptives. Les arrêts inattendus de nœuds peuvent entraîner des problèmes de résolution DNS.
  • Utiliser 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.
  • Organiser avec des espaces de noms : utilisez des espaces de noms Kubernetes pour regrouper les services associés. Cette approche permet d'éviter les conflits de noms et d'améliorer l'organisation des ressources du cluster.
  • Surveiller et valider le DNS : surveillez régulièrement les métriques et les journaux DNS pour identifier les problèmes potentiels avant qu'ils n'aient un impact sur 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.

Étape suivante