SUSE Rancher vs OpenShift – så väljer du

"Ska vi köra Rancher eller OpenShift?" är en vanlig fråga, och en av de mest missförstådda, för produkterna löser delvis olika problem. Vi arbetar dagligen i både SUSE Rancher och Red Hat OpenShift. Vi har byggt och driftat Rancher- och OpenShift-plattformar i högt reglerade sektorer, bland annat försvar och offentlig verksamhet. Därför vet vi var de skaver.

Den här artikeln går igenom skillnaderna i arkitektur, drift, säkerhet, utvecklarupplevelse och kostnad. Vi tittar också särskilt på vad valet betyder i reglerade miljöer med krav från cybersäkerhetslagen (NIS2) och CRA. Sist kommer ett enkelt beslutsträd.

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

Kort svar

Välj OpenShift om du vill ha en komplett, sammanhållen plattform från en leverantör, där operativsystem, Kubernetes, register, routing och övervakning uppgraderas som en helhet. Du betalar för det, och du följer Red Hats sätt att göra saker.
Välj SUSE Rancher om du vill hantera många kluster på många ställen med ett gemensamt lager för åtkomst, policyer och GitOps, och själv vill välja distribution (RKE2, K3s, AKS, EKS, GKE med flera) och verktyg runt omkring.

Båda kan bli en utmärkt plattform. Båda kan också bli en dyr besvikelse om de väljs av fel skäl.

Två olika saker: hanteringslager och distribution

Det är här de flesta jämförelser går fel.

Rancher (Rancher Manager) är i grunden ett hanteringslager för många kluster. Det kan skapa egna kluster med SUSE:s distributioner RKE2 (härdad, för datacenter) och K3s (lättvikt, för edge). Det kan också importera befintliga kluster, till exempel AKS, EKS och GKE. Runt omkring finns bland annat Fleet för GitOps i stor skala. Rancher Prime är SUSE:s kommersiella prenumeration med support.

OpenShift är en Kubernetes-distribution med allt inbyggt: operativsystemet Red Hat Enterprise Linux CoreOS (RHCOS) på alla noder, Kubernetes, ett integrerat image-register, routing, en webbkonsol och operatorer för GitOps (Argo CD), pipelines (Tekton), loggning och övervakning. Vill du hantera många OpenShift-kluster centralt använder du Red Hat Advanced Cluster Management (RHACM). Uppströmsprojektet heter OKD.

Om du ska jämföra med en analogi: Rancher är flygledartornet som ser och styr alla plan, oavsett flygbolag. OpenShift är ett helt flygbolag, med plan, piloter, underhåll och bokningssystem från samma ägare. Du kan låta tornet hålla koll på flygbolagets plan, men det gör inte tornet till ett flygbolag.

Jämförelsen punkt för punkt

Vad det är

SUSE Rancher (med RKE2): ett hanteringslager för flera kluster plus egna distributioner.
Red Hat OpenShift: en komplett Kubernetes-plattform.

Operativsystem

Rancher/RKE2: valfritt operativsystem som stöds, till exempel SLES, SLE Micro, RHEL eller Ubuntu.
OpenShift: RHCOS på alla noder. Sedan OpenShift 4.19 är RHCOS det enda operativsystem som stöds, både för kontrollplanet och för arbetsnoderna.

Flera kluster och moln

Rancher: inbyggt. Rancher importerar även AKS, EKS, GKE och andra konforma kluster.
OpenShift: via RHACM, som är en separat produkt.

Säkerhet som standard

RKE2: en CIS-profil (restriktiv Pod Security, nätverkspolicyer, audit) och ett FIPS 140-2-läge.
OpenShift: restriktiva Security Context Constraints (SCC) som standard och Compliance Operator.

GitOps och CI/CD

Rancher: Fleet ingår. Argo CD, Tekton, GitLab CI med flera är valfria.
OpenShift: OpenShift GitOps (Argo CD) och OpenShift Pipelines (Tekton) som operatorer.

