Kommerzielle Kubernetes-Distributionen im Vergleich

Angetreten, Entwickler beim Automatisieren der Bereitstellung, Skalierung und Verwaltung von Containeranwendungen zu unterstützen, ist Kubernetes heute in vielen Firmen ein unverzichtbarer Bestandteil der Containerinfrastruktur. Treibende Kraft hinter dem Orchestrierungstool ist Google; im Jahr 2015 übergab man das Produkt der „Cloud Native Computing Foundation“ (CNCF). Die Liste der CNCF-Mitglieder ist lang – sie liest sich wie das Who’s who der IT-Welt. Nicht verwunderlich ist es daher, dass sich um Kubernetes in den letzten Jahren ein großes Ökosystem gebildet hat. Auch die Anzahl der Kubernetes-Distributionen hat stark zugenommen. Anfangs war die Auswahl hier noch recht bescheiden: In der Public Cloud war dies vor allem Googles Kubernetes Engine (GKE) und in der On-Premises-­Welt ist Red Hat mit OpenShift seit jeher der Platzhirsch. Unterdessen gibt es neben diesen beiden Produkten eine Reihe weiterer Kandidaten, die eine Betrachtung wert sind.

Der folgende Artikel konzentriert sich dabei auf Pakete, die sich on Premises oder in einer hybriden Umgebung betreiben lassen. Neben Red Hat OpenShift sind dies Googles Plattform Anthos, VMwares neues vSphere 7, Rancher, SUSEs CaaS, aber auch das mittlerweile zu Mirantis gehörende Docker EE (für Enterprise Edition). Darüber hinaus gibt es Angebote von Micro­soft und AWS, die zusammen mit Hardware gebündelt sind – die dieser Artikel jedoch nicht berücksichtigt.

Kriterien für den Unternehmenseinsatz

Da Kubernetes selbst Open Source ist, müssen kommerzielle Anbieter einen deutlichen Mehrwert bieten, sodass Kunden bereit sind, Geld dafür zu investieren. Dabei gibt es eine Reihe von Herausforderungen, vor denen Entwickler stehen, Abbildung 1 gibt hier einen ersten Überblick.

Da ist zunächst das Identity- und Access-Management. Kubernetes selbst bietet keine Möglichkeiten, Benutzer zu verwalten. Stattdessen muss man diese in einer separaten Datenbank außerhalb von Kubernetes speichern. Weiter bleibt die Frage, wie man Benutzer authentifizieren möchte. Standardmäßig erfolgt das mit Zertifikaten, Token oder dem Basic-Authen­tication-Modus. Viele Hersteller haben an dieser Stelle Erweiterungen vorgenommen, die sich – zum Beispiel auf Basis von OpenID-Connect – in bestehende Identity-Systeme einklinken.

Clusterseitig spielt Auto Healing – die Fähigkeit, kaputte Knoten zur Laufzeit zu erkennen und zu ersetzen – ebenfalls eine große Rolle. Damit lassen sich die Auswirkungen auf den Betrieb durch einen Ausfall minimieren. Cluster Scaling ermöglicht das automatisierte Skalieren eines Kubernetes-Clusters; es kann entweder Knoten hinzufügen (Scale-out) oder entfernen (Scale-­in). Auch Unterstützung beim Upgrade eines Clusters ist ein wünschenswertes Feature. In vielen Umgebungen kann man dies sowohl zeitgesteuert als auch bei Bedarf erledigen.

Da Kubernetes selbst keine zentralen Logging- und Monitoring-Mechanismen mitbringt, sind die kommerziellen Kubernetes-Anbieter an dieser Stelle gefragt, Abhilfe zu schaffen. Viele setzen hierfür auf eigene Lösungen, andere nutzen bekannte Open-Source-Tools wie Prometheus oder Elasticsearch.

Zum Speichern von Container-Images bedarf es einer Container-Registry. Diese sollte mit einer Role-based Access Con­trol (RBAC) geschützt sein. Weiter sind eine grafische Schnittstelle und eine API essenziell. Auch sollte die Registry Container-Images auf Schwachstellen hin überprüfen können.

