Google PCD: Compute, kontenery i platformy uruchomieniowe serverless — Przewodnik do nauki

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

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

Przegląd

Google Cloud oferuje wiele platform wykonawczych, obejmujących rozwiązania bezserwerowe, kontenery i maszyny wirtualne. Wybór odpowiedniej platformy zależy od charakterystyki obciążenia, takich jak wzorce żądań, zarządzanie stanem, dyscyplina w procesach budowania i wydawania, model operacyjny oraz ograniczenia sieciowe. Ta sekcja omawia zasady projektowania, tryby awarii i kompromisy dla Cloud Run, App Engine, Cloud Functions, Google Kubernetes Engine (GKE) i Compute Engine, wraz z usługami pomocniczymi do obsługi obrazów, tożsamości, sieci, konfiguracji i operacji.

Bezserwerowe środowiska uruchomieniowe: Cloud Run, App Engine, Cloud Functions

Cloud Run

Model: W pełni zarządzane kontenery z obsługą żądań HTTP lub skonteneryzowane zadania (Jobs), które działają aż do ukończenia.
Rewizje i ruch: Każde wdrożenie tworzy niezmienną rewizję. Podział ruchu procentowo między rewizjami umożliwia wdrożenia typu canary i blue-green z natychmiastowym wycofaniem zmian. Przykład:

  gcloud run services update-traffic my-svc --to-revisions rev-green=90,rev-blue=10

Współbieżność i skalowanie: Domyślna współbieżność to 80; ustaw na 1 dla kodu intensywnie wykorzystującego CPU lub niebędącego bezpiecznym wątkowo. Wyższa współbieżność zmniejsza efekt zimnego startu i koszty, ale może zwiększyć opóźnienia końcowe (tail latency), jeśli zasoby CPU/pamięci na żądanie są niewystarczające. Cloud Run skaluje się do zera i w górę w zależności od natężenia przychodzących żądań; kontroluj za pomocą minimalnej/maksymalnej liczby instancji, aby zredukować zimne starty i ograniczyć koszty.
Alokacja CPU: Wybierz opcję „CPU zawsze alokowane” dla pracy w tle między żądaniami, co wiąże się z dodatkowymi opłatami; w przeciwnym razie CPU jest alokowane tylko podczas obsługi żądań.
Zadania (Jobs): Cloud Run Jobs uruchamiają N równoległych zadań aż do ich ukończenia, z maksymalną liczbą ponowień na zadanie i ogólnymi limitami czasu; odpowiednie do przetwarzania ETL, wsadowego i typu fan-out. Tryby awarii obejmują „hot-spotting” backendów, gdy wiele zadań celuje w tę samą zależność; dodaj ograniczanie szybkości (rate limiting) i ponowienia z wycofywaniem wykładniczym (backoff).
Sieć: Publiczny, uwierzytelniany przez IAM lub prywatny za VPC za pośrednictwem Serverless VPC Access i Private Service Connect.

App Engine

Środowiska:
- Standard: Środowisko izolowane (sandbox), szybkie skalowanie, stałe środowiska uruchomieniowe dla poszczególnych języków; niskie opóźnienie zimnego startu z automatycznym skalowaniem; ograniczony system plików, limity czasu żądań i limity rozmiaru żądań przychodzących. Użyj podpisanych adresów URL Cloud Storage do przesyłania dużych plików.
- Flexible: Oparty na Dockerze, możliwości podobne do maszyn wirtualnych, niestandardowe środowiska uruchomieniowe, wolniejsze skalowanie w górę niż w Standard, obsługuje wątki w tle i zapis na dysk lokalny.
Usługi i wersje: Usługa (mikroserwis) może hostować wiele wersji; kieruj ruchem procentowo między wersjami, podobnie jak w Cloud Run. Użyj pliku dispatch.yaml do kierowania określonych ścieżek lub hostów do usług w celu prostego, scentralizowanego routingu bez zewnętrznego load balancera.
Skalowanie: Ręczne, podstawowe lub automatyczne w środowisku Standard; skalowanie oparte na liczbie maszyn wirtualnych w Flexible. Kompromis: agresywne autoskalowanie poprawia responsywność, ale może zwiększyć koszty i rywalizację o zasoby backendu.
Częste pułapki: Nieograniczone skalowanie instancji bez limitów (quotas) może przeciążyć systemy podrzędne; wymuszaj limity i stosuj mechanizmy circuit breaker.

