Conéctate a servicios locales a través de redes híbridas con Private Service Connect y el NEG híbrido con un balanceador de cargas HTTP(s) interno

1. Introducción

Cloud Load Balancing admite el balanceo de cargas de tráfico a extremos que se extienden más allá de Google Cloud, como centros de datos locales y otras nubes públicas a las que puede acceder la conectividad híbrida.

Una estrategia híbrida es una solución pragmática para que te adaptes a las demandas cambiantes del mercado y modernices gradualmente tus aplicaciones. Puede ser una implementación híbrida temporal para permitir la migración a una solución moderna basada en la nube o un elemento permanente de la infraestructura de TI de tu organización.

Configurar el balanceo de cargas híbrido también te permite llevar los beneficios de las capacidades de red de Cloud Load Balancing a los servicios que se ejecutan en tu infraestructura existente fuera de Google Cloud.

Si quieres que el servicio híbrido esté disponible en otras redes de VPC, puedes usar Private Service Connect para publicar el servicio. Si colocas un adjunto de servicio frente a tu balanceador de cargas HTTP(s) regional interno,puedes permitir que los clientes de otras redes de VPC accedan a los servicios híbridos que se ejecutan en entornos locales o en otros entornos de nube.

Qué compilarás

En este codelab, compilarás un balanceador de cargas HTTP(S) interno con conectividad híbrida para un servicio local usando un grupo de extremos de red. La VPC del consumidor podrá comunicarse con el servicio local mediante los puertos 80, el puerto 443 no está dentro del alcance del codelab.

Nota: El codelab ofrece pasos de configuración y validación según la topología ilustrada. Modifica el procedimiento según sea necesario para cumplir con los requisitos de tu organización. Los permisos de IAM no están dentro del alcance de este codelab.

Qué aprenderás

• Cómo crear un balanceador de cargas HTTP(S) interno con un backend de NEG híbrido
• Cómo establecer un productor (adjunto de servicio) y un consumidor (regla de reenvío) de Private Service Connect

Nota: Este codelab se enfoca en un balanceador de cargas HTTP(S) interno. implementación con PSC . La configuración de red híbrida no está documentada, pero se proporcionan documentación de respaldo y capturas de pantalla.

Requisitos

• Redes híbridas establecidas, p. ej., VPN con alta disponibilidad, Interconnect o SW-WAN
• Proyecto de Google Cloud

Establece la conectividad híbrida

Tu Google Cloud y los entornos locales o de otras nubes deben estar conectados a través de conectividad híbrida, ya sea mediante adjuntos de VLAN de Cloud Interconnect o túneles de Cloud VPN con Cloud Router. Te recomendamos usar una conexión de alta disponibilidad.

Un Cloud Router habilitado con enrutamiento dinámico global aprende sobre el extremo específico a través de BGP y lo programa en tu red de VPC de Google Cloud. No se admite el enrutamiento dinámico regional. Tampoco se admiten las rutas estáticas.

La red de VPC de Google Cloud que usas para configurar Cloud Interconnect o Cloud VPN es la misma que usas para configurar la implementación del balanceo de cargas híbrido. Asegúrate de que los rangos de CIDR de la subred de tu red de VPC no entren en conflicto con tus rangos de CIDR remotos. Cuando las direcciones IP se superponen, las rutas de subred tienen prioridad sobre la conectividad remota.

Para obtener instrucciones, consulta los siguientes vínculos:

• Documentación de Cloud VPN
• Documentación de Cloud Interconnect

Anuncios de ruta personalizada

Las subredes que se encuentran a continuación requieren anuncios personalizados del Cloud Router a la red local, lo que garantiza la actualización de las reglas de firewall locales.

Subred	Descripción
172.16.0.0/23	Subred de proxy que se usa para comunicarse directamente con el servicio local
130.211.0.0/22, 35.191.0.0/16	Verificación de estado de Google Cloud

2. Antes de comenzar

Actualiza el proyecto para que sea compatible con el codelab

