De vierde versie van OpenShift is relatief recent uitgebracht. De actuele versie is 4.3, die sinds eind januari beschikbaar is, en alle wijzigingen hierin zijn ofwel iets volkomen nieuws dat niet in de derde versie aanwezig was, ofwel een grote update van wat in versie 4.1 is verschenen. Alles wat we nu zullen bespreken is belangrijk om te weten, te begrijpen en in overweging te nemen voor diegenen die met OpenShift werken en van plan zijn om over te stappen op de nieuwe versie.
Met de uitgave van OpenShift 4.2 heeft Red Hat het werken met Kubernetes vereenvoudigd. Er zijn nieuwe tools en plugins toegevoegd voor het creëren van containers, CI/CD-pijplijnen en serverless-implementaties. Deze vernieuwingen geven ontwikkelaars de mogelijkheid om zich te concentreren op coderen, in plaats van zich bezig te houden met Kubernetes.
Wat is er eigenlijk nieuw in de versies OpenShift 4.2 en 4.3?
De beweging richting hybride clouds
Bij het plannen van een nieuwe IT-infrastructuur of het ontwikkelen van het bestaande IT-landschap overwegen bedrijven steeds vaker een cloudbenadering voor de levering van IT-bronnen, waarvoor ze private cloudoplossingen implementeren of gebruik maken van de mogelijkheden van publieke cloudproviders. Moderne IT-infrastructuren worden steeds vaker opgebouwd volgens een 'hybride' cloudmodel, waarbij zowel on-premises bronnen als publieke cloudbronnen met een gemeenschappelijk beheersysteem worden toegepast. Red Hat OpenShift 4.2 is speciaal ontwikkeld om de overstap naar het hybride cloudmodel te vereenvoudigen en stelt bedrijven in staat om eenvoudig bronnen van providers zoals AWS, Azure en Google Cloud Platform aan hun cluster toe te voegen, naast het gebruik van private clouds op VMware en OpenStack.
Een nieuwe benadering van installatie
In versie 4 is de benadering van de installatie van OpenShift veranderd. Red Hat biedt een speciale tool voor het implementeren van een OpenShift-cluster - openshift-install. Deze tool is een enkele binaire uitvoerbare bestand, geschreven in Go. De openshift-installer bereidt een yaml-bestand voor met de configuratie die nodig is voor de implementatie.
Bij de installatie met behulp van cloudbronnen moet de minimale informatie over het toekomstige cluster worden opgegeven: DNS-zone, aantal worker-nodes, specifieke instellingen voor de cloudprovider en inloggegevens voor toegang tot de cloudprovider. Na het voorbereiden van het configuratiebestand kan het cluster met één opdracht worden geïmplementeerd.
Bij installatie op eigen computermiddelen, bijvoorbeeld bij het gebruik van een privécloud (ondersteunt vSphere en OpenStack) of bij installatie op bare metal-servers, is handmatige configuratie van de infrastructuur vereist – bereid het minimale aantal virtuele machines of fysieke servers voor dat nodig is om een Control Plane-cluster te creëren, configureer netdiensten. Na deze configuratie kan het OpenShift-cluster op dezelfde manier worden aangemaakt met een enkele opdracht van het openshift-installer-hulpprogramma.
Updates in de infrastructuur
Integratie met CoreOS
Een belangrijk update is de integratie met Red Hat CoreOS. Nu kunnen de master-nodes van Red Hat OpenShift draaien van op het nieuwe besturingssysteem. Dit is een gratis besturingssysteem van Red Hat, speciaal ontworpen voor containeroplossingen. Red Hat CoreOS is een lichtgewicht Linux, geoptimaliseerd voor het draaien van containers.
Waar in 3.11 het besturingssysteem en OpenShift afzonderlijk bestonden, zijn ze in 4.2 onlosmakelijk met elkaar verbonden. Nu is het één appliance – immutable infrastructure.
Voor clusters die RHCOS voor alle nodes gebruiken, is de update van OpenShift Container Platform een eenvoudig en goed geautomatiseerd proces.
Vroeger, om OpenShift te updaten, moest je eerst het onderliggende besturingssysteem, waarop het product draaide (destijds was dat Red Hat Enterprise Linux), bijwerken. Pas daarna kon je OpenShift geleidelijk bijwerken, node voor node. Van automatisering van het proces was geen sprake.
Tegenwoordig, aangezien het OpenShift Container Platform volledig de systemen en diensten op elke node, inclusief het besturingssysteem, beheert, wordt deze taak met één druk op de knop vanuit de webinterface opgelost. Vervolgens wordt er een speciale operator binnen het OpenShift-cluster gestart, die het hele updateproces beheert.
Nieuwe CSI
Ten tweede – nieuwe CSI – een controller voor de storage-interface, die het mogelijk maakt om verschillende externe opslagoplossingen aan het OpenShift-cluster te koppelen. Er is ondersteuning voor een groot aantal opslagprovider-drivers voor OpenShift, gebaseerd op drivers die door de leveranciers van opslagoplossingen zijn geschreven. De volledige lijst met ondersteunde CSI-drivers is te vinden in dit document: . In deze lijst vindt u alle belangrijke modellen van schijfarrays van toonaangevende fabrikanten (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage), SDS-oplossingen (Ceph) en cloudopslag (AWS, Azure, Google). OpenShift 4.2 ondersteunt de werking met CSI-drivers van specificatie CSI versie 1.1.
RedHat OpenShift Service Mesh
Gebaseerd op de projecten Istio, Kiali en Jaeger - Red Hat OpenShift Service Mesh, naast de gebruikelijke taken van het routeren van verzoeken tussen services, maakt het ook mogelijk om deze te traceren en visualiseren. Dit helpt ontwikkelaars om de interactie, observatie en het beheer van de applicatie, die is uitgerold binnen Red Hat OpenShift, te vereenvoudigen.
Visualisatie van een applicatie met een microservicesarchitectuur met behulp van Kiali
Om de installatiewerkzaamheden, service en lifecycle management van Service Mesh zo eenvoudig mogelijk te maken, biedt Red Hat OpenShift beheerders een speciale operator - Service Mesh Operator. Dit is een Kubernetes-operator die het mogelijk maakt om herconfigureerbare pakketten van Istio, Kiali en Jaeger in de cluster uit te rollen, waarmee de administratieve last van het beheer van applicaties tot een minimum wordt beperkt.
CRI-O in plaats van Docker
De standaard container-runtime Docker is vervangen door CRI-O. Het was al mogelijk om CRI-O te gebruiken in versie 3.11, maar in 4.2 is het de standaard geworden. Noch goed, noch slecht, maar het is iets om rekening mee te houden bij het gebruik van het product.
Operators en de uitrol van applicaties
Operators zijn een nieuwe entiteit voor RedHat OpenShift, die in de vierde versie is geïntroduceerd. Het is een methode voor het verpakken, uitrollen en beheren van Kubernetes-applicaties. Het kan worden voorgesteld als een plug-in voor applicaties die zijn uitgerold in containers, beheerd met behulp van de Kubernetes API en kubectl-tools.
Kubernetes-operators helpen het automatiseren van alle taken die verband houden met het beheer en de lifecycle van de applicatie die u in uw cluster uitrolt. Bijvoorbeeld, een operator kan updates, back-ups en schaling van de applicatie automatiseren, de configuratie wijzigen, enz. De volledige lijst van operators kan worden bekeken op .
OperatorHub is direct toegankelijk vanuit de webinterface van de beheerconsole. Het is een catalogus van applicaties voor OpenShift, ondersteund door Red Hat. Dat wil zeggen, alle operators goedgekeurd door Red Hat, zullen worden gedekt door vendorondersteuning.
OperatorHub-portaal in de beheerconsole van OpenShift
Universele basisafbeelding
Dit is een gestandaardiseerde set OS RHEL-images die u kunt gebruiken om uw applicaties in containers te creëren. Er zijn minimalistische, standaard en volledige sets. Ze nemen heel weinig ruimte in beslag, ondersteunen alle benodigde vooraf geïnstalleerde pakketten en programmeertalen.
CI/CD-tools
In RedHat OpenShift 4.2 is de mogelijkheid geïntroduceerd om te kiezen tussen Jenkins en OpenShift Pipelines op basis van Tekton Pipelines.
OpenShift Pipelines is gebaseerd op Tekton, dat beter de benaderingen Pipeline as Code en GitOps ondersteunt. In de OpenShift-conveyors wordt elke stap uitgevoerd in zijn eigen container, waardoor middelen alleen tijdens de uitvoering van de stap worden gebruikt. Dit geeft ontwikkelaars volledige controle over de levering van modules, plugins en toegangsbeheer zonder een centrale CI/CD-server voor beheer.
OpenShift Pipelines is momenteel in de Preview-fase voor ontwikkelaars en beschikbaar als operator op het OpenShift 4-cluster. Natuurlijk kunnen OpenShift-gebruikers nog steeds Jenkins gebruiken in RedHat OpenShift 4.
Updates in het beheer voor ontwikkelaars
In 4.2 heeft OpenShift de webinterface volledig vernieuwd, zowel voor ontwikkelaars als voor beheerders.
In eerdere versies van OpenShift werkten gebruikers met drie consoles: servicecatalogus, beheerconsole en werkconsole. Nu is de cluster verdeeld in slechts twee delen — beheerconsole en ontwikkelaarsconsole.
De ontwikkelaarsconsole heeft aanzienlijke verbeteringen in de gebruikersinterface gekregen. Nu zijn applicietopologieën en hun builds gemakkelijker weer te geven. Dit vergemakkelijkt het voor ontwikkelaars om containerapplicaties en clusterresources te creëren, implementeren en visualiseren. Hiermee kunnen ze zich concentreren op wat voor hen belangrijk is.
Ontwikkelaarsportaal in de OpenShift-beheerconsole
Odo
Odo is een ontwikkelaarsgerichte commandoregeltool die de ontwikkeling van applicaties in OpenShift vereenvoudigt. Met de git push-stijl interactie helpt deze CLI ontwikkelaars, die niet bekend zijn met Kubernetes, bij het creëren van applicaties in OpenShift.
Integratie met ontwikkelomgevingen
Ontwikkelaars kunnen nu hun applicaties in OpenShift creëren, debuggen en implementeren zonder hun favoriete code-ontwikkelomgeving te verlaten, zoals Microsoft Visual Studio, JetBrains (inclusief IntelliJ), Eclipse Desktop, enz.
Red Hat OpenShift Deployment-extensie voor Microsoft Azure DevOps
De Red Hat OpenShift Deployment-extensie is beschikbaar voor Microsoft Azure DevOps. Gebruikers van deze DevOps-tools kunnen nu hun applicaties eenvoudig vanuit Microsoft Azure DevOps implementeren in Azure Red Hat OpenShift of andere OpenShift-clusters.
Overstap van versie drie naar vier
Aangezien dit een nieuwe release betreft en geen update is, is het niet mogelijk om versie vier zomaar over versie drie te installeren. De update van versie drie naar vier zal niet worden ondersteund..
Er is echter ook goed nieuws: Red Hat biedt tools voor het migreren van projecten van 3.7 naar 4.2. U kunt applicatielasten migreren met behulp van de Cluster Application Migration (CAM) tool. CAM stelt u in staat om de migratie te controleren en de uitvaltijd van de applicatie te minimaliseren.
OpenShift 4.3
De belangrijkste nieuwigheden die in dit artikel worden beschreven, zijn geïntroduceerd in versie 4.2. In de onlangs uitgebracht versie 4.3 zijn de wijzigingen niet zo ingrijpend, maar er is wel iets nieuws. De lijst met wijzigingen is vrij uitgebreid, hier zijn de meest significante naar ons idee:
Updates van de Kubernetes-versie naar 1.16.
De versie is met twee stappen geüpgraded; in OpenShift 4.2 was dit 1.14.
Versleuteling van gegevens in etcd
Vanaf versie 4.3 is het mogelijk om gegevens in de etcd-database te versleutelen. Na inschakeling van de versleuteling kunnen de volgende OpenShift API- en Kubernetes API-resources versleuteld worden: Secrets, ConfigMaps, Routes, toegangstokens en OAuth-autorisatie.
Helm
Ondersteuning voor Helm versie 3 toegevoegd - een populaire package manager voor Kubernetes. De ondersteuning heeft momenteel de status TECHNOLOGY PREVIEW. In toekomstige versies van OpenShift zal de ondersteuning voor Helm worden uitgebreide tot volledige integratie. De helm cli-tool wordt meegeleverd met OpenShift en kan worden gedownload vanuit de webconsole van het clusterbeheer.
Update van Project Dashboard
In de nieuwe versie biedt het Project Dashboard extra informatie op de projectpagina: projectstatus, resourcegebruik en quota voor het project.
Weergave van kwetsbaarheden voor quay in de webconsole
De beheconsole is uitgerust met een functie om bekende kwetsbaarheden in afbeeldingen in Quay-repositories weer te geven. Er is ondersteuning voor kwetsbaarheidsoverzicht voor lokale en externe repositories.
Vereenvoudigde creatie van de offline operatorhub
Voor de implementatie van een OpenShift-cluster in een geïsoleerd netwerk, waarvan de toegang tot het internet beperkt of afwezig is, is het eenvoudiger geworden om een "spiegel" voor de OperatorHub-register te creëren. Dit kan nu met slechts drie commando's.
Authors:
Victor Puchkov, Yuri Semenyukov
Bron: habr.com
