Przejdź do treści
DevOps

Kubernetes - Kompletne wprowadzenie dla deweloperów

Opublikowano:
·6 min czytania·Autor: MDS Software Solutions Group
kubernetesdockerdevopscloud

Kubernetes Kompletne wprowadzenie

devops

Kubernetes - Kompletne wprowadzenie dla deweloperów

Kubernetes (w skrócie K8s) to platforma do orkiestracji kontenerów, która zrewolucjonizowała sposób wdrażania, skalowania i zarządzania aplikacjami w środowiskach produkcyjnych. Jeśli pracujesz z kontenerami Docker i zastanawiasz się, jak efektywnie zarządzać nimi na większą skalę, Kubernetes jest odpowiedzią na Twoje potrzeby.

W tym przewodniku przeprowadzimy Cię przez wszystkie kluczowe koncepcje Kubernetes - od podstawowych obiektów, przez manifesty YAML, aż po praktyczne wdrożenie aplikacji Next.js w klastrze K8s.

Dlaczego Kubernetes?#

Kiedy Twoja aplikacja działa w jednym kontenerze Docker na jednym serwerze, wszystko jest proste. Problemy zaczynają się, gdy musisz:

  • Skalować aplikację na wiele instancji w zależności od ruchu
  • Zapewnić wysoką dostępność - automatyczny restart po awarii
  • Zarządzać konfiguracją wielu mikroserwisów jednocześnie
  • Wdrażać bez przestojów - zero-downtime deployments
  • Balansować ruch między wieloma instancjami aplikacji
  • Zarządzać sekretami i konfiguracją w bezpieczny sposób

Docker Compose sprawdza się w środowiskach deweloperskich, ale w produkcji potrzebujesz czegoś mocniejszego. Kubernetes automatyzuje wszystkie te zadania i dostarcza deklaratywny model zarządzania infrastrukturą.

Architektura Kubernetes#

Zanim przejdziemy do praktyki, warto zrozumieć podstawową architekturę klastra Kubernetes:

  • Control Plane (Master) - mózg klastra, zarządzający stanem i podejmujący decyzje o schedulingu
    • API Server - centralne API do komunikacji z klastrem
    • etcd - rozproszona baza klucz-wartość przechowująca stan klastra
    • Scheduler - decyduje, na którym node uruchomić Pod
    • Controller Manager - monitoruje stan klastra i dokonuje korekt
  • Worker Nodes - maszyny, na których działają kontenery
    • kubelet - agent zarządzający Podami na danym node
    • kube-proxy - zarządza regułami sieciowymi

Podstawowe obiekty Kubernetes#

Pod - najmniejsza jednostka#

Pod to najmniejsza jednostka wdrożeniowa w Kubernetes. Może zawierać jeden lub więcej kontenerów, które współdzielą sieć i storage:

apiVersion: v1
kind: Pod
metadata:
  name: my-nextjs-app
  labels:
    app: nextjs
    environment: production
spec:
  containers:
    - name: nextjs
      image: my-registry/nextjs-app:1.0.0
      ports:
        - containerPort: 3000
      resources:
        requests:
          memory: "128Mi"
          cpu: "250m"
        limits:
          memory: "256Mi"
          cpu: "500m"
      livenessProbe:
        httpGet:
          path: /api/health
          port: 3000
        initialDelaySeconds: 10
        periodSeconds: 30
      readinessProbe:
        httpGet:
          path: /api/health
          port: 3000
        initialDelaySeconds: 5
        periodSeconds: 10

W praktyce rzadko tworzymy Pody bezpośrednio. Zamiast tego używamy kontrolerów wyższego poziomu, takich jak Deployment.

Deployment - zarządzanie replikami#

Deployment to najczęściej używany obiekt w Kubernetes. Zarządza zestawem identycznych Podów (ReplicaSet) i umożliwia deklaratywne aktualizacje:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nextjs-app
  labels:
    app: nextjs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nextjs
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: nextjs
        version: "1.0.0"
    spec:
      containers:
        - name: nextjs
          image: my-registry/nextjs-app:1.0.0
          ports:
            - containerPort: 3000
          env:
            - name: NODE_ENV
              value: "production"
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: app-secrets
                  key: database-url
          resources:
            requests:
              memory: "128Mi"
              cpu: "250m"
            limits:
              memory: "256Mi"
              cpu: "500m"

Strategia RollingUpdate z maxUnavailable: 0 gwarantuje, że podczas wdrożenia zawsze będzie dostępna wymagana liczba Podów, co zapewnia zero-downtime deployment.

Service - wewnętrzna komunikacja#

Service zapewnia stały punkt dostępu do grupy Podów. Nawet gdy Pody są tworzone i niszczone, Service zachowuje stały adres IP i DNS:

apiVersion: v1
kind: Service
metadata:
  name: nextjs-service
