1. Wprowadzenie
Wewnętrzny regionalny system równoważenia obciążenia TCP serwera proxy TCP z połączeniami hybrydowymi pozwala udostępnić klientom w Twojej sieci VPC usługę hostowaną w środowisku lokalnym lub w innym środowisku w chmurze.
Jeśli chcesz udostępnić usługę hybrydową w innych sieciach VPC, możesz opublikować usługę za pomocą usługi Private Service Connect. Dodając przyłącze usługi przed wewnętrznym regionalnym systemem równoważenia obciążenia serwera proxy TCP, możesz umożliwić klientom z innych sieci VPC dostęp do usług hybrydowych działających w środowisku lokalnym lub w innych środowiskach w chmurze.
Co utworzysz
W ramach tego ćwiczenia w Codelabs utworzysz wewnętrzny system równoważenia obciążenia serwera proxy TCP z połączeniem hybrydowym z usługą lokalną przy użyciu grupy punktów końcowych sieci. Ze środowiska VPC klienta będzie można komunikować się z usługą lokalną.
Czego się nauczysz
- Jak utworzyć wewnętrzny system równoważenia obciążenia serwera proxy TCP z usługą backendu hybrydowej grupy punktów końcowych sieci
- Jak utworzyć producenta (przyłącze usługi) i konsumenta (reguła przekierowania) w usłudze Private Service Connect
- Jak testować i weryfikować komunikację między konsumentem a producentem
Czego potrzebujesz
- Ustanowione sieci hybrydowe, np.sieć VPN o wysokiej dostępności, połączenie międzysieciowe, SW-WAN
- Projekt Google Cloud
Nawiązywanie połączeń hybrydowych
Twoje środowisko Google Cloud oraz środowisko lokalne lub inne w chmurze muszą być połączone przez połączenie hybrydowe z użyciem przyłączy VLAN Cloud Interconnect lub tuneli Cloud VPN z Cloud Router. Zalecamy korzystanie z połączenia o wysokiej dostępności.
Router Cloud Router z włączonym globalnym routingiem dynamicznym uczy się o konkretnym punkcie końcowym przez BGP i programuje go w Twojej sieci VPC Google Cloud. Regionalny routing dynamiczny nie jest obsługiwany. Trasy statyczne też nie są obsługiwane.
Sieć VPC Google Cloud, której używasz do konfigurowania Cloud Interconnect lub Cloud VPN, to ta sama sieć, której używasz do konfigurowania wdrożenia hybrydowego równoważenia obciążenia. Sprawdź, czy zakresy CIDR podsieci Twojej sieci VPC nie kolidują ze zdalnymi zakresami CIDR. Gdy adresy IP się nakładają, trasy podsieci mają wyższy priorytet niż połączenia zdalne.
Instrukcje znajdziesz tutaj:
Reklamy tras niestandardowych
Poniższe podsieci wymagają reklam niestandardowych z routera Cloud Router do sieci lokalnej, co zapewnia aktualizację lokalnych reguł zapory sieciowej.
Podsieć | Opis |
172.16.0.0/23 | Podsieć serwera proxy TCP używana do bezpośredniej komunikacji z usługą lokalną |
130.211.0.0/22, 35.191.0.0/16 |
2. Zanim zaczniesz
Zaktualizuj projekt, aby obsługiwał ćwiczenia z programowania
W tym ćwiczeniach z programowania korzystamy ze zmiennych $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 producenta
Tworzenie sieci VPC producenta
W Cloud Shell wykonaj te czynności
gcloud compute networks create producer-vpc --project=$psclab --subnet-mode=custom
Tworzenie podsieci Producer
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
Tworzenie podsieci serwera proxy TCP
Przydział serwera proxy jest na poziomie VPC, a nie systemu równoważenia obciążenia. Musisz utworzyć 1 podsieć tylko-proxy w każdym regionie sieci wirtualnej (VPC), w którym używasz systemów równoważenia obciążenia opartych na Envoy. Jeśli wdrażasz wiele systemów równoważenia obciążenia w tym samym regionie i tej samej sieci VPC, na potrzeby równoważenia obciążenia będą one współdzielić tę samą podsieć tylko-proxy.
- Klient nawiązuje połączenie z adresem IP i portem reguły przekierowania systemu równoważenia obciążenia.
- Każdy serwer proxy nasłuchuje pod adresem IP i portem określonych przez odpowiednią regułę przekierowania systemu równoważenia obciążenia. Jeden z serwerów proxy odbiera i kończy połączenie sieciowe klienta.
- Serwer proxy nawiązuje połączenie z odpowiednią maszyną wirtualną lub punktem końcowym backendu w grupie NEG zgodnie z mapą URL i usługami backendu systemu równoważenia obciążenia.
Musisz utworzyć podsieci tylko-proxy niezależnie od tego, czy Twoja sieć działa w trybie automatycznym czy niestandardowym. Podsieć tylko-proxy musi zawierać co najmniej 64 adresy IP. Odpowiada to długości prefiksu wynoszącej /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 1 dedykowaną podsieć do użycia z usługą Private Service Connect. Jeśli publikujesz usługę w konsoli Google Cloud, możesz podczas tej procedury utworzyć podsieci. Utwórz podsieć w tym samym regionie co system równoważenia obciążenia usługi. Nie możesz 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 usługi Producer
Skonfiguruj reguły zapory sieciowej, aby zezwolić na ruch między punktami końcowymi Private Service Connect a przyłączem usługi. W ramach ćwiczenia w Codelabs utworzyliśmy regułę zapory sieciowej ruchu przychodzącego pozwalającą podsieci NAT 100.100.10.0/24 na dostęp do przyłącza usługi Private Service Connect (wewnętrznego systemu równoważenia obciążenia).
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łę kontroli stanu fw-allow-health-health, aby umożliwić kontroli stanu Google Cloud dotarcie do usługi lokalnej (usługi backendu) 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łę zapory sieciowej dla ruchu przychodzącego pozwalającą usługom lokalnym na komunikację z podsiecią serwera proxy na porcie 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 połączeniami hybrydowymi
Podczas tworzenia grupy punktów końcowych sieci użyj takiej,która minimalizuje odległość geograficzną między Google Cloud a Twoim środowiskiem lokalnym lub innym środowiskiem chmurowym. Jeśli na przykład hostujesz usługę w środowisku lokalnym we Frankfurcie w Niemczech, podczas tworzenia grupy punktów końcowych sieci możesz określić strefę europe-west3-a Google Cloud.
Poza tym jeśli korzystasz z Cloud Interconnect, STREFA użyta do utworzenia grupy punktów końcowych sieci powinna znajdować się w tym samym regionie, w którym skonfigurowano przyłącze Cloud Interconnect.
Informacje o dostępnych regionach i strefach znajdziesz w dokumentacji Compute Engine: dostępne regiony i strefy.
Utwórz w Cloud Shell grupę punktów końcowych sieci w połączeniach hybrydowych 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 lokalny punkt końcowy IP:port 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 kolejnych krokach skonfigurujesz system równoważenia obciążenia (regułę przekierowania) i powiąż z grupą punktów końcowych sieci
Utwórz w Cloud Shell regionalną kontrolę stanu przekazaną do usługi lokalnej
gcloud compute health-checks create tcp on-prem-service-hc \
--region=us-central1 \
--use-serving-port
Utwórz w Cloud Shell usługę backendu dla backendu lokalnego.
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
W Cloud Shell dodaj backend hybrydowej grupy punktów końcowych sieci do usługi backendu. Dla MAX_CONNECTIONS wpisz maksymalną liczbę równoczesnych połączeń, które powinien obsłużyć backend.
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
Tworzenie docelowego serwera proxy w Cloud Shell
gcloud compute target-tcp-proxies create on-premise-svc-tcpproxy \
--backend-service=on-premise-service-backend \
--region=us-central1
Tworzenie reguły przekierowania (ILB) w Cloud Shell
Utwórz regułę przekierowania za pomocą polecenia gcloud computeforward-rules create.
Zastąp FWD_RULE_PORT pojedynczym numerem portu od 1 do 65535. Reguła przekierowania przekazuje tylko pakiety z pasującym portem docelowym.
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
Uzyskiwanie adresu IP wewnętrznego systemu równoważenia obciążenia
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. Weryfikowanie systemu równoważenia obciążenia
W konsoli Cloud otwórz Usługi sieciowe → Równoważenie obciążenia → Systemy równoważenia obciążenia. Uwaga: 1 grupa punktów końcowych sieci jest „zielona”, co wskazuje na pomyślną kontrolę stanu usługi lokalnej
Wybranie opcji ‘on-premise-service-backend' powoduje wyświetlenie adresu IP interfejsu użytkownika.
5. Wyświetl zapamiętane trasy z lokalizacji
Wybierz Sieć VPC → Trasy. Uwaga: zapamiętana podsieć usługi lokalnej 192.168.1.0/27
6. Weryfikowanie połączenia z usługą lokalną
W środowisku VPC Producers utworzymy maszynę wirtualną, aby przetestować połączenie z usługą lokalną, gdy następnym razem przyłącze usługi będzie skonfigurowane.
Tworzenie instancji testowej w środowisku vpc producenta w Cloud Shell
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 nawiązywanie połączeń z maszynami wirtualnymi, utwórz regułę zapory sieciowej, która:
- Dotyczy wszystkich instancji maszyn wirtualnych, które mają być dostępne za pomocą IAP.
- Zezwala na ruch przychodzący z zakresu adresów IP 35.235.240.0/20. Ten zakres zawiera wszystkie adresy IP używane przez IAP do przekierowywania TCP.
Tworzenie instancji testowej w środowisku vpc producenta w Cloud Shell
gcloud compute firewall-rules create ssh-iap \
--network producer-vpc \
--allow tcp:22 \
--source-ranges=35.235.240.0/20
Zaloguj się w polu test-box-us-central1 za pomocą IAP w Cloud Shell, aby zweryfikować połączenie z usługą lokalną przez „curl” względem adresu IP systemu 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
Wykonaj curl, aby sprawdzić połączenie z usługą lokalną. Po sprawdzeniu wyjścia maszyny wirtualnej nastąpi powrót do promptu Cloud Shell. Zastąp adres IP wewnętrznego systemu równoważenia obciążenia na podstawie danych wyjściowych zidentyfikowanych w krokach 3 i 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. Utwórz przyłącze usługi Private Service Connect
W kolejnych krokach utworzymy przyłącze usługi po sparowaniu z punktem końcowym klienta i dostępem do usługi lokalnej bez konieczności łączenia się z siecią równorzędną VPC.
Utwórz przyłącze usługi
Tworzenie załącznika usługi w 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
Opcjonalnie: jeśli korzystasz ze współdzielonego środowiska VPC, utwórz przyłącze usługi w projekcie usługi
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>
Zweryfikuj przyłącze usługi TCP
gcloud compute service-attachments describe service-1 --region us-central1
8. Opcjonalnie: wybierz Usługi sieciowe → Private Service Connect, aby wyświetlić nowo utworzony przyłącze usługi
Wybranie opcji Service-1 udostępnia więcej szczegółów, w tym identyfikator URI przyłącza usługi używany przez konsumenta do nawiązania prywatnego połączenia usługi. Zanotuj identyfikator URI, ponieważ będzie on potrzebny w następnym kroku.
Szczegóły przyłącza usługi: projects/<nazwa projektu>/regions/us-central1/serviceAttachments/service-1
9. Konfiguracja dla klientów indywidualnych
Tworzenie sieci VPC dla klientów indywidualnych
W Cloud Shell wykonaj te czynności
gcloud compute networks create consumer-vpc --project=$psclab --subnet-mode=custom
Tworzenie podsieci klienta
Tworzenie podsieci GCE w obrębie Cloud Shell
gcloud compute networks subnets create subnet-101 --project=$psclab --range=10.100.1.0/24 --network=consumer-vpc --region=us-central1
Tworzenie podsieci punktu końcowego klienta w obrębie Cloud Shell
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 klienta (reguła przekierowania)
Utwórz w Cloud Shell statyczny adres IP, który będzie używany jako punkt końcowy klienta
gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=subnet-102 --addresses 10.100.2.10
Użyjmy wcześniej wygenerowanego identyfikatora URI przyłącza usługi, aby utworzyć punkt końcowy klienta
Tworzenie punktu końcowego klienta w 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. Weryfikacja usługi Consumer Private Service Connect – sieć VPC klienta
W środowisku VPC klienta sprawdź udane połączenie prywatne, przechodząc do Network Services → Private Service Connect → połączone punkty końcowe. Zwróć uwagę na utworzone połączenie psc-consumer-1 i odpowiadający mu adres IP, który wcześniej utworzyliśmy.
W przypadku wybrania opcji dodania psc-consumer-1 podawane są szczegóły, w tym identyfikator URI przyłącza usługi
11. Weryfikacja usługi Consumer Private Service Connect – środowisko VPC producenta
W sieci VPC producenta sprawdź, czy prywatne połączenie usługi zostało poprawnie zakończone, przechodząc do Network Services → Private Service Connect → opublikowana usługa. Uwaga: opublikowane połączenie service-1 wskazuje teraz 1 regułę przekierowania (punkt końcowy połączenia).
12. Utwórz prywatną strefę DNS Rekord A
Utwórz prywatną strefę DNS zmapowaną na punkt końcowy połączenia PSC, co umożliwia bezproblemowy 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"
13. Sprawdzanie dostępu konsumenta do usługi Producers za pomocą maszyny wirtualnej
W środowisku VPC konsumentów utworzymy maszynę wirtualną, aby przetestować połączenie z usługą lokalną przez dostęp do punktu końcowego service1.codelabs.net
Tworzenie instancji testowej w vpc konsumenta w 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
Aby umożliwić IAP nawiązywanie połączeń z maszynami wirtualnymi, utwórz regułę zapory sieciowej, która:
- Dotyczy wszystkich instancji maszyn wirtualnych, które mają być dostępne za pomocą IAP.
- Zezwala na ruch przychodzący z zakresu adresów IP 35.235.240.0/20. Ten zakres zawiera wszystkie adresy IP używane przez IAP do przekierowywania TCP.
Tworzenie instancji testowej w vpc konsumenta w Cloud Shell
gcloud compute firewall-rules create ssh-iap-consumer \
--network consumer-vpc \
--allow tcp:22 \
--source-ranges=35.235.240.0/20
Zaloguj się w maszynie wirtualnej konsumenta za pomocą IAP w Cloud Shell, aby zweryfikować połączenie z usługą lokalną, wykonując „curl” w przypadku instancji DNS w ramach usługi FQDN 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
Wykonaj curl, aby sprawdzić połączenie z usługą lokalną. Po sprawdzeniu wyjścia z maszyny wirtualnej powrót do promptu Cloud Shell
Zwijanie w 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!!
Poniżej znajdziesz przykładowy przechwycony adres z usługi lokalnej. Źródłowy adres IP 172.16.0.2 pochodzi z zakresu podsieci 172.16.0.0/23 serwera proxy TCP.
14. Czyszczenie Producer
Usuwanie komponentów narzędzia Producer
Usuwanie komponentów producenta w 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. Czyszczenie dla konsumentów
Usuwanie komponentów konsumenta
Usuwanie komponentów konsumenta w 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. Gratulacje
Gratulujemy! Udało Ci się skonfigurować i zweryfikować usługę Private Service Connect z serwerem proxy TCP.
Udało Ci się utworzyć infrastrukturę producenta i dodać przyłącze usługi w produkcyjnej sieci VPC wskazujące usługę lokalną. Wiesz już, jak utworzyć punkt końcowy konsumenta w środowisku VPC klienta, który umożliwi połączenie z usługą lokalną.
Co dalej?
Zapoznaj się z tymi ćwiczeniami z programowania...
- Korzystanie z usług prywatnych przy użyciu GKE
- Używanie usługi Private Service Connect do publikowania i używania usług