10. Juli 2019

OpenShift vs. Kubernetes

commerce-container-export-379964

Welche Vor- und Nachteile haben Kubernetes und OpenShift? Dieser Frage geht ti&m-Surfer Bernd Leinfelder in seinem aktuellen Blog-Beitrag nach.

Kubernetes, ein ursprünglich von Google gestartetes Projekt, hat sich mittlerweile als Standardprodukt für die Container Orchestrierung im Container-as-a-Service (CaaS)-Umfeld etabliert. Kubernetes ist eine flexibel einsetzbare, weitgehend den Bedürfnissen anpassbare Plattform. OpenShift dagegen bietet zusätzliches Tooling, um das Setup und den Betrieb einer CaaS-Plattform zu vereinfachen und Build Prozesse zu automatisieren.

Einige der wichtigsten Unterschiede sind im Folgenden dargestellt.

 

Produkt vs. Projekt

OpenShift ist in erster Linie eine Kubernetes Distribution, die von Red Hat als Produkt vertrieben wird. Als Analogie mag hier der Linux Kernel dienen: So wie Linux Distributionen aus einem Kernel ein nutzbares Betriebssystem machen, das einfach als Ganzes installiert werden kann, macht OpenShift aus Kubernetes eine out of the box nutzbare integrierte Container Plattform.

Als von Red Hat vertriebenes Produkt ist für OpenShift Herstellersupport erhältlich. Wer keinen Wert auf den Herstellersupport legt, kann aber mit OKD (früher OpenShift Origin) auch eine Community Edition nutzen, die die meisten Komponenten von OpenShift Enterprise inkludiert.

 

Plattformsupport

Einen signifikanten Unterschied gibt es in den unterstützten Plattformen. Während Kubernetes auf praktisch allen Systemen, inklusive MacOS und Windows zum Laufen zu bekommen ist, beschränkt sich OpenShift auf Red Hat Enterprise Linux, Fedora und CentOS.

 

Secure by Default

Mit Hinsicht auf die anvisierte Zielgruppe sind einige Sicherheitsoptionen in OpenShift strenger konfiguriert als in Kubernetes. So ist es per Default nicht möglich, in OpenShift Container mit Root-Rechten laufen zu lassen. Berechtigungsmodell in OpenShift ist immer RBAC, während Kubernetes RBAC erst seit Version 1.8 (Sept. 2017) unterstützt.

 

Netzwerkmodell

Networking im Kubernetes Cluster wird immer über ein Software Defined Network (SDN) abgewickelt. Die Implementierung kann frei gewählt werden. Alleine auf der Kubernetes Webseite sind derzeit etwa 20 verschiedene Netzwerkimplementierungen aufgeführt. Allen gemeinsam sind folgende Eigenschaften:

  • Alle Pods im Kubernetes Cluster können ohne NAT mit allen anderen Pods kommunizieren.
  • Alle Services auf einem Host (zum Beispiel System Deamons) können mit allen Pods auf dem gleichen Host kommunizieren.

Die einzelnen Implementierungen unterscheiden sich beispielsweise in der unterstützten Backend Technologie, es gibt beispielsweise eine Implementierung speziell für NSX-T (die Netzwerkvirtualisierungs- und Sicherheitsplattform von VMware), für Google Cloud Engine oder einfache Implementierungen wie Flannel, die ein einfaches, flaches Netzwerk bereitstellen. Dazwischen gibt es Implementierungen, die unterschiedliche Level von Sicherheits- und Routingfunktionalität bereitstellen und so je nach Use-Case optimale Lösungen bieten.

OpenShift stellt dem Anwender nur drei sogenannte Netzwerkplugins zur Auswahl: Mit ovs-subnet wird ein flaches Netzwerk bereitgestellt, in dem jeder Pod mit jedem anderen Pod kommunizieren kann. ovs-multitenant ermöglicht eine Isolierung auf Projekt-Level. Pods aus einem Projekt können nicht direkt mit Pods aus einem anderen Projekt kommunizieren. Am Granularsten lassen sich Netzwerkverbindungen mit ovs-networkpolicy definieren. Mit diesem Plugin können Punkt-zu-Punkt Verbindungen für jeden Pod definiert werden.

 