spec:
  type: ClusterIP
  selector:
    app: nextjs
  ports:
    - protocol: TCP
      port: 80
      targetPort: 3000

Kubernetes oferuje kilka typów Service:

  • ClusterIP (domyślny) - dostępny tylko wewnątrz klastra
  • NodePort - wystawia port na każdym node klastra
  • LoadBalancer - tworzy zewnętrzny load balancer (w chmurze)
  • ExternalName - mapuje Service na zewnętrzny DNS

Ingress - routing zewnętrznego ruchu#

Ingress to obiekt zarządzający dostępem HTTP/HTTPS z zewnątrz klastra. Umożliwia routing na podstawie hostów i ścieżek:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nextjs-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - myapp.example.com
      secretName: myapp-tls
  rules:
    - host: myapp.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: nextjs-service
                port:
                  number: 80
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 8080

Podstawy kubectl#

kubectl to główne narzędzie CLI do interakcji z klastrem Kubernetes. Oto najważniejsze komendy, które powinieneś znać:

# Informacje o klastrze
kubectl cluster-info
kubectl get nodes

# Zarządzanie Podami
kubectl get pods
kubectl get pods -o wide
kubectl describe pod <nazwa-poda>
kubectl logs <nazwa-poda>
kubectl logs -f <nazwa-poda>  # follow
kubectl exec -it <nazwa-poda> -- /bin/sh

# Zarządzanie Deployments
kubectl get deployments
kubectl rollout status deployment/nextjs-app
kubectl rollout history deployment/nextjs-app
kubectl rollout undo deployment/nextjs-app

# Aplikowanie manifestów
kubectl apply -f deployment.yaml
kubectl apply -f ./k8s/  # wszystkie pliki w katalogu
kubectl delete -f deployment.yaml

# Skalowanie
kubectl scale deployment nextjs-app --replicas=5

# Debugowanie
kubectl get events --sort-by='.lastTimestamp'
kubectl top pods
kubectl top nodes

ConfigMaps i Secrets#

ConfigMap - konfiguracja aplikacji#

ConfigMap przechowuje dane konfiguracyjne jako pary klucz-wartość. Umożliwia oddzielenie konfiguracji od obrazu kontenera:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  NEXT_PUBLIC_API_URL: "https://api.example.com"
  NEXT_PUBLIC_SITE_NAME: "My Application"
  LOG_LEVEL: "info"
  CACHE_TTL: "3600"
  nginx.conf: |
    server {
      listen 80;
      server_name localhost;
      location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
      }
    }

Secret - dane wrażliwe#

Secrets służą do przechowywania danych wrażliwych, takich jak hasła, tokeny API czy certyfikaty. Wartości są kodowane w base64:

apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
data:
  database-url: cG9zdGdyZXNxbDovL3VzZXI6cGFzc0BkYjoxNTQzMi9teWRi
  jwt-secret: c3VwZXItc2VjcmV0LWtleS0xMjM0NTY=
  redis-password: cmVkaXMtcGFzc3dvcmQtMTIz

Użycie ConfigMap i Secret w Deployment:

spec:
  containers:
    - name: nextjs
      image: my-registry/nextjs-app:1.0.0
      envFrom:
        - configMapRef:
            name: app-config
        - secretRef:
            name: app-secrets
      volumeMounts:
        - name: config-volume
          mountPath: /etc/nginx/conf.d
  volumes:
    - name: config-volume
      configMap:
        name: app-config
        items:
          - key: nginx.conf
            path: default.conf

Pamiętaj, że Secrets w Kubernetes nie są domyślnie szyfrowane - są jedynie kodowane w base64. W środowisku produkcyjnym rozważ użycie narzędzi takich jak Sealed Secrets, HashiCorp Vault lub AWS Secrets Manager.

Namespaces - izolacja zasobów#

Namespaces pozwalają na logiczną izolację zasobów w klastrze. Są szczególnie przydatne w środowiskach wielozespołowych:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    environment: production
---
apiVersion: v1
kind: Namespace
metadata:
  name: staging
  labels:
    environment: staging

Możesz ograniczyć zasoby dostępne w danym namespace za pomocą ResourceQuota:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: production-quota
  namespace: production
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    pods: "20"

Persistent Volumes - trwały storage#

Kontenery są z natury efemeryczne. Persistent Volumes (PV) i Persistent Volume Claims (PVC) pozwalają na trwałe przechowywanie danych:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-data
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: standard
  resources:
    requests:
      storage: 20Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
        - name: postgres
          image: postgres:16-alpine
          ports:
            - containerPort: 5432
          env:
            - name: POSTGRES_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: db-secrets
                  key: postgres-password
          volumeMounts:
            - name: postgres-storage
              mountPath: /var/lib/postgresql/data
      volumes:
        - name: postgres-storage
          persistentVolumeClaim:
            claimName: postgres-data

