Cloud Run – błyskawiczne wdrażanie aplikacji w chmurze Google

Chmura pozwala znacznie odciążyć zespoły IT. Jej zarządzane usługi przejmują lwią część prac utrzymaniowych, pozostawiając więcej przestrzeni na rozwój. Pozwalają szybciej wdrażać i modyfikować aplikacje, zapewniają wysoką dostępność poprzez skalowanie w odpowiedzi na bieżące zapotrzebowanie oraz prowadzą do optymalizacji kosztów dzięki rozliczeniom w modelu pay-as-you-use. Szczególnie popularnymi usługami wśród przedsiębiorstw, jak też indywidualnych specjalistów, są te z wachlarza Compute & Serverless.

Compute i Serverless. Moc obliczeniowa chmury Google

Google Cloud oferuje blisko 200 zarządzanych usług chmurowych, w tym maszyny wirtualne oraz platformy developerskie (grupa Compute & Serverless). To usługi, które dają dostęp do niemal nieograniczonej mocy obliczeniowej Google.

Do usług Compute & Serverless należą między innymi:

• Compute Engine – usługa maszyn wirtualnych w modelu Infrastructure as a Service,
• App Engine – platforma developerska z automatyczną obsługą infrastruktury,
• Google Kubernetes Engine – zarządzany Kubernetes w chmurze, czyli platforma orkiestracji kontenerów i klastrów,
• Cloud Run – bezserwerowa platforma do uruchamiania kontenerów, funkcji i zadań,
• Cloud Run functions – nowa nazwa Cloud Functions (2nd gen); Cloud Functions (1st gen) pozostaje odrębną generacją usługi.

Co to jest Cloud Run?

Cloud Run to w pełni zarządzana, bezserwerowa platforma do uruchamiania kontenerów na infrastrukturze Google. Użytkownik nie zarządza serwerami ani orkiestracją – skupia się na kodzie.

Cloud Run obsługuje trzy typy zasobów:

• Services – dla endpointów HTTP (oraz WebSockets, HTTP/2 i gRPC) oraz zdarzeń,
• Jobs – dla prac, które kończą się po wykonaniu (ręcznie, według harmonogramu lub z workflow; mogą działać równolegle jako array jobs),
• Worker Pools – dla stale działających, nie-HTTP, pull-based procesów w tle, np. konsumentów Kafka, Pub/Sub pull lub RabbitMQ.

Worker Pools nie obsługują wbudowanego autoskalowania. Liczbę instancji ustawia się ręcznie albo automatyzuje zewnętrznym autoskalerem (np. opartym na metrykach kolejki, takim jak CREMA/KEDA). Jeśli liczba instancji wynosi 0, worker pool nie rozpocznie przetwarzania, mimo że wdrożenie zakończyło się powodzeniem. Worker pools nie mają load-balanced endpointu ani publicznego URL i są rozliczane za czas działania instancji.

Funkcjonalności Cloud Run

