Google ACE: Kontenery, hosting aplikacji i platformy bezserwerowe — Przewodnik do nauki

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Część Google Associate Cloud Engineer — 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 kontinuum platform do uruchamiania kontenerów i aplikacji, od w pełni zarządzanych rozwiązań serverless po konfigurowalne klastry Kubernetes. Wybór i obsługa odpowiedniej platformy wymaga zrozumienia płaszczyzn sterowania, modeli skalowania, mechanizmów wydań, sieci i bezpieczeństwa. Ta sekcja zawiera skonsolidowane wskazówki operacyjne dla Google Kubernetes Engine (GKE), Artifact Registry, Cloud Run, App Engine i Cloud Functions, a także wzorce dotyczące sekretów, bezpiecznych wdrożeń i diagnostyki.

Kubernetes Engine: Klastry, Workloady i Sieć

Klastry GKE zapewniają zarządzaną płaszczyznę sterowania Kubernetes z pulami węzłów, których rozmiar i zabezpieczenia konfigurujesz. Wybierz tryb Autopilot, aby zminimalizować obciążenie operacyjne i korzystać z predefiniowanych ustawień, lub Standard, aby uzyskać szczegółową kontrolę nad węzłami, siecią i dodatkami. Używaj kanałów wydań i automatycznej aktualizacji węzłów, aby zapewnić przewidywalne i bezpieczne aktualizacje; włącz automatyczną naprawę węzłów. Preferuj Container-Optimized OS dla wzmocnionych węzłów, chyba że określone pakiety wymagają Ubuntu.

Pule węzłów i harmonogramowanie
- Oddzielaj pule węzłów według klasy workloadu (np. ogólne, GPU, spot) i używaj taints/tolerations do kierowania Podów.
- Włącz cluster autoscaler i skonfiguruj min/max dla każdej puli. Pamiętaj, że PodDisruptionBudgets i żądania zasobów mogą blokować skalowanie w dół lub pozostawiać Pody w stanie oczekiwania, jeśli żądania przekraczają dostępne kształty węzłów.
- Węzły typu spot/preemptible obniżają koszty, ale wprowadzają ryzyko eksmisji; łącz je z budżetami surge dla Deployment i ograniczeniami topologii Podów w celu zapewnienia odporności.
Przestrzenie nazw i wielodostępność
- Używaj przestrzeni nazw do podziału przydziałów (quotas), polityk i RBAC. Stosuj NetworkPolicies, aby ograniczyć ruch wschód-zachód. Wymuszaj standardy Pod Security w zakresie przestrzeni nazw, aby unikać uprzywilejowanych workloadów.
Workloady
- Deploymenty zarządzają bezstanowymi Podami za pomocą aktualizacji kroczących, budżetów surge/unavailable i szybkich wycofań. Używaj sond gotowości (readiness probes) do kierowania ruchem oraz sond liveness/startup do autonaprawy. Błędnie skonfigurowane sondy gotowości mogą tworzyć czarną dziurę dla ruchu; przetestuj je przed wdrożeniem na produkcję.
- StatefulSety zapewniają stabilne tożsamości i uporządkowane skalowanie dla baz danych i systemów opartych na kworum. Użyj usługi typu headless i StorageClass obsługującej dynamiczne provisionowanie; zaplanuj lokalność strefową PV.
- DaemonSety harmonogramują jednego Poda na każdym węźle (np. agenty logowania/monitoringu). Respektują one autoskalowanie i zdarzenia opróżniania węzła (drain) i są idealne do telemetrii w skali całego węzła.
Usługi i Ingress
- ClusterIP udostępnia wewnątrzklastrowy DNS i równoważenie obciążenia. NodePort służy głównie do rozwiązywania problemów. LoadBalancer provisionuje zewnętrzny lub wewnętrzny load balancer TCP/UDP Google Cloud; używaj wewnętrznego dla usług prywatnych.
- GKE Ingress konfiguruje globalne równoważenie obciążenia HTTP(S) z zarządzanymi certyfikatami, mapami URL i Cloud Armor. W celu nowoczesnego zarządzania ruchem preferuj natywne dla kontenerów równoważenie obciążenia (NEG), aby uzyskać sprawdzanie stanu zdrowia na poziomie Poda i szybszą konwergencję. Upewnij się, że punkty końcowe gotowości (readiness) odzwierciedlają rzeczywisty stan aplikacji; w przeciwnym razie backend stanie się niedostępny (unhealthy), powodując błędy 502.
Autoskalowanie
- Horizontal Pod Autoscaler skaluje repliki na podstawie metryk, takich jak CPU lub metryki niestandardowe za pośrednictwem Cloud Monitoring; upewnij się, że Metrics Server jest w dobrym stanie. Vertical Pod Autoscaler może dopasować żądania zasobów; unikaj konfliktów z HPA, używając VPA w trybie „rekomendacji” dla workloadów zarządzanych przez HPA lub ostrożnie używaj trybu kompatybilnego HPA+VPA.
- Cluster autoscaler dodaje/usuwa węzły, aby dopasować je do Podów. Jeśli Pody żądają więcej zasobów, niż oferuje jakikolwiek kształt węzła, nigdy nie zostaną zaplanowane; dostosuj żądania/limity do kształtów puli węzłów.

