Den fjärde versionen av OpenShift släpptes relativt nyligen. Den nuvarande versionen 4.3 har varit tillgänglig sedan slutet av januari och alla ändringar i den är antingen något helt nytt som inte fanns i den tredje versionen, eller en större uppdatering av det som dök upp i version 4.1. Allt som vi kommer att berätta nu måste vara känt, förstås och tas i beaktande av de som arbetar med OpenShift och planerar att byta till en ny version.
Med lanseringen av OpenShift 4.2 har Red Hat gjort arbetet med Kubernetes enklare. Nya verktyg och plugins har dykt upp för att skapa behållare, CI/CD-pipelines och serverlösa distributioner. Innovationer ger utvecklare möjlighet att fokusera på att skriva kod, och inte på att hantera Kubernetes.
Egentligen, vad är nytt i versionerna av OpenShift 4.2 och 4.3?
Går mot hybridmoln
När de planerar en ny IT-infrastruktur eller när de utvecklar ett befintligt IT-landskap överväger företag i allt högre grad en molnstrategi för tillhandahållande av IT-resurser, för vilka de implementerar privata molnlösningar eller använder kraften hos offentliga molnleverantörer. Alltså byggs moderna IT-infrastrukturer i allt högre grad enligt en ”hybrid” molnmodell, när både lokala resurser och publika molnresurser med ett gemensamt ledningssystem används. Red Hat OpenShift 4.2 är speciellt designad för att förenkla övergången till en hybridmolnmodell och gör det enkelt att koppla resurser från leverantörer som AWS, Azure och Google Cloud Platform till klustret, tillsammans med att använda privata moln på VMware och OpenStack.
Nytt sätt att installera
I version 4 har metoden för att installera OpenShift ändrats. Red Hat tillhandahåller ett speciellt verktyg för att distribuera ett OpenShift-kluster - openshift-install. Verktyget är en enda binär fil skriven i Go. Openshit-installer förbereder en yaml-fil med den konfiguration som krävs för distribution.
Vid installation med molnresurser måste du ange minimal information om det framtida klustret: DNS-zon, antal arbetarnoder, specifika inställningar för molnleverantören, kontoinformation för åtkomst till molnleverantören. Efter att ha förberett konfigurationsfilen kan klustret distribueras med ett kommando.
I händelse av installation på dina egna datorresurser, till exempel när du använder ett privat moln (vSphere och OpenStack stöds) eller när du installerar på servrar av ren metall, måste du manuellt konfigurera infrastrukturen - förbereda minsta antal virtuella maskiner eller fysiska servrar som krävs för att skapa ett Control Plane-kluster, konfigurera nätverkstjänster. Efter denna konfiguration kan ett OpenShift-kluster skapas på liknande sätt med ett kommando från openshift-installer-verktyget.
Infrastrukturuppdateringar
CoreOS-integration
Den viktigaste uppdateringen är integration med Red Hat CoreOS. Red Hat OpenShift-masternoder kan nu fungera endast på det nya operativsystemet. Detta är ett gratis operativsystem från Red Hat som är designat specifikt för containerlösningar. Red Hat CoreOS är ett lätt Linux optimerat för att köra containrar.
Om i 3.11 operativsystemet och OpenShift existerade separat, så är det i 4.2 oupplösligt kopplat till OpenShift. Nu är detta en enda apparat - oföränderlig infrastruktur.
För kluster som använder RHCOS för alla noder är uppgradering av OpenShift Container Platform en enkel och mycket automatiserad process.
Tidigare, för att uppdatera OpenShift, var du först tvungen att uppdatera det underliggande operativsystemet som produkten kördes på (på den tiden Red Hat Enterprise Linux). Först då kunde OpenShift uppdateras gradvis, nod för nod. Någon automatisering av processen var det inte tal om.
Nu, eftersom OpenShift Container Platform helt kontrollerar systemen och tjänsterna på varje nod, inklusive operativsystemet, löses denna uppgift genom att trycka på en knapp från webbgränssnittet. Efter detta startas en speciell operatör inuti OpenShift-klustret, som styr hela uppdateringsprocessen.
Nytt CSI
För det andra är nya CSI en lagringsgränssnittskontroller som låter dig ansluta olika externa lagringssystem till OpenShift-klustret. Ett stort antal leverantörer av lagringsdrivrutiner för OpenShift stöds baserat på lagringsdrivrutiner som är skrivna av lagringssystemtillverkarna själva. En komplett lista över CSI-drivrutiner som stöds finns i detta dokument: . I den här listan kan du hitta alla huvudmodeller av diskarrayer från ledande tillverkare (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage), SDS-lösningar (Ceph) och molnlagring (AWS, Azure, Google). OpenShift 4.2 stöder CSI-drivrutiner för CSI-specifikationen version 1.1.
RedHat OpenShift Service Mesh
Baserat på Istio-, Kiali- och Jaeger-projekten tillåter Red Hat OpenShift Service Mesh, förutom de vanliga uppgifterna att dirigera förfrågningar mellan tjänster, spårning och visualisering av dem. Detta hjälper utvecklare att enkelt kommunicera, övervaka och hantera en applikation som distribueras inuti Red Hat OpenShift.
Visualisering av en applikation som har en mikrotjänstarkitektur med Kiali
För att förenkla installationen, underhållet och livscykelhanteringen av Service Mesh så mycket som möjligt ger Red Hat OpenShift administratörer en speciell operatör, Service Mesh Operator. Detta är en Kubernetes-operatör som låter dig distribuera omkonfigurerade Istio-, Kiali- och Jaeger-paket i ett kluster, vilket maximerar den administrativa bördan för att hantera applikationer.
CRI-O istället för Docker
Standard container runtime Docker har ersatts av CRI-O. Det var möjligt att använda CRI-O redan i version 3.11, men i 4.2 blev det den huvudsakliga. Varken bra eller dåligt, men något att tänka på när du använder produkten.
Operatörer och applikationsdistribution
Operatörer är en ny enhet för RedHat OpenShift, som dök upp i den fjärde versionen. Det är en metod för att paketera, distribuera och hantera en Kubernetes-applikation. Det kan ses som en plugin för applikationer som distribueras i behållare, driven av Kubernetes API och kubectl-verktyg.
Kubernetes-operatörer hjälper till att automatisera alla uppgifter relaterade till administration och livscykelhantering av applikationen du distribuerar till ditt kluster. Operatören kan till exempel automatisera uppdateringar, säkerhetskopiering och skalning av applikationen, ändra konfigurationen osv. En komplett lista över operatörer finns på .
OperatorHub är tillgänglig direkt från hanteringskonsolens webbgränssnitt. Det är en applikationskatalog för OpenShift som underhålls av Red Hat. De där. alla Red Hat-godkända operatörer kommer att omfattas av leverantörssupport.
OperatorHub-portal i OpenShift-hanteringskonsolen
Universell basbild
Det är en standardiserad uppsättning RHEL OS-bilder som kan användas för att bygga dina containeriserade applikationer. Det finns minimala, standard- och kompletta set. De tar upp väldigt lite utrymme och stöder alla nödvändiga installerade paket och programmeringsspråk.
CI/CD-verktyg
I RedHat OpenShif 4.2 blev det möjligt att välja mellan Jenkins och OpenShift Pipelines baserade på Tekton Pipelines.
OpenShift Pipelines är baserad på Tekton, som stöds bättre av Pipeline när Code och GitOps närmar sig. I OpenShift-pipelines körs varje steg i sin egen behållare, så resurser används bara medan steget körs. Detta ger utvecklare fullständig kontroll över modulleveranspipelines, plugins och åtkomstkontroll utan en central CI/CD-server att hantera.
OpenShift Pipelines är för närvarande i Developer Preview och tillgänglig som operatör på ett OpenShift 4-kluster. Naturligtvis kan OpenShift-användare fortfarande använda Jenkins på RedHat OpenShift 4.
Uppdateringar för utvecklarhantering
I 4.2 OpenShift har webbgränssnittet blivit helt uppdaterat för både utvecklare och administratörer.
I tidigare versioner av OpenShift arbetade alla i tre konsoler: servicekatalog, administratörskonsol och arbetskonsol. Nu är klustret bara uppdelat i två delar - administratörskonsol och utvecklarkonsol.
Utvecklarkonsolen har fått betydande förbättringar av användargränssnittet. Nu visar den mer bekvämt topologierna för applikationer och deras sammansättningar. Detta gör det enklare för utvecklare att skapa, distribuera och visualisera containeriserade applikationer och klustrade resurser. Låter dem fokusera på det som är viktigt för dem.
Utvecklarportal i OpenShift-hanteringskonsolen
Odo
Odo är ett utvecklarorienterat kommandoradsverktyg som förenklar applikationsutveckling i OpenShift. Med hjälp av kommunikation i git push-stil hjälper denna CLI utvecklare som är nya för Kubernetes att bygga applikationer i OpenShift.
Integration med utvecklingsmiljöer
Utvecklare kan nu bygga, felsöka och distribuera sina applikationer i OpenShift utan att lämna sin favoritkodutvecklingsmiljö, såsom Microsoft Visual Studio, JetBrains (inklusive IntelliJ), Eclipse Desktop, etc.
Red Hat OpenShift Deployment-tillägg för Microsoft Azure DevOps
Red Hat OpenShift Deployment-tillägget för Microsoft Azure DevOps har släppts. Användare av denna DevOps-verktygsuppsättning kan nu distribuera sina applikationer till Azure Red Hat OpenShift eller något annat OpenShift-kluster direkt från Microsoft Azure DevOps.
Övergång från den tredje versionen till den fjärde
Eftersom vi pratar om en ny version, och inte en uppdatering, kan du inte bara lägga den fjärde versionen ovanpå den tredje. Uppdatering från version XNUMX till version XNUMX stöds inte..
Men det finns goda nyheter: Red Hat tillhandahåller verktyg för att migrera projekt från 3.7 till 4.2. Du kan migrera applikationsarbetsbelastningar med CAM-verktyget (Cluster Application Migration). CAM låter dig kontrollera migreringen och minimera stilleståndstid för applikationer.
OpenShift 4.3
De viktigaste innovationerna som beskrivs i den här artikeln dök upp i version 4.2. De nyligen släppta 4.3-ändringarna är inte lika stora, men det finns fortfarande några nya saker. Listan över ändringar är ganska omfattande, här är de viktigaste enligt vår mening:
Uppdatera Kubernetes version till 1.16.
Versionen uppgraderades med två steg samtidigt; i OpenShift 4.2 var den 1.14.
Datakryptering i etcd
Från och med version 4.3 blev det möjligt att kryptera data i etcd-databasen. När kryptering har aktiverats kommer det att vara möjligt att kryptera följande OpenShift API och Kubernetes API-resurser: Secrets, ConfigMaps, Routes, access tokens och OAuth-auktorisering.
Helm
Lade till stöd för Helm version 3, en populär pakethanterare för Kubernetes. För närvarande har supporten statusen TECHNOLOGY PREVIEW. Helm-stödet kommer att utökas till fullt stöd i framtida versioner av OpenShift. Verktyget helm cli kommer med OpenShift och kan laddas ner från webbkonsolen för klusterhantering.
Uppdatering av projektinstrumentpanelen
I den nya versionen ger Project Dashboard ytterligare information på projektsidan: projektstatus, resursutnyttjande och projektkvoter.
Visar sårbarheter för kaj i webbkonsolen
En funktion har lagts till i hanteringskonsolen för att visa kända sårbarheter för bilder i Quay repositories. Visning av sårbarheter för lokala och externa arkiv stöds.
Förenklat skapande av offline-operatörshubb
För fallet med att distribuera ett OpenShift-kluster i ett isolerat nätverk, från vilket tillgången till Internet är begränsad eller frånvarande, är det förenklat att skapa en "spegel" för OperatorHub-registret. Nu kan detta göras med bara tre lag.
Författare:
Victor Puchkov, Yuri Semenyukov
Källa: will.com