Utvecklarupplevelse

Rancher: ren Kubernetes. Ni bygger er egen "gyllene väg".
OpenShift: en webbkonsol med utvecklarfunktioner, Routes och Builds.

Uppgraderingar

Rancher: Manager och de underliggande klustren uppgraderas separat, och operativsystemet hanteras för sig.
OpenShift: hela plattformen, inklusive RHCOS, uppgraderas samlat via uppdateringskanaler.

Licens

Rancher: öppen källkod, med Rancher Prime som prenumeration.
OpenShift: prenumeration, med OKD som community-variant.

Inlåsning

Rancher: låg, eftersom det är standard-Kubernetes under.
OpenShift: högre, eftersom det finns OpenShift-specifika API:er och arbetssätt.

Arkitektur och drift i vardagen

Uppgraderingar

I OpenShift uppgraderar du plattformen som en helhet. Cluster Version Operator rullar ut Kubernetes och plattformens operatorer i rätt ordning, och Machine Config Operator uppdaterar RHCOS på noderna. Du väljer själv uppdateringskanal. Det är bekvämt och förutsägbart, men tempot styrs av Red Hats livscykel. Ligger du efter blir det flera hopp i rad.

I Rancher är det fler rörliga delar. Rancher Manager uppgraderas för sig, och därefter de underliggande klustren (till exempel RKE2) i en ordning som matchar supportmatrisen. Operativsystemet patchas med egna verktyg, till exempel SUSE Manager eller Ansible. Det ger mer flexibilitet men kräver mer disciplin. Utan en tydlig uppgraderingsrutin hamnar man lätt med fem kluster i fyra olika versioner.

Många kluster på många ställen

Här har Rancher en naturlig fördel, eftersom det är byggt för att vara paraplyet. Har ni en blandning av on-prem, edge och ett par molnkluster är Rancher ofta det enklaste sättet att få gemensam inloggning, RBAC och policyer över allt. OpenShift löser samma behov med RHACM, och det fungerar bra när alla kluster är OpenShift.

Driftbördan

OpenShift tar mer resurser i varje kluster, eftersom mycket ingår och körs i klustret. I gengäld behöver du sätta ihop färre delar själv. Rancher med RKE2 är slankare, men då är det ni (eller er driftpartner) som väljer, integrerar och underhåller loggning, övervakning, ingress och register. Ingen av dem är "underhållsfri". Frågan är bara var arbetet hamnar.

Säkerhet direkt ur lådan

SCC eller Pod Security med CIS-profil

OpenShift är strikt från start. Standardpolicyerna (SCC restricted-v2 sedan 4.11, och i nya installationer av senare versioner restricted-v3, som dessutom kräver Linux user namespaces) kör containrar som en slumpmässig, icke-privilegierad användare. Det är bra säkerhet, men det är också anledningen till att många färdiga images från Docker Hub stannar med felet "unable to validate against any security context constraint".

RKE2 gör Kubernetes standardfunktioner strikta i stället. Med profile: cis aktiveras restriktiv Pod Security Admission, standardnätverkspolicyer och inställningar enligt CIS-riktmärket. RKE2 kan också köras med FIPS 140-2-validerad kryptografi. Ditt team lär sig alltså standard-Kubernetes, inte en Red Hat-variant.

Efterlevnad och bevis

Båda kan skanna mot CIS. OpenShift har Compliance Operator, som bygger på OpenSCAP och har profiler för bland annat CIS och NIST. I Rancher kör du skanningarna från gränssnittet med appen Rancher Compliance, som ersatte den tidigare CIS Benchmark-appen i Rancher 2.12. På operativsystemsnivå härdar vi enligt CIS Benchmarks och DISA STIG och verifierar löpande med OpenSCAP eller motsvarande. Det viktiga är inte vilken knapp du trycker på. Det viktiga är att resultatet sparas, följs upp och går att visa vid en revision.