Klassischerweise administriert man Kubernetes über die Konsole. Bei der täglichen Arbeit kann ein grafisches Tool dabei helfen, insbesondere wenn den Betreibern nicht alle Konsolenbefehle geläufig sind.

In vielen Projekten stehen Storage-Aspekte oben auf der Liste der größten He­rausforderungen. Standardmäßig ist der Storage eines Containers flüchtig und somit nur an die Laufzeit des Containers oder Pod gebunden. Persistenz erfordert das Einbinden von externem Storage. Kubernetes definiert hierfür das Container Stor­age Interface (CSI) – die verschiedenen Distributionen bieten darüber hinaus eine Reihe weiterer Integrationen.

Im Betrieb stellt das Netzwerk eine weitere Herausforderung dar. Es ist eine zentrale Komponente in Kubernetes, daher ist es für Entwickler und Administratoren unerlässlich, sich mit dessen wichtigsten Eigenschaften vertraut zu machen. Für die Konfiguration ist in einer Vanilla-­Kubernetes-Umgebung ein Netzwerk-­Plug-in zu installieren, das die grundlegende Konnektivität zwischen Pods und Services regelt. Kommerzielle Distributionen können sich an dieser Stelle mit weiter gehenden Funktionen wie Load-­Balancer-, Software-defined-Networking-Integration (SDN) oder Security Policies auszeichnen.

In größeren Umgebungen ist bisweilen Multimandantenfähigkeit gefragt. Zu diesem Zweck bietet Kubernetes verschiedene Konstrukte, etwa Namespaces, um Elemente verschiedener Mandanten voneinander zu trennen. Trotzdem kann es schwierig sein, die Workload unterschiedlicher Mandanten korrekt zu administrieren, insbesondere bei über Clustergrenzen hinweg verteilter Arbeitslast. Bietet eine Kubernetes-Distribution Methoden für diese Szenarien an, ist dies ein echter Mehrwert.

Bisweilen sind beim Kubernetes-Einsatz beteiligte externe Firmen in der Pflicht, Auditing- und Compliance-­Aspekte zu berücksichtigen und darüber Nachweis zu führen. In einer Vanilla-Kubernetes-Umgebung gerät dies schnell zu einer umfangreichen Aufgabe, sodass eine Unterstützung in diesem Bereich ein wichtiges Feature einer kommerziellen Distribution sein kann.

Weiteres Kriterium für eine Kaufentscheidung ist neben der effizienten und einheitlichen Verwaltung ganzer Clusterverbünde das einfache Einbinden eigens geschriebener Software oder der Programme von Drittanbietern. Wer eine Marketplace-Integration samt großer Produktauswahl vorweisen kann, verschafft sich weitere Pluspunkte.

Zur Verringerung der Komplexität beim Verwalten von in Kubernetes bereitgestellten Workloads bietet sich die In­tegration eines Service Mesh an. Der bekannteste Vertreter ist derzeit die Open-­Source-Software Istio. Sie eröffnet einen einheitlichen und zentralen Weg zum Absichern, Verbinden und Überwachen von Microservices. Da Installation, Konfiguration und Betrieb eines Service Mesh einen gewissen Aufwand bedeuten, ist es wünschenswert, dass eine Kubernetes-Distribution hier zur Vereinfachung beitragen kann.

In jüngster Zeit erfreuen sich neben Microservices Serverless-Applikationen wachsender Beliebtheit. Für Entwickler vereinfachen sie vieles, da sie die Kubernetes-Komplexität mit einer neuen Ab­straktionsschicht reduzieren. Ein populäres Serverless-Framework für Kubernetes ist das von Google jüngst vorgestellte Knative, das ist wie Kubernetes selbst anbieterneutral. Eine Zusammenarbeit damit ist also wünschenswert.

Google Anthos

Als Erfinder von Kubernetes hat Google schon seit langer Zeit mit seiner Kubernetes Engine (GKE) ein Managed Kubernetes in der eigenen Public Cloud im Angebot. Bei Gesprächen mit Kunden hat der Hersteller jedoch herausgefunden, dass ein Großteil Kubernetes on Premises verwenden möchte. Dies war für Google Grund genug, mit Anthos einen hybriden Ansatz zu schaffen. Es ist somit kein reines On-Premises-Angebot, sondern benötigt immer eine Verbindung in die Google Cloud und integriert sich in deren Cloud-Ökosys­tem – insbesondere für eine einheitliche Verwaltung. Darüber können Kunden Kubernetes-Workload in der Cloud oder on Premises betreiben (Abbildung 2).

