Présentation de la mise en réseau de services

Cette page explique comment déployer des services dans Google Kubernetes Engine (GKE). Utilisez cette page comme guide pour mieux comprendre les aspects de la mise en réseau de services et les fonctionnalités du réseau de service disponibles dans GKE.

Présentation de la mise en réseau de services

La mise en réseau de services est la publication d'applications d'une manière qui imite la propriété, la mise en œuvre ou l'environnement sous-jacent de l'application utilisée par les clients. Dans sa forme la plus simple, un service est un point de terminaison sécurisé, cohérent et disponible via lequel une application est accessible.

Les clients et les applications ont des besoins variés en communication. Il peut s'agir d'une solution aussi simple que d'exposer votre application dans le cluster Kubernetes pour que les pods puissent les consommer, ou tout aussi compliqué que de router le trafic vers votre application depuis des clients Internet à travers le monde. GKE propose de nombreuses manières d'exposer les applications sous forme de services adaptés à vos cas d'utilisation uniques.

Éléments d'un service

L'exposition d'une application aux clients implique trois éléments clés d'un service :

  • Interface : l'interface de l'équilibreur de charge définit le champ d'application dans lequel les clients peuvent accéder au trafic et l'envoyer à celui-ci. Il s'agit de l'emplacement réseau qui écoute le trafic. Elle dispose d'un réseau, d'une région spécifique (ou d'un sous-réseau au sein du réseau), d'une ou de plusieurs adresses IP au sein du réseau, des ports, de protocoles spécifiques et des certificats TLS présentés pour établir des connexions sécurisées.

  • Routage et équilibrage de charge : le routage et l'équilibrage de charge définissent la manière dont vous traitez et acheminez votre trafic. Vous pouvez acheminer le trafic vers des services en fonction de paramètres tels que les protocoles, les en-têtes HTTP et les chemins HTTP. Selon l'équilibreur de charge que vous utilisez, il peut équilibrer le trafic pour offrir une latence plus faible et une résilience accrue à vos clients.

  • Backends : les backends de l'équilibreur de charge sont définis par le type de points de terminaison, la plate-forme d'application et l'intégration de la détection de services de backend. GKE utilise l'intégration de la détection de services pour mettre à jour les backends d'un équilibreur de charge de manière dynamique à mesure que les points de terminaison GKE deviennent opérationnels.

Le schéma suivant illustre ces concepts pour le trafic interne et externe :

Dans ce schéma, l'équilibreur de charge d'application externe écoute le trafic sur l'Internet public via des centaines de points de présence Google dans le monde. Cette interface globale permet d'arrêter le trafic en périphérie, à proximité des clients, avant qu'il ne équilibre la charge du trafic vers ses backends dans un centre de données Google.

L'équilibreur de charge d'application interne écoute le champ d'application de votre réseau VPC, ce qui permet les communications privées en interne. Ces propriétés d'équilibreur de charge sont adaptées à différents types de cas d'utilisation d'application.

Comprendre l'équilibrage de charge GKE

Pour exposer des applications en dehors d'un cluster GKE, GKE fournit un contrôleur d'entrée GKE et un contrôleur de service GKE intégrés qui déploient des équilibreurs de charge pour le compte des utilisateurs de GKE. Cela est identique à l'infrastructure d'équilibrage de charge de la VM, sauf que son cycle de vie est entièrement automatisé et contrôlé par GKE. Les contrôleurs de réseau GKE fournissent un équilibrage de charge de l'adresse IP du pod natif en conteneurs à l'aide d'interfaces rigoureuses et de haut niveau conformes aux normes de l'API Ingress et Service.

Le schéma suivant illustre la manière dont les contrôleurs réseau GKE automatisent la création d'équilibreurs de charge :

Comme le montre le schéma, un administrateur d'infrastructure ou d'application déploie un fichier manifeste déclaratif sur son cluster GKE. Les contrôleurs d'entrée et de service surveillent les ressources réseau GKE (telles que les objets Ingress) et déploient des équilibreurs de charge (ainsi que l'adressage IP, les règles de pare-feu, etc.) en fonction du fichier manifeste.

Le contrôleur continue de gérer l'équilibreur de charge et les backends en fonction des modifications apportées à l'environnement et au trafic. De ce fait, l'équilibrage de charge GKE devient un équilibreur de charge dynamique et autonome avec une interface conçue pour les développeurs.

Choisir la méthode pour exposer votre application

