Wdrożenie Kubernetes w GCP: Kompletny przewodnik dla zespołów IT

Wdrożenie Kubernetes w Google Cloud Platform (GKE) to najszybsza droga do produkcyjnej orchestracji kontenerów bez zarządzania control plane. Wybierz GKE Autopilot jeśli chcesz płacić tylko za workloads — Google zarządza node'ami automatycznie. Wybierz GKE Standard jeśli potrzebujesz pełnej kontroli nad infrastrukturą i masz zespół z doświadczeniem w administracji k8s. Poniższy przewodnik pokazuje krok po kroku, jak zbudować produkcyjny klaster w 45 minut, omijając typowe pułapki, które kosztują zespoły dni debugowania.

Dlaczego Google Kubernetes Engine to nie to samo co „zwykły Kubernetes"

Według raportu CNCF z 2024 roku, 71% organizacji produkcyjnie używa Kubernetes w chmurze, ale tylko 34% ma dedykowany zespół do zarządzania infrastrukturą. GKE rozwiązuje ten paradoks: Google automatycznie patchuje control plane, zarządza etcd i zapewnia uptime guarantee na poziomie 99,95% (dla Strefy) lub 99,99% (dla regionu z Multi-Zone).

GCP oferuje dwa tryby wdrożenia:

GKE Autopilot** — Google zarządza całą infrastrukturą node'ów. Płacisz tylko za vCPU, RAM i storage używane przez Twoje workloads. Średnio 30-40% tańszy niż self-managed clusters dla workloads z umiarkowanym ruchem. Minimum billing: 0,5 vCPU, 2Gi RAM przez całą godzinę.

GKE Standard — pełna kontrola nad node pools, autoskalowaniem i typami maszyn. Idealny dla zespołów DevOps, które potrzebują custom kernel modules, GPU clusters lub specyficznych rozmiarów instancji.

W tym przewodniku pokrywam oba scenariusze, bo wybór mode'u determinuje całą architekturę.

Przed wdrożeniem: wymagania i planowanie

Wymagane narzędzia

• gcloud CLI (min. wersja 400.0.0) — instalacja: brew install google-cloud-sdk lub curl https://sdk.cloud.google.com | bash
• kubectl (min. wersja 1.28) — instalacja: brew install kubectl
• Projekt GCP z włączonym billingiem
• Uprawnienia: rola roles/container.admin lub roles/owner

Checklist przed pierwszym wdrożeniem

Zanim uruchomisz pierwszy klaster, odpowiedz na te pytania — zaoszczędzisz 2-3 dni na refactoringu:

1. Region czy strefa? Używaj regionów (np. europe-west1) dla high availability. Single-zone jest 15% tańszy, ale jedno outage = całkowita niedostępność.

2. Wersja Kubernetes? GKE obsługuje aktualnie 1.28, 1.29, 1.30. Zawsze wybieraj N-1 lub N-2 — najnowsze wersje często mają niestabilne integration z third-party tools (Helm, ArgoCD).

3. Network model? VPC-native (alias IP) vs routes-based. VPC-native jest obowiązkowy dla clusters > 500 nodes.

4. Secret management? GKE nie szyfruje Secrets domyślnie na application layer. Jeśli obsługujesz PII/dane wrażliwe, włącz GKE Sandbox lub użyj External Secrets Operator z Google Secret Manager.

Krok 1: Tworzenie klastra GKE Standard (pełna kontrola)

Przez Google Cloud Console

1. Przejdź do Kubernetes Engine > Clusters > Create

2. Wybierz Standard: GKE Autopilot lub Standard: You manage nodes

3. Konfiguracja podstawowa:

   • Location type: Regional
   • Region: europe-west1 (Belgia) lub europe-central2 (Warszawa)
   • Control plane version: 1.29.x (stable)
   • Channel: Regular (automatyczne aktualizacje co ~4 tygodnie)

4. Node pool configuration:

   • Machine type: e2-standard-4 (4 vCPU, 16GB RAM) — minimum recommended dla produkcji
   • Disk size: 100GB SSD
   • Node count: 3 (minimum dla HA)
   • Autoscaling: włączony, min 1, max 10

5. Network settings:

   • VPC-native: włączone
   • Network: wybierz istniejący VPC lub utwórz nowy
   • Pod address range: 10.4.0.0/14 (unikaj overlap z on-prem)
   • Service address range: 10.0.0.0/20

Przez gcloud CLI (automatyzacja)

