OpenShift kui ettevõtte versioon Kubernetesest. Osa 1

«Mis on erinevus Kubernetes'i ja OpenShift'i vahel?» – see küsimus tõuseb pidevalt esile. Kuigi tegelikult on see nagu küsida, kuidas auto erineb mootorist. Kui jätkata analoogiat, siis auto on valmis toode, mida saab kohe kasutada: istud sisse ja sõidad. Teisest küljest, et mootor sind kuhugi vedada, peab selle juurde lisama palju teisi asju, et lõpuks saada sama auto.

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

Selles artiklis tahame meenutada ja veidi detailsemalt arutada järgmisi põhikohti:

• Kubernetes on OpenShift'i süda. Ja see on 100% sertifitseeritud Kubernetes, täiesti avatud koodiga ja ilma igasuguse omandiõiguse. Kokkuvõtlikult:
  • OpenShift'i klasteri API on 100% Kubernetes.
  • Kui konteiner töötab mõnes muus Kubernetes'i süsteemis, töötab ta ilma muudatusteta ka OpenShift'is. Rakendustes ei ole vaja muudatusi teha.
• OpenShift mitte ainult ei täiusta Kubernetes'e kasulike funktsioonide ja võimalustega. Nagu auto, on OpenShift kohe kasutusvalmis, seda võib koheselt tootmisse viia ja, nagu me allpool näitame, teeb see arendajate elu oluliselt lihtsamaks. Just seetõttu on OpenShift kahel kujul. See on edukas ja laialdaselt tuntud PaaS-platvorm ettevõtte tasemel, kui vaadata arendaja seisukohalt. Ja samal ajal on see äärmiselt usaldusväärne Container-as-a-Service lahendus industriaalsete operatsioonide seisukohalt.

OpenShift on Kubernetes, millel on 100% sertifitseerimine CNCF fondivaldkonnast.

OpenShift'i aluseks on sertifitseeritud Kubernetes.. Seetõttu pärast sobivat koolitust imetlevad kasutajad kubectl'i võimet. Ja need, kes on Kubernetes'i klastrist OpenShift'ile üle läinud, räägivad sageli, kui väga neile meeldib, et pärast kubeconfig'i suunamist OpenShift'i klastrile töötavad kõik olemasolevad skriptid laitmatult.

Sa oled tõenäoliselt kuulnud OpenShift'i käsurea tööriistast nimega OC. See on täielikult kooskõlas käsudega kubectl, pluss pakub mitmeid kasulikke abivahendeid, mis tulevad kasuks paljude ülesannete täitmisel. Kuid kõigepealt veidi rohkem OC ja kubectl ühilduvusest:

kubectl käsud
OC käsud

kubectl get pods
oc get pods

kubectl get namespaces
oc get namespaces

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

Nii näevad välja kubectl'i tulemused OpenShift API-s:

• kubectl get pods – täiesti arusaadavalt toob tagasi pod'id.

• kubectl get namespaces – täiesti arusaadavalt toob tagasi nimealad.

Käsk kubectl create -f mydeployment.yaml loob Kubernetes ressursse samamoodi nagu kõikidel teistel Kubernetes platvormidel, nagu on näidatud allolevas videos:

Teisisõnu, kõik Kubernetesi API-d on OpenShiftis täielikult kergesti ligipääsetavad ja 100% ühilduvad. Just seetõttu OpenShift on tunnustatud Cloud Native Computing Foundation (CNCF) poolt sertifitseeritud Kubernetes platvormina.. 

OpenShift täiendab Kubernetes'e kasulike funktsioonidega.

Kubernetesi API-d on OpenShiftis 100% kergesti ligipääsetavad, kuid tavapäraste Kubernetes'e tööriistade hulgas on kubectl'il selgelt puudu funktsionaalsusest ja mugavusest. Seetõttu on Red Hat lisanud Kubernetes'ele kasulikke funktsioone ja käsurea tööriistu, nagu OC (OpenShift cli lühend) ja ODO (OpenShift DO, see tööriist on suunatud arendajatele).

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

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

Vaatame näidete abil, kuidas OC tööriista sissetegemist ja laiendatud funktsionaalsust aitab lihtsustada igapäevast tööd.

