Managed Kubernetes kontra självhostat: vad väljer svenska företag?

För svenska företag med datalokaliseringskrav (GDPR, eventuell sektorsreglering) är Stockholm-regionerna i AWS och Azure det naturliga valet. Google Clouds närmaste region ligger i Finland, vilket fortfarande är inom EU men kan vara relevant om ni har krav på data inom Sveriges gränser.

Opsios rekommendation: Managed Kubernetes är nästan alltid rätt val om ni inte har extremt specifika krav. Men "managed" betyder inte "hands-off". Ni slipper sköta etcd-backup och API-serverns tillgänglighet – men allt från nätverkspolicyer till pod security standards är fortfarande ert ansvar. Managerade molntjänster

Klusterarkitektur: vad vi rekommenderar i produktion

Separera miljöer – men inte med bara namespaces

Ett vanligt misstag är att köra utveckling, staging och produktion i samma kluster och separera med namespaces. Det fungerar för kostnadsoptimering i tidiga skeden men ger svag isolering. En minnesläcka i en dev-pod kan påverka produktionspoddar på samma nod.

Vår rekommendation:

• Produktion: Eget kluster med dedikerade nodpooler, strikt RBAC och nätverkspolicyer
• Staging: Eget kluster som speglar produktionens konfiguration (annars testar ni inte det ni faktiskt kör)
• Utveckling: Kan vara ett gemensamt kluster med namespace-isolering och resource quotas – kostnaden motiverar sällan ett tredje kluster

Noder och skalning

Kör minst tre noder i produktionsklustret, spridda över availability zones. Använd Cluster Autoscaler (eller Karpenter på EKS) för att skala nodpoolen baserat på faktisk scheduling-efterfrågan.

På pod-nivå:

• Horizontal Pod Autoscaler (HPA) – skalar antal replikor baserat på CPU, minne eller anpassade metriker (t.ex. requests per second via Prometheus)
• Vertical Pod Autoscaler (VPA) – justerar resource requests/limits. Kör den i rekommendationsläge först – VPA i auto-läge startar om poddar, vilket kan överraska

En vanlig fälla: HPA och VPA i kombination på samma deployment kan skapa oscillering. Använd HPA för skalning och VPA-rekommendationer för att justera baslinjen manuellt.

GitOps: den operativa modell som faktiskt fungerar

GitOps innebär att hela klustrets önskade tillstånd definieras i Git-repon och att ett verktyg (Argo CD eller Flux) kontinuerligt säkerställer att klustret matchar det tillståndet.

Varför detta är överlägset manuell kubectl apply:

1. Spårbarhet – varje förändring är en commit med författare, tidsstämpel och granskare

2. Rollback – git revert återställer klustret till föregående tillstånd

3. Revisionssäkerhet – NIS2 och SOC 2 kräver att ni kan visa vem som ändrade vad och när. Git-historiken ger det gratis

4. Konsistens – inga konfigurationsavvikelser (drift) mellan det ni tror körs och det som faktiskt körs

Praktisk GitOps-struktur

```

├── clusters/

│ ├── production/

│ │ ├── kustomization.yaml

│ │ ├── namespaces/

│ │ ├── network-policies/

│ │ └── apps/

│ └── staging/

│ └── ...

├── base/

│ ├── app-a/

│ │ ├── deployment.yaml

│ │ ├── service.yaml

│ │ └── hpa.yaml

│ └── app-b/

└── infrastructure/

├── cert-manager/

├── ingress-nginx/

└── monitoring/

```

Separera applikationskonfiguration från infrastrukturkomponenter. Använd Kustomize-overlays eller Helm values per miljö. Opsio hjälper kunder att sätta upp denna struktur som del av vår managerade DevOps-tjänst.

Säkerhet i Kubernetes-drift: vad NIS2 kräver i praktiken

NIS2-direktivet, som trädde i kraft i EU under 2024 och implementeras nationellt, klassar många svenska organisationer som "väsentliga" eller "viktiga" entiteter. Om ni kör affärskritiska applikationer i Kubernetes behöver ni behandla klustret som kritisk infrastruktur.

