Mise en réseau de services pour les applications distribuées dans Cross-Cloud Network

Last reviewed 2024-05-31 UTC

Ce document fait partie d'une série de guides de conception pour Cross-Cloud Network.

Cette série comprend les parties suivantes :

Ce document explique comment assembler une application à partir d'un ensemble de composants de service créés ou choisis. Nous vous recommandons de lire l'intégralité du document avant de suivre les étapes.

Ce document vous guide tout au long des décisions suivantes :

  • Créer vous-même le service individuel ou utiliser un service tiers.
  • Indiquer si le service est disponible au niveau mondial ou régional.
  • Indiquer si le service est utilisé sur site, dans d'autres clouds ou dans aucun des deux.
  • Accéder au point de terminaison du service via un VPC de services partagés ou distribuer les points de terminaison via tous les VPC d'application concernés.

Ce document vous guide tout au long des étapes suivantes :

  1. Déterminer si votre application est mondiale ou régionale.
  2. Choisir des services gérés tiers ou créer et publier vos propres services.
  3. Configurer l'accès privé aux points de terminaison du service en mode partagé ou dédié.
  4. Assembler les services en applications pour correspondre à un archétype régional ou global.

Les développeurs définissent la couche réseau de services pour Cross-Cloud Network. À ce stade, les administrateurs ont conçu une couche de connectivité pour le réseau multicloud qui permet de bénéficier d'une certaine flexibilité dans les options de mise en réseau de services décrites dans ce document. Dans certains cas, des contraintes liées à la transitivité limitée entre VPC existent. Nous décrivons ces contraintes lorsqu'elles peuvent avoir une incidence sur les décisions de conception.

Déterminer si votre application est régionale ou mondiale

Déterminez si les clients de l'application que vous créez ont besoin d'un archétype de déploiement régional ou mondial. Vous pouvez obtenir une résilience régionale en répartissant les charges sur les zones d'une région. Vous pouvez obtenir une résilience mondiale en répartissant les charges entre différentes régions.

Tenez compte des facteurs suivants lorsque vous choisissez un archétype :

  • Exigences de disponibilité de l'application
  • Emplacement d'utilisation de l'application
  • Coût

Pour en savoir plus, consultez la section Archétypes de déploiement Google Cloud.

Ce guide de conception explique comment prendre en charge les archétypes de déploiement suivants :

Dans une application distribuée sur plusieurs clouds, différents services de cette application peuvent être fournis par différents fournisseurs de services cloud (CSP) ou par des centres de données privés. Pour garantir une structure de résilience cohérente, placez les services hébergés dans différents CSP dans des centres de données CSP géographiquement proches les uns des autres.

Le schéma suivant illustre une pile d'applications globale distribuée sur plusieurs clouds et différents services d'applications déployés dans différents CSP. Chaque service d'application global dispose d'instances de charge de travail dans différentes régions d'une même CSP.

Pile d'applications globale distribuée sur plusieurs clouds

Définir des services applicatifs et y accéder

Pour assembler votre application, vous pouvez utiliser des services gérés tiers existants, créer et héberger vos propres services applicatifs, ou utiliser une combinaison des deux.

Utiliser des services gérés tiers existants

Choisissez les services gérés tiers que vous pouvez utiliser pour votre application. Déterminez lesquels sont des services régionaux ou des services mondiaux. Déterminez également les options d'accès privé compatibles avec chaque service.

Lorsque vous savez quels services gérés vous pouvez utiliser, vous pouvez déterminer quels services créer.

Créer des services applicatifs et y accéder

Chaque service est hébergé par une ou plusieurs instances de charge de travail auxquelles il est possible d'accéder en tant que point de terminaison unique ou en tant que groupe de points de terminaison.

Le schéma général d'un service d'application est illustré dans le schéma suivant. Le service d'application est déployé sur un ensemble d'instances de charge de travail. (Dans ce cas, une instance de charge de travail peut être une VM Compute Engine, un cluster Google Kubernetes Engine (GKE) ou un autre backend qui exécute du code.) Les instances de charge de travail sont organisées en un ensemble de backends associés à un équilibreur de charge.

Le schéma suivant présente un équilibreur de charge générique avec un ensemble de backends.

Équilibreur de charge avec des backends