Krótkie przykłady:

Wycofaj zepsute wydanie:

undefined

Szybko sprawdź inny kontekst:

undefined

Zarządzanie Artefaktami, Bezpieczeństwo Łańcucha Dostaw i Bezpieczne Wydania

Artifact Registry przechowuje obrazy kontenerów w podziale na regiony ze wsparciem dla VPC Service Controls. Stosuj oddzielne repozytoria (lub prefiksy) dla różnych środowisk i wymuszaj niezmienne tagi; wdrażaj po sumie kontrolnej (digest), aby wyeliminować niejednoznaczność. Zintegruj Cloud Build lub swoje CI, aby budować i wysyłać obrazy z metadanymi pochodzenia (provenance).

Zarządzanie podatnościami
- Włącz Artifact Analysis, aby skanować obrazy pod kątem CVE dla systemów operacyjnych i języków programowania. Przerywaj buildy lub blokuj promocję w przypadku wykrycia podatności o wysokiej wadze. Połącz to z Binary Authorization, aby wymagać podpisów/atestacji (np. zgodność z polityką podatności, pochodzenie SLSA) przed dopuszczeniem do GKE.
Promocja obrazów
- Promuj przez kopiowanie sumy kontrolnej (digest) obrazu z repozytorium deweloperskiego do repozytoriów stagingowych/produkcyjnych lub przez ponowne tagowanie w repozytorium promocyjnym; unikaj zmiennego tagu „latest”. Automatyzuj za pomocą wyzwalaczy Cloud Build warunkowanych wynikami testów i skanowania.
Secrety i konfiguracja
- Preferuj Secret Manager z dostępem z najniższymi uprawnieniami. W GKE używaj sterownika Secret Manager CSI z Workload Identity, aby węzły nigdy nie miały dostępu do długożyjących sekretów. W przypadku konfiguracji KRM oddzielaj ConfigMap (niepoufne) od Secret (poufne) i montuj w trybie tylko do odczytu.
- W przypadku rozwiązań serverless montuj secrety za pomocą bezpośrednich powiązań z Secret Manager; unikaj osadzania sekretów w zmiennych środowiskowych, chyba że jest to absolutnie konieczne.
Wzorce wycofywania i wydawania
- Kubernetes: używaj aktualizacji kroczących z maxUnavailable=0 dla wdrożeń bez przestoju i maxSurge dostosowanym do pojemności; realizuj wdrożenie kanarkowe (canary) z dwoma Deploymentami za jedną usługą (Service) lub użyj Service mesh do stopniowego przełączania ruchu w procentach. Chroń krytyczne workloady za pomocą PodDisruptionBudgets i minReadySeconds.
- Cloud Run i App Engine: używaj rewizji/wersji i podziału ruchu dla wdrożeń kanarkowych i blue/green. Utrzymuj poprzednie rewizje w stanie gotowości (warm), aby zmniejszyć opóźnienie przy wycofywaniu.
- Scenariusze awarii: rozjazd wersji spowodowany zmiennymi tagami, luki czasowe w skanowaniu i błędnie zdefiniowane sondy gotowości to częste przyczyny awarii. Używaj sum kontrolnych obrazów (digest), sprawdzeń przed wdrożeniem i syntetycznych sond stanu zdrowia.