Lorsque vous choisissez une méthode pour exposer votre application dans GKE, le protocole, la régionalisation des applications et le réseau du client sont les principaux facteurs à prendre en compte. Avec la suite de contrôleurs d'entrée et de service de GKE, vous pouvez exposer vos applications en tenant compte de ces facteurs.

Bien que les sections suivantes ne couvrent pas tous les aspects de la mise en réseau des applications, le recours à chacun des facteurs suivants peut vous aider à déterminer la solution la mieux adaptée à vos applications. La plupart des environnements GKE hébergent de nombreux types d'applications, tous ayant des exigences uniques. Il est donc probable que vous utiliserez plusieurs services dans un cluster donné.

Pour consulter un comparatif détaillé des fonctionnalités d'entrée, consultez la page Configuration d'entrée.

Réseau client

Un réseau client désigne le réseau à partir duquel vos clients d'application accèdent à l'application. Cela a une incidence sur l'emplacement d'écoute de l'interface de votre équilibreur de charge. Par exemple, les clients peuvent se trouver dans le même cluster GKE que l'application. Dans ce cas, ils accéderaient à votre application à partir du réseau de clusters, ce qui leur permettrait d'utiliser l'équilibrage de charge ClusterIP Kubernetes natif.

Les clients peuvent également être des clients réseau internes, accédant à votre application à partir du cloud privé virtuel (VPC) ou de votre réseau sur site via Cloud Interconnect.

Les clients peuvent également être externes, et accéder à votre application à partir d'un réseau Internet public. Chaque type de réseau détermine une topologie d'équilibrage de charge différente.

Dans GKE, vous pouvez choisir entre les équilibreurs de charge internes et externes. Interne fait référence au réseau VPC qui est un réseau privé interne non directement accessible sur Internet. Externe fait référence à l'Internet public. Les services ClusterIP sont internes à un seul cluster GKE. Ils sont donc limités à un réseau encore plus petit que le réseau VPC.

Le tableau suivant présente les solutions disponibles pour les réseaux internes et externes.

Type de réseau Solutions disponibles
Interne Service ClusterIP
Service NodePort
Service LoadBalancer interne
Ingress interne
Externe Service NodePort1
Service LoadBalancer externe
Ingress externe
Multi Cluster Ingress

1 Les clusters GKE publics fournissent des adresses IP publiques et privées à chaque nœud GKE, de sorte que les services NodePort puissent être accessibles en interne et en externe.

Protocole

Le protocole est le langage utilisé par vos clients pour communiquer avec l'application. Les applications Voice, de jeu et de faible latence utilisent directement TCP ou UDP, ce qui nécessite des équilibreurs de charge qui ont un contrôle précis au niveau de la couche 4. D'autres applications utilisent le protocole HTTP, HTTPS, gRPC ou HTTP2 et nécessitent des équilibreurs de charge compatibles avec ces protocoles. Les exigences liées au protocole définissent davantage les types de méthodes d'exposition d'application qui conviennent le mieux.

Dans GKE, vous pouvez configurer des équilibreurs de charge de couche 4, qui acheminent le trafic en fonction des informations réseau, telles que le port et le protocole, et les équilibreurs de charge de couche 7, qui connaissent des informations sur les applications telles que les sessions client. Chaque équilibreur de charge offre une compatibilité de protocole spécifique, comme indiqué dans le tableau suivant :

Couches Protocole Solutions disponibles
L4 TCP
UDP		 Service ClusterIP
Service NodePort
Service LoadBalancer interne
Service LoadBalancer externe
L7 HTTP
HTTPS
HTTP2 		Ingress interne
Ingress externe
Multi Cluster Ingress

Régionalité de l'application

La régionalité de l'application fait référence au degré de distribution de votre application sur plusieurs clusters GKE ou régions. L'hébergement d'une instance unique d'une application présente des conditions différentes de l'hébergement d'instances redondantes d'une application sur deux clusters GKE indépendants. L'hébergement d'une application distribuée géographiquement sur cinq clusters GKE pour placer les charges de travail plus près de l'utilisateur final à des fins de latence réduite nécessite une connaissance encore plus étendue et multirégionale de l'équilibreur de charge.

