Google PCNE: GKE, kontenery i sieci aplikacyjne — 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

Google Kubernetes Engine (GKE) jest ściśle zintegrowany z sieciami Google Cloud. Projektowanie pod kątem niezawodności i bezpieczeństwa wymaga zrozumienia adresacji IP w trybie VPC-native, prywatnych płaszczyzn sterowania, ruchu wychodzącego (egress), ruchu północ-południe i wschód-zachód, egzekwowania polityk oraz konstrukcji wieloklastrowych. Ta sekcja zawiera wskazówki projektowe, uzasadnienie operacyjne i typowe scenariusze awarii dla sieci kontenerów i aplikacji w Google Cloud.

Architektura IP w GKE i klastry prywatne

Klastry VPC-native

• Używają aliasów IP z dwoma dodatkowymi zakresami w podsieci VPC: jednym dla Podów (PodCIDR) i jednym dla serwisów (ServiceCIDR). Pozwala to uniknąć SNAT opartego na iptables na węzłach, umożliwia natywne dla kontenerów równoważenie obciążenia za pomocą NEG i skaluje się lepiej niż klastry oparte na trasach.
• Wskazówki dotyczące doboru rozmiaru:
  • Pody: przydziel PodsPerNode × MaxNodes, plus zapas (20–30%). Na przykład, obecne 10 węzłów × 20 Podów + wzrost do 100 × 200 sugeruje zakres /17 dla Podów; serwisy często mieszczą się w zakresie /21 dla ponad 2 tys. serwisów.
  • Serwisy: każdy ClusterIP zużywa jeden adres IP; uwzględnij zapas na migracje z serwisów typu headless do ClusterIP oraz na dodatki (add-ons).
• Scenariusze awarii:
  • Wyczerpanie adresów IP dla Podów: Pody pozostają w stanie Pending lub pojawiają się błędy CNI/IPAM; przeskaluj dodatkowy zakres IP dla Podów lub zmniejsz maksymalną liczbę podów na węzeł, a następnie utwórz węzły na nowo.
  • Wyczerpanie adresów IP dla serwisów: nowe serwisy nie mogą przydzielić adresu ClusterIP; rozszerz dodatkowy zakres IP dla serwisów.
  • Nakładające się zakresy aliasów IP: tworzenie klastra kończy się niepowodzeniem lub występują czarne dziury w routingu; sprawdź, czy nie ma nakładania się z innymi podsieciami lub sieciami VPC połączonymi peeringiem.

Klastry prywatne, dostęp do płaszczyzny sterowania i ruch wychodzący z węzłów

• Klastry prywatne ograniczają punkt końcowy płaszczyzny sterowania do prywatnego adresu z puli RFC1918, osiągalnego tylko z Twojej sieci VPC poprzez peering producenta. Węzły nie wymagają zewnętrznych adresów IP.
• Dla operatorów, do wyboru:
  • Tylko prywatny punkt końcowy: płaszczyzna sterowania jest osiągalna z podsieci VPC i połączonych sieci. Użyj hosta bastionowego lub Cloud Shell z Private Service Connect, aby uzyskać do niej dostęp.
  • Publiczny punkt końcowy z Authorized Networks: udostępnij płaszczyznę sterowania na publicznym adresie IP, ograniczając dostęp do określonych źródłowych zakresów CIDR. Jest to wygodne, ale zwiększa ekspozycję; używaj tylko przy ścisłym określaniu zakresów CIDR i silnych kontrolach tożsamości administratorów.
• Ruch wychodzący z węzłów (egress):
  • Dla węzłów bez zewnętrznych adresów IP zapewnij ruch wychodzący do internetu za pomocą Cloud NAT. Umożliwia to aktualizacje systemu operacyjnego, pobieranie obrazów kontenerów z zewnętrznych rejestrów i dostęp do API partnerów, jednocześnie zachowując prywatność węzłów.
  • Aby uzyskać dostęp do Google APIs oraz Artifact/Container Registry bez zewnętrznych adresów IP, włącz Private Google Access (PGA) na podsieciach węzłów. PGA rozwiązuje nazwy i kieruje ruch do Google APIs/rejestrów do brzegu sieci Google bez publicznych źródłowych adresów IP. PGA jest preferowane do pobierania obrazów; połącz je z Cloud NAT, jeśli wymagany jest również ruch wychodzący do usług spoza Google.
  • Jeśli wysyłasz ruch 0.0.0.0/0 przez zaporę sieciową innej firmy, nadal włącz PGA i dodaj statyczne trasy dla zakresów VIP Google APIs do domyślnej bramy internetowej, aby ominąć zaporę dla usług Google.

