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

1. Введение

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

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

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

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

Что вы построите

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

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

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

• Как создать внутренний балансировщик нагрузки HTTP(S) с бэкэндом Hybrid NEG
• Как установить связь между производителем (приложением к услуге) и потребителем (правилом переадресации) частной услуги.

Примечание: Данная практическая работа посвящена реализации внутреннего балансировщика нагрузки HTTP(S) с использованием PSC. Настройка гибридной сети не документирована, хотя предоставлены сопроводительная документация и скриншоты.

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

• Устоявшиеся гибридные сети, например, HA VPN, Interconnect, SW-WAN.
• Проект Google Cloud

Создать гибридную связь

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

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

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

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

• Документация по облачному VPN
• Документация по взаимосвязи облачных сервисов

Реклама на заказных маршрутах

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

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

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

Обновите проект, чтобы он поддерживал практическое занятие.

В этом практическом занятии используется переменная `$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

Используйте команду `computer addresses describe` , чтобы просмотреть выделенный 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 адресов только для прокси-сервера).

Примечание: Для работы подсети, предназначенной только для прокси, требуется объявление BGP от клиента в локальной сети, поэтому она маршрутизируется в вашу локальную сеть; доступ к сервису обеспечивается через предоставленную подсеть прокси.

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

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 перейдите в раздел «Сетевые службы» → «Балансировка нагрузки» → «Балансировщики нагрузки» . Обратите внимание, что значение 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, чтобы проверить подключение к локальной службе, выполнив команду curl к IP-адресу балансировщика нагрузки. Повторите попытку, если произойдет таймаут.

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

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

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

Выбор Service-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. Проверка подключения частной службы потребителя (Consumer Private Service Connect) - Потребительская VPC

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

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

10. Проверка подключения частного сервиса потребителя к платному сервису производителя (VPC).

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

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

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

Примечание: Доступ к потребительской точке через пиринг 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 создайте тестовый экземпляр в VPC потребителя.

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 создайте тестовый экземпляр в VPC потребителя.

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

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

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

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

Внутри Cloud Shell выполнить команду curl

$ 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 удалите тестовые экземпляры в VPC Producer.

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

Что дальше?

Посмотрите некоторые из этих практических занятий по программированию...

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

Дополнительная литература и видеоматериалы

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

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

• Обзор внутреннего балансировщика нагрузки HTTP(s)
• Обзор медицинских осмотров
• Как опубликовать сервис с помощью Private Service Connect