Łącz się z usługami lokalnymi przez sieć hybrydową z użyciem usługi Private Service Connect i hybrydowej grupy punktów końcowych sieci z wewnętrznym systemem równoważenia obciążenia HTTP(s)

Informacje o tym ćwiczeniu (w Codelabs)
schedule76 minut
subjectOstatnia aktualizacja: 13 grudnia 2022
account_circleAutorzy: Deepak Michael

Równoważenie obciążenia w chmurze umożliwia równoważenie obciążenia ruchu na punktach końcowych wykraczających poza Google Cloud, takich jak centra danych lokalnych i inne chmury publiczne, do których można dotrzeć za pomocą połączenia hybrydowego.

Strategia hybrydowa to praktyczne rozwiązanie, które pozwala dostosować się do zmieniających się wymagań rynku i stopniowo ulepszać aplikacje. Może to być tymczasowe wdrożenie hybrydowe, które umożliwi migrację do nowoczesnego rozwiązania w chmurze, lub stałe rozwiązanie w infrastrukturze IT organizacji.

Konfiguracja hybrydowego równoważenia obciążenia umożliwia również korzystanie z funkcji sieciowych systemu równoważenia obciążenia Cloud do usług działających w ramach istniejącej infrastruktury poza Google Cloud.

Jeśli chcesz udostępnić usługę hybrydową w innych sieciach VPC, możesz użyć Private Service Connect, aby opublikować usługę. Umieszczenie załącznika usługi przed wewnętrznym regionalnym systemem równoważenia obciążenia HTTP(S) pozwala klientom z innych sieci VPC uzyskiwać dostęp do usług hybrydowych działających w środowiskach lokalnych lub innych środowiskach chmurowych.

W tym laboratorium programistycznym utworzysz wewnętrzny system równoważenia obciążenia HTTP(S) z hybrydowym połączeniem z usługą lokalną przy użyciu grupy punktów końcowych sieci. Usługa VPC klienta będzie mogła komunikować się z usługą lokalną przy użyciu portu 80. Port 443 nie jest objęty zakresem tego laboratorium.

4ad647fa51b3473e.png

Czego się nauczysz

  • Jak utworzyć wewnętrzny system równoważenia obciążenia HTTP(S) z backendem hybrydowej grupy punktów końcowych sieci
  • Jak utworzyć producenta (Service Attachment) i konsumenta (regułę przekierowania) usługi Private Service Connect

Czego potrzebujesz

  • Ustanowiona sieć hybrydowa, np.sieć VPN o wysokiej dostępności, połączenie międzysieciowe, sieć SW-WAN
  • Projekt Google Cloud

Ustanowienie połączeń hybrydowych

Środowiska Google Cloud i środowiska lokalne lub inne środowiska chmurowe muszą być połączone za pomocą połączeń hybrydowych, korzystając z przyłączy VLAN Cloud Interconnect lub tuneli Cloud VPN z routerem Cloud Router. Zalecamy korzystanie z połączenia o wysokiej dostępności.

Cloud Router z włączoną funkcją globalnego routingu dynamicznego uzyskuje informacje o określonym punkcie końcowym za pomocą protokołu BGP i zapisuje je w sieci VPC Google Cloud. Dynamiczny routing regionalny nie jest obsługiwany. Trasy statyczne również nie są obsługiwane.

Sieć VPC Google Cloud, której używasz do konfigurowania Cloud Interconnect lub Cloud VPN, jest tą samą siecią, której używasz do konfigurowania hybrydowego wdrożenia równoważenia obciążenia. Upewnij się, że zakresy CIDR podsieci sieci VPC nie kolidują z zakresami CIDR zdalnymi. Gdy adresy IP się pokrywają, trasy podsieci mają wyższy priorytet niż połączenia zdalne.

Instrukcje znajdziesz w tych artykułach:

Niestandardowe rozgłaszanie tras