Skalowanie i rozwiązywanie problemów z adresacją IP

• Monitoruj zużycie aliasów IP na poziomie dodatkowych zakresów podsieci. Jeśli presja na adresy IP wzrasta:
  • Zwiększ rozmiary dodatkowych zakresów (dodaj większe zakresy, w razie potrzeby utwórz klaster na nowo lub zmigruj obciążenia).
  • Dostosuj max-pods-per-node, aby zrównoważyć zużycie IP na węzeł z fragmentacją harmonogramowania.
  • Usuwaj porzucone serwisy; serwisy typu headless nie alokują adresów ClusterIP, ale konwersja do typu ClusterIP spowoduje zużycie adresów IP.
• Planuj rozwój wieloregionalny, używając nienakładających się dodatkowych zakresów, aby uniknąć konieczności zmiany adresacji IP podczas korzystania z Shared VPC, VPC Peering lub usług wieloklastrowych.

Ingress, Gateway API, Services i polityki

Services i load balancery

• Typy Service:
  • ClusterIP: dostęp tylko wewnątrz klastra; ruch wschód-zachód (east-west) wykorzystuje kube-proxy lub dataplane v2.
  • NodePort: alokuje port na każdym węźle; używany przez wiele LB jako backend, ale należy unikać bezpośredniego wystawiania go w internecie.
  • LoadBalancer: provisionuje chmurowy load balancer. Zewnętrzne lub wewnętrzne load balancery L4 obsługują TCP/UDP; koligacja sesji (session affinity) typu ClientIP zapewnia lepkość (stickiness) sesji dla wielu protokołów, gdy jest to wymagane.
• Natywny dla kontenerów load balancing wykorzystuje Network Endpoint Groups (NEGs), dzięki czemu load balancer kieruje ruch bezpośrednio na adresy IP:porty Podów, co poprawia sygnalizację stanu (health signaling) i redukuje przeskoki między węzłami (node hops). W GKE używaj GKE Pod NEGs (GCE_POD). Inne typy NEG to VM_IP_PORT, Internet FQDN i PSC.
• GKE Ingress i Gateway API:
  • Ingress jest stabilnym rozwiązaniem dla ruchu północ-południe (north-south) HTTP(S) z globalnym zewnętrznym HTTP(S) load balancerem Google lub regionalnym wewnętrznym HTTP(S) load balancerem. Kontroler automatycznie programuje health checki i reguły firewalla dla standardowych wzorców.
  • Gateway API dostarcza bardziej ekspresyjny model z obiektami Gateway oraz HTTPRoute/TCPRoute. Obsługuje konfiguracje wielodostępowe (multi-tenant), zaawansowany routing i spójną specyfikację w różnych środowiskach. Wybierz Gateway API z myślą o przyszłości (future-proofing); używaj Ingress, gdy liczy się prostota i kompatybilność.

Ograniczenia dla klientów i health checki

• Ograniczanie klientów do określonych zakresów źródłowych (source ranges) można zrealizować na warstwie L4 za pomocą reguł firewalla VPC skierowanych na instancje backendu lub na warstwie L7 za pomocą polityk Cloud Armor w load balancerach HTTP(S).
• Zawsze zezwalaj na ruch z zakresów źródłowych health checkerów Google do docelowych backendów lub Podów, aby health checki przechodziły pomyślnie. W niektórych wdrożeniach GKE automatycznie tworzy reguły k8s-fw; jeśli dodajesz restrykcyjne reguły, zachowaj jawne zezwolenia dla zakresów health checkerów.
• Przykładowe podejście dla backendów L4: oznacz węzły tagiem „application” i utwórz regułę firewalla zezwalającą na ruch tcp:NodePort z dozwolonych CIDR-ów klientów oraz zakresów health checków Google, a także regułę blokującą (deny) o wyższym priorytecie dla wszystkich innych źródeł z włączonym logowaniem, aby obserwować odrzucone pakiety.

