Se connecter aux services sur site via un réseau hybride à l'aide de Private Service Connect et d'un NEG hybride avec l'équilibreur de charge HTTP(S) interne

1. Introduction

Cloud Load Balancing prend en charge le trafic d'équilibrage de charge vers des points de terminaison qui vont au-delà de Google Cloud, tels que des centres de données sur site et d'autres clouds publics que vous pouvez atteindre en utilisant la connectivité hybride.

Une stratégie hybride est une solution pragmatique qui vous permet de vous adapter à l'évolution des demandes du marché et de moderniser progressivement vos applications. Il peut s'agir d'un déploiement hybride temporaire pour permettre la migration vers une solution cloud moderne ou d'un dispositif permanent de l'infrastructure IT de votre organisation.

La configuration de l'équilibrage de charge hybride vous permet également de bénéficier des avantages des fonctionnalités réseau de Cloud Load Balancing pour les services exécutés sur votre infrastructure existante en dehors de Google Cloud.

Si vous souhaitez que le service hybride soit disponible dans d'autres réseaux VPC, vous pouvez utiliser Private Service Connect pour publier le service. En plaçant un rattachement de service devant votre équilibreur de charge HTTP(S) interne régional,vous pouvez permettre aux clients d'autres réseaux VPC d'accéder aux services hybrides exécutés sur site ou dans d'autres environnements cloud.

Objectifs de l'atelier

Dans cet atelier de programmation, vous allez créer un équilibreur de charge HTTP(S) interne avec une connectivité hybride vers un service sur site à l'aide d'un groupe de points de terminaison réseau. Le VPC client pourra communiquer avec le service sur site à l'aide des ports 80. Le port 443 n'entre pas dans le champ d'application de cet atelier de programmation.

Remarque : Le codelab propose des étapes de configuration et de validation basées sur la topologie illustrée. Modifiez la procédure si nécessaire pour répondre aux exigences de votre organisation. Les autorisations IAM ne sont pas incluses dans l'atelier de programmation.

Points abordés

• Créer un équilibreur de charge HTTP(S) interne avec un backend de NEG hybride
• Établir un producteur (rattachement de service) et un client (règle de transfert) Private Service Connect

Remarque : Cet atelier de programmation est axé sur l'implémentation d'un équilibreur de charge HTTP(S) interne avec PSC. La configuration du réseau hybride n'est pas documentée, bien que des documents et des captures d'écran complémentaires soient fournis.

Prérequis

• Mise en réseau hybride établie (par exemple, VPN haute disponibilité, interconnect, SW-WAN)
• Projet Google Cloud

Établir une connectivité hybride

Votre environnement Google Cloud et vos environnements sur site ou dans le cloud doivent être connectés via une connectivité hybride, à l'aide d'un rattachement de VLAN Cloud Interconnect ou de tunnels Cloud VPN avec Cloud Router. Nous vous recommandons d'utiliser une connexion à haute disponibilité.

Lorsque le routage dynamique global est activé, le routeur Cloud Router apprend le point de terminaison spécifique par l'intermédiaire de BGP et le programme dans votre réseau VPC Google Cloud. Le routage dynamique régional n'est pas pris en charge. De même, les routes statiques ne sont pas prises en charge.

Le réseau VPC Google Cloud que vous utilisez pour configurer Cloud Interconnect ou Cloud VPN est le même réseau que celui que vous utilisez pour configurer le déploiement de l'équilibrage de charge hybride. Assurez-vous que les plages CIDR de sous-réseau de votre réseau VPC n'entrent pas en conflit avec vos plages CIDR distantes. Lorsque les adresses IP se chevauchent, les routes de sous-réseau sont prioritaires sur la connectivité à distance.

Pour savoir comment procéder, consultez les articles suivants :

• Documentation de Cloud VPN
• Documentation Cloud Interconnect

Annonces de routage personnalisées

Les sous-réseaux ci-dessous exigent des annonces personnalisées de Cloud Router vers le réseau sur site pour garantir la mise à jour des règles de pare-feu sur site.

Sous-réseau	Description
172.16.0.0/23	Sous-réseau proxy utilisé pour communiquer directement avec le service sur site
130.211.0.0/22, 35.191.0.0/16	Vérification de l'état Google Cloud