Konkreta säkerhetsåtgärder

RBAC (Role-Based Access Control)

• Inga cluster-admin-bindningar utanför break-glass-konton
• Använd Role/RoleBinding per namespace, inte ClusterRole/ClusterRoleBinding
• Integrera mot er IdP (Azure AD, Okta, AWS IAM) – inga statiska tokens

Nätverkspolicyer

• Default deny ingress och egress per namespace
• Öppna explicit bara de flöden som behövs
• Calico eller Cilium ger mer avancerade policyer än den inbyggda nätverksmodellen

Pod Security Standards

• Använd Kubernetes inbyggda Pod Security Admission (PSA) med restricted-profilen i produktion
• Blockera privilegierade containrar, root-användare och hostNetwork

Supply chain-säkerhet

• Signera container-images med Cosign/Sigstore
• Kör sårbarhetsskanning (Trivy, Grype) i CI-pipelinen – blockera deploys med kritiska CVE:er
• Använd en policy engine (Kyverno eller OPA Gatekeeper) för att tvinga fram att bara signerade images deployas

Loggning och audit

• Aktivera Kubernetes audit logging på API-servern
• Samla loggar centralt (OpenSearch, Loki, eller molnleverantörens lösning)
• Sätt retention till minst 12 månader – NIS2 och branschregelverk förväntar sig det

Molnsäkerhet

FinOps för Kubernetes: sluta betala för tomma poddar

Flexeras State of the Cloud-rapport har konsekvent visat att kostnadshantering är den största utmaningen för molnorganisationer. Kubernetes gör det lättare att skala – men också lättare att slösa.

Var pengarna försvinner

• Överproviserade resource requests – Utvecklare sätter 2 CPU och 4 Gi minne "för säkerhets skull". Podden använder 0,1 CPU och 200 Mi.
• Tomma dev/test-kluster – kluster som snurrar dygnet runt men bara används kontorstid
• Persistent volumes som blivit kvar – volymer som inte rensas efter att poddar tas bort
• Overprovisioned node instances – m5.2xlarge där m5.large hade räckt

Åtgärder som ger omedelbar effekt

1. Inför resource requests och limits på alla deployments – det är grunden för att Kubernetes scheduler ska packa poddar effektivt

2. Kör VPA i rekommendationsläge och justera requests kvartalsvis

3. Schemalägg nedstängning av icke-produktionskluster – Karpenter/Cluster Autoscaler kan skala ner till noll noder utanför arbetstid

4. Använd Spot/Preemptible instances för stateless workloads och batchjobb – besparingen ligger typiskt på 60–80 procent jämfört med on-demand

5. Mät faktisk kostnad per team/tjänst med Kubecost eller OpenCost – synlighet förändrar beteende

Cloud FinOps

Observabilitet: de tre pelarna i K8s-drift

Observabilitet i Kubernetes vilar på tre pelare – och ingen av dem är förhandlingsbar i produktion.

Metriker

Prometheus är de facto-standarden. Kör Prometheus Operator med ServiceMonitors för att automatisera scraping. Visualisera i Grafana. Alerta på SLI:er (latens, felfrekvens, throughput) snarare än infrastrukturmetriker.

Loggar

Samla containerloggar centralt. Populära stackar: Loki + Promtail (lättviktigt), OpenSearch (fulltextsökning), eller molnleverantörens lösning (CloudWatch, Azure Monitor). Strukturerad loggning i JSON från applikationen sparar timmar vid felsökning.

Traces

Distribuerade traces (OpenTelemetry → Jaeger/Tempo) visar exakt var latensen sitter i en kedja av mikrotjänster. Utan traces blir felsökning i en miljö med 20+ tjänster en gissningslek.

Vad Opsios SOC ser: De flesta incidenter som eskaleras till oss handlar om saknade eller missvisande alerts. Antingen alertar systemet på allt (alert fatigue) eller ingenting. Vi rekommenderar att definiera SLO:er (Service Level Objectives) och alerta på error budget burn rate – då får ni meningsfulla signaler.

