Kubernetes i produktion: Lärdomar från verkligheten

Kubernetes i en tutorial ser elegant ut. Kubernetes i produktion klockan tre på natten när pods kraschar i en loop — det är en annan upplevelse. Den här artikeln delar de lärdomar som skiljer en stabil K8s-miljö från en som genererar PagerDuty-alerts varje vecka.

Resource requests och limits — viktigare än du tror

Det vanligaste misstaget: att inte sätta resource requests och limits. Utan dem schemalägger Kubernetes pods utan att veta hur mycket CPU och RAM de behöver. Resultatet är att noder överbokas, pods evictas slumpmässigt och din applikation blir instabil.

# Deployment med korrekta resource limits
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: api-server:v2.1.0
        resources:
          requests:
            cpu: "250m"      # Garanterad CPU
            memory: "256Mi"  # Garanterat minne
          limits:
            cpu: "500m"      # Max CPU
            memory: "512Mi"  # Max minne (OOMKill)
        # Requests = vad schedulern reserverar
        # Limits = max användning innan throttling/kill

Tumregel: Sätt requests till vad din app normalt använder och limits till vad den behöver vid peak. Övervaka med kubectl top pods och justera efter verklig data, inte gissningar.

Health checks: Liveness vs Readiness

Liveness probes kontrollerar om containern lever — om den misslyckas startas containern om. Readiness probes kontrollerar om containern kan ta emot trafik — om den misslyckas tas pod:en bort från service-endpoints.

Vanligt misstag: att använda samma endpoint för båda. Om din app är överbelastad och svarar långsamt vill du att readiness-proben misslyckas (stoppa ny trafik) men att liveness-proben lyckas (starta inte om — det hjälper inte).

# Separata probes med olika logik
containers:
- name: api
  ports:
  - containerPort: 3000
  livenessProbe:
    httpGet:
      path: /healthz        # Grundläggande: lever processen?
      port: 3000
    initialDelaySeconds: 15
    periodSeconds: 20
    failureThreshold: 3
  readinessProbe:
    httpGet:
      path: /ready           # Djupare: kan jag ta emot trafik?
      port: 3000
    initialDelaySeconds: 5
    periodSeconds: 10
    failureThreshold: 2
  startupProbe:
    httpGet:
      path: /healthz
      port: 3000
    failureThreshold: 30    # 30 * 10s = 5 min för uppstart
    periodSeconds: 10

Horizontal Pod Autoscaler

HPA skalas automatiskt baserat på CPU, minne eller anpassade metriker. Men den behöver korrekt konfigurerade resource requests för att fungera — utan dem vet den inte vad 80% CPU-användning innebär.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-server-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 3
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60
      policies:
      - type: Pods
        value: 4          # Max 4 nya pods per 60s
        periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300  # 5 min innan nedskalning
      policies:
      - type: Percent
        value: 25         # Max 25% nedskalning per 5 min
        periodSeconds: 300

Pod Disruption Budgets

Vid noduppgraderingar och kluster-underhåll evictar Kubernetes pods. Utan PDB (Pod Disruption Budget) kan alla dina replicas evictas samtidigt — resultat: nertid.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-server-pdb
spec:
  minAvailable: 2    # Alltid minst 2 pods körande
  selector:
    matchLabels:
      app: api-server

Managed vs self-managed Kubernetes

Kör inte Kubernetes själv om du inte har ett dedikerat plattformsteam. Managed tjänster som EKS (AWS), AKS (Azure) och GKE (Google) hanterar control plane, uppgraderingar och integrationer med molnleverantörens ekosystem.

GKE har generellt den bästa Kubernetes-upplevelsen (Google skapade K8s). EKS är mest populärt bland AWS-kunder. AKS integrerar bäst med Azure AD och Microsoft-verktyg.

Läs vår grundläggande Kubernetes-guide för att komma igång, eller vår DevOps-guide för det bredare perspektivet.