OpenShift kui ettevõte versioon Kubernetes. Osa 1

„Mis on Kubernetes ja OpenShift'i vahe?“ – see küsimus tekib pidevalt. Tegelikult on see sama, mis küsida, mis vahe on autol ja selle mootoril. Jätkates analoogiat, on auto valmis toode, millega saab kohe kasutama hakata: istud sisse ja sõidad. Teisest küljest, et mootor viiks sind kuhugi, peab see olema täiendatud paljude teiste asjadega, et lõpuks saada sama auto.

Seetõttu on Kubernetes nagu mootor, mille ümber on kokku pandud auto (platvorm) OpenShift, mis viib sind eesmärgini.

Selles artiklis soovime meelde tuletada ja pisut põhjalikumalt käsitleda järgmisi olulisi punkte:

• Kubernetes on OpenShift'i platvormi süda. Ja see on 100% sertifitseeritud Kubernetes, täielikult avatud koodiga ja ilma vähimagi eraviisilisuseta. Lühidalt:
  • OpenShift'i kluster API on 100% Kubernetes.
  • Kui konteiner töötab mõnes teises Kubernetes'i süsteemis, siis töötab see ilma muudatusteta ka OpenShift'is. Rakendustes muudatuste tegemine ei ole vajalik.
• OpenShift ei täienda mitte ainult Kubernetes'e kasulike funktsioonidega ja võimalustega. Nagu auto, on OpenShift kohe kasutusvalmis — seda saab kohe rakendada tootmisesse, ja nagu me allpool näitame, lihtsustab see oluliselt arendaja elu. Just seetõttu on OpenShift kahel näol: see on edukas ja laialdaselt tuntud PaaS-platvorm ettevõtte tasemel arendajate jaoks, samuti super usaldusväärne Container-as-a-Service lahendus, kui vaadata tööstuslikust perspektiivist.

OpenShift on Kubernetes, millel on 100% sertifikaat CNCF fondist

OpenShifti aluseks on sertifitseeritud Kubernetes. Seetõttu imetlevad kasutajad pärast vastava väljaõppe läbimist kubectl'i võimsust. Ja need, kes on OpenShift'i üle läinud Kubernetes Cluster'ilt, ütlevad sageli, kui väga neile meeldib, et pärast kubeconfig'i suunamist OpenShifti klastrisse töötavad kõik olemasolevad skriptid laitmatult.

Olete tõenäoliselt kuulnud OpenShifti komandorealist utiliidist nimega OC. See on täiesti ühilduv käskudega kubectl ja pakub lisaks mitmeid kasulikke abilisi, mis tulevad kasuks paljude ülesannete täitmisel. Kuid kõigepealt räägime natuke rohkem OC ja kubectl ühilduvusest:

kubectl käskude
OC käskude

kubectl get pods
oc get pods

kubectl get namespaces
oc get namespaces

kubectl create -f deployment.yaml
oc create -f deployment.yaml

Siin on, kuidas kubectl tulemused OpenShift API-lt välja paistavad:

• kubectl get pods – ilmselt tagastab pod’id.

• kubectl get namespaces – ilmselt tagastab nimesid.

Käsk kubectl create -f mydeployment.yaml loob Kubernetes'i ressursse samamoodi nagu igal teisel Kubernetes platvormil, nagu on näidatud allpool videos:

Teisisõnu, kõik Kubernetes’i API-d on OpenShiftis täielikult saadaval, säilitades 100% ühilduvust. Just sellepärast OpenShift on tunnustatud sertifitseeritud Kubernetes platvormina Cloud Native Computing Foundation (CNCF) fondi poolt.. 

OpenShift täiendab Kubernetes'i kasulike funktsioonidega.

Kubernetesi API-d on OpenShiftis 100% kättevõtlikud, kuid Kubernetesi seadme kubectl funktsionaalsus ja mugavus jätavad soovida. Seetõttu on Red Hat täiendanud Kubernetesit kasulike funktsioonide ja käsurea tööriistadega, nagu OC (OpenShift kliendi lühend) ja ODO (OpenShift DO, see tööriist on mõeldud arendajatele).