En este codelab, se usa $variables para facilitar la implementación de la configuración de gcloud en Cloud Shell.

En Cloud Shell, haz lo siguiente

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

3. Configuración del productor

Crea la VPC de productor

En Cloud Shell, haz lo siguiente

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

Crea las subredes de Producer

En Cloud Shell, haz lo siguiente

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

Reserva una dirección IP para el balanceador de cargas interno

Dentro de Cloud Shell, realiza lo siguiente, con SHARED_VIP no es compatible con Private Service Connect, usa GCE_ENDPOINT en su lugar

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

Usa el comando compute addresses describe para ver la dirección IP asignada.

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

Crea las subredes del proxy regional

La asignación de proxy se realiza a nivel de VPC, no a nivel del balanceador de cargas. Debes crear una subred de solo proxy en cada región de una red virtual (VPC) en la que uses balanceadores de cargas basados en Envoy. Si implementas varios balanceadores de cargas en la misma región y la misma red de VPC, compartirán la misma subred de solo proxy para el balanceo de cargas.

1. Un cliente establece una conexión a la dirección IP y al puerto de la regla de reenvío del balanceador de cargas.
2. Cada proxy escucha en la dirección IP y el puerto que especifica la regla de reenvío del balanceador de cargas correspondiente. Uno de los servidores proxy recibe y finaliza la conexión de red del cliente.
3. El proxy establece una conexión con la VM o el extremo de backend adecuados en un NEG, según lo determinan los servicios de backend y el mapa de URL del balanceador de cargas.

Debes crear subredes de solo proxy sin importar si tu red está en modo automático o personalizado. Una subred de solo proxy debe proporcionar 64 direcciones IP o más. Esto corresponde a una longitud de prefijo de /26 o menor. El tamaño de subred recomendado es /23 (512 direcciones de solo proxy).

Nota: La subred de solo proxy requiere que un anuncio de BGP del cliente sea local, por lo que se puede enrutar a tu red local y el acceso al servicio es posible mediante la subred de proxy proporcionada.

En Cloud Shell, haz lo siguiente

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 las subredes NAT de Private Service Connect

Crea una o más subredes dedicadas para usar con Private Service Connect. Si usas la consola de Google Cloud para publicar un servicio, puedes crear las subredes durante ese procedimiento. Crea la subred en la misma región que el balanceador de cargas del servicio. No puedes convertir una subred normal en una subred de Private Service Connect.

En Cloud Shell, haz lo siguiente

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 las reglas de firewall de Producer

Configura las reglas de firewall para permitir el tráfico entre los extremos de Private Service Connect y el adjunto de servicio. En el codelab, creaste una regla de firewall de entrada que permite que la subred NAT 100.100.10.0/24 acceda al adjunto de servicio de Private Service Connect (balanceador de cargas interno).

En Cloud Shell, haz lo siguiente

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

Dentro de Cloud Shell, crea la regla fw-allow-health-check para permitir que las verificaciones de estado de Google Cloud alcancen el servicio local (servicio de backend) en el puerto 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 regla de firewall de permiso de entrada para la subred de solo proxy de modo que el balanceador de cargas pueda comunicarse con instancias de backend en el puerto 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

Configura el NEG de conectividad híbrida

Cuando crees el NEG, usa una ZONA que minimice la distancia geográfica entre Google Cloud y tu entorno local o algún otro entorno de nube. Por ejemplo, si alojas un servicio en un entorno local en Fráncfort, Alemania, puedes especificar la zona europe-west3-a de Google Cloud cuando crees el NEG.

Además, si usas Cloud Interconnect, la ZONA que se usa para crear el NEG debe estar en la misma región donde se configuró el adjunto de Cloud Interconnect.

Para conocer las regiones y zonas disponibles, consulta la documentación de Compute Engine: Regiones y zonas disponibles.

Dentro de Cloud Shell, crea un NEG de conectividad híbrida con el 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