2. Avant de commencer

Mettre à jour le projet pour qu'il soit compatible avec l'atelier de programmation

Cet atelier de programmation utilise des $variables pour faciliter l'implémentation de la configuration gcloud dans Cloud Shell.

Dans Cloud Shell, procédez comme suit :

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
psclab=YOUR-PROJECT-NAME
echo $psclab

3. Configuration du producteur

Créer le VPC de producteur

Dans Cloud Shell, effectuez les opérations suivantes :

gcloud compute networks create producer-vpc --project=$psclab --subnet-mode=custom

Créer les sous-réseaux de producteurs

Dans Cloud Shell, procédez comme suit :

gcloud compute networks subnets create subnet-201 --project=$psclab --range=10.10.1.0/24 --network=producer-vpc --region=us-central1

gcloud compute networks subnets create subnet-202 --project=$psclab --range=10.20.1.0/24 --network=producer-vpc --region=us-central1

Réserver une adresse IP pour l'équilibreur de charge interne

Dans Cloud Shell, effectuez les opérations suivantes. L'utilisation de SHARED_VIP n'est pas compatible avec Private Service Connect. Utilisez plutôt GCE_ENDPOINT.

gcloud compute addresses create lb-ip \
    --region=us-central1 \
    --subnet=subnet-202 \
    --purpose=GCE_ENDPOINT

Utiliser la commande compute addresses describe pour afficher l'adresse IP allouée

gcloud compute addresses describe lb-ip  --region=us-central1 | grep address:

Créer les sous-réseaux proxy régionaux

L'allocation du proxy s'effectue au niveau du VPC, et non au niveau de l'équilibreur de charge. Vous devez créer un sous-réseau proxy réservé dans chaque région d'un réseau virtuel (VPC) dans lequel vous utilisez des équilibreurs de charge basés sur Envoy. Si vous déployez plusieurs équilibreurs de charge dans la même région et le même réseau VPC, ils partagent le même sous-réseau proxy réservé pour l'équilibrage de charge.

1. Un client établit une connexion avec l'adresse IP et le port de la règle de transfert de l'équilibreur de charge.
2. Chaque proxy écoute l'adresse IP et le port spécifiés par la règle de transfert de l'équilibreur de charge correspondant. L'un des proxys reçoit la connexion réseau du client et y met fin.
3. Le proxy établit une connexion à la VM de backend ou au point de terminaison approprié dans un NEG, comme déterminé par le mappage d'URL et les services de backend de l'équilibreur de charge.

Vous devez créer des sous-réseaux proxy réservés que votre réseau soit en mode automatique ou personnalisé. Un sous-réseau proxy réservé doit fournir au moins 64 adresses IP. Cela correspond à une longueur de préfixe inférieure ou égale à /26. La taille de sous-réseau recommandée est de /23 (512 adresses proxy réservées).

Remarque : Le sous-réseau proxy réservé nécessite une annonce BGP client sur site, donc routable vers votre réseau sur site. L'accès au service est possible via le sous-réseau proxy fourni.

Dans Cloud Shell, effectuez les opérations suivantes :

gcloud compute networks subnets create proxy-subnet-us-central \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --region=us-central1 \
  --network=producer-vpc \
  --range=172.16.0.0/23

Créer les sous-réseaux NAT Private Service Connect

Créez un ou plusieurs sous-réseaux dédiés à utiliser avec Private Service Connect. Si vous utilisez la console Google Cloud pour publier un service, vous pouvez créer les sous-réseaux pendant cette procédure. Créez le sous-réseau dans la même région que l'équilibreur de charge du service. Vous ne pouvez pas convertir un sous-réseau standard en sous-réseau Private Service Connect.

Dans Cloud Shell, procédez comme suit :

gcloud compute networks subnets create psc-nat-subnet --network=producer-vpc --region=us-central1 --range=100.100.10.0/24 --purpose=private-service-connect

Créer les règles de pare-feu du producteur

