«Was ist der Unterschied zwischen Kubernetes und OpenShift?» – diese Frage taucht erstaunlich oft auf. Tatsächlich ist es vergleichbar mit der Frage, was der Unterschied zwischen einem Auto und einem Motor ist. Fährt man mit dem Auto, so ist es das Endprodukt, das sofort genutzt werden kann: man setzt sich einfach hinein und fährt los. Im Gegensatz dazu muss der Motor zunächst mit vielen anderen Komponenten ergänzt werden, um letztendlich das gleiche Auto zu erhalten.
Daher ist Kubernetes der Motor, um den das Auto (die Plattform) OpenShift gebaut ist, das Sie zu Ihrem Ziel transportiert.
In diesem Artikel möchten wir an einige wesentliche Punkte erinnern und sie etwas detaillierter erläutern:
- Kubernetes ist das Herz der OpenShift-Plattform und ist zu 100 % ein zertifiziertes Kubernetes mit vollständig offenem Code und ohne jegliche Proprietärität. Kurz gesagt:
- Die API für das OpenShift-Cluster ist ein hundertprozentiges Kubernetes.
- Wenn ein Container in einem anderen Kubernetes-System funktioniert, wird er ohne Änderungen auch auf OpenShift funktionieren. Änderungen an den Anwendungen sind nicht erforderlich.
- OpenShift erweitert Kubernetes um nützliche Funktionen und Möglichkeiten. Wie ein Auto ist OpenShift sofort einsatzbereit, kann direkt in die Produktion gehen und, wie wir gleich zeigen werden, macht es das Leben von Entwicklern erheblich einfacher. Deshalb ist OpenShift in zweifacher Hinsicht einzigartig. Es ist sowohl eine erfolgreiche, weithin bekannte PaaS-Plattform der Unternehmensklasse aus der Sicht von Entwicklern als auch eine extrem zuverlässige Lösung der Klasse Container-as-a-Service aus der Perspektive der industriellen Nutzung.
OpenShift ist Kubernetes mit 100% Zertifizierung durch die CNCF-Stiftung.
Im Kern von OpenShift steht . Daher sind die Benutzer nach entsprechender Schulung von der Leistungsfähigkeit von kubectl begeistert. Und diejenigen, die von einem Kubernetes-Cluster auf OpenShift umgestiegen sind, berichten oft, wie sehr sie es schätzen, dass nach der Umstellung der kubeconfig auf das OpenShift-Cluster alle vorhandenen Skripte einwandfrei funktionieren.
Sie haben sicherlich von der OpenShift-Befehlszeilenanwendung namens OC gehört. Sie ist vollständig kompatibel mit den Befehlen von kubectl und bietet zudem einige hilfreiche Werkzeuge, die bei einer Vielzahl von Aufgaben nützlich sind. Lassen Sie uns zunächst etwas genauer auf die Kompatibilität zwischen OC und kubectl eingehen:
kubectl-Befehle
OC-Befehle
kubectl get pods
oc get pods
kubectl get namespaces
oc get namespaces
kubectl create -f deployment.yaml
oc create -f deployment.yaml
So sehen die Ergebnisse der Verwendung von kubectl mit der OpenShift-API aus:
• kubectl get pods – gibt wie erwartet die Pods zurück.
• kubectl get namespaces – gibt wie erwartet die Namespaces zurück.
Der Befehl kubectl create -f mydeployment.yaml erstellt Kubernetes-Ressourcen exakt so, wie auf jeder anderen Kubernetes-Plattform, wie im folgenden Video gezeigt:
Anders ausgedrückt, alle Kubernetes-APIs sind vollständig in OpenShift verfügbar, wobei 100% Kompatibilität gewährleistet ist. Deshalb .
OpenShift erweitert Kubernetes um nützliche Funktionen.
Die Kubernetes-APIs sind in OpenShift zu 100 % verfügbar, jedoch mangelt es der standardmäßigen Kubernetes-Utility kubectl an Funktionalität und Benutzerfreundlichkeit. Daher hat Red Hat Kubernetes um nützliche Funktionen und Befehlszeilen-Tools wie OC (kurz für OpenShift-Client) und ODO (OpenShift DO, dieses Tool ist für Entwickler gedacht) erweitert.
1. Das Tool OC ist eine leistungsfähigere und benutzerfreundlichere Variante von Kubectl.
Im Gegensatz zu kubectl ermöglicht es beispielsweise das Erstellen neuer Namespaces und das einfache Wechseln des Kontexts. Zudem bietet es eine Reihe nützlicher Befehle für Entwickler, etwa zum Erstellen von Container-Images und zum Bereitstellen von Anwendungen direkt aus Quellcode oder Binärdateien (Source-to-image, s2i).
Lassen Sie uns anhand von Beispielen betrachten, wie die integrierten Helfer und die erweiterte Funktionalität des Tools OC die tägliche Arbeit erleichtern.
Beispiel eins – Verwaltung von Namensräumen. In jedem Kubernetes-Cluster gibt es mehrere Namensräume. Diese werden typischerweise verwendet, um Entwicklungs- und Produktionsumgebungen zu erstellen, können aber auch dazu dienen, jedem Entwickler eine persönliche "Sandkiste" zur Verfügung zu stellen. In der Praxis führt dies dazu, dass Entwickler häufig zwischen den Namensräumen wechseln müssen, da kubectl im Kontext des aktuellen Namensraums arbeitet. Daher nutzen viele für kubectl hilfreiche Skripte. Bei der Verwendung von OC reicht es aus, um auf den gewünschten Namensraum zu wechseln, einfach "oc project raum_name" zu sagen.
Erinnern Sie sich nicht, wie das benötigte Namespace heißt? Kein Problem, geben Sie einfach „oc get projects“ ein, um die vollständige Liste anzuzeigen. Fragen Sie sich skeptisch, wie das funktioniert, wenn Sie nur Zugriff auf eine eingeschränkte Teilmenge von Namespaces im Cluster haben? Nun, kubectl macht dies korrekt, aber nur, wenn RBAC Ihnen erlaubt, alle Namespaces im Cluster zu sehen, und in großen Clustern haben nicht alle diese Berechtigungen. Die gute Nachricht ist: Für OpenShift ist das überhaupt kein Problem, und es wird in dieser Situation problemlos die vollständige Liste bereitstellen. Solche Details zeigen die Unternehmensorientierung von OpenShift und die gute Skalierbarkeit dieser Plattform in Bezug auf Benutzer und Anwendungen.
2. ODO – eine verbesserte Version von kubectl für Entwickler
Ein weiteres Beispiel für die Verbesserungen von Red Hat OpenShift im Vergleich zu Kubernetes ist das ODO-Befehlszeilenwerkzeug. Es ist für Entwickler gedacht und ermöglicht es, lokal geschriebenen Code schnell auf einem Remote-OpenShift-Cluster bereitzustellen. Darüber hinaus kann es interne Prozesse optimieren, um alle Codeänderungen sofort mit Containern auf dem Remote-OpenShift-Cluster zu synchronisieren, ohne die Images neu zu bauen, in ein Register hochzuladen und erneut bereitzustellen.
Schauen wir uns an, wie OC und ODO die Arbeit mit Containern und Kubernetes erleichtern.
Lassen Sie uns ein paar Arbeitsabläufe vergleichen, die auf kubectl basieren, und solche, die OC oder ODO verwenden.
• Bereitstellung von Code auf OpenShift für diejenigen, die mit YAML nicht vertraut sind:
Kubernetes / kubectl
$> git clone
1- Erstellen Sie ein Dockerfile, das ein Image aus dem Code baut
————–
FROM node
WORKDIR /usr/src/app
COPY package*.json ./
COPY index.js ./
COPY ./app ./app
RUN npm install
EXPOSE 3000
CMD [ "npm", "start" ]
————–
2- Bauen Sie das Image
$> podman build …
3- Melden Sie sich im Register an
podman login …
4- Hochladen des Images ins Register
podman push
5- Wir erstellen YAML-Dateien für die Bereitstellung der Anwendung (deployment.yaml, service.yaml, ingress.yaml) – das ist das absolute Minimum.
6- Wir implementieren die Manifest-Dateien:
Kubectl apply -f .
OpenShift / oc
$ > oc new-app – unser_Anwendungsname
OpenShift / odo
$> git clone
$ > odo create component nodejs myapp
$ > odo push
• Kontextwechsel: Ändern des Arbeitsnamensraums oder des Arbeitsclusters.
Kubernetes / kubectl
1- Wir erstellen den Kontext in der kubeconfig für das Projekt „myproject“
2- kubectl set-context …
OpenShift / oc
oc project „myproject“
Qualitätssicherung: „Hier gibt es eine interessante Funktion, die sich noch in der Alpha-Version befindet. Sollen wir sie in die Produktion einführen?“
Stellen Sie sich vor, Sie sitzen in einem Rennwagen und man sagt: „Wir haben hier neue Bremsen eingebaut, und um ehrlich zu sein, sind diese noch nicht ganz zuverlässig... Aber machen Sie sich keine Sorgen, wir werden sie während des Rennens aktiv weiterentwickeln.“ Wie klingt das für Sie? Uns bei Red Hat nicht besonders. 🙂
Deshalb bemühen wir uns, von Alpha-Versionen abzusehen, bis sie ausreichend reif sind und wir gründliche Feldtests durchgeführt haben und uns sicher fühlen, dass sie sicher verwendbar sind. In der Regel durchlaufen unsere Produkte zuerst die Phase der Dev Preview und dann die und erst danach wird es als öffentliche Freigabe veröffentlicht (GA), die bereits so stabil ist, dass sie für den Einsatz in der Produktion geeignet ist.
Warum ist das so? Weil, ähnlich wie bei der Entwicklung anderer Software, nicht alle ursprünglichen Ideen in Kubernetes bis zur endgültigen Veröffentlichung gelangen. Oder sie erreichen das Ziel und behalten die geplante Funktionalität bei, aber ihre Umsetzung unterscheidet sich grundlegend von der in der Alpha-Version. Da Tausende von Red Hat-Kunden OpenShift zur Unterstützung geschäftskritischer Aufgaben einsetzen, legen wir besonderen Wert auf die Stabilität unserer Plattform und auf langfristigen Support.
Red Hat veröffentlicht gezielt häufige Updates für OpenShift und aktualisiert die darin enthaltene Kubernetes-Version. Zum Beispiel ist in der zum Zeitpunkt des Verfassens dieses Artikels aktuellen GA-Version von OpenShift 4.3 Kubernetes 1.16 integriert, das nur einen Versionsschritt hinter der upstream-Version Kubernetes 1.17 liegt. Damit bemühen wir uns, unseren Kunden Kubernetes auf Unternehmensniveau anzubieten und zusätzliche Qualitätskontrollen im Prozess der Veröffentlichung neuer OpenShift-Versionen sicherzustellen.
Software-Patches: "In der Version von Kubernetes, die wir in der Produktion verwenden, wurde eine Sicherheitslücke entdeckt. Diese kann nur durch ein Update auf drei Versionen höher geschlossen werden. Gibt es alternative Optionen?"
Im Rahmen des Open-Source-Projekts Kubernetes werden Software-Patches normalerweise im nächsten Release veröffentlicht, wobei manchmal auch ein oder zwei vorherige Zwischenversionen abgedeckt werden, was einen Rückblick von insgesamt 6 Monaten ermöglicht.
Red Hat ist zu Recht stolz darauf, kritische Patches früher als andere anzubieten und eine viel längere Unterstützung zu gewährleisten. Nehmen wir beispielsweise die Privilegieneskalationsanfälligkeit in Kubernetes (): Sie wurde in Kubernetes 1.11 entdeckt, während Patches für frühere Releases nur bis zur Version 1.10.11 veröffentlicht wurden, wodurch diese Lücke in allen vorherigen Kubernetes-Releases von 1.x bis 1.9 bestehen blieb.
Im Gegenzug (dort läuft Kubernetes 1.2), und deckte dabei neun OpenShift-Releases ab, was die Kundenorientierung eindrucksvoll demonstriert (mehr dazu ).
Wie OpenShift und Red Hat Kubernetes vorantreiben
Red Hat belegt den zweiten Platz in Bezug auf den Beitrag zur Open-Source-Community des Kubernetes-Projekts, direkt hinter Google. Drei von fünf der aktivsten Entwickler sind Mitarbeiter von Red Hat. Ein weiterer weniger bekannter Fakt: Viele der kritischen Funktionen wurden in Kubernetes durch die Initiative von Red Hat eingeführt, darunter:
- RBAC. In Kubernetes gab es keine RBAC-Funktionen (ClusterRole, ClusterRoleBinding), bevor die Ingenieure von Red Hat sich entschieden, diese direkt in die Plattform zu integrieren, anstatt sie als zusätzliches Feature von OpenShift anzubieten. Scheut Red Hat sich davor, Kubernetes zu verbessern? Natürlich nicht, denn Red Hat folgt strikt den Prinzipien der Open-Source-Philosophie und spielt nicht mit Open-Core-Modellen. Verbesserungen und Innovationen, die auf Community-Ebene umgesetzt werden, statt auf proprietäre Weise, erweisen sich als tragfähiger und verbreiten sich breiter, was perfekt mit unserem Hauptziel übereinstimmt – die Nützlichkeit von Open-Source-Software für unsere Kunden zu erhöhen.
- Sicherheitsrichtlinien für Pods (Pod Security Policies). Ursprünglich wurde dieses Konzept zur sicheren Ausführung von Anwendungen innerhalb von Pods in OpenShift unter dem Namen SCC (Security Context Constraints) implementiert. Und wie im vorherigen Beispiel hat Red Hat beschlossen, diese Entwicklungen in das Open-Source-Projekt Kubernetes einzuführen, damit sie von jedem genutzt werden können.
Diese Reihe von Beispielen könnte weitergeführt werden, aber wir wollten lediglich zeigen, dass Red Hat tatsächlich bestrebt ist, Kubernetes weiterzuentwickeln und es für alle besser zu machen.
Es ist klar, OpenShift ist Kubernetes. Aber wo liegen die Unterschiede? 🙂
Wir hoffen, dass Sie beim Lesen an dieser Stelle verstanden haben, dass Kubernetes der zentrale Bestandteil von OpenShift ist. Zentral, aber bei weitem nicht der einzige. Mit anderen Worten, wenn Sie nur Kubernetes installieren, erhalten Sie nicht die Enterprise-Plattform. Sie müssen Authentifizierung, Netzwerk, Sicherheit, Monitoring, Log-Management und vieles mehr hinzufügen. Darüber hinaus müssen Sie aus einer Vielzahl verfügbarer Tools eine schwierige Wahl treffen (um die Vielfalt des Ökosystems zu beurteilen, werfen Sie einfach einen Blick auf ) und auf eine Weise Konsistenz und Harmonie gewährleisten, damit sie wie ein Ganzes funktionieren. Darüber hinaus müssen Sie regelmäßig Updates und Regressionstests durchführen, wenn eine neue Version einer der verwendeten Komponenten veröffentlicht wird. Das bedeutet, dass Sie neben der Erstellung und Pflege der Plattform auch die gesamte Software betreuen müssen. Wahrscheinlich bleibt nicht viel Zeit, um Geschäftsprobleme zu lösen und Wettbewerbsvorteile zu erzielen.
Im Fall von OpenShift übernimmt Red Hat all diese Komplexitäten und bietet Ihnen einfach eine funktional vollständige Plattform, die nicht nur Kubernetes selbst enthält, sondern auch das gesamte Paket an notwendigen Open-Source-Tools, die Kubernetes in eine echte Unternehmenslösung verwandeln, die sofort und vollkommen problemlos in die Produktion überführt werden kann. Natürlich können Sie, wenn Sie über eigene technologische Stacks verfügen, OpenShift in bereits bestehende Lösungen integrieren.
Blicken Sie auf das obige Bild: Alles, was außerhalb des Kubernetes-Rechtecks liegt, sind Bereiche, in denen Red Hat Funktionen hinzufügt, die in Kubernetes nicht enthalten sind, was man als 'by-design' bezeichnet. Jetzt werden wir die wichtigsten dieser Bereiche näher betrachten.
1. Zuverlässiges Betriebssystem als Grundlage: RHEL CoreOS oder RHEL
Red Hat ist seit über 20 Jahren führender Anbieter von Linux-Distributionen für geschäftskritische Anwendungen. Die in diesem Bereich gesammelte Erfahrung, die kontinuierlich aktualisiert wird, ermöglicht es uns, eine wirklich zuverlässige und vertrauenswürdige Grundlage für den industriellen Einsatz von Containern anzubieten. RHEL CoreOS verwendet denselben Kernel wie RHEL, ist jedoch insbesondere für Aufgaben wie das Ausführen von Containern und die Arbeit in Kubernetes-Clustern optimiert: Ihre reduzierte Größe und Unveränderlichkeit erleichtern die Einrichtung von Clustern, die automatisierte Skalierung, das Bereitstellen von Patches usw. All diese Funktionen machen es zu einer idealen Grundlage für ein einheitliches Benutzererlebnis mit OpenShift in den unterschiedlichsten Rechenumgebungen, von Bare Metal bis hin zu privaten und öffentlichen Clouds.
2. Automatisierung von IT-Operationen
Die Automatisierung von Installations- und Betriebsvorgängen des zweiten Tages (d. h. des täglichen Betriebs) ist das Steckenpferd von OpenShift. Sie erleichtert erheblich die Verwaltung, Aktualisierung und den Betrieb der Containerplattform auf höchstem Niveau. Dies wird durch die Unterstützung von Kubernetes-Operatoren auf der Kernel-Ebene von OpenShift 4 erreicht.
OpenShift 4 ist auch ein ganzes Ökosystem von Lösungen, die auf Kubernetes-Operatoren basieren und sowohl von Red Hat als auch von Partnern entwickelt wurden (siehe Red Hat oder den Operator-Marktplatz , den Red Hat für externe Entwickler erstellt hat).
Der integrierte Katalog von OpenShift 4 umfasst mehr als 180 Kubernetes-Operatoren.
3. Entwickler-Tools
Seit 2011 ist OpenShift als PaaS-Plattform (Platform-as-a-Service) verfügbar, die das Leben von Entwicklern erheblich erleichtert, ihnen hilft, sich auf das Schreiben von Code zu konzentrieren, und integrierte Unterstützung für Programmiersprachen wie Java, Node.js, PHP, Ruby, Python, Go sowie Dienste für kontinuierliche Integration und Bereitstellung (CI/CD), Datenbanken usw. bietet. OpenShift 4 bietet , einschließlich über 100 Kubernetes-Operator-basierten Diensten, die von Red Hat und unseren Partnern entwickelt wurden.
Im Gegensatz zu Kubernetes verfügt OpenShift 4 über ein spezielles grafisches Interface (), das Entwicklern hilft, Anwendungen aus verschiedenen Quellen (git, externe Registries, Dockerfiles usw.) ohne großen Aufwand in ihren Namensräumen bereitzustellen und die Verbindungen zwischen den Anwendungs Komponenten anschaulich darzustellen.
Darüber hinaus bietet OpenShift eine Sammlung von Codeready-Entwicklungstools, zu denen unter anderem gehört , eine vollständig containerisierte IDE mit Web-Interface, die direkt auf OpenShift läuft und das Konzept „IDE als Service“ umsetzt. Für diejenigen, die strikt lokal arbeiten möchten, gibt es die Codeready Containers – eine voll funktionsfähige Version von OpenShift 4, die auf einem Laptop bereitgestellt werden kann.
Integrierte „IDE als Service“ für effiziente Entwicklung auf der Kubernetes/OpenShift-Plattform.
OpenShift bietet direkt ab Werk ein vollständiges CI/CD-System, entweder basierend auf containerisiertem Jenkins und dem Plugin für die Arbeit mit Pipelines oder ein auf Kubernetes ausgerichtetes CI/CD-System (derzeit in der technischen Vorschau). Beide Lösungen sind vollständig in die OpenShift-Konsole integriert und ermöglichen das Auslösen von Pipeline-Triggern, das Anzeigen von Deployments, Protokollen usw.
4. Werkzeuge für Anwendungen
OpenShift ermöglicht das Bereitstellen sowohl traditioneller stateful Anwendungen als auch cloud-basierter Lösungen auf Basis neuer Architekturen wie Microservices oder Serverless. Die OpenShift Service Mesh-Lösung bringt sofort gebrauchsfertige, wichtige Werkzeuge zur Verwaltung von Microservices mit, wie Istio, Kiali und Jaeger. Zudem umfasst die OpenShift Serverless-Lösung nicht nur Knative, sondern auch Werkzeuge, die im Rahmen einer Zusammenarbeit mit Microsoft entstanden sind, wie Keda, die Azure-Funktionen auf der OpenShift-Plattform bereitstellt.
Die integrierte Lösung OpenShift ServiceMesh (Istio, Kiali, Jaeger) ist nützlich bei der Entwicklung von Microservices
Um die Kluft zwischen legacy Anwendungen und Containern zu überbrücken, ermöglicht OpenShift jetzt die Migration von virtuellen Maschinen auf die OpenShift-Plattform mittels Container Native Virtualization (derzeit in Tech Preview), was hybride Anwendungen zur Realität werden lässt und deren Transfer zwischen verschiedenen Cloud-Umgebungen, sowohl privat als auch öffentlich, erleichtert.
Windows 2019 Virtual Machine, die über Container Native Virtualization (derzeit in Tech Preview) auf OpenShift läuft
5. Tools für Cluster
Eine Unternehmensplattform benötigt Monitoring-Services sowie zentrale Logging-Werkzeuge, Sicherheitsmechanismen, Authentifizierung und Autorisierung sowie Netzwerkverwaltung. OpenShift bietet all dies bereits direkt an, und das vollständig auf Open Source-Basis, einschließlich Lösungen wie ElasticSearch, Prometheus und Grafana. All diese Lösungen sind mit Dashboards, Metriken und Benachrichtigungen ausgestattet, die bereits zusammengestellt und konfiguriert sind, basierend auf den umfangreichen Erfahrungen von Red Hat im Bereich des Cluster-Monitorings, sodass Sie von Anfang an Ihre Produktionsumgebung effektiv überwachen und nachverfolgen können.
OpenShift bietet auch wichtige Funktionen für Unternehmenskunden wie die Authentifizierung über einen integrierten OAuth-Anbieter, die Integration mit Anmeldediensten wie LDAP, ActiveDirectory, OpenID Connect und vieles mehr.
Vorkonfigurierte Grafana-Dashboards zur Überwachung von OpenShift-Clustern.
Über 150 vorkonfigurierte Prometheus-Metriken und Benachrichtigungen zur Überwachung von OpenShift-Clustern.
Fortsetzung folgt
Die umfangreiche Funktionalität der Lösung und die weitreichende Erfahrung von Red Hat im Bereich Kubernetes sind der Grund, warum OpenShift eine dominierende Marktposition erlangt hat, wie im folgenden Bild gezeigt (mehr dazu ).
Derzeit führt Red Hat den Markt mit einem Anteil von 44 % an.
Das Unternehmen profitiert von seiner Vertriebsstrategie, die eine aktive Beteiligung am Kunden beinhaltet, bei der zunächst Unternehmensentwickler beraten und geschult werden, bevor die Monetarisierung erfolgt, wenn das Unternehmen beginnt, Container in die Produktion einzuführen.
(Quelle: )
Wir hoffen, Ihnen hat dieser Artikel gefallen. In den nächsten Beiträgen dieser Serie werden wir die Vorteile von OpenShift im Vergleich zu Kubernetes in jeder der hier behandelten Kategorien genauer betrachten.
Quelle: habr.com