Dentro de Cloud Shell, agrega el extremo IP:Port local al NEG híbrido.

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

Configura el balanceador de cargas

En los siguientes pasos, configurarás el balanceador de cargas (regla de reenvío) y asociar al grupo de extremos de red

Dentro de Cloud Shell, crea la verificación de estado regional que se pasa al servicio local

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

Dentro de Cloud Shell, crea el servicio de backend para el backend local que aprovecha el NEG híbrido

 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

Dentro de Cloud Shell, agrega el backend de NEG híbrido al servicio de backend. En RATE, ingresa la RATE máxima que el backend debe controlar.

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

Dentro de Cloud Shell, crea el mapa de URL para enrutar las solicitudes entrantes al servicio de backend

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

Crea el proxy HTTP de destino

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

Crea una regla de reenvío para enrutar las solicitudes entrantes al proxy. No uses la subred de solo proxy para crear la regla de reenvío.

 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. Valida el balanceador de cargas

En la consola de Cloud, navega a Servicios de red → Balanceo de cargas → Balanceadores de cargas. Ten en cuenta que el NEG 1 es “verde” que indica una verificación de estado correcta al servicio local

Cuando se selecciona ‘on-premise-svc-url-map', se obtiene la dirección IP del frontend y se identifica el servicio de backend.

5. Visualiza las rutas aprendidas desde la infraestructura local

Navega a Red de VPC → Rutas. Ten en cuenta que la subred de servicio local aprendida 192.168.1.0/27

6. Valida la conectividad al servicio local

Desde la VPC de productores, crearemos una VM para probar la conectividad al servicio local. Luego de que el adjunto de servicio sea la siguiente configuración,

En Cloud Shell, crea la instancia de prueba en la VPC del productor

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

Para permitir que IAP se conecte a tus instancias de VM, crea una regla de firewall que haga lo siguiente:

• Se aplica a todas las instancias de VM a las que deseas que se pueda acceder mediante IAP.
• Permite el tráfico de entrada del rango de IP 35.235.240.0/20. Este rango contiene todas las direcciones IP que IAP usa para el reenvío de TCP.

En Cloud Shell, crea la instancia de prueba en la VPC del productor

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

Inicie sesión en test-box-us-central1 con IAP en Cloud Shell para validar la conectividad al servicio local. Para ello, ejecute un comando curl en función de la dirección IP de balanceo de cargas. Vuelve a intentarlo si se agotó el tiempo de espera.

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

Realiza un comando curl que valide la conectividad al servicio local. Una vez validada, salga de la VM y regrese a la ventana de Cloud Shell. Reemplaza la IP del balanceador de cargas interno según el resultado que identificaste en el paso 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. Crea el adjunto del servicio de Private Service Connect

En los siguientes pasos, crearemos el adjunto de servicio, una vez que se vincula con un extremo del consumidor, el acceso al servicio local se logra sin necesidad de un intercambio de tráfico entre VPC.

Crea el adjunto de servicio

Crea el adjunto de servicio en Cloud Shell

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

Opcional: Si usas una VPC compartida, crea el adjunto de servicio en el proyecto de servicio.

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>

Valida el adjunto de servicio de TCP

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

Opcional: Navega a Servicios de red → Private Service Connect para ver el adjunto de servicio recién establecido.

Seleccionar Service-1 proporciona más detalles, incluido el URI del adjunto de servicio que usa el consumidor para establecer una conexión de servicio privada. Toma nota del URI, ya que lo usarás en un paso posterior.

Detalles del adjunto de servicio: projects/<projectname>/regions/us-central1/serviceAttachments/service-1

8. Configuración del consumidor

Crea la VPC del consumidor

En Cloud Shell, haz lo siguiente

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

Crea las subredes del consumidor

En Cloud Shell, crea la subred de GCE

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

En Cloud Shell, crea la subred del extremo del consumidor

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

Crea el extremo del consumidor (regla de reenvío)

En Cloud Shell, crea la dirección IP estática que se usará como extremo del consumidor.

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