Configurez des règles de pare-feu pour autoriser le trafic entre les points de terminaison Private Service Connect et le rattachement de service. Dans cet atelier de programmation, vous avez créé une règle de pare-feu d'entrée autorisant le sous-réseau NAT 100.100.10.0/24 à accéder au rattachement de service Private Service Connect (équilibreur de charge interne).

Dans Cloud Shell, procédez comme suit :

gcloud compute --project=$psclab firewall-rules create allow-to-ingress-nat-subnet --direction=INGRESS --priority=1000 --network=producer-vpc --action=ALLOW --rules=all --source-ranges=100.100.10.0/24

Dans Cloud Shell, créez la règle fw-allow-health-check pour autoriser les vérifications de l'état Google Cloud à atteindre le service sur site (service backend) sur le port TCP 80.

gcloud compute firewall-rules create fw-allow-health-check \
    --network=producer-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --rules=tcp:80

Créez une règle de pare-feu autorisant les entrées pour le sous-réseau proxy réservé afin de permettre à l'équilibreur de charge de communiquer avec les instances backend sur le port TCP 80.

gcloud compute firewall-rules create fw-allow-proxy-only-subnet \
    --network=producer-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=172.16.0.0/23 \
    --rules=tcp:80

Configurer le NEG de connectivité hybride

Lorsque vous créez le NEG, utilisez une ZONE qui réduit la distance géographique entre Google Cloud et votre environnement sur site ou autre environnement cloud. Par exemple, si vous hébergez un service dans un environnement sur site à Francfort, en Allemagne, vous pouvez spécifier la zone Google Cloud europe-west3-a lorsque vous créez le NEG.

De plus, si vous utilisez Cloud Interconnect, la ZONE utilisée pour créer le NEG doit se trouver dans la même région que le rattachement Cloud Interconnect.

Pour en savoir plus sur les régions et zones disponibles, consultez la documentation Compute Engine: Régions et zones disponibles.

Dans Cloud Shell, créez un NEG de connectivité hybride à l'aide de la commande gcloud compute network-endpoint-groups create.

gcloud compute network-endpoint-groups create on-prem-service-neg \
    --network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \
    --zone=us-central1-a \
    --network=producer-vpc

Dans Cloud Shell, ajoutez le point de terminaison IP:Port sur site au NEG hybride.

gcloud compute network-endpoint-groups update on-prem-service-neg \
    --zone=us-central1-a \
    --add-endpoint="ip=192.168.1.5,port=80"

Configurer l'équilibreur de charge

Dans les étapes suivantes, vous allez configurer l'équilibreur de charge (règle de transfert) et associer au groupe de points de terminaison du réseau

Dans Cloud Shell, créez la vérification d'état régionale transmise au service sur site.

gcloud compute health-checks create http http-health-check \
    --region=us-central1 \
    --use-serving-port

Dans Cloud Shell, créez le service de backend pour le backend sur site utilisant un NEG hybride.

 gcloud compute backend-services create on-premise-service-backend \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --protocol=HTTP \
      --health-checks=http-health-check \
      --health-checks-region=us-central1 \
      --region=us-central1

Dans Cloud Shell, ajoutez le backend NEG hybride au service de backend. Pour RATE, saisissez le RATE maximal que le backend doit gérer.

gcloud compute backend-services add-backend on-premise-service-backend \
    --region=us-central1 \
    --balancing-mode=RATE \
    --max-rate-per-endpoint=100 \
    --network-endpoint-group=on-prem-service-neg \
    --network-endpoint-group-zone=us-central1-a

Dans Cloud Shell, créez le mappage d'URL pour acheminer les requêtes entrantes vers le service de backend.

gcloud compute url-maps create on-prem-svc-url-map \
    --default-service on-premise-service-backend \
    --region=us-central1

Créer le proxy HTTP cible

gcloud compute target-http-proxies create proxy-subnet-us-central\
    --url-map=on-prem-svc-url-map \
    --url-map-region=us-central1 \
    --region=us-central1

Créez une règle de transfert pour acheminer les requêtes entrantes vers le proxy. N'utilisez pas le sous-réseau proxy réservé pour créer la règle de transfert.

 gcloud compute forwarding-rules create http-hybrid-neg-fwd-rule \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=producer-vpc \
      --subnet=subnet-202 \
      --address=lb-ip \
      --ports=80 \
      --region=us-central1 \
      --target-http-proxy=proxy-subnet-us-central \
      --target-http-proxy-region=us-central1