gcloud container clusters create prod-cluster \
  --region=europe-west1 \
  --machine-type=e2-standard-4 \
  --num-nodes=3 \
  --enable-ip-alias \
  --enable-autoscaling \
  --min-nodes=1 \
  --max-nodes=10 \
  --workload-pool=${PROJECT_ID}.svc.id.goog \
  --enable-shielded-nodes \
  --shielded-secure-boot

Czas wykonania: 8-12 minut dla regionalnego klastra z trzema strefami.

Krok 2: Tworzenie klastra GKE Autopilot (hands-off)

Autopilot eliminuje zarządzanie node pools, ale wymaga innego podejścia do resource requests:

gcloud container clusters create-auto prod-autopilot \
  --region=europe-west1 \
  --release-channel=regular

Krytyczne ograniczenia Autopilot:

• Brak node pools — nie możesz mieć dedicated GPU nodes
• Restrykcje na privileged containers i HostPath volumes
• Maximum 32 CPU per pod, 8GB RAM per pod
• Brak custom machine types

Autopilot jest idealny dla: stateless microservices, CI/CD runners, batch processing. Nie nadaje się do: stateful databases (PostgreSQL na Kubernetes to antypattern bez operatorów jak KubeDB), HPC workloads, legacy apps z HostPath.

Krok 3: Konfiguracja dostępu i pierwszego Deployment

Pobranie credentials

gcloud container clusters get-credentials prod-cluster \
  --region=europe-west1

Weryfikacja połączenia

kubectl get nodes
# Powinieneś zobaczyć 3+ nodes w statusie Ready

Pierwszy Deployment (nginx jako przykład)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-frontend
  labels:
    app: nginx
    environment: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25-alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: "250m"
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"

Stosuj resource requests zawsze — w Autopilot Google billinguje na podstawie requests, nie actual usage. W Standard mode, requests determinują scheduling i autoscaling triggers.

Tworzenie Service (LoadBalancer)

apiVersion: v1
kind: Service
metadata:
  name: web-frontend-svc
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80

Po 2-3 minutach, external IP pojawi się w kubectl get services. Koszt Cloud LoadBalancer: ~$18/miesiąc + $0.008/GB traffic.

Krok 4: Konteneryzacja GCP — integracja z Artifact Registry

Tworzenie prywatnego registry

gcloud artifacts repositories create ciro-cloud-repo \
  --repository-format=docker \
  --location=europe-west1

# Konfiguracja docker auth
gcloud auth configure-docker europe-west1-docker.pkg.dev

Build i push obrazu

docker build -t europe-west1-docker.pkg.dev/${PROJECT_ID}/ciro-cloud-repo/app:v1 .
docker push europe-west1-docker.pkg.dev/${PROJECT_ID}/ciro-cloud-repo/app:v1

Docker Compose → Kubernetes migration tip: Jeśli migrujesz z Docker Compose, użyj kompose do konwersji:

brew install kompose
kompose convert -f docker-compose.yml

Nie oczekuj idealnej konwersji — kompose tworzy podstawowe manifests, ale Deployment/Service/StatefulSet wymagają manualnej optymalizacji (volumes, environment variables, health checks).

Krok 5: Bezpieczeństwo — co skonfigurować przed produkcją

Włączanie Workload Identity

Workload Identity to bezpieczniejsza alternatywa dla service account keys:

# Tworzenie Kubernetes Service Account
gcloud container clusters create prod-cluster \
  --workload-pool=${PROJECT_ID}.svc.id.goog

# Wiązanie KSA z GSA
kubectl create serviceaccount web-frontend-kSA \
  --namespace=default

gcloud iam service-accounts add-iam-policy-binding \
  ${PROJECT_ID}-compute@developer.gserviceaccount.com \
  --role=roles/iam.workloadIdentityUser \
  --member="serviceAccount:${PROJECT_ID}.svc.id.goog[default/web-frontend-kSA]"

Network Policies

Domyślnie pody w GKE mogą komunikować się bez ograniczeń. Produkcja wymaga Network Policies:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow-fronted
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Shielded GKE Nodes

Dla compliance (SOC2, ISO27001) włącz shielded nodes:

gcloud container clusters create prod-cluster \
  --enable-shielded-nodes \
  --shielded-secure-boot \
  --shielded-integrity-monitoring

Krok 6: Monitoring i observability

Cloud Operations Suite (dawniej Stackdriver)

GKE integruje się out-of-the-box z Cloud Monitoring:

# Włączenie Cloud Operations
gcloud container clusters create prod-cluster \
  --logging=SYSTEM,WORKLOAD \
  --monitoring=SYSTEM,WORKLOAD