Polityki sieciowe (Network policies) i dataplane v2

• Włącz Kubernetes NetworkPolicy i użyj GKE Dataplane V2 do egzekwowania polityk w oparciu o eBPF, co poprawia wydajność i wierność w porównaniu do mechanizmów opartych na iptables.
• Podstawowa konfiguracja (baseline posture):
  • Domyślnie blokuj ruch wychodzący (egress) i przychodzący (ingress) dla przestrzeni nazw (namespaces); jawnie zezwalaj na przepływy między Podami (Pod-to-Pod) i z Poda do Service (Pod-to-Service).
  • Użyj selektorów namespace i podSelectors, aby tworzyć warstwy usług (frontend, backend, data) i zezwalaj tylko na minimalny niezbędny ruch, określając kierunki i porty.
• Zabezpieczanie komunikacji między serwisami:
  • Dla modelu zero trust wewnątrz klastra, mTLS najlepiej jest realizować za pomocą service mesh; NetworkPolicy obsługuje warstwy L3/L4 i nie może uwierzytelniać tożsamości.
  • Dla ruchu północ-południe (north-south), dołącz Cloud Armor do load balancerów HTTP(S), aby uzyskać WAF, ograniczanie liczby zapytań (rate limiting) oraz tryb podglądu (preview mode) do testowania reguł blokujących (deny) na podejrzanych atakujących bez zakłócania pracy użytkowników.

Tryby awarii i kompromisy

• Zbyt wiele lub zbyt ogólne polityki NetworkPolicy mogą powodować nieoczekiwane odrzucanie ruchu; weryfikuj je za pomocą wdrożeń etapowych (staged rollouts), logowania i narzędzi do analizy polityk.
• Poleganie na NodePort w połączeniu z zewnętrznymi regułami firewalla jest kruche; preferuj zarządzane load balancery i Pod NEGs.
• Gateway API wprowadza bogatsze funkcje, ale wymaga dojrzałości kontrolera i znajomości tematu w zespole; weryfikuj funkcje takie jak routing oparty na nagłówkach czy mTLS passthrough dla każdego kanału wydawniczego (release channel).

Wiele klastrów, siatka usług i tożsamość

Usługi wieloklastrowe i networking floty

• Zarejestruj klastry we flocie, aby używać Multi-Cluster Services (MCS) do odnajdywania usług i równoważenia obciążenia między klastrami. Eksportuj usługi z każdego klastra; klienci rozwiązują pojedynczą nazwę DNS, za którą stoją punkty końcowe w różnych klastrach.
• Wzorce ruchu międzyklastrowego:
  • Ta sama sieć VPC, różne podsieci: ruch przepływa przez prywatne adresy RFC1918 z optymalnym kosztem i opóźnieniem.
  • Różne sieci VPC: połącz za pomocą VPC Peering dla prywatnej, prostej łączności bez tranzytywności lub użyj Cloud VPN/Cloud Router, jeśli organizacje są różne lub wymagane jest szyfrowanie przez internet. W celu scentralizowanej administracji, Shared VPC udostępnia projektom usługowym tylko potrzebne podsieci.
• Tryby awarii:
  • Nakładające się zakresy CIDR blokują routing; upewnij się, że PodCIDR i ServiceCIDR nie nakładają się przed peeringiem lub połączeniem VPN.
  • Problemy z DNS typu split-horizon mogą zakłócić rozwiązywanie nazw między klastrami; zweryfikuj ścieżki wyszukiwania i domeny szczątkowe (stub domains).

Siatka usług, ruch wschód-zachód i obserwowalność

• Wdróż siatkę usług, taką jak Anthos Service Mesh, aby uzyskać:
  • mTLS z silną tożsamością obciążenia, politykę ruchu (ponowienia, limity czasu, wykrywanie anomalii) i podział ruchu (traffic splitting).
  • Spójną politykę wschód-zachód w klastrach dzięki federacji siatki lub topologiom multi-primary.
  • Bogata telemetria: złote sygnały (golden signals) dla każdego obciążenia, ślady zapytań (request traces) i audyty polityk.
