Den fjerde version af OpenShift er blevet udgivet for nylig. Den aktuelle version 4.3 har været tilgængelig siden slutningen af januar, og alle ændringer i den er enten helt nye funktioner, som ikke fandtes i den tredje version, eller store opdateringer af det, der blev introduceret i version 4.1. Alt, hvad vi nu vil fortælle, er vigtigt at vide, forstå og tage højde for for dem, der arbejder med OpenShift og planlægger at skifte til den nye version.
Med udgivelsen af OpenShift 4.2 har Red Hat gjort arbejdet med Kubernetes lettere. Der er kommet nye værktøjer og plugins til oprettelse af containere, CI/CD-pipelines og serverless-implementationer. Nyhederne giver udviklere mulighed for at fokusere på at skrive kode i stedet for at bekymre sig om Kubernetes.
Hvad er der egentlig nyt i versionerne OpenShift 4.2 og 4.3?
Bevægelse mod hybride skyer
Når der planlægges en ny IT-infrastruktur eller udvikles en eksisterende IT-landskab, overvejer virksomheder i stigende grad en skytilgang til levering af IT-ressourcer, hvilket indebærer at implementere private cloud-løsninger eller benytte ressourcer fra offentlige cloud-udbydere. Derved bliver moderne IT-infrastrukturer i stigende grad bygget efter en "hybrid" cloud-model, hvor både on-premises ressourcer og offentlige cloud-ressourcer anvendes sammen med et fælles administrationssystem. Red Hat OpenShift 4.2 er specielt designet til at lette overgangen til en hybrid cloud-model og gør det nemt at tilslutte ressourcer fra udbydere som AWS, Azure og Google Cloud Platform ved siden af brugen af private sky-løsninger på VMware og OpenStack.
Ny tilgang til installation
I den fjerde version er tilgangen til installationen af OpenShift ændret. Red Hat leverer et særligt værktøj til implementering af OpenShift-klynger – openshift-install. Værktøjet består af en enkelt binær fil skrevet i Go. Openshift-installer forbereder en yaml-fil med den nødvendige konfiguration til implementeringen.
Ved installation ved brug af cloud-ressourcer kræves det at angive minimumsinformation om den fremtidige klynge: DNS-zone, antal worker-noder, specifikke indstillinger til cloud-udbyderen og kontooplysninger for adgang til cloud-udbyderen. Efter forberedelse af konfigurationsfilen kan klyngen implementeres med en enkelt kommando.
Ved installation på egne beregningsressourcer, for eksempel ved brug af et privat cloud (vSphere og OpenStack understøttes) eller ved installation på bare metal-servere, vil manuel konfiguration af infrastrukturen være nødvendig – forbered det minimale antal virtuelle maskiner eller fysiske servere, der kræves for at oprette Control Plane-klyngen, og konfigurere netværkstjenesterne. Efter denne konfiguration kan OpenShift-klyngen oprettes på samme måde med en enkelt kommando fra værktøjet openshift-installer.
Opdateringer i infrastrukturen
Integration med CoreOS
Nøgleopdateringen er integrationen med Red Hat CoreOS. Nu kan master-noderne i Red Hat OpenShift køre kun på det nye operativsystem. Det er et gratis operativsystem fra Red Hat, der er specielt designet til containerløsninger. Red Hat CoreOS er et letvægts Linux, der er optimeret til at køre containere.
Hvis operativsystemet og OpenShift i version 3.11 eksisterede separat, så er de i 4.2 uadskilleligt forbundet med OpenShift. Nu er det en enkelt appliance – immutable infrastructure.
For klynger, der bruger RHCOS til alle noder, er opdateringen af OpenShift Container Platform en enkel og velautomatiseret proces.
Tidligere var det nødvendigt først at opdatere det grundlæggende operativsystem, som produktet blev kørt på (dengang var det Red Hat Enterprise Linux), før OpenShift kunne opdateres gradvist, node for node. Der var ikke tale om automatisering af processen.
Nu, da OpenShift Container Platform fuldt ud kontrollerer systemer og tjenester på hver node, inklusive OS, løses denne opgave med et enkelt klik via webgrænsefladen. Herefter startes en særlig operator inden for OpenShift-klyngen, som håndterer hele opdateringsprocessen.
Ny CSI
Det andet – den nye CSI – controller til storage-grænsefladen, der giver mulighed for at tilslutte forskellige eksterne storage-anlæg til OpenShift-klyngen. Der understøttes et stort antal storage-driverudbydere til OpenShift baseret på storage-drivere, der skrives af producenterne af storage-anlæggene. En komplet liste over understøttede CSI-drivere kan findes i dette dokument: . På denne liste kan du finde alle de vigtigste modeller af diskarrays fra førende producenter (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage), SDS-løsninger (Ceph) og cloud-lagringsløsninger (AWS, Azure, Google). OpenShift 4.2 understøtter brugen af CSI-drivere i CSI-specifikation version 1.1.
RedHat OpenShift Service Mesh
Baseret på projekterne Istio, Kiali og Jaeger - Red Hat OpenShift Service Mesh, udover de almindelige opgaver med routing af anmodninger mellem tjenester, muliggør også sporings- og visualiseringsfunktioner. Dette hjælper udviklerne med at forenkle interaktionen, overvågningen og styringen af applikationen, der er implementeret i Red Hat OpenShift.
Visualisering af en applikation med mikrotjenestearkitektur ved hjælp af Kiali
For at maksimere forenklingen af installationsprocesserne, tjenesterne og administrationen af Service Mesh livscyklussen, tilbyder Red Hat OpenShift administratorer en speciel operator - Service Mesh Operator. Det er en Kubernetes-operator, der gør det muligt at implementere rekonfigurerede pakker af Istio, Kiali og Jaeger på klyngen, hvilket minimerer den administrative byrde ved administrationen af applikationerne.
CRI-O i stedet for Docker
Den standard container runtime Docker er blevet erstattet af CRI-O. Man kunne allerede anvende CRI-O i version 3.11, men det blev primært i version 4.2. Det er hverken godt eller dårligt, men det er værd at have in mente ved brug af produktet.
Operatører og deployment af applikationer
Operatører er en ny enhed for RedHat OpenShift, som blev introduceret i fjerde version. Det er en metode til pakning, deployment og styring af en Kubernetes-applikation. Det kan ses som en API-styret plugin for applikationer, der køres i containere ved hjælp af Kubernetes og kubectl-værktøjer.
Kubernetes-operatører hjælper med at automatisere enhver opgave relateret til administrationen og livscyklusstyring af applikationen, du implementerer i din klynge. For eksempel kan en operatør automatisere opdateringer, backup og skalering af applikationen, ændre konfigurationen osv. Den fulde liste over operatører kan ses på .
OperatorHub er tilgængelig direkte fra webinterface til styringskonsollen. Det repræsenterer et katalog over applikationer til OpenShift, støttet af Red Hat. Det vil sige, at alle operatører godkendt af Red Hat vil blive dækket af leverandørens support.
OperatorHub-portalen i OpenShift's styringskonsol
Universal base image
Dette er et standardiseret sæt af operativsystembilleder til RHEL, som kan bruges til at oprette dine applikationer i containere. Der er minimal, standard og fuld sæt. De optager meget lidt plads, understøtter alle nødvendige installerede pakker og programmeringssprog.
CI/CD værktøjer
I RedHat OpenShift 4.2 er der mulighed for at vælge mellem Jenkins og OpenShift Pipelines baseret på Tekton Pipelines.
OpenShift Pipelines er baseret på Tekton, som bedre understøtter tilgange som Pipeline as Code og GitOps. I OpenShift-pipelines udføres hvert trin i sin egen container, så ressourcer kun bruges under udførelsen af trinnet. Dette giver udviklere fuld kontrol over levering pipelines, plugins og adgangskontrol uden en central CI/CD server til administration.
OpenShift Pipelines er i øjeblikket i Preview for udviklere og er tilgængelig som en operator på OpenShift 4 klyngen. Naturligvis kan OpenShift-brugere stadig bruge Jenkins i RedHat OpenShift 4.
Opdateringer i administrationen for udviklere
I 4.2 er OpenShift's webgrænseflade blevet helt opdateret både for udviklere og administratorer.
I de tidligere versioner af OpenShift arbejdede alle i tre konsoller: servicekatalog, administrator-konsol og arbejds-konsol. Nu er klyngen opdelt i to dele — administrator-konsolen og udvikler-konsolen.
Udvikler-konsollen har fået betydelige forbedringer af brugergrænsefladen. Den viser nu applikationernes topologier og deres byggere mere bekvemt. Dette letter udvikleres oprettelse, udrulning og visualisering af containerapplikationer og klyngeressourcer. Det gør det muligt for dem at fokusere på det, der er vigtigt for dem.
Udviklerportalen i OpenShift's administrationskonsol
Odo
Odo er et udviklerfokuseret kommandolinjeværktøj, der forenkler applikationsudviklingen i OpenShift. Ved at bruge interaktion i stil med git push hjælper denne CLI udviklere, der ikke er bekendt med Kubernetes, med at oprette applikationer i OpenShift.
Integration med udviklingsmiljøer
Udviklere kan nu oprette, 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 extension til Microsoft Azure DevOps
Der er nu en Red Hat OpenShift Deployment-udvidelse til Microsoft Azure DevOps. Brugere af dette DevOps-værktøjssæt kan nu implementere deres applikationer i Azure Red Hat OpenShift eller hvilken som helst anden OpenShift-klynge direkte fra Microsoft Azure DevOps.
Overgangen fra version tre til version fire
Da det drejer sig om en ny version og ikke en opdatering, kan man ikke bare installere den fjerde version oven på den tredje. Opdateringen fra version tre til fire vil ikke blive understøttet.
Men der er også gode nyheder: Red Hat leverer værktøjer til at migrere projekter fra 3.7 til 4.2. Du kan flytte applikationsbelastninger ved hjælp af Cluster Application Migration (CAM)-værktøjet. CAM tillader kontrol over migreringen og minimering af applikationens nedetid.
OpenShift 4.3
De vigtigste nye funktioner beskrevet i denne artikel dukkede op i version 4.2. I den nyligt udgivne 4.3 er ændringerne ikke så betydningsfulde, men der er alligevel noget nyt. Listen over ændringer er ret omfattende; her er de mest betydningsfulde, efter vores mening:
Opdatering af Kubernetes-versionen til 1.16.
Versionen opgraderede to trin ad gangen; i OpenShift 4.2 var den 1.14.
Kryptering af data i etcd
Fra og med version 4.3 er der mulighed for at kryptere data i etcd-databasen. Når kryptering er aktiveret, vil det være muligt at kryptere følgende ressourcer i OpenShift API og Kubernetes API: Secrets, ConfigMaps, Routes, adgangs- og OAuth-autorisationstokens.
Helm
Tilføjet support til version 3 af Helm – den populære pakket 관리자 til Kubernetes. Indtil videre har støtte status som TECHNOLOGY PREVIEW. I fremtidige versioner af OpenShift vil understøttelsen af Helm blive udvidet til fuld støtte. Helm-cli-værktøjet leveres sammen med OpenShift og kan downloades fra Cluster Management Web Console.
Opdatering af Project Dashboard
I den nye version giver Project Dashboard yderligere information på projektsiden: projektstatus, ressourceforbrug og kvoter for projektet.
Visning af sårbarheder for quay i webkonsollen
Funktionen til visning af kendte sårbarheder for billeder i Quay-repositorier er tilføjet til styringskonsollen. Visning af sårbarheder understøttes for både lokale og eksterne repositories.
Oprettelsen af offline operatorhub er blevet forenklet
I tilfælde af implementering af et OpenShift-kluster i et isoleret netværk, hvor der er begrænset eller ingen adgang til internettet, er det blevet lettere at oprette et "spejl" for OperatorHub-registret. Dette kan nu gøres med blot tre kommandoer.
Forfattere:
Viktor Puchkov, Yuriy Semyenukov
Kilde: habr.com
