Private Service Connect с автоматической настройкой DNS

1. Введение

Private Service Connect с автоматической настройкой DNS использует Service Directory и Cloud DNS для автоматического создания записей DNS, запрограммированных с использованием IP-адресов конечной точки Private Service Connect потребителя.

Что ты построишь

В этой лабораторной работе вы собираетесь создать комплексную архитектуру Private Service Connect, которая иллюстрирует использование автоматического DNS, как показано на рисунке 1.

Автоматический DNS возможен благодаря следующему:

1. Вложение службы производителя создает автоматический DNS, предоставляя принадлежащему обществу общедоступному домену флаг «-domain-names» при создании вложения службы Private Service Connect.
2. Потребитель определяет имя конечной точки.
3. Автоматический DNS создает как DNS-зону goog-psc-default-us-central1, так и DNS-имя cospopup.net, а также запись в каталоге служб, состоящую из имени конечной точки потребителя.

Преимущество автоматического DNS проиллюстрировано в (4), где конечный пользователь может связываться с конечной точкой потребителя через DNS, полное доменное имя stargazer.cosmopup.net.

Рисунок 1

Примечание. Codelab предлагает этапы настройки и проверки на основе иллюстрированной топологии. При необходимости измените процедуру в соответствии с требованиями вашей организации. Разрешения IAM не входят в область действия лаборатории кода.

Что вы узнаете

• Как создать внутренний балансировщик нагрузки HTTP(S)
• Как создать служебное вложение с автоматическим DNS
• Как установить службу Private Service Connect Producer
• Как получить доступ к конечной точке потребителя с помощью автоматического DNS

Что вам понадобится

• Облачный проект Google
• Общественное достояние, которым вы владеете

2. Прежде чем начать

Обновите проект для поддержки лаборатории кода.

В этом Codelab используются переменные $variables для облегчения реализации конфигурации gcloud в Cloud Shell.

Внутри Cloud Shell выполните следующие действия:

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

3. Настройка продюсера

Создайте производитель VPC.

Внутри Cloud Shell выполните следующие действия:

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

Создайте подсети производителей

Внутри Cloud Shell выполните следующие действия:

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

Внутри Cloud Shell выполните следующие действия:

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

Зарезервируйте IP-адрес для внутреннего балансировщика нагрузки.

Внутри Cloud Shell выполните следующие действия:

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

Примечание. Использование SHARED_VIP не поддерживается с помощью Private Service Connect, вместо этого используйте GCE_ENDPOINT.

Просмотр выделенного IP-адреса

Используйте команду описания адресов вычислений, чтобы просмотреть выделенный IP-адрес.

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

Создайте региональные подсети прокси.

Распределение прокси осуществляется на уровне сети VPC, а не на уровне балансировщика нагрузки. Вы должны создать одну подсеть только для прокси-сервера в каждом регионе виртуальной сети (VPC), в которой вы используете балансировщики нагрузки на основе Envoy. Если вы развертываете несколько балансировщиков нагрузки в одном регионе и одной сети VPC, они используют одну и ту же подсеть только для прокси-сервера для балансировки нагрузки.

1. Клиент устанавливает соединение с IP-адресом и портом правила переадресации балансировщика нагрузки.
2. Каждый прокси-сервер прослушивает IP-адрес и порт, указанные в правиле переадресации соответствующего балансировщика нагрузки. Один из прокси получает и разрывает сетевое соединение клиента.
3. Прокси-сервер устанавливает соединение с соответствующей серверной виртуальной машиной, определяемой картой URL-адресов балансировщика нагрузки и серверными службами.

Вы должны создавать подсети только для прокси-серверов независимо от того, работает ли ваша сеть VPC в автоматическом или пользовательском режиме. Подсеть только для прокси-сервера должна предоставлять 64 или более IP-адресов. Это соответствует длине префикса /26 или короче. Рекомендуемый размер подсети — /23 (512 адресов только для прокси).

Внутри Cloud Shell выполните следующие действия:

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

Создайте подсети NAT Private Service Connect.

Создайте одну или несколько выделенных подсетей для использования с Private Service Connect. Если вы используете консоль Google Cloud для публикации службы , вы можете создать подсети во время этой процедуры. Создайте подсеть в том же регионе, что и балансировщик нагрузки службы. Обычную подсеть невозможно преобразовать в подсеть Private Service Connect.