Cloud Functions

Procedury obsługi sterowane zdarzeniami: Wyzwalane przez zdarzenia HTTP, Pub/Sub, Cloud Storage lub Eventarc. Użyj 2. generacji, aby wykorzystać model wykonawczy Cloud Run, kontrolę ruchu wychodzącego VPC i współbieżność; 1. generacja przetwarza jedno żądanie na raz.
Ponowienia i idempotentność: Funkcje działające w tle mogą być ponawiane w przypadku awarii; projektuj idempotentne procedury obsługi i używaj kluczy deduplikacyjnych, aby uniknąć podwójnego przetwarzania. Wyzwalacze HTTP nie są ponawiane przez platformę; zaimplementuj ponowienia po stronie klienta z wycofywaniem wykładniczym (exponential backoff).
Konfiguracja środowiska uruchomieniowego: Zmienne środowiskowe, integracja z Secret Manager oraz współbieżność/maksymalna liczba instancji na funkcję. Ustaw limity czasu, aby ograniczyć niekontrolowane koszty. Uważaj na długie zimne starty przy dużych zależnościach; utrzymuj pakiety w niewielkim rozmiarze.

Kontenery w Google Kubernetes Engine

Obciążenia

Deployments: Bezstanowe pody z aktualizacjami kroczącymi (rolling updates). Zapewnij bezpieczne wdrożenia za pomocą limitów surge/unavailable:

  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

StatefulSets: Uporządkowane, stabilne identyfikatory sieciowe i woluminy trwałe dla usług stanowych.
DaemonSets, Jobs, CronJobs: Agenci na poziomie węzła i obciążenia wsadowe.

Usługi (Services) i Ingress

Typy usług (Service):
- ClusterIP tylko do użytku wewnętrznego.
- NodePort dla prostego dostępu zewnętrznego (ograniczony operacyjnie).
- LoadBalancer dla regionalnego równoważenia obciążenia zewnętrznego/wewnętrznego.
Ingress: Routing HTTP(S) i terminacja TLS; preferuj Gateway API lub Ingress z zarządzanymi kontrolerami dla polityk warstwy 7. Tryb awarii: testy kondycji (health checks) kończą się niepowodzeniem z powodu zapory sieciowej; zezwól na dostęp z zakresów IP load balancera do węzłów backendu.

Autoskalowanie i pule węzłów (Node Pools)

Horizontal Pod Autoscaler (HPA): Skaluje pody na podstawie użycia CPU, pamięci lub metryk niestandardowych; połącz z Pod Disruption Budgets, aby chronić dostępność.
Vertical Pod Autoscaler (VPA): Dopasowuje żądania/limity zasobów podów; unikaj jednoczesnego używania HPA i VPA na tym samym wymiarze, aby zapobiec pętlom sprzężenia zwrotnego.
Cluster Autoscaler: Dodaje/usuwa węzły, aby zaspokoić oczekujące żądania zasobów przez pody.
Pule węzłów (Node pools): Oddzielaj pule według klasy obciążenia. Używaj taints/tolerations i etykiet do planowania (scheduling). Mieszaj instancje spot/preemptible dla obciążeń wrażliwych na koszty i tolerujących przerwy. Wybieraj typy maszyn z wystarczającą przepustowością pamięci/CPU, aby limity na pod nie powodowały dławienia (throttling).

Kondycja i wdrożenia

Sondy liveness, readiness i startup zapobiegają wysyłaniu ruchu do niegotowych podów i restartują zablokowane kontenery. Zbyt rygorystyczne sondy liveness mogą powodować kaskadowe restarty; dostosuj początkowe opóźnienia i progi niepowodzeń.
Wycofanie zmian za pomocą kubectl rollout undo. W przypadku wdrożeń canary użyj wielu zasobów Deployment i podziału ruchu na poziomie Service za pomocą Ingress/Gateway.

Compute Engine dla obciążeń aplikacyjnych

