1. Introduction
Un équilibreur de charge proxy TCP interne régional avec connectivité hybride vous permet de rendre un service hébergé sur site ou dans d'autres environnements cloud disponible pour les clients de votre réseau VPC.
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 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.
Objectifs de l'atelier
Dans cet atelier de programmation, vous allez créer un équilibreur de charge proxy TCP interne avec connectivité hybride à un service sur site à l'aide d'un groupe de points de terminaison du réseau. Le VPC consommateur pourra communiquer avec le service sur site.
Points abordés
- Créer un équilibreur de charge interne proxy TCP avec un service de backend de NEG hybride
- Établir une connexion Private Service Connect entre un producteur (rattachement de service) et un consommateur (règle de transfert)
- Tester et valider la communication entre le consommateur et le producteur de services
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 situés sur site ou sur d'autres cloud doivent être connectés via une connectivité hybride, en utilisant des rattachements de VLAN Cloud Interconnect ou des 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 que celui que vous utilisez pour configurer le déploiement d'é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 :
Annonces de routage personnalisées
Les sous-réseaux ci-dessous nécessitent des annonces personnalisées du routeur cloud au réseau sur site pour s'assurer que les règles de pare-feu sur site sont mises à jour.
Sous-réseau | Description |
172.16.0.0/23 | Sous-réseau de proxy TCP utilisé pour communiquer directement avec le service sur site |
130.211.0.0/22, 35.191.0.0/16 |
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 du producteur
Dans Cloud Shell, procédez comme suit :
gcloud compute networks create producer-vpc --project=$psclab --subnet-mode=custom
Créer les sous-réseaux du producteur
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
Créer les sous-réseaux de proxy TCP
Le proxy est alloué 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) où 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.
- Un client établit une connexion avec l'adresse IP et le port de la règle de transfert de l'équilibreur de charge.
- 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.
- Le proxy établit une connexion à la VM de backend ou au point de terminaison approprié dans un groupe de points de terminaison du réseau, tel que déterminé par les services de backend et le mappage d'URL 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 /23 (512 adresses proxy réservées).
Dans Cloud Shell, procédez comme suit :
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 l'atelier de programmation, vous avez créé une règle de pare-feu d'entrée permettant au sous-réseau NAT 100.100.10.0/24 d'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 d'état Google Cloud à atteindre le service sur site (service de 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 d'entrée autorisant les services sur site à communiquer avec le sous-réseau proxy sur le port 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 connaître les régions et les 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 l'associer au groupe de points de terminaison du réseau.
Dans Cloud Shell, créez la vérification de l'état régionale transmise au service sur site.
gcloud compute health-checks create tcp on-prem-service-hc \
--region=us-central1 \
--use-serving-port
Dans Cloud Shell, créez le service de backend pour le backend sur site.
gcloud compute backend-services create on-premise-service-backend \
--load-balancing-scheme=INTERNAL_MANAGED \
--protocol=TCP \
--region=us-central1 \
--health-checks=on-prem-service-hc \
--health-checks-region=us-central1
Dans Cloud Shell, ajoutez le backend de NEG hybride au service de backend. Pour MAX_CONNECTIONS, saisissez le nombre maximal de connexions simultanées que le backend doit gérer.
gcloud compute backend-services add-backend on-premise-service-backend \
--network-endpoint-group=on-prem-service-neg \
--network-endpoint-group-zone=us-central1-a \
--region=us-central1 \
--balancing-mode=CONNECTION \
--max-connections=100
Dans Cloud Shell, créez le proxy cible.
gcloud compute target-tcp-proxies create on-premise-svc-tcpproxy \
--backend-service=on-premise-service-backend \
--region=us-central1
Dans Cloud Shell, créez la règle de transfert (ILB).
Créez la règle de transfert à l'aide de la commande gcloud compute forwarding-rules create.
Remplacez FWD_RULE_PORT par un numéro de port unique compris entre 1 et 65 535. La règle de transfert ne transfère que les paquets avec un port de destination correspondant.
gcloud compute forwarding-rules create tcp-ilb-psc \
--load-balancing-scheme=INTERNAL_MANAGED \
--network=producer-vpc \
--subnet=subnet-201 \
--ports=80 \
--region=us-central1 \
--target-tcp-proxy=on-premise-svc-tcpproxy \
--target-tcp-proxy-region=us-central1
Obtenir l'adresse IP de l'équilibreur de charge interne
gcloud compute forwarding-rules describe tcp-ilb-psc --region=us-central1 | grep -i IPAddress:
Example output:
gcloud compute forwarding-rules describe tcp-ilb-psc --region=us-central1 | grep -i IPAddress:
IPAddress: 10.10.1.2
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.
La sélection de ‘on-premise-service-backend' génère l'adresse IP du frontend.
5. Afficher les routes apprises depuis l'environnement 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 des producteurs, nous allons créer une VM pour tester la connectivité au service sur site. Ensuite, nous allons configurer le rattachement de 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 permettre à IAP de se connecter à vos instances de VM, créez une règle de pare-feu qui :
- S'applique à toutes les instances de VM auxquelles vous souhaitez être accessible à l'aide d'IAP.
- Autorise le trafic entrant à partir de la plage d'adresses IP 35.235.240.0/20. Cette plage contient toutes les adresses IP qu'IAP utilise 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 effectuant une requête curl sur l'adresse IP de l'équilibreur de charge. Réessayez en cas de délai d'expiration.
gcloud compute ssh test-box-us-central1 --project=$psclab --zone=us-central1-a --tunnel-through-iap
Effectuez un 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 aux étapes 3 et 4.
deepakmichael@test-box-us-central1:~$ curl -v 10.10.1.2
* Expire in 0 ms for 6 (transfer 0x55b9a6b2f0f0)
* Trying 10.10.1.2...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55b9a6b2f0f0)
* Connected to 10.10.1.2 (10.10.1.2) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.10.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, 05 Dec 2022 15:42:38 GMT
< Cache-Control: max-age=0
< Content-Length: 37
< Date: Mon, 05 Dec 2022 15:42:38 GMT
< Server: lighttpd/1.4.53
<
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 consommateur, l'accès au service sur site est possible sans appairage VPC.
Créer le rattachement de service
Dans Cloud Shell, créez l'association de service.
gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=tcp-ilb-psc --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=psc-nat-subnet
Facultatif : Si vous utilisez un VPC partagé, créez le rattachement de service dans le projet de service.
gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=tcp-ilb-psc --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=projects/<hostproject>/regions/<region>/subnetworks/<natsubnet>
Valider le rattachement de service TCP
gcloud compute service-attachments describe service-1 --region us-central1
8. Facultatif : Accédez à Services réseau → Private Service Connect pour afficher le rattachement de service nouvellement établi.
La sélection de Service-1 fournit plus de détails, y compris l'URI du rattachement de service utilisé par le consommateur pour établir une connexion Private Service. Notez l'URI, car vous en aurez besoin à une étape ultérieure.
Détails du rattachement de service : projects/<nom_du_projet>/regions/us-central1/serviceAttachments/service-1
9. Configuration par le consommateur
Créer le VPC consommateur
Dans Cloud Shell, procédez comme suit :
gcloud compute networks create consumer-vpc --project=$psclab --subnet-mode=custom
Créer les sous-réseaux du consommateur
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 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 du consommateur (règle de transfert)
Dans Cloud Shell, créez l'adresse IP statique qui sera utilisée comme point de terminaison client.
gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=subnet-102 --addresses 10.100.2.10
Utilisons l'URI du rattachement de service généré précédemment pour créer le point de terminaison du consommateur.
Dans Cloud Shell, créez le point de terminaison du consommateur.
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
10. Valider Private Service Connect pour les consommateurs : VPC consommateur
Dans le VPC du consommateur, vérifiez que la connexion Private Service Connect a réussi 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 créées précédemment.
Lorsque vous sélectionnez "psc-consumer-1", des informations supplémentaires s'affichent, y compris l'URI du rattachement de service.
11. Valider le réseau VPC consommateur Private Service Connect – producteur
Dans le VPC du producteur, vérifiez qu'une connexion Private Service Connect a bien été établie en accédant à Services réseau → Private Service Connect → Service publié. Notez que la connexion au service 1 publié indique désormais une règle de transfert (point de terminaison de connexion).
12. 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.
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"
13. Valider l'accès du consommateur au service du producteur à 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 service de point de terminaison consommateur1.codelabs.net.
Dans Cloud Shell, créez l'instance de test dans le VPC consommateur.
gcloud compute instances create consumer-vm \
--zone=us-central1-a \
--image-family=debian-10 \
--image-project=debian-cloud \
--subnet=subnet-101 \
--no-address
Pour permettre à IAP de se connecter à vos instances de VM, créez une règle de pare-feu qui :
- S'applique à toutes les instances de VM auxquelles vous souhaitez être accessible à l'aide d'IAP.
- Autorise le trafic entrant à partir de la plage d'adresses IP 35.235.240.0/20. Cette plage contient toutes les adresses IP qu'IAP utilise pour le transfert TCP.
Dans Cloud Shell, créez l'instance de test dans le VPC consommateur.
gcloud compute firewall-rules create ssh-iap-consumer \
--network consumer-vpc \
--allow tcp:22 \
--source-ranges=35.235.240.0/20
Connectez-vous à consumer-vm à l'aide d'IAP dans Cloud Shell pour valider la connectivité au service sur site en effectuant une requête curl sur le nom de domaine complet DNS service1.codelab.net. Réessayez en cas de délai avant expiration.
gcloud compute ssh consumer-vm --project=$psclab --zone=us-central1-a --tunnel-through-iap
Effectuez un curl pour valider la connectivité au service sur site. Une fois la validation effectuée, quittez la VM pour revenir à l'invite Cloud Shell.
Dans Cloud Shell, effectuez un 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.2 provient de la plage de sous-réseau du proxy TCP 172.16.0.0/23.
14. Nettoyage du producteur
Supprimer les composants Producer
Dans Cloud Shell, supprimez les composants 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 tcp-ilb-psc --region=us-central1 --quiet
gcloud compute target-tcp-proxies delete on-premise-svc-tcpproxy --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 networks subnets delete psc-nat-subnet subnet-201 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 on-prem-service-hc --region=us-central1 --quiet
gcloud compute networks delete producer-vpc --quiet
15. Nettoyage des comptes consommateurs
Supprimer les composants Consumer
Dans Cloud Shell, supprimez les composants du consommateur.
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
16. Félicitations
Félicitations, vous avez configuré et validé Private Service Connect avec le proxy TCP.
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 consommateur dans le VPC consommateur, ce qui permettait la connectivité au service sur site.
Et ensuite ?
Découvrez quelques-uns des ateliers de programmation...
- Publier et consommer des services avec GKE à l'aide de Private Service Connect
- Publier et consommer des services à l'aide de Private Service Connect