1. Введение
Пиринг VPC — это распространенный метод, с помощью которого производители предлагают потребление услуг своим пользователям. Однако использование пиринга VPC сопряжено со многими сложностями маршрутизации, такими как нетранзитивный пиринг VPC, большое потребление IP-адресов и чрезмерная доступность ресурсов в одноранговом VPC.
Private Service Connect (PSC) — это метод подключения, который позволяет производителям предоставлять услугу через одну конечную точку, которую потребитель предоставляет в VPC рабочей нагрузки. Это устраняет множество проблем, с которыми пользователи сталкиваются при пиринге VPC. Несмотря на то, что с помощью PSC создается множество новых сервисов, все еще существует множество сервисов, которые существуют как пиринговые сервисы VPC.
Google Cloud рада представить способ миграции сервисов , созданных вами с помощью пиринга VPC, на архитектуру на основе PSC. При использовании этого метода миграции IP-адрес службы производителя, предоставляемый через пиринг VPC, сохраняется в архитектуре на основе PSC, поэтому для потребителя требуются минимальные изменения. Следуйте инструкциям в этой кодовой лаборатории, чтобы изучить технические этапы выполнения этой миграции.
ПРИМЕЧАНИЕ. Этот путь миграции предназначен только для сервисов, где производитель и потребитель существуют в одной организации Google Cloud. Для любых сервисов Google Cloud или сторонних сервисов, использующих пиринг VPC, будет использоваться аналогичный метод миграции, но он будет настроен для самой службы. Обратитесь к соответствующим сторонам, чтобы узнать о пути перехода для этих типов услуг.
Что вы узнаете
- Как настроить службу пиринга VPC
- Как настроить сервис на базе PSC
- Использование API внутренних диапазонов для выполнения миграции подсети через пиринг VPC для достижения миграции службы пиринга VPC в службу PSC.
- Понимание того, когда должен произойти простой для миграции услуг
- Этапы очистки миграции
Что вам понадобится
- Проект Google Cloud с разрешениями владельца
2. Топология Codelab
Для простоты эта кодовая лаборатория централизует все ресурсы в одном проекте. В кодлабе будет отмечено, какие действия необходимо выполнить на стороне производителя и какие действия необходимо выполнить на стороне потребителя в том случае, если производители и потребители находятся в разных проектах.
Эта кодовая лаборатория будет иметь 4 состояния.
Состояние 1 — это состояние пиринга VPC. Будет два VPC: Consumer-VPC и Producer-VPC, которые будут пиринговаться вместе. Producer-vpc будет иметь простую службу Apache, предоставляемую через внутренний балансировщик нагрузки сквозной сети. Consumer-vpc будет иметь одну потребительскую виртуальную машину для целей тестирования.
Состояние 2 — это состояние тестирования PSC. Мы создадим новое правило переадресации и будем использовать его для связи с нашим прикрепленным сервисом. Затем мы создадим тестовую конечную точку PSC в Consumer-VPC, чтобы проверить, работает ли наша служба PSC должным образом.
Состояние 3 – это состояние миграции. Мы зарезервируем диапазон подсети в Producer-VPC, где была развернута служба пиринга VPC, для использования в Consumer-VPC. Затем мы создадим новую конечную точку PSC с тем же IP-адресом, что и уже существующее правило переадресации в Producer-VPC.
Состояние 4 является конечным состоянием PSC. Мы очистим тестовую конечную точку PSC и удалим пиринг VPC между Consumer-VPC и Producer-VPC.
3. Настройка и требования
Самостоятельная настройка среды
- Войдите в Google Cloud Console и создайте новый проект или повторно используйте существующий. Если у вас еще нет учетной записи Gmail или Google Workspace, вам необходимо ее создать .
- Имя проекта — это отображаемое имя для участников этого проекта. Это строка символов, не используемая API Google. Вы всегда можете обновить его.
- Идентификатор проекта уникален для всех проектов Google Cloud и является неизменяемым (невозможно изменить после его установки). Cloud Console автоматически генерирует уникальную строку; обычно тебя не волнует, что это такое. В большинстве лабораторий кода вам потребуется указать идентификатор проекта (обычно идентифицируемый как
PROJECT_ID). Если вам не нравится сгенерированный идентификатор, вы можете создать другой случайный идентификатор. Альтернативно, вы можете попробовать свой собственный и посмотреть, доступен ли он. Его нельзя изменить после этого шага и он сохраняется на протяжении всего проекта. - К вашему сведению, есть третье значение — номер проекта , которое используют некоторые API. Подробнее обо всех трех этих значениях читайте в документации .
- Затем вам необходимо включить выставление счетов в Cloud Console, чтобы использовать облачные ресурсы/API. Прохождение этой кодовой лаборатории не будет стоить много, если вообще что-то стоить. Чтобы отключить ресурсы и избежать выставления счетов за пределами этого руководства, вы можете удалить созданные вами ресурсы или удалить проект. Новые пользователи Google Cloud имеют право на участие в программе бесплатной пробной версии стоимостью 300 долларов США .
Запустить Cloud Shell
Хотя Google Cloud можно управлять удаленно с вашего ноутбука, в этой лаборатории вы будете использовать Google Cloud Shell , среду командной строки, работающую в облаке.
В Google Cloud Console щелкните значок Cloud Shell на верхней правой панели инструментов:
Подготовка и подключение к среде займет всего несколько минут. Когда все будет готово, вы должны увидеть что-то вроде этого:
Эта виртуальная машина оснащена всеми необходимыми инструментами разработки. Он предлагает постоянный домашний каталог объемом 5 ГБ и работает в Google Cloud, что значительно повышает производительность сети и аутентификацию. Всю работу в этой лаборатории кода можно выполнять в браузере. Вам не нужно ничего устанавливать.
4. Прежде чем начать
Включить API
В Cloud Shell убедитесь, что ваш проект настроен, и настройте переменные.
gcloud auth login gcloud config list project gcloud config set project [YOUR-PROJECT-ID] export projectid=[YOUR-PROJECT-ID] export region=us-central1 export zone=$region-a echo $projectid echo $region echo $zone
Включите все необходимые сервисы
gcloud services enable compute.googleapis.com gcloud services enable networkconnectivity.googleapis.com gcloud services enable dns.googleapis.com
5. Создание сети VPC производителя (деятельность производителя)
Сеть VPC
Из Cloud Shell
gcloud compute networks create producer-vpc \
--subnet-mode=custom
Создание подсетей
Из Cloud Shell
gcloud compute networks subnets create producer-service-subnet \
--network=producer-vpc \
--range=10.0.0.0/28 \
--region=$region
gcloud compute networks subnets create producer-fr-subnet \
--network=producer-vpc \
--range=192.168.0.0/28 \
--region=$region
Создайте облачный маршрутизатор производителя и облачный NAT.
Из Cloud Shell
gcloud compute routers create $region-cr \
--network=producer-vpc \
--region=$region
gcloud compute routers nats create $region-nat \
--router=$region-cr \
--region=$region \
--nat-all-subnet-ip-ranges \
--auto-allocate-nat-external-ips
Создание политики и правил брандмауэра сети производителя.
Из Cloud Shell
gcloud compute network-firewall-policies create producer-vpc-policy --global
gcloud compute network-firewall-policies associations create \
--firewall-policy producer-vpc-policy \
--network producer-vpc \
--name network-producer-vpc \
--global-firewall-policy
Чтобы разрешить IAP подключаться к вашим экземплярам виртуальных машин, создайте правило брандмауэра, которое:
- Применяется ко всем экземплярам виртуальных машин, доступ к которым вы хотите сделать с помощью IAP.
- Разрешает входящий трафик из диапазона IP 35.235.240.0/20. Этот диапазон содержит все IP-адреса, которые IAP использует для пересылки TCP.
Из Cloud Shell
gcloud compute network-firewall-policies rules create 1000 \
--action ALLOW \
--firewall-policy producer-vpc-policy \
--description "SSH with IAP" \
--direction INGRESS \
--src-ip-ranges 35.235.240.0/20 \
--layer4-configs tcp:22 \
--global-firewall-policy
Мы также создадим еще два правила, которые позволят балансировщику нагрузки проверять работоспособность службы, а также разрешать сетевой трафик от виртуальных машин, которые будут подключаться из потребительского vpc.
Из Cloud Shell
gcloud compute network-firewall-policies rules create 2000 \
--action ALLOW \
--firewall-policy producer-vpc-policy \
--description "LB healthchecks" \
--direction INGRESS \
--src-ip-ranges 130.211.0.0/22,35.191.0.0/16 \
--layer4-configs tcp:80 \
--global-firewall-policy
gcloud compute network-firewall-policies rules create 3000 \
--action ALLOW \
--firewall-policy producer-vpc-policy \
--description "allow access from consumer-vpc" \
--direction INGRESS \
--src-ip-ranges 10.0.1.0/28 \
--layer4-configs tcp:80 \
--global-firewall-policy
6. Настройка службы продюсера (деятельность продюсера)
Мы создадим службу-производитель с одной виртуальной машиной, на которой работает веб-сервер Apache, которая будет добавлена в группу неуправляемых экземпляров, перед которой находится балансировщик нагрузки сквозной региональной внутренней сети.
Создайте группу виртуальных машин и неуправляемых экземпляров.
Из Cloud Shell
gcloud compute instances create producer-service-vm \
--network producer-vpc \
--subnet producer-service-subnet \
--zone $zone \
--no-address \
--metadata startup-script='#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
a2enmod ssl
sudo a2ensite default-ssl
echo "I am a Producer Service." | \
tee /var/www/html/index.html
systemctl restart apache2'
Из Cloud Shell
gcloud compute instance-groups unmanaged create prod-uig \ --zone=$zone gcloud compute instance-groups unmanaged add-instances prod-uig \ --zone=$zone \ --instances=producer-service-vm
Создание транзитного балансировщика нагрузки региональной внутренней сети.
Из Cloud Shell
gcloud compute health-checks create http producer-hc \
--region=$region
gcloud compute backend-services create producer-bes \
--load-balancing-scheme=internal \
--protocol=tcp \
--region=$region \
--health-checks=producer-hc \
--health-checks-region=$region
gcloud compute backend-services add-backend producer-bes \
--region=$region \
--instance-group=prod-uig \
--instance-group-zone=$zone
gcloud compute addresses create producer-fr-ip\
--region $region \
--subnet producer-fr-subnet \
--addresses 192.168.0.2
gcloud compute forwarding-rules create producer-fr \
--region=$region \
--load-balancing-scheme=internal \
--network=producer-vpc \
--subnet=producer-fr-subnet \
--address=producer-fr-ip \
--ip-protocol=TCP \
--ports=80 \
--backend-service=producer-bes \
--backend-service-region=$region
7. Создайте потребительскую сеть VPC (деятельность потребителя)
Сеть VPC
Из Cloud Shell
gcloud compute networks create consumer-vpc \
--subnet-mode=custom
Создать подсеть
Из Cloud Shell
gcloud compute networks subnets create consumer-vm-subnet \
--network=consumer-vpc \
--range=10.0.1.0/28 \
--region=$region
Создание политики и правил брандмауэра потребительской сети
Мы создадим еще одну политику сетевого брандмауэра для потребительского vpc.
Из Cloud Shell
gcloud compute network-firewall-policies create consumer-vpc-policy --global
gcloud compute network-firewall-policies associations create \
--firewall-policy consumer-vpc-policy \
--network consumer-vpc \
--name network-consumer-vpc \
--global-firewall-policy
gcloud compute network-firewall-policies rules create 1000 \
--action ALLOW \
--firewall-policy consumer-vpc-policy \
--description "SSH with IAP" \
--direction INGRESS \
--src-ip-ranges 35.235.240.0/20 \
--layer4-configs tcp:22 \
--global-firewall-policy
8. Создайте узел VPC
Продюсерская деятельность
Из Cloud Shell
gcloud compute networks peerings create producer-vpc-peering \
--network=producer-vpc \
--peer-project=$projectid \
--peer-network=consumer-vpc
Потребительская активность
Из Cloud Shell
gcloud compute networks peerings create consumer-vpc-peering \
--network=consumer-vpc \
--peer-project=$projectid \
--peer-network=producer-vpc
Убедитесь, что пиринг установлен, проверив список маршрутов в файле Consumer-VPC. Вы должны увидеть маршруты как для Consumer-VPC, так и для Producer-VPC.
Потребительская активность
Из Cloud Shell
gcloud compute routes list --filter="network=consumer-vpc"
Ожидаемый результат
NAME: default-route-49dda7094977e231 NETWORK: consumer-vpc DEST_RANGE: 0.0.0.0/0 NEXT_HOP: default-internet-gateway PRIORITY: 1000 NAME: default-route-r-10d65e16cc6278b2 NETWORK: consumer-vpc DEST_RANGE: 10.0.1.0/28 NEXT_HOP: consumer-vpc PRIORITY: 0 NAME: peering-route-496d0732b4f11cea NETWORK: consumer-vpc DEST_RANGE: 192.168.0.0/28 NEXT_HOP: consumer-vpc-peering PRIORITY: 0 NAME: peering-route-b4f9d3acc4c08d55 NETWORK: consumer-vpc DEST_RANGE: 10.0.0.0/28 NEXT_HOP: consumer-vpc-peering PRIORITY: 0
9. Создайте зону DNS (активность потребителя)
Мы создадим частную зону Cloud DNS для вызова службы производителя через DNS, а не через частный IP-адрес, чтобы продемонстрировать более реалистичный пример.
Мы добавим запись A в домен example.com, указывающую service.example.com на IP-адрес правила переадресации балансировщика сетевой нагрузки, который мы создали ранее. IP-адрес этого правила переадресации — 192.168.0.2.
Из Cloud Shell
gcloud dns managed-zones create "producer-service" \ --dns-name=example.com \ --description="producer service dns" \ --visibility=private \ --networks=consumer-vpc gcloud dns record-sets transaction start \ --zone="producer-service" gcloud dns record-sets transaction add 192.168.0.2 \ --name=service.example.com \ --ttl=300 \ --type=A \ --zone="producer-service" gcloud dns record-sets transaction execute \ --zone="producer-service"
10. Служба производителя тестирования через одноранговый узел VPC (активность потребителя)
На данный момент архитектура State 1 создана.
Создайте виртуальную машину потребительского клиента.
Из Cloud Shell
gcloud compute instances create consumer-client \ --zone=$zone \ --subnet=consumer-vm-subnet \ --no-address
Тестирование подключения
Из Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
Из виртуальной машины потребительского клиента
curl service.example.com
Ожидаемый результат
I am a Producer Service.
Из виртуальной машины потребительского клиента
exit
11. Подготовка службы к частному подключению службы (деятельность продюсера)
Теперь, когда мы завершили все первоначальные шаги по настройке, мы приступим к подготовке службы VPC-Peered к миграции на Private Service Connect. В этом разделе мы внесем изменения в производитель-vpc, настроив службу для предоставления через вложение службы. Нам нужно будет создать новую подсеть и новое правило переадресации в этой подсети, чтобы мы могли перенести существующую подсеть в потребительский виртуальный компьютер и сохранить существующий IP-адрес службы нетронутым.
Создайте подсеть, в которой будет размещаться новый IP-адрес правила переадресации балансировщика нагрузки.
Из Cloud Shell
gcloud compute networks subnets create producer-psc-fr-subnet \
--network=producer-vpc \
--range=10.0.2.64/28 \
--region=$region
Создайте внутренний IP-адрес правила переадресации балансировщика нагрузки.
Из Cloud Shell
gcloud compute addresses create producer-psc-ip \ --region $region \ --subnet producer-psc-fr-subnet \ --addresses 10.0.2.66
Создайте новое правило переадресации балансировщика нагрузки. Это правило настроено на использование той же серверной службы и проверок работоспособности, которые мы настроили ранее.
Из Cloud Shell
gcloud compute forwarding-rules create psc-service-fr \ --region=$region \ --load-balancing-scheme=internal \ --network=producer-vpc \ --subnet=producer-psc-fr-subnet \ --address=producer-psc-ip \ --ip-protocol=TCP \ --ports=80 \ --backend-service=producer-bes \ --backend-service-region=$region
Подсеть psc-nat-subnet будет связана с приложением службы PSC для целей трансляции сетевых адресов. Для производственных вариантов использования размер этой подсети должен быть соответствующим, чтобы поддерживать количество подключенных конечных точек. Дополнительную информацию см. в документации по определению размеров подсети PSC NAT.
Из Cloud Shell
gcloud compute networks subnets create psc-nat-subnet \
--network=producer-vpc \
--range=10.100.100.0/28 \
--region=$region \
--purpose=PRIVATE_SERVICE_CONNECT
Мы должны добавить дополнительное правило брандмауэра в политику сетевого брандмауэра, чтобы теперь разрешать трафик из подсети psc-nat-subnet. При доступе к службе через PSC трафик будет поступать в подсеть psc-nat-subnet.
Из Cloud Shell
gcloud compute network-firewall-policies rules create 2001 \
--action ALLOW \
--firewall-policy producer-vpc-policy \
--description "allow PSC NAT subnet" \
--direction INGRESS \
--src-ip-ranges 10.100.100.0/28 \
--layer4-configs tcp:80 \
--global-firewall-policy
Создайте вложение службы и запишите URI вложения службы, чтобы настроить конечную точку PSC в следующем разделе.
Из Cloud Shell
gcloud compute service-attachments create producer-sa \
--region=$region \
--producer-forwarding-rule=psc-service-fr \
--connection-preference=ACCEPT_MANUAL \
--consumer-accept-list=$projectid=5 \
--nat-subnets=psc-nat-subnet
Из Cloud Shell
gcloud compute service-attachments describe producer-sa --region=$region
Пример вывода
connectionPreference: ACCEPT_MANUAL consumerAcceptLists: - connectionLimit: 5 projectIdOrNum: $projectid creationTimestamp: '2025-04-24T11:23:09.886-07:00' description: '' enableProxyProtocol: false fingerprint: xxx id: 'xxx' kind: compute#serviceAttachment name: producer-sa natSubnets: - https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region/subnetworks/psc-nat-subnet pscServiceAttachmentId: high: 'xxx' low: 'xxx' reconcileConnections: false region: https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region selfLink: https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region/serviceAttachments/producer-sa targetService: https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region/forwardingRules/psc-service-fr
12. Подключите «тестовую» конечную точку Consumer PSC к службе производителя и протестируйте (активность потребителя)
Архитектура сейчас находится в состоянии 2.
На данный момент существующая служба производителя, предоставляемая через пиринг VPC, все еще активна и работает правильно в производственном сценарии. Мы создадим «тестовую» конечную точку PSC, чтобы убедиться, что предоставленное вложение службы работает правильно, прежде чем мы начнем период простоя для миграции текущей подсети пиринга VPC в потребительский VPC. Нашим конечным соединением будет конечная точка PSC с тем же IP-адресом, что и текущее правило переадресации для службы на основе пиринга VPC.
Создать конечную точку PSC
Из Cloud Shell
gcloud compute addresses create test-psc-endpoint-ip \
--region=$region \
--subnet=consumer-vm-subnet \
--addresses 10.0.1.3
Целевой службой ниже будет URI вложения службы, который вы указали на последнем шаге.
Из Cloud Shell
gcloud compute forwarding-rules create test-psc-endpoint \ --region=$region \ --network=consumer-vpc \ --address=test-psc-endpoint-ip \ --target-service-attachment=projects/$projectid/regions/$region/serviceAttachments/producer-sa
Протестируйте «тестовую» конечную точку PSC
Из Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
От потребителя-клиента
curl 10.0.1.3
Ожидаемый результат
I am a Producer Service.
От потребителя-клиента
exit
13. Перенос существующей подсети правила переадресации производителя.
Выполнение этих действий приведет к отключению работающей службы Producer на основе пиринга VPC. Теперь мы перенесем подсеть правил переадресации с vpc производителя на vpc потребителя с помощью API внутренних диапазонов . Это заблокирует использование подсети в промежуточный период, когда мы удалим подсеть в поставщике-vpc и назначим ее только в целях миграции для создания в потребительском-vpc.
API внутреннего диапазона требует, чтобы вы зарезервировали существующую подсеть правила переадресации пиринга VPC (producer-fr-subnet, 192.168.0.0/28) и указали имя целевой подсети в Consumer-vpc (consumer-psc-subnet). Создаем новую подсеть в Consumer-VPC с этим именем в несколько шагов.
Зарезервируйте подсеть Producer-FR для миграции.
Продюсерская деятельность
Из Cloud Shell
gcloud network-connectivity internal-ranges create producer-peering-internal-range \
--ip-cidr-range=192.168.0.0/28 \
--network=producer-vpc \
--usage=FOR_MIGRATION \
--migration-source=projects/$projectid/regions/$region/subnetworks/producer-fr-subnet \
--migration-target=projects/$projectid/regions/$region/subnetworks/consumer-psc-subnet
Запустите описание внутреннего диапазона, который мы создали, чтобы просмотреть состояние подсети.
Продюсерская деятельность
Из Cloud Shell
gcloud network-connectivity internal-ranges describe producer-peering-internal-range
Пример вывода
createTime: '2025-04-24T19:26:10.589343291Z' ipCidrRange: 192.168.0.0/28 migration: source: projects/$projectid/regions/$region/subnetworks/producer-fr-subnet target: projects/$projectid/regions/$region/subnetworks/consumer-psc-subnet name: projects/$projectid/locations/global/internalRanges/producer-peering-internal-range network: https://www.googleapis.com/compute/v1/projects/$project/global/networks/producer-vpc peering: FOR_SELF updateTime: '2025-04-24T19:26:11.521960016Z' usage: FOR_MIGRATION
Удалите правило переадресации и подсеть на основе пиринга VPC.
Продюсерская деятельность
Из Cloud Shell
gcloud compute forwarding-rules delete producer-fr --region=$region gcloud compute addresses delete producer-fr-ip --region=$region gcloud compute networks subnets delete producer-fr-subnet --region=$region
Перенос подсети
Перенесите подсеть в потребительский виртуальный компьютер, создав новую подсеть, используя внутренний диапазон, который мы создали ранее. Имя этой подсети должно быть тем же именем, которое мы указали ранее (consumer-psc-subnet). Конкретная цель PEER_MIGRATION отмечает, что подсеть зарезервирована для миграции подсети между одноранговыми VPC. С этим флагом назначения эта подсеть может содержать только зарезервированные статические IP-адреса и конечные точки PSC.
Потребительская активность
Из Cloud Shell
gcloud compute networks subnets create consumer-psc-subnet \ --purpose=PEER_MIGRATION \ --network=consumer-vpc \ --range=192.168.0.0/28 \ --region=$region
14. Создайте конечную точку PSC конечного состояния (активность потребителя)
На данный момент служба Producer все еще не работает. Подсеть, которую мы только что создали, по-прежнему заблокирована и может использоваться только для конкретной цели миграции. Вы можете проверить это, попытавшись создать виртуальную машину в этой подсети. Создание виртуальной машины завершится неудачно.
Из Cloud Shell
gcloud compute instances create test-consumer-vm \
--zone=$zone \
--subnet=consumer-psc-subnet \
--no-address
Ожидаемый результат
ERROR: (gcloud.compute.instances.create) Could not fetch resource: - Subnetwork must have purpose=PRIVATE.
Мы можем использовать эту подсеть только для создания конечной точки PSC. Обратите внимание, что создаваемый нами IP-адрес использует тот же IP-адрес, что и правило переадресации, которое наша служба производителя использовала для узла VPC.
Из Cloud Shell
gcloud compute addresses create psc-endpoint-ip \
--region=$region \
--subnet=consumer-psc-subnet \
--addresses 192.168.0.2
Еще раз: вы должны использовать тот же URI вложения службы, который вы отметили ранее и который также использовался для создания «тестовой» конечной точки PSC.
Из Cloud Shell
gcloud compute forwarding-rules create psc-endpoint \
--region=$region \
--network=consumer-vpc \
--address=psc-endpoint-ip \
--target-service-attachment=projects/$projectid/regions/$region/serviceAttachments/producer-sa
15. Проверьте конечную точку PSC конечного состояния (активность потребителя)
На данный момент вы находитесь в архитектуре State 3.
Из Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
Из виртуальной машины потребительского клиента
curl service.example.com
Ожидаемый результат
I am a Producer Service.
Из виртуальной машины потребительского клиента
exit
На данный момент сбой закончился, и услуга снова работает. Обратите внимание, что нам не пришлось вносить какие-либо изменения в существующий DNS. Никаких изменений клиента на стороне потребителя вносить не нужно. Приложения могут просто возобновить работу с перенесенной службой.
16. Очистка миграции
Чтобы завершить миграцию, нам необходимо выполнить несколько шагов по очистке. Мы должны удалить и разблокировать ресурсы.
Разблокировать подсеть внутреннего диапазона
Это разблокирует перенесенную подсеть, и ее цель можно будет изменить с «PEER_MIGRATION» на «ЧАСТНАЯ».
Продюсерская деятельность
Из Cloud Shell
gcloud network-connectivity internal-ranges delete producer-peering-internal-range
Потребительская активность
Из Cloud Shell
gcloud compute networks subnets update consumer-psc-subnet \
--region=$region \
--purpose=PRIVATE
gcloud compute networks subnets describe consumer-psc-subnet --region=$region
Пример вывода
creationTimestamp: '2025-04-24T12:29:33.883-07:00' fingerprint: xxx gatewayAddress: 192.168.0.1 id: 'xxx' ipCidrRange: 192.168.0.0/28 kind: compute#subnetwork name: consumer-psc-subnet network: https://www.googleapis.com/compute/v1/projects/$projectid/global/networks/consumer-vpc privateIpGoogleAccess: false privateIpv6GoogleAccess: DISABLE_GOOGLE_ACCESS purpose: PRIVATE region: https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region selfLink: https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region/subnetworks/consumer-psc-subnet
Удаление узлов VPC
Продюсерская деятельность
Из Cloud Shell
gcloud compute networks peerings delete producer-vpc-peering \
--network=producer-vpc
Потребительская активность
Из Cloud Shell
gcloud compute networks peerings delete consumer-vpc-peering \
--network=consumer-vpc
Удалить «тестовую» конечную точку PSC.
Потребительская активность
Из Cloud Shell
gcloud compute forwarding-rules delete test-psc-endpoint --region=$region gcloud compute addresses delete test-psc-endpoint-ip --region=$region
17. Финальный тест после очистки миграции (активность потребителей)
На данный момент архитектура State 4 (окончательное состояние) достигнута.
Еще раз проверьте подключение к конечной точке PSC, чтобы убедиться в отсутствии каких-либо побочных эффектов в результате очистки миграции.
Из Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
Из виртуальной машины потребительского клиента
curl service.example.com
Ожидаемый результат
I am a Producer Service.
Из виртуальной машины потребительского клиента
exit
УСПЕХ!
18. Этапы очистки
Из Cloud Shell
gcloud compute forwarding-rules delete psc-endpoint --region=$region -q gcloud compute addresses delete psc-endpoint-ip --region=$region -q gcloud compute instances delete consumer-client --zone=$zone --project=$projectid -q gcloud dns record-sets delete service.example.com --zone="producer-service" --type=A -q gcloud dns managed-zones delete "producer-service" -q gcloud compute network-firewall-policies rules delete 1000 --firewall-policy consumer-vpc-policy --global-firewall-policy -q gcloud compute network-firewall-policies associations delete --firewall-policy=consumer-vpc-policy --name=network-consumer-vpc --global-firewall-policy -q gcloud compute network-firewall-policies delete consumer-vpc-policy --global -q gcloud compute networks subnets delete consumer-psc-subnet --region=$region -q gcloud compute networks subnets delete consumer-vm-subnet --region=$region -q gcloud compute networks delete consumer-vpc -q gcloud compute service-attachments delete producer-sa --region=$region -q gcloud compute forwarding-rules delete psc-service-fr --region=$region -q gcloud compute addresses delete producer-psc-ip --region=$region -q gcloud compute backend-services delete producer-bes --region=$region -q gcloud compute health-checks delete producer-hc --region=$region -q gcloud compute instance-groups unmanaged delete prod-uig --zone=$zone -q gcloud compute instances delete producer-service-vm --zone=$zone --project=$projectid -q gcloud compute network-firewall-policies rules delete 3000 --firewall-policy producer-vpc-policy --global-firewall-policy -q gcloud compute network-firewall-policies rules delete 2001 --firewall-policy producer-vpc-policy --global-firewall-policy -q gcloud compute network-firewall-policies rules delete 2000 --firewall-policy producer-vpc-policy --global-firewall-policy -q gcloud compute network-firewall-policies rules delete 1000 --firewall-policy producer-vpc-policy --global-firewall-policy -q gcloud compute network-firewall-policies associations delete --firewall-policy=producer-vpc-policy --name=network-producer-vpc --global-firewall-policy -q gcloud compute network-firewall-policies delete producer-vpc-policy --global -q gcloud compute routers nats delete $region-nat --router=$region-cr --region=$region -q gcloud compute routers delete $region-cr --region=$region -q gcloud compute networks subnets delete psc-nat-subnet --region=$region -q gcloud compute networks subnets delete producer-psc-fr-subnet --region=$region -q gcloud compute networks subnets delete producer-service-subnet --region=$region -q gcloud compute networks delete producer-vpc -q
19. Поздравляем!
Поздравляем с завершением работы над кодом.
Что мы рассмотрели
- Как настроить службу пиринга VPC
- Как настроить сервис на базе PSC
- Использование API внутренних диапазонов для выполнения миграции подсети через пиринг VPC для достижения миграции службы пиринга VPC в службу PSC.
- Понимание того, когда должен произойти простой для миграции услуг
- Этапы очистки миграции