De la périphérie au maillage multicluster : applications distribuées à l'échelle mondiale exposées via GKE Gateway et Cloud Service Mesh

Last reviewed 2024-06-30 UTC

Cette architecture de référence décrit les avantages de l'exposition des applications en externe via des passerelles Google Kubernetes Engine (GKE) s'exécutant sur plusieurs clusters GKE au sein d'un maillage de services. Ce guide s'adresse aux administrateurs de plate-forme.

Vous pouvez améliorer la résilience et la redondance de vos services en déployant des applications de manière cohérente sur plusieurs clusters GKE, où chaque cluster devient un domaine de défaillance supplémentaire. Par exemple, l'infrastructure de calcul d'un service avec un objectif de niveau de service (SLO) de 99,9 % lorsqu'il est déployé dans un seul cluster GKE atteint un SLO de 99,9999 % lorsqu'il est déployé sur deux clusters GKE (1 - (0,001)2). Vous pouvez également proposer aux utilisateurs une expérience où les requêtes entrantes sont automatiquement dirigées vers la passerelle d'entrée de maillage la moins latence et la plus disponible.

Si vous souhaitez connaître les avantages de l'exposition d'applications compatibles avec le service mesh qui s'exécutent sur un seul cluster, consultez la section De la périphérie au réseau: exposer les applications d'un maillage de services via GKE Gateway.

Architecture

Le diagramme d'architecture suivant montre comment les données circulent via l'entrée cloud et l'entrée de maillage:

Chiffrement TLS à partir du client, d'un équilibreur de charge et du maillage

Le schéma précédent illustre les scénarios de flux de données suivants:

  • À partir du client qui se termine à l'équilibreur de charge Google Cloud à l'aide de son propre certificat TLS géré par Google
  • À partir de l'équilibreur de charge Google Cloud au proxy d'entrée du réseau maillé à l'aide de son propre certificat TLS autosigné
  • À partir du proxy de la passerelle d'entrée du réseau maillé vers les proxys side-car de la charge de travail à l'aide de mTLS compatible avec le maillage de services

Cette architecture de référence contient les deux couches d'entrée suivantes:

  • Cloud Ingress : dans cette architecture de référence, vous utilisez l'API Kubernetes Gateway (et GKE Gateway Controller) pour programmer la couche d'équilibrage de charge HTTP(S) externe multicluster. L'équilibreur de charge vérifie les proxys d'entrée de maillage dans plusieurs régions, en envoyant des requêtes au cluster opérationnel le plus proche. Il implémente également une stratégie de sécurité Google Cloud Armor.
  • Entrée de maillage : dans le 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.

Lorsque vous utilisez les couches d'entrée ensemble, chaque couche a un rôle complémentaire. Pour atteindre les objectifs suivants, Google Cloud optimise les fonctionnalités les plus appropriées de la couche d'entrée cloud et de la couche d'entrée en réseau maillé:

  • Offrir une faible latence
  • Améliorer la disponibilité
  • Utiliser les fonctionnalités de sécurité de la couche d'entrée cloud
  • Utiliser les fonctionnalités de sécurité, d'autorisation et d'observabilité de la couche d'entrée du maillage

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 est intégrée aux services suivants, elle excelle dans l'exécution de ces services en périphérie, en dehors du maillage:

  • Protection contre les attaques DDoS
  • Pare-feu Cloud
  • Authentification et autorisation
  • Chiffrement

La logique de routage est généralement simple au niveau de la couche d'entrée cloud. Cependant, cela peut être plus complexe pour les environnements multiclusters 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 la plate-forme 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. Tenez compte de ces facteurs pour déterminer les droits d'accès administrateur à cette couche et la manière dont vous accordez cet 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 fournit un point d'entrée pour le trafic entrant dans le maillage de services. La couche fournit également mTLS backend, des règles d'autorisation et une mise en correspondance flexible avec des expressions régulières.

Le déploiement de l'équilibrage de charge d'application externe en dehors du maillage avec une couche d'entrée du maillage offre des avantages considérables, en particulier pour la gestion du trafic Internet. Même si le 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.

Produits et fonctionnalités utilisés

La liste suivante récapitule tous les produits et fonctionnalités Google Cloud utilisés par cette architecture de référence:

  • GKE Enterprise : service Kubernetes géré que vous pouvez utiliser pour déployer et exploiter des applications conteneurisées à grande échelle à l'aide de l'infrastructure de Google. Dans le cadre de cette architecture de référence, chacun des clusters GKE qui diffusent une application doit se trouver dans le même parc.
  • Parcs et passerelles multiclusters : services permettant de créer des applications conteneurisées à grande échelle à l'aide de l'infrastructure de Google et de GKE Enterprise.
  • Google Cloud Armor : service vous aidant à protéger vos applications et vos sites Web contre les attaques par déni de service et les attaques sur le Web
  • Cloud Service Mesh : maillage de services entièrement géré basé sur Envoy et Istio
  • Équilibreur de charge d'application : équilibreur de charge de couche 7 basé sur un proxy vous permettant d'exécuter et de faire évoluer vos services
  • Gestionnaire de certificats : service vous permettant d'acquérir et de gérer des certificats TLS à utiliser avec Cloud Load Balancing

