„Was ist der Unterschied zwischen Kubernetes und OpenShift?“ – diese Frage stellt sich mit beneidenswerter Konsequenz. Obwohl dies in Wirklichkeit so ist, als würde man fragen, wie sich ein Auto von einem Motor unterscheidet. Wenn wir die Analogie fortsetzen, dann ist ein Auto ein fertiges Produkt, man kann es sofort nutzen, im wahrsten Sinne des Wortes: einsteigen und losfahren. Um andererseits einen Motor irgendwohin zu bringen, muss er zunächst mit vielen anderen Dingen ergänzt werden, um am Ende das gleiche Auto zu erhalten.
Daher ist Kubernetes der Motor, um den herum das Auto (die Plattform) der Marke OpenShift aufgebaut ist, das Sie an Ihr Ziel bringt.
In diesem Artikel möchten wir Sie daran erinnern und die folgenden Kernpunkte etwas genauer untersuchen:
- Kubernetes ist das Herzstück der OpenShift-Plattform und zu 100 % zertifiziertes Kubernetes, vollständig Open Source und ohne den geringsten proprietären Charakter. Knapp:
- Die OpenShift-Cluster-API ist zu XNUMX % Kubernetes.
- Wenn der Container auf einem anderen Kubernetes-System läuft, läuft er ohne Änderungen auf OpenShift. Es sind keine Änderungen an den Anwendungen erforderlich.
- OpenShift erweitert Kubernetes nicht nur um nützliche Features und Funktionen. Wie ein Auto ist OpenShift sofort einsatzbereit, kann sofort in die Produktion übernommen werden und erleichtert, wie wir weiter unten zeigen werden, das Leben eines Entwicklers erheblich. Deshalb ist OpenShift in zwei Personen vereint. Aus Entwicklersicht handelt es sich um eine sowohl erfolgreiche als auch bekannte PaaS-Plattform der Enterprise-Klasse. Und gleichzeitig ist es aus Sicht des Industriebetriebs eine äußerst zuverlässige Container-as-a-Service-Lösung.
OpenShift ist Kubernetes mit 100 % CNCF-Zertifizierung
OpenShift basiert auf . Daher sind Benutzer nach entsprechender Schulung von der Leistungsfähigkeit von kubectl begeistert. Und diejenigen, die vom Kubernetes-Cluster auf OpenShift umgestiegen sind, sagen oft, wie gut es ihnen gefällt, dass nach der Umleitung von kubeconfig auf den OpenShift-Cluster alle vorhandenen Skripte einwandfrei funktionieren.
Sie haben wahrscheinlich schon von OpenShifts Befehlszeilendienstprogramm namens OC gehört. Es ist vollständig befehlskompatibel mit kubectl und bietet außerdem mehrere nützliche Helfer, die sich bei der Ausführung einer Reihe von Aufgaben als nützlich erweisen. Aber zunächst etwas mehr zur Kompatibilität von OC und kubectl:
kubectl-Befehle
OK-Teams
Kubectl bekommen Schoten
oc hol dir Pods
kubectl ruft Namespaces ab
oc Namespaces abrufen
kubectl create -f distribution.yaml
oc create -f distribution.yaml
So sehen die Ergebnisse der Verwendung von kubectl auf der OpenShift-API aus:
• kubectl get pods – gibt Pods wie erwartet zurück.
• kubectl get namespaces – gibt Namespaces wie erwartet zurück.
Der Befehl kubectl create -f mydeployment.yaml erstellt Kubernetes-Ressourcen wie auf jeder anderen Kubernetes-Plattform, wie im Video unten gezeigt:
Mit anderen Worten: Alle Kubernetes-APIs sind in OpenShift vollständig verfügbar und bieten gleichzeitig eine 100-prozentige Kompatibilität. Genau deshalb .
OpenShift fügt Kubernetes nützliche Funktionen hinzu
Kubernetes-APIs sind in OpenShift zu 100 % verfügbar, dem standardmäßigen Kubernetes-Dienstprogramm kubectl mangelt es jedoch eindeutig an Funktionalität und Komfort. Aus diesem Grund hat Red Hat Kubernetes um nützliche Funktionen und Befehlszeilentools erweitert, beispielsweise OC (kurz für OpenShift Client) und ODO (OpenShift DO, dieses Dienstprogramm richtet sich an Entwickler).
1. OC-Dienstprogramm – eine leistungsfähigere und praktischere Version von Kubectl
Im Gegensatz zu kubectl ermöglicht es Ihnen beispielsweise das Erstellen neuer Namespaces und das einfache Wechseln von Kontexten und bietet außerdem eine Reihe nützlicher Befehle für Entwickler, z. B. das Erstellen von Container-Images und das Bereitstellen von Anwendungen direkt aus Quellcode oder Binärdateien (Source-to-Image, s2i).
Sehen wir uns Beispiele dafür an, wie die integrierten Helfer und erweiterten Funktionen des OC-Dienstprogramms dazu beitragen, die tägliche Arbeit zu vereinfachen.
Das erste Beispiel ist die Namensraumverwaltung. Jeder Kubernetes-Cluster verfügt immer über mehrere Namespaces. Sie dienen in der Regel der Erstellung von Entwicklungs- und Produktionsumgebungen, können aber beispielsweise auch dazu dienen, jedem Entwickler eine persönliche Sandbox zur Verfügung zu stellen. In der Praxis führt dies dazu, dass der Entwickler häufig zwischen Namespaces wechseln muss, da kubectl im Kontext des aktuellen Space ausgeführt wird. Daher werden im Fall von kubectl hierfür aktiv Hilfsskripte verwendet. Wenn Sie jedoch OC verwenden, sagen Sie einfach „oc project namespace“, um zum gewünschten Bereich zu wechseln.
Sie wissen nicht mehr, wie der Namespace heißt, den Sie benötigen? Kein Problem, geben Sie einfach „oc get project“ ein, um die vollständige Liste anzuzeigen. Sie fragen sich skeptisch, wie das funktionieren soll, wenn Sie nur Zugriff auf eine begrenzte Teilmenge der Namespaces im Cluster haben? Nun, weil kubectl dies nur dann richtig macht, wenn RBAC es Ihnen ermöglicht, alle Bereiche im Cluster zu sehen, und in großen Clustern nicht jeder solche Berechtigungen erhält. Wir antworten also: Für das OK ist das überhaupt kein Problem und es wird in einer solchen Situation problemlos eine vollständige Liste erstellen. Es sind diese kleinen Dinge, die die Unternehmensausrichtung von Openshift und die gute Skalierbarkeit dieser Plattform in Bezug auf Benutzer und Anwendungen ausmachen
2. ODO – eine verbesserte Version von kubectl für Entwickler
Ein weiteres Beispiel für die Verbesserungen von Red Hat OpenShift gegenüber Kubernetes ist das ODO-Befehlszeilendienstprogramm. Es wurde für Entwickler entwickelt und ermöglicht Ihnen die schnelle Bereitstellung von lokalem Code in einem Remote-OpenShift-Cluster. Darüber hinaus können interne Prozesse optimiert werden, um alle Codeänderungen an Containern in einem Remote-OpenShift-Cluster sofort zu synchronisieren, ohne dass Images neu erstellt, registriert und erneut bereitgestellt werden müssen.
Schauen wir uns an, wie OC und ODO die Arbeit mit Containern und Kubernetes einfacher machen.
Vergleichen Sie einfach ein paar Workflows, wenn sie auf Basis von kubectl erstellt werden und wenn OC oder ODO verwendet werden.
• Bereitstellung von Code auf OpenShift für diejenigen, die kein YAML sprechen:
Kubernetes / kubectl
$>Git-Klon
1- Erstellen Sie eine Docker-Datei, die das Image aus Code erstellt
-----
FROM-Knoten
ARBEITSVERZEICHNIS /usr/src/app
KOPIEREN Sie das Paket*.json ./
KOPIEREN index.js ./
KOPIEREN ./app ./app
Führen Sie die NPM-Installation aus
AUSSETZEN 3000
CMD [ „npm“, „start“ ] ————–
2- Wir erstellen das Image
$>Podman-Build...
3- Melden Sie sich bei der Registrierung an
Podman-Login...
4- Platzieren Sie das Bild in der Registrierung
Podman Push
5- Erstellen Sie Yaml-Dateien für die Anwendungsbereitstellung (deployment.yaml, service.yaml, ingress.yaml) – das ist das absolute Minimum
6- Manifestdateien bereitstellen:
Kubectl apply -f .
OpenShift/oc
$> oc neue-App – unser_Anwendungsname
OpenShift/odo
$>Git-Klon
$> odo erstellt Komponente nodejs myapp
$>odo push
• Kontextwechsel: Arbeitsnamespace oder Arbeitscluster ändern.
Kubernetes / kubectl
1- Erstellen Sie in kubeconfig einen Kontext für das Projekt „myproject“
2- kubectl set-context…
OpenShift/oc
oc-Projekt „myproject“
Qualitätskontrolle: „Hier ist ein interessantes Feature aufgetaucht, noch in der Alpha-Version. Vielleicht können wir es in Produktion bringen?“
Stellen Sie sich vor, Sie sitzen in einem Rennwagen und erfahren: „Wir haben eine neue Art von Bremsen eingebaut und ehrlich gesagt ist die Zuverlässigkeit noch nicht in Ordnung ... Aber keine Sorge, wir werden sie im Laufe des Kurses aktiv verbessern.“ der Meisterschaft.“ Wie gefällt Ihnen diese Aussicht? Wir bei Red Hat sind irgendwie nicht sehr glücklich. 🙂
Daher versuchen wir, die Alpha-Versionen so lange zurückzuhalten, bis sie ausreichend ausgereift sind und wir gründliche Kampftests durchgeführt haben und der Meinung sind, dass sie sicher zu verwenden sind. Normalerweise durchläuft alles zuerst die Dev Preview-Phase und dann die Phase und kommt erst dann als öffentliche Veröffentlichung heraus (GA), das bereits so stabil ist, dass es für die Produktion geeignet ist.
Warum so? Denn wie bei der Entwicklung jeder anderen Software gelangen auch bei Kubernetes nicht alle ersten Ideen in die endgültige Veröffentlichung. Oder sie erreichen es und behalten sogar die vorgesehene Funktionalität bei, aber ihre Umsetzung unterscheidet sich radikal von der in der Alpha-Version. Da Tausende und Abertausende von Red Hat-Kunden OpenShift zur Unterstützung geschäftskritischer Workloads nutzen, legen wir besonderen Wert auf die Stabilität unserer Plattform und den langfristigen Support.
Red Hat ist bestrebt, OpenShift regelmäßig zu veröffentlichen und die dazugehörige Kubernetes-Version zu aktualisieren. Beispielsweise umfasst die aktuelle GA-Version von OpenShift 4.3 zum Zeitpunkt des Verfassens dieses Artikels Kubernetes 1.16, was nur eine Einheit hinter der Upstream-Version von Kubernetes mit der Nummer 1.17 liegt. Daher versuchen wir, dem Kunden Kubernetes der Enterprise-Klasse zur Verfügung zu stellen und zusätzliche Qualitätskontrolle zu bieten, wenn wir neue Versionen von OpenShift veröffentlichen.
Software-Korrekturen: „Es gab eine Lücke in der Version von Kubernetes, die wir in der Produktion haben. Und Sie können es nur schließen, indem Sie drei Versionen aktualisieren. Oder gibt es irgendwelche Optionen?
Beim Kubernetes-Open-Source-Projekt werden Software-Korrekturen normalerweise als Teil der nächsten Version veröffentlicht und decken manchmal ein oder zwei vorherige Meilenstein-Releases ab, sodass die Abdeckung bereits nach 6 Monaten zurückliegt.
Red Hat ist stolz darauf, kritische Fixes früher als andere zu veröffentlichen und viel länger Support zu bieten. Nehmen Sie zum Beispiel die Sicherheitslücke bezüglich der Eskalation von Kubernetes-Privilegien (): Es wurde in Kubernetes 1.11 entdeckt und Korrekturen für frühere Versionen wurden nur bis zur Version 1.10.11 veröffentlicht, sodass dieses Problem in allen früheren Kubernetes-Versionen von 1.x bis 1.9 in der Lücke steckt.
Im Gegenzug (Kubernetes 1.2 ist da), erfasst neun OpenShift-Releases und zeigt deutlich die Betreuung der Kunden (weitere Details ).
Wie OpenShift und Red Hat Kubernetes voranbringen
Red Hat ist nach Google der zweitgrößte Software-Anbieter des Open-Source-Kubernetes-Projekts, wobei drei der fünf produktivsten Entwickler von Red Hat kommen. Eine weitere wenig bekannte Tatsache: Viele kritische Funktionen erschienen in Kubernetes insbesondere auf Initiative von Red Hat, wie zum Beispiel:
- RBAC. Kubernetes verfügte nicht über RBAC-Funktionen (ClusterRole, ClusterRoleBinding), bis die Ingenieure von Red Hat beschlossen, sie als Teil der Plattform selbst und nicht als zusätzliche OpenShift-Funktionalität zu implementieren. Hat Red Hat Angst, Kubernetes zu verbessern? Natürlich nicht, denn Red Hat folgt strikt den Open-Source-Prinzipien und spielt keine Open-Core-Spiele. Verbesserungen und Innovationen, die nicht von proprietären, sondern von Entwicklungsgemeinschaften vorangetrieben werden, sind praktikabler und werden weiter verbreitet, was gut zu unserem Kernziel passt, Open-Source-Software für unsere Kunden nützlicher zu machen.
- Sicherheitsrichtlinien für Pods (Pod-Sicherheitsrichtlinien). Dieses Konzept der sicheren Ausführung von Anwendungen innerhalb von Pods wurde ursprünglich in OpenShift unter dem Namen SCC (Security Context Constraints) implementiert. Und wie im vorherigen Beispiel hat Red Hat beschlossen, diese Entwicklungen in das offene Kubernetes-Projekt einzuführen, damit jeder sie nutzen kann.
Diese Reihe von Beispielen könnte fortgesetzt werden, aber wir wollten nur zeigen, dass Red Hat sich wirklich dafür einsetzt, Kubernetes weiterzuentwickeln und es für alle besser zu machen.
Es ist klar, dass OpenShift Kubernetes ist. Was sind die Unterschiede? 🙂
Wir hoffen, dass Sie durch die Lektüre bis hierhin erkannt haben, dass Kubernetes die Kernkomponente von OpenShift ist. Der wichtigste, aber bei weitem nicht der einzige. Mit anderen Worten: Durch die einfache Installation von Kubernetes erhalten Sie keine Plattform der Enterprise-Klasse. Sie müssen Authentifizierung, Netzwerk, Sicherheit, Überwachung, Protokollverwaltung und mehr hinzufügen. Außerdem müssen Sie aus der Vielzahl der verfügbaren Tools einige schwierige Entscheidungen treffen (um die Vielfalt des Ökosystems zu schätzen, werfen Sie einfach einen Blick darauf). ) und irgendwie für Konsistenz und Kohärenz sorgen, sodass sie als Einheit funktionieren. Darüber hinaus müssen Sie regelmäßig Aktualisierungen und Regressionstests durchführen, wenn eine neue Version einer der von Ihnen verwendeten Komponenten veröffentlicht wird. Das heißt, Sie müssen sich neben der Erstellung und Wartung der Plattform selbst auch mit der gesamten Software befassen. Es ist unwahrscheinlich, dass noch viel Zeit bleibt, um geschäftliche Probleme zu lösen und Wettbewerbsvorteile zu erzielen.
Aber im Fall von OpenShift übernimmt Red Hat all diese Komplexitäten und stellt Ihnen einfach eine funktional vollständige Plattform zur Verfügung, die nicht nur Kubernetes selbst, sondern auch den gesamten Satz notwendiger Open-Source-Tools umfasst, die Kubernetes zu einer echten Enterprise-Klasse machen Lösung, die Sie sofort und völlig beruhigt in die Produktion bringen können. Und wenn Sie über einige Ihrer eigenen Technologie-Stacks verfügen, können Sie OpenShift natürlich in bestehende Lösungen integrieren.
Schauen Sie sich das Bild oben an: Bei allem, was außerhalb des Kubernetes-Rechtecks liegt, fügt Red Hat Funktionen hinzu, über die Kubernetes, wie man sagt, nicht von Natur aus verfügt. Und jetzt werden wir uns die wichtigsten dieser Bereiche ansehen.
1. Robustes Betriebssystem als Basis: RHEL CoreOS oder RHEL
Red Hat ist seit mehr als 20 Jahren ein führender Anbieter von Linux-Distributionen für geschäftskritische Anwendungen. Unsere gesammelten und ständig aktualisierten Erfahrungen in diesem Bereich ermöglichen es uns, eine wirklich zuverlässige und vertrauenswürdige Basis für den industriellen Betrieb von Containern zu bieten. RHEL CoreOS verwendet denselben Kernel wie RHEL, ist jedoch in erster Linie für Aufgaben wie das Ausführen von Containern und das Ausführen von Kubernetes-Clustern optimiert: Seine reduzierte Größe und Unveränderlichkeit erleichtern das Einrichten von Clustern, die automatische Skalierung, die Bereitstellung von Patches usw. All diese Funktionen machen es aus eine ideale Grundlage, um mit OpenShift in einer Vielzahl von Computerumgebungen, von Bare-Metal bis hin zu privaten und öffentlichen Clouds, das gleiche Benutzererlebnis zu bieten.
2. Automatisierung des IT-Betriebs
Die Automatisierung von Installationsprozessen und Day-4-Operationen (d. h. tägliche Abläufe) ist die Stärke von OpenShift und erleichtert die Verwaltung, Aktualisierung und Aufrechterhaltung der Leistung der Containerplattform auf höchstem Niveau erheblich. Dies wird durch die Unterstützung von Kubernetes-Operatoren auf der OpenShift XNUMX-Kernel-Ebene erreicht.
OpenShift 4 ist außerdem ein ganzes Ökosystem von Lösungen, die auf Kubernetes-Operatoren basieren und sowohl von Red Hat selbst als auch von Drittpartnern entwickelt wurden (siehe. Red Hat oder Operator Store , erstellt von Red Hat für Drittentwickler).
Der integrierte OpenShift 4-Katalog umfasst mehr als 180 Kubernetes-Operatoren
3. Entwicklertools
Seit 2011 ist OpenShift als PaaS-Plattform (Platform-as-a-Service) verfügbar, die Entwicklern das Leben erheblich erleichtert, ihnen hilft, sich auf das Codieren zu konzentrieren, und native Unterstützung für Programmiersprachen wie Java und Node.js bietet , PHP, Ruby, Python, Go sowie CI/CD Continuous Integration und Delivery Services, Datenbanken usw. OpenShift 4 bietet , das mehr als 100 Dienste umfasst, die auf Kubernetes-Operatoren basieren und von Red Hat und unseren Partnern entwickelt wurden.
Im Gegensatz zu Kubernetes verfügt OpenShift 4 über eine dedizierte GUI (), das Entwicklern hilft, Anwendungen aus verschiedenen Quellen (Git, externe Register, Dockerfile usw.) mühelos in ihren Namespaces bereitzustellen und die Beziehungen zwischen Anwendungskomponenten klar zu visualisieren.
Darüber hinaus bietet OpenShift eine Reihe von Codeready-Entwicklungstools an, zu denen insbesondere Folgendes gehört , eine vollständig containerisierte IDE mit einer Weboberfläche, die direkt auf OpenShift läuft und einen IDE-as-a-Service-Ansatz implementiert. Für diejenigen, die ausschließlich im lokalen Modus arbeiten möchten, gibt es hingegen 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 sofort ein vollständiges CI/CD-System, entweder basierend auf containerisiertem Jenkins und einem Plugin für die Arbeit mit Pipelines oder ein Kubernetes-orientiertes CI/CD-System (derzeit in der Tech-Vorschauversion). Beide Lösungen lassen sich vollständig in die OpenShift-Konsole integrieren und ermöglichen Ihnen die Ausführung von Pipeline-Triggern, die Anzeige von Bereitstellungen, Protokollen und mehr.
4. Anwendungstools
Mit OpenShift können Sie sowohl traditionelle zustandsbehaftete Anwendungen als auch cloudbasierte Lösungen bereitstellen, die auf neuen Architekturen wie Microservices oder serverlosen Lösungen basieren. Die OpenShift Service Mesh-Lösung ist sofort einsatzbereit und enthält wichtige Tools für die Wartung von Microservices wie Istio, Kiali und Jaeger. Die OpenShift Serverless-Lösung wiederum umfasst nicht nur Knative, sondern auch Tools wie Keda, die im Rahmen einer gemeinsamen Initiative mit Microsoft entwickelt wurden, um Azure-Funktionen auf der OpenShift-Plattform bereitzustellen.
Die integrierte Lösung OpenShift ServiceMesh (Istio, Kiali, Jaeger) wird bei der Entwicklung von Microservices nützlich sein
Um die Lücke zwischen Legacy-Anwendungen und Containern zu schließen, ermöglicht OpenShift jetzt die Migration virtueller Maschinen auf die OpenShift-Plattform mithilfe von Container Native Virtualization (derzeit in TechPreview), wodurch Hybridanwendungen Wirklichkeit werden und ihre Migration zwischen verschiedenen privaten und öffentlichen Clouds erleichtert wird.
Virtuelle virtuelle Maschine von Windows 2019, die unter OpenShift über Container Native Virtualization ausgeführt wird (derzeit in der Tech-Preview-Version)
5. Tools für Cluster
Jede Plattform der Enterprise-Klasse muss über Überwachungs- und zentralisierte Protokollierungsdienste, Sicherheitsmechanismen, Authentifizierung und Autorisierung sowie Netzwerkverwaltungstools verfügen. Und OpenShift bietet all dies sofort einsatzbereit, und es ist alles zu 100 % Open Source, einschließlich Lösungen wie ElasticSearch, Prometheus, Grafana. Alle diese Lösungen verfügen über Dashboards, Metriken und Warnungen, die mithilfe der umfangreichen Cluster-Überwachungskompetenz von Red Hat bereits erstellt und konfiguriert wurden, sodass Sie Ihre Produktionsumgebung von Anfang an effektiv steuern und überwachen können.
OpenShift verfügt außerdem standardmäßig über so wichtige Dinge für Unternehmenskunden wie die Authentifizierung mit einem integrierten OAuth-Anbieter, die Integration mit Anmeldeinformationsanbietern, einschließlich LDAP, ActiveDirectory, OpenID Connect und vielem mehr.
Vorkonfiguriertes Grafana-Dashboard für die OpenShift-Clusterüberwachung
Über 150 vorkonfigurierte Prometheus-Metriken und -Warnungen für die OpenShift-Clusterüberwachung
To be continued
Die reichhaltige Funktionalität der Lösung und die umfangreiche Erfahrung von Red Hat im Bereich Kubernetes sind die Gründe dafür, dass OpenShift eine marktbeherrschende Stellung erlangt hat, wie in der Abbildung unten dargestellt (weiterlesen). ).
„Red Hat ist derzeit mit einem Anteil von 44 % Marktführer.
Das Unternehmen profitiert von den Vorteilen seiner kundenorientierten Vertriebsstrategie, bei der es zunächst Unternehmensentwickler berät und schult und dann zur Monetarisierung übergeht, wenn das Unternehmen mit der Bereitstellung von Containern in der Produktion beginnt.“
(Geschichte: )
Wir hoffen, dass Ihnen dieser Artikel gefallen hat. In zukünftigen Beiträgen dieser Reihe werden wir uns die Vorteile von OpenShift gegenüber Kubernetes in jeder der hier besprochenen Kategorien genauer ansehen.
Source: habr.com