1. OC tööriist – võimsam ja mugavam variant Kubectl'ile

Näiteks, erinevalt kubectl'ist, võimaldab see luua uusi nimiruumide ja hõlpsalt konteksti vahetada, samuti pakub arendajatele mitmeid kasulikke käske, näiteks konteineripiltide koostamiseks ja rakenduste juurutamiseks otse lähtekoodist või binaarfailidest (Source-to-image, s2i).

Vaatame näitlikult, kuidas sisseehitatud abivahendid ja OC tööriista täiendav funktsionaalsus aitavad igapäevaseid ülesandeid lihtsustada.

Esimene näide – nimede haldamine. Igas Kubernetes klasteris eksisteerib alati mitu nimeala. Need kasutatakse tavaliselt arendus- ja tootmis keskkondade loomiseks, kuid neid võib kasutada ka näiteks iga arendaja isikliku "liiva" loomiseks. Praktiliselt tähendab see, et arendajal tuleb sageli vahetada nimealasid, kuna kubectl töötab praeguse nimeala kontekstis. Seetõttu kasutatakse kubectl-i puhul seda eesmärki saavutamiseks aktiivselt abiskripte. OC kasutamisel piisab soovitud nimealale üleminekuks lihtsalt öelda "oc project nimeala".

Kas te ei mäleta, kuidas vajalik nimeala nimetatakse? Pole probleemi, lihtsalt sisestage "oc get projects", et kuvada täielik nimealade loetelu. Kas te olete skeptiliselt huvitatud, kuidas see töötab, kui teil on juurdepääs ainult piiratud alamehhanismide kogumile klastris? Noh, kuna kubectl teeb seda õigesti vaid juhul, kui RBAC lubab teil näha kõiki nimealasid klastris, ja suurtes klastrites ei anta selliseid õigusi sugugi kõigile. Nii et vastame: OC jaoks pole see üldse probleem ja ta väljastab sellises olukorras hõlpsalt täieliku nimealade loetelu. Sellistest pisiasjadest koosnebki Openshift'i ettevõttele orienteerituse ja selle platvormi hea skaleeritavus kasutajate ja rakenduste osas.

2. ODO – täiustatud versioon kubectl'ist arendajatele

Veel ühe näitena Red Hat OpenShift'i täiustustest võrreldes Kubernetes'ega võib tuua käsurea tööriista ODO. See on mõeldud arendajatele ning võimaldab kiiresti juurutada paikset koodi kaug-OpenShift klastris. Lisaks võimaldab see optimeerida sisemisi protsesse, et koheselt sünkroonida kõik koodimuudatused konteineritega kaug-OpenShift klastris, ilma et oleks vaja uuesti ehitada, registreerida ja juurutada pilte.

Vaadakem, kuidas OC ja ODO lihtsustavad töötamist konteineritega ja Kubernetes'ega.

Lihtsalt võrdleme paari tööprotsessi, kui need põhinevad kubectl'il ja kui rakendatakse OC-d või ODO-d.

• Koodi juurutamine OpenShift'is neile, kes ei valda YAML keelt:

Kubernetes / kubectl
$> git clone github.com/sclorg/nodejs-ex.git
1- Loome Dockerfile'i, mis ehitab pildi koodist
————–
FROM node
WORKDIR /usr/src/app
COPY package*.json ./
COPY index.js ./
COPY ./app ./app
RUN npm install
EXPOSE 3000
CMD [ “npm”, “start” ]
————–
2- Ehita pilt
$> podman build …
3- Logi sisse registrisse
podman login …
4- Aseta pilt registrisse
podman push
5- Loome yaml-failid rakenduse juurutamiseks (deployment.yaml, service.yaml, ingress.yaml) – see on absoluutne miinimum.
6- Juurutame manifest-failid:
Kubectl apply -f .