4. Valider l'équilibreur de charge

Dans la console Cloud, accédez à Services réseau → Équilibrage de charge → Équilibreurs de charge. Notez que le NEG 1 est "vert", ce qui indique que la vérification de l'état du service sur site a réussi.

Si vous sélectionnez ‘on-premise-svc-url-map', vous obtenez l'adresse IP du frontal et le service de backend.

5. Afficher les routes apprises sur site

Accédez à Réseau VPC → Routes. Notez que le sous-réseau de service sur site appris est 192.168.1.0/27.

6. Valider la connectivité au service sur site

À partir du VPC du producteur, nous allons créer une VM pour tester la connectivité au service sur site. La configuration suivante consiste à associer le service.

Dans Cloud Shell, créez l'instance de test dans le VPC du producteur.

gcloud compute instances create test-box-us-central1 \
    --zone=us-central1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=subnet-201 \
    --no-address

Pour autoriser IAP à se connecter à vos instances de VM, créez une règle de pare-feu qui:

• S'applique à toutes les instances de VM que vous souhaitez rendre accessibles à l'aide d'IAP.
• Autorise le trafic entrant provenant de la plage d'adresses IP 35.235.240.0/20. Cette plage contient toutes les adresses IP utilisées par IAP pour le transfert TCP.

Dans Cloud Shell, créez l'instance de test dans le VPC du producteur.

gcloud compute firewall-rules create ssh-iap \
    --network producer-vpc \
    --allow tcp:22 \
    --source-ranges=35.235.240.0/20

Connectez-vous à test-box-us-central1 à l'aide d'IAP dans Cloud Shell pour valider la connectivité au service sur site en exécutant une commande curl sur l'adresse IP de l'équilibrage de charge. Réessayez en cas de délai avant expiration.

gcloud compute ssh test-box-us-central1 --project=$psclab --zone=us-central1-a --tunnel-through-iap

Effectuer une requête curl pour valider la connectivité au service sur site. Une fois la validation effectuée, quittez la VM pour revenir à l'invite Cloud Shell. Remplacez l'adresse IP de l'équilibreur de charge interne en fonction de la sortie identifiée à l'étape 4.

user@test-box-us-central1:~$ curl -v 10.20.1.2
* Expire in 0 ms for 6 (transfer 0x55b7725c10f0)
*   Trying 10.20.1.2...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55b7725c10f0)
* Connected to 10.20.1.2 (10.20.1.2) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.20.1.2
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< content-type: text/html; charset=utf-8
< accept-ranges: bytes
< etag: "3380914763"
< last-modified: Mon, 05 Dec 2022 15:10:56 GMT
< expires: Mon, 12 Dec 2022 03:17:20 GMT
< cache-control: max-age=0
< content-length: 37
< date: Mon, 12 Dec 2022 03:17:20 GMT
< server: lighttpd/1.4.53
< via: 1.1 google
< 
Welcome to my on-premise service!!

7. Créer le rattachement de service Private Service Connect

Dans les étapes suivantes, nous allons créer le rattachement de service, une fois associé à un point de terminaison client. L'accès au service sur site est possible sans qu'il soit nécessaire d'effectuer un appairage de VPC.

Créer le rattachement de service

Dans Cloud Shell, créez l'attachement de service.

gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=http-hybrid-neg-fwd-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=psc-nat-subnet

Facultatif : si vous utilisez un VPC partagé, créez l'association de service dans le projet de service.

gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=http-hybrid-neg-fwd-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=projects/<hostproject>/regions/<region>/subnetworks/<natsubnet>

Valider le rattachement du service TCP

gcloud compute service-attachments describe service-1 --region us-central1

Facultatif : Accédez à Services réseau → Private Service Connect pour afficher le nouveau rattachement de service.

Si vous sélectionnez Service-1, vous obtenez des informations plus détaillées, y compris l'URI du rattachement de service utilisé par le client pour établir une connexion de service privée. Notez l'URI, car vous l'utiliserez dans une étape ultérieure.

