Google PCNE: Architektura VPC, podsieci i planowanie adresacji — Przewodnik do nauki

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Część Google Professional Cloud Network Engineer — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Google, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Wirtualna chmura prywatna (VPC) to globalna, logicznie odizolowana sieć, która obejmuje wszystkie regiony Google Cloud. Podsieci to regionalne elementy w ramach VPC, które zawierają zakresy IP obsługujące Compute Engine, GKE i inne zasoby. Dobra architektura VPC równoważy wydajność adresacji, możliwości rozwoju i kontrolę operacyjną, zapewniając jednocześnie niskie opóźnienia i opłacalną łączność dla obciążeń wewnątrzprojektowych i międzyprojektowych oraz z interfejsami API Google.

Zakres VPC, architektura podsieci i tryby

• Globalna sieć VPC, regionalne podsieci

  • Pojedyncza sieć VPC obejmuje wszystkie regiony. Podsieci są tworzone w poszczególnych regionach i definiują główne zakresy CIDR IPv4 oraz opcjonalne zakresy dodatkowe. Instancje otrzymują adresy IP z podsieci regionalnych, ale domyślnie mogą komunikować się prywatnie między regionami w ramach tej samej sieci VPC.
  • Tryb routingu dynamicznego
    • Regionalny: Cloud Routers wymieniają trasy tylko z podsieciami w swoim regionie.
    • Globalny: Cloud Routers w jednym regionie rozgłaszają poznane trasy do wszystkich regionów. Preferuj tryb globalny, gdy wymagane są obciążenia wieloregionalne lub wyjście o wysokiej dostępności (HA).

• Tryb automatyczny a tryb niestandardowy

  • Tryb automatyczny tworzy jedną podsieć w każdym regionie z predefiniowanymi zakresami CIDR. Jest wygodny do szybkiego startu, ale nieelastyczny na dużą skalę. Można go przekonwertować na tryb niestandardowy; konwersja jest jednokierunkowa.
  • Tryb niestandardowy zapewnia pełną kontrolę nad tworzeniem podsieci i wyborem zakresów CIDR. Jest to zalecany wzorzec do planowania adresacji w środowiskach produkcyjnych, Shared VPC, peeringu i przyszłego rozwoju.
  • Uwaga dotycząca migracji: Po konwersji z trybu automatycznego na niestandardowy, artefakty lub szablony, które zakładały istnienie podsieci automatycznych, często przestają działać, dopóki nie zostaną jawnie zaktualizowane, aby odwoływały się do podsieci niestandardowych.

• Niezmienność i rozbudowa podsieci

  • Region podsieci jest niezmienny; nie można przenieść podsieci między regionami.
  • Główne zakresy IPv4 można rozszerzać w miejscu (poszerzając prefiks), nie można ich zmniejszać i muszą pozostać nienakładające się w całej sieci VPC i wszelkich połączonych sieciach.
  • Zakresy dodatkowe można dodawać lub usuwać (w zależności od ich użycia), ale również nie mogą się one nakładać.

Planowanie adresacji: zakresy główne/dodatkowe, aliasy IP, IPv6 i przestrzeń prywatna

• Główne i dodatkowe zakresy IPv4

  • Zakres główny: przypisuje adresy do interfejsów maszyn wirtualnych (domyślnie nic0). Tworzy generowaną przez system trasę podsieci i jest używany do większości komunikacji wewnętrznej.
  • Zakresy dodatkowe: kojarzą dodatkowe zakresy CIDR z podsiecią i są wymagane dla klastrów GKE działających w trybie VPC-native. Generowane przez system trasy dla zakresów dodatkowych umożliwiają komunikację wschód-zachód dla zasobów Pod i Service.

• Aliasy IP

  • Aliasy IP pozwalają, aby karta sieciowa (NIC) maszyny wirtualnej posiadała wiele adresów IP z głównego lub dodatkowych zakresów podsieci, co umożliwia stosowanie ścisłych polityk opartych na IP, przypisywanie adresów IP do zasobów Pod w GKE VPC-native oraz efektywne wykorzystanie adresów IP.
  • Dla GKE planuj duże, ciągłe dodatkowe zakresy CIDR, aby zminimalizować fragmentację i potrzebę zmiany rozmiaru w przyszłości. Przykład: dla 100 węzłów z 200 zasobami Pod na węzeł i 1500 zasobami Service, przydziel dodatkowy zakres dla Pod o rozmiarze co najmniej /17, a dla Service /21, aby pozostawić zapas.

