Kubernetes i produktion: mer än kubectl apply

Kubernetes har vunnit orkestreringsmarknaden. Enligt CNCFs årliga undersökningar har Kubernetes-adoption i produktion ökat stadigt, och alternativ som Docker Swarm eller Nomad används i en bråkdel av fallen. Men adoption betyder inte mognad.

Managerad kontra självhostad Kubernetes

Det första strategiska valet är om ni ska driva egna kluster eller använda en managerad tjänst. Svaret för de allra flesta svenska organisationer är managerad – och det gäller även tekniskt avancerade team.

AWS EKS i eu-north-1 (Stockholm) ger låg latens för nordisk trafik och integrerar med IAM, ALB och CloudWatch. Kontrollplanet kostar runt 70 USD/månad, men den verkliga kostnaden ligger i EC2-noder. Med Karpenter som nod-autoscaler får ni snabb och kostnadseffektiv skalning.

Azure AKS i Sweden Central erbjuder gratis kontrollplan och tight integration med Entra ID (fd Azure AD) och Azure Policy. För organisationer som redan lever i Microsoft-ekosystemet är AKS ofta det naturliga valet – särskilt med Azure Arc för hybridscenarier.

Google GKE har den mest mogna Kubernetes-implementationen (Google skapade trots allt Kubernetes). GKE Autopilot tar bort nodhantering helt och debiterar per pod. Nackdelen är att Google inte har en svensk region – närmaste är Finland (europe-north1).

Managerade molntjänster

Klusterarkitektur och namnrymder

Ett vanligt misstag är att skapa ett enda stort kluster för allt. I praktiken rekommenderar vi separata kluster för produktion och icke-produktion, med namnrymder (namespaces) för att isolera team och tjänster inom varje kluster. Varje namespace bör ha definierade ResourceQuotas och LimitRanges – annars äter en enskild tjänst upp all tillgänglig compute.

Network policies är inte valfritt. Utan dem kan varje pod prata med varje annan pod i klustret. Calico eller Cilium ger L3/L4-nätverkspolicyer; Cilium erbjuder dessutom L7-medvetenhet och eBPF-baserad observabilitet som vi ser allt fler driftteam uppskatta.

Säkerhet i containerkedjan – från build till runtime

Containersäkerhet är inte en punkt i en checklista utan en kedja av kontroller. Vi på Opsio ser regelbundet organisationer som har skanning i CI/CD men ingen runtime-skydd, eller tvärtom. Båda behövs.

Build-fas: images som grund

Börja med en minimal basimage. alpine eller distroless-images från Google reducerar angreppsytan dramatiskt jämfört med fullständiga OS-images. Varje Dockerfile bör:

• Använda specifika versionstaggar, aldrig :latest
• Köra applikationen som non-root-användare
• Använda multi-stage builds för att exkludera build-verktyg från produktionsimagen
• Skanna med verktyg som Trivy, Grype eller Snyk Container i CI/CD-pipelinen

Image-signering med Cosign och Sigstore skapar ett verifierbart bevis på att en image inte har manipulerats mellan build och deploy. I en NIS2-kontext är detta typ av supply chain-verifiering inte bara bra praxis – det hjälper er uppfylla kraven på dokumenterad leveranskedjeintegritet.

Runtime-fas: skydd i produktion

Pod Security Standards (PSS) i Kubernetes ersätter de föråldrade Pod Security Policies. Konfigureras på namespacenivå med tre profiler: Privileged, Baseline och Restricted. Vi rekommenderar Restricted som standard och Baseline som undantag med dokumenterad motivering.

Falco, det CNCF-graduerade runtime-säkerhetsverktyget, övervakar syscalls och kan detektera avvikande beteende – en container som plötsligt kör en shell, läser /etc/shadow eller initierar en utgående anslutning till en okänd IP.

Molnsäkerhet

Secrets management

Kubernetes Secrets är base64-kodade, inte krypterade. Använd en extern secrets-motor: AWS Secrets Manager, Azure Key Vault eller HashiCorp Vault. Med External Secrets Operator synkroniseras hemligheter automatiskt till Kubernetes utan att klartextvärden hamnar i Git.