Platformy aplikacji bezserwerowych

Cloud Run dostarcza natywne dla kontenerów, sterowane żądaniami zasoby obliczeniowe z automatycznym skalowaniem do zera i egzekwowaniem tożsamości dla każdego żądania.

Usługi i zadania Cloud Run
- Usługi obsługują HTTP; współbieżność (concurrency) kontroluje liczbę jednoczesnych żądań na instancję (dostosuj pod kątem opóźnień vs wydajności). Zadania (jobs) obsługują zadania wsadowe/cron inne niż HTTP i mogą być przetwarzane równolegle.
- Rewizje (revisions) to niezmienne migawki. Dzielenie ruchu (traffic splitting) umożliwia wdrożenia typu canary według procentów. Ustaw minimalną liczbę instancji (min instances), aby zredukować zimne starty (cold starts); użyj alokacji CPU w stanie bezczynności, jeśli wymagane jest przetwarzanie w tle.
- Tożsamość: przypisz dedykowane konto serwisowe (service account) do każdej usługi/rewizji z zasadą najmniejszych uprawnień. Ogranicz wywoływanie za pomocą IAM (rola Cloud Run Invoker) lub w razie potrzeby ustaw jako publiczne. Do uwierzytelniania użytkowników końcowych użyj podpisanych tokenów IAP lub wbudowanego uwierzytelniania Cloud Run z Identity Platform.
Sieć
- Użyj konektorów Serverless VPC, aby uzyskać dostęp do prywatnych zasobów VPC. Wybierz ruch wychodzący (egress): cały ruch przez konektor lub tylko prywatne zakresy RFC1918. Pamiętaj o limitach przepustowości konektora; skaluj rozmiar konektora i dopasuj jego region do regionu usługi. W przypadku wychodzącego ruchu internetowego z zasobów mających tylko prywatne IP, połącz z Cloud NAT.
- Private Service Connect umożliwia prywatne korzystanie z usług producenta lub udostępnianie wewnętrznych punktów końcowych. Do przyjmowania ruchu przez zewnętrzne HTTP(S) użyj Cloud Load Balancing z serwerlessowymi grupami NEG.

App Engine oferuje dwa środowiska:

Standard
- Działa w piaskownicy (sandbox), szybko się skaluje, obsługuje skalowanie automatyczne, podstawowe lub ręczne. Skalowanie automatyczne z min_idle_instances zapewnia wstępnie rozgrzane zasoby. Szybki zimny start i prosty model wdrożenia; ograniczone możliwości dostosowywania na poziomie systemu operacyjnego i stały zestaw środowisk uruchomieniowych.
Flexible
- Uruchamia Dockera na maszynach wirtualnych Compute Engine z większą kontrolą nad bibliotekami systemowymi i siecią. Wolniejszy cykl życia instancji i wyższy koszt bazowy; odpowiednie, gdy potrzebne są niestandardowe środowiska uruchomieniowe lub biblioteki natywne.
Usługi i wersje
- Dziel ruch według wersji (losowo, na podstawie ciasteczka lub IP). Każda usługa może skalować się niezależnie. Stosuj stopniowe wdrożenia (gradual rollouts) i zachowaj poprzednią wersję w celu natychmiastowego wycofania zmian (rollback).

Cloud Functions dostarcza jednofunkcyjne, sterowane zdarzeniami funkcje.

Wyzwalacze (triggers): Pub/Sub, Cloud Storage, HTTP, Eventarc dla wielu źródeł. Twórz idempotentne procedury obsługi (handlers); niektóre wyzwalacze ponawiają próbę w przypadku błędu, co prowadzi do zduplikowanego przetwarzania.
Konfiguracja środowiska uruchomieniowego: zmienne środowiskowe, powiązania z Secret Manager, maksymalna liczba instancji, pamięć/CPU. Kontroluj współbieżność dla funkcji HTTP, aby zrównoważyć opóźnienia i koszty.
Częste pułapki: nieograniczona współbieżność lub nieidempotentne efekty uboczne powodują duplikację danych; zapewnij kolejki DLQ dla Pub/Sub; ustaw odpowiednie limity czasu (timeouts).

