Private Service Connect con configuración de DNS automática

1. Introducción

Private Service Connect con configuración de DNS automática usa el Directorio de servicios y Cloud DNS para crear automáticamente registros DNS programados con las direcciones IP del extremo de Private Service Connect del consumidor.

Qué compilarás

En este codelab, compilarás una arquitectura integral de Private Service Connect que ilustre el uso del DNS automático, como se muestra en la Figura 1.

El DNS automático es posible gracias a lo siguiente:

1. El archivo adjunto de servicio del productor origina el DNS automático proporcionando un dominio público propio con la marca "– domain-names" cuando se crea el archivo adjunto de servicio de Private Service Connect.
2. El consumidor define un nombre de extremo.
3. El DNS automático crea una Zona de DNS goog-psc-default-us-central1 y un Nombre de DNS cosmopup.net, además de una entrada del Directorio de servicios que consta del nombre del extremo del consumidor.

El beneficio del DNS automático se ilustra en (4), donde un usuario final puede comunicarse con el extremo del consumidor a través del DNS, el FQDN stargazer.cosmopup.net.

Figura 1

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
• Cómo crear un archivo adjunto de servicio con DNS automático
• Cómo establecer un servicio de productor de Private Service Connect
• Cómo acceder a un extremo de consumidor con DNS automático

Requisitos

• Proyecto de Google Cloud
• Un dominio público que te pertenezca

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]
projectname=YOUR-PROJECT-NAME
echo $projectname

3. Configuración del productor

Crea la VPC de productor

En Cloud Shell, haz lo siguiente:

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

Crea las subredes de productor

En Cloud Shell, haz lo siguiente:

gcloud compute networks subnets create gce-subnet --project=$projectname --range=172.16.20.0/28 --network=producer-vpc --region=us-central1

En Cloud Shell, haz lo siguiente:

gcloud compute networks subnets create load-balancer-subnet --project=$projectname --range=172.16.10.0/28 --network=producer-vpc --region=us-central1

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

En Cloud Shell, haz lo siguiente:

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

Nota: El uso de SHARED_VIP no es compatible con Private Service Connect. En su lugar, usa GCE_ENDPOINT.

Cómo ver la dirección IP asignada

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 red 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 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 de backend adecuada, 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 de VPC 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).

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 \
    --project $projectname \
    --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 la subred de NAT de Private Service Connect y la subred de solo proxy de ILB.

En Cloud Shell, haz lo siguiente:

gcloud compute --project=$projectname 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 de firewall fw-allow-health-check para permitir que las verificaciones de estado de Google Cloud lleguen al servicio de productor (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 para 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

Configuración de Cloud Router y NAT

En el codelab, se usa Cloud NAT para la instalación de paquetes de software, ya que la instancia de VM no tiene una dirección IP externa.

En Cloud Shell, crea el router en la nube.

gcloud compute routers create cloud-router-for-nat --network producer-vpc --region us-central1

En Cloud Shell, crea la puerta de enlace de NAT.

gcloud compute routers nats create cloud-nat-us-central1 --router=cloud-router-for-nat --auto-allocate-nat-external-ips --nat-all-subnet-ip-ranges --region us-central1

Configuración del grupo de instancias

En la siguiente sección, crearás la instancia de Compute Engine y el grupo de instancias no administrado. En pasos posteriores, el grupo de instancias se usará como el servicio de backend del balanceador de cargas.

En Cloud Shell, crea la verificación de estado regional que se pasa al servicio de productor.

gcloud compute instances create app-server-1 \
    --project=$projectname \
    --machine-type=e2-micro \
    --image-family debian-10 \
    --no-address \
    --image-project debian-cloud \
    --zone us-central1-a \
    --subnet=gce-subnet \
    --metadata startup-script="#! /bin/bash
      sudo apt-get update
      sudo apt-get install apache2 -y
      sudo service apache2 restart
      echo 'Welcome to App-Server-1 !!' | tee /var/www/html/index.html
      EOF"

En Cloud Shell, crea el grupo de instancias no administrado.

gcloud compute instance-groups unmanaged create psc-instance-group --zone=us-central1-a

gcloud compute instance-groups unmanaged set-named-ports psc-instance-group --project=$projectname --zone=us-central1-a --named-ports=http:80

gcloud compute instance-groups unmanaged add-instances psc-instance-group --zone=us-central1-a --instances=app-server-1

Configura el balanceador de cargas

En los siguientes pasos, configurarás el balanceador de cargas HTTP interno que se publicará como archivo adjunto del servicio en un paso posterior.

En Cloud Shell, crea la verificación de estado regional.

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

En Cloud Shell, crea el servicio de backend.

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

En Cloud Shell, agrega backends al servicio de backend.

gcloud compute backend-services add-backend l7-ilb-backend-service \
  --balancing-mode=UTILIZATION \
  --instance-group=psc-instance-group \
  --instance-group-zone=us-central1-a \
  --region=us-central1

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

gcloud compute url-maps create l7-ilb-map \
    --default-service l7-ilb-backend-service \
    --region=us-central1

Crea el proxy de destino HTTP.

gcloud compute target-http-proxies create l7-ilb-proxy\
    --url-map=l7-ilb-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 l7-ilb-forwarding-rule \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=producer-vpc \
      --subnet=load-balancer-subnet \
      --address=lb-ip \
      --ports=80 \
      --region=us-central1 \
      --target-http-proxy=l7-ilb-proxy \
      --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. Anota la verificación de estado correcta en el servicio de backend

Si seleccionas "l7-ilb-map", se muestra la dirección IP del frontend, que debe coincidir con la dirección IP que grepeaste en un paso anterior, y se identifica el servicio de backend.

5. Crea el archivo adjunto del servicio de Private Service Connect

Nota: Si especificas un nombre de dominio, el nombre se usa para configurar automáticamente entradas de DNS privadas para tus servicios en la red de VPC del consumidor de servicios. Debes ser un propietario verificado del nombre de dominio que especifiques. La publicación del servicio falla si no posees el dominio. Puedes hacer clic en Verificar dominio para ver y configurar la propiedad del dominio. En la siguiente sintaxis, cosmopup.net. se usa como el nombre de dominio. Actualiza la configuración con un dominio público autorizado de tu propiedad.

Crea el adjunto del servicio

En Cloud Shell, crea el archivo adjunto del servicio. Asegúrate de agregar el punto al final del nombre de dominio.

gcloud compute service-attachments create published-service --region=us-central1 --producer-forwarding-rule=l7-ilb-forwarding-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=psc-nat-subnet --domain-names=cosmopup.net.

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

gcloud compute service-attachments create published-service --region=us-central1 --producer-forwarding-rule=l7-ilb-forwarding-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=projects/<hostproject>/regions/us-central1/subnetworks/psc-nat-subnet --domain-names=cosmopup.net.

Navega a Servicios de red → Private Service Connect para ver el archivo adjunto de servicio establecido recientemente.

Si seleccionas published-service, se proporcionan más detalles, incluido el URI del adjunto de servicio que usa el consumidor para establecer una conexión de servicio privado y el nombre de dominio.

Detalles del archivo adjunto de servicio:

projects/<project name>/regions/us-central1/serviceAttachments/published-service

6. Configuración del consumidor

Habilita las APIs para consumidores

En Cloud Shell, haz lo siguiente:

gcloud services enable dns.googleapis.com
gcloud services enable servicedirectory.googleapis.com

Crea la red de VPC de consumidor

En Cloud Shell, haz lo siguiente:

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

Crea las subredes de consumidor

En Cloud Shell, crea la subred para la instancia de prueba.

gcloud compute networks subnets create db1-subnet --project=$projectname --range=10.20.0.0/28 --network=consumer-vpc --region=us-central1

En Cloud Shell, crea una subred para el extremo del consumidor.

gcloud compute networks subnets create consumer-ep-subnet --project=$projectname --range=10.10.0.0/28 --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á para el extremo del consumidor.

gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=consumer-ep-subnet --addresses 10.10.0.10

Usamos 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 stargazer --region=us-central1 --network=consumer-vpc --address=psc-consumer-ip-1 --target-service-attachment=projects/$projectname/regions/us-central1/serviceAttachments/published-service

7. Valida la conexión en la red de VPC del consumidor

Desde la red de 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. Observa la conexión establecida de Stargazer y la dirección IP correspondiente que creamos anteriormente.

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

8. Valida la conexión en la red de VPC del productor

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

9. Valida la configuración de DNS automática

Evaluemos la configuración del DNS y del Directorio de servicios.

Configuración de Cloud DNS

Navega a Servicios de red → Cloud DNS → Zonas. La zona goog-psc-default-us-central & el nombre de DNS cosmopup.net. se generan automáticamente.

Cómo ver la configuración de DNS y el Directorio de servicios

Seleccionar el nombre de la zona nos permite ver cómo se integra el Directorio de servicios con Cloud DNS.

Configuración del Directorio de servicios

Navega a Servicios de red → Directorio de servicios.

¿Recuerdas el nombre del extremo del consumidor "stargazer"? Se programa automáticamente en el Directorio de servicios, lo que nos permite llegar al extremo del consumidor mediante el FQDN stargazer.goog-psc-default–us-central1.

10. Valida el acceso de los consumidores al servicio de los productores

Desde la red de VPC del consumidor, crearemos una VM para probar la conectividad del servicio publicado accediendo al extremo del consumidor stargazer.cosmopup.net.

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

gcloud compute instances create db1 \
    --zone=us-central1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=db1-subnet \
    --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 regla de firewall de IAP.

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 de productor mediante un curl. Vuelve a intentarlo si se agota el tiempo de espera.

gcloud compute ssh db1 --project=$projectname --zone=us-central1-a --tunnel-through-iap

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

En Cloud Shell, realiza un curl en tu dominio personalizado, por ejemplo, stargazer.[custom-domain.com]. En el siguiente resultado, se realiza un curl en stargazer.cosmopup.net.

user@db1:~$ curl -v stargazer.cosmopup.net
*   Trying 10.10.0.10...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55d3aa8190f0)
* Connected to stargazer.cosmopup.net (10.10.0.10) port 80 (#0)
> GET / HTTP/1.1
> Host: stargazer.cosmopup.net
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< date: Thu, 22 Dec 2022 00:16:25 GMT
< server: Apache/2.4.38 (Debian)
< last-modified: Wed, 21 Dec 2022 20:26:32 GMT
< etag: "1b-5f05c5e43a083"
< accept-ranges: bytes
< content-length: 27
< content-type: text/html
< via: 1.1 google
< 
Welcome to App-Server-1 !!

Sal de la VM y vuelve al mensaje de Cloud Shell para iniciar las tareas de limpieza.

11. Limpia

En Cloud Shell, borra los componentes del codelab.

gcloud compute forwarding-rules delete stargazer --region=us-central1 --quiet

gcloud compute instances delete db1 --zone=us-central1-a --quiet 

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

gcloud compute networks subnets delete consumer-ep-subnet db1-subnet --region=us-central1 --quiet 

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

gcloud compute networks delete consumer-vpc --quiet 

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

gcloud compute forwarding-rules delete l7-ilb-forwarding-rule --region=us-central1 --quiet 

gcloud compute target-http-proxies delete l7-ilb-proxy --region=us-central1 --quiet 
 
gcloud compute url-maps delete l7-ilb-map --region=us-central1 --quiet 
 
gcloud compute backend-services delete l7-ilb-backend-service --region=us-central1 --quiet
 
gcloud compute instance-groups unmanaged delete psc-instance-group --zone=us-central1-a --quiet
 
gcloud compute instances delete app-server-1 --zone=us-central1-a --quiet 
 
gcloud compute firewall-rules delete allow-to-ingress-nat-subnet fw-allow-health-check fw-allow-proxy-only-subnet --quiet 
 
gcloud compute addresses delete lb-ip --region=us-central1 --quiet 
 
gcloud compute networks subnets delete gce-subnet load-balancer-subnet psc-nat-subnet proxy-subnet-us-central --region=us-central1 --quiet 
 
gcloud compute routers delete cloud-router-for-nat --region=us-central1 --quiet 
 
gcloud compute networks delete producer-vpc --quiet 

12. Felicitaciones

¡Felicitaciones! Configuraste y validaste correctamente un extremo de Private Service Connect con la configuración automática de DNS.

Creaste la infraestructura del productor y agregaste un archivo adjunto de servicio con registro de dominio público. Aprendiste a crear un extremo de consumidor en la red de VPC del consumidor que permitió la conectividad al servicio local con un DNS generado automáticamente.

Cosmopup piensa que los codelabs son geniales.

¿Qué sigue?

Consulta algunos codelabs sobre los siguientes temas:

• Usa Private Service Connect 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
• Private Service Connect: DNS automático