Observabilitet: loggar, mätvärden och traces

Containrar är efemära. En pod kan leva i minuter, och loggar försvinner när den termineras. Utan centraliserad observabilitet flyger ni blinda.

De tre pelarna

Mätvärden: Prometheus med Grafana är branschstandard. Kube-state-metrics exponerar klusterstatus, medan node-exporter ger infrastrukturmätvärden. Managed-alternativ som Amazon Managed Prometheus eller Azure Monitor Container Insights minskar driftbördan.

Loggar: Fluent Bit som DaemonSet samlar loggar från varje nod och skickar till OpenSearch, Loki eller CloudWatch. Strukturerade loggar i JSON-format är ett absolut krav – grep-vänliga textloggar skalar inte.

Traces: OpenTelemetry har blivit standarden för distribuerad tracing. Instrumentera applikationerna med OpenTelemetry SDK och skicka traces till Jaeger, Tempo eller en kommersiell lösning. Utan traces blir det i princip omöjligt att felsöka latens i en mikrotjänstarkitektur.

Från Opsios NOC-perspektiv: det som avgör om vi kan lösa en incident på fem minuter eller fem timmar är nästan alltid kvaliteten på observabiliteten. Investera här.

Managerad DevOps

FinOps för containrar: sluta slösa på överallokerade pods

Flexeras State of the Cloud-rapport har konsekvent visat att kostnadsoptimering är den enskilt största utmaningen för molnanvändare. Containrar gör problemet granulärare men inte enklare.

Requests och limits – den dolda kostnadsdrivaren

I Kubernetes definierar varje pod sina CPU/minnes-requests (garanterad resurs) och limits (maxtak). Problemet: utvecklare sätter ofta höga requests "för säkerhets skull", vilket innebär att klustret allokerar resurser som aldrig används.

Vi mäter regelbundet klustre hos kunder och ser typiskt 30–40 % överallokering. Verktyg som Kubecost, OpenCost (CNCF-sandbox) eller de inbyggda rekommendationerna i GKE ger insyn i faktisk förbrukning kontra allokering.

Praktisk åtgärd: Inför Vertical Pod Autoscaler (VPA) i rekommendationsläge först. Låt den samla data i två veckor, granska förslagen, och applicera sedan gradvis. Kombinera med Horizontal Pod Autoscaler (HPA) baserad på verklig CPU/minnes-last eller anpassade mätvärden.

Spot-instanser och nod-pooler

Kör icke-kritiska arbetsbelastningar (batch-jobb, dev/test, CI-runners) på spot-instanser. AWS Spot i eu-north-1 ger typiskt 60–70 % rabatt jämfört med on-demand. Karpenter i EKS eller AKS node auto-provisioning kan automatiskt välja billigaste instanstyp som uppfyller podens resurskrav.

Separera nod-pooler: en stabil on-demand-pool för produktion, en spot-pool för allt annat. Taint och toleration i Kubernetes styr vilka pods som hamnar var.

Cloud FinOps

CI/CD och GitOps: leveranskedjan för containrar

En containeriserad applikation utan automatiserad pipeline är som en Formel 1-bil utan pit crew. Manuella builds och deploys skapar flaskhalsar och ökar risken för mänskliga fel.

GitOps med Argo CD eller Flux

GitOps-modellen innebär att Kubernetes-klustrets önskade tillstånd definieras deklarativt i Git. En GitOps-kontroller (Argo CD eller Flux) övervakar repot och reconcilierar automatiskt eventuella avvikelser. Fördelen: full revisionslogg, enkel rollback (git revert), och inga direkta kubectl-ändringar i produktion.

Argo CD har blivit det populäraste valet enligt CNCFs undersökningar och erbjuder ett visuellt gränssnitt som driftteam uppskattar. Flux är lättare och passar bättre för rent CLI-baserade arbetsflöden.

Pipeline-steg vi rekommenderar