Für eine Anthos-Installation benötigt man neben den entsprechenden Ressourcen zum Betrieb der virtuellen Maschinen auch administrativen Zugriff auf eine VMware-vSphere-Umgebung. Mit anderen Hypervisoren arbeitet Anthos noch nicht. Zusätzlich ist Google eine Partnerschaft mit Cisco eingegangen, um ein einfaches Deployment auf Ciscos Hyperflex-­Umgebungen zu ermöglichen.

Hinsichtlich Load Balancing ist Anthos ebenfalls sehr flexibel. Der integrierte Load Balancer steht kurz vor der Auslieferung – bis dato gibt es eine Integration in F5 Big IP zum automatisierten Veröffentlichen von Services. Andere Load Balancer lassen sich natürlich auch einsetzen, allerdings fehlt dann die Möglichkeit, Services automatisiert zu veröffentlichen.

Das Installieren von Anthos erfordert im Moment noch etwas Geduld und Sorgfalt. Zuerst lädt man von Google eine VMware Appliance (OVA) herunter, die man in die eigene VMware-Umgebung importiert. Aus dieser kann man anschließend eine Admin-Workstation kreieren und darüber mithilfe des Tools gkectl eine GKE-on-Premises-Installation bewerkstelligen. Zuerst benutzt man gkectl dazu, einen Admin-Cluster zu erstellen, um in einem zweiten Schritt darin individuelle User-Kubernetes-Cluster zu erzeugen und später zu aktualisieren. Sobald die Installation abgeschlossen ist, kann man Anthos im GKE-Dashboard registrieren und dort die gleichen Informationen einsehen wie bei gewöhnlichen GKE-Clustern.

Anthos implementiert ein Service Mesh von Istio. Dabei ist Istio nicht auf einen einzelnen Kubernetes-Cluster beschränkt. Vielmehr kann sich das Service Mesh über verschiedene Cluster erstrecken – egal ob on Premises oder in der Public Cloud. Einen Wermutstropfen gibt es allerdings: Das Dashboard kann derzeit nur Informationen von GKE abrufen – laut Google dürfte es allerdings nicht mehr so lange dauern, bis Anthos-Cluster sich auf der Unterstützungsliste finden.

Netzwerktechnisch bringt Google Anthos weder eine Integration noch ein eigenes Overlay-Netz mit – stattdessen benutzt es für die Knotenkommunikation ein BGP-Mesh (jeder Knoten ist mit jedem anderen vermascht), sodass sich die Knoten über das darunterliegende Netz unterhalten können. Eine Kommunikation funk­tioniert jedoch nur zwischen den Knoten, daher heißt diese Konfiguration auch Island Mode. Auch in Sachen Network Policy geht Anthos keine neuen Wege. Es setzt auf das freie Calico, das sich bereits im Kubernetes-Umfeld bewährt hat.

Da Google Anthos dediziert für VMware vSphere konzipiert hat, zeigen sich natürlich Abhängigkeiten – die auch Vorteile bieten. In Sachen Storage setzt es auf die Storage-Abstraktion von vSphere. Damit lässt sich jeglicher unter vSpehre einbindbarer Storage ebenfalls für Anthos als Persistent Volume nutzen. Ein klarer Vorteil, da man VMware in vielen Enterprise-­Umgebungen als gesetzt ansehen darf.

Ein weiterer Pluspunkt für Anthos dürfte Googles Marketplace sein, von dessen Wachstum man sich wohl viel erhofft. Obwohl die Menge an Third-Party-Angeboten noch recht überschaubar ist, bietet der Marketplace doch schon das eine oder andere interessante, einfach integrierbare Produkt für Anthos, etwa von cloudbees, JFrog oder Instana.

