Kubernetes-arkitektur: det du behöver förstå

Control plane

Control plane är klustrets hjärna och består av:

I managed Kubernetes (EKS, AKS, GKE) driftar molnleverantören control plane åt dig. Det innebär att du slipper patcha etcd och hantera apiserver-certifikat — men du behöver fortfarande förstå hur schedulern placerar arbetsbelastningar och hur RBAC konfigureras.

Worker nodes

Varje worker node kör tre centrala processer:

• kubelet — agenten som tar emot pod-specifikationer och säkerställer att containrar körs
• kube-proxy — hanterar nätverksregler för Service-objekt
• Container runtime — containerd är standard sedan K8s 1.24 (Dockershim borttagen)

Pods, Deployments och Services

En pod är den minsta driftsättningsbara enheten — en eller flera containrar som delar nätverks-namespace och lagring. I praktiken kör du sällan nakna pods. Istället använder du:

• Deployment för stateless-applikationer med rolling updates
• StatefulSet för databaser och andra stateful-tjänster som kräver stabil nätverksidentitet
• DaemonSet för agenter som ska köras på varje nod (loggsamlare, nodövervakare)
• Service (ClusterIP, NodePort, LoadBalancer) för att exponera applikationer
• Ingress (eller Gateway API sedan K8s 1.29+) för HTTP/HTTPS-routing

Driftsättning med GitOps: vad som fungerar i produktion

Den manuella kubectl apply-metoden fungerar för experiment. I produktion ser vi GitOps som den överlägset mest robusta modellen — och det är vad vi rekommenderar alla Opsio-kunder.

Så fungerar GitOps i praktiken

1. All Kubernetes-konfiguration (manifester, Helm charts, Kustomize-overlays) versionshanteras i Git

2. En GitOps-operator (Argo CD eller Flux) övervakar repot

3. Vid push till main-branchen synkar operatorn automatiskt klustrets tillstånd

4. Drift detekteras och korrigeras — klustret konvergerar alltid mot det som finns i Git

Fördelarna är konkreta: full revisionslogg (vem ändrade vad, när), enkel rollback (git revert), och möjlighet att återskapa hela miljön från ett repo. Det sistnämnda är avgörande vid incidenthantering enligt NIS2-direktivets krav på spårbarhet.

Managerad DevOps

CI/CD-pipeline för Kubernetes

En typisk pipeline vi sätter upp:

```

Kod-push → Bygg container-image → Sårbarhetsskanning (Trivy/Grype)

→ Push till container-registry → Uppdatera manifest i GitOps-repo

→ Argo CD synkar till kluster → Smoke-test → Produktionstrafik

```

Image-scanning i pipeline-steget är inte valfritt. Vi ser regelbundet CVE:er med CVSS 9+ i basimages som inte uppdaterats på några månader. Automatiserad scanning stoppar det innan det når produktion.

Säkerhet: det Kubernetes inte gör åt dig

Kubernetes default-konfiguration är öppen. Utan aktiva åtgärder kan vilken pod som helst prata med vilken annan pod, och containrar kan köras som root. Det är oacceptabelt i produktion — särskilt under NIS2-direktivet som ställer explicita krav på riskbaserade säkerhetsåtgärder.

Säkerhetslager vi implementerar hos alla kunder

1. RBAC (Role-Based Access Control)

Principen om minsta privilegium. Varje team, CI/CD-pipeline och serviceaccount får exakt de rättigheter de behöver — inte mer. ClusterRoleBindings ska vara ytterst sällsynta.

2. Nätverkspolicyer

Kubernetes NetworkPolicy (eller Cilium Network Policy för mer avancerade behov) fungerar som brandväggsregler mellan pods. Default-deny som utgångspunkt, sedan explicit tillåtna flöden.

3. Pod Security Standards

