RKE2 vs K3s – vilken Rancher-distribution?

RKE2 och K3s kommer från samma familj, installeras på nästan samma sätt och hanteras från samma Rancher. Ändå är de byggda för helt olika vardagar. Väljer du fel märks det sällan första veckan. Det märks vid första revisionen, eller när ett kluster i en fabrikshall ska klara sig utan nätverk.

Den här artikeln går igenom skillnaderna mellan RKE2 och K3s: varifrån de kommer, en jämförelsetabell, säkerhet och CIS-härdning, det stora ingressbytet 2026, hur de fungerar i en blandad flotta med Rancher och de vanligaste misstagen vi ser.

Har du frågor om ämnet? Tveka inte att höra av dig till oss!

Av Johan Kuylenstierna, VD Agency 42 · Senast granskad 2 november 2026

Kort svar

Välj RKE2 för datacenter, moln och reglerade miljöer där ni behöver bevisbar härdning, FIPS-stöd och en distribution som ligger nära uppströms Kubernetes. Välj K3s för edge, labb, CI och små eller resurssnåla miljöer där enkelhet och litet fotavtryck väger tyngst. Båda är fullständiga Kubernetes-distributioner och båda kan hanteras från Rancher.

Tänk på dem som en lastbil och en skåpbil från samma fabrik. Lastbilen har färdskrivare och besiktningsprotokoll. Skåpbilen tar sig in på gator där lastbilen inte får plats. Ingen av dem är bättre, men de är dåliga på varandras jobb.

Samma familj, olika uppdrag

RKE2 kallas även RKE Government. Enligt dokumentationen är den byggd med fokus på säkerhet och regelefterlevnad för amerikansk federal sektor. Den ska klara CIS Kubernetes Benchmark med minimal insats från operatören, stöder FIPS 140-2 och skannas efter sårbarheter med Trivy i byggkedjan. RKE2 tar installationsmodellen från K3s och den nära linjen mot uppströms Kubernetes från föregångaren RKE1.

K3s är lättviktsdistributionen. Hela kontrollplanet körs i en enda binär och process, och den levereras med allt som behövs för ett fungerande kluster. Dokumentationen nämner edge, IoT, CI, utveckling, ARM-kort och inbäddade system som typiska användningsområden. RKE2:s dokumentation säger rakt ut att K3s på vissa punkter avviker från uppströms Kubernetes för att optimera för edge. K3s har varit ett CNCF-projekt på sandbox-nivå sedan augusti 2020.

Jämförelsetabell

	RKE2	K3s
Fokus	Säkerhet och regelefterlevnad	Lättvikt, edge och enkelhet
Kontrollplan	Statiska poddar som kubelet hanterar	En binär och en process
Datalager	Inbäddad etcd	SQLite som standard, inbäddad etcd för HA, eller externt etcd, MySQL, MariaDB eller PostgreSQL
Standard-CNI	Canal (Cilium, Calico och Flannel paketeras också)	Flannel, med kube-router för nätverkspolicy
Ingress	Traefik som standard från v1.36	Traefik
CIS-härdning	`profile: cis` gör det mesta åt dig	Du konfigurerar flaggor och policyer själv
FIPS 140-2	Ja, enligt dokumentationen	Inte dokumenterat, finns på projektets roadmap
Rancher	Provisionering och import	Provisionering och import

Uppgifterna kommer från respektive projekts dokumentation, hämtad den 2 november 2026. Kontrollera alltid versionen ni faktiskt kör.

När RKE2 är rätt

Ni har krav på CIS, FIPS eller revisionsspår och vill kunna visa hur klustret är härdat.
Ni kör långlivade produktionskluster i datacenter eller moln, med flera team på samma plattform.
Ni vill ha flera CNI-alternativ, till exempel Cilium med eBPF eller Calico, utan att bygga in dem själva.
Ni behöver Windows-noder i klustret.

När K3s är rätt