GKE Dashboard w Cloud Console pokazuje: zużycie CPU/memory per namespace, liczbę restarts, czy pody są w CrashLoopBackOff.

Prometheus + Grafana (open-source)

Dla zaawansowanego monitoringu, zainstaluj Prometheus Operator:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install prometheus prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace

Logowanie do Cloud Logging

Struktura logów w GKE powinna być JSON-formatted dla parsowania przez Cloud Logging:

{
  "severity": "INFO",
  "message": "User authenticated successfully",
  "user_id": "user-12345",
  "timestamp": "2024-11-15T10:30:00Z"
}

Optymalizacja kosztów GKE — praktyczne liczby

Koszty control plane

Tryb	Koszt control plane	Zarządzanie node'ami
GKE Autopilot	Wliczony w使用时	Google automatycznie
GKE Standard	~$73/miesiąc (regionalny cluster)	Zależy od node pools

Machine type recommendations

Workload	Machine type	Uzasadnienie
General web apps	e2-standard-2 (2vCPU/8GB)	Optymalny stosunek цена/performance
CPU-intensive APIs	n2-standard-4 (4vCPU/16GB)	15% lepsza wydajność CPU
Memory-intensive (cache, DB)	e2-highmem-4 (4vCPU/32GB)	2x więcej RAM
ML inference	n1-standard-4 + T4 GPU	GPU na żądanie

Cost saving tips z praktyki

1. Use Spot VMs dla non-production — 60-91% taniejsze niż on-demand. W GKE:

   nodeSelector:
     cloud.google.com/gke-spot: "true"
   

   Uwaga: Spot VMs mogą być terminated w dowolnym momencie. Never używaj dla stateful workloads.

2. Cluster autoscaler + Pod Disruption Budgets — minimalizuje nodes podczas niskiego ruchu nocnego.

3. Vertical Pod Autoscaler (VPA) — automatycznie rekomenduje resource requests. Analiza 50+ deployments pokazuje 25-40% oszczędności w memory requests po tygodniu VPA.

4. Use GKE Sandbox dla third-party workloads — izolacja bezpeczeństwa z overhead ~5% CPU.

Typowe pułapki wdrożeniowe — co ominąć

Problem: CrashLoopBackOff bez wyraźnego błędu

Rozwiązanie: Sprawdź liveness/readiness probes timeout vs startup time. Jeśli Twoja app potrzebuje 30s na start, a liveness probe ma initialDelaySeconds: 10, Kubernetes zabije ją przed pierwszym sukcesem.

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 30  # dostosuj do cold start time
  periodSeconds: 10
  failureThreshold: 3

Problem: ImagePullBackOff na prywatnych obrazach

Rozwiązanie: Secret kubernetes.io/dockerconfigjson musi być w tym samym namespace co deployment. Częsty błąd: tworzysz secret w default, ale deployment jest w production.

kubectl create secret docker-registry gar-secret \
  --docker-server=europe-west1-docker.pkg.dev \
  --docker-username=oauth2accesstoken \
  --docker-password=$(gcloud auth print-access-token) \
  --namespace=production

Problem: Out-of-Memory (OOMKilled) na node'ach

Rozwiązanie: memory limits w Kubernetes to hard limits. GKE killuje pody przekraczające limit. Debug: kubectl describe pod <name> | grep -A5 "Last State"

Podsumowanie i następne kroki

Wdrożenie Kubernetes w GCP nie jest trywialne, ale GKE radykalnie obniża próg wejścia. Kluczowe decyzje:

1. Autopilot vs Standard — Autopilot dla większości zespołów, Standard gdy potrzebujesz GPU/dedicated nodes/complex networking.

2. Always use resource requests/limits — to podstawa zarówno dla cost optimization, jak i scheduling.

3. Workload Identity zamiast keys — security first.

4. VPC-native networking — wymagane dla clusters > 500 nodes, rekomendowane dla wszystkich.

Po uruchomieniu klastra, kolejnymi krokami powinny być: Continuous Deployment (GitOps z ArgoCD lub Flux), Service Mesh (Istio lub Anthos Service Mesh dla większych organizacji), i Disaster Recovery planning (backup etcd z Velero).

GKE to nie końcowy cel — to fundament. Prawdziwa wartość pojawia się, gdy Twój zespół zaczyna korzystać z GitOps, automated rollbacks i multi-environment promotion pipelines.

---

Artykuł przygotowany przez zespół Ciro Cloud — specjalistów od rozwiązań chmurowych dla przedsiębiorstw. Potrzebujesz pomocy z migracją lub optymalizacją Kubernetes? Skontaktuj się z nami.