Parcs

Pour gérer les déploiements multiclusters, GKE Enterprise et Google Cloud utilisent des parcs pour regrouper et normaliser logiquement des clusters Kubernetes.

L'utilisation d'un ou de plusieurs parcs peut vous aider à passer de la gestion de clusters individuels à celle de groupes entiers de clusters. Pour réduire les frictions liées à la gestion des clusters, utilisez le principe de parc de l'uniformité de l'espace de noms. Pour chaque cluster GKE d'un parc, assurez-vous de configurer toutes les passerelles d'entrée du réseau maillé de la même manière.

Déployez également des services d'application de manière cohérente afin que le service de lecture de l'équilibre dans le compte d'espace de noms soit associé à un service identique dans chaque cluster GKE du parc. Les principes d'uniformité et de confiance supposés au sein d'un parc vous permettent d'utiliser l'ensemble des fonctionnalités de parc de GKE Enterprise et de Google Cloud.

Les règles de routage est-ouest dans le maillage de services et les règles de trafic sont gérées au niveau de la couche d'entrée du maillage. La couche d'entrée du réseau maillé est déployée sur chaque cluster GKE du parc. Configurez chaque passerelle d'entrée de réseau maillé de la même manière, en respectant le principe d'uniformité des espaces de noms du parc.

Bien qu'il n'y ait qu'un seul cluster de configuration pour GKE Gateway, vous devez synchroniser vos configurations GKE Gateway sur tous les clusters GKE du parc.

Si vous devez désigner un nouveau cluster de configuration, utilisez ConfigSync. ConfigSync permet de s'assurer que toutes ces configurations sont synchronisées sur tous les clusters GKE du parc et d'éviter le rapprochement avec une configuration non actuelle.

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 réseau maillé.

Pour gérer le trafic externe, vous avez besoin d'un équilibreur de charge externe au réseau maillé. Pour automatiser le déploiement, cette architecture de référence utilise Cloud Load Balancing, qui est provisionné via des ressources GKE Gateway.

GKE Gateway et services multiclusters

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 et améliore la ressource Ingress.

Lorsque vous déployez des ressources GKE Gateway sur votre cluster GKE, le contrôleur Gateway surveille les ressources de l'API Gateway et rapproche 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 :

  • Indique si les services backend se trouvent dans un seul cluster GKE ou sont répartis sur plusieurs clusters GKE (dans le même parc).
  • É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 Gateway, ce comportement est contrôlé en spécifiant la classe GatewayClass appropriée. En ce qui concerne les classes Gateway, celles qui peuvent être utilisées dans des scénarios multiclusters ont un nom de classe se terminant par -mc.

Cette architecture de référence explique comment exposer des services d'application de manière externe via un équilibreur de charge d'application externe. Toutefois, lorsque vous utilisez Gateway, vous pouvez également créer un équilibreur de charge d'application interne régional multicluster.

Pour déployer des services d'application dans des scénarios multiclusters, vous pouvez définir les composants de l'équilibreur de charge Google Cloud de deux manières:

Pour en savoir plus sur ces deux approches de déploiement de services d'application, consultez la section Choisir votre API d'équilibrage de charge multicluster pour GKE.

Multi Cluster  Ingress repose sur la création de ressources MultiClusterService. La passerelle multicluster repose sur la création de ressources ServiceExport et la référence aux ressources ServiceImport.

Lorsque vous utilisez une passerelle multicluster, vous pouvez activer les fonctionnalités supplémentaires de l'équilibreur de charge Google Cloud sous-jacent en créant des règles. Le guide de déploiement associé à cette architecture de référence explique comment configurer une stratégie de sécurité Google Cloud Armor pour aider à protéger les services de backend contre les scripts intersites.

Ces ressources de règles ciblent les services backend du parc qui sont exposés sur plusieurs clusters. Dans les scénarios multiclusters, toutes ces règles doivent faire référence à la ressource ServiceImport et au groupe d'API.

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. La passerelle GKE vérifie l'état des proxys d'entrée du réseau maillé, et le réseau maillé, en retour, vérifie l'état des backends d'application.

  • Entrée cloud : dans cette architecture de référence, vous configurez l'équilibreur de charge Google Cloud via GKE Gateway pour qu'il vérifie l'état des proxys d'entrée du réseau maillé sur leurs ports de vérification d'état exposés. Si un proxy de réseau maillé est indisponible, ou si le cluster, le réseau maillé 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 réseau maillé. Dans ce cas, le trafic est acheminé vers un autre proxy de réseau maillé dans un autre cluster ou région GKE.
  • Entrée de réseau maillé : dans l'application de réseau maillé 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.

