"Vi kör managed Kubernetes" är en av de mest förrädiska meningarna i svensk IT. För en person betyder det att leverantören sköter allt utom koden. För en annan betyder det att någon annan patchar kontrollplanet medan ditt team fortfarande äger noderna, nätverket, uppgraderingarna och nattjouren. Båda har rätt, för ordet managed betyder olika saker hos olika leverantörer.
Den här artikeln går igenom vad managed Kubernetes faktiskt innebär, de tre vanligaste modellerna i Sverige (hyperscalerns tjänst, svensk eller europeisk CaaS och egen plattform med driftpartner), en jämförelsetabell, vad ingen leverantör tar ansvar för och tio frågor att ställa innan du skriver på.
Har du frågor om ämnet? Tveka inte att höra av dig till oss!
Av Johan Kuylenstierna, VD Agency 42 · Senast granskad 26 oktober 2026
Vad "managed" faktiskt betyder
Ett Kubernetes-kluster består av flera lager. Det är ansvarsgränsen mellan lagren du köper, inte ordet på prislistan.
Tänk på det som att hyra bostad. En hyresrätt, en bostadsrätt och ett eget hus har alla tak, men vem som byter taket, rensar stupröret och betalar när det läcker skiljer sig rejält. Kontrollera vilket kontrakt du faktiskt har.
| Lager | Hyperscaler (AKS/EKS/GKE) | Svensk/europeisk CaaS | Egen plattform + driftpartner |
|---|---|---|---|
| Kontrollplan (API-server, etcd) | Leverantören | Leverantören | Driftpartnern |
| Noder och operativsystem | Delat – ofta du, med verktyg från leverantören | Ofta leverantören, varierar | Driftpartnern |
| Klusteruppgraderingar | Du startar, leverantören utför | Varierar, ofta leverantören | Driftpartnern, i ert fönster |
| Add-ons (ingress, CNI, lagring, övervakning) | Delvis leverantören, resten du | Ofta ett paket från leverantören | Driftpartnern, enligt er design |
| RBAC, policyer, nätverksregler | Du | Du | Ni tillsammans |
| Applikationer, pipelines, hemligheter | Du | Du | Du (med stöd) |
Tabellen är en grov karta, inte ett kontrakt. Läs alltid leverantörens ansvarsmodell (ofta kallad shared responsibility) innan du jämför priser.
Modell 1: hyperscalerns tjänst (AKS, EKS, GKE)
Microsoft (AKS), AWS (EKS) och Google (GKE) sköter kontrollplanet och ger dig bra verktyg för noder, skalning och identitet. Flera av dem har regioner i Sverige.
Fördelar:
- Snabb start och stor självbetjäning.
- Tät integration med molnets identitet, lagring, nätverk och databaser.
- Bred dokumentation och många som kan plattformen.
Nackdelar:
- Ditt team äger fortfarande mycket: nodpooler, add-ons, uppgraderingstakt, policyer och jour.
- Kostnaden styrs av mer än noderna: lastbalanserare, utgående trafik, loggar och lagring kan bli större poster än du räknade med.
- Leverantören är bolag utanför EU. Data i en svensk region betyder dataplats i Sverige, men inte automatiskt att bara svensk eller europeisk lag gäller. Det är en juridisk fråga att reda ut med er jurist, inte en teknisk.
- Djup integration gör exit dyrare. Ju fler molnspecifika tjänster du binder dig till, desto längre blir flyttlistan.
Modell 2: svensk eller europeisk CaaS
Flera svenska och europeiska molnleverantörer säljer Kubernetes som tjänst, container as a service. Upplägget skiljer sig mellan leverantörerna, så jämför på ansvarsgräns och inte på varumärke.
Fördelar:
- Dataplats och bolag inom EU, vilket ofta förenklar dialogen med jurister och kunder.
- Kortare väg till människor som kan svara på tekniska frågor.
- Ofta ett färdigt paket med ingress, lagring och övervakning.
Nackdelar:
- Färre färdiga tjänster runt klustret än hos en hyperscaler.
- Du är beroende av leverantörens val av Kubernetes-version, CNI och add-ons.
- Kontrollera vad som ingår i drift och jour, och vad som är "best effort".
Modell 3: egen plattform med driftpartner
Här kör ni en egen Kubernetes-distribution, till exempel SUSE Rancher med RKE2 eller Red Hat OpenShift, i ert eget datacenter, hos en hostingleverantör eller i ett moln. En driftpartner tar ansvar för plattformen enligt ett avtal som ni själva formar.
Fördelar:
- Full kontroll över versioner, härdning, nätverk och var data ligger.
- Samma plattform on-prem, i molnet och vid kanten, vilket gör exit och hybriddrift enklare.
- Passar miljöer med höga krav på spårbarhet och kontrollerad förändringshantering.
Nackdelar:
- Mer ansvar totalt sett, även om det delas med partnern.
- Kräver licens- och supportbeslut (till exempel Rancher Prime eller OpenShift-prenumeration).
- Ni behöver en tydlig RACI så att ingen tror att "partnern tar det" när det gäller era applikationer.
Vill du jämföra de två vanligaste distributionerna? Läs SUSE Rancher vs OpenShift – så väljer du och Vad är SUSE Rancher?.
Jämförelsetabell
| Kriterium | Hyperscaler | Svensk/europeisk CaaS | Egen plattform + driftpartner |
|---|---|---|---|
| Ansvarsgräns | Kontrollplan hos leverantören, mycket kvar hos dig | Mer hos leverantören, varierar | Avtalas fritt |
| Dataplats och jurisdiktion | Svensk region finns, bolag utanför EU | Sverige/EU | Där ni väljer |
| Anpassningsbarhet | Hög inom molnets ramar | Begränsad till leverantörens paket | Hög |
| Kompetenskrav i eget team | Medel till hög | Låg till medel | Medel, delat med partnern |
| Kostnadsdrivare | Noder, trafik, lastbalanserare, loggar | Noder och paketnivå | Infrastruktur, licenser, driftavtal |
| Exit | Svårare ju fler molntjänster | Medel | Enklast, plattformen följer med |
| Underlag för NIS2/tillsyn | Leverantörens dokumentation + ert arbete | Leverantörens dokumentation + ert arbete | Ni styr evidensen direkt |
Det finns ingen vinnare i tabellen. Det finns bara en modell som passar era krav bättre än de andra.
Det som ingen managed-tjänst tar ansvar för
Det här är avsnittet som brukar komma som en överraskning efter första incidenten.
1. Era workloads
Leverantören ser till att API-servern svarar. Den ser inte till att din deployment har rätt resursgränser, health checks eller fungerande rollback.
2. Behörigheter och policyer
RBAC-design, namnrymder, nätverkspolicyer och regler för vilka images som får köras är ert ansvar i alla tre modellerna. Vi visar hur det kan bevisas i Kubernetes-härdning som bevis.
3. Pipeline och leveranskedja
Signerade images, SBOM, sårbarhetsskanning och hemlighetshantering ligger i er pipeline. Mer om det under DevOps och DevSecOps.
4. Regelefterlevnad och incidentrapportering
Omfattas ni av cybersäkerhetslagen (2025:1506) ligger ansvaret kvar hos er som verksamhetsutövare, oavsett vem som kör klustret. Säkerhet i leveranskedjan är en av de åtgärder lagen kräver (2 kap. 3 § punkt 4), och det är ni som ska rapportera betydande incidenter enligt 2 kap. 5–8 §§. Er leverantör måste alltså kunna ge er underlag snabbt.
Är leverantören själv en molntjänstleverantör som omfattas, gäller dessutom EU:s genomförandeförordning (EU) 2024/2690. Enligt artikel 7 är en incident bland annat betydande om molntjänsten är helt otillgänglig i mer än 30 minuter. Läs mer i Cybersäkerhetslagen för dig som driftar plattformen.
Det här är en teknisk genomgång och inte juridisk rådgivning.
Tio frågor att ställa till leverantören
- Exakt vilka lager i tabellen ovan ingår i ert ansvar, och var står det i avtalet?
- Vem bestämmer när klustret uppgraderas, och hur länge får vi ligga kvar på en version? (Kubernetes-projektet underhåller bara de tre senaste minor-versionerna.)
- Ingår noder, operativsystem och patchning, eller bara kontrollplanet?
- Vilka add-ons ingår, och vem felsöker dem klockan tre på natten?
- Var lagras data, backup och loggar, och vilket bolag och vilken jurisdiktion gäller?
- Hur snabbt får vi underlag om en incident hos er påverkar oss, och i vilket format?
- Vilken evidens kan ni lämna inför en revision: härdningsrapporter, ändringsloggar, åtkomstloggar?
- Hur ser backup och återläsning ut, och när testades den senast?
- Hur tar vi ut våra kluster, konfigurationer och data om vi vill byta leverantör?
- Vilka underleverantörer ingår i er kedja?
En 42-blinkning: om svaret på fråga 1 är "det beror på", fråga igen. Svaret på allt kan vara 42, men svaret på ansvarsfrågan ska stå i avtalet.
Så väljer du
- Välj hyperscalerns tjänst om ni redan bygger djupt i det molnet, har ett eget plattformsteam och jurisdiktionsfrågan är utredd.
- Välj svensk eller europeisk CaaS om ni vill ha data och avtalspart i EU och klarar er med leverantörens standardpaket.
- Välj egen plattform med driftpartner om ni behöver styra versioner, härdning och evidens själva, kör hybrid eller on-prem, eller har krav som standardpaket inte täcker.
Många landar i en kombination, till exempel Rancher som gemensam styrning över både molnkluster och egna kluster. Det fungerar bra så länge ansvarsgränserna är nedskrivna.
Sammanfattning
- Managed Kubernetes är en ansvarsgräns, inte en produkt. Jämför lager för lager.
- Hyperscalers ger snabb start och stora ekosystem, men mycket ansvar ligger kvar hos dig.
- Svensk eller europeisk CaaS ger dataplats och avtalspart i EU, med mindre flexibilitet.
- Egen plattform med driftpartner ger mest kontroll och enklast exit, men kräver tydlig RACI.
- Workloads, policyer, pipeline och regelefterlevnad är alltid ditt ansvar.
Du ska välja egen plattform med driftpartner när:
- ni behöver bestämma uppgraderingstakt och härdning själva,
- ni kör i reglerade eller säkerhetskritiska miljöer med krav på spårbarhet,
- ni vill kunna byta infrastruktur utan att bygga om plattformen.
Vanliga frågor
Vad är managed Kubernetes?
Ett upplägg där en leverantör tar ansvar för delar av ett Kubernetes-kluster, oftast kontrollplanet och ibland även noder, uppgraderingar och add-ons. Exakt vad som ingår varierar mellan leverantörer.
Behöver vi ett eget plattformsteam om vi köper managed Kubernetes?
Oftast ja, eller en partner som fyller rollen. Någon måste äga RBAC, policyer, pipelines, uppgraderingsplanering och samarbetet med applikationsteamen.
Räcker det att data ligger i Sverige?
Dataplats är en del av svaret. Vilket bolag som driver tjänsten och vilken lag det bolaget lyder under är en annan del. Reda ut det med er jurist.
Påverkar cybersäkerhetslagen valet av managed Kubernetes?
Ja, indirekt. Ansvaret för säkerhetsåtgärder och incidentrapportering ligger kvar hos verksamhetsutövaren, så leverantören måste kunna ge underlag och följa era krav på leveranskedjan.
Hur byter man leverantör av managed Kubernetes?
Håll konfigurationen i Git (GitOps), undvik onödiga molnspecifika beroenden, testa backup och återläsning till en annan miljö och skriv in exit-villkor i avtalet från början.
Vad kostar managed Kubernetes utöver noderna?
Typiska poster är lastbalanserare, utgående trafik, lagring, loggar och övervakning, support- eller licensnivåer samt tiden ert eget team lägger på drift.
Vill du ha hjälp att välja – eller att drifta det du redan har?
Vi är Sveriges go-to-specialister på Kubernetes. Vi designar och bygger nya plattformar på SUSE Rancher, Red Hat OpenShift och managed Kubernetes, och kan ta över driften av en plattform ni redan har. Vi har erfarenhet från säkerhetskritisk plattformsdrift i försvarssektorn. Uppdrag på plats i Skåne och i Köpenhamn när det behövs, annars på distans i hela Sverige. Kontakta oss för offert eller boka ett första tekniskt samtal.
Läs mer på:
- Kubernetes-konsult för design, bygge och drift
- SUSE Rancher-konsult
- Linuxplattform på SUSE och Red Hat
- Compliance: NIS2 och CRA i plattformen
- Kundcase
- Kontakta oss
Källor
Kontrollerade 2026-10-26.
- Cybersäkerhetslag (2025:1506), särskilt 2 kap. 3 § och 5–8 §§. riksdagen.se
- Kommissionens genomförandeförordning (EU) 2024/2690, artikel 3 och 7. eur-lex.europa.eu
- Kubernetes, Release History (de tre senaste minor-versionerna underhålls). kubernetes.io
