De la périphérie au réseau : exposer les applications d'un maillage de services via GKE Gateway

Last reviewed 2023-10-24 UTC

Cette architecture de référence explique comment combiner Cloud Service Mesh à Cloud Load Balancing pour exposer les applications d'un maillage de services à des clients Internet.

Cloud Service Mesh est un maillage de services géré, basé sur Istio, qui fournit une couche de communication observable, standardisée et à la sécurité renforcée pour les applications. Un maillage de services fournit une plate-forme de communication globale pour les clients qui communiquent via le maillage. Toutefois, il reste un défi à relever pour connecter des clients situés en dehors du maillage à des applications hébergées dans le maillage.

Vous pouvez exposer une application à des clients de différentes manières selon l'emplacement des clients. Cette architecture de référence s'adresse aux professionnels avancés qui utilisent Cloud Service Mesh, mais elle fonctionne également pour Istio sur Google Kubernetes Engine (GKE).

Passerelle d'entrée du réseau maillé

Istio 0.8 a introduit la passerelle d'entrée du maillage. La passerelle fournit un ensemble dédié de proxys dont les ports sont exposés au trafic provenant de l'extérieur du maillage de services. Ces proxys d'entrée du maillage vous permettent de contrôler le comportement d'exposition du réseau séparément de celui du routage des applications.

Les proxys vous permettent également d'appliquer le routage et la règle au trafic externe au réseau maillé avant qu'il n'atteigne un side-car d'application. L'entrée de réseau maillé définit le traitement du trafic lorsqu'il atteint un nœud du maillage, mais les composants externes doivent définir la façon dont le trafic arrive au maillage.

Pour gérer ce trafic externe, vous avez besoin d'un équilibreur de charge externe au maillage. Cette architecture de référence utilise Google Cloud Load Balancing provisionné via des ressources GKE Gateway afin d'automatiser le déploiement.

Pour Google Cloud, l'exemple canonique de cette configuration est un service d'équilibrage de charge externe qui déploie un équilibreur de charge réseau public (L4). Cet équilibreur de charge pointe vers les NodePorts d'un cluster GKE. Ces NodePorts exposent les pods de passerelle d'entrée Istio, qui acheminent le trafic vers les proxys side-car du réseau maillé en aval.

Architecture

Le schéma suivant illustre cette topologie. L'équilibrage de charge pour le trafic privé interne ressemble à cette architecture, à la différence que vous déployez un équilibreur de charge réseau interne à stratégie directe à la place.

Un équilibreur de charge externe achemine les clients externes vers le maillage via des proxys de passerelle d'entrée.

Le schéma précédent montre que l'utilisation de l'équilibrage de charge transparent de couche 4 avec une passerelle d'entrée du maillage offre les avantages suivants :

  • La configuration simplifie le déploiement de l'équilibreur de charge.
  • L'équilibreur de charge fournit une adresse IP virtuelle (VIP) stable, une vérification d'état et une répartition du trafic fiable en cas de modifications du cluster, d'interruptions de nœud ou de pannes de processus.
  • Toutes les règles de routage, l'arrêt TLS et la règle de trafic sont gérés de façon centralisée dans la passerelle d'entrée du maillage.

GKE Gateway et services

Il existe de nombreuses façons d'accorder l'accès aux applications aux clients situés en dehors du cluster. GKE Gateway est une implémentation de l'API Kubernetes Gateway. GKE Gateway fait évoluer la ressource Ingress et l'améliore.

Lorsque vous déployez des ressources GKE Gateway sur votre cluster GKE, le contrôleur Gateway surveille les ressources de l'API Gateway et consolide les ressources Cloud Load Balancing pour mettre en œuvre le comportement de mise en réseau spécifié par les ressources GKE Gateway.

Lorsque vous utilisez GKE Gateway, le type d'équilibreur de charge que vous utilisez pour exposer les applications aux clients dépend principalement des facteurs suivants :

  • État des clients (externe ou interne)
  • Capacités requises de l'équilibreur de charge, y compris la possibilité de s'intégrer à des règles de sécurité Google Cloud Armor
  • Exigences de couverture du maillage de services. Les maillages de services peuvent s'étendre sur plusieurs clusters GKE ou être contenus dans un seul cluster.