• Projektowanie prywatnej przestrzeni adresowej RFC 1918 i zarządzanie IP

  • Wybierz nienakładające się bloki adresów we wszystkich obecnych i planowanych sieciach VPC, środowiskach on-premises i u partnerów. Zarezerwuj duże bloki nadrzędne dla każdego środowiska, a następnie wydzielaj z nich przewidywalne podbloki dla poszczególnych regionów i funkcji.
  • Zarezerwuj pojemność na przyszły rozwój, zakresy dodatkowe, bufory migracyjne (tymczasowy dual-stack/podwójny NAT) oraz punkty końcowe infrastruktury (ILB VIPs, punkty końcowe PSC).
  • Unikaj najpopularniejszych bloków adresów korporacyjnych, jeśli prawdopodobna jest łączność z partnerami; lub posegmentuj sieć za pomocą NAT, aby uniknąć konfliktów.

• Planowanie IPv6

  • Zewnętrzne IPv6: używaj globalnych zewnętrznych adresów IPv6 na globalnych load balancerach, aby zapewnić dostęp klientom i osiągalność anycast.
  • Wewnętrzne IPv6: tam, gdzie to możliwe, włącz podsieci dual-stack, aby przypisywać wewnętrzne adresy IPv6 do maszyn wirtualnych i odpowiednio dostosuj reguły zapory sieciowej. Zaplanuj rekordy DNS AAAA i zapewnij zgodność z politykami dla IPv4.
  • Zachowaj IPv4 do kontroli wewnątrz chmury i integracji z systemami firm trzecich; wprowadzaj IPv6 stopniowo poprzez load balancery i podsieci dual-stack.

Trasowanie: trasy implikowane, trasy niestandardowe, priorytety, tagi i następne skoki

• Trasy implikowane (generowane przez system)

  • Trasy podsieci: jedna na każdą podsieć podstawową i każdy zakres dodatkowy, miejsce docelowe równe CIDR, następnym skokiem jest sama podsieć.
  • Trasa domyślna: trasa 0.0.0.0/0 do domyślnej bramki internetowej jest tworzona domyślnie; ruch wychodzący (egress) do internetu wymaga zewnętrznego adresu IP lub NAT.

• Trasy niestandardowe i logika wyboru

  • Wygrywa dopasowanie najdłuższego prefiksu. Jeśli wiele tras ma tę samą długość prefiksu, wygrywa najniższy numer priorytetu (domyślny priorytet 1000).
  • Tagi i konta usługowe
    • Trasy bez tagów dotyczą wszystkich maszyn wirtualnych. Trasy ograniczone tagami dotyczą tylko instancji z pasującymi tagami sieciowymi.
    • Reguły zapory sieciowej oparte na tożsamości mogą dopasowywać konta usługowe; używaj ich do bardziej szczegółowej kontroli niż tagi, gdy jest to możliwe.

• Następne skoki

  • Obsługiwane następne skoki dla tras niestandardowych obejmują:
    • Domyślną bramkę internetową (dla 0.0.0.0/0 lub bardziej szczegółowych prefiksów ruchu wychodzącego)
    • Instancję (wymaga włączonego przekazywania IP (IP forwarding) do trasowania ruchu dla innych; używane dla urządzeń wirtualnych)
    • Tunel Cloud VPN (trasy statyczne)
    • Regionalny wewnętrzny load balancer jako następny skok (dla skalowalnych wzorców urządzeń)
  • Nie można ustawić jako następnego skoku połączenia VPC peering; peering obsługuje własną wymianę tras.

• Przykład kierowania ruchem (urządzenie wirtualne)

  • Utwórz trasę bardziej szczegółową niż trasa podsieci, z następnym skokiem do instancji z włączonym przekazywaniem IP, ograniczoną tagami na źródłowych maszynach wirtualnych.
  • Przykład:
    • gcloud compute routes create app-egress –network=prod-vpc –destination-range=0.0.0.0/0 –next-hop-instance=fw-appliance –next-hop-instance-zone=us-west1-a –priority=800 –tags=egress-via-fw