Pour parvenir à la répartition de charge choisie et automatiser les basculements, ces groupes de points de terminaison utilisent un équilibreur de charge frontend. En utilisant une instance gérée (MIG), vous pouvez augmenter ou diminuer de façon élastique la capacité en faisant évoluer automatiquement les points de terminaison formant le backend de l'équilibreur de charge. De plus, en fonction des exigences du service d'application, l'équilibreur de charge peut également fournir des services d'authentification, de terminaison TLS et d'autres services spécifiques à la connexion.

Déterminer le champ d'application du service (régional ou mondial)

Déterminez si votre service a besoin d'une résilience régionale ou mondiale, et s'il peut la prendre en charge. Un service logiciel régional peut être conçu pour la synchronisation avec un budget de latence régional. Un service d'application global peut prendre en charge les basculements synchrones entre les nœuds répartis sur plusieurs régions. Si votre application est mondiale, vous voudrez peut-être que les services qui la soutiennent soient également mondiaux. Toutefois, si votre service nécessite une synchronisation entre ses instances pour prendre en charge le basculement, vous devez tenir compte de la latence entre les régions. Pour votre situation, vous devrez peut-être vous appuyer sur des services régionaux avec redondance dans les mêmes régions ou dans des régions proches, ce qui permet une synchronisation à faible latence pour le basculement.

Cloud Load Balancing accepte les points de terminaison hébergés à partir d'une même région ou répartis entre plusieurs régions. Ainsi, vous pouvez créer une couche globale orientée client qui communique avec les couches de service globales, régionales ou hybrides. Choisissez vos déploiements de services pour vous assurer que le basculement réseau dynamique (ou l'équilibrage de charge entre les régions) correspond à l'état de résilience et aux capacités de votre logique d'application.

Le schéma suivant montre comment un service global créé à partir d'équilibreurs de charge régionaux peuvent atteindre les backends d'autres régions, offrant ainsi le basculement automatique entre régions. Dans cet exemple, la logique d'application est globale, et le backend choisi prend en charge la synchronisation entre les régions. Chaque équilibreur de charge envoie principalement des requêtes à la région locale, mais peut basculer vers des régions distantes.

Équilibreurs de charge avec des backends dans différentes régions

  • Un backend global est un ensemble de backends régionaux auxquels un ou plusieurs équilibreurs de charge ont accès.
  • Bien que les backends soient mondiaux, l'interface de chaque équilibreur de charge est régionale.
  • Dans ce modèle d'architecture, les équilibreurs de charge ne distribuent principalement le trafic qu'au sein de leur région, mais peuvent également répartir le trafic vers d'autres régions lorsque les ressources de la région locale ne sont pas disponibles.
  • Un ensemble d'interfaces d'équilibreurs de charge régionaux, chacune accessible depuis d'autres régions et capable d'atteindre les backends d'autres régions, forment un service global.
  • Pour assembler une pile d'applications globale, comme indiqué dans Concevoir des piles d'applications globales, vous pouvez utiliser le routage DNS et les vérifications d'état pour mettre en œuvre un basculement interrégional des interfaces.
  • Les interfaces de l'équilibreur de charge sont elles-mêmes accessibles depuis d'autres régions à l'aide de l'accès mondial (non illustré dans le schéma).

Ce même schéma peut être utilisé pour inclure des services publiés avec un basculement global. Le schéma suivant illustre un service publié qui utilise des backends à l'échelle mondiale.

Équilibreurs de charge accessibles à partir de différentes régions

Dans le schéma, notez que le basculement global est implémenté pour le service publié dans l'environnement de production. L'ajout d'un basculement global dans l'environnement grand public permet de résister aux défaillances régionales dans l'infrastructure d'équilibrage de charge grand public. Le basculement interrégional du service doit être mis en œuvre à la fois dans la logique d'application du service et dans la conception d'équilibrage de charge du producteur de services. Les producteurs de services peuvent implémenter d'autres mécanismes.

Pour déterminer le produit Cloud Load Balancing à utiliser, vous devez d'abord déterminer le type de trafic que vos équilibreurs de charge doivent gérer. Tenez compte des règles générales suivantes :

  • Utilisez un équilibreur de charge d'application pour le trafic HTTP(S).
  • Utilisez un équilibreur de charge réseau proxy pour le trafic TCP autre que HTTP(S). Cet équilibreur de charge proxy est également compatible avec le déchargement TLS.
  • Utilisez un équilibreur de charge réseau passthrough pour conserver l'adresse IP source du client dans l'en-tête, ou pour accepter des protocoles supplémentaires comme UDP, ESP et ICMP.

