🧡 🖲️ 🍚 OpenShift als Unternehmensversion von Kubernetes 🌯 👨🏼‍🎓 🥤

"Was ist der Unterschied zwischen Kubernetes und OpenShift?" - Diese Frage stellt sich mit beneidenswerter Konstanz. Obwohl es 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, Sie können es sofort verwenden, buchstäblich: Sie haben sich hingesetzt und sind gegangen. Auf der anderen Seite muss der Motor, um Sie irgendwohin zu bringen, zuerst mit einer Vielzahl anderer Dinge ergänzt werden, um schließlich das gleiche Auto zu erhalten.

Daher ist Kubernetes ein solcher Motor, um den ein Automobil (Plattform) der Marke OpenShift montiert ist, der Sie zum Ziel führt.

In diesem Artikel möchten wir die folgenden Schlüsselpunkte abrufen und genauer analysieren:

Kubernetes ist das Herzstück der OpenShift-Plattform. Es ist zu 100% Kubernetes-zertifiziert, vollständig Open Source und ohne die geringste Richtigkeit. Zusamenfassend:
- API OpenShift – Kubernetes.
- Kubernetes, - OpenShift. .
OpenShift Kubernetes . , OpenShift , , , . OpenShift . , PaaS- , . Container-as-a-Service .

OpenShift – Kubernetes 100% CNCF

OpenShift basiert auf Kubernetes Certified . Daher bewundern Benutzer nach entsprechender Schulung die Leistungsfähigkeit von kubectl. Und diejenigen, die mit Kubernetes Cluster zu OpenShift gewechselt sind, sagen oft, dass sie das wirklich mögen, nachdem sie kubeconfig zum OpenShift-Cluster umgeleitet haben. Alle verfügbaren Skripte funktionieren einwandfrei.

Sie haben wahrscheinlich von dem OpenShift-Befehlszeilenprogramm OC gehört. Es ist vollständig kompatibel mit kubectl-Befehlen und bietet mehrere nützliche Hilfsprogramme, die bei der Ausführung einer Reihe von Aufgaben hilfreich sind. Aber zuerst ein bisschen mehr über OC- und Kubectl-Kompatibilität:

Kubectl-Teams	OK-Teams
Kubectl bekommen Schoten	Ich bekomme Schoten
kubectl bekommt Namespaces	oc Namespaces bekommen
kubectl create -f deploy.yaml	oc create -f deploy.yaml

So sehen die Ergebnisse der Verwendung von kubectl in der OpenShift-API aus:

• kubectl get pods - Es wird erwartet, dass Pods zurückgegeben werden.

• kubectl get Namespaces - gibt erwartungsgemäß Namespaces zurück.

Mit dem Befehl kubectl create -f mydeployment.yaml werden kubernetes-Ressourcen wie auf jeder anderen Kubernetes-Plattform erstellt, wie im folgenden Video gezeigt:

Mit anderen Worten, auf alle Kubernetes-APIs kann in OpenShift mit 100% iger Kompatibilität vollständig zugegriffen werden. Aus diesem Grund wird OpenShift von der Cloud Native Computing Foundation (CNCF) als zertifizierte Kubernetes-Plattform anerkannt .

OpenShift unterstützt Kubernetes mit nützlichen Funktionen

Die APIs von Kubernetes sind zu 100% in OpenShift verfügbar, aber dem regulären Kubectl-Dienstprogramm von Kubernetes mangelt es eindeutig an Funktionalität und Komfort. Daher hat Red Hat Kubernetes mit nützlichen Funktionen und Befehlszeilentools wie OC (kurz für OpenShift Client) und ODO (OpenShift DO, dieses Dienstprogramm ist für Entwickler gedacht) hinzugefügt.

1. Das OC-Dienstprogramm - eine leistungsstärkere und bequemere Version von Kubectl

Im Gegensatz zu kubectl können Sie damit neue Namespaces erstellen und den Kontext einfach wechseln. Außerdem erhalten Entwickler eine Reihe nützlicher Befehle, z. B. zum Erstellen von Container-Images und zum Bereitstellen von Anwendungen direkt aus Quellcode oder Binärdateien (Source-to-Image, s2i).

Schauen wir uns Beispiele an, wie integrierte Helfer und erweiterte Funktionen des OC-Dienstprogramms die tägliche Arbeit vereinfachen.

