"Mis vahe on Kubernetesel ja OpenShiftil?" – kerkib see küsimus kadestamisväärse järjekindlusega. Kuigi tegelikult on see nagu küsimine, mille poolest erineb auto mootorist. Kui jätkata analoogiat, siis auto on valmistoode, seda saab kohe kasutada, sõna otseses mõttes: istu sisse ja lähe. Teisest küljest, et mootor sind kuhugi viiks, tuleb seda esmalt täiendada paljude muude asjadega, et lõpuks sama auto saada.
Seetõttu on Kubernetes mootor, mille ümber on kokku pandud OpenShifti kaubamärgi auto (platvorm), mis viib teid eesmärgini.
Selles artiklis tahame teile meelde tuletada ja veidi üksikasjalikumalt uurida järgmisi põhipunkte:
- Kubernetes on OpenShifti platvormi süda ja see on 100% sertifitseeritud Kubernetes, täiesti avatud lähtekoodiga ja ilma vähimagi omandiõiguseta. Lühidalt:
- OpenShifti klastri API on XNUMX% Kubernetes.
- Kui konteiner töötab mõnes muus Kubernetese süsteemis, töötab see OpenShiftis ilma muudatusteta. Rakendustes pole vaja muudatusi teha.
- OpenShift mitte ainult ei lisa Kubernetesile kasulikke funktsioone ja funktsioone. Nagu autogi, on OpenShift karbist väljas, selle saab kohe tootmisse panna ja, nagu allpool näitame, muudab see arendaja elu palju lihtsamaks. Seetõttu on OpenShift üks kahest inimesest. See on arendaja vaatenurgast nii edukas kui ka tuntud ettevõtteklassi PaaS platvorm. Ja samas on see tööstusliku käitamise seisukohalt üliusaldusväärne Container-as-a-Service lahendus.
OpenShift on 100% CNCF-sertifikaadiga Kubernetes
OpenShift põhineb . Seetõttu hämmastab kasutajad pärast korralikku väljaõpet kubectli võimsusest. Ja need, kes läksid Kubernetes Clusterilt OpenShiftile üle, ütlevad sageli, kui väga neile meeldib, et pärast kubeconfigi ümbersuunamist OpenShifti klastrisse töötavad kõik olemasolevad skriptid laitmatult.
Olete ilmselt kuulnud OpenShifti käsurea utiliidist nimega OC. See ühildub täielikult kubectliga käskudega, lisaks pakub see mitmeid kasulikke abilisi, mis on kasulikud mitmete ülesannete täitmisel. Kuid kõigepealt natuke rohkem OC ja kubectli ühilduvuse kohta:
kubectl käsud
OC meeskonnad
kubectl saada kaunad
oc saada kaunad
kubectl saada nimeruumid
oc hankige nimeruumid
kubectl create -f deployment.yaml
oc create -f deployment.yaml
Kubectli kasutamise tulemused OpenShift API-s näevad välja järgmised:
• kubectl get pods – tagastab kaunad ootuspäraselt.
• kubectl get namespaces – tagastab ootuspäraselt nimeruumid.
Käsk kubectl create -f mydeployment.yaml loob kubernetese ressursid nagu mis tahes muul Kubernetese platvormil, nagu on näidatud allolevas videos:
Teisisõnu, kõik Kubernetes API-d on OpenShiftis täielikult saadaval, säilitades samal ajal 100% ühilduvuse. Sellepärast .
OpenShift lisab Kubernetesile kasulikke funktsioone
Kubernetese API-d on OpenShiftis 100% saadaval, kuid tavalisel Kubernetese utiliidil kubectl puudub selgelt funktsionaalsus ja mugavus. Seetõttu on Red Hat lisanud Kubernetesisse kasulikke funktsioone ja käsureatööriistu, nagu OC (lühend OpenShift kliendist) ja ODO (OpenShift DO, see utiliit on suunatud arendajatele).
1. OC-utiliit - Kubectli võimsam ja mugavam versioon
Näiteks erinevalt kubectlist võimaldab see luua uusi nimeruume ja hõlpsalt kontekste vahetada ning pakub arendajatele ka mitmeid kasulikke käske, nagu konteinerpiltide loomine ja rakenduste juurutamine otse lähtekoodist või kahendfailidest (Source-to-image, s2i).
Vaatame näiteid selle kohta, kuidas OC utiliidi sisseehitatud abimehed ja täiustatud funktsionaalsus aitavad igapäevatööd lihtsustada.
Esimene näide on nimeruumi haldamine. Igal Kubernetese klastris on alati mitu nimeruumi. Neid kasutatakse tavaliselt arendus- ja tootmiskeskkondade loomiseks, kuid nende abil saab ka näiteks iga arendaja isikliku liivakasti kasutada. Praktikas toob see kaasa selle, et arendaja peab sageli nimeruume vahetama, kuna kubectl töötab praeguse ruumi kontekstis. Seetõttu kasutavad inimesed kubectli puhul selleks aktiivselt abiskripte. Kuid OC kasutamisel öelge soovitud ruumi lülitumiseks lihtsalt "oc projekti nimeruum".
Kas te ei mäleta, kuidas seda nimeruumi nimetatakse? Pole probleemi, täieliku loendi kuvamiseks tippige lihtsalt "oc get projects". Kas kahtlete, kuidas see toimib, kui teil on juurdepääs klastri nimeruumide piiratud alamhulgale? Noh, kuna kubectl teeb seda õigesti ainult siis, kui RBAC võimaldab teil näha klastri kõiki ruume ja suurtes klastrites ei anta kõigile selliseid õigusi. Seega vastame: OC jaoks pole see probleem ja sellises olukorras koostab see hõlpsasti täieliku loendi. Just need pisiasjad moodustavad Openshifti ettevõtte orientatsiooni ja selle platvormi hea skaleeritavuse kasutajate ja rakenduste osas
2. ODO – kubectli täiustatud versioon arendajatele
Veel üks näide Red Hat OpenShifti täiustustest Kubernetesiga võrreldes on ODO käsurea utiliit. See on mõeldud arendajatele ja võimaldab teil kiiresti juurutada kohalikku koodi OpenShifti kaugklastrisse. Samuti saab see sujuvamaks muuta sisemisi protsesse, et sünkroonida koheselt kõik koodimuudatused OpenShifti kaugklastri konteineritega, ilma et peaksite pilte uuesti koostama, registreerima ja ümber paigutama.
Vaatame, kuidas OC ja ODO muudavad konteinerite ja Kubernetesega töötamise lihtsamaks.
Võrrelge lihtsalt paari töövoogu, kui need on üles ehitatud kubectli baasil ja kui kasutatakse OC või ODO.
• Koodi juurutamine OpenShiftis neile, kes YAML-i ei räägi:
Kubernetes / kubectl
$>git kloon
1- Looge Dockeri fail, mis loob pildi koodist
-----
sõlmest
WORKDIR /usr/src/app
KOPIJA pakett*.json ./
KOPIJA index.js ./
KOPEERI ./rakendus ./rakendus
RUN npm install
KOKKUPUUDE 3000
CMD [ "npm", "start" ] ————–
2- Me loome pildi
$> podmani ehitamine...
3- Logige registrisse
podmani sisselogimine...
4- Asetage pilt registrisse
podmani lükkamine
5- Looge rakenduse juurutamiseks yaml-failid (deployment.yaml, service.yaml, ingress.yaml) – see on absoluutne miinimum
6- Manifestifailide juurutamine:
Kubectl rakendus -f .
OpenShift/oc
$> oc uus rakendus – meie_rakenduse_nimi
OpenShift/odo
$>git kloon
$> odo luua komponent nodejs myapp
$>odo push
• Kontekstilüliti: töö nimeruumi või tööklastri muutmine.
Kubernetes / kubectl
1- Looge kubeconfigis kontekst projektile "myproject"
2- kubectl komplekti kontekst…
OpenShift/oc
oc projekt "minuprojekt"
Kvaliteedikontroll: "Siia on ilmunud üks huvitav funktsioon, endiselt alfaversioonis. Äkki paneme selle tootmisse?”
Kujutage ette, kui istute võidusõiduautosse ja teile öeldakse: "Oleme paigaldanud uut tüüpi pidurid ja ausalt öeldes pole nende töökindlus veel korras... Aga ärge muretsege, me täiustame neid kursuse jooksul aktiivselt meistrivõistlustest." Kuidas teile see väljavaade meeldib? Meie Red Hatis pole millegipärast väga rahul. 🙂
Seetõttu püüame alfaversioonide puhul hoiduda seni, kuni need on piisavalt küpsed ja oleme läbinud põhjalikud lahingutestid ning tunneme, et neid on ohutu kasutada. Tavaliselt läbib kõik kõigepealt Dev Preview etapi ja seejärel läbi ja alles siis ilmub avaliku väljalasena (GA), mis on juba nii stabiilne, et sobib tootmiseks.
Miks nii? Sest nagu iga teise tarkvara arendamise puhul, ei jõua Kubernetese kõik esialgsed ideed lõpliku väljalaskeni. Või jõuavad nad selleni ja säilitavad isegi kavandatud funktsionaalsuse, kuid nende rakendamine erineb radikaalselt alfaversiooni omast. Kuna tuhanded ja tuhanded Red Hati kliendid kasutavad OpenShifti missioonikriitiliste töökoormuste toetamiseks, paneme erilist rõhku oma platvormi stabiilsusele ja pikaajalisele toele.
Red Hat on pühendunud OpenShifti sageli avaldamisele ja selle kaasasoleva Kubernetese versiooni värskendamisele. Näiteks OpenShift 4.3 praegune GA väljalase selle kirjutamise ajal sisaldab Kubernetes 1.16, mis jääb vaid ühe võrra alla Kubernetese ülesvoolu versioonile numbriga 1.17. Seega üritame OpenShifti uute versioonide väljalaskmisel pakkuda kliendile ettevõtlusklassi Kubernetes ja pakkuda täiendavat kvaliteedikontrolli.
Tarkvaraparandused: "Meil tootmises olevas Kubernetese versioonis oli auk. Ja saate selle sulgeda ainult kolme versiooni värskendamisega. Või on mingeid variante?
Kubernetese avatud lähtekoodiga projektis avaldatakse tarkvaraparandused tavaliselt järgmise väljalaske osana, mõnikord katavad need ühe või kaks eelmist verstapostiväljaannet, andes katvuse tagasi vaid 6 kuuks.
Red Hat on uhke selle üle, et avaldab kriitilised parandused teistest varem ja pakub tuge palju kauem. Võtke näiteks Kubernetese privileegide eskalatsiooni haavatavus (): see avastati Kubernetese versioonis 1.11 ja eelmiste väljaannete parandused avaldati ainult kuni versioonini 1.10.11, jättes selle auku kõigis varasemates Kubernetese versioonides 1.x kuni 1.9.
Omakorda (Kubernetes 1.2 on olemas), jäädvustades üheksa OpenShifti väljalaset ja demonstreerides selgelt klientide eest hoolitsemist (täpsemalt ).
Kuidas OpenShift ja Red Hat Kubernetes edasi viivad
Red Hat on avatud lähtekoodiga Kubernetese projekti suuruselt teine tarkvarapanustaja, jäädes alla ainult Google'ile, kusjuures kolm viiest kõige viljakamast arendajast on pärit Red Hatilt. Veel üks vähetuntud fakt: paljud kriitilised funktsioonid ilmusid Kubernetes täpselt Red Hati algatusel, näiteks:
- RBAC. Kubernetesil ei olnud RBAC-funktsioone (ClusterRole, ClusterRoleBinding), kuni Red Hati insenerid otsustasid need juurutada platvormi enda osana, mitte OpenShift lisafunktsioonina. Kas Red Hat kardab Kubernetest parandada? Muidugi mitte, sest Red Hat järgib rangelt avatud lähtekoodiga põhimõtteid ega mängi Open Core mänge. Täiustused ja uuendused, mida juhivad arenduskogukonnad, mitte patenteeritud, on elujõulisemad ja laiemalt kasutusele võetud, mis on hästi kooskõlas meie põhieesmärgiga muuta avatud lähtekoodiga tarkvara klientidele kasulikumaks.
- Podide turvapoliitikad (Pod Security Policies). See rakenduste turvalise töötamise kontseptsioon kaustades rakendati algselt OpenShiftis nime all SCC (turvakonteksti piirangud). Ja nagu eelmises näites, otsustas Red Hat need arendused tutvustada avatud Kubernetese projektis, et kõik saaksid neid kasutada.
Seda näidete seeriat võiks jätkata, kuid tahtsime lihtsalt näidata, et Red Hat on tõesti pühendunud Kubernetese arendamisele ja selle kõigi jaoks paremaks muutmisele.
On selge, et OpenShift on Kubernetes. Millised on erinevused? 🙂
Loodame, et seni lugedes olete aru saanud, et Kubernetes on OpenShifti põhikomponent. Peamine, kuid kaugeltki mitte ainus. Teisisõnu, lihtsalt Kubernetese installimine ei anna teile ettevõtteklassi platvormi. Peate lisama autentimise, võrgu, turvalisuse, jälgimise, logihalduse ja palju muud. Lisaks peate suure hulga saadaolevate tööriistade hulgast tegema raskeid valikuid (ökosüsteemi mitmekesisuse hindamiseks vaadake lihtsalt ) ning tagavad kuidagi järjepidevuse ja sidususe, et need toimiksid ühtsena. Lisaks peate regulaarselt läbi viima värskendusi ja regressiooniteste alati, kui mis tahes kasutatava komponendi uus versioon avaldatakse. See tähendab, et lisaks platvormi enda loomisele ja hooldamisele peate tegelema ka kogu selle tarkvaraga. On ebatõenäoline, et äriprobleemide lahendamiseks ja konkurentsieeliste saavutamiseks jääb palju aega.
Kuid OpenShifti puhul võtab Red Hat kõik need keerukused enda peale ja annab teile lihtsalt funktsionaalselt tervikliku platvormi, mis ei sisalda mitte ainult Kubernetesi ennast, vaid ka kõiki vajalikke avatud lähtekoodiga tööriistu, mis muudavad Kubernetese tõeliseks ettevõtteklassiks. lahendus, mille saad kohe ja täiesti rahulikult tootmisse käivitada. Ja muidugi, kui teil on oma tehnoloogiavirnad, saate OpenShifti integreerida olemasolevatesse lahendustesse.
Heitke pilk ülalolevale pildile: kõik, mis jääb Kubernetese ristkülikust välja, on see, kuhu Red Hat lisab funktsionaalsust, mida Kubernetesel pole, nagu öeldakse, kaaskujundus. Ja nüüd vaatleme nende valdkondade peamisi.
1. Tugev OS baasina: RHEL CoreOS või RHEL
Red Hat on olnud juhtiv Linuxi distributsioonide pakkuja ärikriitiliste rakenduste jaoks enam kui 20 aastat. Meie kogutud ja pidevalt uuenev kogemus selles valdkonnas võimaldab meil pakkuda tõeliselt usaldusväärset alust konteinerite tööstuslikuks käitamiseks. RHEL CoreOS kasutab sama tuuma mis RHEL, kuid on optimeeritud peamiselt selliste ülesannete jaoks nagu konteinerite käitamine ja Kubernetese klastrite käitamine: selle vähendatud suurus ja muutumatus muudavad klastrite seadistamise, automaatse skaleerimise, paikade juurutamise jne lihtsamaks. Kõik need funktsioonid muudavad selle lihtsamaks. ideaalne alus OpenShiftiga sama kasutajakogemuse pakkumiseks paljudes arvutuskeskkondades, alates metallist kuni privaatse ja avaliku pilveni.
2. IT toimingute automatiseerimine
Installimisprotsesside ja 4. päeva toimingute (st igapäevaste toimingute) automatiseerimine on OpenShifti tugevaim külg, mis muudab konteineriplatvormi haldamise, värskendamise ja jõudluse kõrgeimal tasemel hoidmise palju lihtsamaks. See saavutatakse Kubernetese operaatorite toetamise kaudu OpenShift XNUMX kerneli tasemel.
OpenShift 4 on ka terve Kubernetese operaatoritel põhinevate lahenduste ökosüsteem, mille on välja töötanud nii Red Hat ise kui ka kolmandatest osapooltest partnerid (vt. Red Hat ehk operaatoripood , mille on loonud Red Hat kolmandate osapoolte arendajatele).
Integreeritud OpenShift 4 kataloog sisaldab enam kui 180 Kubernetese operaatorit
3. Arendaja tööriistad
Alates 2011. aastast on OpenShift saadaval PaaS-i (Platform-as-a-Service) platvormina, mis muudab arendajate elu palju lihtsamaks, aitab neil keskenduda kodeerimisele ja pakub programmeerimiskeelte (nt Java, Node.js) natiivset tuge. , PHP, Ruby, Python, Go, samuti CI/CD pidev integreerimine ja edastamise teenused, andmebaasid jne. OpenShift 4 pakub , mis sisaldab enam kui 100 teenust, mis põhinevad Red Hati ja meie partnerite välja töötatud Kubernetese operaatoritel.
Erinevalt Kubernetesest on OpenShift 4-l spetsiaalne GUI (), mis aitab arendajatel hõlpsalt juurutada erinevatest allikatest (git, välised registrid, Dockerfile jne) pärit rakendusi oma nimeruumidesse ja visualiseerib selgelt rakenduse komponentide vahelisi seoseid.
Lisaks pakub OpenShift Codeready arendustööriistade komplekti, mis sisaldab eelkõige , täielikult konteineriseeritud IDE koos veebiliidesega, mis töötab otse OpenShifti peal ja rakendab IDE-teenusena lähenemisviisi. Teisest küljest, neile, kes soovivad töötada rangelt kohalikus režiimis, on olemas Codeready Containers, OpenShift 4 täisfunktsionaalne versioon, mida saab sülearvutis juurutada.
Integreeritud IDE kui teenus tõhusaks arendamiseks Kubernetes/OpenShift platvormil
OpenShift pakub karbist välja võttes täielikku CI/CD-süsteemi, mis põhineb kas konteineris Jenkinsil ja pistikprogrammil torujuhtmetega töötamiseks või Kubernetesele orienteeritud CI/CD süsteemiga (praegu tehnilises eelvaateversioonis). Mõlemad lahendused integreeruvad täielikult OpenShift-konsooliga, võimaldades teil käivitada konveieri käivitajaid, vaadata juurutusi, logisid ja palju muud.
4. Rakendustööriistad
OpenShift võimaldab juurutada nii traditsioonilisi olekupõhiseid rakendusi kui ka pilvepõhiseid lahendusi, mis põhinevad uutel arhitektuuridel, nagu mikroteenused või serverita. OpenShift Service Mesh lahendus tuleb kohe karbist välja koos võtmetööriistadega mikroteenuste hooldamiseks, nagu Istio, Kiali ja Jaeger. OpenShift Serverless lahendus ei sisalda omakorda mitte ainult Knative'i, vaid ka selliseid tööriistu nagu Keda, mis on loodud Microsoftiga ühise algatuse raames, et pakkuda OpenShifti platvormil Azure'i funktsioone.
Integreeritud lahendus OpenShift ServiceMesh (Istio, Kiali, Jaeger) tuleb kasuks mikroteenuste arendamisel
Pärandrakenduste ja konteinerite vahelise lõhe ületamiseks võimaldab OpenShift nüüd virtuaalmasina migratsiooni OpenShifti platvormile, kasutades Container Native Virtualizationit (praegu TechPreviews), muutes hübriidrakendused reaalsuseks ja hõlbustades nende migratsiooni erinevate privaatsete ja avalike pilvede vahel.
Windows 2019 virtuaalne virtuaalmasin, mis töötab OpenShiftis konteineri natiivse virtualiseerimise kaudu (praegu tehnilises eelvaate versioonis)
5. Tööriistad klastrite jaoks
Igal ettevõtteklassi platvormil peavad olema seire- ja tsentraliseeritud logiteenused, turvamehhanismid, autentimine ja autoriseerimine ning võrguhaldustööriistad. Ja OpenShift pakub kõike seda juba karbist välja ja see kõik on 100% avatud lähtekoodiga, sealhulgas sellised lahendused nagu ElasticSearch, Prometheus, Grafana. Kõik need lahendused on varustatud armatuurlaudade, mõõdikute ja hoiatustega, mis on juba ehitatud ja konfigureeritud, kasutades Red Hati laialdast klastri jälgimise asjatundlikkust, võimaldades teil kohe algusest peale tõhusalt kontrollida ja jälgida oma tootmiskeskkonda.
OpenShift on standardvarustuses ka äriklientide jaoks oluliste asjadega, nagu autentimine sisseehitatud oauth-pakkujaga, integreerimine mandaadi pakkujatega, sealhulgas LDAP, ActiveDirectory, OpenID Connect ja palju muud.
Eelkonfigureeritud Grafana armatuurlaud OpenShifti klastri jälgimiseks
Üle 150 eelkonfigureeritud Prometheuse mõõdiku ja hoiatuse OpenShifti klastri jälgimiseks
Et jätkata
Lahenduse rikkalik funktsionaalsus ja Red Hati laialdased kogemused Kubernetese vallas on põhjused, miks OpenShift on saavutanud turul domineeriva positsiooni, nagu on näha alloleval joonisel (loe edasi ).
„Red Hat juhib praegu turgu 44% osalusega.
Ettevõte lõikab kasu oma kliendikesksest müügistrateegiast, kus ta kõigepealt konsulteerib ja koolitab ettevõtete arendajaid ning seejärel läheb üle raha teenimisele, kui ettevõte hakkab konteinereid tootmisse juurutama.
(Allikas: )
Loodame, et teile meeldis see artikkel. Selle seeria tulevastes postitustes vaatleme lähemalt OpenShifti eeliseid Kubernetese ees kõigis siin käsitletud kategooriates.
Allikas: www.habr.com