• Dowolna technologia – dowolny język i biblioteki, o ile da się je spakować do kontenera. Można też wdrożyć kod źródłowy bez ręcznego budowania obrazu.
• Kontenery i rejestry – Cloud Run może wdrażać obrazy z Artifact Registry, który Google rekomenduje jako rejestr obrazów. Integruje się z Cloud Build.
• Integracja z ekosystemem GCP – Cloud SQL, Firestore, Pub/Sub, Secret Manager, Cloud Monitoring itd.
• Przenośność – Cloud Run korzysta z koncepcji kontenerowych i ekosystemu Knative. Przenośny jest przede wszystkim obraz kontenera i logika aplikacyjna. Konfiguracje Cloud Run (IAM, sieć, rewizje, eventy, GPU) nie są automatycznie przenośne między chmurami.
• Zarządzana infrastruktura – nie wymaga zarządzania serwerami ani orkiestracją, lecz nadal wymaga utrzymania własnego kodu, zależności, obrazów bazowych, polityk IAM i konfiguracji bezpieczeństwa.
• Szybkie skalowanie (Services) – skalowanie w górę i w dół, w tym scale-to-zero (przy odpowiedniej konfiguracji). Utworzenie nowej instancji może wiązać się z cold startem.
• Redundancja regionalna – Cloud Run jest usługą regionalną; ruch i dane są automatycznie rozkładane między strefami w obrębie regionu. Wdrożenie wieloregionowe wymaga skonfigurowania co najmniej dwóch usług Cloud Run w różnych regionach oraz warstwy routingu, zwykle globalnego Application Load Balancera i Serverless NEG. Cloud Run oferuje mechanizm service health dla automatycznego failover i failback, ale nie jest to domyślna właściwość pojedynczej usługi regionalnej – wymaga skonfigurowania co najmniej jednej minimalnej instancji (min-instances) w każdym regionie, co oznacza, że nie działa przy scale-to-zero.
• Bezpieczeństwo – Binary Authorization, izolowane środowiska uruchomieniowe, Secret Manager, Identity-Aware Proxy. Kontenery działają w środowisku sandboxed. Cloud Run udostępnia także sandboxes do wykonywania niezaufanego kodu (w tym kodu generowanego przez LLM) w izolowanych kontenerach opartych na gVisor – funkcja ta ma jednak konkretne ograniczenia i nie stanowi pełnej gwarancji bezpieczeństwa dowolnego kodu.
• Monitoring i rollback – integracja z Cloud Monitoring, Logging, Trace i Error Reporting + możliwość szybkiego powrotu do poprzedniej rewizji.
• GPU i AI – Cloud Run obsługuje NVIDIA L4 oraz NVIDIA RTX PRO 6000 Blackwell (w zależności od regionu i dostępnej puli quota). Ograniczenia: jedna karta GPU na instancję, wymagany model rozliczeniowy instance-based, minimalne zasoby (L4: min. 4 vCPU / 16 GiB RAM; RTX PRO 6000: min. 20 vCPU / 80 GiB). GPU może scale-to-zero w usługach Cloud Run Services, jednak po uruchomieniu instancji opłata za GPU jest naliczana przez cały cykl jej życia. Dla Jobs GPU jest rozliczane przez cały czas działania instancji zadania.

Przykłady użycia Cloud Run

• Serwis internetowy – dynamiczne strony HTTP z bazą w Cloud SQL lub Firestore.
• Aplikacje back-office – integracje, zarządzanie dostępami, obieg dokumentów.
• Automatyczne generowanie dokumentów – Cloud Run Jobs + Cloud Scheduler (opłata tylko za czas wykonania zadania oraz ewentualne koszty usług powiązanych i transferu).
• AI i procesy w tle – inference z GPU, agenty, Worker Pools do ciągłego przetwarzania kolejek.

Uwaga o kosztach przy braku ruchu: przy usługach z request-based billing i minimum instances = 0 nie płaci się za sam Cloud Run, gdy nie ma żądań. Mogą jednak pozostać koszty usług towarzyszących (Cloud Build, Artifact Registry, transfer sieciowy, VPC connector, bazy danych, logi itp.).

Ile kosztuje Cloud Run? Koszty usługi

Cloud Run rozlicza zużycie z dokładnością do 100 ms. Ceny zależą od regionu oraz modelu rozliczeniowego.

Free tier (agregowany na poziomie konta rozliczeniowego, odnawia się co miesiąc):

Model	CPU	Pamięć	Requesty
Request-based	180 000 vCPU-sekund	360 000 GiB-sekund	2 miliony
Instance-based / Jobs	240 000 vCPU-sekund	450 000 GiB-sekund	–

Orientacyjne stawki Tier 1 (np. europe-west1 Belgia, us-central1) – request-based, aktywny czas:

• vCPU: 0,000024 USD / s
• Pamięć: 0,0000025 USD / GiB-s
• Requesty: 0,40 USD / milion

Uwaga: region europe-central2 (Warszawa) należy do Tier 2 – stawki są wyższe niż w Tier 1. Zawsze sprawdzaj aktualny cennik dla wybranego regionu: cloud.google.com/run/pricing.

Do oszacowania kosztów służy kalkulator Google Cloud.

FAQ – najczęściej zadawane pytania o Cloud Run

Czy Google Cloud Run oferuje darmowy pakiet (Free Tier)?

Tak. W modelu request-based billing miesięczny Free Tier obejmuje m.in. 2 mln żądań, 180 000 vCPU-sekund oraz 360 000 GiB-sekund pamięci. Limit jest agregowany na poziomie konta rozliczeniowego i odnawia się co miesiąc. Free Tier nie obejmuje automatycznie wszystkich elementów architektury. Niezależnie mogą być naliczane koszty np. Cloud Build, Artifact Registry, transferu sieciowego, VPC Connectora, bazy danych, logów lub innych usług Google Cloud.