1. Lint och test – enhetstester, Helm lint, Kubernetes manifest-validering med kubeconform

2. Build – multi-stage Docker build med caching

3. Scan – Trivy/Grype för CVE:er, Checkov/Kics för IaC-misconfigurations

4. Push – till privat container-register (ECR, ACR, Artifact Registry) med image-signering

5. Deploy – GitOps-kontroller plockar upp ny image-tag och rullar ut med progressiv strategi

6. Verify – automatiserade smoke tests, canary-analys med Argo Rollouts eller Flagger

Molnmigrering

Containerhantering för svenska organisationer – regulatorisk kontext

NIS2 och containeriserade system

NIS2-direktivet, som trädde i kraft i EU:s medlemsstater, ställer krav på riskhantering och incidentrapportering för organisationer inom väsentliga och viktiga sektorer. För containeriserade system innebär det:

• Supply chain-säkerhet: Verifierbara images, signerade artefakter, SBOM (Software Bill of Materials) genererad i build-steget
• Incidenthantering: Centraliserade, oföränderliga loggar som möjliggör forensisk analys
• Åtkomststyrning: RBAC i Kubernetes kopplat till organisationens identitetslösning (Entra ID, Okta, etc.)

GDPR och datalokalitet

Containrar som hanterar personuppgifter måste köras på infrastruktur som uppfyller GDPR:s krav. Med eu-north-1 (Stockholm) för AWS och Sweden Central för Azure finns det inga tekniska hinder – men ni måste säkerställa att container-images inte dras från register utanför EU vid deploy, och att loggar med persondata inte hamnar i en US-region.

Integritetsskyddsmyndigheten (IMY) har visat ökad tillsynsaktivitet, och det är inte otänkbart att containeriserade system granskas specifikt – särskilt i kontext av tredjepartsberoenden och image-register.

Vanliga frågor

Vad är skillnaden mellan Docker och Kubernetes?

Docker är container-runtime och byggverktyg – det skapar och kör enskilda containrar. Kubernetes är en orkestreringsplattform som hanterar hundratals eller tusentals containrar i produktion: schemaläggning, skalning, self-healing och nätverkshantering. De kompletterar varandra; Docker bygger images, Kubernetes kör dem i skala.

Ska vi köra Kubernetes själva eller använda en managerad tjänst?

För de allra flesta organisationer är managerad Kubernetes (EKS, AKS, GKE) rätt val. Att driva egna kontrollplan kräver dedikerad SRE-kompetens som är svår att rekrytera i Sverige. Managerade tjänster hanterar uppgraderingar, etcd-backup och kontrollplans-tillgänglighet – så att ert team kan fokusera på applikationslogik.

Hur hanterar vi containersäkerhet i en NIS2-kontext?

Börja med image scanning i CI/CD (t.ex. Trivy eller Snyk Container), signera images med Cosign/Sigstore, kör med read-only root filesystem och non-root-användare, och implementera network policies i Kubernetes. NIS2 kräver dokumenterad incidenthantering och spårbarhet – container-loggar bör centraliseras med oföränderlig lagring.

Vad kostar containerhantering i molnet?

Kontrollplanet i EKS kostar cirka 70 USD/månad, i AKS är det gratis, och GKE erbjuder ett gratiskluster. Den verkliga kostnaden ligger i worker-noder (compute), lagring och nätverkstrafik. Utan FinOps-disciplin – rätt requests/limits och autoscaling – ser vi regelmässigt 30–40 % överallokering hos nya containeranvändare.

Hur kommer vi igång med containerhantering om vi kör legacy-applikationer?

Börja med att containerisera stateless-tjänster och API:er – de ger snabbast avkastning. Lyft inte monoliter rakt in i containrar utan att först identifiera vilka komponenter som kan brytas ut. En strangler fig-strategi, där ny funktionalitet byggs som mikrotjänster medan monoliten gradvis krymper, är det mönster vi ser fungera bäst i praktiken.

For hands-on delivery in India, see konsult consulting for enterprise.

For hands-on delivery in India, see gcp managed for enterprise.