Внутри Cloud Shell выполните следующие действия:

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

Создайте правила брандмауэра производителя.

Настройте правила брандмауэра , чтобы разрешить трафик между подсетью NAT Private Service Connect и подсетью только прокси-сервера ILB.

Внутри Cloud Shell выполните следующие действия:

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

В Cloud Shell создайте правило брандмауэра fw-allow-health-check, чтобы разрешить проверкам работоспособности Google Cloud достигать службы производителя (внутренней службы) через 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

Создайте входное правило брандмауэра для подсети только для прокси-сервера, чтобы позволить балансировщику нагрузки взаимодействовать с экземплярами серверной части через 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

Облачный маршрутизатор и конфигурация NAT

Cloud NAT используется в лаборатории кода для установки пакета программного обеспечения, поскольку экземпляр виртуальной машины не имеет внешнего IP-адреса.

Внутри Cloud Shell создайте облачный маршрутизатор.

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

Внутри Cloud Shell создайте шлюз 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

Конфигурация группы экземпляров

В следующем разделе вы создадите экземпляр Compute Engine и группу неуправляемых экземпляров. На последующих этапах группа экземпляров будет использоваться в качестве внутренней службы балансировки нагрузки.

Внутри Cloud Shell создайте региональную проверку работоспособности, передаваемую в службу производителя.

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"

В Cloud Shell создайте группу неуправляемых экземпляров.

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

Настройте балансировщик нагрузки

На следующих шагах вы настроите внутренний балансировщик нагрузки HTTP, который будет опубликован как вложение службы на более позднем этапе.

В Cloud Shell создайте региональную проверку работоспособности.

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

Внутри Cloud Shell создайте серверную службу.

 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

В Cloud Shell добавьте серверные части к серверной службе.

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

В Cloud Shell создайте карту URL-адресов для маршрутизации входящих запросов к серверной службе.

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

Создайте целевой прокси-сервер HTTP.

gcloud compute target-http-proxies create l7-ilb-proxy\
    --url-map=l7-ilb-map \
    --url-map-region=us-central1 \
    --region=us-central1

Создайте правило переадресации для маршрутизации входящих запросов на прокси. Не используйте подсеть только для прокси-сервера для создания правила переадресации.

 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. Проверка балансировщика нагрузки

В Cloud Console перейдите в «Сетевые службы» → «Балансировка нагрузки» → «Балансировщики нагрузки» . Обратите внимание на успешную проверку работоспособности серверной службы.

Выбор «l7-ilb-map» дает внешний IP-адрес, который должен совпадать с IP-адресом, полученным вами на предыдущем этапе, и идентифицирует внутреннюю службу.

5. Создайте вложение службы Private Service Connect.

Примечание. Если вы укажете доменное имя, оно будет использоваться для автоматической настройки частных записей DNS для ваших служб в сети VPC потребителя услуг. Вы должны быть подтвержденным владельцем указанного вами доменного имени. Публикация службы невозможна, если вы не являетесь владельцем домена. Вы можете нажать «Проверить домен», чтобы просмотреть и настроить владение доменом. В приведенном ниже синтаксисе — cospopup.net. используется в качестве доменного имени. Обновите конфигурацию, указав принадлежащий вам авторизованный общедоступный домен.

Создайте вложение службы

В Cloud Shell создайте вложение службы. Обязательно добавьте '.' в конце доменного имени.

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.

Необязательно: если вы используете общий VPC, создайте вложение службы в проекте службы.

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.

Перейдите в «Сетевые службы» → «Подключение частной службы» , чтобы просмотреть вновь установленное вложение службы.

Выбор опубликованной службы предоставляет более подробную информацию, включая URI вложения службы, используемый потребителем для установления соединения с частной службой, и имя домена.

Детали сервисного приложения:

projects/<имя проекта>/regions/us-central1/serviceAttachments/published-service

6. Настройка потребителя

Включить потребительские API

Внутри Cloud Shell выполняет следующее:

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

Создайте потребительскую сеть VPC.

Внутри Cloud Shell выполните следующие действия:

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

Создайте потребительские подсети

Внутри Cloud Shell создайте подсеть для тестового экземпляра.

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

Внутри Cloud Shell создайте подсеть для конечной точки потребителя.

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

Создайте конечную точку потребителя (правило переадресации).

В Cloud Shell создайте статический IP-адрес, который будет использоваться для конечной точки потребителя.

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