Wybór platformy, sieć i odpowiedzialność operacyjna

Wybierz platformę w oparciu o wymagany poziom kontroli, charakterystykę skalowania, potrzeby w zakresie przenośności i budżet operacyjny.

Kontrola a narzut operacyjny
- Najwyższy poziom kontroli: GKE Standard (system operacyjny węzłów, sieć, dodatki bezpieczeństwa) z odpowiadającym mu narzutem operacyjnym.
- Zrównoważone podejście: GKE Autopilot (brak zarządzania węzłami, predefiniowane zasady bezpieczeństwa).
- Najniższy narzut operacyjny: Cloud Run, App Engine, Cloud Functions (brak węzłów, zarządzane skalowanie), ale z ograniczeniami wynikającymi z modelu środowiska uruchomieniowego i zapytań.
Skalowanie i dopasowanie do obciążenia
- Obciążenia z nagłymi skokami zapytań: Cloud Run/App Engine Standard sprawdzają się doskonale; Functions dla handlerów sterowanych zdarzeniami.
- Aplikacje stanowe lub niestandardowa sieć: GKE z StatefulSets i funkcjami CNI.
- Przenośność: kontenery na GKE/Cloud Run; Functions są mniej przenośne ze względu na model FaaS.
Sieć w architekturze serverless, ruch wychodzący i usługi prywatne
- Używaj konektorów VPC do dostępu prywatnego; monitoruj wykorzystanie konektora, aby uniknąć dławienia (throttlingu). Ustawiaj ruch wychodzący (egress) na „all” tylko wtedy, gdy jest to konieczne; w przeciwnym razie ogranicz go do zakresów prywatnych, aby zmniejszyć koszty i ryzyko.
- Dla prywatnego ruchu przychodzącego (ingress) rozważ wewnętrzny load balancing HTTP(S) z serwerlessowymi NEG lub Private Service Connect.
- W celu kontroli eksfiltracji danych, połącz z VPC Service Controls tam, gdzie jest to wspierane, i ogranicz trasy ruchu wychodzącego za pomocą zapory sieciowej i Cloud NAT.
Diagnostyka i odpowiedzialność operacyjna
- Standaryzuj logowanie w oparciu o Cloud Logging ze strukturalnymi logami (JSON) i identyfikatorami trace/span we wszystkich usługach w celu korelacji. Używaj dashboardów Cloud Monitoring, kontroli dostępności (uptime checks), SLO i polityk alertów.
- Dla GKE: włącz Cloud Ops for GKE, zbieraj metryki aplikacji za pomocą Prometheus lub Cloud Monitoring i używaj DaemonSets do telemetrii na poziomie węzła.
- Dla serverless: wykorzystaj wbudowane logi zapytań, Error Reporting, Trace i Profiler. Definiuj SLO i alerty dla każdej usługi na podstawie opóźnień, wskaźnika błędów i nasycenia (współbieżność, CPU instancji).
- Model odpowiedzialności: zdefiniuj, kto jest odpowiedzialny za parametry środowiska uruchomieniowego (skalowanie, współbieżność), IAM i potoki wdrożeniowe (release pipelines). Regularnie testuj procedury wycofywania zmian i scenariusze awaryjne.

Praktyczny scenariusz problemowy

Firma Acme Retail planuje udostępnić nowe API do obsługi płatności, jednocześnie modernizując wewnętrzne usługi. Wymagania: publiczne API o niskim opóźnieniu z wdrożeniami typu canary, prywatny dostęp do wewnętrznej bazy danych stanów magazynowych w VPC, egzekwowanie zasad łańcucha dostaw oraz przejrzysta procedura wycofywania zmian przy minimalnym narzucie operacyjnym.

Wybierz Cloud Run dla publicznego API i GKE Autopilot dla wewnętrznej usługi inwentaryzacyjnej.

Uzasadnienie: Cloud Run minimalizuje narzut operacyjny dla bezstanowego HTTP, wspiera rewizje i dzielenie ruchu (traffic splitting); GKE Autopilot dostarcza funkcje Kubernetes dla usług stanowych/wewnętrznych bez konieczności zarządzania węzłami.

