1. Wprowadzenie
Usługa Private Service Connect z automatyczną konfiguracją DNS korzysta z katalogu usług i Cloud DNS do automatycznego tworzenia rekordów DNS, które są programowane za pomocą adresów IP punktów końcowych usługi Private Service Connect konsumenta.
Co utworzysz
W tym laboratorium kodu utworzysz kompleksową architekturę Private Service Connect, która ilustruje użycie automatycznego DNS, jak pokazano na rysunku 1.
Automatyczny DNS jest możliwy dzięki:
- Załącznik usługi producenta tworzy automatyczny DNS, podając własną domenę publiczną z flagą „– domain-names” podczas tworzenia załącznika usługi Private Service Connect.
- Konsument definiuje nazwę punktu końcowego.
- Automatyczny DNS tworzy strefę DNS goog-psc-default-us-central1 i nazwa DNS cosmopup.net, a także wpis w katalogu usług zawierający nazwę punktu końcowego konsumenta.
Zalety automatycznego DNS ilustruje punkt (4), w którym użytkownik końcowy może komunikować się z punktem końcowym dla konsumenta za pomocą DNS, FQDN stargazer.cosmopup.net.
Rysunek 1.
Czego się nauczysz
- Jak utworzyć wewnętrzny system równoważenia obciążenia HTTP(S)
- Jak utworzyć załącznik usługi z automatycznym DNS
- Jak utworzyć usługę producenta Private Service Connect
- Jak uzyskać dostęp do punktu końcowego użytkownika za pomocą automatycznego DNS
Czego potrzebujesz
- Projekt Google Cloud
- Domena publiczna, której jesteś właścicielem
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]
projectname=YOUR-PROJECT-NAME
echo $projectname
3. Konfiguracja Producer
Utwórz sieć VPC producenta
W Cloud Shell wykonaj te czynności:
gcloud compute networks create producer-vpc --project=$projectname --subnet-mode=custom
Tworzenie podsieci producenta
W Cloud Shell wykonaj te czynności:
gcloud compute networks subnets create gce-subnet --project=$projectname --range=172.16.20.0/28 --network=producer-vpc --region=us-central1
W Cloud Shell wykonaj te czynności:
gcloud compute networks subnets create load-balancer-subnet --project=$projectname --range=172.16.10.0/28 --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:
gcloud compute addresses create lb-ip \
--region=us-central1 \
--subnet=load-balancer-subnet \
--purpose=GCE_ENDPOINT
Wyświetlanie przydzielonego adresu IP
Aby wyświetlić przypisany adres IP, użyj polecenia compute addresses describe.
gcloud compute addresses describe lb-ip --region=us-central1 | grep address:
Tworzenie regionalnych podsieci serwerów proxy
Przydział serwera proxy odbywa się na poziomie sieci 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.
- Klient nawiązuje połączenie z adresem IP i portem reguły przekierowania systemu równoważenia obciążenia.
- 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.
- Serwer proxy nawiązuje połączenie z odpowiednią maszyną wirtualną backendu określoną przez mapę URL systemu równoważenia obciążenia i usługi backendu.
Musisz utworzyć podsieci tylko z proxy niezależnie od tego, czy sieć VPC 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 \
--project $projectname \
--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 sieciowej, aby zezwolić na ruch między podsiecią NAT usługi Private Service Connect a podsiecią tylko dla proxy ILB.
W Cloud Shell wykonaj te czynności:
gcloud compute --project=$projectname 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łę zapory sieciowej fw-allow-health-check, aby umożliwić kontrolom stanu Google Cloud dostęp do usługi producenta (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
Konfiguracja Cloud Router i NAT
W tym laboratorium kodowania Cloud NAT jest używany do instalacji pakietu oprogramowania, ponieważ instancja maszyny wirtualnej nie ma zewnętrznego adresu IP.
W Cloud Shell utwórz router chmury.
gcloud compute routers create cloud-router-for-nat --network producer-vpc --region us-central1
W Cloud Shell utwórz bramę NAT.
gcloud compute routers nats create cloud-nat-us-central1 --router=cloud-router-for-nat --auto-allocate-nat-external-ips --nat-all-subnet-ip-ranges --region us-central1
Konfiguracja grupy instancji
W następnej sekcji utworzysz instancję Compute Engine i niezarządzaną grupę instancji. W kolejnych krokach grupa instancji będzie używana jako usługa backendu systemu równoważenia obciążenia.
W Cloud Shell utwórz regionalną kontrolę stanu przekazywaną usłudze producenta.
gcloud compute instances create app-server-1 \
--project=$projectname \
--machine-type=e2-micro \
--image-family debian-10 \
--no-address \
--image-project debian-cloud \
--zone us-central1-a \
--subnet=gce-subnet \
--metadata startup-script="#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
sudo service apache2 restart
echo 'Welcome to App-Server-1 !!' | tee /var/www/html/index.html
EOF"
W Cloud Shell utwórz niezarządzaną grupę instancji.
gcloud compute instance-groups unmanaged create psc-instance-group --zone=us-central1-a
gcloud compute instance-groups unmanaged set-named-ports psc-instance-group --project=$projectname --zone=us-central1-a --named-ports=http:80
gcloud compute instance-groups unmanaged add-instances psc-instance-group --zone=us-central1-a --instances=app-server-1
Konfigurowanie systemu równoważenia obciążenia
W kolejnych krokach skonfigurujesz wewnętrzny system równoważenia obciążenia HTTP , który zostanie opublikowany jako załącznik usługi w późniejszym kroku.
W Cloud Shell utwórz regionalną kontrolę stanu.
gcloud compute health-checks create http http-health-check \
--region=us-central1 \
--use-serving-port
W Cloud Shell utwórz usługę backendu.
gcloud compute backend-services create l7-ilb-backend-service \
--load-balancing-scheme=INTERNAL_MANAGED \
--protocol=HTTP \
--health-checks=http-health-check \
--health-checks-region=us-central1 \
--region=us-central1
W Cloud Shell dodaj backendy do usługi backendu.
gcloud compute backend-services add-backend l7-ilb-backend-service \
--balancing-mode=UTILIZATION \
--instance-group=psc-instance-group \
--instance-group-zone=us-central1-a \
--region=us-central1
W Cloud Shell utwórz mapę URL, aby kierować przychodzące żądania do usługi backendu.
gcloud compute url-maps create l7-ilb-map \
--default-service l7-ilb-backend-service \
--region=us-central1
Utwórz docelowy serwer proxy HTTP.
gcloud compute target-http-proxies create l7-ilb-proxy\
--url-map=l7-ilb-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 l7-ilb-forwarding-rule \
--load-balancing-scheme=INTERNAL_MANAGED \
--network=producer-vpc \
--subnet=load-balancer-subnet \
--address=lb-ip \
--ports=80 \
--region=us-central1 \
--target-http-proxy=l7-ilb-proxy \
--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. Zapisz kontrolę stanu zakończoną pomyślnie w usłudze backendu
Wybranie opcji ‘l7-ilb-map' spowoduje wyświetlenie adresu IP interfejsu, który powinien być zgodny z adresem IP wyodrębnionym w poprzednim kroku, oraz identyfikuje usługę backendową.
5. Tworzenie załącznika usługi Private Service Connect
Tworzenie załącznika usługi
W Cloud Shell utwórz załącznik usługi. Pamiętaj, aby dodać kropkę na końcu nazwy domeny.
gcloud compute service-attachments create published-service --region=us-central1 --producer-forwarding-rule=l7-ilb-forwarding-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=psc-nat-subnet --domain-names=cosmopup.net.
Opcjonalnie: jeśli używasz współdzielonego środowiska VPC, utwórz załącznik usługi w projekcie usługi.
gcloud compute service-attachments create published-service --region=us-central1 --producer-forwarding-rule=l7-ilb-forwarding-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=projects/<hostproject>/regions/us-central1/subnetworks/psc-nat-subnet --domain-names=cosmopup.net.
Aby wyświetlić nowo utworzone połączenie usługi, przejdź do sekcji Usługi sieciowe → Private Service Connect.
Wybranie opcji published-service powoduje wyświetlenie dodatkowych informacji, w tym URI przyłącza usługi używanego przez konsumenta do ustanowienia połączenia z usługą prywatną oraz nazwy domeny.
Szczegóły załącznika usługi:
projects/<project name>/regions/us-central1/serviceAttachments/published-service
6. Konfiguracja przez konsumenta
Włączanie interfejsów API dla konsumentów
W Cloud Shell wykonaj te czynności:
gcloud services enable dns.googleapis.com
gcloud services enable servicedirectory.googleapis.com
Tworzenie sieci VPC konsumenta
W Cloud Shell wykonaj te czynności:
gcloud compute networks create consumer-vpc --project=$projectname --subnet-mode=custom
Tworzenie podsieci dla użytkowników
W Cloud Shell utwórz podsieć dla testowej instancji.
gcloud compute networks subnets create db1-subnet --project=$projectname --range=10.20.0.0/28 --network=consumer-vpc --region=us-central1
W Cloud Shell utwórz podsieć dla punktu końcowego konsumenta.
gcloud compute networks subnets create consumer-ep-subnet --project=$projectname --range=10.10.0.0/28 --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 przez punkt końcowy klienta.
gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=consumer-ep-subnet --addresses 10.10.0.10
Do utworzenia punktu końcowego dla konsumenta używamy wcześniej wygenerowanego identyfikatora URI załącznika usługi.
W Cloud Shell utwórz punkt końcowy dla konsumenta.
gcloud compute forwarding-rules create stargazer --region=us-central1 --network=consumer-vpc --address=psc-consumer-ip-1 --target-service-attachment=projects/$projectname/regions/us-central1/serviceAttachments/published-service
7. Sprawdzanie połączenia w sieci VPC konsumenta
W sieci VPC konsumenta sprawdź, czy połączenie z usługą prywatną zostało nawiązane. Aby to zrobić, otwórz kolejno Usługi sieciowe → Private Service Connect → Połączone punkty końcowe. Zwróć uwagę na ustanowione połączenie z teleskopem i odpowiadający mu adres IP, który został utworzony wcześniej.
Po wybraniu psc-consumer-1 podawane są szczegóły, w tym identyfikator URI załącznika usługi.
8. Sprawdź połączenie w sieci VPC producenta.
W sieci VPC producenta 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 → Opublikowana usługa. Zauważ, że opublikowane połączenie usługi wskazuje teraz 1 regułę przekierowania (punkt końcowy połączenia).
9. Sprawdzanie poprawności automatycznej konfiguracji DNS
Sprawdźmy konfigurację DNS i katalogu usług.
Konfiguracja Cloud DNS
Kliknij Usługi sieciowe > Cloud DNS > Strefy. Strefa goog-psc-default-us-central & nazwa DNS cosmopup.net jest generowana automatycznie.
Wyświetlanie konfiguracji DNS i katalogu usług
Wybranie nazwy strefy pozwala nam zobaczyć, jak usługa Service Directory jest zintegrowana z Cloud DNS.
Konfiguracja katalogu usług
Kliknij Usługi sieciowe → Katalog usług.
Czy pamiętasz nazwę punktu końcowego dla konsumentów „stargazer”? Jest on programowany automatycznie w katalogu usług, co pozwala nam docierać do punktu końcowego konsumenta za pomocą nazwy FQDN stargazer.goog-psc-default–us-central1.
10. Sprawdzanie dostępu konsumenta do usługi producenta
W sieci VPC konsumenta utworzymy maszynę wirtualną, aby przetestować łączność opublikowanej usługi przez dostęp do punktu końcowego konsumenta stargazer.cosmopup.net.
W Cloud Shell utwórz testową instancję w sieci VPC dla klienta.
gcloud compute instances create db1 \
--zone=us-central1-a \
--image-family=debian-10 \
--image-project=debian-cloud \
--subnet=db1-subnet \
--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 regułę zapory sieciowej IAP.
gcloud compute firewall-rules create ssh-iap-consumer \
--network consumer-vpc \
--allow tcp:22 \
--source-ranges=35.235.240.0/20
Zaloguj się na maszynę wirtualną consumer-vm za pomocą IAP w Cloud Shell, aby sprawdzić łączność z usługą producenta, wykonując polecenie curl. W przypadku przekroczenia limitu czasu spróbuj ponownie.
gcloud compute ssh db1 --project=$projectname --zone=us-central1-a --tunnel-through-iap
Wykonaj curl, aby sprawdzić połączenie z usługą producenta. Po zatwierdzeniu wyjścia z maszyny wirtualnej nastąpi powrót do promptu Cloud Shell.
W Cloud Shell wykonaj polecenie curl w swojej domenie niestandardowej, np. stargazer.[custom-domain.com]. W wyniku poniżej wykonywane jest wywołanie curl do adresu stargazer.cosmopup.net.
user@db1:~$ curl -v stargazer.cosmopup.net
* Trying 10.10.0.10...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55d3aa8190f0)
* Connected to stargazer.cosmopup.net (10.10.0.10) port 80 (#0)
> GET / HTTP/1.1
> Host: stargazer.cosmopup.net
> User-Agent: curl/7.64.0
> Accept: */*
>
< HTTP/1.1 200 OK
< date: Thu, 22 Dec 2022 00:16:25 GMT
< server: Apache/2.4.38 (Debian)
< last-modified: Wed, 21 Dec 2022 20:26:32 GMT
< etag: "1b-5f05c5e43a083"
< accept-ranges: bytes
< content-length: 27
< content-type: text/html
< via: 1.1 google
<
Welcome to App-Server-1 !!
Zamknij maszynę wirtualną, aby powrócić do Cloud Shell i rozpocząć zadania czyszczenia.
11. Czyszczenie danych
W Cloud Shell usuń komponenty codelab.
gcloud compute forwarding-rules delete stargazer --region=us-central1 --quiet
gcloud compute instances delete db1 --zone=us-central1-a --quiet
gcloud compute addresses delete psc-consumer-ip-1 --region=us-central1 --quiet
gcloud compute networks subnets delete consumer-ep-subnet db1-subnet --region=us-central1 --quiet
gcloud compute firewall-rules delete ssh-iap-consumer --quiet
gcloud compute networks delete consumer-vpc --quiet
gcloud compute service-attachments delete published-service --region=us-central1 --quiet
gcloud compute forwarding-rules delete l7-ilb-forwarding-rule --region=us-central1 --quiet
gcloud compute target-http-proxies delete l7-ilb-proxy --region=us-central1 --quiet
gcloud compute url-maps delete l7-ilb-map --region=us-central1 --quiet
gcloud compute backend-services delete l7-ilb-backend-service --region=us-central1 --quiet
gcloud compute instance-groups unmanaged delete psc-instance-group --zone=us-central1-a --quiet
gcloud compute instances delete app-server-1 --zone=us-central1-a --quiet
gcloud compute firewall-rules delete allow-to-ingress-nat-subnet fw-allow-health-check fw-allow-proxy-only-subnet --quiet
gcloud compute addresses delete lb-ip --region=us-central1 --quiet
gcloud compute networks subnets delete gce-subnet load-balancer-subnet psc-nat-subnet proxy-subnet-us-central --region=us-central1 --quiet
gcloud compute routers delete cloud-router-for-nat --region=us-central1 --quiet
gcloud compute networks delete producer-vpc --quiet
12. Gratulacje
Gratulacje! Punkt końcowy Private Service Connect został skonfigurowany i zweryfikowany za pomocą automatycznej konfiguracji DNS.
Utworzono infrastrukturę producenta i dodano załącznik usługi z rejestracją domeny publicznej. Dowiedz się, jak utworzyć punkt końcowy konsumenta w sieci VPC konsumenta, który umożliwiał połączenie z usługą lokalną za pomocą automatycznie wygenerowanego DNS.
Cosmopup uważa, że ćwiczenia z programowania są niesamowite.
Co dalej?
Zapoznaj się z tymi ćwiczeniami z programowania
- Korzystanie z Private Service Connect do publikowania i używania usług w GKE
- Używanie Private Service Connect do publikowania i korzystania z usług
- Łączenie z usługami lokalnymi za pomocą Hybrid Networking przy użyciu Private Service Connect i wewnętrznego systemu równoważenia obciążenia serwera proxy TCP
Więcej informacji i filmy
- Omówienie Private Service Connect
- Co to jest Private Service Connect?
- Obsługiwane typy systemów równoważenia obciążenia