Czym jest Kubernetes? Praktyczne wprowadzenie dla zespołów wdrażających kontenery

Konteneryzacja rozwiązała problem „u mnie działa” - aplikacja spakowana w kontener zachowuje się identycznie na laptopie dewelopera i na serwerze produkcyjnym. Ale z jednym kontenerem sobie poradzisz. Problem zaczyna się, gdy masz ich 20, 50 albo 200 - rozproszonych po wielu serwerach, wymagających wzajemnej komunikacji, automatycznego restartu po awarii i skalowania pod obciążeniem.

Do tego służy Kubernetes: zarządza cyklem życia kontenerów na skalę, której ręczne zarządzanie byłoby niewykonalne.

Skąd wziął się Kubernetes

Kubernetes powstał w Google w 2014 roku jako open-source’owa wersja wewnętrznego systemu Borg, który od dekady zarządzał kontenerami w skali Google. W 2015 roku projekt trafił pod opiekę CNCF (Cloud Native Computing Foundation) i od tego czasu stał się de facto standardem orkiestracji kontenerów.

Dziś Kubernetes jest dostępny jako usługa zarządzana u wszystkich głównych dostawców chmury:

• Amazon EKS (Elastic Kubernetes Service)
• Azure AKS (Azure Kubernetes Service)
• Google GKE (Google Kubernetes Engine)

Porównanie tych usług w kontekście wdrożeń produkcyjnych znajdziesz w naszym artykule AWS vs Azure - strategie wdrażania kontenerów.

Kluczowe koncepcje Kubernetes

Pod - najmniejsza jednostka

Pod to najmniejsza wdrażalna jednostka w Kubernetes. Zawiera jeden lub więcej kontenerów, które współdzielą sieć i storage. W praktyce większość podów zawiera dokładnie jeden kontener - ale zdarzają się przypadki użycia sidecar (np. kontener proxy Envoy obok kontenera aplikacji).

apiVersion: v1
kind: Pod
metadata:
  name: api-server
spec:
  containers:
    - name: api
      image: myapp/api:v2.1.0
      ports:
        - containerPort: 8080
      resources:
        requests:
          memory: "128Mi"
          cpu: "250m"
        limits:
          memory: "256Mi"
          cpu: "500m"

Podów nie tworzy się bezpośrednio w produkcji. Zamiast tego używa się wyższych abstrakcji.

Deployment - deklaratywne zarządzanie podami

Deployment definiuje pożądany stan aplikacji: ile replik (podów) ma działać, jaki obraz kontenera używać i jak przeprowadzić aktualizację. Kubernetes stale dąży do tego, aby aktualny stan odpowiadał deklaracji.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-server
  template:
    metadata:
      labels:
        app: api-server
    spec:
      containers:
        - name: api
          image: myapp/api:v2.1.0
          ports:
            - containerPort: 8080
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

Jeśli jeden pod umrze - Kubernetes automatycznie uruchomi nowy. Jeśli zaktualizujesz obraz kontenera - Kubernetes przeprowadzi rolling update bez przestoju.

Service - stabilny endpoint dla podów

Pody są efemeryczne - mogą powstawać i znikać. Service zapewnia stały adres sieciowy (ClusterIP, NodePort lub LoadBalancer), pod którym pody są dostępne niezależnie od tego, które konkretne instancje aktualnie działają.

apiVersion: v1
kind: Service
metadata:
  name: api-server
spec:
  selector:
    app: api-server
  ports:
    - port: 80
      targetPort: 8080
  type: ClusterIP

Inne serwisy w klastrze komunikują się z api-server przez DNS: http://api-server.default.svc.cluster.local.

Ingress - ruch z zewnątrz

Ingress zarządza dostępem z internetu do serwisów wewnątrz klastra. Definiuje reguły routingu HTTP/HTTPS - np. api.example.com trafia do serwisu API, a app.example.com do serwisu frontend.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: main-ingress
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  tls:
    - hosts:
        - api.example.com
      secretName: api-tls
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: api-server
                port:
                  number: 80

Namespace - izolacja logiczna

Namespace dzieli klaster na logiczne grupy. Typowe podejście: production, staging, monitoring. Każdy namespace ma oddzielne limity zasobów (ResourceQuota) i polityki sieciowe (NetworkPolicy).

Autoskalowanie w Kubernetes

Kubernetes oferuje trzy poziomy autoskalowania:

HPA jest najczęściej używany. Przykład: jeśli CPU podów API przekroczy 70%, HPA doda nowe repliki. Gdy obciążenie spadnie - usunie nadmiarowe.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-server-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Kubernetes w praktyce - kiedy warto, kiedy nie

Warto wdrożyć Kubernetes gdy:

• Masz min. 5+ mikroserwisów komunikujących się ze sobą
• Potrzebujesz zero-downtime deployments (rolling updates, canary releases)
• Twoja aplikacja wymaga elastycznego skalowania (np. e-commerce z sezonowymi pikami)
• Pracujesz w modelu DevOps/GitOps i chcesz mieć deklaratywną infrastrukturę
• Planujesz multi-cloud lub chcesz uniknąć vendor lock-in’u na poziomie orkiestracji

Nie warto gdy:

• Masz 1–3 serwisy bez planów wzrostu → Fargate, Cloud Run lub App Service wystarczą
• Twój zespół nie ma doświadczenia z kontenerami → najpierw konteneryzacja, potem K8s
• Budżet jest ograniczony a klaster byłby zbyt mały (<3 node’y) → koszt operacyjny K8s przewyży korzyści
• Aplikacja jest monolityczna i nie planujesz rozbijać jej na mikroserwisy