Horizontal Pod Autoscaler (HPA)#

HPA automatycznie skaluje liczbę Podów w zależności od obciążenia. Wymaga zainstalowanego Metrics Server:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nextjs-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nextjs-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60
      policies:
        - type: Pods
          value: 2
          periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Pods
          value: 1
          periodSeconds: 120

Sekcja behavior pozwala na precyzyjne kontrolowanie szybkości skalowania w górę i w dół, co zapobiega zbyt agresywnym zmianom.

Helm Charts - menedżer pakietów Kubernetes#

Helm to menedżer pakietów dla Kubernetes, który upraszcza wdrażanie złożonych aplikacji. Chart to zbiór plików opisujących powiązane zasoby Kubernetes:

# Chart.yaml
apiVersion: v2
name: nextjs-app
description: A Helm chart for Next.js application
type: application
version: 1.0.0
appVersion: "1.0.0"
dependencies:
  - name: postgresql
    version: "13.x.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: postgresql.enabled

# values.yaml
replicaCount: 3

image:
  repository: my-registry/nextjs-app
  tag: "1.0.0"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 80

ingress:
  enabled: true
  className: nginx
  hosts:
    - host: myapp.example.com
      paths:
        - path: /
          pathType: Prefix
  tls:
    - secretName: myapp-tls
      hosts:
        - myapp.example.com

resources:
  limits:
    cpu: 500m
    memory: 256Mi
  requests:
    cpu: 250m
    memory: 128Mi

autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 10
  targetCPUUtilizationPercentage: 70

postgresql:
  enabled: true
  auth:
    database: myapp
    username: myapp

Podstawowe komendy Helm:

# Instalacja chart
helm install my-release ./nextjs-chart -f values.yaml

# Aktualizacja
helm upgrade my-release ./nextjs-chart -f values.yaml

# Rollback
helm rollback my-release 1

# Lista wydań
helm list

# Usunięcie
helm uninstall my-release

Lokalne środowisko Kubernetes#

Do nauki i developmentu nie potrzebujesz klastra w chmurze. Istnieje kilka narzędzi do uruchomienia Kubernetes lokalnie:

Minikube#

Najpopularniejsze narzędzie do lokalnego Kubernetes:

# Instalacja i uruchomienie
minikube start --driver=docker --cpus=4 --memory=8192

# Dashboard
minikube dashboard

# Wystawienie serwisu
minikube service nextjs-service

# Zatrzymanie
minikube stop

Kind (Kubernetes in Docker)#

Lekka alternatywa, idealna do CI/CD:

# Utworzenie klastra
kind create cluster --name my-cluster

# Z konfiguracją wielu node'ów
kind create cluster --config kind-config.yaml

# kind-config.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
  - role: worker
  - role: worker

Docker Desktop#

Docker Desktop ma wbudowane wsparcie dla Kubernetes - wystarczy włączyć je w ustawieniach. Jest to najprostsza opcja dla deweloperów korzystających z Docker Desktop na co dzień.

Praktyczne wdrożenie aplikacji Next.js#

Połączmy wszystkie koncepcje i wdróżmy aplikację Next.js w klastrze Kubernetes. Struktura katalogów:

k8s/
  namespace.yaml
  configmap.yaml
  secret.yaml
  deployment.yaml
  service.yaml
  ingress.yaml
  hpa.yaml

Kompletny manifest wdrożeniowy:

# k8s/namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: nextjs-production
---
# k8s/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: nextjs-config
  namespace: nextjs-production
data:
  NEXT_PUBLIC_API_URL: "https://api.example.com"
  NODE_ENV: "production"
---
# k8s/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nextjs-app
  namespace: nextjs-production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nextjs
  template:
    metadata:
      labels:
        app: nextjs
    spec:
      containers:
        - name: nextjs
          image: my-registry/nextjs-app:1.0.0
          ports:
            - containerPort: 3000
          envFrom:
            - configMapRef:
                name: nextjs-config
          resources:
            requests:
              cpu: "250m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"
          livenessProbe:
            httpGet:
              path: /api/health
              port: 3000
            initialDelaySeconds: 15
            periodSeconds: 30
          readinessProbe:
            httpGet:
              path: /api/health
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 10
---
# k8s/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: nextjs-service
  namespace: nextjs-production
spec:
  type: ClusterIP
  selector:
    app: nextjs
  ports:
    - port: 80
      targetPort: 3000
---
# k8s/ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nextjs-ingress
  namespace: nextjs-production
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - myapp.example.com
      secretName: myapp-tls
  rules:
    - host: myapp.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: nextjs-service
                port:
                  number: 80

Wdrożenie jedną komendą:

kubectl apply -f k8s/