Utvecklarupplevelse

OpenShift har ett försprång om utvecklarna ska klicka sig fram. Webbkonsolens utvecklarfunktioner, Builds (Source-to-Image) och Routes gör att ett team kan komma igång utan att lära sig allt om Kubernetes. Sedan OpenShift 4.19 är konsolens vyer samlade, och den separata utvecklarvyn får slås på vid behov. Baksidan är att manifest och vanor blir OpenShift-specifika, till exempel Routes i stället för Ingress eller Gateway API.

Med Rancher får utvecklarna ren Kubernetes. Det kräver att plattformsteamet bygger mallar, pipelines och en tydlig "gyllene väg", men koden blir lättare att flytta.

Kostnad och licenser

Vi anger inga listpriser, eftersom de ändras och förhandlas. Det här brukar avgöra totalkostnaden:

Prenumerationer. OpenShift licensieras per kapacitet (kärnor eller sockets). Rancher Prime har en egen prenumerationsmodell. Community-varianterna (OKD och Rancher med öppen källkod) har ingen licensavgift men heller ingen leverantörssupport.
Overhead. Fler plattformskomponenter i varje OpenShift-kluster betyder mer hårdvara per kluster.
Kompetens. Med OpenShift följer mycket med i paketet. Med Rancher krävs mer eget integrationsarbete.
Drift. Den tyngsta posten är nästan alltid människor och tid, inte licenser. Räkna på uppgraderingar, incidenter och revisioner under tre till fem år.

Reglerade miljöer, NIS2 och CRA

För verksamheter som omfattas av cybersäkerhetslagen (2025:1506), som gäller sedan den 15 januari 2026, är valet av plattform mindre viktigt än hur den drivs. Lagen kräver säkerhetsåtgärder ur ett allriskperspektiv (2 kap. 3 §). Det gäller bland annat incidenthantering, säkerhet i leveranskedjan, säkerhet vid utveckling och underhåll, kryptografi och åtkomstkontroll. Båda plattformarna kan uppfylla det. Ingen av dem gör det automatiskt.

Det vi tittar på i reglerade miljöer:

Isolerade (airgappade) installationer. Båda stöds, med spegling av images till ett internt register. Rancher och RKE2 går att installera från lokala artefakter. OpenShift har en etablerad metod med spegling av releaser och operatorer.
Spårbarhet. GitOps (Fleet eller Argo CD) ger en historik över ändringarna, och audit-loggar visar vem som gjorde vad.
Leveranskedja. Signerade images (Sigstore/Cosign), SBOM och admission-policyer (Kyverno eller OPA Gatekeeper) fungerar på båda. Bygger ni produkter som omfattas av Cyber Resilience Act är det samma pipeline som tar fram underlaget till rapporteringsplikten, som gäller sedan den 11 september 2026. Läs mer i vår artikel om CRA-rapportering.
Leverantörens livscykel. Planera efter de supportfönster som SUSE och Red Hat publicerar, inte efter förhoppningar.

Beslutsträd

Är alla kluster i samma typ av miljö, och vill ni ha "allt i ett" med en leverantör? Då pekar det mot OpenShift.
Har ni (eller kommer ni att ha) kluster i flera moln, on-prem och edge? Då pekar det mot Rancher.
Ska utvecklarna arbeta i ett färdigt gränssnitt utan djup Kubernetes-kunskap? Det är en fördel för OpenShift.
Är låg inlåsning och standard-Kubernetes viktigast? Det är en fördel för Rancher med RKE2.
Har ni redan Red Hat-avtal och RHEL-kompetens, eller SUSE-avtal och SLES-kompetens? Låt det väga tungt. Befintlig kompetens är värd mer än en funktion i en jämförelse.
Har ni ett eget plattformsteam? Utan ett sådant team, eller en driftpartner, blir båda svåra.