Migreringsvägen: från VM till Kubernetes

Många svenska organisationer kör fortfarande arbetsbelastningar på virtuella maskiner. Migreringsvägen till Kubernetes är sällan en big bang.

Fas 1: Containerisera – Paketera applikationer i Docker-images. Börja med stateless tjänster.

Fas 2: Kör i Kubernetes utan att ändra arkitektur – Samma applikation, nu i en pod. Ni får redan nytta av deklarativ konfiguration och automatisk omstart.

Fas 3: Bryt ut mikrotjänster gradvis – Extrahera komponenter en i taget. Strangler fig pattern fungerar väl.

Fas 4: Plattformsmaturity – GitOps, fullständig observabilitet, automatiserad skalning, FinOps.

Försök inte ta alla steg samtidigt. Vi har sett organisationer som hoppar direkt till service mesh (Istio) innan de ens har fungerande hälsokontroller – det skapar mer komplexitet än nytta. Molnmigrering

Vanliga misstag vi ser i produktion

Så arbetar Opsio med Kubernetes-drift

Vårt SOC/NOC i Karlstad och Bangalore övervakar kunders Kubernetes-kluster dygnet runt. Praktiskt innebär det:

• Proaktiv uppgradering – vi planerar och genomför K8s-versionsuppgraderingar innan end-of-life
• Incidentrespons – alerting via Prometheus/Alertmanager → PagerDuty → Opsio on-call. Medelresponstid under 10 minuter nattetid
• Säkerhetsgranskningar – kvartalsvisa genomgångar av RBAC, nätverkspolicyer och image-scanning
• Kostnadsrapporter – månatliga FinOps-rapporter med konkreta rekommendationer
• GitOps-drift – vi underhåller Argo CD/Flux-installationer och hanterar klustrets infrastrukturkomponenter

Vi anpassar oss efter er mognad. Har ni redan ett plattformsteam kompletterar vi med nattjour och specialistkunskap. Är ni i början av resan bygger vi plattformen tillsammans. Managerade molntjänster

Vanliga frågor

Vad är skillnaden mellan managed Kubernetes och självhostat?

Managed Kubernetes (EKS, AKS, GKE) innebär att molnleverantören sköter kontrollplanet – etcd, API-server, scheduler. Du ansvarar fortfarande för worker-noder, nätverkspolicyer, säkerhetsuppdateringar och applikationskonfiguration. Självhostat ger full kontroll men kräver dedikerat plattformsteam.

Behöver vi Kubernetes om vi bara kör ett fåtal tjänster?

Inte nödvändigtvis. För under tio mikrotjänster kan ECS Fargate, Azure Container Apps eller Cloud Run vara enklare och billigare. Kubernetes ger störst värde när ni har många team, komplexa beroenden och behov av en enhetlig plattform.

Hur påverkar NIS2 vår Kubernetes-drift?

NIS2 ställer krav på incidentrapportering, åtkomststyrning och riskhantering. I praktiken innebär det RBAC med least privilege, nätverkspolicyer som begränsar pod-till-pod-trafik, centraliserad loggning och att ni kan visa upp en auditspårning för IMY eller MSB vid tillsyn.

Vad kostar Kubernetes-drift i molnet?

EKS kostar runt 0,10 USD/timme per kluster för kontrollplanet. Den verkliga kostnaden sitter i compute-noder, persistent storage och dataöverföring. Utan aktiv FinOps-styrning ser vi regelmässigt 25–40 procent överprovisioning hos kunder som inte mäter faktisk resursanvändning.

Kan Opsio hjälpa med befintliga Kubernetes-kluster vi redan kör?

Ja. Vi börjar med en operativ genomlysning – säkerhet, kostnad, observabilitet och CI/CD-mognad – och tar sedan över drift och övervakning via vårt 24/7 SOC/NOC. Vi tvingar ingen att börja om från noll.

For hands-on delivery in India, see end-to-end drift.