Podane poniżej podsieci wymagają niestandardowego rozgłaszania z routera Cloud Router do sieci lokalnej, aby zapewnić aktualizację reguł zapory sieciowej na urządzeniu lokalnym.

Podsieć

Opis

172.16.0.0/23

Podmiana adresu sieci podrzędnej używana do komunikacji bezpośrednio z usługą lokalną

130.211.0.0/22, 35.191.0.0/16

Google Cloud Health Check

2. Zanim zaczniesz

Aktualizowanie projektu w celu obsługi ćwiczeń z programowania

Ten samouczek Codelab wykorzystuje zmienne $variables, aby ułatwić implementację konfiguracji gcloud w Cloud Shell.

W Cloud Shell wykonaj te czynności:

gcloud config list project
gcloud config
set project [YOUR-PROJECT-NAME]
psclab
=YOUR-PROJECT-NAME
echo $psclab

3. Konfiguracja Producer

Utwórz środowisko VPC producenta

W Cloud Shell wykonaj te czynności:

gcloud compute networks create producer-vpc --project=$psclab --subnet-mode=custom

Tworzenie podsieci producenta

W Cloud Shell wykonaj te czynności:

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

Zarezerwuj adres IP dla wewnętrznego systemu równoważenia obciążenia

W Cloud Shell wykonaj te czynności: usługa SHARED_VIP nie jest obsługiwana w przypadku usługi Private Service Connect, użyj zamiast niej GCE_ENDPOINT.

gcloud compute addresses create lb-ip \
   
--region=us-central1 \
   
--subnet=subnet-202 \
   
--purpose=GCE_ENDPOINT

Aby wyświetlić przypisany adres IP, użyj polecenia compute addresses describe.

gcloud compute addresses describe lb-ip  --region=us-central1 | grep address:

Tworzenie podsieci regionalnych serwerów proxy

Przydział proxy odbywa się na poziomie VPC, a nie systemu równoważenia obciążenia. W każdym regionie sieci wirtualnej (VPC), w którym używasz systemów równoważenia obciążenia opartych na Envoy, musisz utworzyć podsieć tylko-proxy . Jeśli wdrożesz wiele systemów równoważenia obciążenia w tym samym regionie i tej samej sieci VPC, będą one udostępniać tę samą podsieć tylko-proxy do równoważenia obciążenia.

  1. Klient nawiązuje połączenie z adresem IP i portem reguły przekierowania systemu równoważenia obciążenia.
  2. Każde proxy nasłuchuje na adresie IP i porcie określonym przez regułę przekierowania odpowiedniego systemu równoważenia obciążenia. Jeden z serwerów proxy odbiera i kończy połączenie sieciowe klienta.
  3. Serwer proxy nawiązuje połączenie z odpowiednią maszyną wirtualną backendu lub punktem końcowym w NEG, zgodnie z mapą URL systemu równoważenia obciążenia i usługami backendu.

Musisz utworzyć podsieci tylko-proxy niezależnie od tego, czy sieć jest w trybie automatycznym, czy niestandardowym. Podsieć tylko dla proxy musi zawierać co najmniej 64 adresy IP. Odpowiada to długości prefiksu /26 lub krótszej. Zalecany rozmiar podsieci to /23 (512 adresów tylko-proxy).

W Cloud Shell wykonaj te czynności:

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

Tworzenie podsieci NAT usługi Private Service Connect

Utwórz co najmniej jedną dedykowaną podsieć, która będzie używana z Private Service Connect. Jeśli konsoli Google Cloud używasz do publikowania usługi, możesz utworzyć podsieci podczas tej procedury. Utwórz podsieć w tym samym regionie co system równoważenia obciążenia usługi. Nie można przekonwertować zwykłej podsieci na podsieć Private Service Connect.

W Cloud Shell wykonaj te czynności:

gcloud compute networks subnets create psc-nat-subnet --network=producer-vpc --region=us-central1 --range=100.100.10.0/24 --purpose=private-service-connect

Tworzenie reguł zapory sieciowej dla producenta