Pour obtenir des conseils détaillés sur le choix de l'équilibreur de charge le mieux adapté à votre cas d'utilisation, consultez la section Choisir un équilibreur de charge.

Services avec des backends sans serveur

Un service peut être défini à l'aide de backends sans serveur. Le backend de l'environnement de production peut être organisé dans un NEG sans serveur en tant que backend d'un équilibreur de charge. Ce service peut être publié avec Private Service Connect en créant un rattachement de service associé à l'interface de l'équilibreur de charge du producteur. Le service publié peut être utilisé via des points de terminaison Private Service Connect ou des backends Private Service Connect. Si le service nécessite des connexions initiées par le producteur, vous pouvez utiliser un connecteur d'accès au VPC sans serveur pour permettre aux environnements Cloud Run, App Engine standard et fonctions Cloud Run d'envoyer des paquets aux adresses IPv4 internes des ressources d'un réseau VPC. L'accès au VPC sans serveur accepte également l'envoi de paquets à d'autres réseaux connectés au réseau VPC sélectionné.

Méthodes d'accès privé aux services

Votre application peut être composée de services gérés fournis par Google, de services tiers fournis par des fournisseurs externes ou par des groupes de pairs de votre organisation, et de services développés par votre équipe. Certains de ces services peuvent être accessibles sur Internet à l'aide d'adresses IP publiques. Cette section décrit les méthodes que vous pouvez utiliser pour accéder à ces services via le réseau privé. Les types de services suivants existent :

  • API publiques de Google
  • API sans serveur de Google
  • Services gérés publiés par Google
  • Services gérés publiés par des fournisseurs et des pairs
  • Vos services publiés

Gardez ces options à l'esprit lorsque vous lirez les sections suivantes. Selon la façon dont vous allouez vos services, vous pouvez utiliser une ou plusieurs des options d'accès privé décrites.

L'organisation (ou le groupe au sein d'une organisation) qui assemble, publie et gère un service est appelé "producteur de services". Vous et votre application êtes appelés "consommateur du service".

Certains services gérés sont publiés exclusivement à l'aide de services privés Google Cloud. Les conceptions réseau recommandées dans l'article Connectivité interne et mise en réseau VPC peuvent héberger les services publiés avec l'accès privé aux services et Private Service Connect.

Pour obtenir une présentation des options d'accès privé aux services, consultez la section Options d'accès privé aux services.

Nous vous recommandons d'utiliser Private Service Connect pour vous connecter aux services gérés dans la mesure du possible. Pour en savoir plus sur les modèles de déploiement de Private Service Connect, consultez la page Modèles de déploiement Private Service Connect.

Il existe deux types de Private Service Connect, et les différents services peuvent être publiés sous l'un des types suivants :

Les services publiés en tant que points de terminaison Private Service Connect peuvent être consommés directement par d'autres charges de travail. Les services s'appuient sur l'authentification et la résilience fournies par le producteur du service. Si vous souhaitez un contrôle supplémentaire sur l'authentification et la résilience du service, vous pouvez utiliser les backends Private Service Connect pour ajouter une couche d'équilibrage de charge pour l'authentification et la résilience dans le réseau consommateur.

Le schéma suivant illustre les services accessibles via des points de terminaison Private Service Connect :

Accès aux services via des points de terminaison Private Service Connect

Le schéma illustre le modèle suivant :

  • Un point de terminaison Private Service Connect est déployé dans le VPC consommateur, ce qui met le service producteur à la disposition des VM et des nœuds GKE.
  • Les réseaux consommateur et producteur doivent être déployés dans la même région.

Le schéma précédent montre les points de terminaison en tant que ressources régionales. Les points de terminaison sont accessibles depuis d'autres régions grâce à l'accès global.

Pour en savoir plus sur les modèles de déploiement, consultez Modèles de déploiement Private Service Connect.

Les backends Private Service Connect utilisent un équilibreur de charge configuré avec des backends de groupes de points de terminaison du réseau (NEG) Private Service Connect. Pour obtenir la liste des équilibreurs de charge compatibles, consultez À propos des backends Private Service Connect.

