Эта страница переведена с помощью Cloud Translation API.

Подключайтесь к локальным службам через гибридную сеть с помощью Private Service Connect и Hybrid NEG с внутренним балансировщиком нагрузки HTTP(s).

1. Введение

Балансировка нагрузки в облаке поддерживает балансировку нагрузки на конечные точки, выходящие за пределы Google Cloud, например локальные центры обработки данных и другие общедоступные облака, для доступа к которым можно использовать гибридное подключение .

Гибридная стратегия — это прагматичное решение, позволяющее адаптироваться к меняющимся требованиям рынка и постепенно модернизировать ваши приложения. Это может быть временное гибридное развертывание, позволяющее перейти к современному облачному решению или постоянному элементу ИТ-инфраструктуры вашей организации.

Настройка гибридной балансировки нагрузки также позволяет вам использовать преимущества сетевых возможностей Cloud Load Balancing для сервисов, работающих в вашей существующей инфраструктуре за пределами Google Cloud.

Если вы хотите сделать гибридную службу доступной в других сетях VPC, вы можете использовать Private Service Connect для публикации службы . Разместив вложение службы перед внутренним региональным балансировщиком нагрузки HTTP(s), вы можете позволить клиентам в других сетях VPC получать доступ к гибридным службам, работающим в локальных или других облачных средах.

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

В этой лабораторной работе вы собираетесь создать внутренний балансировщик нагрузки HTTP(S) с гибридным подключением к локальной службе с использованием группы конечных точек сети. Потребительский VPC сможет взаимодействовать с локальной службой, используя порты 80. , порт 443 выходит за рамки лаборатории кода.

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

Как создать внутренний балансировщик нагрузки HTTP(S) с гибридным бэкэндом NEG
Как установить производителя Private Service Connect (приложение службы) и потребителя (правило пересылки)

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

Установленная гибридная сеть, например HA VPN, Interconnect, SW-WAN.
Облачный проект Google

Установите гибридное соединение

Ваше облако Google Cloud и локальные или другие облачные среды должны быть соединены посредством гибридного подключения с использованием либо подключений Cloud Interconnect VLAN, либо туннелей Cloud VPN с Cloud Router. Мы рекомендуем использовать соединение высокой доступности.

Облачный маршрутизатор с поддержкой глобальной динамической маршрутизации узнает о конкретной конечной точке через BGP и программирует ее в вашей сети Google Cloud VPC. Региональная динамическая маршрутизация не поддерживается. Статические маршруты также не поддерживаются.

Сеть Google Cloud VPC, которую вы используете для настройки Cloud Interconnect или Cloud VPN, — это та же сеть, которую вы используете для настройки гибридного развертывания балансировки нагрузки. Убедитесь, что диапазоны CIDR подсети вашей сети VPC не конфликтуют с вашими удаленными диапазонами CIDR. Когда IP-адреса перекрываются, маршруты подсети имеют приоритет над удаленным подключением.

Инструкции см.:

Рекламные объявления настраиваемых маршрутов

Для подсетей, указанных ниже, требуются специальные объявления от облачного маршрутизатора в локальной сети, обеспечивающие обновление локальных правил брандмауэра.

Подсеть	Описание
172.16.0.0/23	Прокси-подсеть, используемая для прямого взаимодействия с локальной службой.
130.211.0.0/22, 35.191.0.0/16	Проверка работоспособности облака Google

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

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

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

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

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

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

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

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

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

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

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

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

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

Внутри Cloud Shell выполните следующие действия: использование SHARED_VIP не поддерживается в Private Service Connect, вместо этого используйте GCE_ENDPOINT.

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

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

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

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

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

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

Вы должны создавать подсети только для прокси-серверов независимо от того, работает ли ваша сеть в автоматическом режиме или настраиваемая. Подсеть только для прокси-сервера должна предоставлять 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 --network=producer-vpc --region=us-central1 --range=100.100.10.0/24 --purpose=private-service-connect

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

Настройте правила брандмауэра , чтобы разрешить трафик между конечными точками Private Service Connect и вложением службы. В лаборатории кода создано правило входящего брандмауэра, разрешающее подсети NAT 100.100.10.0/24 доступ к приложению службы Private Service Connect (внутреннему балансировщику нагрузки).

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

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