Kluster vid kanten: butiker, fabriker, fordon och fältutrustning där hårdvaran är begränsad.
Labb, CI och utvecklingsmiljöer som ska upp snabbt och gärna kastas efteråt. Ett kluster med en server och SQLite är fullt rimligt där.
ARM-kort och inbäddade system.
Team som vill ha Kubernetes utan att äga etcd. K3s kan använda en extern MySQL- eller PostgreSQL-databas som datalager.

Dokumentationen för båda beskriver installation utan internetåtkomst, så nätverksisolerade miljöer avgör inte valet i sig.

Säkerhet och härdning i praktiken

Skillnaden mellan "går att härda" och "är härdad som standard" är där de flesta jämförelser går för fort fram.

Med RKE2 sätter du profile: cis i konfigurationen. Då kontrollerar RKE2 värdkraven och vägrar starta om de inte är uppfyllda, kör etcd som en egen användare, lägger på nätverkspolicyer för systemnamnrymderna och tvingar Pod Security Admission till restricted i alla namnrymder utom systemets. Du behöver fortfarande själv sätta kärnparametrar, skapa etcd-användaren, stänga av automatisk token-montering för default-servicekontot och skriva en riktig audit-policy. Standardpolicyn loggar ingenting.

Med K3s är utgångsläget lättare. Dokumentationen säger att K3s som standard inte har några pod security- eller nätverkspolicyer, och att audit-loggning måste konfigureras manuellt. Härdningsguiden går igenom flaggor, en psa.yaml, nätverkspolicyer, audit och några manuella kontroller, till exempel filrättigheter på certifikat.

Båda går alltså att få CIS-kompatibla. Frågan är hur mycket av jobbet du vill göra själv, och hur mycket du vill kunna visa en revisor att du gjort. Oavsett distribution: lägg härdningen i Git, låt pipelinen kontrollera den och spara resultatet som evidens. Mer om det i DevOps och DevSecOps.

Ingressbytet 2026

Det här är årets mest kännbara förändring för RKE2-användare. Enligt RKE2-dokumentationen nådde ingress-nginx end of life i mars 2026. Från RKE2 v1.36 är Traefik standard, och i v1.37 går ingress-nginx inte längre att välja för nya kluster. Befintliga kluster kan köra båda parallellt under en övergång eller gå över helt till Traefik. Rancher Prime-kunder erbjuds en förlängd supportperiod för ingress-nginx.

K3s har haft Traefik som standard länge, så på den här punkten har familjen närmat sig varandra. Vill ni använda Gateway API i RKE2 är det också Traefik som gäller.

Har ni RKE2-kluster med ingress-nginx: inventera era Ingress-resurser och annoteringar nu, testa Traefik i en kopia av miljön och planera bytet som en vanlig förändring med rollback.

Blandade flottor med Rancher

Många organisationer landar i båda: RKE2 i datacentret och K3s ute vid kanten. Det fungerar bra, för Rancher kan provisionera och importera båda. I SUSE:s supportmatris för Rancher 2.15 är RKE2 och K3s certifierade för samma Kubernetes-versioner.

Några saker att tänka på:

Uppgraderingar. Hanteras klustret av Rancher ska ni uppgradera via Rancher, inte med en egen system-upgrade-controller vid sidan av.
GitOps. Använd Fleet eller Argo CD så att samma policyer och baskonfiguration rullas ut till båda typerna.
Olika standardval. Canal och Flannel beter sig olika. Skriv nätverkspolicyer som fungerar oavsett CNI, och testa dem på båda.

Läs mer om hanteringslagret i Vad är SUSE Rancher?.

Vanliga misstag

1. K3s i datacentret "för att det är enklare"

Det fungerar tekniskt. Men om ni har revisionskrav köper ni er enkelhet med manuellt härdningsarbete som RKE2 hade gjort åt er.

2. SQLite när klustret ska ha flera servrar

SQLite fungerar inte med flera servernoder. Planerar ni för HA, välj inbäddad etcd eller en extern databas från början.

3. Byta CNI i efterhand