Les backends Private Service Connect vous permettent de créer les configurations de backend suivantes :

  • Domaines et certificats détenus par le client devant des services gérés
  • Basculement contrôlé par le client entre des services gérés dans différentes régions
  • Configuration de la sécurité et contrôle des accès centralisés pour les services gérés

Dans le schéma suivant, l'équilibreur de charge global utilise un NEG Private Service Connect en tant que backend pour établir la communication avec le fournisseur de services. Aucune autre configuration réseau n'est requise, et les données sont transmises via le maillage SDN de Google.

Équilibreur de charge global utilisant un groupe de points de terminaison réseau

La plupart des services sont conçus pour des connexions initiées par le consommateur. Lorsque des services doivent initier des connexions à partir du producteur, utilisez des interfaces Private Service Connect.

La transitivité est un élément clé à prendre en compte lors du déploiement de l'accès privé aux services ou de Private Service Connect. Les services publiés ne sont généralement pas accessibles via une connexion d'appairage de réseau VPC ou via Network Connectivity Center. L'emplacement du sous-réseau ou des points de terminaison d'accès aux services dans la topologie du VPC détermine si vous concevez le réseau pour le déploiement de services partagés ou dédiés.

Des options telles que le VPN haute disponibilité et les proxys gérés par le client permettent de communiquer de manière transitive entre les VPC.

Les points de terminaison Private Service Connect ne sont pas accessibles via l'appairage de réseaux VPC. Si vous avez besoin de ce type de connectivité, déployez un équilibreur de charge interne et un NEG Private Service Connect en tant que backend, comme illustré dans le schéma suivant :

Utiliser des NEG pour assurer la connectivité

Vous pouvez accéder aux API Google de manière privée à l'aide de points de terminaison et de backends Private Service Connect. L'utilisation de points de terminaison est généralement recommandée, car le producteur de l'API Google fournit une résilience et une authentification basée sur les certificats.

Créez un point de terminaison Private Service Connect dans chaque VPC dans lequel le service doit être accessible. Comme l'adresse IP du consommateur est une adresse IP privée globale, un seul mappage DNS est requis pour chaque service, même s'il existe des instances de point de terminaison dans plusieurs VPC, comme indiqué dans le schéma suivant :

Private Service Connect avec les API Google

Définir des modèles de consommation de service

Les services peuvent s'exécuter dans divers emplacements : votre réseau VPC, un autre VPC, un centre de données sur site, ou dans le cloud. Quel que soit l'emplacement où la charge de travail du service s'exécute, votre application utilise ces services via un point d'accès, tel que l'un des suivants :

  • Une adresse IP dans un sous-réseau d'accès privé aux services
  • Un point de terminaison Private Service Connect
  • Une adresse IP virtuelle pour un équilibreur de charge utilisant des NEG Private Service Connect

Les points d'accès grand public peuvent être partagés entre plusieurs réseaux ou dédiés à un seul réseau. Déterminez si vous souhaitez créer des points d'accès partagés ou dédiés en fonction de la façon dont votre organisation gère l'accès aux services : elle peut déléguer la tâche de création des points d'accès aux services consommateurs à chaque groupe d'applications ou gérer l'accès aux services de manière consolidée.

La gestion de l'accès aux services implique les activités suivantes :

  • Créer les points d'accès
  • Déployer les points d'accès dans un VPC disposant du type de joignabilité approprié
  • Enregistrer les adresses IP et les URL des points d'accès consommateurs dans le DNS
  • Gérer les certificats de sécurité et la résilience du service dans l'espace consommateur, lors de l'ajout d'un équilibrage de charge devant les points d'accès des consommateurs

Pour certaines organisations, il peut être judicieux d'attribuer la gestion des accès aux services à une équipe centrale, tandis que d'autres peuvent être structurées de manière à donner plus d'indépendance à chaque équipe de consommateurs ou d'applications. L'un des effets secondaires du fonctionnement en mode dédié est que certains éléments sont répliqués. Par exemple, un service est enregistré avec plusieurs noms DNS par groupe d'applications et gère plusieurs ensembles de certificats TLS.