Beispiel eins ist die Namespace-Verwaltung. Jeder Kubernetes-Cluster verfügt immer über mehrere Namespaces. Normalerweise werden sie zum Erstellen von Entwicklungs- und Produktionsumgebungen verwendet, können aber auch verwendet werden, um beispielsweise jedem Entwickler eine persönliche „Sandbox“ zu geben. In der Praxis führt dies dazu, dass der Entwickler häufig zwischen Namespaces wechseln muss, da kubectl im Kontext des aktuellen Space arbeitet. Daher verwenden die Leute im Fall von kubectl aktiv Hilfsskripte dafür. Wenn Sie jedoch OC verwenden, um zum gewünschten Speicherplatz zu wechseln, reicht es aus, "oc project namespace_" zu sagen.

Erinnerst du dich nicht, wie der Namespace heißt? Kein Problem, geben Sie einfach "oc get projects" ein, um eine vollständige Liste anzuzeigen. Sie fragen sich skeptisch, wie dies funktionieren wird, wenn Sie nur auf eine begrenzte Teilmenge von Namespaces im Cluster zugreifen können? Nun, weil kubectl dies korrekt macht, nur wenn RBAC es Ihnen erlaubt, alle Leerzeichen im Cluster zu sehen, und in großen Clustern gibt nicht jeder eine solche Autorität. Wir antworten also: Für OC ist dies überhaupt kein Problem und es wird in einer solchen Situation leicht eine vollständige Liste geben. Aus solchen Kleinigkeiten besteht der Unternehmensfokus 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 gegenüber Kubernetes ist das ODO-Befehlszeilenprogramm. Es ist für Entwickler gedacht und ermöglicht Ihnen die schnelle Bereitstellung von lokalem Code in einem Remote-OpenShift-Cluster. Darüber hinaus können damit interne Prozesse optimiert werden, um alle Codeänderungen sofort mit Containern in einem Remote-OpenShift-Cluster zu synchronisieren, ohne dass Images neu zusammengesetzt, in die Registrierung gestellt und erneut bereitgestellt werden müssen.

Mal sehen, wie OC und ODO Container und Kubernetes einfacher machen.

Vergleichen Sie einfach einige Workflows, wenn sie auf der Basis von kubectl erstellt wurden und wenn OC oder ODO verwendet werden.

• Bereitstellung von Code unter OpenShift für diejenigen, die die YAML-Sprache nicht sprechen:

Kubernetes / kubectl	$> git clone github.com/sclorg/nodejs-ex.git 1- Dockerfile, ————– FROM node WORKDIR /usr/src/app COPY package*.json ./ COPY index.js ./ COPY ./app ./app RUN npm install EXPOSE 3000 CMD [ “npm”, “start” ] ————– 2- $> podman build … 3- podman login … 4- podman push 5- yaml- (deployment.yaml, service.yaml, ingress.yaml) – 6- manifest-: Kubectl apply -f .
OpenShift / oc	$> oc new-app github.com/sclorg/nodejs-ex.git – __
OpenShift / odo	$> git clone github.com/sclorg/nodejs-ex.git $> odo create component nodejs myapp $> odo push

• : .

Kubernetes / kubectl	1- kubeconfig “myproject” 2- kubectl set-context …
OpenShift / oc	oc project “myproject”

: « , -. ?»

Stellen Sie sich vor, Sie sitzen in einem Rennwagen und sie sagen: "Wir haben hier eine neue Art von Bremsen eingebaut, und ehrlich gesagt haben sie noch nicht alles in Ordnung mit Zuverlässigkeit ... Aber keine Sorge, wir werden sie im Verlauf der Meisterschaft aktiv verfeinern." Wie gefällt Ihnen diese Aussicht? Wir bei Red Hat sind irgendwie nicht sehr. :)

Deshalb versuchen wir, von Alpha-Versionen abzusehen, bis sie reif genug sind, und wir führen keine gründlichen Kampftests durch und sind der Meinung, dass sie sicher verwendet werden können. Normalerweise durchläuft alles zuerst die Dev Preview-Phase, dann die Tech Preview und wird erst dann als öffentliche Version von General Availability (GA) veröffentlicht, die bereits stabil genug ist, um für die Produktion geeignet zu sein.