OpenShift / oc
$> oc new-app github.com/sclorg/nodejs-ex.git – meie_rakenduse_nimi

OpenShift / odo
$> git clone github.com/sclorg/nodejs-ex.git
$> odo create component nodejs myapp
$> odo push

• Konteksti vahetamine: tööruumi nimete või klastrisse vahetamine.

Kubernetes / kubectl
1- Loome konteksti kubeconfigis projekti “myproject” jaoks
2- kubectl set-context …

OpenShift / oc
oc project “myproject”

Kvaliteedikontroll: „Siia tuli üks huvitav funktsioon, mis on praegu alfa-versioonis. Kas me toome selle tootmisse?“

Kujutage ette, et teid istutakse võidusõidumasinasse ja öeldakse: „Oleme paigaldanud uue tüüpi pidurid ja, ausalt öeldes, pole need veel täiesti usaldusväärsed… Aga ärge muretsege, me töötame neid aktiivselt kogu meistrivõistluste jooksul edasi.“ Kuidas teile selline perspektiiv meeldib? Meile Red Hat'is ei meeldi see just eriti. 🙂

Seetõttu püüame hoiduda alfa-versioonidest seni, kuni need pole piisavalt küpsed ja me ei ole läbi viinud põhjalikku lahingutesti ning tunnetanud, et neid on ohutu kasutada. Tavaliselt läbib kõik kõigepealt Dev Preview etapi, seejärel Tech Preview ja ainult siis tuleb see välja avaliku väljaandena Üldine kättesaadavus (GA), mis on juba nii stabiilne, et sobib tootmisse.

Miks nii? Sest nagu iga muu tarkvara arendamisel, ei jõua kõik esialgsed ideed Kuberneteses lõpuks väljaande juurde. Või nad jõuavad ning säilitavad isegi kavandatud funktsionaalsuse, kuid nende rakendamine erineb radikaalselt sellest, mis oli alfa-versioonis. Kuna tuhanded ja tuhanded Red Hati kliendid kasutavad OpenShifti kriitiliste ülesannete toetamiseks, keskendume oma platvormi stabiilsusele ja pikaajalisele toele.

Red Hat vabastab sihikindlalt sagedased OpenShifti väljaanded ja värskendab selle koosseisu kuuluvat Kubernetes versiooni. Näiteks on praeguses OpenShifti 4.3 GA-väljaandes, mis kirjutamise ajal on, sisse ehitatud Kubernetes 1.16, mis on üks numbriga maas upstream-versioonist Kubernetes, mille numbriks on 1.17. Seega püüame anda kliendile ettevõtte tasemel Kubernetes ja tagada täiendav kvaliteedikontroll OpenShifti uute väljaannete väljalaskmisprotsessis.

Tarkvaraparandused: «Kuberneetes, mis meil tootmises on, on leidunud turvaauke. Ja neid saab kinni panna ainult kolmanda versiooni värskendamisega. Või on olemas muid võimalusi?»

Avaallikaprojekti Kuberneetes raames väljastatakse tarkvaraparandused tavaliselt järgmise versiooni koosseisus, mõnikord katab neid üks või kaks eelmist vaheversiooni, mis annab katvuse kuni kuue kuu jooksul tagasi.

Red Hat on õigustatult uhke, et väljastab kriitilisi parandusi varem kui teised ning tagab toetuse palju pikema ajaperioodi jooksul. Võtame näiteks Kuberneeteses tuvastatud privileegide eskaleerimise haavatavuse (CVE-2018-1002105): see avastati Kuberneetes 1.11-s, aga parandusi eelnevate versioonide jaoks väljastati kuni versioonini 1.10.11, jättes selle haavatavuse kõikidesse eelnevatesse Kuberneetes versioonidesse, alates 1.x kuni 1.9.