Projektowanie maszyn wirtualnych

Szablony instancji (instance templates) definiują typ maszyny, obraz, dyski, zakresy konta serwisowego, skrypty startowe i metadane. Obrazy powinny być jak najmniejsze; używaj skryptów startowych lub obrazów przygotowanych za pomocą Packer, aby zapewnić deterministyczne uruchamianie.
Dyski: Używaj zbalansowanych (balanced) lub stałych dysków SSD (SSD persistent disks) dla aplikacji wrażliwych na opóźnienia. Udostępniaj duże zbiory danych tylko do odczytu w ramach zarządzanej grupy instancji za pomocą stałego dysku tylko do odczytu (read-only persistent disk) podłączonego do wielu instancji, aby uzyskać niskie opóźnienia i szybkie uruchamianie.
Sieć: Twórz reguły zapory sieciowej (firewall) dla mechanizmów sprawdzania kondycji (health checkers) podczas korzystania z systemów równoważenia obciążenia (load balancers). Przykład:

  gcloud compute firewall-rules create allow-lb \
    --network my-net --allow tcp \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 --direction INGRESS

Zarządzane grupy instancji (MIGs)

Autoskalowanie na podstawie użycia procesora, liczby żądań na sekundę do load balancera, niestandardowych metryk lub harmonogramów. Ustaw okresy “cool-down” (oczekiwania), aby zapobiec gwałtownym, niestabilnym zmianom liczby instancji (thrashing).
Autonaprawianie (autohealing) za pomocą kontroli stanu (health checks) restartuje niestabilne maszyny wirtualne; upewnij się, że ścieżka kontroli stanu testuje gotowość aplikacji, a nie tylko osiągalność portu, aby uniknąć obsługiwania błędów 500.
Aktualizacje kroczące (rolling updates) i wdrożenia blue-green: Utwórz nowy szablon instancji i rozpocznij aktualizację typu “canary” na podzbiorze instancji. Jeśli liczba błędów wzrośnie, wycofaj zmiany (rollback) do poprzedniego szablonu. Kontrole dostępności (uptime checks) i alerty oparte na SLO pozwalają szybko wykrywać degradacje.

Logowanie i monitorowanie

Zainstaluj agentów, aby zbierać logi aplikacji bez zmian w kodzie; przesyłaj je do Cloud Logging i konfiguruj alerty za pomocą Cloud Monitoring. Używaj Debug Logpoints do diagnostyki na żywo przy minimalnym zakłóceniu działania.

Budowanie, tożsamość, sieć, sekrety i operacje

Artifact Registry i obrazy

Używaj Artifact Registry do przechowywania obrazów kontenerów i artefaktów językowych. Włącz skanowanie podatności i generowanie pochodzenia (provenance). Utrzymuj małe rozmiary obrazów:
- Używaj budowania wieloetapowego (multi-stage builds), aby oddzielić środowisko budowania od uruchomieniowego.
- Unikaj narzędzi deweloperskich w finalnym obrazie; przypinaj wersje systemu operacyjnego i pakietów. Przykład:

  FROM golang:1.22 AS build
  WORKDIR /src
  COPY . .
  RUN CGO_ENABLED=0 go build -o app

  FROM gcr.io/distroless/base-debian12
  COPY --from=build /src/app /app
  ENTRYPOINT ["/app"]

Promocja: Taguj obrazy w sposób niezmienny (np. app:1.3.7, app:prod-20240901) i promuj je poprzez ponowne tagowanie w Artifact Registry; unikaj zmiennego tagu latest w środowisku produkcyjnym. Warunkuj promocje wynikami testów integracyjnych i kanarkowych.

Tożsamość w czasie wykonania i zasada najmniejszych uprawnień

Przypisuj dedykowane konto serwisowe (service account) do każdego obciążenia roboczego z minimalnym wymaganym zestawem ról IAM. Unikaj szerokich ról, takich jak Editor. W GKE mapuj konta ServiceAccount z Kubernetes na konta serwisowe Google za pomocą Workload Identity. W przypadku usług serverless, jawnie ustawiaj konto serwisowe środowiska uruchomieniowego i usuwaj zakresy domyślnego tokena.

