Kubernetes dla Początkujących - Kompletny Przewodnik

📦 Pod

Pod to najmniejsza jednostka w Kubernetes. To grupa jednego lub więcej kontenerów Docker, które dzielą storage i network. W 99% przypadków: 1 Pod = 1 kontener.

apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
  labels:
    app: my-app
spec:
  containers:
  - name: nginx
    image: nginx:1.25
    ports:
    - containerPort: 80

🚀 Deployment

Deployment zarządza Podami. Definiujesz ile replik chcesz, a Kubernetes automatycznie tworzy i utrzymuje odpowiednią liczbę Podów. Obsługuje rolling updates, rollback i self-healing.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3  # 3 kopie aplikacji
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: my-app:v1.0
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 512Mi

🌐 Service

Service to stabilny endpoint dla Podów. Pody mają dynamiczne IP, które zmieniają się przy każdym restarcie. Service zapewnia stały DNS name i load balancing.

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  type: LoadBalancer  # Publiczny IP
  selector:
    app: my-app  # Kieruje ruch do Podów z tym labelem
  ports:
  - port: 80        # Port zewnętrzny
    targetPort: 8080  # Port w kontenerze

⚙️ ConfigMap & Secret

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  API_URL: "https://api.example.com"
  LOG_LEVEL: "info"

apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
data:
  DB_PASSWORD: cGFzc3dvcmQxMjM=  # base64
  API_KEY: c2VjcmV0a2V5NDU2=

Podstawowe operacje

Deploy aplikacji

Update i rollback

Debugging

Cleanup

Rolling Update (default)

Stopniowa wymiana Podów ze starej wersji na nową. Kubernetes usuwa stare Pody i tworzy nowe partiami, utrzymując minimum działających replik.

spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1  # Max 1 Pod offline
      maxSurge: 2        # Max 2 extra Pods podczas update

Blue/Green Deployment

Dwa identyczne środowiska: Blue (current production) i Green (new version). Deploy do Green, testuj, przełącz ruch z Blue na Green (instant switch).

Canary Deployment

Nowa wersja najpierw dla małej grupy użytkowników (np. 5%). Jeśli wszystko OK, stopniowo zwiększasz procent (10%, 25%, 50%, 100%).

Horizontal Pod Autoscaler (HPA)

HPA automatycznie zmienia liczbę replik (Podów) w zależności od CPU, RAM lub custom metrics.

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

Vertical Pod Autoscaler (VPA)

VPA automatycznie dostosowuje CPU i RAM requests/limits dla Podów. Zamiast więcej Podów (horizontal), większe Pody (vertical).

Cluster Autoscaler

Cluster Autoscaler automatycznie dodaje/usuwa worker nodes w zależności od potrzeb. Gdy Pody czekają na zasoby (pending), CA dodaje nowe nody. Gdy nody są puste, CA je usuwa.

Podstawy Kubernetes networking

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend-service
            port:
              number: 80

CNI (Container Network Interface)

CNI plugin implementuje networking model Kubernetes. Wybór CNI wpływa na performance i features.

Network Policies (firewall rules)

Network Policies to firewall dla Podów. Domyślnie wszystkie Pody mogą się komunikować ze wszystkimi. Network Policy ogranicza komunikację.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend  # Tylko frontend może łączyć się z backend

Option 1: Local development (Minikube / kind)

Najszybszy sposób na naukę. Single-node cluster na Twoim laptopie.

Option 2: Production cluster (Azure AKS)

Managed Kubernetes w Azure. 10 minut setup, production-ready.

Krok 1: Przygotowanie obrazu Docker

Najpierw konteneryzuj swoją aplikację Node.js i wypchnij do rejestru kontenerów (Docker Hub, Azure ACR, AWS ECR).

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

Krok 2: Deployment Kubernetes

Utwórz Deployment z 3 replikami, limitami zasobów i health checks.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nodejs-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nodejs-api
  template:
    metadata:
      labels:
        app: nodejs-api
    spec:
      containers:
      - name: api
        image: myregistry.azurecr.io/nodejs-api:v1.0
        ports:
        - containerPort: 3000
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: db-secret
              key: url
        - name: NODE_ENV
          value: "production"
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 512Mi
        livenessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 3000
          initialDelaySeconds: 5
          periodSeconds: 5

Krok 3: Service i Ingress

Udostępnij API przez LoadBalancer Service i skonfiguruj Ingress dla HTTPS.

apiVersion: v1
kind: Service
metadata:
  name: nodejs-api-service
spec:
  type: LoadBalancer
  selector:
    app: nodejs-api
  ports:
  - port: 80
    targetPort: 3000

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

Krok 4: Konfiguracja auto-skalowania

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

Krok 5: Wdrożenie na Kubernetes

# Utwórz namespace
kubectl create namespace production

# Utwórz secret dla bazy danych
kubectl create secret generic db-secret \
  --from-literal=url="postgresql://user:pass@db.example.com/mydb" \
  -n production