Sedan K8s 1.25 finns tre inbyggda profiler: Privileged, Baseline och Restricted. Vi kör Restricted som standard och gör undantag enbart där det krävs (t.ex. för monitoring-agenter som behöver hostNetwork).

4. Secrets-hantering

Kubernetes Secrets är base64-kodade, inte krypterade. Använd external-secrets-operator med AWS Secrets Manager, Azure Key Vault eller HashiCorp Vault. Kryptera etcd at rest.

5. Image-policy

Tillåt enbart images från era egna registries. Verktyg som Kyverno eller OPA Gatekeeper kan enforca policy direkt i admission-steget.

Molnsäkerhet

Kostnad och FinOps: där de flesta Kubernetes-projekt spårar ur

Flexeras State of the Cloud har konsekvent visat att kostnadshantering är den främsta utmaningen för molnanvändande organisationer. Kubernetes gör problemet mer komplext — kostnaden sitter inte i enstaka VM:ar utan är utspridd över noder, persistent storage, load balancers och inter-AZ-trafik.

Vanliga kostnadsfällor

Överprovisioning av resurser. Utvecklare sätter generösa CPU/minne-requests "för säkerhets skull". Resultatet: noder som är 20 % belagda men debiteras till 100 %. Vi ser det i nästan varje ny K8s-miljö vi tar över.

Avsaknad av autoscaling. Kluster med fast antal noder, dimensionerade för peak-trafik, betalar för kapacitet de inte behöver 80 % av tiden. Horizontal Pod Autoscaler (HPA) och Cluster Autoscaler (eller Karpenter på EKS) är grundläggande verktyg.

Inter-AZ-trafik. I eu-north-1 (Stockholm) kostar trafik mellan tillgänglighetszoner per GB. Topology-aware routing (sedan K8s 1.27 stabil) minskar kostnaden genom att hålla trafiken inom samma zon där det är möjligt.

Persistent Volume-överprovisioning. EBS-volymer (gp3) eller Azure Managed Disks som allokeras men aldrig fylls. Övervaka med Prometheus-mätvärden och skala ner.

Praktisk FinOps-strategi

1. Sätt resurslimiter från dag ett — requests och limits på varje pod, inga undantag

2. Inför namespace-kvotor — ResourceQuota per team/miljö förhindrar att ett team svälter andra

3. Kör Kubecost eller OpenCost — tillskrivning av kostnad per namespace/team/label

4. Aktivera Cluster Autoscaler / Karpenter — automatisk nod-skalning

5. Granska Spot/Preemptible-noder — för fault-toleranta arbetsbelastningar kan kostnaden sjunka med 60–70 %

Cloud FinOps

Managed Kubernetes vs. egen drift

Vår rekommendation: kör managed Kubernetes om ni inte har starka skäl att inte göra det. De starka skälen är vanligtvis regulatoriska krav på full kontroll över control plane (sällsynt) eller edge-scenarier utan molnanslutning.

Managerade molntjänster

Observerbarhet: tre pelare i K8s-miljön

Utan observerbarhet flyger du blint. I Kubernetes kräver det en genomtänkt stack:

Mätvärden: Prometheus + Grafana är de facto-standard. Scrapa kubelet-metrics, node-exporter, kube-state-metrics. Sätt alerts på pod-restart-loopar, nod-resursbrist och control plane-latens.

Loggar: Centraliserad loggning med Fluent Bit (DaemonSet) → OpenSearch/Elasticsearch eller Grafana Loki. Strukturerad JSON-loggning i applikationerna förenklar sökning enormt.

Spårning: Distribuerad tracing med OpenTelemetry → Grafana Tempo eller Jaeger. Nödvändigt för att felsöka latens i mikrotjänstarkitekturer.

Datadog State of Cloud rapporterar konsekvent att organisationer med containerbaserade miljöer hanterar betydligt fler infrastrukturkomponenter per ingenjör — det gör observerbarhet till en grundförutsättning, inte ett nice-to-have.