Omalt poolt, Red Hat on OpenShifti patche'inud tagasi isegi versioonini 3.2 (seal on Kuberneetes 1.2), hõlmates üheksa OpenShifti versiooni ja demonstreerides selgelt hoolt klientide üle (lisainfot siit).

Kuidas OpenShift ja Red Hat viivad Kuberneetes edasi

Red Hat on teisel kohal Kubernetesi avatud projekti programmistiku panustes, jäädes alla ainult Google'ile, samas kui 3 5-st kõige viljakamatest arendajatest kuuluvad Red Hati. Veel üks vähetuntud fakt: paljud kriitilised funktsioonid tulid Kubernetesesse just Red Hati initsiatiivil, sealhulgas järgmised:

• RBAC. Kuberneteses ei olnud RBAC (ClusterRole, ClusterRoleBinding) funktsioone, kuni Red Hati insenerid ei otsustanud need ellu viia platvormi osana, mitte eraldi OpenShifti lisafunktsiooni näol. Kas Red Hat pelgab Kuberneteset täiustamast? Muidugi mitte, sest Red Hat järgib rangelt avatud koodi põhimõtteid ja ei mängi Open Core'i mänge. Parandused ja uuendused, mis rakendatakse arenduskogukonna tasandil, mitte omandiõiguse alusel, muutuvad elujõulisemaks ja saavutavad laiemat levikut, mis sobib suurepäraselt meie peamise eesmärgiga – muuta avatud lähtekoodiga tarkvara meie klientide jaoks kasulikuks.
• Turvasekumate poliitikad pod'ides (Pod Security Policies). Alguses rakendati seda rakenduste turvalise täitmise kontseptsiooni pod'ides OpenShiftis nimega SCC (Security Context Constraints). Nagu eelnevas näites, otsustas Red Hat tuua need arendused avatud projekti Kubernetes, et neid saaks kasutada kõik soovijad.

Seda näidete rida võiks jätkata, kuid tahtsime lihtsalt näidata, et Red Hat tõeliselt püüab arendada Kubernetesit ja muuta selle paremaks kõigile.

Selge, OpenShift on Kubernetes. Aga milles on siis erinevused? 🙂

Loodame, et olete selle kohani jõudnud ja mõistnud, et Kubernetes on OpenShifti põhikomponent. Põhikomponent, kuid kindlasti mitte ainus. Teisisõnu, lihtsalt Kubernetesit installides ei saa te ettevõtte klassi platvormi. Peate lisama autentimise, võrgu, turvalisuse, jälgimise, logihalduse ja palju muud. Lisaks tuleb teha keeruline valik paljusid saadaval olevate tööriistade vahel (kui soovite hinnata ökosüsteemi mitmekesisust, vaadake lihtsalt CNCF diagrammi) ja tagada ühtsus ja koostöö, et nad töötaksid kui üks tervik. Lisaks peate regulaarselt teostama uuendusi ja regressioonitestimist, kui mõni kasutatav komponendi uus versioon välja tuleb. See tähendab, et peale platvormi loomise ja hooldamise peate tegelema ka kogu selle tarkvaraga. Kahtlemata jääb siin vähegi aega äriülesannete lahendamiseks ja konkurentsieeliste saavutamiseks.

Ent OpenShift'i puhul võtab Red Hat kõik need keerukused enda kanda ja pakub teile lihtsalt funktsionaalselt valmistoote platvormi, kuhu kuulub mitte ainult Kubernetes, vaid ka kõik vajalikud avatud lähtekoodiga tööriistad, mis muudavad Kubernetes'i tõeliseks ettevõttetasandi lahenduseks, mida saab kohe ja muretult tootmisse käivitada. Ja muidugi, kui teil on oma tehnolooge, saate OpenShift'i integreerida olemasolevatesse lahendustesse.

OpenShift on nutikas Kubernetes'i platvorm