Für die Administration der einzelnen Cluster oder Cluster-Verbünde setzt Anthos auf ein an GitOps angelehntes Vorgehen. Dabei speichert man die gewünschte Konfiguration in Dateien und legt diese in einem Git-Repository ab. Eine interne Komponente – Anthos Config Management – überwacht etwaige Änderungen und bringt diese in die Kubernetes-­Umgebungen.

Neben dem Deployen klassischer Kubernetes-Konstrukte erlaubt Anthos auch den Betrieb einer Serverless-Umgebung. Dafür installiert es das Open-Source-Frame­work Knative. Der Google Ma­naged Service Google Run basiert ebenfalls auf Knative und lässt sich so als Serverless-­Workload hybrid und ohne Vendor Lock-in betreiben.

Anthos funktioniert auch für Multi-­Cloud-Umgebungen: Man kann es auch bei AWS und Azure deployen und gelangt so zu einem standardisierten Layer über alle Clouds und Hersteller – inklusive eines überall nutzbaren, deklarativen Konfigurations- und Policy-Managements.

VMware vSphere 7/Tanzu

Seit geraumer Zeit verfolgt VMware die Strategie, sich für die zukünftige Infrastruktur- und Applikationswelt zu rüsten, in der virtuelle Maschinen nicht mehr die Hauptrolle spielen. Dafür hat man in Zusammenarbeit mit Google und Pivotal (das inzwischen VMware gehört) im Jahr 2018 das Produkt PKS veröffentlicht. Das konnte zwar schon im Unternehmensumfeld Fuß fassen, aber etablierten Konkurrenzprodukten wie OpenShift noch keinen großen Marktanteil entreißen.

Weil aber Kubernetes auch für VMware von strategischer Bedeutung ist, hat der Virtualisierungsspezialist letztes Jahr angekündigt, Teile von ESXi und vSphere umzuschreiben und somit Kubernetes nativ zu implementieren. Unternehmen, die auf VMware vSphere setzen – und das sind ja bekanntlich viele –, erhalten also mit dem jetzt freigegebenen vSphere 7 die Möglichkeit, Kubernetes-Cluster bereitzustellen, ohne ein neues Produkt einführen zu müssen.

Die dafür erforderlichen Komponenten hat VMware in der Suite Tanzu zusammengefasst, in der auch PKS aufgehen wird. Sobald man Kubernetes in einer vSphere-Umgebung aktiviert, findet eine Transformation in einen Kubernetes-Supervisor-Cluster statt (siehe Abbildung 3).

Dabei spielt die Installationsroutine eine Reihe virtueller Maschinen auf die als Control Plane fungierenden ESXi-Server. Die eigentliche Kommunikation zwischen ESXi-­Host und Control Plane wickeln die Spherelets ab, die namenstechnisch an kube­lets angelehnt sind. Schließlich ermöglichen die ESXi-Server mithilfe einer Container-Runtime Executable (CRX) das Ausführen von Kubernetes-Workload. Vieles von dem, was VMware mit Project Pacific geschaffen hat, könnte man auch mit existierenden Open-Source-Paketen bereitstellen – Projekte wir Kata Container, gVisor oder KubeVirt lassen grüßen. Für eine nahtlose Integration in die vSphere-­Welt ist VMware jedoch seinen eigenen Weg gegangen. So ist das Besondere am VMware-­Ansatz, dass traditionelle Administratoren weiterhin ihre Arbeit mit vCenter und dem vSphere-Webclient erledigen können, es aber gleichzeitig einen Zugriff für Entwickler auf Basis der Kubernetes-­API gibt. Ein weiterer großer Vorteil: Kubernetes ist in Form eines vSphere-Up­grades ohne großen Aufwand lauffähig. Den fertig erstellten Supervisor-Cluster kann man in einem zweiten Schritt zum Erzeugen weiterer Guest-Cluster verwenden.