Мы используем ранее созданный URI вложения службы для создания конечной точки потребителя.

Внутри Cloud Shell создайте конечную точку потребителя.

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. Проверка подключения в сети VPC потребителя.

В потребительской сети VPC проверьте успешное подключение частной службы, перейдя в раздел «Сетевые службы» → «Подключение частной службы» → «Подключенные конечные точки» . Обратите внимание на установленное соединение с звездочётом и соответствующий IP-адрес, который мы создали ранее.

При выборе psc-consumer-1 предоставляются сведения, включая URI вложения службы.

8. Проверьте подключение в сети VPC производителя.

В сети VPC производителя проверьте успешное подключение частной службы, перейдя в раздел «Сетевые службы» → «Подключение частной службы» → «Опубликованная служба». Обратите внимание, что опубликованное соединение службы теперь указывает 1 правило переадресации (конечная точка соединения).

9. Проверьте автоматическую конфигурацию DNS.

Давайте оценим конфигурацию DNS и Service Directory.

Конфигурация облачного DNS

Перейдите в «Сетевые службы» → «Облачный DNS» → «Зоны». Зона goog-psc-default-us-central и DNS-имя cospopup.net. генерируется автоматически.

Просмотр конфигурации DNS и каталога служб

Выбор имени зоны позволяет нам увидеть, как Service Directory интегрируется с Cloud DNS.

Конфигурация каталога служб

Перейдите в Сетевые службы → Каталог служб.

Помните имя конечной точки потребителя « звездочёт »? Он автоматически программируется в каталоге служб, что позволяет нам достичь конечной точки потребителя с помощью полного доменного имени stargazer.goog-psc-default–us-central1.

10. Проверка доступа потребителей к сервису производителей

В сети VPC потребителя мы создадим виртуальную машину для проверки возможности подключения опубликованного сервиса, получив доступ к конечной точке потребителя stargazer.cosmopup.net.

Внутри Cloud Shell создайте тестовый экземпляр в потребительском виртуальном компьютере.

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

Чтобы разрешить IAP подключаться к вашим экземплярам виртуальных машин, создайте правило брандмауэра, которое:

• Применяется ко всем экземплярам виртуальных машин, доступ к которым вы хотите сделать с помощью IAP.
• Разрешает входящий трафик из диапазона IP 35.235.240.0/20. Этот диапазон содержит все IP-адреса, которые IAP использует для пересылки TCP.

В Cloud Shell создайте правило брандмауэра IAP.

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

Войдите в потребительскую виртуальную машину с помощью IAP в Cloud Shell, чтобы проверить подключение к службе производителя, выполнив завивку. Повторите попытку, если истекло время ожидания.

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

Выполните завивку, проверяющую подключение к службе производителя. После подтверждения выйдите из виртуальной машины и вернитесь к приглашению Cloud Shell.

Внутри Cloud Shell выполните скручивание вашего личного домена, например stargazer.[custom-domain.com]. В приведенном ниже выводе выполняется скручивание для 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 !!

Выйдите из виртуальной машины и вернитесь к приглашению Cloud Shell для запуска задач очистки.

11. Очистка

Из Cloud Shell удалите компоненты 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. Поздравления

Поздравляем, вы успешно настроили и проверили конечную точку Private Service Connect с автоматической настройкой DNS.

Вы создали инфраструктуру производителя и добавили вложение службы с регистрацией в общедоступном домене. Вы узнали, как создать потребительскую конечную точку в потребительской сети VPC, которая позволяла бы подключаться к локальной службе с помощью автоматически созданного DNS.

Cosmopup считает, что кодлабы — это здорово!!

Что дальше?

Посмотрите некоторые из этих кодовых лабораторий...

• Использование Private Service Connect для публикации и использования сервисов с помощью GKE
• Использование Private Service Connect для публикации и использования сервисов
• Подключайтесь к локальным службам через гибридную сеть с помощью Private Service Connect и внутреннего балансировщика нагрузки TCP-прокси.

Дальнейшее чтение и видео

• Обзор частного сервиса Connect
• Что такое подключение к частному сервису?
• Поддерживаемые типы балансировщиков нагрузки

Справочная документация

• Обзор внутреннего балансировщика нагрузки HTTP(s)
• Обзор проверок работоспособности
• Как опубликовать службу с помощью Private Service Connect
• Private Service Connect – автоматический DNS