RKE2 stöder inte byte av primär CNI eller kluster-CIDR på ett körande kluster. Välj CNI innan första start, annars är det ombyggnad som gäller.

4. Flannel i en härdad miljö

Flannel saknar stöd för nätverkspolicyer och rekommenderas därför inte för härdade RKE2-installationer. Välj Canal, Calico eller Cilium.

5. Ett jämnt antal servernoder

etcd behöver ett udda antal servrar för att behålla kvorum. Tre är det rekommenderade.

Och om noderna står i NotReady direkt efter installationen: don't panic. Kontrollera först att ett CNI faktiskt är installerat. Utan CNI blir noderna aldrig Ready.

Sammanfattning

RKE2 och K3s är fullständiga Kubernetes-distributioner från samma familj, men byggda för olika miljöer.
RKE2 är härdad som standard, stöder FIPS 140-2 och ligger nära uppströms.
K3s är en binär med flexibelt datalager och passar edge, labb och CI.
Ingress-nginx är på väg ut ur RKE2. Planera bytet till Traefik nu.
Rancher hanterar båda, så en blandad flotta är fullt rimlig.

Du ska välja RKE2 när:

ni behöver visa CIS- eller FIPS-efterlevnad,
klustren är långlivade och delas av flera team,
ni vill kunna välja Cilium eller Calico utan eget integrationsarbete.

Du ska välja K3s när:

hårdvaran är begränsad eller sitter långt från datacentret,
klustren är kortlivade, som i CI och labb,
ni vill slippa drifta etcd.

Vanliga frågor

Vad är skillnaden mellan RKE2 och K3s?

RKE2 är SUSE:s säkerhetsfokuserade distribution för datacenter och reglerade miljöer, med CIS-profil och FIPS 140-2. K3s är en lättviktsdistribution i en enda binär för edge, labb och små miljöer.

Kan man köra K3s i produktion?

Ja. K3s är en fullständig Kubernetes-distribution, och dokumentationen beskriver hög tillgänglighet med inbäddad etcd eller extern databas. Härdningen kräver mer manuellt arbete än i RKE2.

Kan RKE2 och K3s hanteras från samma Rancher?

Ja. Rancher kan både provisionera och importera RKE2- och K3s-kluster, och båda finns i SUSE:s supportmatris för Rancher.

Vilken ingress använder RKE2 nu?

Från RKE2 v1.36 är Traefik standard. Ingress-nginx nådde end of life i mars 2026 och går inte att välja för nya kluster från v1.37.

Kan man byta från K3s till RKE2?

Vi rekommenderar att bygga ett nytt RKE2-kluster och flytta arbetslasterna dit, i stället för att försöka konvertera ett befintligt kluster. Det går smidigt om konfiguration och arbetslaster ligger i Git.

Vill du ha hjälp att välja och drifta rätt Rancher-distribution?

Vi är Sveriges go-to-specialister på Kubernetes. Vi designar, bygger och driftar plattformar på SUSE Rancher med RKE2 och K3s, härdar dem mot CIS och kopplar ihop dem med GitOps och säkra CI/CD-kedjor. Vi har erfarenhet av plattformsdrift för danska försvaret med Rancher-hanterade kluster, SUSE Linux, härdning och kontrollerad förändringshantering. 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å:

Källor

Hämtade 2026-11-02.

RKE2, Introduction. docs.rke2.io
RKE2, Network Options och Networking Services. docs.rke2.io, docs.rke2.io
RKE2, CIS Hardening Guide och FIPS 140-2 Enablement. docs.rke2.io, docs.rke2.io
RKE2, High Availability och Automated Upgrades. docs.rke2.io, docs.rke2.io
K3s, What is K3s?, Cluster Datastore och CIS Hardening Guide. docs.k3s.io, docs.k3s.io, docs.k3s.io
K3s, ROADMAP.md. github.com
CNCF, k3s. cncf.io
SUSE, Support matrix Rancher v2.15.2. suse.com