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

4ad647fa51b3473e.png

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

  • Как создать внутренний балансировщик нагрузки 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, они используют одну и ту же подсеть только для прокси-сервера для балансировки нагрузки.

  1. Клиент устанавливает соединение с IP-адресом и портом правила переадресации балансировщика нагрузки.
  2. Каждый прокси-сервер прослушивает IP-адрес и порт, указанные в правиле переадресации соответствующего балансировщика нагрузки. Один из прокси получает и разрывает сетевое соединение клиента.
  3. Прокси-сервер устанавливает соединение с соответствующей серверной виртуальной машиной или конечной точкой в ​​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 имеет зеленый цвет, что указывает на успешную проверку работоспособности локальной службы.

bb5d117dee3b8b04.png

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

128a7e85e8069097.png

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

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

d1ab51b79aeea9d8.png

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

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

2f84578c9f2cc361.png

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

41639cb160231275.png

Сведения о вложении службы: 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-адрес, который мы создали ранее.

b91ee5d5c854e60b.png

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

1dbc63217819dcd5.png

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

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

951090b812a8d119.png

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

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

30802152f51ff751.png

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, которая позволяла бы подключаться к локальной службе.

Что дальше?

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

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

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