Détails du rattachement de service : projects/<nom du projet>/regions/us-central1/serviceAttachments/service-1

8. Configuration client

Créer le VPC consommateur

Dans Cloud Shell, effectuez les opérations suivantes :

gcloud compute networks create consumer-vpc --project=$psclab --subnet-mode=custom

Créer les sous-réseaux de client

Dans Cloud Shell, créez le sous-réseau GCE

gcloud compute networks subnets create subnet-101 --project=$psclab --range=10.100.1.0/24 --network=consumer-vpc --region=us-central1

Dans Cloud Shell, créez le sous-réseau du point de terminaison du client.

gcloud compute networks subnets create subnet-102 --project=$psclab --range=10.100.2.0/24 --network=consumer-vpc --region=us-central1

Créer le point de terminaison client (règle de transfert)

Dans Cloud Shell, créez l'adresse IP statique qui servira de point de terminaison client.

gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=subnet-102 --addresses 10.100.2.10

Permet d'utiliser l'URI du rattachement de service généré précédemment pour créer le point de terminaison client

Dans Cloud Shell, créez le point de terminaison du client.

gcloud compute forwarding-rules create psc-consumer-1 --region=us-central1 --network=consumer-vpc --address=psc-consumer-ip-1 --target-service-attachment=projects/$psclab/regions/us-central1/serviceAttachments/service-1

9. Valider Private Service Connect pour les clients : VPC client

Dans le VPC du client, vérifiez que la connexion Private Service Connect a bien été établie en accédant à Services réseau → Private Service Connect → Points de terminaison connectés. Notez la connexion psc-consumer-1 établie et l'adresse IP correspondante que nous avons précédemment créées.

Lorsque vous sélectionnez psc-consumer-1, des informations sont fournies, y compris l'URI du rattachement de service.

10. Valider Private Service Connect pour les consommateurs : VPC producteur

Dans le VPC du producteur, vérifiez que la connexion de service privée a bien été établie en accédant à Services réseau → Private Service Connect → Service publié. Notez que la connexion service-1 publiée indique désormais une règle de transfert (point de terminaison de la connexion).

11. Créer une zone DNS privée et un enregistrement A

Créez la zone DNS privée mappée au point de terminaison de connexion PSC pour permettre un accès fluide au producteur depuis n'importe quel hôte du VPC.

Remarque:L'accès à un point de terminaison consommateur via l'appairage de VPC n'est pas disponible.

Depuis Cloud Shell

gcloud dns --project=$psclab managed-zones create codelab-zone --description="" --dns-name="codelab.net." --visibility="private" --networks="consumer-vpc"

gcloud dns --project=$psclab record-sets create service1.codelab.net. --zone="codelab-zone" --type="A" --ttl="300" --rrdatas="10.100.2.10"

12. Valider l'accès du client au service Producers à l'aide d'une VM

À partir du VPC des consommateurs, nous allons créer une VM pour tester la connectivité au service sur site en accédant au point de terminaison du service consommateur service1.codelabs.net.

Dans Cloud Shell, créez l'instance de test dans le VPC du client.

gcloud compute instances create consumer-vm \
    --zone=us-central1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=subnet-101 \
    --no-address

Pour autoriser IAP à se connecter à vos instances de VM, créez une règle de pare-feu qui :

• S'applique à toutes les instances de VM que vous souhaitez rendre accessibles à l'aide d'IAP.
• Autorise le trafic entrant provenant de la plage d'adresses IP 35.235.240.0/20. Cette plage contient toutes les adresses IP utilisées par IAP pour le transfert TCP.

Dans Cloud Shell, créez l'instance de test dans le VPC du client.

gcloud compute firewall-rules create ssh-iap-consumer \
    --network consumer-vpc \
    --allow tcp:22 \
    --source-ranges=35.235.240.0/20

Connectez-vous à l'instance consumer-vm à l'aide d'IAP dans Cloud Shell pour valider la connectivité au service sur site en exécutant une commande curl sur le nom de domaine complet du DNS service1.codelab.net. Réessayez en cas d'expiration du délai.

gcloud compute ssh consumer-vm --project=$psclab --zone=us-central1-a --tunnel-through-iap