Går det att kombinera?

Ja. Rancher kan importera konforma Kubernetes-kluster och fungera som gemensamt lager för åtkomst och översikt. Räkna dock med att OpenShift-klustrens livscykel fortfarande hanteras med OpenShifts egna verktyg. Ni får alltså två sätt att uppgradera. Det kan vara rätt under en övergångsperiod eller för olika organisationsdelar, men det är sällan ett slutmål.

Sammanfattning

Du ska välja OpenShift när:

du vill ha en sammanhållen plattform med en leverantör och ett samlat uppgraderingsflöde,
utvecklarupplevelsen "ur lådan" är viktig,
ni redan har Red Hat-kompetens och Red Hat-avtal.

Du ska välja SUSE Rancher när:

du hanterar många kluster i olika miljöer,
du vill ha standard-Kubernetes och låg inlåsning,
du vill välja verktyg själv och har kapacitet att integrera dem.

I båda fallen avgör driften om plattformen blir en tillgång eller en huvudvärk.

Vanliga frågor

Är OpenShift "bara Kubernetes"? Nej. OpenShift bygger på Kubernetes men levereras med operativsystem, register, routing, säkerhetspolicyer och utvecklarverktyg, och har egna API:er.

Kan Rancher hantera OpenShift-kluster? Rancher kan importera konforma Kubernetes-kluster för översikt och åtkomst, men OpenShifts egen livscykelhantering används fortfarande för uppgraderingar.

Kan man köra OpenShift på vanlig RHEL? Inte längre. Sedan OpenShift 4.19 är RHCOS det enda operativsystem som stöds för alla noder, även arbetsnoderna.

Vilken är säkrast? Båda kan härdas till en mycket hög nivå. OpenShift är striktare från start. RKE2 med CIS-profil når långt med standard-Kubernetes. Hur säker plattformen blir avgörs mest av drift, patchning och policyer.

Vad är skillnaden mellan RKE2 och K3s? RKE2 är SUSE:s härdade distribution för datacenter och reglerade miljöer. K3s är en lättviktsvariant för edge och små miljöer. Båda kan hanteras från Rancher.

Behöver vi Rancher Prime, eller räcker öppen källkod? Det beror på krav på support, certifierade versioner och er riskaptit. I verksamhetskritiska och reglerade miljöer väljer man oftast kommersiell support.

Vill du ha hjälp att välja, bygga eller drifta Rancher eller OpenShift?

Vi hjälper till med arkitektur, migrering, härdning och drift på båda plattformarna, även i reglerade och säkerhetskritiska miljöer. Kontakta oss för offert eller ett första tekniskt samtal.

Läs mer på:

Källor

Alla kontrollerade 2026-10-08 mot OpenShift 4.22 och aktuell Rancher- och RKE2-dokumentation.

Red Hat, OpenShift Container Platform 4.22 – Architecture: Red Hat Enterprise Linux CoreOS (RHCOS är det enda operativsystem som stöds för alla nodtyper). docs.redhat.com
Red Hat, OpenShift Container Platform 4.19 release notes (RHEL-arbetsnoder borttagna, samlad konsolvy). docs.redhat.com
Red Hat, OpenShift Container Platform 4.22 – Managing security context constraints (restricted-v2, restricted-v3). docs.redhat.com
Red Hat Advanced Cluster Management for Kubernetes. redhat.com
RKE2 documentation – CIS Hardening Guide och FIPS 140-2 Enablement. docs.rke2.io/security/hardening_guide och docs.rke2.io/security/fips_support
SUSE Rancher Manager documentation – Compliance Scan Guides (rancher-compliance). ranchermanager.docs.rancher.com
SUSE, Rancher Prime. suse.com/products/rancher
Cybersäkerhetslag (2025:1506), 2 kap. 3 §. riksdagen.se
Förordning (EU) 2024/2847 (CRA), art. 14 och 71. eur-lex.europa.eu