La conception du VPC décrite dans Segmentation et connectivité réseau pour les applications distribuées dans Cross-Cloud Network permet de déployer des points d'accès aux services en mode partagé ou dédié. Les points d'accès client partagés sont déployés dans des VPC de service accessibles depuis n'importe quel autre VPC ou réseau externe. Les points d'accès dédiés aux consommateurs sont déployés dans des VPC d'application, auxquels il n'est possible d'accéder qu'à partir des ressources situées dans ce VPC.

La principale différence entre un VPC de service et un VPC d'application est la connectivité transitoire de point d'accès rendue possible par un VPC de service. Les VPC de service ne sont pas limités à l'hébergement de points d'accès consommateurs. Un VPC peut héberger des ressources d'application, ainsi que des points d'accès partagés pour les consommateurs. Dans ce cas, le VPC doit être configuré et géré en tant que VPC de service.

Accès partagé aux services gérés

Pour toutes les méthodes de consommation de services, y compris Private Service Connect, assurez-vous d'effectuer les tâches suivantes :

  • Déployer les points d'accès des consommateurs de services dans un VPC de services. Les VPC de service disposent d'une joignabilité transitoire vers d'autres VPC.
  • Annoncer le sous-réseau du point d'accès consommateur en tant qu'annonce de routage personnalisée depuis le routeur Cloud Router appairé à d'autres réseaux via un VPN haute disponibilité. Pour les API Google, annoncez l'adresse IP de l'hôte de l'API.
  • Mettez à jour les règles de pare-feu multicloud pour autoriser le sous-réseau d'accès privé aux services.

Pour l'accès aux services privés en particulier, assurez-vous de pouvoir répondre aux exigences supplémentaires suivantes :

  • Exportez des routes personnalisées vers le réseau du producteur de services. Pour en savoir plus, consultez Les hôtes sur site ne peuvent pas communiquer avec le réseau du producteur de services.
  • Créez des règles de pare-feu d'entrée pour autoriser le sous-réseau d'accès privé aux services dans les VPC d'application.
  • Créez des règles de pare-feu d'entrée pour autoriser le sous-réseau d'accès privé aux services dans le VPC des services.

Pour l'accès aux services sans serveur, assurez-vous de pouvoir remplir les conditions suivantes :

  • Le connecteur d'accès nécessite un sous-réseau standard dédié de taille /28
  • Cloud Router annonce par défaut les sous-réseaux standards
  • Créer des règles de pare-feu d'entrée pour tous les sous-réseaux d'accès VPC autorisés au sein du ou des VPC
  • Mettre à jour les règles de pare-feu multicloud pour autoriser le sous-réseau du connecteur d'accès VPC
  • Créer une ou plusieurs règles de pare-feu d'entrée pour autoriser le sous-réseau d'accès privé aux services dans les VPC d'application

Accès aux services gérés dédiés

Assurez-vous d'effectuer les tâches suivantes :

  • Dans chaque VPC d'application où l'accès est nécessaire, déployez une règle de transfert pour le service afin de créer un point d'accès.
  • Pour l'accès privé aux services, créez une ou plusieurs règles de pare-feu d'entrée pour autoriser le sous-réseau d'accès privé aux services à accéder aux VPC de l'application.

Pour l'accès aux services sans serveur, assurez-vous de pouvoir remplir les conditions suivantes :

  • Le connecteur d'accès nécessite un sous-réseau standard dédié de taille /28
  • Créer des règles de pare-feu d'entrée pour autoriser le sous-réseau du connecteur d'accès au VPC au sein du ou des VPC d'application

Assembler la pile d'applications

Cette section décrit l'assemblage d'une pile d'applications régionale ou globale.

Concevoir des piles d'applications régionales

Lorsqu'une application suit les archétypes de déploiement régionaux ou multirégionaux, utilisez des piles d'applications régionales. Les piles d'applications régionales peuvent être considérées comme une concaténation de couches de services d'applications régionales. Par exemple, une couche de service Web régionale qui communique avec une couche d'application dans la même région, qui communique à son tour avec une couche de base de données dans la même région, est une pile d'applications régionale.

Chaque couche de service d'application régionale utilise des équilibreurs de charge pour répartir le trafic entre les points de terminaison de la couche dans cette région. La fiabilité est obtenue en répartissant les ressources de backend sur au moins trois zones de la région.