• Ruch wychodzący (egress) do Google APIs bez zewnętrznych adresów IP

  • Opcja 1: Włącz Private Google Access (PGA) na podsieciach, a następnie dodaj niestandardowe trasy dla wirtualnych adresów IP (VIP) Google API do domyślnej bramki internetowej, aby w razie potrzeby ominąć domyślną ścieżkę wyjściową innej firmy.
  • Opcja 2: Użyj Cloud NAT z PGA, aby zapewnić ruch wychodzący dla prywatnych maszyn wirtualnych do usług Google.
  • Opcja 3: Użyj Private Service Connect do Google APIs, aby korzystać z nich bez dostępu do internetu; ruch pozostaje w sieci Google i używa prywatnego punktu końcowego RFC1918 w Twojej sieci VPC.
  • Aby uzyskać ograniczony dostęp, skieruj klientów na ograniczone wirtualne adresy IP (VIP) Google API i egzekwuj kontrole ruchu wychodzącego.

Shared VPC, peering, delegowana administracja i konta usługowe

• Shared VPC

  • Projekt hosta (host project) jest właścicielem jednej lub więcej centralnie zarządzanych sieci VPC i podsieci. Projekty usługowe (service projects) dołączają obciążenia robocze do wybranych współdzielonych podsieci.
  • Delegowana administracja
    • Administrator Shared VPC (Shared VPC Admin) konfiguruje dołączanie projektów i udostępnianie podsieci.
    • Administratorzy sieci (Network Admins) zarządzają trasami, podsieciami i zaporą sieciową w projekcie hosta.
    • IAM na poziomie projektu w projektach usługowych kontroluje wdrażanie obciążeń roboczych; możesz udostępniać tylko wymagane podsieci, aby ograniczyć promień rażenia (blast radius) i widoczność tras.
  • Konta usługowe
    • Preferuj polityki zapory sieciowej oparte na kontach usługowych, aby uzyskać deterministyczną, opartą na tożsamości kontrolę między zespołami.
    • Używaj dedykowanych kont usługowych dla każdej warstwy i środowiska, z rolami o najniższych uprawnieniach (least-privilege) do dostępu do danych (na przykład nadaj rolę Storage Object Viewer kontu usługowemu, które odczytuje dane z Cloud Storage).

• VPC Network Peering

  • Ograniczenia
    • Nieprzechodniość: A↔B i B↔C nie oznacza A↔C. W razie potrzeby zbuduj pełną siatkę (full mesh).
    • Brak nakładających się zakresów IP w połączonych sieciach.
    • Wymiana jest ograniczona do tras podsieci (w tym zakresów dodatkowych); kierowanie za pomocą następnego skoku przez peering nie jest obsługiwane.
  • Używaj peeringu do zapewnienia prywatnej łączności wewnątrzorganizacyjnej o niskim opóźnieniu i minimalnym narzucie operacyjnym, gdy oddzielne sieci VPC muszą pozostać administracyjnie odrębne.

• Łączność hybrydowa

  • Scentralizuj Dedicated Interconnect i Cloud Router w projekcie hosta Shared VPC, aby współdzielić łączność o dużej przepustowości z projektami usługowymi poszczególnych działów.
  • Używaj załączników VLAN o wysokiej dostępności (HA), zróżnicowanych lokalizacji brzegowych, podwójnych Cloud Routers i globalnego routingu dynamicznego, aby zapewnić odporność i propagację tras do wszystkich potrzebnych regionów.

Operacje: rozszerzanie, wysoka dostępność (HA), dostęp prywatny, weryfikacja i rozwiązywanie problemów

• Ograniczenia dotyczące rozszerzania i migracji podsieci

  • Rozszerzaj podsieć w miejscu, gdy zbliża się do wyczerpania pojemności; sprawdź wszystkie połączone sieci pod kątem braku nakładania się zakresów i upewnij się, że zależne zakresy dodatkowe GKE pozostają wystarczające.
  • Jeśli zakresy nakładają się między organizacjami lub partnerami, zastosuj NAT lub etapową zmianę numeracji. Nie można połączyć peeringiem nakładających się sieci VPC ani zainstalować nakładających się tras dynamicznych.