Vaata ülaltoodud pilti: kõik, mis jääb Kubernetes'i ristküliku välja, on need valdkonnad, kuhu Red Hat lisab funktsionaalsust, mida Kubernetes'is ei ole, seda nimetatakse by-design. Nüüd vaatame neid põhivaldkondi.

1. Usaldusväärne opsüsteem aluseks: RHEL CoreOS või RHEL

Red Hat on olnud enam kui 20 aastat juhtiv Linuxi jaotus kritilise äri rakenduste jaoks. Kogutud ja pidevalt uuendatud kogemus selles valdkonnas võimaldab meil pakkuda tõeliselt usaldusväärset ja usaldusväärset alust konteinerite tootmiseks. RHEL CoreOS kasutab sama tuuma nagu RHEL, kuid on optimeeritud peamiselt selliste toimingute jaoks nagu konteinerite käitamine ja töö Kubernetes'i klastrites: selle vähendatud suurus ja muutumatud omadused lihtsustavad klastrite seadistamist, automaatset skaleerimist, paranduspakettide juurutamist jne. Kõik need funktsioonid teevad sellest ideaalse aluse, et tagada sama kasutajakogemus OpenShiftis erinevates arvutuskeskkondades, alates „alusest rauast” kuni eraisikute ja avalike pilvedeni.

2. IT-operatorsioonide automatiseerimine

Protsesside automatiseerimine paigaldamise ja teise päeva toimingute jaoks (st igapäevase kasutamise) on OpenShifti tugevus, mis muudab konteinerite platvormi haldamise, uuendamise ja töö säilitamise tunduvalt lihtsamaks. See saavutatakse OpenShift 4 süvakihis Kubernetes'i operaatorite toe kaudu.

OpenShift 4 on samuti terve Kubernetes'i operaatorite lahenduste ökosüsteem, mida on välja töötanud nii Red Hat ise kui ka kolmandate osapoolte partnerid (vt. operaatorite katalooge Red Hat, või operaatorite pood operatorhub.io, mille on loonud Red Hat kolmandate osapoolte arendajatele).

OpenShift 4 integreeritud kataloog sisaldab üle 180 Kubernetes'i operaatori

3. Arendajate tööriistad

Alates 2011. aastast on OpenShift saadaval PaaS (Platform-as-a-Service) platvormina, mis muudab arendajate elu oluliselt lihtsamaks, aidates neil keskenduda koodi loomisele ning pakkudes sisseehitatud tuge sellistele programmeerimiskeeltedele nagu Java, Node.js, PHP, Ruby, Python, Go, ning teenuseid pidevaks integreerimiseks ja kohaletoimetamiseks CI/CD, andmebaasid jne. OpenShift 4 pakub ulatuslikku katalooge, sisaldab rohkem kui 100 Red Hati ja meie partnerite välja töötatud Kubernetes-i operaatoritel põhinevat teenust.

Erinevalt Kubernetesest on OpenShift 4-l spetsiaalne kasutajaliides (Arendaja konsool), mis aitab arendajatel hõlpsalt juurutada oma nimepindades rakendusi erinevatest allikatest (git, välistest registritest, Dockerfile jt) ning visuaalselt demonstreerida rakenduse komponentide vahelisi suhteid.

Arendaja konsool esitab rakenduse komponente selgelt ja lihtsustab Kubernetesega töötamist.

Lisaks pakub OpenShift arendustööriistade komplekti Codeready, kuhu kuulub muu hulgas Codeready tööruumid, täielikult konteineriseeritud veebiliidesega IDE, mis töötab otse OpenShiftil ja rakendab lähenemist „IDE teenusena”. Teisest küljest, need, kes soovivad töötada rangelt lokaalses režiimis, saavad kasutada Codeready konteineri – täielikult funktsionaalset OpenShift 4 versiooni, mida saab juurutada sülearvutisse.

Integreeritud „IDE teenusena” efektiivseks arendamiseks Kubernetes/OpenShift platvormil.