Les couches de services d'application dans d'autres CSP ou centres de données sur site doivent être déployées dans des régions équivalentes des réseaux externes. Rendez également les services publiés disponibles dans la région de la pile. Pour aligner la pile d'applications dans une région, les URL de la couche de service d'application doivent être résolues en fonction de l'adresse IP régionale spécifique du frontend de l'équilibreur de charge. Ces mappages DNS sont enregistrés dans la zone DNS pertinente pour chaque service d'application.

Le schéma suivant illustre une pile régionale avec une résilience active-standby :

Pile régionale avec résilience active-standby

Une instance complète de la pile d'applications est déployée dans chaque région sur les différents centres de données cloud. Lorsqu'une défaillance régionale se produit sur l'une des couches de service d'application, la pile de l'autre région prend en charge la distribution de l'application entière. Ce basculement est effectué en réponse à une surveillance hors bande des différentes couches de service de l'application.

Lorsqu'un échec est signalé pour l'une des couches de service, l'interface de l'application est de nouveau associée à la pile de sauvegarde. L'application est écrite pour faire référence à un ensemble d'enregistrements de noms régionaux qui reflètent la pile d'adresses IP régionales dans le DNS. Ainsi, chaque couche de l'application maintient ses connexions dans la même région.

Concevoir des piles d'applications globales

Lorsqu'une application suit l'archétype de déploiement d'application global, chaque couche de service d'application inclut des backends dans plusieurs régions. L'inclusion de backends dans plusieurs régions développe le pool de résilience pour la couche de service d'application au-delà d'une seule région et permet d'automatiser la détection de basculement et la reconvergence.

Le schéma suivant illustre une pile d'applications globale :

Pile globale utilisant un projet de hub et un projet d'application

Le schéma précédent montre une application globale assemblée à partir des composants suivants :

  • Services exécutés dans des centres de données sur site avec des interfaces d'équilibreur de charge. Les points d'accès de l'équilibreur de charge sont accessibles via Cloud Interconnect depuis le VPC de transit.
  • Un VPC de transit héberge des connexions hybrides entre le centre de données externe et le VPC d'application.
  • Un VPC d'application qui héberge l'application principale s'exécutant sur des instances de charge de travail. Ces instances de charge de travail se trouvent derrière des équilibreurs de charge. Les équilibreurs de charge sont accessibles depuis n'importe quelle région du réseau et peuvent atteindre des backends dans n'importe quelle région du réseau.
  • Un VPC de services qui héberge des points d'accès pour les services exécutés dans d'autres emplacements, tels que des VPC tiers. Ces points d'accès aux services sont accessibles via la connexion VPN haute disponibilité entre le VPC de services et le VPC de transit.
  • Les VPC de producteurs de services hébergés par d'autres organisations ou l'organisation principale et les applications qui s'exécutent dans d'autres emplacements. Les services concernés sont rendus accessibles par les backends Private Service Connect déployés en tant que backends mondiaux pour les équilibreurs de charge régionaux hébergés dans le VPC de services. Les équilibreurs de charge régionaux sont accessibles depuis n'importe quelle autre région.

Si vous souhaitez que l'application créée soit accessible depuis Internet, vous pouvez ajouter un équilibreur de charge d'application externe global qui pointe vers les charges de travail d'application dans le VPC d'application (non représenté dans le schéma).

Afin de prendre en charge une pile d'applications globale, nous avons utilisé des backends mondiaux pour chaque couche d’application. Cela permet de récupérer en cas de défaillance de tous les points de terminaison de backend dans une région. Chaque région dispose d'une interface d'équilibreur de charge régional pour chaque couche de service d'application. En cas de basculement régional, les interfaces des équilibreurs de charge régionaux internes peuvent être accessibles dans toutes les régions, car elles utilisent l'accès global. La pile d'applications étant globale, les règles de routage de géolocalisation DNS permettent de sélectionner l'interface régionale la plus appropriée pour une requête ou un flux spécifique. En cas de défaillance de l'interface, les vérifications d'état DNS peuvent être utilisées pour automatiser le basculement d'une interface à une autre.

Les services publiés à l'aide de backends Private Service Connect bénéficient de l'accès mondial Private Service Connect. Cette fonctionnalité permet au backend Private Service Connect d'être accessible depuis n'importe quelle région et limite les perturbations dues aux défaillances de la couche de service de l'application. Cela signifie que les backends Private Service Connect peuvent être utilisés comme backends globaux, comme décrit dans Déterminer la portée du service (régional ou global).