• Rozmieszczenie regionalne i wysoka dostępność

  • Umieszczaj podsieci w regionach najbliższych użytkownikom i danym. Dla użytkowników po obu stronach Atlantyku, pojedyncza sieć VPC z regionalnymi podsieciami w us-east1 i europe-west1 zapewnia bezpośrednią łączność prywatną z optymalnym opóźnieniem i zerową opłatą za ruch wychodzący wewnątrz VPC.
  • Rozkładaj obciążenia robocze pomiędzy strefy; używaj regionalnych zarządzanych grup instancji oraz regionalnych wewnętrznych/zewnętrznych load balancerów w celu zapewnienia odporności na awarie stref.
  • W przypadku rozwiązań hybrydowych, wdrażaj podwójne Cloud Routers i połączenia (attachments) na region lub lokalizację brzegową; włącz BFD tam, gdzie jest obsługiwany; używaj globalnego routingu dynamicznego do obsługi przełączania awaryjnego (failover).

• Prywatny dostęp do Google (Private Google Access) i ograniczone punkty końcowe

  • Włącz PGA na podsieciach hostujących instancje bez zewnętrznych adresów IP.
  • Aby uniemożliwić ogólny ruch wychodzący do internetu, jednocześnie zezwalając na dostęp do Google APIs:
    • Kieruj domyślny ruch do swojego NGFW.
    • Dodaj bardziej szczegółowe trasy statyczne dla VIP-ów Google API do domyślnej bramy internetowej lub wdróż punkty końcowe PSC dla Google APIs.

  • Przykład:

undefined

• Weryfikacja topologii i rozwiązywanie problemów
  • Użyj Network Intelligence Center:
    • Connectivity Tests do walidacji osiągalności i symulacji decyzji dotyczących routingu, zapory sieciowej i bram.
    • Performance Dashboard i Topology do wizualizacji ścieżek i stanu kondycji.
  • Logi i telemetria:
    • VPC Flow Logs do obserwacji dozwolonego/odrzuconego ruchu (allow/deny) i opóźnień na interfejs.
    • Firewall Rules Logging do potwierdzania dopasowań reguł.
    • Logi i stan kondycji Cloud NAT do diagnozowania problemów z ruchem wychodzącym bez zewnętrznych adresów IP.
    • Logi load balancera i kontroli stanu (health-check) do weryfikacji gotowości backendów.

  • Sprawdzenia z CLI:

undefined

i

undefined

do potwierdzenia obowiązującej polityki. -

undefined

i

undefined

z testowych maszyn wirtualnych; użyj packet mirroring do głębokiej inspekcji w razie potrzeby.

Praktyczny scenariusz problemowy

Acme Retail Group potrzebuje wieloregionalnej sieci Google Cloud o niskim opóźnieniu, ze scentralizowaną kontrolą, dostępem do Google APIs dla prywatnych instancji bez użycia internetu oraz ścisłą izolacją między działami, które nie muszą się komunikować. Niektóre zespoły używają GKE z dużą gęstością Podów. Acme kieruje również ogólny ruch wychodzący przez zaporę sieciową innej firmy, ale chce, aby ruch do Google API omijał tę zaporę.

1. Zbuduj pojedynczą sieć Shared VPC w projekcie hosta w trybie niestandardowym (custom mode) z globalnym routingiem dynamicznym i utwórz regionalne podsieci w us-east1 i europe-west1 z zarezerwowanymi zakresami dodatkowymi dla GKE.

• Uzasadnienie: Jedna sieć VPC zapewnia prywatną, bezkosztową łączność międzyregionalną przy użyciu adresów RFC1918 dla optymalnej wydajności. Tryb niestandardowy i globalny routing dynamiczny wspierają precyzyjne planowanie adresacji IP i propagację tras w wielu regionach.

2. Udostępnij tylko określone podsieci potrzebne każdemu projektowi usługowemu działu; utwórz trzy projekty usługowe (Sprzedaż, Finanse, Marketing) i udostępnij każdemu z nich tylko wymagane podsieci.