Vous pouvez décomposer la régionalité des solutions d'équilibrage de charge GKE en deux catégories :

  • Champ d'application du backend (ou champ d'application du cluster): ce champ d'application indique si un équilibreur de charge peut envoyer du trafic vers des backends sur plusieurs clusters GKE. Multi Cluster Ingress peut exposer une seule adresse IP virtuelle qui dirige le trafic vers les pods de différents clusters et de différentes régions.

  • Champ d'application de l'interface: ce champ d'application indique si une adresse IP d'équilibreur de charge écoute dans une seule région ou plusieurs régions. Tous les équilibreurs de charge externes écoutent sur Internet, qui est fondamentalement multirégional, mais certains équilibreurs de charge internes écoutent dans une seule région uniquement.

Le tableau suivant détaille les solutions d'équilibrage de charge GKE pour ces deux dimensions.

Champ d'application du backend
(champ d'application du cluster)		 Solutions disponibles
Cluster unique Service ClusterIP
Service NodePort
Service LoadBalancer interne
Service LoadBalancer externe
Ingress interne
Ingress externe
Multicluster Entrée multicluster
Champ d'application de l'interface Solutions disponibles
Régional Service ClusterIP
Ingress interne
Monde Service ClusterIP
Service NodePort
Service LoadBalancer interne
Service LoadBalancer externe
Ingress externe
Multi Cluster Ingress

Autres solutions pour l'exposition des applications

Les solutions ci-dessus ne sont pas les seules disponibles pour exposer des applications. Les solutions suivantes peuvent également être des remplacements viables ou des compléments aux équilibreurs de charge GKE.

Entrée dans le cluster

L'entrée dans le cluster fait référence aux contrôleurs d'entrée logiciel dont les proxys d'entrée sont hébergés à l'intérieur du cluster Kubernetes lui-même. Ce service est différent des contrôleurs d'entrée GKE, qui hébergent et gèrent leur infrastructure d'équilibrage de charge séparément du cluster Kubernetes. Ces solutions tierces sont généralement auto-déployées et autogérées par l'opérateur de cluster. istio-ingressgateway et nginx-ingress sont deux exemples de contrôleurs d'entrée dans le cluster, qui sont Open Source et couramment utilisés.

Les contrôleurs d'entrée au sein du cluster sont généralement conformes à la spécification d'entrée de Kubernetes, et offrent diverses fonctionnalités et facilité d'utilisation. Les solutions Open Source sont susceptibles de nécessiter une gestion plus poussée et un niveau d'expertise technique plus élevé, mais elles peuvent répondre à vos besoins si elles fournissent des fonctionnalités spécifiques requises par vos applications. Il existe également un vaste écosystème de solutions d'entrées pour les entreprises, qui reposent sur la communauté Open Source et offrent des fonctionnalités avancées et une assistance aux entreprises.

Groupes de points de terminaison du réseau (NEG) autonomes

Les contrôleurs de service et d'entrée GKE fournissent des méthodes automatisées, déclaratives et natives de Kubernetes pour le déploiement de Cloud Load Balancing. Il existe également des cas d'utilisation valides pour le déploiement manuel d'équilibreurs de charge pour les backends GKE (par exemple, un contrôle direct et plus précis de l'équilibreur de charge, ou un équilibrage de charge entre les backends de VM et conteneurs).

Les NEG autonomes assurent cette possibilité en mettant à jour dynamiquement les adresses IP des backends des pods pour un NEG, tout en autorisant le déploiement manuel de l'interface de l'équilibreur de charge. Cela permet un contrôle maximal et direct de l'équilibreur de charge, tout en conservant les backends dynamiques contrôlés par le cluster GKE.

Maillage de services

Les maillages de services fournissent un équilibrage de charge côté client via un plan de contrôle centralisé. Traffic Director et Anthos Service Mesh permettent d'équilibrer la charge du trafic interne entre les clusters GKE, entre les régions, ainsi qu'entre les conteneurs et les VM. Cela floute la ligne entre l'équilibrage de charge interne (trafic est-ouest) et l'exposition de l'application (trafic nord-sud). Grâce à la flexibilité et à la portée des plans de contrôle modernes du maillage de services, il est plus que jamais probable que le client et le serveur soient accessibles dans le même champ d'application du maillage de services. Les solutions Service et Ingress GKE ci-dessus déploient généralement des équilibreurs de charge proxy intermédiaires pour les clients qui ne disposent pas de leurs propres proxys side-car. Toutefois, si un client et un serveur se trouvent dans le même maillage, l'exposition des applications peut être traitée via le maillage plutôt que via l'équilibrage de charge proxy intermédiaire.

Étapes suivantes