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 tráfico de balanceo de cargas a extremos que se extienden más allá de Google Cloud, como centros de datos locales y otras nubes públicas a las que puedes usar la conectividad híbrida para llegar.

Una estrategia híbrida es una solución pragmática para que te adaptes a las demandas cambiantes del mercado y modernices tus aplicaciones de forma incremental. Esta 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.

La configuración del balanceo de cargas híbrido también te permite aprovechar los beneficios de las capacidades de red de Cloud Load Balancing en 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 a un servicio local mediante un grupo de extremos de red. La VPC del consumidor podrá comunicarse con el servicio local a través de los puertos 80. El puerto 443 no está dentro del alcance del codelab.

Nota: El codelab ofrece pasos de configuración y validación basados en 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 del codelab.

Qué aprenderás

• Cómo crear un balanceador de cargas de 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 la implementación de un balanceador de cargas HTTP(S) interno con PSC. La configuración de redes híbridas no está documentada, aunque se proporcionan capturas de pantalla y documentación de respaldo.

Requisitos

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

Establece una conectividad híbrida

Tu Google Cloud y otros entornos de nube deben estar conectados a través de la conectividad híbrida, 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 red 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 la red de VPC no entren en conflicto con los rangos de CIDR remotos. Cuando las direcciones IP se superponen, las rutas de subred se priorizan por 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 indican a continuación requieren anuncios personalizados del Cloud Router a la red local para garantizar que se actualicen las reglas del firewall local.

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 admitir el codelab

En este codelab, se usan $variables para ayudar a implementar 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 del productor

En Cloud Shell, haz lo siguiente:

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

Crea las subredes de productor

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

En Cloud Shell, realiza lo siguiente. No se admite el uso de SHARED_VIP con Private Service Connect. En su lugar, usa GCE_ENDPOINT.

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 de proxy regionales

La asignación de proxy está a nivel de la 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 red de VPC, estos comparten 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 la asignación 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 un anuncio de BGP del cliente a la ubicación local, por lo que se puede enrutar a tu red local. El acceso al servicio es posible a través de 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 de 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 del productor

Configura 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 de 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

En Cloud Shell, crea la regla fw-allow-health-check para permitir que las verificaciones de estado de Google Cloud lleguen al 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 a fin de permitir que el balanceador de cargas se comunique 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 de otra 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 ZONE que se usa para crear el NEG debe estar en la misma región en la que 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.

En 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

En Cloud Shell, agrega el extremo de 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 lo asociarás con el grupo de extremos de red.

En 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

En 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

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

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

En 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 de destino HTTP

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”, lo que indica que la verificación de estado del servicio local se realizó correctamente.

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

5. Consulta las rutas aprendidas desde la infraestructura local

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

6. Valida la conectividad al servicio local

Desde la VPC del productor, crearemos una VM para probar la conectividad con el servicio local. Luego, el adjunto de servicio es 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 cumpla con lo siguiente:

• Se aplica a todas las instancias de VM a las que deseas acceder mediante IAP.
• Permite el tráfico de entrada desde el 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

Accede a test-box-us-central1 con IAP en Cloud Shell para validar la conectividad al servicio local mediante la ejecución de un comando curl en la dirección IP del balanceador de cargas. Vuelve a intentarlo si se agota el tiempo de espera.

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

Realiza un curl para validar la conectividad al servicio local. Una vez que se valide, sal de la VM y regresa al mensaje 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 de servicio de Private Service Connect

En los siguientes pasos, crearemos el archivo adjunto de servicio. Una vez que se vincule con un extremo de consumidor, se logrará el acceso al servicio local sin necesidad de establecer un intercambio de tráfico de VPC.

Crea el archivo adjunto del servicio

En Cloud Shell, crea el archivo adjunto del 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=psc-nat-subnet

Opcional: Si usas una VPC compartida, crea el archivo 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 archivo adjunto del servicio 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 establecido recientemente.

Si seleccionas Service-1, se proporcionan 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 se usará 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 de consumidor

Crea la subred de GCE en Cloud Shell

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 archivo adjunto de servicio generado anteriormente para crear el extremo del consumidor.

En 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 Private Service Connect para consumidores: VPC del consumidor

Desde la VPC del consumidor, verifica que la conexión de Private Service Connect se haya realizado correctamente navegando a Servicios de red → Private Service Connect → Extremos conectados. Ten en cuenta la conexión psc-consumer-1 establecida y la dirección IP correspondiente que creamos anteriormente.

Cuando seleccionas psc-consumer-1, se proporcionan detalles, incluido el URI del adjunto de servicio.

10. Valida Private Service Connect para consumidores: VPC del productor

Desde la VPC del productor, verifica que la conexión privada a servicio se haya establecido correctamente navegando a Servicios de red → Private Service Connect → Servicio publicado. Ten en cuenta que la conexión del servicio 1 publicado ahora indica 1 regla de reenvío (extremo de conexión).

11. Crea una zona de DNS privada y un registro A

Crea la zona de DNS privada asignada al extremo de conexión de PSC, lo que permite un acceso sin problemas 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 de 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 extremo de consumidor service1.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 cumpla con lo siguiente:

• Se aplica a todas las instancias de VM a las que deseas acceder mediante IAP.
• Permite el tráfico de entrada desde el 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 mediante la ejecución de un curl en el FQDN de DNS service1.codelab.net. Vuelve a intentarlo si se produce un tiempo de espera.

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

Realiza un curl para validar la conectividad al servicio local. Una vez que se valide, sal de la VM y vuelve al mensaje de Cloud Shell.

En Cloud Shell, realiza 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!!

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

13. Limpieza del productor

Cómo borrar componentes de productor

En Cloud Shell, borra las instancias de prueba en la VPC del productor

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. Limpieza de consumidores

Cómo borrar componentes de consumidor

En Cloud Shell, borra las instancias de prueba en la VPC de 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

¡Felicidades! 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 de consumidor en la VPC del consumidor que permitió 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 y videos adicionales

• Descripción general de Private Service Connect
• ¿Qué es Private Service Connect?
• Tipos de balanceador 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