Usemos el URI del adjunto de servicio generado con anterioridad para crear el extremo del consumidor

Dentro de Cloud Shell, crea el extremo del consumidor

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. Valida Consumer Private Service Connect: VPC del consumidor

Desde la VPC del consumidor, navega a Servicios de red → Private Service Connect→ Extremos conectados para verificar que haya una conexión de servicio privada exitosa. Observa la conexión psc-consumer-1 establecida y la dirección IP correspondiente que creamos anteriormente.

Cuando se seleccionan los detalles de psc-consumer-1, se incluyen el URI del adjunto de servicio

10. Valida Consumer Private Service Connect: VPC del productor

Desde la VPC del productor, navega a Servicios de red → Private Service Connect→Servicio publicado para verificar que se haya establecido una conexión de servicio privada exitosa. Observa que la conexión service-1 publicada ahora indica 1 regla de reenvío (extremo de conexión).

11. Crea una zona de DNS privada y Registro A

Crea la zona de DNS privada asignada al extremo de conexión de PSC, lo que permite el acceso sin interrupciones al productor desde cualquier host dentro de la VPC.

Nota: No se admite el acceso a un extremo de consumidor a través del intercambio de tráfico entre VPC.

Desde 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. Valida el acceso del consumidor al servicio de productores con una VM

Desde la VPC de consumidores, crearemos una VM para probar la conectividad al servicio local accediendo al servicio del extremo del consumidor 1.codelabs.net

En Cloud Shell, crea la instancia de prueba en la VPC del consumidor

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

Para permitir que IAP se conecte a tus instancias de VM, crea una regla de firewall que haga lo siguiente:

• Se aplica a todas las instancias de VM a las que deseas que se pueda acceder mediante IAP.
• Permite el tráfico de entrada del rango de IP 35.235.240.0/20. Este rango contiene todas las direcciones IP que IAP usa para el reenvío de TCP.

En Cloud Shell, crea la instancia de prueba en la VPC del consumidor

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

Accede a consumer-vm con IAP en Cloud Shell para validar la conectividad al servicio local. Para ello, ejecuta un comando curl en el FQDN de dns service1.codelab.net. Vuelve a intentarlo si se agotó el tiempo de espera.

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

Realiza un comando curl que valide la conectividad al servicio local. Una vez validada, salga de la VM y regrese al prompt de Cloud Shell.

Realiza un curl en 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!!

A continuación, se proporciona una captura de ejemplo del servicio local. Ten en cuenta que la dirección IP de origen 172.16.0.13 es del rango de la subred del proxy 172.16.0.0/23.

13. Limpieza del productor

Cómo borrar componentes de Producer

Dentro de Cloud Shell, borra las instancias de prueba en la VPC de Producer

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. Eliminación de consumidores

Borra componentes de consumidor

Dentro de Cloud Shell, borra las instancias de prueba en la VPC del consumidor

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. Felicitaciones

Felicitaciones, configuraste y validaste correctamente Private Service Connect con un balanceador de cargas HTTP(S) interno.

Creaste la infraestructura del productor y agregaste un adjunto de servicio en la VPC del productor que apunta a un servicio local. Aprendiste a crear un extremo del consumidor en la VPC del consumidor que permitía la conectividad al servicio local.

¿Qué sigue?

Consulta algunos codelabs sobre los siguientes temas:

• Usa Private Service para publicar y consumir servicios con GKE
• Usa Private Service Connect para publicar y consumir servicios
• Conéctate a servicios locales a través de redes híbridas con Private Service Connect y un balanceador de cargas de proxy TCP interno

Lecturas adicionales y Videos

• Descripción general de Private Service Connect
• ¿Qué es Private Service Connect?
• Tipos de balanceadores de cargas admitidos

Documentos de referencia

• Descripción general del balanceador de cargas HTTP(S) interno
• Descripción general de las verificaciones de estado
• Cómo publicar un servicio con Private Service Connect