iX 5/2020
S. 64
Review
Containermanagement
und

Kommerzielle Kubernetes-Distributionen im Vergleich

Steuerjonglage

Guido-Arndt S?ldner, Torsten Volk

Wie kaum ein anderes IT-Produkt kann Kubernetes in den letzten Jahren auf eine gro?e Erfolgsgeschichte verweisen. Doch das Handling des m?chtigen Open-Source-Projekts ist komplex. Kommerzielle Distributionen versprechen hier Abhilfe.

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.

StackOverflow erfasst und klassifiziert die Herausforderungen beim Kubernetes-Einsatz (Abb. 1).

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).

Googles Multi-Cloud-Plattform l?uft im eigenen Rechenzentrum und ben?tigt eine Anbindung an Googles Public Cloud (Abb. 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).

Durch das Aktivieren von Project Pacific mutiert vSphere?7 zur Kubernetes-Plattform (Abb. 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.

VMwares Mission Control erm?glicht es, Governance-Aspekte in Kubernetes-Clustern besser in den Griff zu bekommen (Abb. 4).

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 Docker Enterprise Edition erlaubt den Einsatz von Kubernetes als App Scheduler (Abb. 5).

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.

Auch SUSE setzt mit seiner CaaS Platform auf Kubernetes als zentralen Baustein (Abb. 6).
SUSE

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.

Kommerzielle Kubernetes-Distributionen
Google Anthos VMware vSphere?7/Tanzu Docker EE Red Hat OpenShift SUSE Caas Platform Rancher 2
Installation neutral neutral plus neutral plus plus
IAM-Anbindung plus neutral neutral plus neutral neutral
Multi-Cloud plus plus minus neutral neutral plus
Logging plus neutral plus plus neutral neutral
Monitoring plus plus plus plus neutral plus
Storage-Integration neutral plus minus plus minus plus
SDN neutral plus neutral neutral neutral minus
Serverless plus minus neutral plus minus plus
Security plus plus plus plus plus minus
Upgrading neutral neutral neutral plus neutral neutral
Scaling plus plus neutral neutral neutral plus
Service Mesh plus plus neutral plus plus neutral
minus: verbesserungsf?hig; neutral: funktioniert wie erwartet; plus: besonders positiv

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. ([email protected])

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.

Kommentare lesen (1 Beitrag)

汤姆叔叔影院