Skonfiguruj reguły zapory, aby zezwolić na ruch między punktami końcowymi Private Service Connect a usługą dołączoną. W ramach tego ćwiczenia utworzysz regułę zapory sieciowej Ingress, która zezwala podłączeniu usługi Private Service Connect (wewnętrzny system równoważenia obciążenia) do podsieci NAT 100.100.10.0/24.

W Cloud Shell wykonaj te czynności:

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

W Cloud Shell utwórz regułę fw-allow-health-check, aby umożliwić kontrolom stanu Google Cloud dostęp do usługi lokalnej (usługi backendowej) na porcie 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

Utwórz regułę zezwalania na ruch przychodzący w przypadku pod siecią tylko dla proxy, aby umożliwić systemowi równoważenia obciążenia komunikację z instancjami backendowymi na porcie 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

Konfigurowanie grupy punktów końcowych sieci z hybrydową łącznością

Podczas tworzenia NEG użyj ZONE,która minimalizuje odległość geograficzną między Google Cloud a Twoim środowiskiem lokalnym lub innym środowiskiem Cloud. Jeśli na przykład hostujesz usługę w środowisku lokalnym we Frankfurcie w Niemczech, podczas tworzenia NEG możesz określić strefę Google Cloud europe-west3-a.

Jeśli korzystasz z usługi Cloud Interconnect, strefa ZONE użyta do utworzenia NEG powinna znajdować się w tym samym regionie, w którym skonfigurowano połączenie z Cloud Interconnect.

Dostępne regiony i strefy znajdziesz w dokumentacji Compute Engine: Dostępne regiony i strefy.

W Cloud Shell utwórz NEG hybrydowej łączności za pomocą polecenia 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

W Cloud Shell dodaj punkt końcowy IP:Port w lokalizacji do hybrydowej grupy punktów końcowych sieci.

gcloud compute network-endpoint-groups update on-prem-service-neg \
   
--zone=us-central1-a \
   
--add-endpoint="ip=192.168.1.5,port=80"

Konfigurowanie systemu równoważenia obciążenia

W tych krokach skonfigurujesz system równoważenia obciążenia (regułę przekierowania) i powiążesz go z grupą punktów końcowych sieci

W Cloud Shell utwórz regionalną kontrolę stanu przekazywaną usłudze lokalnej.

gcloud compute health-checks create http http-health-check \
   
--region=us-central1 \
   
--use-serving-port

W Cloud Shell utwórz usługę backendu dla backendu lokalnego korzystającego z hybrydowej grupy punktów końcowych sieci.

 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

W Cloud Shell dodaj do usługi backendu hybrydowy backend NEG. W polu RATE wpisz maksymalną STAWKĘ, którą backend powinien obsługiwać.

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

W Cloud Shell utwórz mapę URL, aby kierować przychodzące żądania do usługi backendu.

gcloud compute url-maps create on-prem-svc-url-map \
   
--default-service on-premise-service-backend \
   
--region=us-central1

Tworzenie docelowego serwera proxy 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

Utwórz regułę przekierowania, aby kierować przychodzące żądania do serwera proxy. Nie używaj podsieci tylko-proxy do tworzenia reguły przekierowania.

 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. Weryfikowanie systemu równoważenia obciążenia

W konsoli Cloud Console otwórz kolejno Usługi sieciowe → Równoważenie obciążenia → Systemy równoważenia obciążenia. Uwaga: 1 NEG to „zielony” stan, który oznacza, że usługa lokalna przeszła pomyślnie kontrolę stanu.

bb5d117dee3b8b04.png

Wybranie opcji ‘on-premise-svc-url-map' (mapa adresów URL usług lokalnych) powoduje wyświetlenie adresu IP interfejsu i identyfikację usługi backendowej.

128a7e85e8069097.png

5. Wyświetlanie zapamiętanych tras z urządzenia lokalnego

Kliknij Sieć VPC → Trasy. Uwaga: zapamiętany podzbiór usługi lokalnej 192.168.1.0/27

