âWas ist der Unterschied zwischen Kubernetes und OpenShift?â â diese Frage hört man mit bemerkenswerter RegelmĂ€Ăigkeit. TatsĂ€chlich ist es jedoch so, als wĂŒrde man fragen, worin der Unterschied zwischen einem Auto und einem Motor besteht. Setzt man die Analogie fort, dann ist das Auto ein fertiges Produkt, das sofort genutzt werden kann: man setzt sich einfach hinein und fĂ€hrt los. Andererseits muss der Motor vorher um viele andere Dinge ergĂ€nzt werden, um am Ende dasselbe Auto zu erhalten.
Deshalb ist Kubernetes der Motor, um den das Auto (die Plattform) OpenShift gebaut ist, das Sie zu Ihrem Ziel bringt.
In diesem Artikel möchten wir folgende SchlĂŒsselpunkte wieder in Erinnerung rufen und etwas detaillierter erlĂ€utern:
- Kubernetes ist das Herz der OpenShift-Plattform und es handelt sich um ein zu 100 % zertifiziertes Kubernetes, mit vollstÀndig offenem Code und ohne jegliche ProprietaritÀt. Kurz gesagt:
- Die API fĂŒr den OpenShift-Cluster ist ein hundertprozentiges Kubernetes.
- Wenn ein Container in einem anderen Kubernetes-System funktioniert, wird er ohne Ănderungen auch auf OpenShift funktionieren. Es sind keine Ănderungen an den Anwendungen erforderlich.
- OpenShift ergĂ€nzt Kubernetes nicht nur mit nĂŒtzlichen Funktionen und Möglichkeiten. Ăhnlich wie ein Auto ist OpenShift sofort einsatzbereit, es kann sofort in Produktion genommen werden und, wie wir weiter unten zeigen werden, vereinfacht es das Leben der Entwickler erheblich. Daher ist OpenShift in zwei Gesichtern einzigartig. Es ist sowohl eine erfolgreiche und weithin bekannte PaaS-Plattform auf Unternehmensniveau, wenn man aus der Sicht des Entwicklers schaut. Gleichzeitig ist es eine Ă€uĂerst zuverlĂ€ssige Container-as-a-Service-Lösung aus Sicht des industriellen Betriebs.
OpenShift ist Kubernetes mit 100 % Zertifizierung durch die CNCF-Stiftung.
Im Kern von OpenShift liegt . Deshalb sind Benutzer nach der entsprechenden Schulung von der LeistungsfÀhigkeit von kubectl begeistert. Und diejenigen, die von einem Kubernetes-Cluster zu OpenShift gewechselt haben, berichten hÀufig begeistert, dass nach der Weiterleitung von kubeconfig auf den OpenShift-Cluster alle vorhandenen Skripte einwandfrei funktionieren.
Sie haben bestimmt von dem OpenShift-Command-Line-Tool namens OC gehört. Es ist vollstĂ€ndig kompatibel mit den Befehlen von kubectl und bietet zusĂ€tzlich einige nĂŒtzliche Helfer, die bei der DurchfĂŒhrung einer Reihe von Aufgaben nĂŒtzlich sind. Aber zuerst etwas detaillierter ĂŒber die KompatibilitĂ€t von OC und kubectl:
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 Nutzung von kubectl mit der OpenShift API aus:
âą kubectl get pods â gibt wie erwartet Pods zurĂŒck.
âą kubectl get namespaces â gibt wie erwartet NamensrĂ€ume zurĂŒck.
Der Befehl kubectl create -f mydeployment.yaml erstellt Kubernetes-Ressourcen genau wie auf jeder anderen Kubernetes-Plattform, wie im folgenden Video gezeigt:
Anders ausgedrĂŒckt, alle Kubernetes-APIs sind vollstĂ€ndig in OpenShift verfĂŒgbar und bieten 100 % KompatibilitĂ€t. Deshalb .â
OpenShift ergĂ€nzt Kubernetes mit nĂŒtzlichen Funktionen.
Die Kubernetes-APIs sind zu 100 % in OpenShift verfĂŒgbar, aber das native Kubernetes-Tool kubectl hat eindeutig an FunktionalitĂ€t und Benutzerfreundlichkeit gefehlt. Daher hat Red Hat Kubernetes um nĂŒtzliche Funktionen und Befehlszeilen-Tools wie OC (Kurzform von OpenShift Client) und ODO (OpenShift DO, dieses Tool ist fĂŒr Entwickler gedacht) erweitert.
1. Das OC-Tool â eine leistungsfĂ€higere und benutzerfreundlichere Version von Kubectl.
Zum Beispiel erlaubt es im Gegensatz zu kubectl, neue NamensrĂ€ume zu erstellen und den Kontext leicht zu wechseln. AuĂerdem bietet es eine Reihe nĂŒtzlicher Befehle fĂŒr Entwickler, um Containerbilder zu erstellen und Anwendungen direkt aus Quellcode oder BinĂ€rdateien bereitzustellen (Source-to-Image, s2i).
Schauen wir uns anhand von Beispielen an, wie die eingebauten Hilfsfunktionen und die erweiterte FunktionalitÀt des OC-Tools helfen, die alltÀgliche Arbeit zu vereinfachen.
Beispiel eins â Verwaltung von NamensrĂ€umen. In jedem Kubernetes-Cluster gibt es immer mehrere NamensrĂ€ume. Sie werden normalerweise verwendet, um Entwicklungs- und Produktionsumgebungen zu erstellen, können aber auch dazu dienen, jedem Entwickler eine persönliche âSandkisteâ zu geben. In der Praxis fĂŒhrt dies dazu, dass Entwickler hĂ€ufig zwischen NamensrĂ€umen wechseln mĂŒssen, da kubectl im Kontext des aktuellen Namensraums arbeitet. Daher verwenden viele Menschen Hilfsskripte fĂŒr kubectl. Bei der Verwendung von OC reicht es jedoch aus, zu sagen âoc project namensraumâ, um auf den gewĂŒnschten Namensraum zu wechseln.
Erinnern Sie sich nicht, wie der benötigte Namensraum heiĂt? Kein Problem, geben Sie einfach âoc get projectsâ ein, um die vollstĂ€ndige Liste anzuzeigen. Sie fragen sich skeptisch, wie das funktioniert, wenn Sie nur Zugriff auf eine eingeschrĂ€nkte Untermenge von Namespaces im Cluster haben? Nun, kubectl funktioniert nur dann korrekt, wenn RBAC Ihnen erlaubt, alle Namespaces im Cluster zu sehen, und in groĂen Clustern haben nicht alle diese Berechtigung. Also, hier die Antwort: FĂŒr OC ist das gar kein Problem und es wird in dieser Situation problemlos die vollstĂ€ndige Liste ausgeben. Solche Kleinigkeiten machen die Unternehmensorientierung von Openshift und die gute Skalierbarkeit dieser Plattform hinsichtlich Benutzer und Anwendungen aus.
2. ODO â die verbesserte Version von kubectl fĂŒr Entwickler
Ein weiteres Beispiel fĂŒr Verbesserungen von Red Hat OpenShift im Vergleich zu Kubernetes ist das Command Line Tool ODO. Es ist fĂŒr Entwickler konzipiert und ermöglicht das schnelle Bereitstellen von lokalem Code auf einem entfernten OpenShift-Cluster. DarĂŒber hinaus kann es interne Prozesse optimieren, um alle CodeĂ€nderungen sofort mit Containern im entfernten OpenShift-Cluster zu synchronisieren, ohne den Build-, Registry-Upload und das erneute Bereitstellen von Images durchzufĂŒhren.
Lassen Sie uns sehen, wie OC und ODO die Arbeit mit Containern und Kubernetes erleichtern.
Vergleichen wir einfach einige ArbeitsablÀufe, wenn sie auf basi kubectl basieren und wenn OC oder ODO verwendet werden.
âą Bereitstellung von Code auf OpenShift fĂŒr diejenigen, die mit YAML nicht vertraut sind:
Kubernetes / kubectl
$> git clone
1- Erstellen Sie eine Dockerfile, die 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 Registry an
podman login âŠ
4- Laden Sie das Image in die Registry hoch
podman push
5- Erstellen Sie YAML-Dateien fĂŒr die Bereitstellung der Anwendung (deployment.yaml, service.yaml, ingress.yaml) â das ist das absolute Minimum
6- Stellen Sie die Manifestdateien bereit:
Kubectl apply -f .
OpenShift / oc
$> oc new-app â name_unserer_anwendung
OpenShift / odo
$> git clone
$> odo create component nodejs myapp
$> odo push
âą Kontextwechsel: Ănderungen des Arbeits-Namensraums oder des Arbeits-Clusters.
Kubernetes / kubectl
1- Erstellen Sie einen Kontext in kubeconfig fĂŒr das Projekt âmyprojectâ
2- kubectl set-context âŠ
OpenShift / oc
oc project âmyprojectâ
QualitĂ€tskontrolle: âHier gibt es eine interessante Funktion, die sich momentan in der Alpha-Phase befindet. Sollen wir sie in die Produktion einfĂŒhren?â
Stellen Sie sich vor, Sie sitzen in einem Rennwagen und jemand sagt: âWir haben hier neue Bremsen eingebaut, und ehrlich gesagt, ihre ZuverlĂ€ssigkeit ist noch nicht optimal⊠Aber machen Sie sich keine Sorgen, wir werden sie wĂ€hrend der Meisterschaft aktiv weiterentwickeln.â Wie finden Sie diese Perspektive? Uns bei Red Hat gefĂ€llt das nicht besonders. đ
Deshalb versuchen wir, von Alpha-Versionen abzusehen, bis sie ausreichend ausgereift sind, und wir umfassende Tests durchgefĂŒhrt haben, sodass wir sicher sind, dass sie sicher verwendet werden können. Normalerweise durchlaufen unsere Produkte zuerst eine Dev Preview-Phase, dann eine und erst dann wird eine allgemeine Veröffentlichung (GA) bereitgestellt, die stabil genug ist, um in der Produktion eingesetzt zu werden.
Warum ist das so? Weil, wie bei der Entwicklung jeder anderen Software, nicht alle anfĂ€nglichen Ideen in Kubernetes bis zur endgĂŒltigen Veröffentlichung gelangen. Oder sie gelangen dahin und behalten sogar ihre geplante FunktionalitĂ€t bei, aber deren Umsetzung unterscheidet sich grundlegend von der, die in der Alpha-Version vorgestellt wurde. Da tausende Kunden von Red Hat OpenShift fĂŒr kritische Anwendungen verwenden, legen wir besonderen Wert auf die StabilitĂ€t unserer Plattform und auf langfristigen Support.
Red Hat veröffentlicht gezielt hĂ€ufige Versionen von OpenShift und aktualisiert die darin enthaltene Version von Kubernetes. Zum Beispiel ist in dem zum Zeitpunkt der Erstellung dieses Artikels aktuellen GA-Release von OpenShift 4.3 Kubernetes 1.16 integriert, das nur um eine Version hinter der upstream-Version von Kubernetes mit der Nummer 1.17 zurĂŒckbleibt. So versuchen wir, unseren Kunden eine Unternehmensversion von Kubernetes anzubieten und zusĂ€tzliche QualitĂ€tskontrolle bei der Veröffentlichung neuer Versionen von OpenShift sicherzustellen.
Software-Updates: âIn der Version von Kubernetes, die wir in der Produktion haben, gibt es eine SicherheitslĂŒcke. Und diese kann nur durch ein Update um drei Versionen nach oben geschlossen werden. Oder gibt es Alternativen?â
Im Rahmen des Open-Source-Projekts Kubernetes werden Software-Updates normalerweise in die nĂ€chste Version integriert, manchmal decken sie auch ein oder zwei vorherige Zwischenversionen ab, was einen Zeitraum von insgesamt 6 Monaten zurĂŒck abdeckt.
Red Hat kann zu Recht stolz darauf sein, kritische Sicherheitsupdates frĂŒher als andere zu veröffentlichen und eine weitaus lĂ€ngere UnterstĂŒtzung zu bieten. Nehmen wir zum Beispiel die Schwachstelle der Privilegieneskalation in Kubernetes (): Sie wurde in Kubernetes 1.11 entdeckt, wĂ€hrend die Patches fĂŒr frĂŒhere Versionen nur bis zur Version 1.10.11 veröffentlicht wurden, was diese Version in eine SicherheitslĂŒcke ĂŒber alle vorherigen Kubernetes-Versionen von 1.x bis 1.9 lieĂ.
Im Gegenzug (dort lÀuft Kubernetes 1.2), was neun OpenShift-Versionen umfasst und deutlich zeigt, dass es Red Hat um die Kunden geht (mehr dazu ).
Wie OpenShift und Red Hat Kubernetes voranbringen
Red Hat belegt den zweiten Platz bei der GröĂe des Softwarebeitrags zum Open-Source-Projekt Kubernetes, wobei nur Google hier vorne liegt, und 3 der 5 produktivsten Entwickler sind Mitarbeiter von Red Hat. Ein weiterer wenig bekannter Fakt: Viele kritische Funktionen wurden in Kubernetes auf Initiative von Red Hat hinzugefĂŒgt, insbesondere solche wie:
- RBAC. In Kubernetes gab es keine RBAC-Funktionen (ClusterRole, ClusterRoleBinding), bis Red Hat-Ingenieure sich entschlossen haben, diese in die Plattform zu integrieren und nicht als zusĂ€tzliche FunktionalitĂ€t in OpenShift bereitzustellen. Hat Red Hat Angst, Kubernetes zu verbessern? NatĂŒrlich nicht, denn Red Hat folgt strengen Open-Source-Prinzipien und spielt nicht mit Open-Core. Verbesserungen und Innovationen, die auf der Ebene der Entwicklergemeinschaften umgesetzt werden und nicht nach dem Prinzip der ProprietaritĂ€t, sind nachhaltiger und verbreiten sich breiter, was hervorragend mit unserem Hauptziel ĂŒbereinstimmt â die Open-Source-Software fĂŒr unsere Kunden nĂŒtzlicher zu machen.
- Sicherheitsrichtlinien fĂŒr Pods (Pod Security Policies). UrsprĂŒnglich wurde dieses Konzept fĂŒr die sichere AusfĂŒhrung von Anwendungen innerhalb von Pods in OpenShift unter dem Namen SCC (Security Context Constraints) umgesetzt. Und wie im vorherigen Beispiel entschloss sich Red Hat, diese Entwicklungen in das Open-Source-Projekt Kubernetes zu integrieren, sodass sie von allen Interessierten genutzt werden können.
Diese Reihe von Beispielen könnte man fortsetzen, aber wir wollten lediglich zeigen, dass Red Hat wirklich bestrebt ist, Kubernetes weiterzuentwickeln und es fĂŒr alle besser zu machen.
Klar, OpenShift ist Kubernetes. Was sind die Unterschiede? đ
Wir hoffen, dass Sie beim Lesen an dieser Stelle verstanden haben, dass Kubernetes der Hauptbestandteil von OpenShift ist. HauptsĂ€chlich, aber bei weitem nicht der einzige. Mit anderen Worten, allein durch die Installation von Kubernetes erhalten Sie keine Unternehmensplattform. Sie mĂŒssen Authentifizierung, Netzwerk, Sicherheit, Ăberwachung, Protokollmanagement und vieles mehr hinzufĂŒgen. DarĂŒber hinaus mĂŒssen Sie eine schwierige Wahl aus einer Vielzahl verfĂŒgbarer Werkzeuge treffen (um die Vielfalt des Ăkosystems zu bewerten, werfen Sie einfach einen Blick auf die ) und sicherstellen, dass sie konsistent und harmonisch zusammenarbeiten, damit sie als Ganzes funktionieren. DarĂŒber hinaus mĂŒssen Sie regelmĂ€Ăig Updates und Regressionstests durchfĂŒhren, wenn eine neue Version eines der verwendeten Komponenten veröffentlicht wird. Das bedeutet, dass Sie neben der Erstellung und Wartung der Plattform auch all diese Software verwalten mĂŒssen. Es bleibt wohl kaum Zeit, um GeschĂ€ftsfragen zu klĂ€ren und Wettbewerbsvorteile zu erzielen.
Im Gegensatz dazu ĂŒbernimmt Red Hat bei OpenShift all diese KomplexitĂ€ten und bietet Ihnen einfach eine funktional vollstĂ€ndige Plattform, die nicht nur Kubernetes selbst, sondern auch das gesamte Set an notwendigen Open-Source-Tools umfasst, die Kubernetes in eine echte Unternehmenslösung verwandeln, die Sie sofort und ganz entspannt in der Produktion einsetzen können. Und natĂŒrlich, wenn Sie ĂŒber eigene Technologiestacks verfĂŒgen, können Sie OpenShift in Ihre bereits bestehenden Lösungen integrieren.
Sehen Sie sich das Bild oben an: Alles, was sich auĂerhalb des Rechtecks Kubernetes befindet, sind die Bereiche, in denen Red Hat Funktionen hinzufĂŒgt, die in Kubernetes von vornherein nicht enthalten sind. Und jetzt werden wir die wichtigsten dieser Bereiche besprechen.
1. ZuverlÀssiges Betriebssystem als Basis: RHEL CoreOS oder RHEL
Red Hat ist seit ĂŒber 20 Jahren ein fĂŒhrender Anbieter von Linux-Distributionen fĂŒr kritische GeschĂ€ftsanwendungen. Unsere umfangreiche und stĂ€ndig aktualisierte Erfahrung in diesem Bereich ermöglicht es uns, eine wirklich zuverlĂ€ssige und vertraute Grundlage fĂŒr den industriellen Einsatz von Containern anzubieten. RHEL CoreOS verwendet denselben Kernel wie RHEL, ist jedoch primĂ€r fĂŒr Aufgaben wie ContainerausfĂŒhrung und den Betrieb in Kubernetes-Clustern optimiert: Ihre reduzierte GröĂe und UnverĂ€nderlichkeit erleichtern die Installation von Clustern, Auto-Scaling, Deployment von Patches usw. All diese Funktionen machen sie zur idealen Basis 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 Installationsprozessen und zweiten Operationen (also des tĂ€glichen Betriebs) ist eine StĂ€rke von OpenShift, die die Verwaltung, Aktualisierung und den Betrieb der Containerplattform auf einem hohen Niveau erheblich erleichtert. Dies wird durch die UnterstĂŒtzung von Kubernetes-Operatoren auf Kernel-Ebene von OpenShift 4 erreicht.
OpenShift 4 ist auch ein ganzes Ăkosystem von Lösungen auf Basis von Kubernetes-Operatoren, die sowohl von Red Hat selbst als auch von Drittanbietern entwickelt wurden (siehe Red Hat oder den Operator-Shop , den Red Hat fĂŒr Drittentwickler erstellt hat).
Der integrierte Katalog von OpenShift 4 umfasst ĂŒber 180 Kubernetes-Operatoren
3. Entwickler-Tools
Seit 2011 steht OpenShift als PaaS-Plattform (Platform-as-a-Service) zur VerfĂŒgung, die das Leben der Entwickler erheblich erleichtert, ihnen hilft, sich auf das Codieren zu konzentrieren, und integrierte UnterstĂŒtzung fĂŒr Programmiersprachen wie Java, Node.js, PHP, Ruby, Python, Go sowie CI/CD-Dienste, Datenbanken usw. bietet. OpenShift 4 bietet , das mehr als 100 Dienste auf Basis von Kubernetes-Operatoren umfasst, die von Red Hat und unseren Partnern entwickelt wurden.
Im Gegensatz zu Kubernetes bietet OpenShift 4 eine spezielle grafische BenutzeroberflĂ€che (), der Entwicklern hilft, ohne groĂen Aufwand Anwendungen aus verschiedenen Quellen (git, externe Registries, Dockerfile usw.) in ihren NamensrĂ€umen bereitzustellen und die Verbindungen zwischen den Anwendungskomponenten anschaulich darzustellen.
DarĂŒber hinaus bietet OpenShift eine Sammlung von Entwicklungswerkzeugen Codeready, zu denen unter anderem gehört , eine vollstĂ€ndig containerisierte IDE mit WeboberflĂ€che, die direkt auf OpenShift lĂ€uft und den Ansatz 'IDE-as-a-Service' verfolgt. Andererseits gibt es fĂŒr diejenigen, die ausschlieĂlich im lokalen Modus arbeiten möchten, Codeready Containers â eine voll funktionsfĂ€hige Version von OpenShift 4, die auf einem Laptop bereitgestellt werden kann.
Integrierte 'IDE als Service' fĂŒr effizientes Entwickeln auf der Kubernetes/OpenShift-Plattform.
Direkt aus der Box bietet OpenShift ein umfassendes CI/CD-System, entweder basierend auf containerisiertem Jenkins und dem Plugin fĂŒr die Arbeit mit Pipelines oder einem auf Kubernetes ausgerichteten CI/CD-System. (derzeit in der Tech Preview-Version). Beide Lösungen integrieren sich nahtlos in die OpenShift-Konsole, sodass Sie Pipeline-Trigger auslösen sowie Bereitstellungen, Protokolle usw. einsehen können.
4. Werkzeuge fĂŒr Anwendungen
OpenShift ermöglicht die Bereitstellung von sowohl traditionellen stateful Anwendungen als auch cloudbasierten Lösungen auf Basis neuer Architekturen wie Microservices oder serverless. Die OpenShift Service Mesh-Lösung bringt direkt aus der Box wichtige Werkzeuge fĂŒr Microservices wie Istio, Kiali und Jaeger mit sich. Im Gegenzug umfasst die OpenShift Serverless-Lösung nicht nur Knative, sondern auch im Rahmen einer Zusammenarbeit mit Microsoft entwickelte Werkzeuge wie Keda zur Bereitstellung von Azure-Funktionen auf der OpenShift-Plattform.
Die integrierte Lösung OpenShift ServiceMesh (Istio, Kiali, Jaeger) ist nĂŒtzlich bei der Entwicklung von Microservices.
Um die LĂŒcke zwischen veralteten Anwendungen und Containern zu schlieĂen, ermöglicht OpenShift nun die Migration von virtuellen Maschinen auf die OpenShift-Plattform mithilfe von Container Native Virtualization (derzeit in der Tech Preview-Version), wodurch hybride Anwendungen RealitĂ€t werden und ihre Ăbertragung zwischen verschiedenen Clouds, sowohl privat als auch öffentlich, erleichtert wird.
Eine Windows 2019 Virtual-Maschine, die ĂŒber Container Native Virtualization (derzeit in der Tech Preview-Version) auf OpenShift lĂ€uft.
5. Werkzeuge fĂŒr Cluster
Jede Unternehmensklasse Plattform muss Monitoring-Dienste und eine zentralisierte ProtokollfĂŒhrung, Sicherheitsmechanismen, Authentifizierung und Autorisierung sowie Netzwerkverwaltungstools bieten. OpenShift bietet all das direkt ab Werk, und das alles in 100% Open-Source-Code, einschlieĂlich Lösungen wie ElasticSearch, Prometheus und Grafana. All diese Lösungen kommen mit Dashboards, Metriken und Benachrichtigungen, die bereits mit dem umfangreichen Erfahrungshorizont von Red Hat im Bereich Cluster-Monitoring konfiguriert und angepasst sind, was es Ihnen ermöglicht, Ihre Produktionsumgebung von Anfang an effektiv zu ĂŒberwachen und zu steuern.
OpenShift verfĂŒgt auch ĂŒber wichtige Funktionen fĂŒr Unternehmenskunden, wie integrierte Authentifizierung mit einem OAuth-Anbieter, Integration mit IdentitĂ€tsanbietern wie LDAP, ActiveDirectory, OpenID Connect und vieles mehr.
Vorkonfigurierte Grafana-Dashboard zur Ăberwachung des OpenShift-Clusters
Ăber 150 vorkonfigurierte Prometheus-Metriken und Benachrichtigungen zur Ăberwachung des OpenShift-Clusters
Fortsetzung folgt
Die umfangreiche FunktionalitÀt der Lösung und die umfassende Erfahrung von Red Hat im Bereich Kubernetes sind der Grund, warum OpenShift eine dominierende Position auf dem Markt einnimmt, wie in der folgenden Abbildung gezeigt (mehr dazu ).
âMomentan fĂŒhrt Red Hat mit einem Marktanteil von 44 %.
Das Unternehmen erntet die FrĂŒchte seiner Vertriebsstrategie, die eine aktive Beteiligung an den Angelegenheiten der Kunden umfasst, wobei es zunĂ€chst Unternehmensentwickler berĂ€t und schult, bevor es zur Monetarisierung ĂŒbergeht, sobald das Unternehmen beginnt, Container in der Produktion zu implementieren.â
(Quelle: )
Wir hoffen, dass Ihnen dieser Artikel gefallen hat. In den nÀchsten BeitrÀgen dieser Serie werden wir die Vorteile von OpenShift im Vergleich zu Kubernetes in jeder der hier behandelten Kategorien detaillierter erlÀutern.
Quelle: habr.com