Konektory VPC i sieć usług

Konektory Serverless VPC Access kierują ruch wychodzący (egress) z Cloud Run, Cloud Functions i App Engine do sieci VPC. Wybierz tryb ruchu wychodzącego:
- Tylko zakresy prywatne (Private ranges only), aby docierać do usług w zakresach RFC1918 i połączonych z VPC, podczas gdy publiczny ruch wychodzący jest kierowany bezpośrednio.
- Cały ruch przez konektor (All traffic) oraz Cloud NAT, aby uzyskać deterministyczne adresy IP dla ruchu wychodzącego i stosować restrykcyjne polityki wychodzące.
Prywatne zależności: Preferuj prywatny adres IP (Private IP) dla Cloud SQL oraz Private Service Connect dla interfejsów API Google lub usług partnerskich. Upewnij się, że konektory są dopasowane regionalnie i zwymiarowane pod kątem przepustowości; monitoruj użycie CPU konektora, aby uniknąć dławienia (throttlingu).

Konfiguracja, sekrety i sprawdzanie stanu

Używaj zmiennych środowiskowych do konfiguracji niebędącej sekretem. Przechowuj sekrety w Secret Manager i montuj je lub wstrzykuj w czasie wykonania; regularnie rotuj klucze. W GKE używaj obiektów Secrets i sterownika CSI dla Secret Manager. W App Engine i Cloud Run nadawaj kontu serwisowemu dostęp do określonych sekretów.
Sprawdzanie stanu (Health checks):
- Cloud Run: restarty instancji po awarii; używaj sprawdzania na poziomie żądania i wskaźników SLI dla opóźnień.
- App Engine: wbudowane sprawdzanie stanu; dostosuj sondy liveness/readiness dla środowiska elastycznego (Flexible).
- GKE: skonfiguruj sondy liveness/readiness/startup.
- Compute Engine za systemami równoważenia obciążenia (LB): używaj sprawdzania stanu HTTP(S) z punktami końcowymi specyficznymi dla aplikacji.

Rozwiązywanie problemów, wycofywanie zmian i wzorce wdrażania

Wdrożenia niebiesko-zielone (blue-green) i kanarkowe (canary) z podziałem ruchu w Cloud Run i App Engine; w GKE używaj równoległych wdrożeń (Deployments) lub kontrolerów progresywnego dostarczania; w grupach MIG używaj kanarkowych podzbiorów instancji. Zawsze definiuj kryteria przerwania wdrożenia w oparciu o budżet błędów SLO i opóźnienia.
Typowe tryby awarii:
- Efekt pędzącego stada (Thundering herd) po skalowaniu do zera lub dużych wdrożeniach; ograniczaj ryzyko za pomocą minimalnej liczby instancji (min instances), mechanizmów rozgrzewania (warmups) i ograniczania szybkości (rate limiting).
- Przekroczone limity backendu lub limity połączeń; stosuj wykładniczy backoff (exponential backoff) i wyłączniki bezpieczeństwa (circuit breakers).
- Zimne starty (cold starts) spowodowane dużymi obrazami lub zależnościami; odchudzaj obrazy i preinicjalizuj klientów.

Praktyczny scenariusz problemu

Firma Acme Retail planuje migrację API do zmiany rozmiaru obrazów z samodzielnie zarządzanych maszyn wirtualnych na skalowalną, opłacalną platformę zapewniającą odpowiedzi o niskim opóźnieniu, prywatny dostęp do regionalnego bucketa Cloud Storage oraz bezpieczne wdrożenia kanarkowe.

Podejście

Spakuj usługę jako mały obraz kontenera i opublikuj w Artifact Registry.

Uzasadnienie: Odchudzona, wieloetapowa kompilacja Docker minimalizuje zimne starty i transfer sieciowy. Artifact Registry centralizuje skanowanie i przepływy pracy związane z promocją.

Wdróż API na Cloud Run z min instances równym 2, concurrency równym 40 i wyłączoną opcją CPU always allocated.