Buduj, skanuj i przechowuj obrazy w Artifact Registry wraz z danymi o pochodzeniu (provenance).

Uzasadnienie: Cloud Build tworzy obrazy kontenerów; Artifact Analysis skanuje je w poszukiwaniu podatności (CVE). Przechowywanie skrótów (digest) i danych o pochodzeniu umożliwia usłudze Binary Authorization wymuszenie uruchamiania tylko przeskanowanych i podpisanych obrazów.

Egzekwuj polityki dopuszczania (admission policies).

Uzasadnienie: Włącz Binary Authorization na klastrze GKE, aby wymagać podpisów i atestacji polityk. Dla Cloud Run skonfiguruj automatyzację wdrożeń, aby uzależnić promocję rewizji od pomyślnego przejścia polityki podatności.

Skonfiguruj sieć z konektorem Serverless VPC i Cloud NAT.

Uzasadnienie: API w Cloud Run musi mieć prywatny dostęp do usługi inwentaryzacyjnej i Cloud SQL. Konektor VPC umożliwia prywatny ruch wychodzący (egress) w przestrzeni RFC1918; Cloud NAT zapewnia wychodzące połączenia z internetem w celu pobierania zależności bez konieczności posiadania zewnętrznych adresów IP na zasobach prywatnych. Utrzymuj konektor i usługi w tym samym regionie i odpowiednio dobierz jego przepustowość.

Zabezpiecz tożsamości i uprawnienia.

Uzasadnienie: Przypisz dedykowane konto serwisowe do usługi Cloud Run z zachowaniem zasady najmniejszych uprawnień (least privilege) (np. rola Cloud SQL Client, uprawnienia do wywoływania wewnętrznych punktów końcowych w razie potrzeby). Dla GKE użyj Workload Identity, aby Pody mogły przyjmować tożsamość kont serwisowych bez poświadczeń na poziomie węzła.

Zaimplementuj bezpieczne wdrożenia i wycofywanie zmian (rollback).

Uzasadnienie: Wdróż API jako nową rewizję Cloud Run i skieruj na nią 5% ruchu w ramach testu canary. Monitoruj opóźnienia, wskaźnik błędów i nasycenie; następnie zwiększ ruch do 100% lub natychmiast go wycofaj, przywracając ruch na poprzednią rewizję. W GKE użyj aktualizacji kroczących (rolling updates) typu Deployment z sondami gotowości (readiness probes) oraz małego wdrożenia canary za tą samą usługą (Service) w celu walidacji przed pełnym wdrożeniem.

Skonfiguruj obserwowalność i SLO.

Uzasadnienie: Emituj strukturalne logi JSON z identyfikatorami śledzenia (trace IDs) z obu platform do Cloud Logging. Utwórz SLO dla opóźnienia p95 i wskaźnika błędów 5xx; dołącz do nich polityki alertów. Użyj Error Reporting i Trace do analizy przyczyn źródłowych (root cause analysis). Dla GKE wdróż DaemonSet do zbierania metryk węzłów i włącz Cloud Ops for GKE.

Zweryfikuj tryby awarii i pojemność.

Uzasadnienie: Przeprowadź testy obciążeniowe, aby zweryfikować przepustowość konektora VPC, współbieżność Cloud Run i działanie HPA w GKE. Potwierdź dokładność sond gotowości, aby zapobiec utracie ruchu (blackholing). Przetestuj ścieżki odmowy przez Binary Authorization oraz wycofanie obrazu po jego skrócie (digest), aby zapewnić możliwość odtworzenia systemu przy włączonym egzekwowaniu zasad łańcucha dostaw.

Takie podejście zapewnia bezpieczne publiczne API o niskim narzucie operacyjnym, kontrolowane usługi wewnętrzne, prywatną sieć, egzekwowalne bezpieczeństwo łańcucha dostaw oraz szybkie wycofywanie zmian, zgodnie z najlepszymi praktykami operacyjnymi Google Cloud.

← Compute Engine i operacje na maszynach wirtualnych · Wszystkie domeny · Sieci VPC →

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