Otse välja pakitud OpenShift pakub täielikku CI/CD süsteemi, kas konteineriseeritud Jenkinsist ja pistikprogrammist DSL torude haldamiseks või Kubernetes-orienteeritud CI/CD süsteemiks Tekton (praegu Tehnilise eelvaate versioonis). Mõlemad lahendused integreeruvad täielikult OpenShifti konsooliga, võimaldades käivitada torude päästikud, vaadata juurutamisi, logisid jne.

4. Rakendustööriistad

OpenShift võimaldab juurutada nii traditsioonilisi stateful-rakendusi kui ka pilvepõhiseid lahendusi, mis põhinevad uutel arhitektuuridel, näiteks mikroteenustel või serverivabadel lahendustel. OpenShift Service Mesh lahendus tuleb kogumisse oluliste mikroteenuste hooldamiseks mõeldud tööriistadega, nagu Istio, Kiali ja Jaeger. Samuti sisaldab OpenShift Serverless lahendus mitte ainult Knative'i, vaid ka Microsoftiga koostöös loodud tööriistu, nagu Keda, et tuua Azure'i funktsioone OpenShifti platvormile.

Integreeritud OpenShift ServiceMesh (Istio, Kiali, Jaeger) lahendus on kasulik mikroteenuste arendamisel

Kuna pärandatud rakenduste ja konteinerite vahelise lõhe vähendamine, võimaldab OpenShift nüüd viia virtuaalmasinad OpenShift platvormile Container Native Virtualization'i abil (praegu TechPreview versioonis), muutes hübriidrakendused reaalsuseks ja lihtsustades nende liikumist erinevate pilvede vahel, nii privaatsete kui ka avalike.

Windows 2019 virtuaalmasin, mis töötab OpenShiftis Container Native Virtualization'i kaudu (praegu Tech Preview versioonis)

5. Tööriistad klastrite jaoks

Igal ettevõtteklassil platvormil peavad olema jälgimise ja keskse logimise teenused, turvamehhanismid, autentimine ja autoriseerimine ning võrgu haldamise vahendid. OpenShift pakub seda kõike standardlahendustena, olles 100% avatud koodiga, sealhulgas lahendusi nagu ElasticSearch, Prometheus ja Grafana. Kõik need lahendused tulevad koos informatiivsete paneelide, mõõdikute ja häiretega, mis on juba kokku pandud ja konfigureeritud, võttes arvesse Red Hati laialdast kogemust klastrite jälgimisel, võimaldades teie tootmiskeskkonna tõhusat jälgimist ja kontrollimist alates esimestest minutidest.

OpenShift sisaldab ettevõtetele olulisi funktsioone, nagu autentimine sisseehitatud oauth-teenusepakkuja kaudu, integreerimine identiteediteenusepakkujatega, sealhulgas LDAP, ActiveDirectory, OpenID Connect ja palju muud.

Eelseadistatud Grafana juhtpaneel OpenShift klastrite jälgimiseks

Rohkem kui 150 eelseadistatud Prometheuse mõõdikut ja teavitust OpenShift klastrite jälgimiseks

Jätkub

Rikka funktsionaalsuse ja Red Hati ulatusliku kogemuse tõttu Kuberneteses on OpenShift turul domineerival positsioonil, nagu näidatud alloleval joonisel (lisainfot siit).

„Praegu on Red Hat turul 44% osakaaluga liider.
Ettevõte korjab vilja oma müügistrateegia tulemustest, milles ta esmalt nõustab ja koolitab ettevõtte arendajaid ja seejärel liigub monetiseerimisele, kui ettevõte hakkab konteinerite tootmisse tooma.“

(Allikas: www.lightreading.com/nfv/containers/ihs-red-hat-container-strategy-is-paying-off/d/d-id/753863)

Loodame, et teile meeldis see artikkel. Järgmistes postitustes selles seerias vaatame lähemalt OpenShift’i eeliseid Kubernetes’e ees igas käsitletud kategoorias.

Allikas: habr.com