Build & Deployment Automatisierung

OpenShift bietet umfangreiche Features im Bereich Continuous Build und Deployment. Mit Build- und ImageStreams werden Möglichkeiten bereitgestellt, um vollautomatische Source-to-Image (S2I) Prozesse aufzusetzen. Kubernetes sieht out of the box keine solchen Möglichkeiten vor.

 

Fazit

Zusammengefasst vereinfacht OpenShift die Bereitstellung einer Container Plattform. Während mittels Kubernetes in einem Custom Setup die Möglichkeiten der Containerisierung bis in die hinterste Ecke ausgelotet werden können, bietet OpenShift eine sinnvolle Vorauswahl für die gängigen Einsatzszenarien. Wer auf Herstellersupport für seine On-premise Containerplattform wert legt, wird um OpenShift Enterprise nicht herumkommen. Wer mit dem hervorragenden Community Support auskommt, wird mit Kubernetes oder OKD ohne Probleme eine reife, stabile Plattform aufbauen können.


Bernd  Leinfelder
Bernd Leinfelder

Bernd Leinfelder ist seit 2016 System Architekt bei ti&m. Er verfügt über langjährige Erfahrungen in Softwareentwicklung und System Engineering. Neben seiner Tätigkeit bei ti&m leitet er den Fachbereich Enterprise Computing an der Fernfachhochschule Schweiz und doziert dort zu Robustheit und Wartbarkeit verteilter Software. Er hält diverse Zertifizierungen in den Bereichen Cloud Computing, IT-Security und IT-Audit.

Weitere Beiträge

Handling the Communication Channel Shift to Social Media
How to Mine Gold: Handling the Communication Channel Shift to Social Media

Data being the gold of the 21st century is a given fact by now. Still, most companies do not have a strategy on how to handle social media data, even though it has become the main channel of client communication. To tackle this problem, we recently carried out a ti&m garage with a major Swiss bank.

Mehr erfahren
Interview
«Das Gesetz unterscheidet nicht zwischen in- und ausländischen Clouds»

Viele Banken haben erst begonnen, sich intensiver mit dem Thema Cloud auseinanderzusetzen. Noch gibt es aber Bedenken, vor allem wie sich die Cloud mit dem Bankgeheimnis vereinbaren lässt. Antworten dazu gibt Martin Hess, Leiter Digitalisierung und Wirtschaftspolitik sowie Direktionsmitglied der Schweizerischen Bankiervereinigung.

Mehr erfahren
André_Rohrbach_beitrag
Digital first! Jetzt wirklich?

Wie man Digitalisierungsinitiativen zum Erfolg führt, indem man den Menschen miteinbezieht. Der Energiedienstleister ewz überträgt Verantwortung in die Teams, um den sich verändernden Kundenbedürfnissen gerecht zu werden.

Mehr erfahren
Identitätskrise 750x410
Identitätskrise - wer bist du wirklich?

Digitale Identität // Eine zuverlässige digitale Identität ist zentral für eine sichere Informationsgesellschaft. Einige europäische Länder stellen für ihre Einwohner umfassende digitale Identifikationssysteme zur Verfügung. Wo steht die Schweiz und welche Instanzen könnten eine globale digitale Identität bereitstellen?

Mehr erfahren
Trust 750x410
Authentication Is Good, Trust Is Better. What About Trusting Delegated Identity?

Trust in a relationship is a must and this is not only holds true for private lives but also in the virtual life. While trustworthiness for established authentication protocols is mainly based on agreement between entities, certificates and keys, trust in the identity delegation context is ambiguous because the owner might not be the consumer of the API. This post addresses some trust concerns when introducing protocols based on identity delegation that de-facto lead to an identity paradigm shift.

Mehr erfahren