VMware versucht mit vSphere 7, Kubernetes möglichst gut in das eigene Produktportfolio zu integrieren. Am stärksten wird dies bei der hauseigenen Netzwerkvirtualisierung NSX sichtbar. vSphere 7 mit Tanzu kann sich in ein existierendes NSX-T (die Stand-alone-Version von NSX für Nicht-VMware-Systeme) integrieren oder bringt ein Embedded NSX mit, falls im Unternehmen kein NSX vorhanden ist. Folglich dient NSX auch als standardmäßiges CNI im Supervisor-Cluster. Dabei nutzt Tanzu das verteilte Switching und Routing, die NSX-Firewalls, das Load Balancing von NSX und stellt eine Isolation der Namespaces sicher. Für Guest Cluster ist eine NSX-T-Integration sowie ein dediziertes Open-Source-CNI auf Basis von Open vSwitch auf der Roadmap, zurzeit ist aber noch Calico gesetzt.

Auch beim Storage versucht VMware neue Wege zu gehen und hat ein eigenes CSI namens Cloud Native Storage (CNS) implementiert, das nun Teil von vSphere ist. Dadurch kann Kubernetes dynamisch vSphere Storage bereitstellen und dies auch Administratoren gegenüber nachvollziehbar aufzeigen – Kubernetes-Disks sind nun also „First-Class“-Objekte in vSphere.

Mit Harbor stellt VMware zudem seine eigene Registry bereit. Der Artikel „Im sicheren Hafen“ stellt diese genauer vor (siehe „Quellen“). Sie bietet ebenfalls Enterprise-Funktionen wie RBAC-­Zugriff, die Möglichkeit, nur Signed Images zu nutzen oder Vul­nerability Scanning. Sie lässt sich entweder extern anbinden oder als integrierte Variante nutzen. Letzterer fehlen aber bis auf den RBAC-Zugriff derzeit noch die Enterprise-Funktionen.

Wie andere Hersteller auch hat VMware in den letzten Jahren versucht, einen funktionierenden Marketplace zu schaffen, steckt dabei aber immer noch in den Kinderschuhen.

Für eine bessere Kubernetes-Verwaltung in Multi-Cloud-Umgebungen und Verbünden hat VMware mit Tanzu Mission Control ein weiteres Produkt im Portfolio. Das lockt vor allem mit Enterprise-­Funktionen wie Auditing, Governance, Monitoring und Logging.

Docker EE

Seit Ende 2019 ist die Docker-Enterprise-­Plattform im Besitz von Mirantis. Die Plattform selbst beherrscht Kubernetes jedoch schon seit knapp zwei Jahren. Damit einhergehend kam die Einsicht, eigene Produktentwicklungen wie Docker Swarm oder Docker Cloud in der Enterprise-Plattform nicht mehr als alleinig gesetzte Tools voranzustellen, sondern den Kunden die Wahl zu lassen, ob sie nicht vielmehr mit dem Kubernetes-Äquivalent arbeiten möchten.

Die jüngste Version ist Docker EE 3.0 und stammt aus dem letzten Jahr. Wie auch die Mitbewerber hat Mirantis seine Kubernetes-Version vollständig von der CNCF zertifizieren lassen. Daneben bietet Docker EE eine Reihe von Enterprise-­Features. Die Docker Trusted Registry (DTR) kommt mit einem eingebauten Security-Scanner. Der kann Schwachstellen und veraltete Versionen in hochgeladenen Images erkennen und nutzt eine Vulnerability-Datenbank, die durch periodische Updates stets aktuell bleibt. Die DTR hat Notary als Bestandteil, das Images signieren und überprüfen kann. Daneben lässt sich die DTR recht einfach in bestehende Con­tinuous-Integration-/Continous-Delivery-Pipe­lines (CI/CD) integrieren. Zu diesem Zweck existieren Web-Hooks, über die sich Anpassungen vornehmen lassen.

Für die Verwaltung der Plattform, der darin liegenden Projekte und der Ressourcen (Netzwerke, Container, Services, Vol­umes) bringt Docker eine dedizierte Control Plane namens Universal Control Plane (UCP) mit. Die ist quasi das Herzstück des Produktes, integriert sich gut in DTR und bietet einen eigenen Authentifizierungsmechanismus. Mittlerweile gibt es eine Integration in das RBAC von Kubernetes. Darüber lassen sich per SAML existierende Identity-Provider anbinden. UCP kann zen­tral Auditing in der Umgebung ausführen und bietet Logging und Monitoring. Für Letzteres verfügt es über eine eingebaute Integration in Prometheus. Darüber hinaus besitzt UCP ein Key-Management-System (KMS) für Verschlüsselung und Secrets-Management-­Tools wie Vault. Selbst eine Integration von Helm und Tiller existiert bereits.