Esimene näide – nimealade haldamine. Igasse Kubernetes klastri kuulub alati mitu nimeala. Tüüpiliselt kasutatakse neid arendus- ja tootmiskeskkondade loomiseks, kuid neid võib kasutada ka näiteks iga arendaja isikliku „liivakasti“ esitamiseks. Praktikas tähendab see, et arendajal tuleb sageli nimealade vahel lülituda, kuna kubectl töötab praeguse nimeala kontekstis. Seetõttu kasutatakse kubectl'i puhul selleks aktiivselt helper-skripte. Kuid OC kasutamisel piisab lülitumiseks soovitud nimealale käskimisest "oc project nimeala".

Ei mäleta, kuidas vajalik nimeala nimetatakse? Pole probleemi, lihtsalt tippige "oc get projects", et kuvada täielik nimekirja. Skeptiliselt küsite, kuidas see töötab, kui teil on juurdepääs vaid piiratud alameetodite kogumile klastris? Kuidas arutada, sest kubectl teeb seda õigesti ainult siis, kui RBAC lubab teil näha kõiki nimealasid klastris, ja suurtes klastrites ei anta selliseid õigusi kõigile. Aga vastame: OC jaoks pole see üldse probleem ja see annab sellises olukorras teabe, mis on täiskohaga. Sellest tulenevad pisiasjad kujundavad korporatiivset orienteeritust Openshiftis ja selle platvormi head skaleeritavust kasutajate ja rakenduste suhtes.

2. ODO – parendatud versioon kubectl-st arendajatele.

Veel üheks näiteks Red Hat OpenShift'i parendustest Kubernetes'i võrreldes on käsurea utiliidi ODO. See on mõeldud arendajatele ja võimaldab kiiresti paigaldada kohaliku koodi kaugklastrisse OpenShift. Lisaks saab seda kasutada siseprotsesside optimeerimiseks, et koheselt sünkroonida kõik koodi muudatused kaugläbivaatuse konteinerite vahel OpenShiftis ilma, et oleks vaja uuesti koostada, registreerida ja uuesti jagada pilte.

Vaatame, kuidas OC ja ODO lihtsustavad töötamist konteinerite ja Kubernetesega.

Lihtsalt võrdleme paar tööprotsessi, kui need põhinevad kubectl-l ja kui kasutatakse OC-d või ODO-d.

• Koodi paigaldamine OpenShiftile neile, kes ei valda YAML-i keelt:

Kubernetes / kubectl
$> git clone github.com/sclorg/nodejs-ex.git
1- Loome Dockerfile, mis koostab 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- Koostame pildi.
$> podman build …
3- Sisselogimine registrisse.
podman login …
4- Paigaldame pildi registrisse.
podman push
5- Loome yaml-failid rakenduse paigaldamiseks (deployment.yaml, service.yaml, ingress.yaml) – see on absoluutne miinimum.
6- Paigaldame 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 nimeala või klastrivahetus.

Kubernetes / kubectl
1- Loome kontakti kubeconfigis projekti "myproject" jaoks.
2- kubectl set-context …

OpenShift / oc
oc project "myproject"

Kvaliteedikontroll: „Siia tuli üks huvitav funktsioon, hetkel alfade versioonis. Kas me toome selle tootmisse?“

Kujutage ette, et teid istutatakse võidusõidumasinasse ja öeldakse: „Me oleme siia pannud uue tüübi pidurid ja ausalt öeldes pole neil veel usaldusväärsusega kõik korras ... Aga ära muretse, me jätkame nende arendamist kogu meistrivõistluste ajal.“ Kuidas selline perspektiiv tundub? Meie Red Hat's ei ole see just väga meeldiv. 🙂

Seetõttu üritame enne piisavalt küpsete versioonide väljaandmist hoiduda alfa-versioonidest, kuni oleme läbi viinud põhjalikud testimised ja tunne, et neid saab ohutult kasutada. Tavaliselt läbib kõik esmalt Dev Preview etapi, seejärel Tech Preview ja alles seejärel ilmub see üldise kergenduse vormis Üldine kergendus (GA), mis on piisavalt stabiilne, et sobida tootmisellu.

Miks nii? Sest nagu iga muu tarkvara arendamisel, ei jõua kõik algsed ideed Kuberneteses lõplikku väljaandesse. Või võivad nad sinna jõuda ja isegi säilitada ette nähtud funktsionaalsuse, kuid nende rakendamine erineb kardinaalselt sellest, mis oli alfa-versioonis. Kuna tuhanded ja tuhanded Red Hati kliendid kasutavad OpenShift'i kriitiliste ülesannete toetamiseks, keskendume oma platvormi stabiilsusele ja pikaajalisele toetusele eriliselt.