Considérations de conception

Cette section fournit des conseils pour vous aider à utiliser cette architecture de référence afin de développer une architecture répondant à vos exigences spécifiques en termes de sécurité et de conformité, de fiabilité et de coût.

Sécurité, confidentialité et conformité

Le schéma d'architecture de ce document contient plusieurs éléments de sécurité. Les éléments les plus critiques concernent la configuration du chiffrement et du déploiement des certificats. GKE Gateway s'intègre à Certificate Manager à des fins de sécurité.

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). Vous pouvez faire référence à un gestionnaire de certificats CertificateMap dans la définition de votre Gateway. Le saut suivant se situe entre Google Front End (GFE) et le proxy d'entrée du réseau maillé. Ce saut est chiffré par défaut.

Le chiffrement au niveau du réseau entre les GFE et leurs backends est appliqué automatiquement. 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 entre la passerelle de cluster et l'entrée du réseau maillé, vous pouvez utiliser un certificat autosigné ou public pour chiffrer le trafic. Vous pouvez utiliser un certificat autosigné ou public, 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é à cette architecture de référence.

Pour éviter une mauvaise gestion des certificats, ne réutilisez pas les certificats publics. Utilisez des certificats distincts pour chaque équilibreur de charge du service mesh.

Pour vous aider à créer des entrées DNS externes et des certificats TLS, le guide de déploiement de cette architecture de référence utilise Cloud Endpoints. L'utilisation de Cloud Endpoints vous permet de créer un sous-domaine cloud.goog disponible en externe. Dans les scénarios d'entreprise, utilisez un nom de domaine plus approprié et créez un enregistrement A qui pointe vers l'adresse IP globale de l'équilibreur de charge d'application dans votre fournisseur de services DNS.

Si le maillage de services que vous utilisez exige l'utilisation du protocole TLS, tout le trafic entre les proxys side-car et tout le trafic vers l'entrée de maillage est chiffré. 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.

Fiabilité et résilience

L'un des principaux avantages du modèle de point de terminaison à maillage multicluster et multirégional est qu'il peut utiliser toutes les fonctionnalités du maillage de services pour l'équilibrage de charge est-ouest, comme le trafic entre les services d'application.

Cette architecture de référence utilise une passerelle GKE multicluster pour acheminer le trafic entrant vers le cloud vers un cluster GKE. Le système sélectionne un cluster GKE en fonction de sa proximité avec l'utilisateur (en fonction de la latence), de sa disponibilité et de son état. Lorsque le trafic atteint la passerelle d'entrée Istio (l'entrée du réseau maillé), il est acheminé vers les backends appropriés via le maillage de services.

Une autre approche pour gérer le trafic est-ouest consiste à utiliser des services multiclusters pour tous les services d'application déployés sur des clusters GKE. Lorsque vous utilisez des services multiclusters sur des clusters GKE dans un parc, les points de terminaison des services sont collectés dans un ClusterSet. Si un service doit appeler un autre service, il peut cibler n'importe quel point de terminaison opérationnel pour le deuxième service. Étant donné que les points de terminaison sont choisis de manière tournante, le point de terminaison sélectionné peut se trouver dans une autre zone ou une autre région.

L'un des principaux avantages de l'utilisation d'un service mesh pour le trafic est-ouest plutôt que de services multiclusters est que le service mesh peut utiliser l'équilibrage de charge local. L'équilibrage de charge de la localité n'est pas une fonctionnalité des services multiclusters, mais vous pouvez le configurer via un DestinationRule.

Une fois configuré, un appel d'un service à un autre tente d'abord d'atteindre un point de terminaison de service dans la même zone, puis dans la même région que le service appelant. Enfin, l'appel ne cible un point de terminaison dans une autre région que si un point de terminaison de service dans la même zone ou la même région est indisponible.

Optimisation des coûts

Lorsque cette architecture multiclusters est adoptée de manière générale dans une entreprise, Cloud Service Mesh et la passerelle multi-clusters sont inclus dans l'édition Enterprise de Google Kubernetes Engine (GKE). De plus, GKE Enterprise inclut de nombreuses fonctionnalités qui vous permettent de gérer et de gouverner les clusters, les applications et d'autres processus GKE à grande échelle.

Déploiement

Pour déployer cette architecture, consultez De la périphérie au réseau multicluster : déployez des applications distribuées à l'échelle mondiale via GKE Gateway et Cloud Service Mesh.

Étape suivante

Contributeurs

Auteurs :

Autres contributeurs :