Mit dem GUI gelingt das Verwalten von Kubernetes-Clustern gut; allerdings berichten Anwender, dass die Nutzung des mitgelieferten CLI bisweilen hakelig ist. Hinsichtlich Storage besteht mittels UCP auch eine Integration in Kubernetes. Docker hat hier eine Reihe von Herstellern zertifiziert, unter anderem NetApp, EMC/Dell und VMware.

Red Hat OpenShift

Mit seiner Container-Plattform OpenShift ist Red Hat einer der etablierten Anbieter von Kubernetes-Plattformen fürs Enterprise. In den letzten Jahren konnte der Hersteller weltweit über 1000 Kunden für sein Produkt gewinnen. Die Plattform besteht aus einer Reihe modularer Komponenten und Dienste auf Basis von Red Hat Enterprise Linux, Docker und Kubernetes. Mit seiner jüngsten Version (aktuell ist 4.3) hat Red Hat versucht, eine Plattform zu schaffen, die für Administratoren und Entwickler gleichermaßen intuitiv bedienbar ist. Schon in der Version 4 hatte man den Installationsvorgang spürbar verbessert. Wie bei anderen kommerziellen Angeboten lässt sich ein Versionsupgrade auf neue Kubernetes-­Versionen ohne allzu großen Aufwand bewerkstelligen. Auch funktioniert das Skalieren von Clustern einfach durch Hinzufügen neuer Knoten.

OpenShift ist für einen Einsatz auch in heterogenen und hybriden Umgebungen konzipiert. Außer auf Virtualisierungsplattformen wie VMware oder der hauseigenen Enterprise Virtualization kann man es in Amazon Web Services (AWS), Microsoft Azure, Google Cloud IBM Cloud oder Red Hat OpenStack betreiben.

Bei der Oberfläche hat sich der Hersteller Mühe gegeben, sie ist gut bedienbar. Aber auch eine eigene CLI ist Teil des Produktes. OpenShift bringt eine eigene, nahtlos ins Produkt integrierte CI/CD-Pipeline mit. Dank der weiten Verbreitung funk­tionieren aber viele andere DevOps-Tools ebenfalls damit. Wer etwa mit Azure DevOps arbeitet, wird die OpenShift-Integration begrüßen. Auch die jüngsten Trends geht OpenShift mit: Das integrierte Services Mesh basiert auf dem Gespann Istio-Kiali-Jaeger und hilft insbesondere beim Entwickeln von Microservices. Mit dem auf Knative basierenden OpenShift Serverless lassen sich Serverless-Lösungen realisieren.

Netzwerktechnisch nutzt Red Hat seinen eigenen SDN-Ansatz, der per Open vSwitch (OVS) ein Overlay-Netzwerk konfiguriert. Dies erlaubt netzwerktechnisch das Isolieren verschiedener Work­loads und eine Multi-Tenancy. Auch die granulare Konfiguration des Ingress-Netzwerks ist damit möglich.

SUSE CaaS Platform

Auch die Nürnberger Firma SUSE hat seit geraumer Zeit ein Auge auf Kubernetes geworfen und im Herbst letzten Jahres SUSE CaaS Platform in der Version 4 veröffentlicht.

Wie bei den meisten anderen Enterprise-­Paketen erlaubt auch SUSEs Plattform ein automatisiertes Installieren und Aktualisieren der verschiedenen Kubernetes-Versionen. Dabei können Anwender mit einem kleinen Cluster beginnen und diesen sukzessive horizontal skalieren. Das Produkt selbst lässt sich entweder Bare-Metal oder mit Hersteller-Support in einer VMware vSphere-Umgebungen aufspielen. Für die Zukunft ist außerdem eine Anbindung an Public-Cloud-Provider angedacht.