Внутри 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

Настройка гибридного подключения NEG

При создании NEG используйте ЗОНУ, которая минимизирует географическое расстояние между Google Cloud и вашей локальной или другой облачной средой. Например, если вы размещаете службу в локальной среде во Франкфурте, Германия, вы можете указать зону Google Cloud Europe-west3-a при создании NEG.

Более того, если вы используете Cloud Interconnect, ЗОНА, используемая для создания NEG, должна находиться в том же регионе, где было настроено подключение Cloud Interconnect.

Доступные регионы и зоны см. в документации Compute Engine: Доступные регионы и зоны .

Внутри Cloud Shell создайте NEG гибридного подключения с помощью команды 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

Внутри Cloud Shell добавьте локальную конечную точку IP:Port в гибридный NEG.

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

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

На следующих шагах вы настроите балансировщик нагрузки (правило переадресации) и свяжете его с группой конечных точек сети.

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

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

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

 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

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

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

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

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

Создайте целевой прокси-сервер 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

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

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

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

Выбор «on-premise-svc-url-map» дает внешний IP-адрес и идентифицирует внутреннюю службу.

5. Просмотр изученных маршрутов локально.

Перейдите в Сеть VPC → Маршруты. Обратите внимание: изученная подсеть локального сервиса 192.168.1.0/27.

6. Проверка подключения к локальной службе.

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

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

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

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

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

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

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

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

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

Выполните завивку, проверяющую подключение к локальной службе. После подтверждения выйдите из виртуальной машины и вернитесь к приглашению Cloud Shell. Замените IP-адрес внутреннего балансировщика нагрузки на основе результатов, определенных на шаге 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. Создайте вложение службы Private Service Connect.

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

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

Внутри 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

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

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>

Проверьте вложение службы TCP

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

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

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

Сведения о вложении службы: projects/<projectname>/regions/us-central1/serviceAttachments/service-1.

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

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

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

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

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

Внутри Cloud Shell создайте подсеть GCE.

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

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

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

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

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

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

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

Внутри 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

9. Проверка подключения потребительского частного сервиса — потребительского VPC

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

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

10. Проверка подключения потребительского частного сервиса — поставщика VPC

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

11. Создайте частную зону DNS и запись

Создайте частную зону DNS, сопоставленную с конечной точкой подключения PSC, обеспечивающую беспрепятственный доступ к источнику с любого хоста в VPC.

Из 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. Проверка доступа потребителя к службе производителей с помощью виртуальной машины.

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

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

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

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

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

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

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

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

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

Внутри 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!!

Ниже приведен пример захвата данных из локальной службы. Обратите внимание, что исходный IP-адрес 172.16.0.13 находится в диапазоне подсети прокси-сервера 172.16.0.0/23.

13. Уборка продюсера

Удалить компоненты производителя

Внутри Cloud Shell удалите тестовые экземпляры в Producer VPC.

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. Уборка потребителей

Удалить потребительские компоненты

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

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. Поздравления

Поздравляем, вы успешно настроили и проверили Private Service Connect с внутренним балансировщиком нагрузки HTTP(S).

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

Что дальше?

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

Подключайтесь к локальным службам через гибридную сеть с помощью Private Service Connect и Hybrid NEG с внутренним балансировщиком нагрузки HTTP(s).

1. Введение

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

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

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

Установите гибридное соединение

Рекламные объявления настраиваемых маршрутов

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

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

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

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

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

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

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

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

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

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

Настройка гибридного подключения NEG

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

4. Проверка балансировщика нагрузки

5. Просмотр изученных маршрутов локально.

6. Проверка подключения к локальной службе.

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

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

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

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

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

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

9. Проверка подключения потребительского частного сервиса — потребительского VPC

10. Проверка подключения потребительского частного сервиса — поставщика VPC

11. Создайте частную зону DNS и запись

12. Проверка доступа потребителя к службе производителей с помощью виртуальной машины.

Ниже приведен пример захвата данных из локальной службы. Обратите внимание, что исходный IP-адрес 172.16.0.13 находится в диапазоне подсети прокси-сервера 172.16.0.0/23.

13. Уборка продюсера

Удалить компоненты производителя

14. Уборка потребителей

Удалить потребительские компоненты

15. Поздравления

Что дальше?

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

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