ADMIN

2022

02

2022-01-30T12:00:00

Cloudmanagement

TESTS

032

Kubernetes

SUSE Rancher

Sattelfester Viehtreiber

von Martin Loschwitz

Veröffentlicht in Ausgabe 02/2022 - TESTS

SUSE bietet mit Rancher eine eigene Kubernetes-Distribution, die entsprechende Cluster und die darauf in Containern laufenden Workloads managt. Der Hersteller verspricht dabei, dem Admin Kubernetes-Verwaltungsaufgaben deutlich zu erleichtern. Ob Rancher dies gelingt, untersucht unser Test ebenso wie den sicheren Betrieb und die Compliance-Funktionen der Software.

Kubernetes und kein Ende: Im Fahrwasser des Cloud Computings ist das Verteilen und Verwalten von Containern über eine Flotte von Servern der aktuelle Goldstandard für den Betrieb von Workloads. Da ist es nicht weiter verwunderlich, dass alle Linux-Distributoren, die etwas auf sich halten, eine eigene Kubernetes-Distribution im Portfolio haben. Red Hats OpenShift war im IT-Administrator bereits mehrmals Thema, zuletzt mit einem Test der Version 4.7. Kubernetes können aber auch andere Hersteller – beispielsweise SUSE. Böse Zungen würden gar behaupten, neben der angestammten Linux-Distribution sei Kubernetes mittlerweile das Einzige, was der Hersteller noch zu bieten habe. Denn sein Storage-Produkt auf Basis von Ceph und die eigene OpenStack-Distribution SUSE Cloud wurden ja in der Zwischenzeit eingestampft.
Hinzu kommt, dass SUSEs Kubernetes-Distribution Rancher keine Eigenentwicklung ist, sondern zugekauft wurde. Kritiker mögen an dieser Stelle womöglich anmerken, dass auch OpenShift kein originäres Red-Hat-Produkt war, sondern aus dem Einkauf von Makara im Jahre 2010 stammt. Zwischenzeitlich hat OpenShift jedoch so viele massive Umwälzungen durchlaufen, dass es als bei Red Hat entwickelt durchgeht. Das ist bei SUSE zumindest im Augenblick noch nicht so, denn allzu lange ist die Rancher-Akquisition noch nicht her. Und der Hersteller ist erkennbar darum bemüht, Rancher einen passenden Platz im eigenen Portfolio zu beschaffen (von wo es SUSEs vorherige Container-Lösung erstmal verdrängen musste).
All das spielt für Admins freilich eine untergeordnete Rolle, wenn sie sich für eine Kubernetes-Distribution am Markt entscheiden sollen. Denn bei solch einer Auswahl stehen andere Aspekte im Vordergrund, wie unser Test von OpenShift im IT-Administrator Juli 2021 unter Beweis gestellt hat. Weil OpenShift und Rancher im selben Becken nach Kunden fischen, ist es nur fair, sie denselben Tests zu unterziehen. Die Mitte Oktober erschienene Version 2.6.2 der Umgebung liefert dazu eine gute Gelegenheit.
Kubernetes und kein Ende: Im Fahrwasser des Cloud Computings ist das Verteilen und Verwalten von Containern über eine Flotte von Servern der aktuelle Goldstandard für den Betrieb von Workloads. Da ist es nicht weiter verwunderlich, dass alle Linux-Distributoren, die etwas auf sich halten, eine eigene Kubernetes-Distribution im Portfolio haben. Red Hats OpenShift war im IT-Administrator bereits mehrmals Thema, zuletzt mit einem Test der Version 4.7. Kubernetes können aber auch andere Hersteller – beispielsweise SUSE. Böse Zungen würden gar behaupten, neben der angestammten Linux-Distribution sei Kubernetes mittlerweile das Einzige, was der Hersteller noch zu bieten habe. Denn sein Storage-Produkt auf Basis von Ceph und die eigene OpenStack-Distribution SUSE Cloud wurden ja in der Zwischenzeit eingestampft.
Hinzu kommt, dass SUSEs Kubernetes-Distribution Rancher keine Eigenentwicklung ist, sondern zugekauft wurde. Kritiker mögen an dieser Stelle womöglich anmerken, dass auch OpenShift kein originäres Red-Hat-Produkt war, sondern aus dem Einkauf von Makara im Jahre 2010 stammt. Zwischenzeitlich hat OpenShift jedoch so viele massive Umwälzungen durchlaufen, dass es als bei Red Hat entwickelt durchgeht. Das ist bei SUSE zumindest im Augenblick noch nicht so, denn allzu lange ist die Rancher-Akquisition noch nicht her. Und der Hersteller ist erkennbar darum bemüht, Rancher einen passenden Platz im eigenen Portfolio zu beschaffen (von wo es SUSEs vorherige Container-Lösung erstmal verdrängen musste).
All das spielt für Admins freilich eine untergeordnete Rolle, wenn sie sich für eine Kubernetes-Distribution am Markt entscheiden sollen. Denn bei solch einer Auswahl stehen andere Aspekte im Vordergrund, wie unser Test von OpenShift im IT-Administrator Juli 2021 unter Beweis gestellt hat. Weil OpenShift und Rancher im selben Becken nach Kunden fischen, ist es nur fair, sie denselben Tests zu unterziehen. Die Mitte Oktober erschienene Version 2.6.2 der Umgebung liefert dazu eine gute Gelegenheit.
SUSE Rancher 2.6.2
Produkt
Software zur Verwaltung von Kubernetes-Clustern und den darin laufenden Workloads.
Hersteller
SUSE
Preis
Der Preis für SUSE Rancher richtet sich nach der Anzahl der genutzten Knoten. So kostet etwa eine per Rancher auf AWS ausgerollte "t2.medium"-Instanz in Frankfurt pro Monat knapp 39 Euro. Das Einholen eines Angebots ist dringend empfohlen, nicht zuletzt, da SUSE den Rancher-Support in zwei Ausprägungen anbietet.
Systemanforderungen
Mindestens 8 GByte RAM sowie zwei CPU-Kerne für Rancher-Installationen, die bis zu 150 Kubernetes-Cluster verwalten. Mit 32 CPU-Kernen sowie 128 GByte RAM im RKE-Cluster für die Rancher-Komponenten lassen sich bis zu 2000 Kubernetes-Instanzen aus bis zu 20.000 Knoten verwalten.
Technische Daten
Fünf Aspekte im Test
Wie OpenShift auch muss Rancher sich im Hinblick auf fünf Kriterien beweisen. Im ersten Schritt geht es um die Frage, wie einfach Rancher sich installieren und aufsetzen lässt. Das Kriterium klopft ein zentrales Versprechen von SUSE ab, wonach Rancher das Handling vieler verschiedener Kubernetes-Instanzen viel leichter handhabbar macht. Der zweite Aspekt schließt daran unmittelbar an: Nimmt Rancher nach dessen Ersteinrichtung dem Admin Arbeit ab, sprich wo erlaubt es Abkürzungen, worum kümmert sich Rancher automatisch und welche Aufgaben fallen somit für den Administrator weg?
Im dritten Punkt beschäftigen wir uns mit den Kubernetes-Grundfunktionen. Die Anbieter von Kubernetes-Distributionen neigen dazu, die eigentliche Grundfunktionalität von Kubernetes unter einem Haufen zusätzlicher Features zu verstecken. Ist das bei Rancher auch so oder bildet Rancher neben den Zusatzfunktionen auch die klassischen Kubernetes-Features ab?
Die Bewertungskategorien vier und fünf nehmen schließlich auf die ewig gültigen Themen der IT Bezug – Sicherheit einerseits und Compliance andererseits. Wie gut ist Rancher ab Werk gegen Angriffe geschützt? Welche Möglichkeiten haben Nutzer, auch ihre Container-Workloads automatisch abzusichern? Und wie gut lässt Rancher sich in bestehende Compliance-Regelwerke integrieren, etwa durch zentrale Autorisierung und Authentifizierung?
Bild 1: Das Rancher-Dashboard vermittelt Administratoren einen guten Überblick über aktuelle Workloads und die jeweils anliegende Last.
Rancher aufsetzen ist komplex
Die Einfachheit der Installation einer Software ist im IT-Administrator aus guten Gründen üblicherweise kein valides Testkriterium. Denn im Jahr 2021 ist die Erwartungshaltung selbstverständlich, dass jedwede Form von Programm oder Umgebung mit einer Setup-Routine ausgestattet ist, die dem Anwender das Gros der Arbeit abnimmt.
Bei Kubernetes liegen die Dinge in aller Regel allerdings etwas anders. Hier stellt sich eine zentrale Frage bereits am Anfang, nämlich ob ein Unternehmen viele kleine Kubernetes-Instanzen betreiben möchte oder doch eine große für viele Kunden. Kubernetes ist traditionell anders als etwa OpenStack nicht sonderlich gut auf den Betrieb mit vielen Mandanten ausgelegt, weshalb viele Firmen sich für den Betrieb vieler kleiner Kubernetes-Instanzen entscheiden. Rancher verspricht, sich wie ein Handschuh um die verschiedenen Kubernetes-Cluster zu legen und Deployment-Hilfe für sie zu sein.
Für die Einordnung dieses Punktes sollten wir uns vergegenwärtigen, dass sich etwa in AWS mit wenigen Mausklicks ein Kubernetes-Cluster per Amazon Elastic Kubernetes starten lässt. Soll Rancher dem Administrator also echten Mehrwert liefern, darf es nicht viel eigenen Overhead produzieren.
Im ersten Augenblick wirkt es allerdings so, als tue Rancher genau das. Nun ist es nicht weiter ungewöhnlich, dass die Kubernetes-Distributionen der großen Hersteller selbst in Kubernetes implementiert sind, also eine Art "Rumpf-Kubernetes" brauchen, um überhaupt zu funktionieren. Auch OpenShift ist auf diese Weise konzipiert. Red Hat legt OpenShift allerdings ein Werkzeug bei, das den Mini-Cluster für Kubernetes automatisch startet, wenn der Admin eine Zielplattform dafür konfiguriert. Im Normalfall reicht ein einzelner Befehl auf der Kommandozeile, um OpenShift mittels einer vorbereiteten Konfigurationsdatei an den Start zu kriegen. Rancher geht hier einen anderen Weg.
Denn sein Rumpf-Kubernetes darf der Administrator sich zunächst selber aus den Rippen leiern. Immerhin bietet Rancher hierfür "RKE" (Rancher Kubernetes Environment) an – und das funktioniert so ähnlich wie der Installer von OpenShift – rollt aber selbst Rancher nicht aus, sondern nur das von Rancher benötigte Kubernetes. Der Administrator legt also eine Konfigurationsdatei für RKE an, ruft im Anschluss rke auf und gibt über den Befehl die Konfigurationsdatei als Parameter mit auf den Weg. Kurze Zeit später steht dann ein Kubernetes zur Verfügung, innerhalb dessen im nächsten Schritt Rancher selbst erwacht.
Sobald RKE läuft, geschieht das Rancher-Deployment über den Paketmanager für Kubernetes namens Helm. Alle Rancher-Komponenten liegen als Helm-Charts vor und der zuvor ausgerollte RKE-Cluster unterstützt Helm ab Werk. Allerdings ist das Setup nicht so trivial, wie mancher Administrator es sich wohl wünschen würde. Denn um Themen wie die SSL-Konfiguration für Rancher muss der Admin sich während der Installation selbst kümmern. Hier steht immerhin die Option im Raum, Zertifikate gleich automatisch über Let's Encrypt zu beziehen, was die Sache deutlich leichter handhabbar macht.
Am Ende eines gar nicht mal so kurzen und auch nicht einfachen Setupvorgangs hat der Admin dann einen laufenden Kubernetes-Cluster, der per verschlüsselter Verbindung erreichbar ist und innerhalb dessen die Rancher-Komponenten laufen. Das bekommt OpenShift besser hin, hier ist also noch Potenzial nach oben.
Bild 2: Rancher integriert ab Werk externe Werkzeuge wie hier Grafana mit dem Log-Aggregator Loki.
Umgestellter Rancher-Betrieb beeindruckt
Bis zu Rancher 2.0 verstand sich das Produkt als General-Purpose-Orchestrierer und ganz klassische Platform-as-a-Service-Anwendung. Der Funktionsumfang glich früheren Versionen von OpenShift erkennbar: So gab es etwa einen über die GUI erreichbaren Katalog, über den sich per Mausklick schnell und einfach Anwendungen in Form so genannter "Stacks" starten ließen.
Neuere Rancher-Versionen schlagen allerdings einen anderen Ton an. Im Zentrum der Funktionalität steht nun nicht mehr die Möglichkeit, PaaS-Anwendungen flott zu starten. Stattdessen versteht Rancher sich mittlerweile als Tool, um verschiedene Kubernetes-Cluster in verschiedenen physischen Umgebungen ebenso zu verwalten wie die Workloads, die darauf laufen.
Die Entwickler sprechen dabei von einem "Ansatz mit drei Ebenen": Ebene 1 bildet die bereits erwähnte basale Kubernetes-Distribution namens RKS. Ebene 2 ist Rancher selbst, das diverse Funktionen für "Unified Cluster Management" bietet. Ebene 3 besteht im "Workload Management", also in der Möglichkeit, über die von Rancher verwalteten Cluster hinweg Workloads zu verteilen.
Durchaus beeindruckend sind in diesem Kontext die Funktionen, die sich die Rancher-Entwickler ausgedacht haben, um den Systemverwalter bei der täglichen Arbeit zu entlasten. Das geht schon bei der Ebene 1 los, also dem grundlegenden Kubernetes, das Rancher betreibt. Weil ohne dieses Kubernetes sämtliche von Rancher verwalteten Setups in der Luft hingen ("Loss of Control", aber immerhin kein "Loss of Functionality"), lässt der RKE-Cluster sich auf passender Hardware redundant ausrollen. Kubernetes nutzt dann seine eingebaute implizite Redundanz, um die Ausfälle einzelner Komponenten zu kompensieren.
Auch auf der Ebene von Rancher selbst lässt sich diese Redundanz einrichten, wenn der zugrunde liegende RKE-Cluster sie ermöglicht. Rancher bietet ab Werk aber noch mehr Funktionen. Der RKE-Cluster etwa lässt sich mittels derselben Werkzeuge, die ihn aufsetzen, auch aktualisieren – und zwar im Regelfall ohne signifikante Unterbrechung.
Beachtlich ist auch der Funktionsumfang auf der Ebene 2, also der von Rancher verwalteten Kubernetes-Instanzen. Wie sein eigenes RKE kann Rancher entfernte Kubernetes-Instanzen auf Zuruf aktualisieren. Es bietet Funktionen für das Management entfernter Hosts und entfernter Cluster an, und zwar ganz gleich, ob diese auf echtem Blech oder beispielsweise in einer öffentlichen Cloud ausgerollt sind.
Das ist im Kubernetes-Ökosystem ein durchaus relevanter Unterschied: Amazon, Azure oder Google bieten fertige Produkte an, deren Kern Kubernetes ist und die über eigene API-Erweiterungen steuerbar sind. Rancher versteht sich auf den Umgang mit diesen Diensten ebenso wie auf den mit Kubernetes-Clustern auf echtem Blech. Und diese Instanzen sind in der Rancher-API und Rancher-UI auch klar voneinander getrennt. Ein Anwender kann also beim Ausrollen eines Workloads mit implizitem Kubernetes festlegen, wo die Umgebung landen soll.
Erhebliche Erleichterungen in der Administration
Obendrein erweitert Rancher Kubernetes um das Konzept der "Projekte". Das ist eine rein auf der Rancher-Ebene existierende Form der Einteilung in Mandanten. Praktisch ist dabei, dass die Workloads einzelner Projekte unter keinen Umständen in denselben Kubernetes-Clustern landen, sodass die nicht gut ausgebaute Fähigkeit zur Verwaltung mehrerer Mandanten in Kubernetes hier nicht zum Problem wird. Insgesamt darf Rancher für sich also reklamieren, Admins den Einsatz und die Wartung von Kubernetes-Clustern erheblich zu erleichtern.
Dass auf der Ebene 2 der Anwendungskatalog mittlerweile aus standardisierten Helm-Charts und nicht wie bei der Konkurrenz zum Teil aus eigens zusammengeschusterten Katalogformaten besteht, ist da nur das sprichwörtliche Sahnehäubchen. Unter Berücksichtigung aller Umstände erweist Rancher sich hier als Werkzeug, das dem Admin die alltäglichen Arbeiten tatsächlich erleichtert.
Dabei spielt übrigens auch die Rancher-GUI eine erhebliche Rolle, denn diese haben die Entwickler in den vergangenen Monaten ordentlich ausgemistet, sodass sie sich aufgeräumt und gut sortiert präsentiert. Darin finden sich deutlich weniger Features als etwa bei OpenShift, was an dieser Stelle aber keinesfalls zum Nachteil erwächst. Alle zentralen Rancher-
Features lassen sich aus der GUI ohne Schwierigkeiten nutzen.
Zusätzlich zu seinen eigenen Kernfeatures bindet Rancher obendrein diverse externe Lösungen ein, um eine bessere Erfahrung für den Admin zu gewährleisten. Durch Rancher in Kubernetes ausgerollte Workloads lassen sich etwa mittels Prometheus überwachen und ihre Logdateien lassen sich an zentraler Stelle sammeln, ohne dass der Administrator viel Arbeit damit hat. Dabei bleibt die Freiheit des IT-Verantwortlichen weitgehend ohne Einschränkung, denn Logs lassen sich etwa nach ElasticSearch, Splunk oder Kafka exportieren. Ein eigenes Monitoring hat Rancher obendrein: Das fußt auf der Komponente für Monitoring, Alerting und Trending Prometheus, die in der FL/OSS-Szene ohnehin eine große Fangemeinde hat.
Alle Kubernetes-Grundfunktionen an Bord
Vor dem Hintergrund des Funktionsumfangs von Rancher wundert es nicht, dass sich das Featureset der durch Rancher ausgerollten Kubernetes-Umgebungen deutlich oberhalb des Kubernetes-Standards befindet. Hier erwächst dem Programm einmal mehr zum Vorteil, dass es – anders als etwa OpenShift – stets mit vielen Kubernetes-Setups hantiert, statt alle Workloads in ein einzelnes zu integrieren. Das verursacht einerseits zwar Overhead, weil eine Rancher-Installation viele Kubernetes-Controller startet und betreibt. Dafür haben Anwender im Gegenzug den Vorteil, dass die ausgerollten Kubernetes-Setups sich um das Thema Mandantenfähigkeit nicht kümmern müssen. Folgerichtig schöpfen die von Rancher gestarteten Kubernetes-Instanzen aus dem Vollen.
Bis zu einem bestimmten Grad spielt hier auch die Frage eine Rolle, welche Kubernetes-Distribution Rancher auf einer entfernten Plattform startet. Wenn es sich um RKE handelt, stehen sämtliche in der Rancher-Dokumentation beschriebenen Funktionen natürlich zur Verfügung. Im Fall eines fertigen Kubernetes-Dienstes bei einem der Cloudanbieter sieht die Sache freilich anders aus. Denn dann ist das dort definierte Featureset der wichtigste Faktor, der die Möglichkeiten definiert. Kubernetes in den großen Public Clouds ist natürlich auf den Betrieb in diesen optimiert und bietet Funktionen, die außerhalb des Betriebs in der jeweiligen Cloud ohne Relevanz wären. Umgekehrt verhält es sich ebenso: Bestimmte SDS- oder SDN-Features zu unterstützen, wäre etwa für Amazons Kubernetes-Produkt völlig unnötig, weil sie sich ohnehin nicht sinnvoll mit dem Rest der Plattform unter einen Hut bringen lassen.
Hier erwächst Rancher und letztlich auch Kubernetes der Trend hin zu versionierten APIs und zu erhöhter Abstraktion zum Vorteil. Will Rancher etwa in einer entfernten Kubernetes-Umgebung Pods starten, muss es für diese nur die wichtigsten Konfigurationsdetails festlegen. Wie etwa Netz und Speicher auf der jeweiligen Plattform implementiert sind, bleibt vor den Augen der User irrelevant.
Rancher rundet sein Angebot schließlich ab, indem es sein Kubernetes ab Werk mit Support für Erweiterungen wie Helm-Charts ausrollt. Für seinen eigenen Anwendungskatalog, der die Nutzung von Rancher im Sinne einer PaaS-Plattform ermöglicht, gilt das natürlich ebenso. Alle grundlegenden Kubernetes-Features wie Replikate und hochverfügbare Pods unterstützt RKE obendrein. Admins bekommen im Rancher-Falle also ein vollwertiges Kubernetes.
Überdurchschnittliche Sicherheit ab Werk
Kein Unternehmen kann es sich heutzutage mehr leisten, den Faktor Sicherheit bei seinen Überlegungen außen vor zu lassen. Systemverwalter setzen bewusst auf Lösungen wie Rancher, weil diese seitens ihrer Hersteller mit diversen Schutzmaßnahmen daherkommen, um die der Admin sich dann selbst nicht mehr zu kümmern braucht. Das ist bei Rancher auch so, was sich an mehreren Stellen deutlich zeigt.
Die eingangs erwähnte Notwendigkeit, das Thema SSL gleich am Anfang eines neu entstehenden Rancher-Setups abzuhandeln, ist dafür ein Indikator. Andere Lösungen – auch OpenShift – starten erstmal mit einem selbst generierten SSL-Zertifikat, das im Browser anschließend natürlich Fehlermeldungen produziert. Rancher bietet dem Administrator an, das Thema gleich vernünftig anzugehen. Dabei hat der Admin die Wahl, ob er wahlweise ein fertiges Zertifikat kauft und Rancher mit auf den Weg gibt oder – falls Rancher eine Verbindung ins Internet hat – Let's Encrypt benutzt, um sich die passenden Zertifikate dynamisch und automatisch ausstellen zu lassen. Eine Option, ohne Verschlüsselung auf Rancher und seine APIs zuzugreifen, ist gar nicht erst vorgesehen.
Auch auf der Ebene der gemanagten Work- loads stellt Rancher das Thema Security in den Vordergrund: "Security Policies" legen fest, welche Kommunikationspfade zwischen Pods erlaubt sind. Auch anhand von Rollen lassen sich Regeln definieren, die die Kommunikation zwischen Kubernetes-Ressourcen erlauben oder einschränken. Zusätzlich stehen im Anwendungskatalog von Rancher Lösungen zur Verfügung, die implizit Sicherheit erzwingen, etwa Istio als MESH-Netzwerk zwischen den Komponenten einer Anwendung, die dem Prinzip der Mikrodienste folgt. Insgesamt präsentiert sich Rancher mithin etwas besser als die Standardfunktionen, die IT-Verantwortliche von Kubernetes heute erwarten.
Bild 3: Auch mit an Bord hat Rancher Prometheus als Monitoringsystem, das an die Bedürfnisse dynamischer Container-Umgebungen besonders gut angepasst ist.
Gute Compliance-Features
Die beste Container-Verwaltung ist nichts wert, wenn sie sich nicht mit den bestehenden Compliance-Regeln in Einklang bringen lässt. In diesem Zusammenhang schöpfen die Rancher-Entwickler allerdings aus dem Vollen: Eingangs erwähnten wir, dass Rancher Projekte als Mandantenersatz nutzt. Um dieses Feature herum baut Rancher eine vorbildliche Compliance auf. So kann Rancher beispielsweise selbst die Authentifizierung von Anwendern vornehmen oder die Entscheidung über den Zugriff an externe Werkzeuge wie Active Directory, LDAP oder die diversen IAM-Systeme der Public-Cloud-Anbieter übertragen.
Selbst implementiert Rancher auf Wunsch eine Benutzerverwaltung und spickt diese mit einer ausgewachsenen Rollenverwaltung (RBAC; Role Based Access Control). Es kann sein RBAC aber auch auf Benutzer aus externen Quellen anwenden. Das in Rancher integrierte RBAC gibt dem IT-Verantwortlichen jedenfalls die Möglichkeit, äußerst fein granuliert die Rechte einzelner Nutzer zu steuern.
Theoretisch möglich, wenn auch seitens der Entwickler nicht aktiv vorgesehen, wäre es obendrein, die Rancher-GUI optisch an vorhandene Corporate-Identity-Vorgaben anzupassen. Ab Werk kommt Rancher mit einem hellen und einem dunklen Thema, und wer die Arbeit investieren will, kann hier etwa das Rancher-Logo durch das eigene Firmenlogo ersetzen.
Insgesamt präsentiert Rancher sich auf der Höhe der Zeit, was Compliance angeht. Denn es bietet alle relevanten Funktionen, die Admins heute zurecht von einem Flottenmanager für Container erwarten.
Fazit
Rancher gibt sich im Test und im direkten Vergleich mit OpenShift keine Blöße. Zwar ist erkennbar, dass die Zielsetzung der beiden Werkzeuge leicht divergiert – automatisch besser oder schlechter wird dadurch aber keines der beiden Tools. OpenShift ist im Hinblick auf das eigene Setup Rancher gegenüber leicht im Vorteil, weil hier ein einzelnes Programm alle relevanten Arbeitsschritte erledigt. Auch lässt OpenShift sich eher als ein fertiger PaaS-Katalog nutzen, der einzelne Anwendungen per Mausklick auf einem Zielcluster startet.
Rancher bietet im Gegenzug ungleich mehr Funktionalität, denn neben den Workloads startet Rancher auf Wunsch einzelne Kubernetes-Cluster, die es für die Workloads braucht, gleich mit. Dabei bindet es sich nicht fest an einzelne Anbieter, sondern unterstützt eine große Variabilität sowohl in der Public Cloud als auch auf echtem Blech im privaten RZ.
Der Funktionsumfang in Sachen Compliance und Security ist derweil bei beiden Lösungen durchaus vergleichbar. Einen eindeutigen Sieger im Duell gibt es vor diesem Hintergrund nicht, wohl aber den Hinweis, im Vorfeld die eigenen Anforderungen penibel zu dokumentieren und beide Lösungen zu evaluieren.
(jp)
So urteilt IT-Administrator
Bewertung
Inbetriebnahme 6 Rancher-Funktionalität 7 Kubernetes-Features 7 Security 6 Compliance 6
Dieses Produkt eignet sich
optimal
für Einsatzzwecke, bei denen mehrere Kubernetes-Cluster sowie ihre Workloads zentral zu verwalten sind.
bedingt
als PaaS-Werkzeug, das mit wenigen Mausklicks PaaS-Umgebungen inklusive ihrer Anwendungen aus dem Boden stampfen soll.
nicht
für einzelne Kubernetes-Cluster für eine Anwendung, denn hier erzeugt Rancher zu viel Overhead.