Fournir un accès privé aux services hébergés sur des réseaux externes

Vous souhaiterez peut-être publier un point d'accès local pour un service hébergé dans un autre réseau. Dans ce cas, vous pouvez utiliser un équilibreur de charge proxy TCP interne régional avec des NEG hybrides. Vous pouvez créer un service hébergé sur site ou dans d'autres environnements cloud disponibles pour les clients de votre réseau VPC, comme illustré dans le schéma suivant :

Point d'accès local utilisant des NEG hybrides

Si vous souhaitez que le service hybride soit disponible dans un réseau VPC autre que celui qui héberge l'équilibreur de charge, vous pouvez utiliser Private Service Connect pour publier le service. En plaçant un rattachement de service devant votre équilibreur de charge proxy TCP régional interne, vous pouvez permettre aux clients d'autres réseaux VPC d'atteindre les services hybrides exécutés dans des environnements sur site ou dans le cloud.

Dans un environnement multicloud, l'utilisation d'un NEG hybride permet une communication sécurisée entre les applications.

Lorsqu'une autre organisation publie un service d'application, utilisez un NEG hybride pour étendre les abstractions d'accès privé à ce service. Le schéma suivant illustre ce scénario :

NEG hybrides devant des services dans d'autres réseaux

Dans le schéma précédent, la couche de service d'application est entièrement composée dans la CSP voisine, qui est mise en évidence dans les parties du schéma qui ne sont pas grisées. Les équilibreurs de charge hybrides sont utilisés conjointement avec les rattachements de service Private Service Connect en tant que mécanisme de publication du service d'application externe pour une utilisation privée dans Google Cloud. Les équilibreurs de charge hybrides avec NEG hybrides et rattachements de service Private Service Connect se trouvent dans un VPC faisant partie d'un projet producteur de services. Ce projet producteur de services peut généralement être un VPC différent du VPC de transit, car il relève du champ d'application administratif de l'organisation ou du projet producteur, et est donc distinct des services de transport communs. Le VPC producteur n'a pas besoin d'être connecté via un VPC d'apairage ou un VPN haute disponibilité avec le VPC consommateur (qui correspond au VPC de services partagé dans le schéma).

Centraliser l'accès aux services

L'accès aux services peut être centralisé dans un réseau VPC et accessible à partir d'autres réseaux d'applications. Le schéma suivant illustre le modèle commun permettant de centraliser les points d'accès :

VPC de services dédié

Le schéma suivant présente tous les services accessibles à partir d'un VPC de services dédié :

VPC de services dédié avec équilibreurs de charge centralisés

Lorsque les services sont utilisés en interface avec des équilibreurs de charge d'application, vous pouvez consolider sur un nombre réduit d'équilibreurs de charge en utilisant des mappages d'URL pour orienter le trafic de différents backends de services plutôt que d'utiliser différents équilibreurs de charge pour chaque service. En principe, une pile d'applications peut être entièrement composée à l'aide d'un seul équilibreur de charge d'application avec des backends de service et des mappages d'URL appropriés.

Dans cette implémentation, vous devez utiliser des NEG hybrides sur des VPC pour la plupart des types de backend. L'exception concerne un NEG ou un backend Private Service Connect, comme décrit dans la section Chaîne explicite entre des équilibreurs de charge L7 Google Cloud avec Private Service Connect.

L'utilisation de NEG hybrides dans plusieurs VPCs implique de renoncer à l'autoréparation et à l'autoscaling pour les backends. Les services publiés disposent déjà d'un équilibreur de charge dans le locataire producteur qui assure l'autoscaling. Par conséquent, vous ne vous heurtez aux limites des NEG hybrides que si vous centralisez la fonction d'équilibrage de charge pour les couches de service composées de manière native plutôt que de les consommer à partir de l'annonce.

Lorsque vous utilisez ce modèle de mise en réseau de services, n'oubliez pas que les services sont consommés par l'intermédiaire d'une couche supplémentaire d'équilibrage de charge.

Utilisez l'équilibrage de charge proxy pour bénéficier des avantages d'évolutivité du VPC spoke Network Connectivity Center sur tous les VPC, tout en fournissant une connectivité transitoire aux services publiés via les équilibreurs de charge proxy.