• Kompromisy:
  • Kontenery sidecar zwiększają narzut zasobów; tryby ambient lub sidecarless mogą zmniejszyć koszty, ale należy zweryfikować zgodność funkcji.
  • Siatka dodaje zależności od płaszczyzny sterowania; projektuj pod kątem wysokiej dostępności (HA) płaszczyzn sterowania i łagodnej degradacji (graceful degradation).

Tożsamość obciążenia, sekrety i zasada najmniejszych uprawnień

• Użyj Workload Identity do mapowania kont usług Kubernetes (KSA) na konta usług Google (GSA), eliminując długoterminowe klucze. Dodaj adnotację do KSA z adresem e-mail GSA i nadaj minimalne role IAM dla GSA.
• Zarządzanie sekretami:
  • Preferuj Secret Manager ze sterownikiem CSI do montowania sekretów w czasie działania; usuń zwykłe sekrety Kubernetes dla wrażliwych danych lub zaszyfruj je w spoczynku (at rest) za pomocą CMEK, jeśli są zachowywane.
  • Nadawaj dostęp do sekretów i bucketów na poziomie GSA zgodnie z zasadą najmniejszych uprawnień. Unikaj ról na poziomie projektu; ograniczaj uprawnienia do ról na poziomie zasobów, takich jak storage.objectViewer, gdy jest to stosowne.

Odporność i aspekty projektowania bezpiecznej platformy

• Klastry regionalne dla wysokiej dostępności; rozmieść węzły w różnych strefach. Dla ruchu północ-południe (north-south) użyj globalnego równoważenia obciążenia HTTP(S), aby uzyskać najniższe opóźnienia dla użytkowników na całym świecie.
• Łączność z płaszczyzną sterowania: wybieraj prywatne płaszczyzny sterowania; unikaj publicznej ekspozycji, chyba że jest to absolutnie konieczne z użyciem Authorized Networks.
• Ruch wychodzący (Egress): węzły bez zewnętrznych adresów IP w połączeniu z Cloud NAT i PGA równoważą bezpieczeństwo i funkcjonalność.
• Obserwowalność: włącz logowanie zapory sieciowej, VPC Flow Logs i telemetrię siatki, aby szybko diagnozować odrzucenia przez polityki lub skoki opóźnień.

Praktyczny scenariusz problemowy

Firma Contoso Retail zarządza dwoma prywatnymi, regionalnymi klastrami GKE w regionach us-east1 i europe-west1. Wymagania: brak zewnętrznych adresów IP na węzłach, bezpieczny ruch przychodzący ograniczony do firmowych zakresów CIDR, globalna dostępność dla usługi sklepu internetowego, pobieranie obrazów bez ekspozycji na internet oraz przełączanie awaryjne (failover) między klastrami dla warstwy API. W przeszłości firma doświadczyła wyczerpania adresów IP podów podczas gwałtownego wzrostu ruchu.

Podejście

1. Zaprojektuj podsieci VPC-native z dużymi zakresami dodatkowymi (secondary ranges).

   • Uzasadnienie: Przydziel zakres /17 dla podów i /21 dla usług w każdym regionie, aby obsłużyć 100 węzłów × 200 podów/węzeł i 1500 usług z 20–30% zapasem. Zapobiega to ponownemu wyczerpaniu adresów IP podów i pozwala uniknąć zmiany adresacji IP w trakcie rozwoju.

2. Utwórz klastry prywatne z prywatnymi punktami końcowymi płaszczyzny sterowania.

   • Uzasadnienie: Ogranicza to ekspozycję płaszczyzny sterowania do sieci VPC. Operatorzy łączą się przez bastion w podsieci zarządzającej. Zmniejsza to powierzchnię ataku w porównaniu z publicznymi punktami końcowymi z Authorized Networks.

3. Włącz Cloud NAT i Private Google Access w podsieciach węzłów.

   • Uzasadnienie: Węzły nie mają zewnętrznych adresów IP, ale nadal muszą pobierać obrazy z Artifact Registry i mieć dostęp do repozytoriów systemów operacyjnych/pakietów. PGA zapewnia dostęp do API Google bez publicznych źródłowych adresów IP; Cloud NAT obsługuje ruch wychodzący do usług innych niż Google w razie potrzeby.