# Zastosuj wszystkie manifesty
kubectl apply -f deployment.yaml -n production
kubectl apply -f service.yaml -n production
kubectl apply -f ingress.yaml -n production
kubectl apply -f hpa.yaml -n production

# Obserwuj wdrożenie
kubectl get pods -n production -w

# Pobierz IP LoadBalancera
kubectl get service nodejs-api-service -n production

Zarządzanie zasobami

• •Zawsze definiuj resource requests i limits – zapobiega to sytuacji, gdy jedna aplikacja zużywa wszystkie zasoby węzła
• •Używaj LimitRanges w namespaces, aby wymusić minimalne i maksymalne limity zasobów
• •Monitoruj zużycie zasobów regularnie używając kubectl top

Bezpieczeństwo

• •Używaj external secret managers (Azure Key Vault, AWS Secrets Manager) zamiast przechowywać sekrety w Git
• •Implementuj Network Policies dla kontroli ruchu między Podami (zero-trust networking)
• •Używaj RBAC (Role-Based Access Control) do ograniczenia dostępu do zasobów klastra
• •Skanuj obrazy kontenerów pod kątem podatności (Trivy, Snyk, Azure Defender)

Niezawodność i dostępność

• •Minimum 2 repliki dla production services – zapewnia high availability podczas aktualizacji
• •Definiuj PodDisruptionBudgets – gwarantuje minimalną liczbę działających replik podczas konserwacji
• •Implementuj liveness i readiness probes – automatyczne wykrywanie i restart niezdrow ych Podów
• •Używaj anti-affinity rules – rozprasza repliki po różnych węzłach dla lepszej odporności

Observability i monitoring

• •Setup monitoring od pierwszego dnia – Prometheus, Grafana, lub managed solutions (Azure Monitor, AWS CloudWatch)
• •Centralizuj logi używając ELK Stack, Loki, lub cloud-native logging
• •Implementuj distributed tracing (Jaeger, Zipkin) dla microservices
• •Konfiguruj alerty dla krytycznych metryk (CPU, RAM, błędy, latency)

Zarządzanie konfiguracją

• •Używaj Namespaces do separacji środowisk (dev, staging, prod)
• •Version control dla manifestów – trzymaj wszystkie YAML-e w Git
• •Używaj Helm lub Kustomize dla zarządzania konfiguracją multi-environment
• •Semantic versioning dla images – używaj v1.2.3 zamiast :latest

1. Brak resource limits → OOM kills i downtime

Jeśli nie ustawisz CPU/RAM limits, Pod może zjeść wszystkie zasoby node'a. Kubernetes zabije (OOMKilled) inne Pody, powodując downtime.

containers:
- name: app
  image: my-app:v1
  # Brak resources!

containers:
- name: app
  image: my-app:v1
  resources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: 500m
      memory: 512Mi

2. Secrets w plaintext w Git → security breach

Kubernetes Secrets są base64-encoded, NIE encrypted. Commitowanie Secrets do Git to security risk.

3. Brak health checks → crashujące Pody obsługują ruch

Bez liveness/readiness probes, Kubernetes nie wie, czy Pod jest healthy. Crashujący Pod dalej dostaje traffic → 500 errors dla użytkowników.

livenessProbe:  # Restart jeśli endpoint failuje
  httpGet:
    path: /health
    port: 3000
  initialDelaySeconds: 30
  periodSeconds: 10
readinessProbe:  # Nie kieruj traffic jeśli nie ready
  httpGet:
    path: /ready
    port: 3000
  initialDelaySeconds: 10
  periodSeconds: 5

4. :latest image tag → unpredictable deployments

image: my-app:latest może oznaczać różne wersje na różnych nodach. Rollback jest niemożliwy.

5. Single replica dla critical services → downtime podczas update

replicas: 1 oznacza, że podczas rolling update jest moment, gdy Pod jest offline.

6. Brak monitoring → blind deployments

Deploy nowej wersji bez monitoring = nie wiesz, czy działa. Błędy wykrywa dopiero user.

Oficjalna dokumentacja

• Kubernetes Documentation – Najbardziej aktualna i kompletna dokumentacja
• kubectl Cheat Sheet – Wszystkie najważniejsze komendy w jednym miejscu
• Official Tutorials – Hands-on exercises od podstaw do zaawansowanych

CNCF Resources

• Certified Kubernetes Administrator (CKA) – Oficjalny certyfikat, potwierdzenie umiejętności
• CNCF Landscape – Mapa ekosystemu cloud native (500+ narzędzi)
• CNCF Blog – Case studies, best practices, nowości

Interactive Learning

• Katacoda Kubernetes Scenarios – Interactive browser-based labs
• Killer Coda – Free Kubernetes playground (successor to Katacoda)
• Instruqt Labs – Advanced hands-on labs

Books & Courses

• Kubernetes Up & Running (Brendan Burns, Kelsey Hightower) – Best book dla beginners
• Kubernetes Patterns (Bilgin Ibryam) – Design patterns dla K8s apps
• Kubernetes in Action (Marko Lukša) – Deep dive, 800+ stron