Dans GKE Gateway, ce comportement est contrôlé en spécifiant la classe GatewayClass appropriée.

Bien que l'équilibreur de charge par défaut pour Cloud Service Mesh soit l'équilibreur de charge réseau, cette architecture de référence se concentre sur l'équilibreur de charge d'application externe (L7). L'équilibreur de charge d'application externe fournit une intégration avec des services de périphérie tels que Identity-Aware Proxy et Google Cloud Armor, des redirections et des réécritures d'URL, ainsi qu'un réseau distribué de proxys de périphérie à l'échelle mondiale. La section suivante décrit l'architecture et les avantages liés à l'utilisation de deux couches d'équilibrage de charge HTTP.

Entrée cloud et entrée du réseau maillé

Le déploiement de l'équilibrage de charge de couche 7 externe en dehors du maillage avec une couche d'entrée du maillage offre des avantages considérables, en particulier pour le trafic Internet. Même si Cloud Service Mesh et les passerelles d'entrée Istio fournissent un routage et une gestion de trafic avancés dans le maillage, certaines fonctions sont mieux adaptées à la périphérie du réseau. L'utilisation de la mise en réseau en périphérie d'Internet via l'équilibreur de charge d'application externe de Google Cloud peut offrir des avantages significatifs en termes de performances, de fiabilité ou de sécurité par rapport à une entrée basée sur le maillage. En voici quelques exemples :

Cette couche externe de l'équilibrage de charge de couche 7 est appelée entrée cloud, car elle est basée sur des équilibreurs de charge gérés par le cloud et non sur les proxys auto-hébergés utilisés par l'entrée de maillage. La combinaison de l'entrée cloud et de l'entrée de maillage utilise des fonctionnalités complémentaires de l'infrastructure Google Cloud et du maillage. Le schéma suivant montre comment associer l'entrée cloud (via GKE Gateway) et l'entrée de maillage afin de créer deux couches d'équilibrage de charge pour le trafic Internet.

L'entrée cloud fait office de passerelle pour le trafic externe vers le maillage via le réseau VPC.

Dans la topologie du schéma précédent, la couche d'entrée cloud récupère le trafic depuis l'extérieur du maillage de services et le dirige vers la couche d'entrée du maillage. La couche d'entrée du maillage dirige ensuite le trafic vers les backends d'application hébergés par le maillage.

Topologie d'entrée dans le cloud et dans le réseau maillé

Cette section décrit les rôles complémentaires de chaque couche d'entrée lorsque vous les utilisez conjointement. Ces rôles ne constituent pas des règles concrètes mais plutôt des consignes qui permettent d'exploiter au mieux les avantages de chaque couche. Il existe probablement des variantes de ce modèle, en fonction de votre cas d'utilisation.

  • Entrée cloud : lorsqu'elle est associée à une entrée de maillage, la couche d'entrée cloud est mieux adaptée à la sécurité périphérique et à l'équilibrage de charge global. Étant donné que la couche d'entrée cloud bénéficie de fonctions intégrées pour la protection contre les attaques DDoS, les pare-feu cloud, l'authentification et les produits de chiffrement en périphérie, cette couche excelle dans l'exécution de ces services en dehors du maillage. La logique de routage est généralement simple à ce niveau, mais elle peut devenir plus complexe pour les environnements multicluster et multirégionaux. En raison de la fonction essentielle des équilibreurs de charge Internet, la couche d'entrée cloud est souvent gérée par une équipe chargée de l'infrastructure qui dispose d'un contrôle exclusif sur l'exposition et la sécurité des applications sur Internet. Ce contrôle rend cette couche moins flexible et dynamique qu'une infrastructure axée sur le développeur, ce qui peut influer sur les personnes auxquelles vous choisissez d'accorder un accès administrateur et sur la manière dont vous procédez pour accorder un tel accès.
  • Entrée de réseau maillé : Lorsqu'elle est associée à un objet d'entrée cloud, la couche d'entrée du maillage permet un routage flexible proche de l'application. En raison de sa flexibilité, l'entrée de maillage est préférable à l'entrée cloud pour une logique de routage complexe et pour une visibilité au niveau de l'application. La séparation entre les couches d'entrée permet également aux propriétaires d'applications de contrôler directement cette couche sans affecter les autres équipes. Pour aider à sécuriser les applications lorsque vous exposez des applications de maillage de services via un équilibreur de charge de niveau 4 au lieu d'un équilibreur de charge de niveau 7, vous devez interrompre le protocole TLS client sur la couche d'entrée du maillage au sein du maillage.

