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 |
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 подключаться к вашим экземплярам виртуальных машин, создайте правило брандмауэра, которое:
- Применяется ко всем экземплярам виртуальных машин, доступ к которым вы хотите сделать с помощью 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 для публикации и использования сервисов с помощью GKE
- Использование Private Service Connect для публикации и использования сервисов
- Подключайтесь к локальным службам через гибридную сеть с помощью Private Service Connect и внутреннего балансировщика нагрузки TCP-прокси.
Дальнейшее чтение и видео
- Обзор частного сервиса Connect
- Что такое подключение к частному сервису?
- Поддерживаемые типы балансировщиков нагрузки