Monitoring z Prometheus i Grafana#

Monitoring jest kluczowy w środowisku produkcyjnym. Prometheus i Grafana to standard w ekosystemie Kubernetes:

# prometheus-values.yaml (Helm)
apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
data:
  prometheus.yml: |
    global:
      scrape_interval: 15s
      evaluation_interval: 15s
    scrape_configs:
      - job_name: "kubernetes-pods"
        kubernetes_sd_configs:
          - role: pod
        relabel_configs:
          - source_labels:
              - __meta_kubernetes_pod_annotation_prometheus_io_scrape
            action: keep
            regex: true
          - source_labels:
              - __meta_kubernetes_pod_annotation_prometheus_io_port
            action: replace
            target_label: __address__
            regex: (.+)

Instalacja kube-prometheus-stack za pomocą Helm:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set grafana.adminPassword=your-password

To zainstaluje Prometheus, Grafana, Alertmanager i zestaw gotowych dashboardów do monitorowania klastra.

Managed Kubernetes w chmurze#

Dla środowisk produkcyjnych najlepszym rozwiązaniem są zarządzane usługi Kubernetes od dostawców chmurowych:

Amazon EKS (Elastic Kubernetes Service)#

  • Głęboka integracja z ekosystemem AWS (ALB, RDS, S3, IAM)
  • Wsparcie dla Fargate (serverless containers)
  • Największy udział w rynku

Azure AKS (Azure Kubernetes Service)#

  • Integracja z Azure DevOps i GitHub Actions
  • Wsparcie dla Windows containers
  • Darmowy control plane

Google GKE (Google Kubernetes Engine)#

  • Twórcy Kubernetes - najbardziej zaawansowana implementacja
  • GKE Autopilot - w pełni zarządzany tryb
  • Najlepsza wydajność i najszybsze aktualizacje

Wybór platformy zależy od Twojego istniejącego ekosystemu chmurowego, wymagań biznesowych i preferencji zespołu.

Kiedy Kubernetes to przesada?#

Kubernetes to potężne narzędzie, ale nie każdy projekt go potrzebuje. K8s jest prawdopodobnie przesadą, gdy:

  • Masz prostą aplikację z jedną lub dwiema usługami
  • Niewielki ruch - kilkaset użytkowników dziennie
  • Mały zespół (1-3 osoby) bez doświadczenia z K8s
  • Budżet jest ograniczony - klaster K8s generuje dodatkowe koszty
  • Nie potrzebujesz autoskalowania - ruch jest przewidywalny i stały

W takich przypadkach lepsze mogą być:

  • Docker Compose + VPS - dla prostych aplikacji
  • Platformy PaaS - Vercel, Railway, Fly.io
  • Serverless - AWS Lambda, Azure Functions, Google Cloud Run
  • Zarządzane kontenery - AWS ECS, Azure Container Apps

Kubernetes nabiera sensu, gdy zarządzasz wieloma mikroserwisami, potrzebujesz zaawansowanego autoskalowania, masz zespół DevOps i wymagania dotyczące wysokiej dostępności.

Podsumowanie#

Kubernetes to niezbędne narzędzie w arsenale nowoczesnego dewelopera. Kluczowe wnioski z tego przewodnika:

  • Pods to podstawowa jednostka, ale używamy ich przez Deployments
  • Services i Ingress zarządzają komunikacją wewnętrzną i zewnętrzną
  • ConfigMaps i Secrets oddzielają konfigurację od kodu
  • HPA automatyzuje skalowanie w oparciu o metryki
  • Helm upraszcza zarządzanie złożonymi wdrożeniami
  • Zacznij od lokalnego klastra (minikube lub kind) przed migracją do chmury

Inwestycja w naukę Kubernetes zwraca się wielokrotnie - automatyzacja, niezawodność i skalowalność, które oferuje, są trudne do osiągnięcia innymi sposobami.

Potrzebujesz pomocy z Kubernetes?#

W MDS Software Solutions Group pomagamy firmom we wdrażaniu i zarządzaniu infrastrukturą Kubernetes. Oferujemy:

  • Projektowanie architektury klastra K8s
  • Migrację aplikacji do Kubernetes
  • Konfigurację CI/CD z automatycznym deploymentem
  • Monitoring i alerting (Prometheus, Grafana)
  • Optymalizację kosztów infrastruktury chmurowej
  • Szkolenia Kubernetes dla zespołów deweloperskich

Skontaktuj się z nami, aby omówić Twój projekt i potrzeby infrastrukturalne!

Autor
MDS Software Solutions Group

Zespół ekspertów programistycznych specjalizujących się w nowoczesnych technologiach webowych.

← Powrót do wiedzy
Kubernetes - Kompletne wprowadzenie dla deweloperów | MDS Software Solutions Group | MDS Software Solutions Group