News zu Tech Portfolio
Wir vergleichen die zwei größten Kubernetes Distributionen am Markt hinsichtlich der Faktoren Support, Security, Installation, Lizenzierung, Updates/Upgrades, Partnerunterstützung und Einhalten der Standards der CNCF.
Red Hat OpenShift, wir betrachten ausschließlich Version 4.X, kommt als All-in-One Lösung und bietet sowohl die Kubernetes Engine, als auch alle Management Tools (Web Console, CLI, Umfangreiche Developer Tools) im Gesamtpaket.
SUSE Rancher ist hingegen zunächst einmal eine Management Platform für verschiedene Kubernetes Distributionen. D.h. Rancher wird entweder außerhalb oder innerhalb einer bestehenden Kubernetes Cluster Umgebung installiert und kann sich dann an diesen Cluster anknüpfen und diesen verwalten. Weiterhin können mit Rancher auch weitere Kubernetes Cluster installiert werden, wenn der Infrastrukturanbieter unterstützt wird (vSphere, AWS, …).
Damit der Vergleich gelingt, wird eine Red Hat OpenShift Container Platform als UPI (User-provisioned infrastructure) und eine SUSE Rancher Installation auf einem SUSE RKE Cluster (Rancher Kubernetes Engine) verglichen. RKE ist die Kubernetes Engine für den Cluster, den die Rancher Installation verwalten wird.
Laut dem Forrester Wave Report 2020, liegt Red Hat OpenShift sowohl in der Strategie, als auch im aktuellen Angebot vor allen anderen Anbietern, inklusive SUSE Rancher.
Quelle: Forrester WAVE LEADER 2020 Report, https://more.suse.com/fy21-global-web-landing-page-forrester-new-wave-enterprise-container-platform
Die Installation eines produktiven Kubernetes Cluster im eigenen Rechenzentrum ist immer mit einigen Aufwand Verbunden. Wir rechnen für den Vergleich der beiden Lösungen die Vorbereitung und Anbindung der Ressourcen wie Netzwerk, Storage und Authentication nicht mit in den Vergleich ein. Betrachtet wird die Installation eines 6 Knoten Cluster, bei dem 3 Knoten als Master und 3 Knoten als Worker konfiguriert sind.
OpenShift bietet, je nach dem auf welche Plattform installiert werden soll, verschiedene Möglichkeiten des Deployments an. Um einen Vergleich zu ermöglichen, wird hier die Bare Metal “UPI” (User Provided Infrastructure) betrachtet.
Für die Installation wird eine Bootstrap Maschine benötigt, auf der eine beliebige Linux Distribution, vorzugsweise aber ein Derivat von Red Hat Enterprise Linux, ausgeführt werden kann.
Die Installation geschieht dann über einen TFTP und DHCP Mechanismus, mit vorbereiteten Ignition Files. Die gesamte Red Hat OpenShift Installation basiert auf Red Hat Enterprise Linux CoreOS (RHCOS) Maschinen, die zentral vom OpenShift System verwaltet werden. Es ist nicht gedacht oder gewünscht, sich direkt auf die Red Hat CoreOS Maschinen zu verbinden, außer für Troubleshooting Aktivitäten. Die Maschinen werden über zentrale MachineConfigs im OpenShift Cluster gesteuert und konfiguriert.
Bei einer UPI Installation müssen folgende Punkte vorbereitet sein:
Wenn die Vorbereitungen vollständig sind, kann die Installation innerhalb weniger Stunden (2–3) durchgeführt werden.
Da Rancher an sich nur eine Verwaltungssoftware für Kubernetes Cluster ist, muss diese auf einer Infrastruktur (Docker, virtuelle Maschine, K3S, Kubernetes Cluster) installiert werden. Für unser Beispiel wird vor der eigentlichen Rancher Installation also ein Kubernetes Cluster mit “RKE” installiert. Da RKE ebenfalls von SUSE bzw. von Rancher stammt, ist dies die bevorzugte Kubernetes Engine für Rancher.
Um RKE installieren zu können, müssen die entsprechenden Knoten als Hardware oder virtuelle Maschinen mit einem unterstützten Linux Betriebssystem installiert sein. Dies kann, wenn Automatisierungstools wie Kickstart Dateien und Ansible genutzt werden, innerhalb 1–2 Stunden erledigt sein. Bei manueller Installation und Konfiguration der Knoten, kann dies 3–6 Stunden in Anspruch nehmen. Unterstützte Betriebssysteme für RKE sind:
Kubernetes ist ein Softwareprodukt mit häufigen Release Zyklen und mit einer Vielzahl an Komponenten die zusammenspielen müssen. Dadurch ist es für Anbieter eine Herausforderung, sowohl eine stabil funktionierende Distribution, als auch aktuelle Software Versionen anzubieten.
Red Hat veröffentlicht etwa alle 3 Monate eine neue Hauptversion der OpenShift Container Platform (OCP). Aktuell ist 4.8 (Release Datum am 27.07.2021). Die Updates lassen sich bequem über die Web Konsole oder das Commandline Interface “oc” einspielen.
Hier genügt ein
oc adm upgrade --to=4.7.19 |
um auf die gewünschte Version zu aktualisieren. Soll ein Upgrade auf die nächste Major Version (4.7 → 4.8) geschehen, muss vorher der aktuelle Channel gewechselt werden (von stable‑4.7 auf stable‑4.8).
! Upgradepfad
Nicht jede Version kann zu jeder Version aktualisiert werden. Um die korrekte Zielversion von der aktuell installierten Version zu ermitteln, bietet Red Hat entsprechende Tools an. Die einfachste Möglichkeit ist der Update Graph:
Ein Upgrade kann, je nachdem wie viele Knoten installiert sind, von mehreren Stunden bis zu einigen Tagen andauern.
Ein Upgrade per Rancher RKE ist recht simpel. In der vorliegenden “cluster.yml” Datei, muss die Kubernetes Version angepasst werden (kubernetes_version: “v1.20.9‑rancher1‑1”).
Danach kann mit
rke up --config cluster.yml |
das Update angestoßen werden.
Je nach Knoten Anzahl kann das Update mehrere Stunden in Anspruch nehmen, ist aber in der Regel deutlich schneller fertig im Vergleich zu OpenShift.
Ein Kern Feature der Container basierten Software ist es, dass die Integration in CI/CD und GitOps sehr gut möglich und sinnvoll ist. Dies beschleunigt die Entwicklungs- und Updatezyklen und vermeidet individuelle Fehler durch Standardisierung.
Aus der Sichtweise eine Software Entwicklers hat Kubernetes an sich einige Vorteile, die in diesem Artikel nicht intensiv dargestellt werden sollen. Im direkten Vergleich der beiden Lösungen, hat Red Hat OpenShift die Nase vorn, wenn es um das Toolset für Entwickler Out-of-the-Box geht. Leider geht Red Hat an der ein oder anderen Stelle (S2I und Red Hat Marketplace mit Operators) einen eigenen Weg, ab von dem in der Community etablierten Mechanismen (Dockerfiles, Helm Charts), welche aber ebenfalls ohne Einschränkungen in OpenShift genutzt werden können.
Gerade im Bereich des sich etablierenden “GitOps” Modells des Deployments, hat Red Hat die OpenSource Lösungen “ArgoCD” und “Tekton” als “OpenShift GitOps” und “OpenShift Pipelines” offiziell in die Distribution ab Version 4.7 aufgenommen. Damit kann aus Entwickler und Administrator Sicht eine schnelle und saubere Deployment Strategie aufgebaut werden.
Rancher bietet mit dem neuen “Continuous Delivery” Tool ebenfalls ein nützliches GitOps Tool Out-of-the-Box. Damit können Ressourcen aus Git Repositories in definierten Namespaces deployed werden. Ebenfalls können im Rancher verwalteten Kubernetes Cluster auch “ArgoCD” und “Tekton” mit wenig Aufwand installiert und verwendet werden.
Ein wichtiger Punkt für den Einsatz in Enterprise Umgebungen ist der verfügbare Support durch Hersteller und Partner. Gerade bei Plattformen, die recht häufig neue Software Releases veröffentlichen, können mögliche Probleme mit kompetenten Partnern und einem guten Hersteller Support schnell gelöst werden.
Der Herstellersupport von Red Hat genießt einen sehr guten Ruf und glänzt durch einen sehr hohe Expertise für die angebotenen Produkte. Im Problemfall wird schnell geholfen, sodass Unterbrechungen minimiert werden können.
Einen Hauptteil des Support decken allerdings sehr gut qualifizierte Partner, wie die ASPICON GmbH, für die Endkunden ab. Hier kann eine Betreuung ab der Planung bis zum Betrieb hin angeboten werden.
Der Herstellersupport umfasst hier, neben den Kernprodukten Rancher und RKE auch das Kubernetes Kernsystem. Auch SUSE baut die Partnerlandschaft strategisch aus und qualifiziert die Partner für den umfassenden Support der Rancher Umgebungen.
Ein wichtiger Punkt für den Einsatz in Enterprise Umgebungen ist der verfügbare Support durch Hersteller und Partner. Gerade bei Plattformen, die recht häufig neue Software Releases veröffentlichen, können mögliche Probleme mit kompetenten Partnern und einem guten Hersteller Support schnell gelöst werden.
Die OCP Plattform berechnet die Support Kosten pro zugewiesener CPU auf den Worker Knoten. Die CPUs der Master werden dabei nicht betrachtet.
Die Supportgebühr berechnet sich hierbei nach der Nummer der Knoten. Die installierten CPUs oder vCPUs werden dabei nicht betrachtet.
Für eine mögliche Migration hin zu Container basierten Applikationen, sind auch Windows native Container ein wichtiger Baustein. Vor allem, wenn Software auf Basis von älteren .NET Frameworks geschrieben ist, kann diese mit Hilfe von Windows Containern auf einen Kubernetes Cluster migriert werden. Um Windows Container im Kubernetes Cluster betreiben zu können, müssen entsprechende Windows Server als Worker Knoten dem Cluster hinzugefügt werden.
Ab Version 4.6 Unterstützt die OpenShift Container Platform den Betrieb von Windows Servern als Worker Knoten im Cluster. Bedingung ist hierbei, dass die Installer Provided Infrastructure Methode für die Installation des OCP Clusters gewählt wurde. Die User Provided Infrastructure wird nicht unterstützt.
Somit können Windows Server Knoten beispielsweise in der Amazon AWS, Microsoft Azure oder auch im eigenen Rechenzentrum auf einem VMware vSphere Cluster installiert und betrieben werden.
Auch mit Rancher lassen sich Windows Server als Kubernetes Worker Knoten betreiben. Dafür muss der Cluster bei der Erstellung für Windows Support aktiviert werden. Die Master, bzw. Controlplane Knoten müssen dabei, wie im OCP Cluster, mit einem Linux Betriebssystem betrieben werden. Die Container Engine auf den Windows Server Knoten muss dabei eine Docker Enterprise Edition sein.
Wenn Anwendungen als Container bereitgestellt werden, erhöht sich zunächst einmal die Komplexität im Gesamtkonstrukt, da hier mehrere Komponenten zusammenspielen müssen. Das kann leicht dazu führen, dass Sicherheitsaspekte außer Augen gelassen werden, oder einfach nicht mehr im Fokus stehen. Die Hersteller bieten verschiedene Möglichkeiten diese Themen zu adressieren.
Im OCP Cluster gibt es Out-of-the-Box mehrere Features, die die Sicherheit im Cluster erhöhen. Das sind beispielsweise “Security Context Constraints”, die verhindern, dass sich Container per default als “root” oder im erhöhten Rechten starten können. Weiterhin ist RBAC per default aktiviert und steuert den Zugriff per RoleBindings im Cluster. Im OpenShift gibt es weiterhin die Möglichkeit Groups anzulegen, denen User zugewiesen und die wiederum in RoleBindings referenziert werden. Jedes neue Projekt bekommt einen Bereich von User- und GroupIDs zugewiesen, die in den jeweiligen Pods verwendet werden sollten. Auch der Einsatz von NetworkPolicies ist eine Option, die die Sicherheit im Cluster erhöht.
Auch bei Suse Rancher wird RBAC automatisch im Cluster aktiviert. Die User können über Identity Provider (wie auch im OpenShift) gesteuert werden, so dass eine Anmeldung über Active Directory möglich ist. Rancher bietet darüber hinaus die Möglichkeit, die User Verwaltung über mehrere Cluster an einem zentralen Punkt zu steuern.
Darüber hinausgehende Einschränkungen für Pods, bspw. im Bezug auf Security Contexte, sind nicht per default aktiviert, können aber im Rahmen der Unterstützung der Kubernetes Engine, nachkonfiguriert werden.
Ein eindeutiger Sieger kann im Vergleich nicht ausgemacht werden. Generell sollte im Enterprise Bereich eher auf Red Hat OpenShift gesetzt werden, da die Partner- und Herstellersupportleistung zum aktuellen Zeitpunkt etwas umfangreicher ist. Zudem ist Red Hat OpenShift auf große Umgebungen und Skalierungen ausgelegt.
Wenn ein bestimmter Teil der Applikationen in einem kürzeren Zeitraum in einer bestehenden Infrastruktur bereitgestellt werden soll, ist Suse Rancher wohl die bessere Wahl. Auch ist der Migrationsaufwand im Vergleich zu OpenShift nicht ganz so hoch, da viele Sicherheitsfeatures, die Red Hat bei OpenShift eingeführt hat, nicht vorhanden sind. Daher ist dies näher an den Kubernetes Installationen der Public Cloud Provider, bietet aber nicht die Sicherheit wie ein OpenShift Cluster.
Interessiert? Hier gibt es weitere Posts zum Thema Kubernetes, OpenShift oder Rancher .
Share this article