Red Hat väljastab sihipäraselt sagedasi OpenShift'i versioone ja uuendab selle koosseisu kuuluva Kubernetes versiooni. Näiteks on käesolevas artiklis kirjutamise hetkel GA-väljalase OpenShift 4.3 integreeritud Kubernetes 1.16, mis jääb ainult ühe ülesvoolu versiooni numbrist 1.17. Seega püüame pakkuda klientidele ettevõtte tasemel Kubernetes'i ja tagada lisakvaliteedikontrolli uute OpenShift'i versioonide väljalaskeprotsessis.

Tarkvaraparandused: „Käesolevas Kubernetes'i versioonis, mis meil tootmises on, leiti nõrk koht. Ja selle sulgemiseks on vajalik uuendada kolme versiooni võrra ülespoole. Või on muid variante?”

Avatud Kubernetes projektis antakse tarkvaraparandused tavaliselt järgmise väljaande koosseisus välja, mõnikord hõlmavad need ühte või kahte eelmist vaheversiooni, mis katab kokku kuue kuu taguseid probleeme.

Red Hat on õigustatult uhke, et toob kriitilised parandusettepanekud turule varem kui teised ning tagab toetuse palju pikemaks ajaks. Näiteks, võtame Kubernetes'e privileegide eskaleerimise haavatavuse (CVE-2018-1002105): see avastati Kubernetes 1.11 versioonis, kuid parandus eelnevate väljalasete jaoks ilmus ainult versioonis 1.10.11, jättes selle haavatavuse kõikidesse varasematesse Kubernetes'e versioonidesse, alates 1.x kuni 1.9.

Oma kord, Red Hat on patcheerinud OpenShift'i kuni versioonini 3.2 (seal on Kubernetes 1.2), katab see üheksa OpenShift'i versiooni ja näitab selgelt hoolivust oma klientide vastu (rohkem teavet siin).

Kuidas OpenShift ja Red Hat edendavad Kubernetes'e

Red Hat on teisel kohal programmi Kubernetes avatud projekti panuses, jäädes sellega alla ainult Google'ile; 3 viiest tootlikumast arendajast on Red Hat'i töötajad. Veel üks vähe tuntud fakt: paljud kriitilise tähtsusega funktsioonid on ilmnenud Kubernetes'es just Red Hat'i algatusel, sealhulgas sellised, nagu:

• RBAC. Kubernetes'es puudusid RBAC funktsioonid (ClusterRole, ClusterRoleBinding) seni, kuni Red Hat'i insenerid otsustasid need rakendada platvormi osana, mitte kui täiendav OpenShift'i funktsionaalsus. Kas Red Hat kardab Kubernetes'e täiustamist? Loomulikult mitte, kuna Red Hat järgib rangelt avatud koodi põhimõtteid ning ei mängi Open Core mänge. Parandused ja uuendused, mis teostatakse arendustegevuse kogukonna tasandil, mitte omandiõiguse alusel, muutuvad elujõulisemaks ja levivad laiemalt, mis kooskõlas meie peamise eesmärgiga – teha avatud koodiga tarkvara meie klientidele veelgi kasulikumaks.
• Pod'ide turvapoliitikad (Pod Security Policies). Alguses rakendati see rakenduste turvalist käitamise kontseptsioon pod'ides OpenShift'is nimega SCC (Security Context Constraints). Ja nagu eelmise näite puhul, otsustas Red Hat need arendused tuua avatud projekti Kubernetes'i, et igaühel oleks võimalik neid kasutada.

Seda rida näiteid võiks jätkata, kuid tahtsime lihtsalt näidata, et Red Hat tõeliselt püüab arendada Kubernetes'e ja teha seda paremaks kõigile.

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

Loodame, et olete jõudnud siia, et mõista, et Kubernetes on OpenShifti peamine komponent. Peamine, kuid kaugeltki mitte ainus. Teisisõnu, lihtsalt Kubernetes'e installimine ei anna teile ettevõtte klassi platvormi. Peate lisama autentimise, võrgu, turvalisuse, monitooringu, logihalduse ja palju muud. Lisaks on teil keeruline valida paljude saadaval olevate tööriistade hulgast (et hinnata ökosüsteemi mitmekesisust, vaadake lihtsalt CNCF diagrammi) ja tagama, et need kõik töötaksid ühtselt ja kooskõlastatult. Lisaks peate regulaarselt teostama uuendusi ja regressioonitestimist iga kord, kui mõni kasutatav komponent uuendatakse. See tähendab, et lisaks platvormi loomisele ja hooldamisele peate tegelema ka kogu selle tarkvaraga. Tõenäoliselt jääb vähe aega äritegevuse probleemide lahendamiseks ja konkurentsieeliste saavutamiseks.

