1. Введение
Внутренний региональный балансировщик нагрузки TCP-прокси с гибридным подключением позволяет сделать службу, размещенную в локальной или другой облачной среде, доступной для клиентов в вашей сети VPC.
Если вы хотите сделать гибридную службу доступной в других сетях VPC, вы можете использовать Private Service Connect для публикации службы . Разместив вложение службы перед внутренним региональным балансировщиком нагрузки TCP-прокси, вы можете позволить клиентам в других сетях VPC получать доступ к гибридным службам, работающим в локальных или других облачных средах.
Что ты построишь
В этой лабораторной работе вы собираетесь создать внутренний балансировщик нагрузки TCP-прокси с гибридным подключением к локальной службе с использованием группы конечных точек сети. Из потребителя VPC сможет взаимодействовать с локальным сервисом.
Что вы узнаете
- Как создать TCP-прокси-ILB с гибридной внутренней службой 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 | Подсеть TCP-прокси, используемая для прямого взаимодействия с локальной службой. |
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
Создайте подсети TCP-прокси.
Распределение прокси осуществляется на уровне 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
Создайте входящее правило брандмауэра, позволяющее локальным службам взаимодействовать с подсетью прокси через порт 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 tcp on-prem-service-hc \
--region=us-central1 \
--use-serving-port
Внутри Cloud Shell создайте серверную службу для локальной серверной части.
gcloud compute backend-services create on-premise-service-backend \
--load-balancing-scheme=INTERNAL_MANAGED \
--protocol=TCP \
--region=us-central1 \
--health-checks=on-prem-service-hc \
--health-checks-region=us-central1
Внутри Cloud Shell добавьте гибридную серверную часть NEG к серверной службе. В поле MAX_CONNECTIONS введите максимальное количество одновременных подключений, которые должна обрабатывать серверная часть.
gcloud compute backend-services add-backend on-premise-service-backend \
--network-endpoint-group=on-prem-service-neg \
--network-endpoint-group-zone=us-central1-a \
--region=us-central1 \
--balancing-mode=CONNECTION \
--max-connections=100
Внутри Cloud Shell создайте целевой прокси.
gcloud compute target-tcp-proxies create on-premise-svc-tcpproxy \
--backend-service=on-premise-service-backend \
--region=us-central1
В Cloud Shell создайте правило переадресации (ILB).
Создайте правило переадресации с помощью команды создания правил пересылки gcloud Compute .
Замените FWD_RULE_PORT одним номером порта от 1 до 65535. Правило пересылки пересылает только пакеты с соответствующим портом назначения.
gcloud compute forwarding-rules create tcp-ilb-psc \
--load-balancing-scheme=INTERNAL_MANAGED \
--network=producer-vpc \
--subnet=subnet-201 \
--ports=80 \
--region=us-central1 \
--target-tcp-proxy=on-premise-svc-tcpproxy \
--target-tcp-proxy-region=us-central1
Получите IP-адрес внутреннего балансировщика нагрузки.
gcloud compute forwarding-rules describe tcp-ilb-psc --region=us-central1 | grep -i IPAddress:
Example output:
gcloud compute forwarding-rules describe tcp-ilb-psc --region=us-central1 | grep -i IPAddress:
IPAddress: 10.10.1.2
4. Проверка балансировщика нагрузки
В Cloud Console перейдите в «Сетевые службы» → «Балансировка нагрузки» → «Балансировщики нагрузки». Обратите внимание, что 1 NEG имеет зеленый цвет, что указывает на успешную проверку работоспособности локальной службы.
Выбор «on-premise-service-backend» дает внешний 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-адрес внутреннего балансировщика нагрузки на основе результатов, определенных на шагах 3 и 4.
deepakmichael@test-box-us-central1:~$ curl -v 10.10.1.2
* Expire in 0 ms for 6 (transfer 0x55b9a6b2f0f0)
* Trying 10.10.1.2...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55b9a6b2f0f0)
* Connected to 10.10.1.2 (10.10.1.2) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.10.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, 05 Dec 2022 15:42:38 GMT
< Cache-Control: max-age=0
< Content-Length: 37
< Date: Mon, 05 Dec 2022 15:42:38 GMT
< Server: lighttpd/1.4.53
<
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=tcp-ilb-psc --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=psc-nat-subnet
Необязательно: при использовании общего VPC создайте вложение службы в проекте службы.
gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=tcp-ilb-psc --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=projects/<hostproject>/regions/<region>/subnetworks/<natsubnet>
Проверьте вложение службы TCP
gcloud compute service-attachments describe service-1 --region us-central1
8. Необязательно: перейдите в «Сетевые службы» → «Подключение частной службы», чтобы просмотреть вновь созданное вложение службы.
Выбор Службы-1 предоставляет более подробную информацию, включая URI вложения службы, используемый потребителем для установления соединения с частной службой. Запишите URI, поскольку он будет использоваться на более позднем этапе.
Сведения о вложении службы: projects/<projectname>/regions/us-central1/serviceAttachments/service-1.
9. Настройка потребителя
Создайте потребительский 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
10. Проверка подключения к частному сервису потребителя — Consumer VPC
В потребительском VPC проверьте успешное подключение частной службы, перейдя в раздел «Сетевые службы» → «Подключение частной службы» → «Подключенные конечные точки» . Обратите внимание на установленное соединение psc-consumer-1 и соответствующий IP-адрес, который мы создали ранее.
При выборе psc-consumer-1 предоставляются дополнительные сведения, включая URI вложения службы.
11. Проверка подключения потребительского частного сервиса — поставщика VPC
В VPC-источнике проверьте успешное подключение частной службы, перейдя в раздел «Сетевые службы» → «Подключение частной службы» → «Опубликованная служба». Обратите внимание, что опубликованное соединение службы-1 теперь указывает 1 правило переадресации (конечная точка соединения).
12. Создайте частную зону 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"
13. Проверка доступа потребителя к службе производителей с помощью виртуальной машины.
В потребительском 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.2 находится в диапазоне подсети TCP-прокси 172.16.0.0/23.
14. Уборка продюсера
Удалить компоненты производителя
Внутри Cloud Shell удалите компоненты производителя.
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 tcp-ilb-psc --region=us-central1 --quiet
gcloud compute target-tcp-proxies delete on-premise-svc-tcpproxy --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 networks subnets delete psc-nat-subnet subnet-201 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 on-prem-service-hc --region=us-central1 --quiet
gcloud compute networks delete producer-vpc --quiet
15. Уборка потребителей
Удалить потребительские компоненты
Внутри Cloud Shell удалите потребительские компоненты.
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
16. Поздравления
Поздравляем, вы успешно настроили и проверили Private Service Connect с TCP-прокси.
Вы создали инфраструктуру производителя и добавили вложение службы в VPC производителя, указывающее на локальную службу. Вы узнали, как создать потребительскую конечную точку в Consumer VPC, обеспечивающую подключение к локальной службе.
Что дальше?
Посмотрите некоторые из этих кодовых лабораторий...
- Использование Private Service для публикации и использования сервисов с помощью GKE
- Использование Private Service Connect для публикации и использования сервисов