«Wat is het verschil tussen Kubernetes en OpenShift?» – deze vraag komt met een opmerkelijke regelmaat voor. Het is eigenlijk vergelijkbaar met vragen wat het verschil is tussen een auto en een motor. Als we de analogie voortzetten, dan is een auto een kant-en-klaar product dat je direct kunt gebruiken: stap in en rij weg. Aan de andere kant, om de motor je ergens naartoe te laten brengen, moet je deze aanvullen met een heleboel andere onderdelen, om uiteindelijk hetzelfde voertuig te krijgen.
Daarom is Kubernetes de motor waarop de auto (platform) van het merk OpenShift is gebouwd, die je naar je bestemming brengt.
In dit artikel willen we de volgende belangrijke punten kort herhalen en iets uitvoeriger bespreken:
- Kubernetes is het hart van het OpenShift-platform En dit is 100% gecertificeerd Kubernetes, met volledig open source code en zonder enige eigendomsaspecten. Samengevat:
- De API voor het OpenShift-cluster is 100% Kubernetes.
- Als een container in een ander Kubernetes-systeem werkt, dan zal deze zonder enige wijziging ook op OpenShift functioneren. Wijzigingen aan toepassingen zijn niet nodig.
- OpenShift voegt niet alleen nuttige functies en mogelijkheden toe aan Kubernetes. Net als een auto is OpenShift direct gebruiksklaar, het kan onmiddellijk in productie worden genomen en, zoals we hieronder laten zien, vergemakkelijkt het het leven van de ontwikkelaar aanzienlijk. Daarom is OpenShift uniek in zijn dubbelzinnigheid. Het is zowel een succesvolle, gevestigde PaaS-platform van ondernemingsklasse vanuit het perspectief van de ontwikkelaar, als een superbetrouwbare oplossing van het type Container-as-a-Service vanuit het oogpunt van industriële exploitatie.
OpenShift is Kubernetes met 100% certificering van de CNCF-stichting
De basis van OpenShift is . Daarom zijn gebruikers na de juiste training vaak onder de indruk van de kracht van kubectl. En degenen die zijn overgestapt van een Kubernetes-cluster naar OpenShift, zeggen vaak hoezeer ze het waarderen dat na het omleiden van kubeconfig naar het OpenShift-cluster, alle bestaande scripts probleemloos werken.
Je hebt waarschijnlijk gehoord over de OpenShift-cli-tool genaamd OC. Deze is volledig compatibel qua commando's met kubectl en biedt bovendien verschillende nuttige helpers die van pas komen bij het uitvoeren van een reeks taken. Maar laten we eerst iets dieper ingaan op de compatibiliteit van OC en kubectl:
kubectl-commando's
OC-commando's
kubectl get pods
oc get pods
kubectl get namespaces
oc get namespaces
kubectl create -f deployment.yaml
oc create -f deployment.yaml
Hier zijn de resultaten van het gebruik van kubectl op de OpenShift API:
• kubectl get pods – verwachtbare terugkeer van pods.
• kubectl get namespaces – verwachtbare terugkeer van namespaces.
De opdracht kubectl create -f mydeployment.yaml creëert Kubernetes-resources op dezelfde manier zoals op elke andere Kubernetes-platform, zoals getoond in de video hieronder:
Met andere woorden, alle Kubernetes-API's zijn volledig toegankelijk in OpenShift met 100% compatibiliteit. Daarom .
OpenShift voegt nuttige functies toe aan Kubernetes.
Kubernetes-API's zijn 100% toegankelijk in OpenShift, maar de standaard Kubernetes-tool kubectl mist duidelijk functionaliteit en gebruiksvriendelijkheid. Daarom heeft Red Hat Kubernetes aangevuld met nuttige functies en commandoregel-tools zoals OC (OpenShift client) en ODO (OpenShift DO, deze tool is bedoeld voor ontwikkelaars).
1. De OC-tool is een krachtigere en gebruiksvriendelijke variant van Kubectl.
Bijvoorbeeld, in tegenstelling tot kubectl, stelt het in staat om nieuwe namespaces te creëren en gemakkelijk van context te wisselen, en biedt het een reeks nuttige opdrachten voor ontwikkelaars, zoals voor het bouwen van containerimages en het implementeren van applicaties rechtstreeks vanuit broncode of binaire bestanden (Source-to-image, s2i).
Laten we aan de hand van voorbeelden bekijken hoe de ingebouwde helpers en uitgebreide functionaliteit van de OC-tool het dagelijkse werk vereenvoudigen.
Voorbeeld één – beheer van namespaces. In elke Kubernetes-cluster zijn er altijd verschillende namespaces. Deze worden gewoonlijk gebruikt voor het creëren van ontwikkel- en productieomgevingen, maar kunnen ook worden toegepast om bijvoorbeeld elke ontwikkelaar een persoonlijke 'sandbox' te geven. In de praktijk betekent dit dat ontwikkelaars vaak moeten schakelen tussen namespaces, aangezien kubectl werkt in de context van de huidige namespace. Daarom gebruiken mensen bij het werken met kubectl actief helper-scripts. Maar bij het gebruik van OC is het voldoende om te zeggen “oc project namespace_naam” om naar de juiste namespace over te schakelen.
Vergeet je de naam van de benodigde namespace? Geen probleem, typ gewoon “oc get projects” om de volledige lijst weer te geven. Ben je sceptisch benieuwd hoe dit werkt als je alleen toegang hebt tot een beperkt subset van namespaces in de cluster? Dat komt omdat kubectl dit correct doet, alleen als RBAC je toestaat om alle namespaces in de cluster te zien, en in grote clusters hebben niet alle gebruikers zulke rechten. Het antwoord is: voor OC is dat helemaal geen probleem en het geeft in een dergelijke situatie eenvoudig de volledige lijst weer. Dit soort details vormen de bedrijfsmatige focus van Openshift en de goede schaalbaarheid van dit platform op het gebied van gebruikers en applicaties.
2. ODO – een verbeterde versie van kubectl voor developers
Een ander voorbeeld van verbeteringen van Red Hat OpenShift ten opzichte van Kubernetes is de ODO commandoregeltool. Deze is bedoeld voor ontwikkelaars en maakt het mogelijk om lokale code snel op een externe OpenShift-cluster te implementeren. Bovendien kun je met deze tool interne processen optimaliseren om direct alle codewijzigingen met containers op de externe OpenShift-cluster te synchroniseren, zonder dat je opnieuw de builds, registraties en implementaties van afbeeldingen hoeft uit te voeren.
Laten we eens bekijken hoe OC en ODO het werken met containers en Kubernetes vergemakkelijken.
Laten we een paar workflows vergelijken, wanneer ze zijn gebaseerd op kubectl, en wanneer OC of ODO worden gebruikt.
• Code implementatie op OpenShift voor degenen die de YAML-taal niet beheersen:
Kubernetes / kubectl
$> git clone
1- Maak een Dockerfile die de afbeelding uit de code bouwt
————–
FROM node
WORKDIR /usr/src/app
COPY package*.json ./
COPY index.js ./
COPY ./app ./app
RUN npm install
EXPOSE 3000
CMD [ “npm”, “start” ]
————–
2- Bouw de afbeelding
$> podman build ...
3- Log in op de registry
podman login ...
4- Plaats de afbeelding in de registry
podman push
5- Maak yaml-bestanden voor de implementatie van de applicatie (deployment.yaml, service.yaml, ingress.yaml) – dit is het absolute minimum
6- Implementeer manifest-bestanden:
Kubectl apply -f .
OpenShift / oc
$> oc new-app – naam_van_onze_applicatie
OpenShift / odo
$> git clone
$> odo create component nodejs myapp
$> odo push
• Context wisselen: het veranderen van de actieve namespace of actieve cluster.
Kubernetes / kubectl
1- Maak een context in kubeconfig voor het project “myproject”
2- kubectl set-context ...
OpenShift / oc
oc project “myproject”
Kwaliteitscontrole: "Hier is een interessante functie verschenen, momenteel in de alfa-versie. Zullen we deze in productie nemen?"
Stel je voor dat je in een raceauto wordt gezet en men zegt: "We hebben hier nieuwe type remmen geïnstalleerd en om eerlijk te zijn, zijn ze nog niet helemaal betrouwbaar… Maar maak je geen zorgen, we zullen ze actief bijwerken tijdens het kampioenschap." Hoe vind je die vooruitzicht? Voor ons bij Red Hat voelt dat niet zo goed. 🙂
Daarom proberen we alias versies te vermijden totdat ze voldoende zijn verfijnd, we grondige operationele tests hebben uitgevoerd en we ons zeker voelen dat ze veilig te gebruiken zijn. Gewoonlijk doorlopen ze eerst de Dev Preview-fase, daarna en pas dan worden ze vrijgegeven als een publieke release (GA), die al zo stabiel is dat deze geschikt is voor productie.
Waarom is dat zo? Omdat, net als bij de ontwikkeling van andere software, niet alle oorspronkelijke ideeën in Kubernetes de definitieve release halen. Of ze halen de release, maar zelfs als ze de bedoelde functionaliteit behouden, verschilt hun uitvoering drastisch van die in de alfa-versie. Aangezien duizenden klanten van Red Hat OpenShift gebruiken voor kritieke taken, leggen we een bijzondere nadruk op de stabiliteit van ons platform en op langdurige ondersteuning.
Red Hat brengt opzettelijk frequente releases van OpenShift uit en werkt de bijbehorende versie van Kubernetes bij. Bijvoorbeeld, in de huidige GA-release van OpenShift 4.3, die op het moment van schrijven is ingebouwd, is Kubernetes 1.16 geïntegreerd, wat slechts één versie achterloopt op de upstream-versie van Kubernetes met nummer 1.17. Zo proberen we de klant een enterprise-klasse Kubernetes te bieden en extra kwaliteitscontrole te waarborgen bij het uitbrengen van nieuwe versies van OpenShift.
Softwarefixes: "In die versie van Kubernetes die we in productie hebben, is een gat gevonden. En het kan alleen worden gesloten door naar drie versies omhoog te updaten. Of zijn er opties?"
In het kader van het open-sourceproject Kubernetes worden softwarefixes gewoonlijk meegeleverd in de volgende release, soms dekken ze een of twee vorige tussentijdse releases, wat een reikwijdte geeft van tot 6 maanden terug.
Red Hat is rightly proud of releasing critical fixes earlier than others and providing support for a much longer period. For example, let's take the privilege escalation vulnerability in Kubernetes (): it was discovered in Kubernetes 1.11, whereas fixes for earlier releases were only released up to version 1.10.11, leaving a gap in all previous Kubernetes releases from 1.x to 1.9.
In turn, (which uses Kubernetes 1.2), encompassing nine releases of OpenShift and clearly demonstrating its commitment to customers (see more ).
How OpenShift and Red Hat Drive Kubernetes Forward
Red Hat ranks second in size of code contributions to the open Kubernetes project, only behind Google, with 3 out of the 5 most prolific developers being Red Hat employees. Another lesser-known fact: many critical features in Kubernetes emerged thanks to the initiatives of Red Hat, specifically such as:
- RBAC. Kubernetes did not have RBAC features (ClusterRole, ClusterRoleBinding) until Red Hat engineers decided to implement them as part of the platform itself, rather than as additional functionality in OpenShift. Is Red Hat afraid to enhance Kubernetes? Of course not, because Red Hat strictly adheres to open-source principles and does not play Open Core games. Improvements and innovations implemented at the level of development communities, rather than on a proprietary basis, become more sustainable and receive wider adoption, which aligns perfectly with our main goal – to make open-source software more beneficial for our customers.
- Pod Security Policies. This concept of securely running applications within pods was initially implemented in OpenShift under the name SCC (Security Context Constraints). And as in the previous example, Red Hat decided to incorporate these developments into the open Kubernetes project so that anyone who wishes can benefit from them.
This series of examples can continue, but we just wanted to show that Red Hat is genuinely committed to developing Kubernetes and making it better for everyone.
Clearly, OpenShift is Kubernetes. So what are the differences? 🙂
We hope that after reading this far, you understand that Kubernetes is a core component of OpenShift. A core, but far from the only one. In other words, simply installing Kubernetes will not give you an enterprise-class platform. You will need to add authentication, networking, security, monitoring, logging management, and much more. Additionally, you will have to make a difficult choice from a plethora of available tools (to appreciate the diversity of the ecosystem, just take a look at the ) and somehow ensure consistency and coherence so that they work as a whole. Furthermore, you will regularly need to perform updates and regression testing whenever a new version of any of the components you are using is released. That is, besides creating and maintaining the platform itself, you will also have to deal with all this software. It's unlikely that much time will be left for solving business problems and achieving competitive advantages.
In the case of OpenShift, Red Hat takes on all these complexities and simply provides you with a functionally complete platform that includes not only Kubernetes itself but also the entire set of necessary open-source tools that turn Kubernetes into a true enterprise-class solution that you can safely launch into production immediately. And of course, if you have any of your own technology stacks, you can integrate OpenShift into your existing solutions.
Take a look at the figure above: everything outside the Kubernetes rectangle represents areas where Red Hat adds features that are not present in Kubernetes by design. Now, we will examine the main of these areas.
1. A reliable OS as a foundation: RHEL CoreOS or RHEL
Red Hat is al meer dan 20 jaar een toonaangevende leverancier van Linux-distributies voor kritieke bedrijfsapplicaties. De uitgebreide en voortdurend bijgewerkte ervaring op dit gebied stelt ons in staat om een echt betrouwbare en vertrouwde basis voor industriële containeroperaties te bieden. RHEL CoreOS gebruikt dezelfde kernel als RHEL, maar is voornamelijk geoptimaliseerd voor taken zoals het uitvoeren van containers en het werken in Kubernetes-clusters: de kleinere omvang en de onveranderlijkheid (immutability) vereenvoudigen het opzetten van clusters, autoscaling, het uitrollen van patches, enz. Al deze kenmerken maken het de ideale basis voor een consistente gebruikerservaring bij het werken met OpenShift in verschillende compute-omgevingen, van 'bare metal' tot privé- en publieke cloud.
2. Automatisering van IT-operaties
Automatisering van installatieprocessen en tweede-dag operaties (d.w.z. dagelijkse exploitatie) is de sterke kant van OpenShift, wat het beheer, de updates en het onderhoud van de containerplatforms op een hoog niveau aanzienlijk vergemakkelijkt. Dit wordt bereikt door de ondersteuning van Kubernetes-operators op het niveau van de kern van OpenShift 4.
OpenShift 4 is ook een compleet ecosysteem van oplossingen gebaseerd op Kubernetes-operators, ontwikkeld zowel door Red Hat als door externe partners (zie Red Hat, of de winkel voor operatoren , gemaakt door Red Hat voor externe ontwikkelaars).
De geïntegreerde catalogus van OpenShift 4 bevat meer dan 180 Kubernetes-operators.
3. Hulpmiddelen voor ontwikkelaars
Sinds 2011 is OpenShift beschikbaar als een PaaS (Platform-as-a-Service), die het leven voor ontwikkelaars aanzienlijk vereenvoudigt, hen helpt zich te concentreren op het schrijven van code en ingebouwde ondersteuning biedt voor programmeertalen zoals Java, Node.js, PHP, Ruby, Python, Go, evenals diensten voor continue integratie en levering CI/CD, databases, enz. OpenShift 4 biedt , inclusief meer dan 100 services gebaseerd op Kubernetes-operators, ontwikkeld door Red Hat en onze partners.
In tegenstelling tot Kubernetes heeft OpenShift 4 een speciale grafische interface (), behulpzaam voor ontwikkelaars om zonder veel moeite applicaties uit verschillende bronnen (git, externe register, Dockerfile enz.) in hun namespaces te implementeren en visueel de verbindingen tussen applicatiecomponenten te visualiseren.
Bovendien biedt OpenShift een set ontwikkeltools Codeready aan, waaronder: , een volledig gecontaineriseerde IDE met een webinterface, die rechtstreeks bovenop OpenShift werkt en het 'IDE-as-a-service'-concept implementeert. Aan de andere kant, voor degenen die strikt in lokale modus willen werken, is er Codeready Containers – een volwaardige versie van OpenShift 4 die op een laptop kan worden geïmplementeerd.
Geïntegreerde 'IDE als service' voor efficiënte ontwikkeling op het Kubernetes/OpenShift-platform.
Direct uit de doos biedt OpenShift een volledig CI/CD-systeem, ofwel op basis van gecontaineriseerde Jenkins en de plugin. voor de verwerking van pipelines, of een Kubernetes-georiënteerd CI/CD-systeem. (momenteel in de Tech preview-versie). Beide oplossingen zijn volledig geïntegreerd met de OpenShift-console, waardoor het mogelijk is om pipeline-triggers te starten, implementaties, logs enz. te bekijken.
4. Applicatietools
OpenShift maakt het mogelijk zowel traditionele stateful-applicaties als cloud-georiënteerde oplossingen op basis van nieuwe architecturen, zoals microservices of serverless, te implementeren. De OpenShift Service Mesh-oplossing bevat uit de doos belangrijke tools voor het beheren van microservices, zoals Istio, Kiali en Jaeger. Bovendien bevat de OpenShift Serverless-oplossing niet alleen Knative, maar ook tools die zijn ontwikkeld in samenwerking met Microsoft, zoals Keda, voor het aanbieden van Azure-functies op het OpenShift-platform.
De geïntegreerde OpenShift ServiceMesh-oplossing (Istio, Kiali, Jaeger) zal nuttig zijn bij de ontwikkeling van microservices.
Om de kloof tussen legacy-applicaties en containers te overbruggen, stelt OpenShift nu in staat om virtuele machines naar het OpenShift-platform te migreren met behulp van Container Native Virtualization (momenteel in de TechPreview-versie), waardoor hybride applicaties werkelijkheid worden en het gemakkelijker wordt om ze tussen verschillende clouds, zowel privé als publiek, te verplaatsen.
Een Windows 2019 Virtual machine, uitgevoerd op OpenShift via Container Native Virtualization (momenteel in de Tech preview-versie).
5. Cluster tools
Elke enterprise-grade platform moet monitoringservices en centrale logboekregistratie hebben, beveiligingsmechanismen, authenticatie en autorisatie, en netwerkinstrumenten. OpenShift biedt dit allemaal out-of-the-box, en alles is 100% open source, inclusief oplossingen zoals ElasticSearch, Prometheus en Grafana. Al deze oplossingen worden geleverd met dashboards, metrics en meldingen die al zijn samengesteld en geconfigureerd op basis van de uitgebreide ervaring van Red Hat op het gebied van clusterbewaking, wat het mogelijk maakt om de werking van uw productieomgeving vanaf het begin effectief te controleren en te volgen.
OpenShift beschikt ook standaard over belangrijke zaken voor zakelijke klanten, zoals authenticatie met een ingebouwde oauth-provider, integratie met credential-providers, waaronder LDAP, ActiveDirectory, OpenID Connect, en nog veel meer.
Vooraf geconfigureerd Grafana-dashboard voor het monitoren van het OpenShift-cluster
Meer dan 150 vooraf geconfigureerde metrics en meldingen van Prometheus voor het monitoren van het OpenShift-cluster
To be continued
De rijke functionaliteit van de oplossing en de uitgebreide ervaring van Red Hat op het gebied van Kubernetes – om deze redenen heeft OpenShift een dominante positie op de markt ingenomen, zoals hieronder weergegeven (meer informatie ).
«Momenteel is Red Hat marktleider met een aandeel van 44%.
Het bedrijf plukt de vruchten van zijn verkoopstrategie met actieve betrokkenheid bij de klant, waarbij het eerst advies en training biedt aan ondernemingsontwikkelaars, en vervolgens overgaat tot monetisatie zodra het bedrijf containers in productie begint te implementeren».
(Bron: )
We hopen dat je dit artikel leuk vond. In de volgende berichten in deze serie zullen we dieper ingaan op de voordelen van OpenShift in vergelijking met Kubernetes in elk van de hier behandelde categorieën.
Bron: habr.com