Jaka jest różnica między Cloud Run a Cloud Run functions?

Cloud Run pozwala uruchamiać własne kontenery jako usługi HTTP, zadania batchowe (Jobs) albo Worker Pools. Deweloper sam określa obraz kontenera, sposób uruchomienia, zależności, konfigurację i skalowanie aplikacji. Cloud Run functions to nowa nazwa Cloud Functions (2nd gen) — model Functions as a Service. Jest przeznaczony przede wszystkim dla pojedynczych funkcji reagujących na żądania HTTP albo zdarzenia, np. publikację komunikatu w Pub/Sub czy zapis pliku w Cloud Storage. Oba produkty korzystają z infrastruktury Cloud Run, ale różnią się doświadczeniem wdrożeniowym i poziomem kontroli nad kontenerem.

Czy mogę nadal korzystać z adresów gcr.io?

Tak, ale nie jako z osobnej usługi Container Registry. Container Registry zostało wycofane, natomiast Artifact Registry może obsługiwać repozytoria kompatybilne z domeną gcr.io oraz przekierowywać do nich żądania. W nowych projektach najlepiej standardowo używać Artifact Registry i regionalnych adresów obrazów w formacie: REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/IMAGE. Artifact Registry jest rekomendowanym przez Google rejestrem do przechowywania obrazów kontenerów używanych w Cloud Run.

Jak działa Serverless GPU w Cloud Run?

Cloud Run umożliwia przypisanie GPU do instancji kontenera — zależnie od regionu, dostępnych limitów quota i konfiguracji zasobów. Dostępne konfiguracje obejmują m.in. NVIDIA L4 i NVIDIA RTX PRO 6000 Blackwell, przeznaczone np. do inference modeli AI i LLM. Dla usług Cloud Run Services instancje z GPU mogą skalować się do zera, gdy nie ma ruchu. GPU wymaga jednak instance-based billing: od chwili uruchomienia instancji naliczane są opłaty za GPU, CPU i pamięć przez cały czas jej działania, z rozliczeniem za użycie zaokrąglonym do 100 ms. Scale-to-zero ogranicza koszt bezczynności, lecz po wznowieniu ruchu może wystąpić cold start.

Do czego służą kontenery sidecar w Cloud Run?

Cloud Run pozwala uruchomić w jednej instancji usługi do 10 współpracujących kontenerów. Kontener główny obsługuje aplikację, a sidecary realizują funkcje pomocnicze. Typowe zastosowania obejmują proxy, autoryzację, zbieranie metryk, telemetrię, logowanie, synchronizację danych albo łączenie aplikacji z usługami pomocniczymi. Takie podejście rozdziela odpowiedzialności, ale zwiększa zużycie zasobów i złożoność działania instancji.

Kiedy wybrać Cloud Run, a kiedy Google Kubernetes Engine?

Wybierz Cloud Run, gdy chcesz szybko wdrożyć aplikację kontenerową bez zarządzania serwerami i klastrem Kubernetes, korzystać z automatycznego skalowania oraz płacić głównie za realne wykorzystanie zasobów. Google Kubernetes Engine lepiej sprawdzi się, gdy potrzebujesz pełnej kontroli nad Kubernetesem – np. operatorów, DaemonSetów, zaawansowanej polityki sieciowej, niestandardowego harmonogramowania, specyficznej konfiguracji węzłów lub wielu wzajemnie zależnych usług działających na klastrze.

Czy Cloud Run nadaje się do aplikacji produkcyjnych?

Tak. Cloud Run zapewnia regionalną redundancję między strefami, zarządzanie rewizjami, stopniowe przekierowywanie ruchu, integrację z IAM oraz narzędziami obserwowalności, takimi jak Cloud Monitoring i Cloud Logging. Wysoka dostępność w wielu regionach wymaga jednak osobnej architektury: wdrożenia aplikacji co najmniej w dwóch regionach oraz warstwy routingu, np. globalnego Application Load Balancera z Serverless NEG. Mechanizm Cloud Run service health może wspierać automatyczny failover i failback, ale nie jest domyślną cechą pojedynczej usługi regionalnej – wymaga skonfigurowania co najmniej jednej minimalnej instancji w każdym regionie, więc nie zadziała przy scale-to-zero.