4. Zaimplementuj globalny ruch przychodzący (ingress) HTTP(S) za pomocą Gateway API z Pod NEGs.

   • Uzasadnienie: Pojedynczy globalny adres VIP anycast zmniejsza opóźnienia dla użytkowników na całym świecie. GKE Pod NEGs wysyłają kontrole stanu (health checks) bezpośrednio do podów i poprawiają wykrywanie awarii. Gateway API zapewnia czysty podział między infrastrukturą (Gateways) a trasami należącymi do aplikacji (Routes).

5. Ogranicz dostęp klientów i zezwól na kontrole stanu.

   • Uzasadnienie: Dołącz politykę Cloud Armor, aby zezwolić tylko na firmowe zakresy CIDR, z domyślnym odrzuceniem (deny) i trybem podglądu (preview mode) do bezpiecznego oceniania nowych blokad. Dodatkowo, upewnij się, że reguły zapory sieciowej VPC zezwalają na ruch ze źródłowych zakresów adresów kontroli stanu Google do backendowych NEG-ów, aby kontrole stanu pozostały zielone.

6. Zastosuj NetworkPolicy z GKE Dataplane V2.

   • Uzasadnienie: Domyślnie blokuj ruch przychodzący i wychodzący dla każdej przestrzeni nazw; zezwalaj tylko na ruch z frontendu do backendu i z backendu do bazy danych na określonych portach. Dataplane V2 efektywnie egzekwuje polityki za pomocą eBPF, zmniejszając promień rażenia (blast radius) w przypadku skompromitowania poda.

7. Włącz Multi-Cluster Services w całej flocie.

   • Uzasadnienie: Eksportuj usługę API w obu regionach i opublikuj jedną nazwę DNS. Klienci automatycznie przełączają się na sprawne punkty końcowe w innych klastrach. Ponieważ oba klastry znajdują się w tej samej sieci VPC z regionalnymi podsieciami, ruch między regionami pozostaje prywatny i generuje minimalny narzut.

8. Zastosuj siatkę usług dla bezpieczeństwa i obserwowalności ruchu wschód-zachód.

   • Uzasadnienie: Wymuszaj mTLS między usługami, dodaj budżety na ponowienia/limity czasu oraz uzyskaj metryki i ślady dla poszczególnych tras. Polityka na poziomie siatki uzupełnia NetworkPolicy: NetworkPolicy kontroluje osiągalność na warstwach L3/L4; siatka uwierzytelnia i autoryzuje tożsamości usług na warstwie L7.

9. Wzmocnij bezpieczeństwo tożsamości obciążeń i sekretów.

   • Uzasadnienie: Mapuj KSA na GSA o wąskim zakresie uprawnień za pomocą Workload Identity; nadawaj tylko niezbędne role, takie jak storage.objectViewer dla usług pobierających raporty. Dostarczaj poświadczenia przez Secret Manager CSI, aby uniknąć statycznych sekretów w manifestach.

10. Wprowadź mechanizmy zabezpieczające (guardrails) dotyczące pojemności i logowania.

    • Uzasadnienie: Ustaw max-pods-per-node w przemyślany sposób, aby zrównoważyć zużycie adresów IP. Monitoruj wykorzystanie dodatkowych zakresów (secondary ranges) i VPC Flow Logs. Utwórz jawną regułę zapory sieciowej o wysokim priorytecie deny-all z logowaniem dla tagu aplikacji, aby ujawnić niezamierzony ruch klientów, zachowując jednocześnie dozwolone ścieżki.

Taki projekt zapewnia domyślnie prywatne klastry z kontrolowanym dostępem północ-południe, odporne na awarie przełączanie między klastrami, pryncypialną tożsamość opartą na zasadzie najmniejszych uprawnień oraz płaszczyznę danych, która skaluje się bez powtarzającego się problemu wyczerpania adresów IP.

← Trasowanie · Wszystkie domeny · Obserwowalność sieci →

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

Przeglądaj Google →