1. Introduzione
Un bilanciatore del carico proxy TCP regionale interno con connettività ibrida ti consente di rendere disponibile per i client nella tua rete VPC un servizio ospitato in ambienti on-premise o in altri ambienti cloud.
Se vuoi rendere il servizio ibrido disponibile in altre reti VPC, puoi utilizzare Private Service Connect per pubblicarlo. Se posizioni un collegamento a un servizio davanti al bilanciatore del carico proxy TCP a livello di regione interno, puoi consentire ai client in altre reti VPC di raggiungere i servizi ibridi in esecuzione in ambienti on-premise o in altri ambienti cloud.
Cosa creerai
In questo codelab, creerai un bilanciatore del carico proxy TCP interno con connettività ibrida a un servizio on-premise utilizzando un gruppo di endpoint di rete. Dal VPC consumer sarà in grado di comunicare con il servizio on-premise.
Cosa imparerai a fare
- Come creare un bilanciatore del carico interno per proxy TCP con il servizio di backend NEG ibrido
- Come stabilire un producer (collegamento di servizio) e consumer (regola di forwarding) di Private Service Connect
- Come testare e convalidare la comunicazione del servizio da consumatore a producer
Che cosa ti serve
- Rete ibrida stabilita, ad esempio VPN ad alta disponibilità, interconnessione, SW-WAN
- Progetto Google Cloud
Stabilire una connettività ibrida
Google Cloud e gli ambienti on-premise o altri cloud devono essere connessi tramite la connettività ibrida, utilizzando i collegamenti VLAN di Cloud Interconnect o i tunnel Cloud VPN con il router Cloud. Ti consigliamo di utilizzare una connessione ad alta disponibilità.
Un router Cloud abilitato con il routing dinamico globale apprende l'endpoint specifico tramite BGP e lo programma nella tua rete VPC di Google Cloud. Il routing dinamico a livello di regione non è supportato. Anche le route statiche non sono supportate.
La rete VPC di Google Cloud che utilizzi per configurare Cloud Interconnect o Cloud VPN è la stessa che utilizzi per configurare il deployment del bilanciamento del carico ibrido. Assicurati che gli intervalli CIDR della subnet della rete VPC non siano in conflitto con gli intervalli CIDR remoti. Quando gli indirizzi IP si sovrappongono, le route di subnet hanno la priorità sulla connettività remota.
Per istruzioni, vedi:
Annunci di route personalizzati
Le subnet seguenti richiedono annunci personalizzati dal router Cloud alla rete on-premise per garantire l'aggiornamento delle regole firewall on-premise.
Subnet | Descrizione |
172.16.0.0/23 | Subnet proxy TCP utilizzata per comunicare direttamente con il servizio on-premise |
130.211.0.0/22, 35.191.0.0/16 |
2. Prima di iniziare
Aggiornare il progetto per supportare il codelab
Questo codelab utilizza le variabili $per facilitare l'implementazione della configurazione di gcloud in Cloud Shell.
In Cloud Shell, esegui queste operazioni
gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
psclab=YOUR-PROJECT-NAME
echo $psclab
3. Configurazione del producer
Crea il VPC del produttore
In Cloud Shell, esegui queste operazioni
gcloud compute networks create producer-vpc --project=$psclab --subnet-mode=custom
Crea le subnet Producer
In Cloud Shell, esegui queste operazioni
gcloud compute networks subnets create subnet-201 --project=$psclab --range=10.10.1.0/24 --network=producer-vpc --region=us-central1
Crea le subnet proxy TCP
L'allocazione del proxy è a livello di VPC, non a livello di bilanciatore del carico. Devi creare una subnet solo proxy in ogni regione di una rete virtuale (VPC) in cui utilizzi bilanciatori del carico basati su Envoy. Se esegui il deployment di più bilanciatori del carico nella stessa regione e nella stessa rete VPC, questi condividono la stessa subnet solo proxy per il bilanciamento del carico.
- Un client stabilisce una connessione all'indirizzo IP e alla porta della regola di forwarding del bilanciatore del carico.
- Ogni proxy rimane in ascolto sull'indirizzo IP e sulla porta specificati dalla regola di forwarding del bilanciatore del carico corrispondente. Uno dei proxy riceve e termina la connessione di rete del client.
- Il proxy stabilisce una connessione alla VM o all'endpoint di backend appropriati in un NEG, come determinato dalla mappa URL e dai servizi di backend del bilanciatore del carico.
Devi creare subnet solo proxy indipendentemente dal fatto che la rete sia in modalità automatica o personalizzata. Una subnet solo proxy deve fornire almeno 64 indirizzi IP. Corrisponde a una lunghezza del prefisso di /26 o inferiore. La dimensione consigliata della subnet è /23 (512 indirizzi solo proxy).
In Cloud Shell, esegui queste operazioni
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
Crea le subnet NAT Private Service Connect
Crea una o più subnet dedicate da utilizzare con Private Service Connect. Se utilizzi la console Google Cloud per pubblicare un servizio, puoi creare le subnet durante la procedura. Crea la subnet nella stessa regione del bilanciatore del carico del servizio. Non puoi convertire una subnet normale in una subnet Private Service Connect.
In Cloud Shell, esegui queste operazioni
gcloud compute networks subnets create psc-nat-subnet --network=producer-vpc --region=us-central1 --range=100.100.10.0/24 --purpose=private-service-connect
Crea le regole firewall del producer
Configura le regole firewall per consentire il traffico tra gli endpoint Private Service Connect e il collegamento al servizio. Nel codelab è stata creata una regola firewall in entrata che consente alla subnet NAT 100.100.10.0/24 di accedere al collegamento del servizio Private Service Connect (bilanciatore del carico interno).
In Cloud Shell, esegui queste operazioni
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
In Cloud Shell Crea la regola fw-allow-health-check per consentire ai controlli di integrità di Google Cloud di raggiungere il servizio on-premise (servizio di backend) sulla porta 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
Crea una regola firewall in entrata che consenta ai servizi on-premise di comunicare con la subnet proxy sulla porta 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
Configura il NEG di connettività ibrida
Quando crei il NEG,utilizza una ZONE che riduca al minimo la distanza geografica tra Google Cloud e il tuo ambiente on-premise o un altro ambiente cloud. Ad esempio, se ospiti un servizio in un ambiente on-premise a Francoforte, in Germania, puoi specificare la zona europe-west3-a Google Cloud quando crei il NEG.
Inoltre, se utilizzi Cloud Interconnect, la ZONE utilizzata per creare il NEG deve trovarsi nella stessa regione in cui è stato configurato il collegamento di Cloud Interconnect.
Per conoscere le regioni e le zone disponibili, consulta la documentazione di Compute Engine: Regioni e zone disponibili.
All'interno di Cloud Shell, crea un NEG di connettività ibrida utilizzando il comando 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
In Cloud Shell, aggiungi l'endpoint IP:Port on-premise al NEG ibrido.
gcloud compute network-endpoint-groups update on-prem-service-neg \
--zone=us-central1-a \
--add-endpoint="ip=192.168.1.5,port=80"
Configura il bilanciatore del carico
Nei passaggi seguenti configurerai il bilanciatore del carico (regola di forwarding) e associare al gruppo di endpoint di rete
All'interno di Cloud Shell crea il controllo di integrità a livello di regione passato al servizio on-premise.
gcloud compute health-checks create tcp on-prem-service-hc \
--region=us-central1 \
--use-serving-port
In Cloud Shell crea il servizio di backend per il backend on-premise
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
In Cloud Shell, aggiungi il backend del NEG ibrido al servizio di backend. Per MAX_CONNECTIONS, inserisci il numero massimo di connessioni simultanee che deve gestire il backend.
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
In Cloud Shell crea il proxy di destinazione
gcloud compute target-tcp-proxies create on-premise-svc-tcpproxy \
--backend-service=on-premise-service-backend \
--region=us-central1
All'interno di Cloud Shell crea la regola di forwarding (ILB)
Crea la regola di forwarding utilizzando il comando gcloud compute forwarding-rules create.
Sostituisci FWD_RULE_PORT con un singolo numero di porta compreso tra 1 e 65535. La regola di forwarding inoltra solo i pacchetti con una porta di destinazione corrispondente.
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
Ottieni l'indirizzo IP del bilanciatore del carico interno
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. Convalida il bilanciatore del carico
Dalla console Cloud, vai a Servizi di rete → Bilanciamento del carico → Bilanciatori del carico. Tieni presente che 1 NEG è 'verde' che indica un controllo di integrità riuscito per il servizio in loco.
Selezionando ‘on-premise-service-backend' si ottiene l'indirizzo IP del frontend.
5. Visualizza le route apprese da on-premise
Vai a Rete VPC → Route. Si noti che la subnet del servizio on-premise appresa 192.168.1.0/27
6. Convalida la connettività al servizio on-premise
Dal VPC dei produttori creeremo una VM per testare la connettività al servizio on-premise; successivamente, il collegamento al servizio sarà il successivo per la configurazione.
All'interno di Cloud Shell crea l'istanza di test nel VPC del producer
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
Per consentire a IAP di connettersi alle tue istanze VM, crea una regola firewall che:
- Si applica a tutte le istanze VM a cui vuoi rendere accessibile tramite IAP.
- Consente il traffico in entrata dall'intervallo IP 35.235.240.0/20. Questo intervallo contiene tutti gli indirizzi IP utilizzati da IAP per l'inoltro TCP.
All'interno di Cloud Shell crea l'istanza di test nel VPC del producer
gcloud compute firewall-rules create ssh-iap \
--network producer-vpc \
--allow tcp:22 \
--source-ranges=35.235.240.0/20
Accedi a test-box-us-central1 utilizzando IAP in Cloud Shell per convalidare la connettività al servizio on-premise eseguendo un comando curl sull'indirizzo IP del bilanciamento del carico. Riprova in caso di timeout.
gcloud compute ssh test-box-us-central1 --project=$psclab --zone=us-central1-a --tunnel-through-iap
Eseguire un comando curl per convalidare la connettività al servizio on-premise. Dopo la convalida, l'uscita dalla VM torna al prompt di Cloud Shell. Sostituisci l'indirizzo IP del bilanciatore del carico interno in base all'output identificato nei passaggi 3 e 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. Crea il collegamento al servizio Private Service Connect
Nei passaggi successivi creeremo il collegamento al servizio, una volta abbinato a un endpoint consumer che l'accesso al servizio on-premise viene ottenuto senza dover utilizzare il peering VPC.
Crea il collegamento al servizio
All'interno di Cloud Shell crea il collegamento al servizio
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
(Facoltativo) Se utilizzi un VPC condiviso, crea il collegamento al servizio nel progetto di servizio
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>
convalida il collegamento al servizio TCP
gcloud compute service-attachments describe service-1 --region us-central1
8. (Facoltativo) Vai a Servizi di rete → Private Service Connect per visualizzare il collegamento al servizio appena stabilito
Se selezioni Service-1, vengono forniti maggiori dettagli, tra cui l'URI del collegamento al servizio utilizzato dal consumer per stabilire una connessione privata ai servizi. Prendi nota dell'URI, che verrà utilizzato in un passaggio successivo.
Dettagli del collegamento dei servizi: projects/<projectname>/regions/us-central1/serviceAttachments/service-1
9. Configurazione consumer
Crea il VPC consumer
In Cloud Shell, esegui queste operazioni
gcloud compute networks create consumer-vpc --project=$psclab --subnet-mode=custom
Crea le subnet consumer
In Cloud Shell crea la subnet GCE
gcloud compute networks subnets create subnet-101 --project=$psclab --range=10.100.1.0/24 --network=consumer-vpc --region=us-central1
In Cloud Shell crea la subnet endpoint consumer
gcloud compute networks subnets create subnet-102 --project=$psclab --range=10.100.2.0/24 --network=consumer-vpc --region=us-central1
Crea l'endpoint del consumatore (regola di forwarding)
In Cloud Shell crea l'indirizzo IP statico che verrà utilizzato come endpoint consumer.
gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=subnet-102 --addresses 10.100.2.10
Consente di utilizzare l'URI del collegamento al servizio generato in precedenza per creare l'endpoint del consumer
Crea l'endpoint consumer all'interno di Cloud Shell
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. Convalida Consumer Private Service Connect - VPC consumer
Dal VPC consumer, verifica che la connessione ai servizi privati sia riuscita andando a Servizi di rete → Private Service Connect → Endpoint connessi. Prendi nota della connessione psc-consumer-1 stabilita e dell'indirizzo IP corrispondente creato in precedenza.
Quando selezioni l'aggiunta psc-consumer-1, vengono forniti i dettagli, incluso l'URI dell'allegato del servizio
11. Convalida Consumer Private Service Connect - VPC producer
Dal VPC del produttore, verifica che la connessione ai servizi privati sia andata a buon fine andando a Servizi di rete → Private Service Connect → Servizio pubblicato. Tieni presente che la connessione service-1 pubblicata ora indica 1 regola di forwarding (endpoint di connessione).
12. Crea una zona DNS privata e Record A
Crea la zona DNS privata mappata all'endpoint di connessione PSC, consentendo un accesso senza interruzioni al producer da qualsiasi host all'interno del VPC.
Da 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. Convalida l'accesso consumer al servizio Producers tramite la VM
Dal VPC consumer creeremo una VM per testare la connettività al servizio on-premise accedendo all'endpoint consumer service1.codelabs.net
All'interno di Cloud Shell crea l'istanza di test nel VPC consumer
gcloud compute instances create consumer-vm \
--zone=us-central1-a \
--image-family=debian-10 \
--image-project=debian-cloud \
--subnet=subnet-101 \
--no-address
Per consentire a IAP di connettersi alle tue istanze VM, crea una regola firewall che:
- Si applica a tutte le istanze VM a cui vuoi rendere accessibile tramite IAP.
- Consente il traffico in entrata dall'intervallo IP 35.235.240.0/20. Questo intervallo contiene tutti gli indirizzi IP utilizzati da IAP per l'inoltro TCP.
All'interno di Cloud Shell crea l'istanza di test nel VPC consumer
gcloud compute firewall-rules create ssh-iap-consumer \
--network consumer-vpc \
--allow tcp:22 \
--source-ranges=35.235.240.0/20
Accedi a consumer-vm utilizzando IAP in Cloud Shell per convalidare la connettività al servizio on-premise eseguendo un curl sul servizio FQDN dns service1.codelab.net. Riprova in caso di timeout.
gcloud compute ssh consumer-vm --project=$psclab --zone=us-central1-a --tunnel-through-iap
Eseguire un comando curl per convalidare la connettività al servizio on-premise. Dopo la convalida, l'uscita dalla VM che torna al prompt di Cloud Shell
Esegui un comando curl all'interno di Cloud Shell
$ 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!!
Di seguito è riportato un esempio di acquisizione dal servizio on-premise. Si noti che l'indirizzo IP di origine 172.16.0.2 proviene dall'intervallo di subnet proxy TCP 172.16.0.0/23
14. Pulizia del producer
Eliminare i componenti di Producer
Elimina i componenti producer dall'interno di Cloud Shell
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. Pulizia del consumatore
Elimina componenti consumer
Elimina i componenti consumer all'interno di Cloud Shell.
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. Complimenti
Congratulazioni, hai configurato e convalidato Private Service Connect con il proxy TCP correttamente.
Hai creato l'infrastruttura del producer e hai aggiunto un collegamento a un servizio nel VPC del producer che punta a un servizio on-premise. Hai imparato come creare un endpoint consumer nel VPC consumer che consenta la connettività al servizio on-premise.
Passaggi successivi
Dai un'occhiata ad alcuni di questi codelab...
- Utilizzo di Private Service per pubblicare e utilizzare servizi con GKE
- Utilizzo di Private Service Connect per pubblicare e utilizzare servizi