• Uzasadnienie: Udostępnianie na poziomie podsieci ogranicza promień rażenia (blast radius) i ekspozycję tras, wymuszając izolację przy jednoczesnym umożliwieniu centralnych operacji. Delegowane uprawnienia IAM pozwalają centralnym administratorom sieci zarządzać zaporami sieciowymi i trasami, podczas gdy zespoły aplikacyjne wdrażają obciążenia niezależnie.

3. W przypadku działów, które muszą się komunikować, połącz ich dedykowane sieci VPC za pomocą peeringu lub umieść je w tych samych podsieciach Shared VPC; w przypadku działów izolowanych, powstrzymaj się od peeringu i nie udostępniaj nakładających się podsieci.

• Uzasadnienie: Peering zapewnia prywatną łączność o niskim opóźnieniu przy minimalnym narzucie operacyjnym. Brak przechodniości (non-transitivity) wymaga jawnych połączeń w siatce (mesh) tylko tam, gdzie jest to potrzebne, co domyślnie zachowuje izolację.

4. Włącz Private Google Access na wszystkich udostępnionych podsieciach i wdróż punkty końcowe Private Service Connect do Google APIs; zachowaj domyślną trasę do zapory sieciowej innej firmy, a dodatkowo dodaj bardziej szczegółowe trasy statyczne dla VIP-ów Google API do domyślnej bramy internetowej.

• Uzasadnienie: PGA i PSC zapewniają konsumpcję API z prywatnych maszyn wirtualnych bez użycia internetu. Bardziej szczegółowe trasy gwarantują, że ruch do API omija NGFW, podczas gdy ruch wychodzący do internetu (inny niż do Google) nadal przechodzi przez ścieżkę inspekcji.

5. Przydziel podstawowe i dodatkowe zakresy CIDR z zapasem na przyszły wzrost: dla GKE, określ rozmiar dodatkowego zakresu dla Podów (np. /17) i dodatkowego zakresu dla Usług (np. /21) na każdy obciążony region; użyj aliasów IP dla Podów i Usług i utwórz klastry VPC-native powiązane z tymi zakresami.

• Uzasadnienie: Zakresy dodatkowe i aliasy IP zapobiegają wyczerpaniu adresów IP węzłów i pozwalają na gęste rozmieszczanie zasobów (dense scheduling). Wymiarowanie z uwzględnieniem przyszłego zapotrzebowania pozwala uniknąć uciążliwych zmian rozmiaru i re-numeracji zakresów dodatkowych.

6. Zaimplementuj wysoką dostępność (HA) dla ruchu hybrydowego i urządzeń wirtualnych: wdróż podwójne Cloud Routers oraz HA VPN lub Interconnect w zależności od potrzeb; tam, gdzie wymagane jest kierowanie ruchu przez urządzenie wirtualne, użyj bardziej szczegółowej trasy niestandardowej z następnym skokiem (next hop) ustawionym na regionalny wewnętrzny load balancer lub instancję z włączonym IP forwarding i zakresem zastosowania ograniczonym przez tagi.

• Uzasadnienie: Wysoka dostępność na brzegu sieci (edge) zapewnia ciągłość działania podczas awarii. Ograniczanie zasięgu trasy za pomocą tagów zapobiega przypadkowemu zawracaniu ruchu (hairpinning) i pozwala tylko wybranym instancjom przechodzić przez ścieżkę urządzenia wirtualnego.

7. Weryfikuj i zarządzaj siecią za pomocą Connectivity Tests w Network Intelligence Center, VPC Flow Logs i Firewall Rules Logging; egzekwuj polityki zapory sieciowej oparte na tożsamości przy użyciu kont usług (service accounts) i utrzymuj dokumentację IPAM z zarezerwowanymi buforami na region i funkcję.

• Uzasadnienie: Proaktywna weryfikacja zapobiega przestojom podczas wprowadzania zmian. Polityki oparte na tożsamości są bardziej niezawodne niż podejścia oparte wyłącznie na tagach. Dyscyplina w zarządzaniu adresacją IP (IPAM) zapobiega nakładaniu się zakresów, które mogłoby zablokować peering lub pominąć nauczone trasy.

Wszystkie domeny · Polityki zapory sieciowej →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →

Przeglądaj Google →