Kubernetes-migrering: steg för steg

Om ni står inför en migrering till Kubernetes rekommenderar vi den här ordningen:

1. Containerisera — Dockerfiler, multi-stage builds, minimal basimage (distroless eller Alpine)

2. Kör lokalt — Validera med kind eller minikube

3. Sätt upp kluster — Managed K8s i eu-north-1 eller Sweden Central

4. Börja med en stateless-tjänst — Webblager eller API, inte databasen

5. Implementera CI/CD + GitOps — Argo CD, image-scanning i pipeline

6. Lägg till observerbarhet — Prometheus, Grafana, Fluent Bit

7. Härdning — RBAC, nätverkspolicyer, Pod Security Standards

8. Migrera fler tjänster — successivt, med traffic shifting (canary/blue-green)

9. Stateful-tjänster sist — databaser med StatefulSet och PersistentVolumeClaims

Molnmigrering

Opsios perspektiv: vad vi ser i produktion

Från vårt SOC/NOC i Karlstad och Bangalore hanterar vi Kubernetes-kluster dygnet runt. De vanligaste incidenterna vi ser:

• OOMKill-loopar — containrar som inte har minnesslimiter och äter upp nodens RAM. Lösning: korrekta requests/limits och HPA.
• Certifikat som löper ut — cert-manager löser det, men bara om den är korrekt konfigurerad med ClusterIssuer och automatisk förnyelse.
• etcd-prestandaproblem — oftast på managed-kluster med för många custom resources. Rensa oanvända CRDs och operator-installationer.
• Ingress-felkonfigurering — TLS-terminering, CORS-headers och rate limiting som inte fungerar som förväntat. Testa ingress-konfigurationen med automatiserade integrationstester.

Vi förespråkar inte Kubernetes som lösning på alla problem. För enklare applikationer kan AWS ECS/Fargate, Azure Container Apps eller till och med en välkonfigurerad VM-baserad setup vara rätt svar. Kubernetes lönar sig när ni har minst 10–15 mikrotjänster, behöver multi-cloud-portabilitet, eller kräver den flexibilitet som K8s ekosystem ger.

Vanliga frågor

Vad är skillnaden mellan Kubernetes och Docker?

Docker bygger och kör enskilda containrar. Kubernetes orkestrerar hundratals eller tusentals containrar över ett kluster — det hanterar skalning, lastbalansering, självläkning och utrullningar. Docker är motorkomponenten, Kubernetes är trafikledningssystemet.

Ska vi köra managed Kubernetes eller bygga eget kluster?

För de allra flesta organisationer är managed Kubernetes (EKS, AKS eller GKE) rätt val. Det eliminerar ansvaret för control plane-drift och ger snabbare säkerhetspatchar. Bygg eget bara om ni har ett dedikerat plattformsteam på minst 3–5 SRE:er och specifika krav på kontroll.

Hur hanterar vi Kubernetes-säkerhet enligt NIS2?

NIS2 kräver riskbaserade säkerhetsåtgärder och incidentrapportering. I Kubernetes innebär det RBAC, nätverkspolicyer, Pod Security Standards, krypterade secrets, image-scanning i CI/CD-pipelinen och centraliserad loggning med åtminstone 90 dagars retention.

Vad kostar Kubernetes i produktion?

Control plane-avgiften på managed-tjänster är försumbar (ca 500–700 SEK/månad). Den verkliga kostnaden sitter i worker nodes, lagring och nätverkstrafik. Utan resurslimiter och autoscaling ser vi typiskt 30–50 % överprovisioning hos nya Kubernetes-användare.

Hur lång tid tar det att migrera till Kubernetes?

En enskild stateless-applikation kan containeriseras och köras på K8s inom dagar. En hel applikationsportfölj med stateful-tjänster, CI/CD-integration och säkerhetshärdning tar typiskt 3–6 månader med ett erfaret team.