Ein besonderes Augenmerk hat SUSE auf das Thema Sicherheit gerichtet. Neben einem einheitlichen RBAC-System, Image-­Scanning in der Registry, konsequenter Verschlüsselung des gesamten Datenverkehrs im Cluster gefällt auch die Integration von Cilium. Das ist ein Open-Source-CNI-Plug-in, mit dessen Hilfe sich Sicherheits-Policies zentral und einheitlich verwalten lassen.

Rancher 2

Die aus Kalifornien stammende Firma Rancher Labs hat mit Rancher 2 eine Multi-Cloud-Plattform fürs Kubernetes-Management geschaffen, die im letzten Jahr einiges Interesse aus der Industrie auf sich ziehen konnte. Als Managementplattform integriert Rancher 2 natürlich die hauseigene Rancher Kubernetes Engine (RKE). RKE selbst läuft auf allen gängigen Linux-Distributionen mit installiertem Docker, wobei der Hersteller Ubuntu 16.04 präferiert, da man mit dieser Betriebssystemversion die meisten Tests und Erfahrungen gemacht hat. Daneben arbeitet Rancher mit einer Reihe von Kubernetes-­Distributionen in der Cloud, unter anderem Google GKE, Azure AKS, Amazon EKS und Digital Ocean.

Administratoren und Entwickler erhalten mit Rancher eine zentralisierte Plattform zur Authentifizierung mit Active-Directory-Einbindung, Zugriffssteuerung mit RBAC, Monitoring und Health Checks – unabhängig davon, in welcher Umgebung die Kubernetes-Distribution läuft.

Technisch setzt Rancher auf Open-Source-Werkzeuge und integriert diese in seine Produkt: Zum Monitoring etwa dienen Prometheus und Grafana, die out of the box lauffähig sind. Darüber hinaus vereinfacht die aktuelle Version das Installieren des Service-Mesh-Tools Istio. Wie bei anderen Produkten auch sind neben Prometheus und Grafana Jaeger für Monitoring und Kiali als Dashboard-Lösung für Netzverkehrvisualisierung und Telemetrie im Einsatz.

Um Entwicklern das Leben zu vereinfachen, hat Rancher ein weiteres Open-Source-Produkt veröffentlicht – Rio, eine Application Deployment Engine für Kubernetes, die auf jedem Kubernetes-Cluster läuft. Rio besteht aus einer Reihe von Custom Resource Definitions (CRD) und einer CLI und erlaubt ein einfaches Deployen von DNS, HTTPS, Routing, Autoscaling, Git-triggered Builds oder anderen Komponenten, ohne dass sich die Nutzer in alle Kubernetes-Untiefen einarbeiten müssen.

Netzwerktechnisch lässt Rancher den Nutzern die freie Wahl und liefert kein eigenes CNI-Plug-in oder SDN-Integration mit. Als Standard wirkt hier Canal, das den Netzwerkverkehr über VXLAN kapselt sowie die Definition von Netz- und Ingress/Egress-Policies ermöglicht. Alternativ lassen sich auch andere CNI-Plug-ins wie Flannel, Calico oder Weave einsetzen.

Fazit

Der Markt für On-Premises-Kubernetes hat deutlich an Fahrt aufgenommen. Daher versuchen gerade die großen Hersteller wie VMware, Google und Red Hat, sich mit vielen neuen Features zu posi­tionieren und entsprechend zu überzeugen. Auch das von Mirantis übernommene Docker EE zeigt solide Leistung und zeichnet sich vor allem durch gute Administrierbarkeit aus. Der deutsche Hersteller SUSE ist mit der CaaS-Plattform inzwischen gut vertreten und kann bei allen technischen Neuerungen Schritt halten. Rancher begeistert vor allem durch die einfache Installation und gute Multi-Cloud-­Einbindung. Worauf letztlich die Wahl fällt, hängt wie immer von der eigenen Gewichtung der verschiedenen Produktaspekte ab. (avr@ix.de)

Dr. Guido-Arndt Söldner

ist Geschäftsführer der Söldner Consult GmbH und beschäftigt sich mit den Themen Cloud-Computing und Enterprise-Programmierung.

Torsten Volk

ist Managing Research Director im Bereich Hybrid Cloud, SDDC und KI-Praxis von Enterprise Management Associates, einer IT-Research-Firma mit Sitz in Boulder, Colorado.