Effectuer une requête curl pour valider la connectivité au service sur site. Une fois la sortie validée de la VM, retour à l'invite Cloud Shell

Dans Cloud Shell, exécutez une requête curl

$ curl -v service1.codelab.net
*   Trying 10.100.2.10...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x5650fc3390f0)
* Connected to service1.codelab.net (10.100.2.10) port 80 (#0)
> GET / HTTP/1.1
> Host: service1.codelab.net
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Accept-Ranges: bytes
< ETag: "3380914763"
< Last-Modified: Mon, 05 Dec 2022 15:10:56 GMT
< Expires: Mon, 05 Dec 2022 15:15:41 GMT
< Cache-Control: max-age=0
< Content-Length: 37
< Date: Mon, 05 Dec 2022 15:15:41 GMT
< Server: lighttpd/1.4.53
< 
Welcome to my on-premise service!!

Vous trouverez ci-dessous un exemple de capture du service sur site. Notez que l'adresse IP source 172.16.0.13 provient de la plage de sous-réseau proxy 172.16.0.0/23.

13. Nettoyage du producteur

Supprimer les composants Producer

Dans Cloud Shell, supprimez les instances de test dans le VPC du producteur.

gcloud compute instances delete test-box-us-central1 --zone=us-central1-a --quiet

gcloud compute service-attachments delete service-1 --region=us-central1 --quiet 

gcloud compute forwarding-rules delete http-hybrid-neg-fwd-rule --region=us-central1 --quiet

gcloud compute target-http-proxies delete proxy-subnet-us-central --region=us-central1 --quiet

gcloud compute url-maps delete on-prem-svc-url-map --region=us-central1 --quiet

gcloud compute backend-services delete on-premise-service-backend --region=us-central1 --quiet

gcloud compute network-endpoint-groups delete on-prem-service-neg --zone=us-central1-a --quiet

gcloud compute addresses delete lb-ip --region=us-central1 --quiet

gcloud compute networks subnets delete psc-nat-subnet subnet-201 subnet-202 proxy-subnet-us-central --region=us-central1 --quiet

gcloud compute firewall-rules delete ssh-iap fw-allow-proxy-only-subnet allow-to-ingress-nat-subnet fw-allow-health-check --quiet

gcloud compute health-checks delete http-health-check --region=us-central1 --quiet

gcloud compute networks delete producer-vpc --quiet

14. Nettoyage consommateur

Supprimer des composants de consommateur

Dans Cloud Shell, supprimez les instances de test dans le VPC du client.

gcloud compute instances delete consumer-vm --zone=us-central1-a --quiet

gcloud compute forwarding-rules delete psc-consumer-1 --region=us-central1 --quiet

gcloud compute addresses delete psc-consumer-ip-1 --region=us-central1 --quiet

gcloud compute networks subnets delete subnet-101 subnet-102 --region=us-central1 --quiet

gcloud compute firewall-rules delete ssh-iap-consumer --quiet

gcloud dns record-sets delete service1.codelab.net --type=A --zone=codelab-zone --quiet

gcloud dns managed-zones delete codelab-zone --quiet 

gcloud compute networks delete consumer-vpc --quiet 

15. Félicitations

Félicitations ! Vous avez correctement configuré et validé Private Service Connect avec un équilibreur de charge HTTP(S) interne.

Vous avez créé l'infrastructure du producteur et ajouté un rattachement de service dans le VPC du producteur pointant vers un service sur site. Vous avez appris à créer un point de terminaison client dans le VPC client qui permet de se connecter au service sur site.

Et ensuite ?

Découvrez quelques-uns des ateliers de programmation...

• Utiliser Private Service pour publier et consommer des services avec GKE
• Publier et consommer des services à l'aide de Private Service Connect
• Se connecter aux services sur site via une mise en réseau hybride à l'aide de Private Service Connect et d'un équilibreur de charge proxy TCP interne

Complément d'informations et Vidéos

• Présentation de Private Service Connect
• Qu'est-ce que Private Service Connect ?
• Types d'équilibreurs de charge compatibles

Documents de référence

• Présentation de l'équilibreur de charge HTTP(S) interne
• Présentation des vérifications de l'état
• Publier un service à l'aide de Private Service Connect