Vérification de l'état

La vérification de l'état peut être compliquée lorsque vous utilisez deux couches d'équilibrage de charge de couche 7. Vous devez configurer chaque équilibreur de charge pour qu'il vérifie l'état de la couche suivante afin de garantir la réception du trafic. La topologie du schéma suivant montre comment l'entrée cloud vérifie l'état des proxys d'entrée du maillage et comment le maillage, en retour, vérifie l'état des backends d'application.

Le contrôleur d'entrée cloud vérifie l'état de l'entrée du maillage, tandis que l'entrée de maillage vérifie l'état des backends de l'application.

La topologie précédente implique les considérations suivantes :

  • Entrée cloud : dans cette architecture de référence, vous configurez l'équilibreur de charge Google Cloud via l'objet Gateway pour qu'il vérifie l'état des proxys d'entrée du maillage sur leurs ports de vérification d'état exposés. Si un proxy de maillage est indisponible, ou si le cluster, le maillage ou la région n'est pas disponible, l'équilibreur de charge de Google Cloud détecte cette condition et n'envoie pas de trafic au proxy de maillage.
  • Entrée de maillage : dans l'application de maillage, vous effectuez directement les vérifications de l'état des backends afin de pouvoir exécuter l'équilibrage de charge et gérer le trafic localement.

Sécurité

La topologie précédente implique également plusieurs éléments de sécurité. L'un des éléments les plus critiques concerne la configuration du chiffrement et du déploiement des certificats. GKE Gateway s'intègre aux certificats gérés par Google. Vous pouvez faire référence à un gestionnaire de certificats CertificateMap dans la définition de votre objet Gateway. Les clients Internet s'authentifient auprès des certificats publics et se connectent à l'équilibreur de charge externe en tant que premier saut dans le cloud privé virtuel (VPC).

Le saut suivant, situé entre Google Front End (GFE) et le proxy d'entrée du maillage, est chiffré par défaut. Le chiffrement au niveau du réseau entre les GFE et leurs backends est appliqué automatiquement. Toutefois, si vos exigences de sécurité impliquent que le propriétaire de la plate-forme conserve la propriété des clés de chiffrement, vous pouvez activer HTTPS/2 avec le chiffrement TLS entre la passerelle du cluster (GFE) et l'entrée de maillage (instance de proxy Envoy). Lorsque vous activez HTTP/2 avec le chiffrement TLS pour ce chemin d'accès, vous pouvez utiliser un certificat autosigné ou public pour chiffrer le trafic, car le GFE ne s'authentifie pas auprès de celui-ci. Cette couche de chiffrement supplémentaire est décrite dans le guide de déploiement associé. Pour éviter une mauvaise gestion des certificats, ne réutilisez pas le certificat public de l'équilibreur de charge public à un autre endroit. Nous vous recommandons plutôt d'utiliser des certificats distincts dans le maillage de services.

Si le maillage de services exige l'utilisation du protocole TLS, tout le trafic est chiffré entre les proxys side-car et l'entrée de maillage. Le schéma suivant illustre le chiffrement HTTPS du client vers l'équilibreur de charge Google Cloud, de l'équilibreur de charge vers le proxy d'entrée du maillage, et du proxy d'entrée vers le proxy side-car.

La sécurité est mise en œuvre à l'aide de certificats gérés en dehors du réseau maillé et de certificats internes à l'intérieur du maillage.

Optimisation des coûts

Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :

Déploiement

Pour déployer cette architecture, consultez la page De la périphérie au réseau : déployer des applications de maillage de services via GKE Gateway.

Étapes suivantes