Den fjerde versjonen av OpenShift ble utgitt relativt nylig. Den nåværende versjonen 4.3 har vært tilgjengelig siden slutten av januar og alle endringene i den er enten noe helt nytt som ikke var i den tredje versjonen, eller en større oppdatering av det som dukket opp i versjon 4.1. Alt vi vil fortelle deg nå må være kjent, forstått og tatt i betraktning av de som jobber med OpenShift og planlegger å bytte til en ny versjon.
Med utgivelsen av OpenShift 4.2 har Red Hat gjort arbeidet med Kubernetes enklere. Nye verktøy og plugins har dukket opp for å lage containere, CI/CD-pipelines og serverløse distribusjoner. Innovasjoner gir utviklere muligheten til å fokusere på å skrive kode, og ikke på å håndtere Kubernetes.
Hva er egentlig nytt i versjoner av OpenShift 4.2 og 4.3?
Beveger seg mot hybridskyer
Når de planlegger en ny IT-infrastruktur eller når de utvikler et eksisterende IT-landskap, vurderer bedrifter i økende grad en skytilnærming til levering av IT-ressurser, som de implementerer private skyløsninger for eller bruker kraften til offentlige skyleverandører for. Dermed bygges moderne IT-infrastruktur i økende grad etter en «hybrid» skymodell, når både lokale ressurser og offentlige skyressurser med felles styringssystem brukes. Red Hat OpenShift 4.2 er spesialdesignet for å forenkle overgangen til en hybrid skymodell og gjør det enkelt å koble ressurser fra leverandører som AWS, Azure og Google Cloud Platform til klyngen, sammen med bruk av private skyer på VMware og OpenStack.
Ny tilnærming til installasjon
I versjon 4 har tilnærmingen til å installere OpenShift endret seg. Red Hat tilbyr et spesielt verktøy for å distribuere en OpenShift-klynge - openshift-install. Verktøyet er en enkelt binær fil skrevet i Go. Openshit-installer forbereder en yaml-fil med konfigurasjonen som kreves for distribusjon.
Ved installasjon ved bruk av skyressurser, må du spesifisere minimal informasjon om den fremtidige klyngen: DNS-sone, antall arbeidernoder, spesifikke innstillinger for skyleverandøren, kontoinformasjon for tilgang til skyleverandøren. Etter å ha klargjort konfigurasjonsfilen, kan klyngen distribueres med én kommando.
Ved installasjon på dine egne dataressurser, for eksempel når du bruker en privat sky (vSphere og OpenStack støttes) eller når du installerer på bare metallservere, må du manuelt konfigurere infrastrukturen - forberede minimum antall virtuelle maskiner eller fysiske servere som kreves for å opprette en Control Plane-klynge, konfigurere nettverkstjenester. Etter denne konfigurasjonen kan en OpenShift-klynge opprettes på samme måte med én kommando fra openshift-installer-verktøyet.
Infrastrukturoppdateringer
CoreOS-integrasjon
Nøkkeloppdateringen er integrasjon med Red Hat CoreOS. Red Hat OpenShift-masternoder kan nå fungere bare på det nye operativsystemet. Dette er et gratis operativsystem fra Red Hat som er designet spesielt for containerløsninger. Red Hat CoreOS er en lett Linux optimert for å kjøre containere.
Hvis operativsystemet og OpenShift i 3.11 eksisterte separat, er det i 4.2 uløselig knyttet til OpenShift. Nå er dette et enkelt apparat - uforanderlig infrastruktur.
For klynger som bruker RHCOS for alle noder, er oppgradering av OpenShift Container Platform en enkel og svært automatisert prosess.
Tidligere, for å oppdatere OpenShift, måtte du først oppdatere det underliggende operativsystemet som produktet kjørte på (den gangen Red Hat Enterprise Linux). Først da kunne OpenShift oppdateres gradvis, node for node. Det var ikke snakk om noen automatisering av prosessen.
Nå, siden OpenShift Container Platform fullt ut kontrollerer systemene og tjenestene på hver node, inkludert OS, løses denne oppgaven ved å trykke på en knapp fra webgrensesnittet. Etter dette lanseres en spesiell operatør inne i OpenShift-klyngen, som styrer hele oppdateringsprosessen.
Ny CSI
For det andre er den nye CSI en lagringsgrensesnittkontroller som lar deg koble ulike eksterne lagringssystemer til OpenShift-klyngen. Et stort antall lagringsdriverleverandører for OpenShift støttes basert på lagringsdrivere som er skrevet av lagringssystemprodusentene selv. En fullstendig liste over støttede CSI-drivere finner du i dette dokumentet: . I denne listen kan du finne alle hovedmodellene av diskarrayer fra ledende produsenter (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage), SDS-løsninger (Ceph) og skylagring (AWS, Azure, Google). OpenShift 4.2 støtter CSI-drivere for CSI-spesifikasjonen versjon 1.1.
RedHat OpenShift Service Mesh
Basert på Istio-, Kiali- og Jaeger-prosjektene tillater Red Hat OpenShift Service Mesh, i tillegg til de vanlige oppgavene med å rute forespørsler mellom tjenester, sporing og visualisering av dem. Dette hjelper utviklere med å enkelt kommunisere, overvåke og administrere en applikasjon som er distribuert i Red Hat OpenShift.
Visualisering av en applikasjon som har en mikrotjenestearkitektur ved bruk av Kiali
For å forenkle installasjon, vedlikehold og livssyklusadministrasjon av Service Mesh så mye som mulig, gir Red Hat OpenShift administratorer en spesiell operatør, Service Mesh Operator. Dette er en Kubernetes-operatør som lar deg distribuere rekonfigurerte Istio-, Kiali- og Jaeger-pakker på en klynge, og maksimere den administrative byrden med å administrere applikasjoner.
CRI-O i stedet for Docker
Standard container runtime Docker er erstattet av CRI-O. Det var mulig å bruke CRI-O allerede i versjon 3.11, men i 4.2 ble det den viktigste. Ikke bra eller dårlig, men noe å huske på når du bruker produktet.
Operatører og applikasjonsdistribusjon
Operatører er en ny enhet for RedHat OpenShift, som dukket opp i den fjerde versjonen. Det er en metode for å pakke, distribuere og administrere en Kubernetes-applikasjon. Det kan tenkes på som en plugin for applikasjoner distribuert i containere, drevet av Kubernetes API og kubectl-verktøy.
Kubernetes-operatører hjelper til med å automatisere alle oppgaver knyttet til administrasjon og livssyklusadministrasjon av applikasjonen du distribuerer til klyngen din. Operatøren kan for eksempel automatisere oppdateringer, sikkerhetskopier og skalering av applikasjonen, endre konfigurasjonen osv. En fullstendig liste over operatører finner du på .
OperatorHub er tilgjengelig direkte fra nettgrensesnittet til administrasjonskonsollen. Det er en applikasjonskatalog for OpenShift vedlikeholdt av Red Hat. De. alle Red Hat-godkjente operatører vil bli dekket av leverandørstøtte.
OperatorHub-portal i OpenShift-administrasjonskonsollen
Universelt grunnbilde
Det er et standardisert sett med RHEL OS-bilder som kan brukes til å bygge dine containeriserte applikasjoner. Det er minimale, standard og fulle sett. De tar opp svært lite plass og støtter alle nødvendige installerte pakker og programmeringsspråk.
CI/CD-verktøy
I RedHat OpenShif 4.2 ble det mulig å velge mellom Jenkins og OpenShift Pipelines basert på Tekton Pipelines.
OpenShift Pipelines er basert på Tekton, som støttes bedre av Pipeline når Code og GitOps nærmer seg. I OpenShift-pipelines kjører hvert trinn i sin egen beholder, så ressurser brukes bare mens trinnet kjøres. Dette gir utviklere full kontroll over modulleveringspipelines, plugins og tilgangskontroll uten en sentral CI/CD-server å administrere.
OpenShift Pipelines er for øyeblikket i Developer Preview og tilgjengelig som operatør på en OpenShift 4-klynge. Selvfølgelig kan OpenShift-brukere fortsatt bruke Jenkins på RedHat OpenShift 4.
Oppdateringer for utvikleradministrasjon
I 4.2 OpenShift er nettgrensesnittet fullstendig oppdatert for både utviklere og administratorer.
I tidligere versjoner av OpenShift jobbet alle i tre konsoller: tjenestekatalog, administratorkonsoll og arbeidskonsoll. Nå er klyngen kun delt i to deler - administratorkonsoll og utviklerkonsoll.
Utviklerkonsollen har fått betydelige forbedringer i brukergrensesnittet. Nå viser den mer praktisk topologiene til applikasjoner og deres sammenstillinger. Dette gjør det enklere for utviklere å lage, distribuere og visualisere containeriserte applikasjoner og grupperte ressurser. Lar dem fokusere på det som er viktig for dem.
Utviklerportal i OpenShift-administrasjonskonsollen
Øre
Odo er et utviklerorientert kommandolinjeverktøy som forenkler applikasjonsutvikling i OpenShift. Ved å bruke kommunikasjon i git push-stil hjelper denne CLI utviklere som er nye til Kubernetes med å bygge applikasjoner i OpenShift.
Integrasjon med utviklingsmiljøer
Utviklere kan nå bygge, feilsøke og distribuere applikasjonene sine i OpenShift uten å forlate deres favorittkodeutviklingsmiljø, for eksempel Microsoft Visual Studio, JetBrains (inkludert IntelliJ), Eclipse Desktop, etc.
Red Hat OpenShift Deployment-utvidelse for Microsoft Azure DevOps
Red Hat OpenShift Deployment-utvidelsen for Microsoft Azure DevOps har blitt utgitt. Brukere av dette DevOps-verktøysettet kan nå distribuere applikasjonene sine til Azure Red Hat OpenShift eller en hvilken som helst annen OpenShift-klynge direkte fra Microsoft Azure DevOps.
Overgang fra tredje versjon til fjerde
Siden vi snakker om en ny utgivelse, og ikke en oppdatering, kan du ikke bare legge den fjerde versjonen på toppen av den tredje. Oppdatering fra versjon XNUMX til versjon XNUMX støttes ikke..
Men det er gode nyheter: Red Hat gir verktøy for å migrere prosjekter fra 3.7 til 4.2. Du kan migrere applikasjonsarbeidsbelastninger ved å bruke CAM-verktøyet (Cluster Application Migration). CAM lar deg kontrollere migrering og minimere nedetid for applikasjoner.
OpenShift 4.3
De viktigste nyvinningene beskrevet i denne artikkelen dukket opp i versjon 4.2. De nylig utgitte 4.3-endringene er ikke like store, men det er fortsatt noen nye ting. Listen over endringer er ganske omfattende, her er de viktigste etter vår mening:
Oppdater Kubernetes-versjonen til 1.16.
Versjonen ble oppgradert med to trinn samtidig; i OpenShift 4.2 var den 1.14.
Datakryptering i etcd
Fra og med versjon 4.3 ble det mulig å kryptere data i etcd-databasen. Når kryptering er aktivert, vil det være mulig å kryptere følgende OpenShift API- og Kubernetes API-ressurser: Secrets, ConfigMaps, Routes, access tokens og OAuth-autorisasjon.
Helm
Lagt til støtte for Helm versjon 3, en populær pakkebehandling for Kubernetes. For nå har støtten statusen TECHNOLOGY PREVIEW. Helm-støtte vil bli utvidet til full støtte i fremtidige versjoner av OpenShift. Hjelm cli-verktøyet kommer med OpenShift og kan lastes ned fra nettkonsollen for klyngeadministrasjon.
Oppdatering av prosjektdashbord
I den nye versjonen gir Project Dashboard tilleggsinformasjon på prosjektsiden: prosjektstatus, ressursutnyttelse og prosjektkvoter.
Viser sårbarheter for kai i nettkonsollen
En funksjon er lagt til administrasjonskonsollen for å vise kjente sårbarheter for bilder i Quay-repositories. Visning av sårbarheter for lokale og eksterne depoter støttes.
Forenklet opprettelse av offline operatørhub
Når det gjelder distribusjon av en OpenShift-klynge i et isolert nettverk, hvor tilgangen til Internett er begrenset eller fraværende, er det forenklet å opprette et "speil" for OperatorHub-registeret. Nå kan dette gjøres med bare tre lag.
Forfattere:
Victor Puchkov, Yuri Semenyukov
Kilde: www.habr.com