Den fjerde version af OpenShift blev udgivet relativt for nylig. Den nuværende version 4.3 har været tilgængelig siden slutningen af januar, og alle ændringerne i den er enten noget helt nyt, som ikke var i den tredje version, eller en større opdatering af det, der dukkede op i version 4.1. Alt, hvad vi vil fortælle dig nu, skal kendes, forstås og tages i betragtning af dem, der arbejder med OpenShift og planlægger at skifte til en ny version.
Med udgivelsen af OpenShift 4.2 har Red Hat gjort arbejdet med Kubernetes lettere. Nye værktøjer og plugins er dukket op til at skabe containere, CI/CD-pipelines og serverløse implementeringer. Innovationer giver udviklere mulighed for at fokusere på at skrive kode og ikke på at håndtere Kubernetes.
Faktisk, hvad er nyt i versioner af OpenShift 4.2 og 4.3?
Bevæger sig mod hybridskyer
Når de planlægger en ny it-infrastruktur eller når de udvikler et eksisterende it-landskab, overvejer virksomheder i stigende grad en cloud-tilgang til at levere it-ressourcer, hvortil de implementerer private cloud-løsninger eller bruger magten fra offentlige cloud-udbydere. Moderne it-infrastrukturer bygges således i stigende grad efter en "hybrid" cloud-model, når både lokale ressourcer og offentlige cloud-ressourcer med fælles ledelsessystem anvendes. Red Hat OpenShift 4.2 er specielt designet til at forenkle overgangen til en hybrid cloud-model og gør det nemt at forbinde ressourcer fra udbydere som AWS, Azure og Google Cloud Platform til klyngen, sammen med brug af private skyer på VMware og OpenStack.
Ny tilgang til installation
I version 4 er tilgangen til installation af OpenShift ændret. Red Hat giver et særligt værktøj til at implementere en OpenShift-klynge - openshift-install. Værktøjet er en enkelt binær fil skrevet i Go. Openshit-installer forbereder en yaml-fil med den konfiguration, der kræves til implementering.
I tilfælde af installation ved hjælp af cloud-ressourcer, skal du angive minimal information om den fremtidige klynge: DNS-zone, antal arbejderknuder, specifikke indstillinger for cloud-udbyderen, kontooplysninger for adgang til cloud-udbyderen. Efter at have forberedt konfigurationsfilen, kan klyngen implementeres med én kommando.
I tilfælde af installation på dine egne computerressourcer, for eksempel når du bruger en privat sky (vSphere og OpenStack understøttes) eller når du installerer på bare metal-servere, skal du manuelt konfigurere infrastrukturen - forberede det mindste antal virtuelle maskiner eller fysiske servere, der kræves for at oprette en Control Plane-klynge, konfigurere netværkstjenester. Efter denne konfiguration kan en OpenShift-klynge på samme måde oprettes med en kommando fra openshift-installer-værktøjet.
Infrastrukturopdateringer
CoreOS integration
Den vigtigste opdatering er integration med Red Hat CoreOS. Red Hat OpenShift-masternoder kan nu fungere kun på det nye OS. Dette er et gratis operativsystem fra Red Hat, der er designet specielt til containerløsninger. Red Hat CoreOS er en letvægts Linux optimeret til at køre containere.
Hvis operativsystemet og OpenShift i 3.11 eksisterede separat, så er det i 4.2 uløseligt forbundet med OpenShift. Nu er dette et enkelt apparat - uforanderlig infrastruktur.
For klynger, der bruger RHCOS til alle noder, er opgradering af OpenShift Container Platform en enkel og meget automatiseret proces.
Tidligere, for at opdatere OpenShift, skulle du først opdatere det underliggende operativsystem, som produktet kørte på (på det tidspunkt Red Hat Enterprise Linux). Først derefter kunne OpenShift opdateres gradvist, node for node. Der var ikke tale om nogen automatisering af processen.
Nu, da OpenShift Container Platformen fuldt ud styrer systemerne og tjenesterne på hver node, inklusive OS, løses denne opgave ved at trykke på en knap fra webgrænsefladen. Herefter lanceres en speciel operatør inde i OpenShift-klyngen, som styrer hele opdateringsprocessen.
Nyt CSI
For det andet er den nye CSI en lagerinterface-controller, der giver dig mulighed for at forbinde forskellige eksterne lagersystemer til OpenShift-klyngen. Et stort antal lagerdriverudbydere til OpenShift understøttes baseret på lagerdrivere, der er skrevet af lagersystemproducenterne selv. En komplet liste over understøttede CSI-drivere kan findes i dette dokument: . På denne liste kan du finde alle de vigtigste modeller af disk-arrays fra førende producenter (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage), SDS-løsninger (Ceph) og cloud storage (AWS, Azure, Google). OpenShift 4.2 understøtter CSI-drivere af CSI-specifikationen version 1.1.
RedHat OpenShift Service Mesh
Baseret på Istio-, Kiali- og Jaeger-projekterne tillader Red Hat OpenShift Service Mesh, ud over de sædvanlige opgaver med at dirigere anmodninger mellem tjenester, deres sporing og visualisering. Dette hjælper udviklere med nemt at kommunikere, overvåge og administrere en applikation, der er implementeret i Red Hat OpenShift.
Visualisering af en applikation med en mikroservicearkitektur ved hjælp af Kiali
For at forenkle installationen, vedligeholdelsen og livscyklusstyringen af Service Mesh så meget som muligt, giver Red Hat OpenShift administratorer en speciel operatør, Service Mesh Operator. Dette er en Kubernetes-operatør, der giver dig mulighed for at implementere omkonfigurerede Istio-, Kiali- og Jaeger-pakker på en klynge, hvilket maksimerer den administrative byrde ved at administrere applikationer.
CRI-O i stedet for Docker
Standard container runtime Docker er blevet erstattet af CRI-O. Det var muligt at bruge CRI-O allerede i version 3.11, men i 4.2 blev det den vigtigste. Ikke godt eller dårligt, men noget at huske på, når du bruger produktet.
Operatører og applikationsimplementering
Operatører er en ny enhed for RedHat OpenShift, som dukkede op i den fjerde version. Det er en metode til at pakke, implementere og administrere en Kubernetes-applikation. Det kan opfattes som et plugin til applikationer implementeret i containere, drevet af Kubernetes API og kubectl værktøjer.
Kubernetes-operatører hjælper med at automatisere alle opgaver relateret til administration og livscyklusstyring af den applikation, du implementerer til din klynge. Operatøren kan for eksempel automatisere opdateringer, sikkerhedskopier og skalering af applikationen, ændre konfigurationen mv. En komplet liste over operatører kan findes på .
OperatorHub er tilgængelig direkte fra webgrænsefladen på administrationskonsollen. Det er en applikationsmappe til OpenShift, der vedligeholdes af Red Hat. De der. alle Red Hat godkendte operatører vil være dækket af leverandørsupport.
OperatorHub-portal i OpenShift-administrationskonsollen
Universelt basisbillede
Det er et standardiseret sæt af RHEL OS-billeder, der kan bruges til at bygge dine containeriserede applikationer. Der er minimale, standard og komplette sæt. De fylder meget lidt og understøtter alle de nødvendige installerede pakker og programmeringssprog.
CI/CD værktøjer
I RedHat OpenShif 4.2 blev det muligt at vælge mellem Jenkins og OpenShift Pipelines baseret på Tekton Pipelines.
OpenShift Pipelines er baseret på Tekton, som er bedre understøttet af Pipeline, efterhånden som Code og GitOps nærmer sig. I OpenShift-pipelines kører hvert trin i sin egen container, så ressourcer bruges kun, mens trinnet udføres. Dette giver udviklere fuld kontrol over modulleveringspipelines, plugins og adgangskontrol uden en central CI/CD-server at administrere.
OpenShift Pipelines er i øjeblikket i Developer Preview og tilgængelig som operatør på en OpenShift 4-klynge. Selvfølgelig kan OpenShift-brugere stadig bruge Jenkins på RedHat OpenShift 4.
Udviklerstyringsopdateringer
I 4.2 OpenShift er webgrænsefladen blevet fuldstændig opdateret for både udviklere og administratorer.
I tidligere versioner af OpenShift arbejdede alle i tre konsoller: servicebibliotek, administratorkonsol og arbejdskonsol. Nu er klyngen kun opdelt i to dele - administratorkonsol og udviklerkonsol.
Udviklerkonsollen har fået betydelige forbedringer af brugergrænsefladen. Nu viser den mere bekvemt topologierne for applikationer og deres samlinger. Dette gør det nemmere for udviklere at oprette, implementere og visualisere containeriserede applikationer og grupperede ressourcer. Giver dem mulighed for at fokusere på det, der er vigtigt for dem.
Udviklerportal i OpenShift-administrationskonsollen
Odo
Odo er et udviklerorienteret kommandolinjeværktøj, der forenkler applikationsudvikling i OpenShift. Ved at bruge git push-stil kommunikation hjælper denne CLI udviklere, der er nye til Kubernetes, med at bygge applikationer i OpenShift.
Integration med udviklingsmiljøer
Udviklere kan nu bygge, debugge og implementere deres applikationer i OpenShift uden at forlade deres foretrukne kodeudviklingsmiljø, såsom Microsoft Visual Studio, JetBrains (inklusive IntelliJ), Eclipse Desktop osv.
Red Hat OpenShift Deployment-udvidelse til Microsoft Azure DevOps
Red Hat OpenShift Deployment-udvidelsen til Microsoft Azure DevOps er blevet frigivet. Brugere af dette DevOps-værktøjssæt kan nu implementere deres applikationer til Azure Red Hat OpenShift eller enhver anden OpenShift-klynge direkte fra Microsoft Azure DevOps.
Overgang fra den tredje version til den fjerde
Da vi taler om en ny udgivelse og ikke en opdatering, kan du ikke bare lægge den fjerde version oven på den tredje. Opdatering fra version XNUMX til version XNUMX vil ikke blive understøttet..
Men der er gode nyheder: Red Hat leverer værktøjer til at migrere projekter fra 3.7 til 4.2. Du kan migrere applikationsarbejdsbelastninger ved hjælp af CAM-værktøjet (Cluster Application Migration). CAM giver dig mulighed for at kontrollere migration og minimere nedetid for applikationer.
OpenShift 4.3
De vigtigste nyskabelser beskrevet i denne artikel dukkede op i version 4.2. De nyligt udgivne 4.3 ændringer er ikke så store, men der er stadig nogle nye ting. Listen over ændringer er ret omfattende, her er de vigtigste efter vores mening:
Opdater Kubernetes-versionen til 1.16.
Versionen blev opgraderet med to trin på én gang; i OpenShift 4.2 var det 1.14.
Datakryptering i etcd
Fra version 4.3 blev det muligt at kryptere data i etcd-databasen. Når kryptering er aktiveret, vil det være muligt at kryptere følgende OpenShift API- og Kubernetes API-ressourcer: Secrets, ConfigMaps, Routes, access tokens og OAuth-autorisation.
Helm
Tilføjet support til Helm version 3, en populær pakkehåndtering til Kubernetes. Indtil videre har support status TECHNOLOGY PREVIEW. Helm-support vil blive udvidet til fuld support i fremtidige versioner af OpenShift. Hjelm cli-værktøjet leveres med OpenShift og kan downloades fra webkonsollen til klyngestyring.
Opdatering af projektdashboard
I den nye version giver Project Dashboard yderligere oplysninger på projektsiden: projektstatus, ressourceudnyttelse og projektkvoter.
Viser sårbarheder for kaj i webkonsollen
En funktion er blevet tilføjet til administrationskonsollen for at vise kendte sårbarheder for billeder i Quay-lagre. Visning af sårbarheder for lokale og eksterne depoter understøttes.
Forenklet oprettelse af offline operatørhub
I tilfælde af implementering af en OpenShift-klynge i et isoleret netværk, hvorfra adgangen til internettet er begrænset eller fraværende, er oprettelse af et "spejl" for OperatorHub-registret forenklet. Nu kan dette gøres med kun tre hold.
Forfattere:
Victor Puchkov, Yuri Semenyukov
Kilde: www.habr.com