“Wat is het verschil tussen Kubernetes en OpenShift?” – deze vraag rijst met benijdenswaardige consistentie. Hoewel dit in werkelijkheid hetzelfde is als vragen hoe een auto verschilt van een motor. Als we de analogie voortzetten, dan is een auto een eindproduct, je kunt hem meteen gebruiken, letterlijk: instappen en weggaan. Aan de andere kant, wil een motor je ergens heen brengen, dan moet deze eerst aangevuld worden met een heleboel andere zaken om uiteindelijk dezelfde auto te krijgen.
Daarom is Kubernetes de motor waarrond de auto (platform) van het merk OpenShift is gemonteerd, die je naar je doel brengt.
In dit artikel willen we u eraan herinneren en de volgende belangrijke punten wat gedetailleerder onderzoeken:
- Kubernetes is het hart van het OpenShift-platform en is 100% gecertificeerd Kubernetes, volledig open source en zonder het minste eigendomsrecht. Kort:
- De OpenShift-cluster-API is XNUMX% Kubernetes.
- Als de container op een ander Kubernetes-systeem draait, draait deze zonder enige wijziging op OpenShift. Het is niet nodig om wijzigingen aan de applicaties aan te brengen.
- OpenShift voegt niet alleen handige features en functionaliteit toe aan Kubernetes. Net als een auto is OpenShift kant-en-klaar, kan onmiddellijk in productie worden genomen en maakt, zoals we hieronder zullen laten zien, het leven van een ontwikkelaar een stuk eenvoudiger. Daarom is OpenShift verenigd in twee personen. Het is zowel een succesvol als bekend PaaS-platform van ondernemingsklasse vanuit het perspectief van een ontwikkelaar. En tegelijkertijd is het vanuit het oogpunt van industriële exploitatie een superbetrouwbare Container-as-a-Service-oplossing.
OpenShift is Kubernetes met 100% CNCF-certificering
OpenShift is gebaseerd op . Daarom zijn gebruikers na een goede training verbaasd over de kracht van kubectl. En degenen die vanuit Kubernetes Cluster naar OpenShift zijn overgestapt, zeggen vaak hoe leuk ze het vinden dat na het omleiden van kubeconfig naar het OpenShift-cluster alle bestaande scripts feilloos werken.
Je hebt waarschijnlijk wel eens gehoord van het opdrachtregelhulpprogramma van OpenShift genaamd OC. Het is volledig commando-compatibel met kubectl, plus het biedt verschillende handige helpers die van pas zullen komen bij het uitvoeren van een aantal taken. Maar eerst iets meer over de compatibiliteit van OC en kubectl:
kubectl-opdrachten
OC-teams
kubectl pods ophalen
oc krijg peulen
kubectl haalt naamruimten op
oc krijg naamruimten
kubectl create -f deployment.yaml
oc create -f deployment.yaml
Hier ziet u hoe de resultaten van het gebruik van kubectl op de OpenShift API eruit zien:
• kubectl get pods – retourneert pods zoals verwacht.
• kubectl get namespaces – retourneert naamruimten zoals verwacht.
Met de opdracht kubectl create -f mydeployment.yaml worden Kubernetes-bronnen gemaakt, net als op elk ander Kubernetes-platform, zoals weergegeven in de onderstaande video:
Met andere woorden: alle Kubernetes API’s zijn volledig beschikbaar in OpenShift met behoud van 100% compatibiliteit. Dat is de reden .
OpenShift voegt handige functies toe aan Kubernetes
Kubernetes API's zijn 100% beschikbaar in OpenShift, maar het standaard Kubernetes-hulpprogramma kubectl mist duidelijk functionaliteit en gemak. Daarom heeft Red Hat handige features en opdrachtregeltools aan Kubernetes toegevoegd, zoals OC (afkorting van OpenShift client) en ODO (OpenShift DO, dit hulpprogramma is gericht op ontwikkelaars).
1. OC-hulpprogramma - een krachtigere en handigere versie van Kubectl
In tegenstelling tot kubectl kunt u hiermee bijvoorbeeld nieuwe naamruimten maken en eenvoudig van context wisselen, en biedt het ook een aantal handige opdrachten voor ontwikkelaars, zoals het bouwen van containerimages en het rechtstreeks implementeren van applicaties vanuit broncode of binaire bestanden (Source-to-image, s2i).
Laten we eens kijken naar voorbeelden van hoe de ingebouwde helpers en geavanceerde functionaliteit van het OC-hulpprogramma het dagelijkse werk helpen vereenvoudigen.
Het eerste voorbeeld is naamruimtebeheer. Elk Kubernetes-cluster heeft altijd meerdere naamruimten. Ze worden meestal gebruikt om ontwikkel- en productieomgevingen te creëren, maar kunnen ook gebruikt worden om bijvoorbeeld elke ontwikkelaar te voorzien van een persoonlijke sandbox. In de praktijk resulteert dit erin dat de ontwikkelaar regelmatig tussen naamruimten moet schakelen, omdat kubectl in de context van de huidige ruimte draait. Daarom gebruiken mensen in het geval van kubectl hiervoor actief helperscripts. Maar als je OC gebruikt, zeg je gewoon "oc projectnaamruimte" om naar de gewenste ruimte te schakelen.
Weet u niet meer hoe de naamruimte die u nodig heeft heet? Geen probleem, typ gewoon “oc get projects” om de volledige lijst weer te geven. Vraagt u zich sceptisch af hoe dit zal werken als u slechts toegang heeft tot een beperkte subset van naamruimten op het cluster? Welnu, omdat kubectl dit alleen correct doet als RBAC je toestaat alle spaties in het cluster te zien, en in grote clusters krijgt niet iedereen dergelijke machtigingen. Wij antwoorden dus: voor de OC is dit helemaal geen probleem en die zal in zo'n situatie gemakkelijk een volledige lijst opleveren. Het zijn deze kleine dingen die de bedrijfsoriëntatie van Openshift en de goede schaalbaarheid van dit platform in termen van gebruikers en applicaties bepalen.
2. ODO - een verbeterde versie van kubectl voor ontwikkelaars
Een ander voorbeeld van de verbeteringen van Red Hat OpenShift ten opzichte van Kubernetes is het ODO-opdrachtregelhulpprogramma. Het is ontworpen voor ontwikkelaars en stelt u in staat snel lokale code te implementeren op een extern OpenShift-cluster. Het kan ook interne processen stroomlijnen om alle codewijzigingen onmiddellijk te synchroniseren met containers op een extern OpenShift-cluster zonder dat u images opnieuw hoeft te bouwen, te registreren en opnieuw te implementeren.
Laten we eens kijken hoe OC en ODO het werken met containers en Kubernetes eenvoudiger maken.
Vergelijk maar eens een paar workflows wanneer deze op basis van kubectl zijn gebouwd, en wanneer OC of ODO wordt gebruikt.
• Implementatie van code op OpenShift voor degenen die geen YAML spreken:
Kubernetes/kubectl
$>git-kloon
1- Maak een Dockerfile die de afbeelding op basis van code opbouwt
-----
VAN knooppunt
WERKDIR /usr/src/app
KOPIEER pakket*.json ./
KOPIEER index.js ./
KOPIËREN ./app ./app
RUN npm-installatie
BELICHT 3000
CMD [ “npm”, “start” ] ————–
2- Wij bouwen het beeld
$>podman bouwen...
3- Log in op het register
Podman inloggen...
4- Plaats de afbeelding in het register
Podman duw
5- Maak yaml-bestanden voor applicatie-implementatie (deployment.yaml, service.yaml, ingress.yaml) - dit is het absolute minimum
6- Implementeer manifestbestanden:
Kubectl past -f toe.
OpenShift/oc
$> oc nieuwe app – onze_applicatie_naam
OpenShift/odo
$>git-kloon
$> odo maak component nodejs myapp
$>doe duwen
• Contextwisseling: werknaamruimte of werkcluster wijzigen.
Kubernetes/kubectl
1- Creëer een context in kubeconfig voor het project “myproject”
2- kubectl set-context…
OpenShift/oc
oc-project “mijnproject”
Kwaliteitscontrole: “Er is hier een interessante functie verschenen, nog steeds in de alfaversie. Misschien kunnen we het in productie nemen?”
Stel je voor dat je in een racewagen zit en te horen krijgt: “We hebben een nieuw type remmen geïnstalleerd en, eerlijk gezegd, de betrouwbaarheid ervan is nog niet in orde... Maar maak je geen zorgen, we zullen ze tijdens de cursus actief verbeteren. van het kampioenschap.” Wat vind je van dit vooruitzicht? Wij bij Red Hat zijn op de een of andere manier niet erg blij. 🙂
Daarom proberen we te wachten met het uitbrengen van alfaversies totdat ze voldoende volwassen zijn en we grondige tests hebben uitgevoerd en het gevoel hebben dat ze veilig zijn om te gebruiken. Meestal gaat alles eerst door de Dev Preview-fase en vervolgens door en komt dan pas uit als een publieke release (GA), dat al zo stabiel is dat het geschikt is voor productie.
Waarom is dat? Omdat, net als bij de ontwikkeling van elke andere software, niet alle initiële ideeën in Kubernetes de definitieve release bereiken. Of ze bereiken het en behouden zelfs de beoogde functionaliteit, maar de implementatie ervan is radicaal anders dan die in de alfaversie. Nu duizenden en duizenden Red Hat-klanten OpenShift gebruiken om bedrijfskritische workloads te ondersteunen, leggen we speciale nadruk op de stabiliteit van ons platform en ondersteuning op lange termijn.
Red Hat streeft ernaar OpenShift regelmatig uit te brengen en de bijbehorende versie van Kubernetes te updaten. De huidige GA-release van OpenShift 4.3 op het moment van schrijven bevat bijvoorbeeld Kubernetes 1.16, wat slechts één is achter de upstream-versie van Kubernetes, genummerd 1.17. Daarom proberen we de klant Kubernetes van ondernemingsklasse te bieden en extra kwaliteitscontrole te bieden wanneer we nieuwe versies van OpenShift uitbrengen.
Softwarefixes: “Er zat een gat in de versie van Kubernetes die we in productie hebben. En je kunt het alleen sluiten door drie versies omhoog te updaten. Of zijn er opties?
In het open source-project van Kubernetes worden softwarefixes meestal uitgebracht als onderdeel van de volgende release, soms voor een of twee eerdere mijlpaalreleases, waardoor de dekking slechts zes maanden teruggaat.
Red Hat is er trots op kritieke oplossingen eerder uit te brengen dan andere en veel langer ondersteuning te bieden. Neem bijvoorbeeld de kwetsbaarheid voor escalatie van bevoegdheden in Kubernetes (): het werd ontdekt in Kubernetes 1.11, en oplossingen voor eerdere releases werden slechts uitgebracht tot en met versie 1.10.11, waardoor deze in alle eerdere Kubernetes-releases, van 1.x tot 1.9, achterbleef.
In beurt (Kubernetes 1.2 is er), met negen OpenShift-releases en een duidelijke demonstratie van zorg voor klanten (meer details ).
Hoe OpenShift en Red Hat Kubernetes vooruit helpen
Red Hat is de op één na grootste softwarebijdrager aan het open source Kubernetes-project, na alleen Google, waarbij drie van de vijf meest productieve ontwikkelaars afkomstig zijn van Red Hat. Nog een weinig bekend feit: veel kritieke functies verschenen in Kubernetes juist op initiatief van Red Hat, zoals:
- RBAC. Kubernetes beschikte niet over RBAC-functies (ClusterRole, ClusterRoleBinding) totdat Red Hat-ingenieurs besloten deze te implementeren als onderdeel van het platform zelf, en niet als aanvullende OpenShift-functionaliteit. Is Red Hat bang om Kubernetes te verbeteren? Natuurlijk niet, want Red Hat volgt strikt de open source-principes en speelt geen Open Core-games. Verbeteringen en innovaties die worden aangestuurd door ontwikkelingsgemeenschappen, in plaats van propriëtaire gemeenschappen, zijn levensvatbaarder en worden op grotere schaal toegepast, wat goed aansluit bij ons kerndoel om open source-software nuttiger te maken voor onze klanten.
- Beveiligingsbeleid voor pods (Pod-beveiligingsbeleid). Dit concept van het veilig uitvoeren van applicaties in pods werd oorspronkelijk geïmplementeerd in OpenShift onder de naam SCC (Security Context Constraints). En net als in het vorige voorbeeld besloot Red Hat deze ontwikkelingen in het open Kubernetes-project te introduceren, zodat iedereen er gebruik van kon maken.
Deze reeks voorbeelden zou kunnen worden voortgezet, maar we wilden alleen laten zien dat Red Hat zich echt inzet om Kubernetes te ontwikkelen en het voor iedereen beter te maken.
Het is duidelijk dat OpenShift Kubernetes is. Wat zijn de verschillen? 🙂
We hopen dat u, door tot nu toe te lezen, beseft dat Kubernetes de kerncomponent van OpenShift is. De belangrijkste, maar verre van de enige. Met andere woorden: het simpelweg installeren van Kubernetes levert u geen platform van ondernemingsklasse op. U moet authenticatie, netwerken, beveiliging, monitoring, logbeheer en meer toevoegen. Bovendien zul je een aantal moeilijke keuzes moeten maken uit het grote aantal beschikbare tools (om de diversiteit van het ecosysteem te waarderen, kijk maar eens ) en zorgen op de een of andere manier voor consistentie en samenhang, zodat ze als één geheel werken. Bovendien zult u regelmatig updates en regressietests moeten uitvoeren wanneer er een nieuwe versie verschijnt van een van de componenten die u gebruikt. Dat wil zeggen dat je naast het creëren en onderhouden van het platform zelf ook met al deze software te maken krijgt. Het is onwaarschijnlijk dat er nog veel tijd over zal zijn om bedrijfsproblemen op te lossen en concurrentievoordelen te behalen.
Maar in het geval van OpenShift neemt Red Hat al deze complexiteiten op zich en biedt het je eenvoudigweg een functioneel compleet platform, dat niet alleen Kubernetes zelf omvat, maar ook de hele set noodzakelijke open source-tools die van Kubernetes een echte ondernemingsklasse maken. oplossing die u direct en geheel rustig in productie kunt nemen. En als u over een aantal van uw eigen technologiestapels beschikt, kunt u OpenShift natuurlijk in bestaande oplossingen integreren.
Kijk eens naar de afbeelding hierboven: alles wat zich buiten de Kubernetes-rechthoek bevindt, is waar Red Hat functionaliteit toevoegt die Kubernetes niet, zoals ze zeggen, by-design heeft. En nu zullen we naar de belangrijkste van deze gebieden kijken.
1. Robuust besturingssysteem als basis: RHEL CoreOS of RHEL
Red Hat is al ruim twintig jaar een toonaangevende leverancier van Linux-distributies voor bedrijfskritische applicaties. Onze opgebouwde en voortdurend bijgewerkte ervaring op dit gebied stelt ons in staat een werkelijk betrouwbare en vertrouwde basis te bieden voor de industriële exploitatie van containers. RHEL CoreOS gebruikt dezelfde kernel als RHEL, maar is primair geoptimaliseerd voor taken zoals het uitvoeren van containers en het uitvoeren van Kubernetes-clusters: de kleinere omvang en onveranderlijkheid maken het eenvoudiger om clusters in te stellen, automatisch te schalen, patches te implementeren, enz. Al deze functies maken het een ideale basis voor het leveren van dezelfde gebruikerservaring met OpenShift in een breed scala aan computeromgevingen, van bare metal tot private en publieke cloud.
2. Automatisering van IT-activiteiten
Automatisering van installatieprocessen en dagelijkse handelingen (dat wil zeggen: dagelijkse werkzaamheden) is het sterke punt van OpenShift, waardoor het veel eenvoudiger wordt om de prestaties van het containerplatform op het hoogste niveau te beheren, bij te werken en te onderhouden. Dit wordt bereikt door ondersteuning voor Kubernetes-operators op OpenShift 4-kernelniveau.
OpenShift 4 is ook een heel ecosysteem van oplossingen gebaseerd op Kubernetes-operators, ontwikkeld door zowel Red Hat zelf als door externe partners (zie. Red Hat, of operatorwinkel , gemaakt door Red Hat voor externe ontwikkelaars).
De geïntegreerde OpenShift 4-catalogus bevat meer dan 180 Kubernetes-operators
3. Ontwikkelaarstools
Sinds 2011 is OpenShift beschikbaar als PaaS-platform (Platform-as-a-Service) dat het leven van ontwikkelaars veel gemakkelijker maakt, hen helpt zich te concentreren op coderen en native ondersteuning biedt voor programmeertalen zoals Java, Node.js , PHP, Ruby, Python, Go, evenals CI/CD continue integratie- en leveringsdiensten, databases, enz. OpenShift 4-aanbiedingen , dat meer dan 100 services omvat op basis van Kubernetes-operators, ontwikkeld door Red Hat en onze partners.
In tegenstelling tot Kubernetes heeft OpenShift 4 een speciale GUI (), waarmee ontwikkelaars moeiteloos applicaties uit verschillende bronnen (git, externe registers, Dockerfile, enz.) in hun naamruimten kunnen implementeren en de relaties tussen applicatiecomponenten duidelijk visualiseert.
Daarnaast biedt OpenShift een reeks Codeready-ontwikkeltools, waaronder met name , een volledig gecontaineriseerde IDE met een webinterface die rechtstreeks bovenop OpenShift draait en een IDE-as-a-service-aanpak implementeert. Aan de andere kant, voor degenen die strikt in de lokale modus willen werken, is er Codeready Containers, een volledig functionele versie van OpenShift 4 die op een laptop kan worden geïmplementeerd.
Geïntegreerde IDE as a service voor efficiënte ontwikkeling op het Kubernetes/OpenShift-platform
OpenShift biedt direct uit de doos een volledig CI/CD-systeem, gebaseerd op gecontaineriseerde Jenkins en een plug-in voor het werken met pipelines, of een Kubernetes-georiënteerd CI/CD-systeem (momenteel in Tech preview-versie). Beide oplossingen zijn volledig te integreren met de OpenShift-console, waardoor u pijplijntriggers kunt uitvoeren, implementaties, logboeken en meer kunt bekijken.
4. Applicatiehulpmiddelen
Met OpenShift kunt u zowel traditionele stateful applicaties als cloudgebaseerde oplossingen implementeren op basis van nieuwe architecturen, zoals microservices of serverless. De OpenShift Service Mesh-oplossing wordt direct uit de doos geleverd met belangrijke tools voor het onderhouden van microservices, zoals Istio, Kiali en Jaeger. De OpenShift Serverless-oplossing omvat op zijn beurt niet alleen Knative, maar ook tools zoals Keda, gemaakt als onderdeel van een gezamenlijk initiatief met Microsoft om Azure-functies op het OpenShift-platform te bieden.
De geïntegreerde oplossing OpenShift ServiceMesh (Istio, Kiali, Jaeger) zal nuttig zijn bij het ontwikkelen van microservices
Om de kloof tussen oudere applicaties en containers te overbruggen, maakt OpenShift nu migratie van virtuele machines naar het OpenShift-platform mogelijk met behulp van Container Native Virtualization (momenteel in TechPreview), waardoor hybride applicaties werkelijkheid worden en de migratie ervan tussen verschillende clouds, zowel privé als openbaar, wordt vergemakkelijkt.
Windows 2019 virtuele virtuele machine draait op OpenShift via Container Native Virtualization (momenteel in Tech preview-versie)
5. Hulpmiddelen voor clusters
Elk platform van ondernemingsklasse moet beschikken over monitoring- en gecentraliseerde logdiensten, beveiligingsmechanismen, authenticatie en autorisatie, en netwerkbeheertools. En OpenShift biedt dit allemaal out-of-the-box, en het is allemaal 100% open source, inclusief oplossingen zoals ElasticSearch, Prometheus, Grafana. Al deze oplossingen worden geleverd met dashboards, statistieken en waarschuwingen die al zijn gebouwd en geconfigureerd met behulp van de uitgebreide expertise van Red Hat op het gebied van clustermonitoring, waardoor u uw productieomgeving vanaf het begin effectief kunt controleren en monitoren.
OpenShift wordt ook standaard geleverd met belangrijke zaken voor zakelijke klanten als authenticatie met een ingebouwde oauth-provider, integratie met credential-providers, waaronder LDAP, ActiveDirectory, OpenID Connect en nog veel meer.
Vooraf geconfigureerd Grafana-dashboard voor OpenShift-clustermonitoring
Meer dan 150 vooraf geconfigureerde Prometheus-statistieken en waarschuwingen voor OpenShift-clustermonitoring
Wordt vervolgd
De rijke functionaliteit van de oplossing en de ruime ervaring van Red Hat op het gebied van Kubernetes zijn de redenen waarom OpenShift een dominante positie in de markt heeft verworven, zoals blijkt uit onderstaande figuur (lees meer ).
“Red Hat leidt momenteel de markt met een aandeel van 44%.
Het bedrijf plukt de vruchten van zijn klantgerichte verkoopstrategie, waarbij het eerst bedrijfsontwikkelaars raadpleegt en traint en vervolgens overgaat op het genereren van inkomsten zodra het bedrijf containers in productie begint te zetten.”
(Источник: )
We hopen dat je dit artikel leuk vond. In toekomstige berichten in deze serie zullen we de voordelen van OpenShift ten opzichte van Kubernetes in elk van de hier besproken categorieën nader bekijken.
Bron: www.habr.com