Les points de terminaison de service Private Service Connect et les règles de transfert pour l'accès aux services privés ne sont pas accessibles via les VPC spoker Network Connectivity Center. De même, les réseaux derrière des connexions hybrides (Cloud Interconnect ou VPN haute disponibilité) ne sont pas accessibles via les VPC spoke Network Connectivity Center, car les routes dynamiques ne sont pas propagées via Network Connectivity Center.

Ce manque de transitivité peut être résolu en déployant des équilibreurs de charge proxy avec les ressources non transitoires gérées en tant que NEG hybrides. Ainsi, nous pouvons déployer des équilibreurs de charge proxy devant les interfaces de service et devant les charges de travail accessibles par l'intermédiaire de connexions hybrides.

Les interfaces proxy de l'équilibreur de charge sont déployées dans des sous-réseaux VPC qui sont propagés dans les VPC spoke Network Connectivity Center. Cette propagation permet d'accéder aux ressources non transitoires via Network Connectivity Center par l'intermédiaire des équilibreurs de charge proxy.

Le mode centralisé ajoute une couche d'équilibrage de charge au côté consommateur du service. Lorsque vous utilisez ce mode, vous devez également gérer les certificats, la résilience et les mappages DNS supplémentaires dans le projet consommateur.

Autres points à noter

Cette section contient des considérations concernant les produits et services courants qui ne sont pas explicitement abordés dans ce document.

Remarques concernant le plan de contrôle GKE

Le plan de contrôle GKE est déployé dans un projet locataire géré par Google et connecté au VPC du client à l'aide de l'appairage de réseaux VPC. L'appairage réseau VPC n'étant pas transitoire, la communication directe avec le plan de contrôle par l'intermédiaire d'une topologie réseau appairée avec un VPC en étoile est impossible.

Lorsque vous examinez les options de conception de GKE (conception centralisée ou décentralisée), l'accès direct au plan de contrôle à partir de sources multicloud est un élément clé à prendre en compte. Si GKE est déployé dans un VPC centralisé, l'accès au plan de contrôle est disponible sur plusieurs clouds et dans Google Cloud. Toutefois, si GKE est déployé dans des VPC décentralisés, la communication directe vers le plan de contrôle est impossible. Si les exigences d'une organisation nécessitent l'accès au plan de contrôle GKE en plus de l'adoption du modèle de conception décentralisé, les administrateurs réseau peuvent déployer un agent de connexion qui agit en tant que proxy, ce qui permet de contourner la limitation d'appairage non transitoire au plan de contrôle GKE.

Sécurité - VPC Service Controls

Pour les charges de travail impliquant des données sensibles, utilisez VPC Service Controls pour configurer des périmètres de service autour de vos ressources VPC et services gérés par Google, ainsi que pour contrôler le déplacement au-delà des limites des périmètres. Grâce à ce service, vous pouvez regrouper les projets et votre réseau sur site dans un seul périmètre qui empêche l'accès aux données via les services gérés par Google. Les règles d'entrée et de sortie VPC Service Controls peuvent être utilisées pour permettre à des projets et services situés dans différents périmètres de service de communiquer (y compris les réseaux VPC qui ne sont pas à l'intérieur du périmètre).

Pour découvrir les architectures de déploiement recommandées, le processus d'intégration complet et les bonnes pratiques opérationnelles, consultez la section Bonnes pratiques VPC Service Controls pour les entreprises et Plan de base de sécurité.

DNS pour les API/services

Les producteurs de services peuvent publier des services à l'aide de Private Service Connect. Le producteur de services peut éventuellement configurer un nom de domaine DNS à associer au service. Si un nom de domaine est configuré et qu'un client de service crée un point de terminaison qui cible ce service, Private Service Connect et l'Annuaire des services créent automatiquement des entrées DNS pour le service Service situé dans une zone DNS privée du réseau VPC du client de services.

Étapes suivantes

Contributeurs

Auteurs :

  • Victor Moreno | Responsable produit, Mise en réseau cloud
  • Ghaleb Al-habian | Spécialiste réseau
  • Deepak Michael | Ingénieur client spécialiste en gestion des réseaux
  • Osvaldo Costa | Ingénieur client spécialiste en gestion des réseaux
  • Jonathan Almaleh | Consultant solutions techniques pour le personnel

Autres contributeurs :