d1ab51b79aeea9d8.png

6. Sprawdzanie połączenia z usługą lokalną

W usłudze VPC producenta utworzymy maszynę wirtualną, aby przetestować połączenie z usługą lokalną. Kolejną konfiguracją jest dołączenie usługi.

W Cloud Shell utwórz instancję testową w VPC producenta

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

Aby umożliwić IAP połączenie z instancjami maszyn wirtualnych, utwórz regułę zapory sieciowej, która:

  • dotyczy wszystkich instancji maszyn wirtualnych, które mają być dostępne przez IAP;
  • Zezwala na ruch przychodzący z zakresu adresów IP 35.235.240.0/20. Ten zakres zawiera wszystkie adresy IP, których IAP używa do przekierowywania TCP.

W Cloud Shell utwórz instancję testową w VPC producenta

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

Zaloguj się na serwer test-box-us-central1 za pomocą IAP w Cloud Shell, aby sprawdzić połączenie z usługą lokalną. W tym celu wykonaj operację curl na adresie IP równoważenia obciążenia. W przypadku przekroczenia limitu czasu spróbuj ponownie.

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

Uruchom curl, aby sprawdzić połączenie z usługą lokalną. Po zatwierdzeniu zamknij maszynę wirtualną, aby powrócić do Cloud Shell. Zastąp adres IP wewnętrznego systemu równoważenia obciążenia na podstawie danych wyjściowych z kroku 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. Tworzenie załącznika usługi Private Service Connect

W kolejnych krokach utworzymy załącznik usługi, który po sparowaniu z punktem końcowym konsumenta uzyska dostęp do usługi lokalnej bez konieczności korzystania z połączenia sieci VPC.

Tworzenie załącznika usługi

W Cloud Shell utwórz załącznik usługi

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

Opcjonalnie: jeśli używasz współdzielonego środowiska VPC, utwórz załącznik usługi w projekcie usługi.

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>

Weryfikowanie załącznika usługi TCP

gcloud compute service-attachments describe service-1 --region us-central1

Opcjonalnie: przejdź do sekcji Usługi sieciowe → Private Service Connect, aby wyświetlić nowo utworzone połączenie z usługą.

2f84578c9f2cc361.png

Wybranie Service-1 powoduje wyświetlenie dodatkowych informacji, w tym URI przyłącza usługi używanego przez konsumenta do ustanowienia połączenia z usługą prywatną. Zapisz ten adres URI, ponieważ będzie on używany w dalszym kroku.

41639cb160231275.png

Szczegóły załącznika usługi: projects/<nazwa projektu>/regions/us-central1/serviceAttachments/service-1

8. Konfiguracja przez konsumenta

Utwórz środowisko VPC konsumenta

W Cloud Shell wykonaj te czynności:

gcloud compute networks create consumer-vpc --project=$psclab --subnet-mode=custom

Tworzenie podsieci dla konsumentów

Utwórz podsieć GCE w Cloud Shell

gcloud compute networks subnets create subnet-101 --project=$psclab --range=10.100.1.0/24 --network=consumer-vpc --region=us-central1

W Cloud Shell utwórz podsieć punktu końcowego dla konsumenta

gcloud compute networks subnets create subnet-102 --project=$psclab --range=10.100.2.0/24 --network=consumer-vpc --region=us-central1

Tworzenie punktu końcowego dla konsumenta (reguła przekierowania)

W Cloud Shell utwórz statyczny adres IP, który będzie używany jako punkt końcowy dla klienta.

gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=subnet-102 --addresses 10.100.2.10

Użyj wygenerowanego wcześniej identyfikatora URI załącznika usługi, aby utworzyć punkt końcowy dla konsumenta.

W Cloud Shell utwórz punkt końcowy dla konsumenta

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. Weryfikowanie usługi Private Service Connect dla konsumentów – VPC konsumenta