Warum so? Denn wie bei der Entwicklung jeder anderen Software erreichen nicht alle ersten Ideen in Kubernetes die endgültige Version. Oder sie erreichen und behalten sogar ihre beabsichtigte Funktionalität bei, aber ihre Implementierung unterscheidet sich grundlegend von der in der Alpha-Version. Da Tausende und Abertausende von Red Hat-Kunden OpenShift zur Unterstützung unternehmenskritischer Aufgaben verwenden, legen wir besonderen Wert auf die Stabilität unserer Plattform und den langfristigen Support.

Red Hat veröffentlicht absichtlich häufige OpenShift-Versionen und aktualisiert seine Version von Kubernetes. Zum Zeitpunkt des Schreibens dieses Artikels enthält die GA-Version von OpenShift 4.3 beispielsweise Kubernetes 1.16, eine Einheit hinter der Upstream-Version von Kubernetes 1.17. Daher versuchen wir, dem Kubernetes-Kunden der Enterprise-Klasse eine zusätzliche Qualitätskontrolle bei der Veröffentlichung neuer Versionen von OpenShift zu bieten.

Software-Korrekturen: „In dieser Version von Kubernetes, die wir in der Produktion haben, war eine Lücke. Und Sie können es nur schließen, indem Sie drei Versionen aktualisieren. Oder gibt es Optionen? "

Im Rahmen des Open-Source-Projekts von Kubernetes werden Software-Fixes normalerweise als Teil der nächsten Version veröffentlicht. Manchmal decken sie ein oder zwei frühere Zwischenversionen ab, die erst vor 6 Monaten behandelt wurden.

Red Hat ist zu Recht stolz darauf, kritische Korrekturen früher als andere zu veröffentlichen und Unterstützung für einen viel längeren Zeitraum bereitzustellen. Nehmen wir zum Beispiel die Sicherheitsanfälligkeit bezüglich der Eskalation von Kubernetes-Berechtigungen ( CVE-2018-1002105 ): Sie wurde in Kubernetes 1.11 entdeckt, und Patches für frühere Versionen wurden nur in Version 1.10.11 veröffentlicht, sodass diese Lücke in allen früheren Kubernetes-Versionen von 1 verbleibt .x bis 1.9.

Im Gegenzug hat Red Hat OpenShift auf Version 3.2 zurückgesetzt(Kubernetes 1.2 steht dort), erfasst neun OpenShift-Versionen und demonstriert die Kundenbetreuung (weitere Informationen hier ).

Wie OpenShift und Red Hat Kubernetes vorwärts bringen

Red Hat belegt den zweiten Platz in Bezug auf Softwarebeiträge zu Kubernetes Open Source, nach Google den zweiten Platz. Drei der fünf produktivsten Entwickler arbeiten für Red Hat. Eine weitere wenig bekannte Tatsache: Viele kritische Funktionen erschienen in Kubernetes genau auf Initiative von Red Hat, insbesondere:

RBAC. Kubernetes RBAC (ClusterRole, ClusterRoleBinding) , Red Hat , OpenShift. Red Hat Kubernetes? , Red Hat , Open Core. , , , , – .
Sicherheitsrichtlinien für Pods (Pod-Sicherheitsrichtlinien). Dieses Konzept der sicheren Anwendungsausführung in 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 Open-Source-Projekt Kubernetes einzuführen, damit jeder sie nutzen kann.

Diese Reihe von Beispielen kann fortgesetzt werden, aber wir wollten nur zeigen, dass Red Hat wirklich bestrebt ist, Kubernetes zu entwickeln und für alle besser zu machen.

OpenShift ist eindeutig Kubernetes. Und was sind die Unterschiede? :) :)

Wir hoffen, dass Sie nach dem Lesen bis zu diesem Punkt festgestellt haben, dass Kubernetes die Hauptkomponente von OpenShift ist. Einfach, aber nicht der einzige. Mit anderen Worten, allein durch die Installation von Kubernetes erhalten Sie keine Plattform der Enterprise-Klasse. Sie müssen Authentifizierung, Netzwerk, Sicherheit, Überwachung, Protokollverwaltung und mehr hinzufügen. Darüber hinaus müssen Sie aus der Vielzahl der verfügbaren Tools eine schwierige Auswahl treffen (um die Vielfalt des Ökosystems zu bewerten, sehen Sie sich einfach das CNCF-Diagramm an) und irgendwie Kohärenz und Kohärenz sicherstellen, damit sie als Ganzes funktionieren. Darüber hinaus müssen Sie regelmäßig Aktualisierungs- und Regressionstests durchführen, wenn eine neue Version einer der verwendeten Komponenten veröffentlicht wird. Das heißt, Sie müssen nicht nur die Plattform selbst erstellen und warten, sondern sich auch mit all dieser Software befassen. Es ist unwahrscheinlich, dass hier noch viel Zeit verbleibt, um geschäftliche Probleme zu lösen und Wettbewerbsvorteile zu erzielen.