Managed Kubernetes vs self-managed

Rekomendacja: dla produkcji niemal zawsze managed Kubernetes. Self-managed ma sens w edge computing, środowiskach air-gapped lub gdy compliance wymaga pełnej kontroli nad control plane.

Ekosystem narzędzi wokół Kubernetes

Kubernetes sam w sobie to platforma - do produkcyjnego użycia potrzebujesz dodatkowych narzędzi:

• Helm - menedżer pakietów (charty definiujące zestawy zasobów K8s)
• ArgoCD / Flux - GitOps (stan klastra = kod w repozytorium Git)
• Cert-Manager - automatyczne certyfikaty TLS (Let’s Encrypt)
• Prometheus + Grafana - monitoring i dashboardy
• Karpenter - autoskalowanie node’ów (szybsze niż Cluster Autoscaler)
• Istio / Linkerd - service mesh (mTLS, observability, traffic management)
• Kyverno / OPA Gatekeeper - polityki bezpieczeństwa klastra

Więcej o tym, jak Infrastructure as Code (Terraform lub OpenTofu) współpracuje z Kubernetes’em w produkcji, przeczytasz w artykule o budowaniu skalowalnej architektury z AWS, Terraform i Kubernetes.

Pierwszy krok: od Docker Compose do Kubernetes

Jeśli dziś uruchamiasz aplikację przez docker-compose up, przejście do K8s wymaga:

1. Konteneryzacja - każdy serwis ma Dockerfile i obraz w registry (ECR, ACR, GCR, Docker Hub)
2. Manifesty K8s - Deployment + Service dla każdego serwisu (zamiast docker-compose.yml)
3. Ingress - zamiast otwierania portów na hoście
4. ConfigMaps / Secrets - zamiast plików .env
5. Persistence - PersistentVolumeClaims zamiast woluminów z hosta

Dla zespołów przechodzących z Docker Compose, narzędzie kompose generuje wstępne manifesty K8s - ale traktuj je jako punkt startowy, nie produkcyjne konfiguracje.

Koszty Kubernetes w chmurze

Koszt Kubernetes składa się z:

Typowy minimalny klaster produkcyjny (3 node’y m5.large, EKS): ~$350–450/mies. Obejmuje control plane, 3 instancje, LB i bazowy storage.

Optymalizacja kosztów K8s to osobny temat. Kluczowe techniki: Spot/Preemptible Instances dla workloadów tolerujących przerwy, right-sizing node’ów i Savings Plans dla stabilnego baseline’u. Więcej o mechanizmach zniżkowych AWS przeczytasz w artykule Savings Plans vs Reserved Instances.

Podsumowanie

Kubernetes to nie narzędzie - to platforma, na której budujesz infrastrukturę produkcyjną. Rozwiązuje realne problemy: zero-downtime deployments, automatyczne skalowanie, self-healing, deklaratywne zarządzanie stanem. Ale wprowadza też złożoność operacyjną, która ma sens dopiero od pewnej skali (5+ serwisów, wymagania HA, potrzeba elastyczności).

Jeśli Twój zespół jest na etapie konteneryzacji - zacznij od poznania silników kontenerowych. Jeśli już masz kontenery w Docker Compose i zastanawiasz się, jak skalować w chmurze - Kubernetes (w wersji managed: EKS, AKS lub GKE) to naturalny następny krok.

Planujesz wdrożenie Kubernetes?

Projektujemy klastry EKS, AKS i GKE od architektury po GitOps. Umów się na bezpłatną 30-minutową konsultację techniczną.

Umów rozmowę

Najczęściej zadawane pytania

Czy Kubernetes jest darmowy?

Kubernetes jako projekt open-source jest darmowy. Koszty pojawiają się przy infrastrukturze: serwery (node’y), load balancery, storage. W managed K8s (EKS, GKE) dochodzi opłata za control plane (~$73/mies.). AKS oferuje darmowy control plane w wersji standardowej.

Ile czasu zajmuje wdrożenie Kubernetes?

Dla zespołu z doświadczeniem kontenerowym: 2–4 tygodnie na klaster produkcyjny z CI/CD. Dla zespołu bez doświadczenia K8s: 6–8 tygodni włącznie z nauką i migracją pierwszych serwisów.

Kubernetes vs Docker - jaka jest różnica?

Docker tworzy i uruchamia kontenery. Kubernetes zarządza wieloma kontenerami na wielu serwerach - decyduje gdzie je uruchomić, jak skalować, jak obsłużyć awarie i jak rozprowadzić ruch. Docker to silnik kontenera, Kubernetes to orkiestrator.

Czy potrzebuję Kubernetes do mikroserwisów?

Nie jest wymagany, ale jest najpopularniejszym wyborem. Alternatywy: AWS ECS/Fargate, Azure Container Apps, Google Cloud Run. Kubernetes daje największą kontrolę i przenośność między chmurami, ale kosztem wyższej złożoności operacyjnej.

Jak zacząć naukę Kubernetes?

1. Opanuj Docker i konteneryzację
2. Zainstaluj minikube lub kind lokalnie
3. Przećwicz tworzenie podów, deploymentów i serwisów z kubectl
4. Wdroż prostą aplikację (frontend + backend + baza danych)
5. Dodaj Ingress, HPA i monitoring