Kuid OpenShift'i puhul võtab Red Hat kõik need keerukused enda kanda ja pakub teile lihtsalt funktsionaalselt lõpetatud platvormi, kuhu kuulub mitte ainult Kubernetes, vaid ka kõik vajalikud avatud lähtekoodiga tööriistad, mis muudavad Kubernetes'e tõeliseks ettevõtte klassi lahenduseks, mida saab kohe ja muretult tootmisesse viia. Muidugi, kui teil on oma tehnolooge, saate OpenShift'i integreerida juba olemasolevatesse lahendustesse.

OpenShift on nutikas Kubernetes platvorm

Vaadake ülaltoodud joonist: kõik, mis jääb Kubernetes'e ristkülikust väljapoole, on need valdkonnad, kus Red Hat lisab funktsionaalsust, mida Kubernetes' ei paku, nagu on ette nähtud. Ja nüüd vaatleme neist peamisi valdkondi.

1. Usaldusväärne OS alusena: RHEL CoreOS või RHEL

Red Hat on juba üle 20 aasta olnud juhtiv Linuxi distributsioonide pakkuja kriitiliselt oluliste äpirakenduste jaoks. Meie valdkonnas omandatud ja pidevalt uuendatud kogemus võimaldab meil pakkuda tõeliselt usaldusväärset ja usaldusväärset alust konteinerite tööstuslikuks kasutamiseks. RHEL CoreOS kasutab sama tuuma kui RHEL, kuid on optimeeritud peamiselt selliste ülesannete jaoks nagu konteinerite käitamine ja Kubernetes klastrites töötamine: selle vähendatud suurus ja muutumatuse (immutability) omadus lihtsustab klastrite seadistamist, automaatset skaleerimist, patch’ide juurutamist jne. Kõik need funktsioonid muudavad selle ideaalseks aluseks sama kasutajakogemuse saavutamiseks OpenShift’is erinevates arvutuskeskkondades alates „paljast riistvarast” kuni privaatsete ja avalike pilvedeni.

2. IT-operations automatiseerimine

Paigaldamise ja teise päeva operatsioonide (st igapäevase töö) automatiseerimine on OpenShift'i tugevus, mis oluliselt lihtsustab konteineriplatvormi haldamist, uuendamist ja töökindluse säilitamist kõrgel tasemel. See saavutatakse Kubernetes'i operaatorite tuumast OpenShift 4 tasemel toe kaudu.

OpenShift 4 on ka terve ökosüsteem lahendusi, mis põhinevad Kubernetes'i operaatoritel, mis on loodud nii Red Hati kui ka kolmandate osapoolte partnerite poolt (vt. operaatorite kataloog Red Hat, või operaatorite pood operatorhub.io, mille on loonud Red Hat kolmandate arendajate jaoks).

Integreeritud OpenShift 4 kataloog sisaldab rohkem kui 180 Kubernetes'i operaatorit

3. Arendajatele mõeldud tööriistad

Alates 2011. aastast on OpenShift saadaval PaaS (Platform-as-a-Service) platvormina, mis oluliselt lihtsustab arendajate elu, aitab neil keskenduda koodi kirjutamisele ja pakub sisse ehitatud tuge sellistele programmeerimiskeeltele nagu Java, Node.js, PHP, Ruby, Python, Go, samuti pideva integreerimise ja kohaletoimetamise CI/CD teenuseid, andmebaase jne. OpenShift 4 pakub ulatuslikku katalooge, mis sisaldab rohkem kui 100 teenust, mis põhinevad Red Hati ja meie partnerite loodud Kubernetes'i operaatoritel.

Erinevalt Kubernetes'est on OpenShift 4-l spetsiaalne graafiline liides (Arendaja konsool), mis aitab arendajatel ilma liialduste ja vaevata juurutada oma nimede ruumidesse rakendusi erinevatest allikatest (git, välistest registritest, Dockerfile jne) ning selgelt visualiseerida seoseid rakenduse komponentide vahel.

Developer Console toob selgelt välja rakenduse komponendid ja lihtsustab töö tegemist Kubernetesega.

