De vierde versie van OpenShift is relatief recent uitgebracht. De huidige versie 4.3 is sinds eind januari beschikbaar en alle wijzigingen daarin zijn ofwel iets compleet nieuws dat niet in de derde versie zat, ofwel een grote update van wat in versie 4.1 verscheen. Alles wat we u nu gaan vertellen, moet bekend, begrepen en in aanmerking genomen worden door degenen die met OpenShift werken en van plan zijn over te stappen naar een nieuwe versie.
Met de release van OpenShift 4.2 heeft Red Hat het werken met Kubernetes eenvoudiger gemaakt. Er zijn nieuwe tools en plug-ins verschenen voor het maken van containers, CI/CD-pijplijnen en serverloze implementaties. Innovaties geven ontwikkelaars de mogelijkheid om zich te concentreren op het schrijven van code, en niet op het omgaan met Kubernetes.
Wat is er eigenlijk nieuw in de versies van OpenShift 4.2 en 4.3?
Op weg naar hybride clouds
Bij het plannen van een nieuwe IT-infrastructuur of bij het ontwikkelen van een bestaand IT-landschap overwegen bedrijven steeds vaker een cloud-aanpak voor de terbeschikkingstelling van IT-middelen, waarvoor ze private cloud-oplossingen implementeren of de kracht van publieke cloud-aanbieders gebruiken. Moderne IT-infrastructuren worden dus steeds meer gebouwd volgens een ‘hybride’ cloudmodel, waarbij zowel lokale bronnen als publieke cloudbronnen met een gemeenschappelijk beheersysteem worden gebruikt. Red Hat OpenShift 4.2 is speciaal ontworpen om de transitie naar een hybride cloudmodel te vereenvoudigen en maakt het eenvoudig om resources van providers als AWS, Azure en Google Cloud Platform aan het cluster te koppelen, samen met het gebruik van private clouds op VMware en OpenStack.
Nieuwe benadering van installatie
In versie 4 is de aanpak voor het installeren van OpenShift veranderd. Red Hat biedt een speciaal hulpprogramma voor het implementeren van een OpenShift-cluster: openshift-install. Het hulpprogramma is een enkel binair bestand geschreven in Go. Openshit-installer bereidt een yaml-bestand voor met de configuratie die vereist is voor implementatie.
In het geval van een installatie met behulp van cloudbronnen, moet u minimale informatie over het toekomstige cluster opgeven: DNS-zone, aantal werkknooppunten, specifieke instellingen voor de cloudprovider, accountinformatie voor toegang tot de cloudprovider. Na het voorbereiden van het configuratiebestand kan het cluster met één commando worden ingezet.
In het geval van installatie op uw eigen computerbronnen, bijvoorbeeld bij gebruik van een privécloud (vSphere en OpenStack worden ondersteund) of bij installatie op bare metal-servers, moet u de infrastructuur handmatig configureren - bereid het minimumaantal virtuele machines voor of fysieke servers die nodig zijn om een Control Plane-cluster te maken, netwerkservices te configureren. Na deze configuratie kan op dezelfde manier een OpenShift-cluster worden gemaakt met één opdracht van het openshift-installer-hulpprogramma.
Infrastructuurupdates
CoreOS-integratie
De belangrijkste update is integratie met Red Hat CoreOS. Red Hat OpenShift-masternodes kunnen nu werken alleen op het nieuwe besturingssysteem. Dit is een gratis besturingssysteem van Red Hat dat speciaal is ontworpen voor containeroplossingen. Red Hat CoreOS is een lichtgewicht Linux die is geoptimaliseerd voor het draaien van containers.
Bestonden in 3.11 het besturingssysteem en OpenShift afzonderlijk, dan is het in 4.2 onlosmakelijk verbonden met OpenShift. Dit is nu één enkel apparaat: een onveranderlijke infrastructuur.
Voor clusters die RHCOS voor alle knooppunten gebruiken, is het upgraden van OpenShift Container Platform een eenvoudig en sterk geautomatiseerd proces.
Voorheen moest u om OpenShift bij te werken eerst het onderliggende besturingssysteem bijwerken waarop het product draaide (destijds Red Hat Enterprise Linux). Alleen dan kon OpenShift geleidelijk worden bijgewerkt, knooppunt voor knooppunt. Er was geen sprake van enige automatisering van het proces.
Omdat het OpenShift Container Platform de systemen en services op elk knooppunt, inclusief het besturingssysteem, volledig controleert, wordt deze taak opgelost door op een knop vanuit de webinterface te drukken. Hierna wordt een speciale operator gelanceerd binnen het OpenShift-cluster, die het hele updateproces bestuurt.
Nieuwe CSI
Ten tweede is de nieuwe CSI een opslaginterfacecontroller waarmee u verschillende externe opslagsystemen op het OpenShift-cluster kunt aansluiten. Een groot aantal aanbieders van opslagstuurprogramma's voor OpenShift worden ondersteund op basis van opslagstuurprogramma's die door de fabrikanten van opslagsystemen zelf zijn geschreven. Een volledige lijst met ondersteunde CSI-stuurprogramma's vindt u in dit document: . In deze lijst vindt u alle belangrijke modellen disk-arrays van toonaangevende fabrikanten (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage), SDS-oplossingen (Ceph) en cloudopslag (AWS, Azure, Google). OpenShift 4.2 ondersteunt CSI-stuurprogramma's met de CSI-specificatie versie 1.1.
RedHat OpenShift-servicemesh
Gebaseerd op de Istio-, Kiali- en Jaeger-projecten maakt Red Hat OpenShift Service Mesh, naast de gebruikelijke taken van het routeren van verzoeken tussen services, het traceren en visualiseren ervan mogelijk. Dit helpt ontwikkelaars eenvoudig te communiceren, monitoren en beheren van een applicatie die is geïmplementeerd binnen Red Hat OpenShift.
Visualisatie van een applicatie met een microservice-architectuur met behulp van Kiali
Om de installatie, het onderhoud en het lifecycle management van Service Mesh zoveel mogelijk te vereenvoudigen, biedt Red Hat OpenShift beheerders een speciale operator, de Service Mesh Operator. Dit is een Kubernetes-operator waarmee u opnieuw geconfigureerde Istio-, Kiali- en Jaeger-pakketten op een cluster kunt implementeren, waardoor de administratieve lasten van het beheer van applicaties worden gemaximaliseerd.
CRI-O in plaats van Docker
De standaard containerruntime Docker is vervangen door CRI-O. Het was al mogelijk om CRI-O te gebruiken in versie 3.11, maar in 4.2 werd het de belangrijkste. Niet goed of slecht, maar wel iets om in gedachten te houden bij het gebruik van het product.
Operators en applicatie-implementatie
Operators zijn een nieuwe entiteit voor RedHat OpenShift, die in de vierde versie verscheen. Het is een methode voor het verpakken, implementeren en beheren van een Kubernetes-applicatie. Het kan worden gezien als een plug-in voor applicaties die in containers worden ingezet, aangedreven door de Kubernetes API en kubectl-tools.
Kubernetes-operators helpen bij het automatiseren van alle taken die verband houden met het beheer en levenscyclusbeheer van de applicatie die u in uw cluster implementeert. Zo kan de operator bijvoorbeeld updates, back-ups en schaling van de applicatie automatiseren, de configuratie wijzigen, etc. Een volledige lijst met operators is te vinden op .
OperatorHub is rechtstreeks toegankelijk via de webinterface van de beheerconsole. Het is een applicatiemap voor OpenShift die wordt onderhouden door Red Hat. Die. alle door Red Hat goedgekeurde operators worden gedekt door leveranciersondersteuning.
OperatorHub-portal in de OpenShift-beheerconsole
Universele basisafbeelding
Het is een gestandaardiseerde set RHEL OS-installatiekopieën die kunnen worden gebruikt om uw containertoepassingen te bouwen. Er zijn minimale, standaard en volledige sets. Ze nemen heel weinig ruimte in beslag en ondersteunen alle benodigde geïnstalleerde pakketten en programmeertalen.
CI/CD-hulpmiddelen
In RedHat OpenShif 4.2 werd het mogelijk om te kiezen tussen Jenkins en OpenShift Pipelines gebaseerd op Tekton Pipelines.
OpenShift Pipelines is gebaseerd op Tekton, dat beter wordt ondersteund door Pipeline naarmate Code en GitOps dichterbij komen. In OpenShift-pijplijnen wordt elke stap in een eigen container uitgevoerd, zodat bronnen alleen worden gebruikt terwijl de stap wordt uitgevoerd. Dit geeft ontwikkelaars volledige controle over pijplijnen voor modulelevering, plug-ins en toegangscontrole zonder dat ze een centrale CI/CD-server hoeven te beheren.
OpenShift Pipelines bevindt zich momenteel in Developer Preview en is beschikbaar als operator op een OpenShift 4-cluster. Uiteraard kunnen OpenShift-gebruikers Jenkins nog steeds gebruiken op RedHat OpenShift 4.
Updates voor ontwikkelaarsbeheer
In 4.2 OpenShift is de webinterface volledig bijgewerkt voor zowel ontwikkelaars als beheerders.
In eerdere versies van OpenShift werkte iedereen in drie consoles: servicedirectory, beheerdersconsole en werkconsole. Nu is het cluster in slechts twee delen verdeeld: de beheerdersconsole en de ontwikkelaarsconsole.
De ontwikkelaarsconsole heeft aanzienlijke verbeteringen in de gebruikersinterface ondergaan. Nu worden de topologieën van applicaties en hun samenstellingen gemakkelijker weergegeven. Dit maakt het voor ontwikkelaars eenvoudiger om gecontaineriseerde applicaties en geclusterde bronnen te creëren, implementeren en visualiseren. Het zorgt ervoor dat ze zich kunnen concentreren op wat voor hen belangrijk is.
Ontwikkelaarsportal in de OpenShift-beheerconsole
odo
Odo is een op ontwikkelaars gericht opdrachtregelhulpprogramma dat de ontwikkeling van applicaties in OpenShift vereenvoudigt. Met behulp van git push-stijl communicatie helpt deze CLI ontwikkelaars die nieuw zijn bij Kubernetes bij het bouwen van applicaties in OpenShift.
Integratie met ontwikkelomgevingen
Ontwikkelaars kunnen nu hun applicaties in OpenShift bouwen, 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 voor Microsoft Azure DevOps is uitgebracht. Gebruikers van deze DevOps-toolset kunnen hun applicaties nu rechtstreeks vanuit Microsoft Azure DevOps implementeren in Azure Red Hat OpenShift of een ander OpenShift-cluster.
Overgang van de derde versie naar de vierde
Omdat we het over een nieuwe release hebben, en niet over een update, kun je niet zomaar de vierde versie bovenop de derde plaatsen. Updaten van versie XNUMX naar versie XNUMX wordt niet ondersteund..
Maar er is goed nieuws: Red Hat biedt tools voor het migreren van projecten van 3.7 naar 4.2. U kunt applicatieworkloads migreren met behulp van de Cluster Application Migration (CAM)-tool. Met CAM kunt u de migratie controleren en de downtime van applicaties minimaliseren.
open ploeg 4.3
De belangrijkste innovaties die in dit artikel worden beschreven, zijn verschenen in versie 4.2. De onlangs uitgebrachte wijzigingen in 4.3 zijn niet zo groot, maar er zijn nog steeds enkele nieuwe dingen. De lijst met wijzigingen is behoorlijk uitgebreid, hier zijn naar onze mening de belangrijkste:
Update de Kubernetes-versie naar 1.16.
De versie werd in twee stappen tegelijk geüpgraded; in OpenShift 4.2 was dit 1.14.
Gegevensversleuteling in etcd
Vanaf versie 4.3 werd het mogelijk om gegevens in de etcd-database te versleutelen. Zodra versleuteling is ingeschakeld, is het mogelijk om de volgende OpenShift API- en Kubernetes API-bronnen te versleutelen: geheimen, ConfigMaps, routes, toegangstokens en OAuth-autorisatie.
Stuurstand
Ondersteuning toegevoegd voor Helm versie 3, een populaire pakketbeheerder voor Kubernetes. Ondersteuning heeft voorlopig de status TECHNOLOGY PREVIEW. Helm-ondersteuning zal worden uitgebreid tot volledige ondersteuning in toekomstige versies van OpenShift. Het hulpprogramma helm cli wordt geleverd met OpenShift en kan worden gedownload via de webconsole voor clusterbeheer.
Projectdashboard-update
In de nieuwe versie biedt Project Dashboard aanvullende informatie op de projectpagina: projectstatus, resourcegebruik en projectquota.
Kwetsbaarheden voor kade weergeven in de webconsole
Er is een functie aan de beheerconsole toegevoegd om bekende kwetsbaarheden voor afbeeldingen in Quay-repository's weer te geven. Het weergeven van kwetsbaarheden voor lokale en externe repositories wordt ondersteund.
Vereenvoudigde creatie van een offline operatorhub
In het geval dat een OpenShift-cluster in een geïsoleerd netwerk wordt ingezet, waarvan de toegang tot internet beperkt of afwezig is, wordt het creëren van een “spiegel” voor het OperatorHub-register vereenvoudigd. Nu kan dit met slechts drie teams.
Auteurs:
Victor Puchkov, Joeri Semenjoekov
Bron: www.habr.com