Im Fall von OpenShift nimmt Red Hat all diese Schwierigkeiten auf sich und bietet Ihnen einfach eine funktional vollständige Plattform, die nicht nur Kubernetes selbst umfasst, sondern auch alle erforderlichen Open Source-Tools, die Kubernetes zu einer echten Lösung der Enterprise-Klasse machen, die Sie können sofort und völlig ruhig in der Produktion laufen. Und wenn Sie einen Ihrer Technologie-Stacks haben, können Sie OpenShift natürlich in Ihre vorhandenen Lösungen einbetten.

OpenShift ist eine intelligente Kubernetes-Plattform.

Sehen Sie sich das Bild oben an: Alles, was sich außerhalb des Kubernetes-Rechtecks befindet, ist der Bereich, in dem Red Hat Funktionen hinzufügt, die Kubernetes nicht wie beabsichtigt hat. Und jetzt werden wir die Hauptbereiche betrachten.

1. Zuverlässiges 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 Geschäftsanwendungen. Die in diesem Bereich gesammelten und ständig aktualisierten Erfahrungen ermöglichen es uns, eine wirklich zuverlässige und vertrauenswürdige Grundlage 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 Arbeiten in Kubernetes-Clustern optimiert: Die reduzierte Größe und Unveränderlichkeit vereinfacht die Clusterinstallation, die automatische Skalierung, die Bereitstellung von Patches usw. All diese Funktionen machen es zu einer idealen Basis, um die gleiche Benutzererfahrung zu erzielen, wenn Sie mit OpenShift in einer Vielzahl von Computerumgebungen arbeiten, von Bare Metal bis hin zu privaten und öffentlichen Clouds.

2. Automatisierung des IT-Betriebs

Die Automatisierung von Installationsprozessen und Vorgängen am zweiten Tag (dh im täglichen Betrieb) ist ein OpenShift-Steckenpferd, das die Verwaltung, Aktualisierung und Wartung der Containerplattform auf höchstem Niveau erheblich erleichtert. Dies wird durch die Unterstützung von Kubernetes-Betreibern auf der Kernebene von OpenShift 4 erreicht.

OpenShift 4 ist auch ein ganzes Ökosystem von Lösungen, die auf Kubernetes-Betreibern basieren, die sowohl von Red Hat als auch von Drittanbietern entwickelt wurden (siehe das Red Hat- Betreiberverzeichnis oder den Betreiberspeicher) operatorhub.io , erstellt von Red Hat für Entwickler von Drittanbietern).

Das integrierte OpenShift 4-Verzeichnis enthält über 180 Kubernetes-Operatoren

3. Entwicklertools

Seit 2011 ist OpenShift als PaaS-Plattform (Platform-as-a-Service) verfügbar, die das Leben von Entwicklern erheblich vereinfacht, ihnen hilft, sich auf die Codeerstellung zu konzentrieren, und integrierte Unterstützung für Programmiersprachen wie Java, Node.js, PHP, Ruby, Python, Go sowie kontinuierliche Integrations- und Bereitstellungsdienste, Datenbanken usw. für CI / CD. OpenShift 4 bietet einen umfangreichen Katalog mit mehr als 100 Diensten, die auf von Red Hat und unseren Partnern entwickelten Kubernetes-Betreibern basieren.

Im Gegensatz zu Kubernetes verfügt OpenShift 4 über eine spezielle grafische Oberfläche ( Developer Console)), mit dem Entwickler Anwendungen in ihren Namespaces aus verschiedenen Quellen (Git, externe Register, Dockerfile usw.) einfach bereitstellen und die Verbindungen zwischen Anwendungskomponenten visuell visualisieren können.

Die Developer Console visualisiert Anwendungskomponenten und vereinfacht die Arbeit mit Kubernetes.

