«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