Lisaks pakub OpenShift arendustööriistade komplekti Codeready, kuhu kuuluvad muu hulgas. Codeready Workspaces, täielikult konteineriseeritud IDE veebiliidese abil, mis töötab otse OpenShifti peal ja rakendab „IDE kui teenus“ lähenemist. Teisest küljest, neile, kes soovivad töötada rangelt lokaalses režiimis, on saadaval Codeready Containers – täielik versioon OpenShift 4, mida saab juurutada sülearvutisse.

Integreeritud „IDE kui teenus“ tõhusaks arendamiseks Kubernetes/OpenShift platvormil.

OpenShift pakub koheselt täisfunktsionaalset CI/CD süsteemi, kas konteineriseeritud Jenkins põhjal ja pluginaga. DSL torude tööks, või Kubernetes põhine CI/CD süsteem. Tekton (hetkel Tech preview versioonis). Need lahendused on täielikult integreeritud OpenShifti konsooliga, võimaldades käivitada konveierite trikke, vaadata juurutamisi, logisid jne.

4. Rakenduste tööriistad

OpenShift võimaldab juurutada nii traditsioonilisi stateful-rakendusi kui ka pilvepõhiseid lahendusi uute arhitektuuride, näiteks mikroteenuste või serverivaba süsteemi põhjal. OpenShift Service Mesh lahendus toob otse välja kõik mikroteenuste toetamiseks vajalikud tööriistad, nagu Istio, Kiali ja Jaeger. Omakorda OpenShift Serverless lahendus hõlmab mitte ainult Knative'id, vaid ka Microsofti koostöö raames loodud tööriistu, nagu Keda, et tuua Azure'i funktsioone OpenShift platvormile.

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

Kuna pärandi rakenduste ja konteinerite vaheline lõhe tuleb vähendada, võimaldab OpenShift nüüd migreerida virtuaalmasinad OpenShift platvormile Container Native Virtualization abil (hetkel TechPreview versioonis), muutes hübriidrakendused reaalsuseks ja hõlbustades nende liikumist erinevate, nii erasektori kui avalike, pilvede vahel.

Windows 2019 Virtual virtuaalmasin, mis töötab OpenShiftis Container Native Virtualization abil (hetkel Tech preview versioonis).

5. Klastri tööriistad

Igal ettevõttel, millel on ettevõtte tasemel platvorm, peavad olema jälgimis- ja tsentraliseeritud logimisfunktsioonid, turvamehhanismid, autentimine ja autoriseerimine, samuti võrguhalduse vahendid. OpenShift pakub kõike seda välja kujundatud kujul, olles 100% avatud lähtekoodiga, sealhulgas lahendusi nagu ElasticSearch, Prometheus, Grafana. Kõik need lahendused tulevad koos teabehalduspaneelide, mõõdikute ja häalertingidega, mis on juba kokku pandud ja seadistatud Red Hati laialdase kogemuse põhjal klastrite jälgimisel, võimaldades tõhusalt jälgida ja hallata teie tootmiskeskkonda esimestest minutidest alates.

OpenShift omab ka selliseid olulisi ettevõtte kliendi jaoks vajalikke funktsioone nagu sisseehitatud oauth autentimine ja integreerimine autentimisteenuse pakkujatega, sealhulgas LDAP, ActiveDirectory, OpenID Connect ja palju muud.

Eelnevalt seadistatud Grafana teabehalduspaneel OpenShift klastrite jälgimiseks

Rohkem kui 150 eelnevalt seadistatud Prometheuse mõõdikut ja häalertingit OpenShift klastrite jälgimiseks

Jätkub

Lahenduse rikkalik funktsionaalsus ja Red Hati ulatuslik kogemus Kuberneteses – need on peamised põhjused, miks OpenShift on saavutanud turul domineeriva positsiooni, nagu on näidatud alloleval joonisel (lisainfot siin).

„Hetkel on Red Hat turuliider 44% turuosaga.
Ettevõte kogub saaki oma müügistrateegiast, mis hõlmab aktiivset osalemist kliendi asjades, kus nad alguses nõustavad ja koolitavad ettevõtte arendajaid ning seejärel liiguvad monetiseerimise suunas, kui ettevõte hakkab konteinerite kasutusele võtma tootmises.“

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

Loodame, et teile meeldis see artikkel. Kätketes postitustes arutame täpsemalt OpenShifti eeliseid võrreldes Kubernetesega kõigis siin käsitletud kategooriates.

Allikas: habr.com