Darüber hinaus bietet OpenShift eine Reihe von Codeready-Entwicklungstools, darunter Codeready Workspaces , eine vollständig containerisierte webbasierte IDE, die direkt auf OpenShift ausgeführt wird und den IDE-ähnlichen Ansatz implementiert Bedienung". Für diejenigen, die ausschließlich im lokalen Modus arbeiten möchten, gibt es Codeready Containers - eine voll funktionsfähige Version von OpenShift 4, die auf einem Laptop bereitgestellt werden kann.

Integrierte „IDE as a Service“ für eine effiziente Entwicklung auf der Kubernetes / OpenShift-Plattform.

OpenShift bietet sofort ein vollständiges CI / CD-System, das entweder auf den containerisierten Jenkins und dem DSL- Plug-In für Pipelines oder auf dem Kubernetes CI / CD-basierten Tekton- System ( vorerst) basiert in der Tech-Vorschau-Version). Beide Lösungen sind vollständig in die OpenShift-Konsole integriert, sodass Sie Pipeline-Trigger ausführen, Bereitstellungen, Protokolle usw. anzeigen können.

4. Tools für Anwendungen

Mit OpenShift können Sie sowohl herkömmliche Stateful-Anwendungen als auch Cloud-basierte Lösungen bereitstellen, die auf neuen Architekturen wie Microservices oder Serverless basieren. Die sofort einsatzbereite OpenShift Service Mesh-Lösung ist der Schlüssel zur Unterstützung von Microservice-Tools wie Istio, Kiali und Jaeger. Die OpenShift Serverless-Lösung 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 OpenShift ServiceMesh-Lösung (Istio, Kiali, Jaeger) ist nützlich bei der Entwicklung von Microservices.

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 der Container Native Virtualization (derzeit in der TechPreview-Version), wobei Hybridanwendungen aktiviert werden in die Realität umzusetzen und den Transfer zwischen verschiedenen privaten und öffentlichen Clouds zu erleichtern.

Virtuelle virtuelle Maschine von Windows 2019, die unter OpenShift über Container Native Virtualization ausgeführt wird (derzeit in der Tech-Vorschau-Version)

5. Tools für Cluster

Jede Plattform der Enterprise-Klasse sollte über Überwachungs- und zentralisierte Protokollierungsdienste, Sicherheitsmechanismen, Authentifizierung und Autorisierung sowie Netzwerkverwaltungstools verfügen. Und OpenShift bietet all dies sofort und alles zu 100% Open Source, einschließlich Lösungen wie ElasticSearch, Prometheus, Grafana. Alle diese Lösungen werden mit Dashboards, Metriken und Warnungen geliefert, die bereits auf der Grundlage der umfassenden Clusterüberwachung von Red Hat konfiguriert und konfiguriert wurden. So können Sie Ihre Produktionsumgebung von den ersten Minuten an effektiv überwachen und verfolgen.

OpenShift hat auch so wichtige Dinge für den Unternehmenskunden wie die Authentifizierung beim integrierten oauth-Anbieter, die Integration mit Anbietern von Anmeldeinformationen, einschließlich LDAP, ActiveDirectory, OpenID Connect und vieles mehr.

Vorkonfiguriertes Grafana-Dashboard zur Überwachung eines OpenShift-Clusters

Über 150 vorkonfigurierte Prometheus-Metriken und Warnungen zur Überwachung eines OpenShift-Clusters

Fortsetzung folgt

Die reichhaltige Funktionalität der Lösung und die umfassende Erfahrung von Red Hat im Bereich Kubernetes sind genau aus diesen Gründen, dass OpenShift eine marktbeherrschende Stellung eingenommen hat, wie in der folgenden Abbildung dargestellt (weitere Details hier ).

„Derzeit ist Red Hat mit einem Anteil von 44% marktführend.
Das Unternehmen profitiert von seiner Vertriebsstrategie durch die aktive Teilnahme an Kundenangelegenheiten, bei denen es zunächst Unternehmensentwickler berät und schult und dann mit der Monetarisierung fortfährt, wenn das Unternehmen beginnt, Container in die Produktion einzuführen. “

(Quelle: www.lightreading.com/nfv/containers/ihs-red-hat-container-strategy-is-paying-off/d/d-id/753863 )

Wir hoffen, dass Ihnen dieser Artikel gefallen hat . In den nächsten Beiträgen dieser Reihe werden wir uns die Vorteile von OpenShift gegenüber Kubernetes in jeder der hier diskutierten Kategorien genauer ansehen.

OpenShift als Unternehmensversion von Kubernetes