W sieci VPC konsumenta sprawdź, czy połączenie z usługą prywatną zostało nawiązane prawidłowo. Aby to zrobić, otwórz kolejno Usługi sieciowe → Private Service Connect → Połączone punkty końcowe. Zwróć uwagę na ustanowione połączenie psc-consumer-1 i odpowiadający mu adres IP utworzony wcześniej.

b91ee5d5c854e60b.png

Po wybraniu psc-consumer-1 podawane są szczegóły, w tym identyfikator URI załącznika usługi

1dbc63217819dcd5.png

10. Weryfikowanie konsumenta usługi Private Service Connect – VPC producenta

W sieci VPC producenta sprawdź, czy połączenie z usługą prywatną zostało ustanowione. Aby to zrobić, otwórz kolejno Usługi sieciowe → Private Service Connect → Opublikowana usługa. Zauważ, że opublikowane połączenie service-1 wskazuje teraz 1 regułę przekierowania (punkt końcowy połączenia).

951090b812a8d119.png

11. Tworzenie prywatnej strefy DNS i rekordu A

Utwórz strefę DNS prywatnej zmapowaną na punkt końcowy połączenia PSC, aby umożliwić płynny dostęp do producenta z dowolnego hosta w VPC.

Z 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. Sprawdzanie dostępu konsumenta do usługi Producent za pomocą maszyny wirtualnej

W sieci VPC konsumenta utworzymy maszynę wirtualną, aby przetestować połączenie z usługą lokalną, uzyskując dostęp do punktu końcowego konsumenta service1.codelabs.net.

W Cloud Shell utwórz instancję testową w sieci VPC klienta

gcloud compute instances create consumer-vm \
   
--zone=us-central1-a \
   
--image-family=debian-10 \
   
--image-project=debian-cloud \
   
--subnet=subnet-101 \
   
--no-address

Aby umożliwić IAP połączenie z instancjami maszyn wirtualnych, utwórz regułę zapory sieciowej, która:

  • dotyczy wszystkich instancji maszyn wirtualnych, które mają być dostępne przez IAP;
  • Zezwala na ruch przychodzący z zakresu adresów IP 35.235.240.0/20. Ten zakres zawiera wszystkie adresy IP, których IAP używa do przekierowywania TCP.

W Cloud Shell utwórz instancję testową w sieci VPC klienta

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

Zaloguj się na maszynie consumer-vm za pomocą IAP w Cloud Shell, aby sprawdzić połączenie z usługą lokalną. W tym celu wykonaj polecenie curl na serwerze FQDN DNS service1.codelab.net. W przypadku przekroczenia limitu czasu spróbuj ponownie.

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

Uruchom curl, aby sprawdzić połączenie z usługą lokalną. Po zatwierdzeniu wyjścia z maszyny wirtualnej nastąpi powrót do promptu Cloud Shell.

Wykonaj w Cloud Shell polecenie 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!!

Poniżej znajduje się przykładowy zrzut z usługi lokalnej. Zwróć uwagę, że adres IP źródłowy 172.16.0.13 pochodzi z zakresu podsieci proxy 172.16.0.0/23

30802152f51ff751.png

13. Producent – sprzątanie

Usuwanie komponentów producenta

W Cloud Shell usuń testowe instancje w VPC producenta

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. Czyszczenie danych

Usuwanie komponentów Consumer

W Cloud Shell usuń testowe instancje w sieci VPC konsumenta.

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. Gratulacje

Gratulacje! Udało Ci się skonfigurować i zweryfikować usługę Private Service Connect z wewnętrznym systemem równoważenia obciążenia HTTP(S).

Utworzono infrastrukturę producenta i dodano do VPC producenta załącznik usługi wskazujący na usługę lokalną. Dowiedz się, jak utworzyć punkt końcowy dla konsumenta w sieci VPC konsumenta, który umożliwia połączenie z usługą lokalną.

Co dalej?

Zapoznaj się z tymi ćwiczeniami z programowania

Więcej informacji i filmy

Dokumenty referencyjne