Uzasadnienie: Cloud Run zapewnia natychmiastowe skalowanie horyzontalne i zarządzany HTTPS. Niewielka pula minimalnych instancji zmniejsza opóźnienia związane z zimnym startem podczas dziennych szczytów obciążenia. Współbieżność na poziomie 40 równoważy koszt i opóźnienia ogonowe (tail latency) dla transformacji obrazów ograniczonych przez I/O. Wyłączenie stałej alokacji CPU pozwala uniknąć płacenia za bezczynne zasoby obliczeniowe między żądaniami.

Utwórz konektor Serverless VPC Access i ustaw egress na private ranges only; włącz Private Google Access w podsieci i w razie potrzeby skonfiguruj punkt końcowy VPC-SC lub Private Service Connect dla Cloud Storage.

Uzasadnienie: API musi pobierać i zapisywać obrazy prywatnie, bez publicznego ruchu wychodzącego. Tryb private ranges zapewnia, że tylko ruch do VPC przechodzi przez konektor, utrzymując publiczne wywołania jako bezpośrednie i wydajne. Private Google Access lub Private Service Connect zapewniają prywatny dostęp do interfejsów API Google z sieci VPC.

Nadaj dedykowanemu kontu serwisowemu środowiska uruchomieniowego dostęp zgodny z zasadą najmniejszych uprawnień do docelowego bucketa Cloud Storage i wymaganych sekretów.

Uzasadnienie: Zasada najmniejszych uprawnień ogranicza promień rażenia (blast radius). Tożsamość środowiska uruchomieniowego otrzymuje uprawnienia storage.objectViewer i storage.objectAdmin do konkretnego bucketa oraz uprawnienie accessor do potrzebnych sekretów w Secret Manager.

Przechowuj klucze API i konfigurację dla poszczególnych środowisk w Secret Manager i zmiennych środowiskowych; wstrzykuj sekrety w czasie wykonania.

Uzasadnienie: Scentralizowana rotacja sekretów i audytowalny dostęp. Konfiguracja niebędąca sekretem za pomocą zmiennych środowiskowych wspiera praktyki 12-factor.

Zaimplementuj wykładniczy backoff i idempotentne zapisy, aby obsługiwać błędy 429/5xx z Cloud Storage.

Uzasadnienie: Podczas nagłych skoków ruchu lub zdarzeń regionalnych mogą wystąpić błędy przejściowe. Backoff z losowym opóźnieniem (jitter) chroni zarówno API, jak i Cloud Storage przed burzami ponownych prób.

Skonfiguruj wersję kanarkową (canary revision) i skieruj na nią 10% ruchu; monitoruj wskaźnik błędów, opóźnienie P95 i nasycenie.

Uzasadnienie: Podział ruchu w Cloud Run umożliwia bezpieczne, progresywne wdrażanie. Monitory oparte na SLO zapewniają automatyczne wyzwalacze wycofania zmian, jeśli budżety błędów wyczerpują się zbyt szybko.

Dodaj punkt końcowy HTTP do sprawdzania stanu, który testuje zależności podrzędne; ustaw alerty na podstawie kontroli dostępności (uptime checks) w Cloud Monitoring i metryk opartych na logach.

Uzasadnienie: Kompleksowe sprawdzanie stanu (end-to-end) pozwala wcześnie wykrywać awarie zależności. Kontrole dostępności zapewniają zewnętrzną perspektywę; metryki oparte na logach wychwytują wzorce awarii specyficzne dla aplikacji.

Ustal limity autoskalowania i budżety; ustaw max instances, aby ograniczyć wydatki, i zdefiniuj obsługę błędu 429 w przypadku przeciążenia.

Uzasadnienie: Ograniczanie skali zapobiega niekontrolowanym kosztom i wyczerpaniu zasobów backendu. Łagodne zachowanie w przypadku przeciążenia utrzymuje stabilność usługi.

Udokumentuj proces wycofywania zmian: przenieś 100% ruchu z powrotem na poprzednią wersję Cloud Run za pomocą jednego polecenia.

Uzasadnienie: Niezmienne wersje sprawiają, że wycofywanie zmian jest bezpieczne i szybkie, minimalizując średni czas do przywrócenia sprawności (MTTR).

← Architektura aplikacji cloud-native oraz wybór usług · Wszystkie domeny · Projektowanie API →

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