"Kio estas la diferenco inter Kubernetes kaj OpenShift?" – ĉi tiu demando aperas kun enviinda konsekvenco. Kvankam fakte tio estas kiel demandi kiel aŭto diferencas de motoro. Se ni daŭrigas la analogion, tiam aŭto estas preta produkto, vi povas uzi ĝin tuj, laŭvorte: eniru kaj iru. Aliflanke, por ke motoro konduku vin ien, ĝi unue devas esti kompletigita per multaj aliaj aferoj por finfine akiri la saman aŭton.
Tial, Kubernetes estas la motoro ĉirkaŭ kiu la OpenShift-marka aŭto (platformo) estas kunvenita, kiu kondukas vin al via celo.
En ĉi tiu artikolo ni volas memorigi vin kaj ekzameni la sekvajn ŝlosilajn punktojn iom pli detale:
- Kubernetes estas la koro de la platformo OpenShift kaj ĝi estas 100% atestita Kubernetes, tute malferma fonto kaj sen la plej eta propra naturo. Mallonge:
- La OpenShift-cluster API estas XNUMX% Kubernetes.
- Se la ujo funkcias per iu ajn alia sistemo de Kubernetes, tiam ĝi funkcios per OpenShift sen ŝanĝoj. Ne necesas fari ŝanĝojn al la aplikaĵoj.
- OpenShift ne nur aldonas utilajn funkciojn kaj funkciojn al Kubernetes. Kiel aŭtomobilo, OpenShift estas el la skatolo, povas esti produktata tuj kaj, kiel ni montros ĉi-sube, multe plifaciligas la vivon de programisto. Tial OpenShift estas unuigita en du personoj. Ĝi estas kaj sukcesa kaj konata entreprena klaso PaaS-platformo el la perspektivo de programisto. Kaj samtempe, ĝi estas superfidinda solvo de Container-as-a-Service el la vidpunkto de industria operacio.
OpenShift estas Kubernetes kun 100% CNCF-atestilo
OpenShift baziĝas sur . Tial, post taŭga trejnado, uzantoj estas mirigitaj de la potenco de kubectl. Kaj tiuj, kiuj ŝanĝis al OpenShift de Kubernetes Cluster, ofte diras kiom ili vere ŝatas tion post alidirektado de kubeconfig al la OpenShift-grupo, ĉiuj ekzistantaj skriptoj funkcias perfekte.
Vi verŝajne aŭdis pri la komandlinia ilo de OpenShift nomata OC. Ĝi estas plene komanda kongrua kun kubectl, krome ĝi ofertas plurajn utilajn helpantojn, kiuj estos utilaj dum la plenumado de kelkaj taskoj. Sed unue, iom pli pri la kongruo de OC kaj kubectl:
kubectl komandoj
OC Teamoj
kubectl akiri podojn
oc akiri podojn
kubectl ricevas nomspacojn
oc akiri nomspacojn
kubectl krei -f deployment.yaml
oc krei -f deployment.yaml
Jen kiel aspektas la rezultoj de uzado de kubectl sur la OpenShift API:
• kubectl get pods – resendas podojn kiel atendite.
• kubectl get namespaces – resendas nomspacojn kiel atendite.
La komando kubectl create -f mydeployment.yaml kreas kubernetes-resursojn same kiel en iu ajn alia Kubernetes-platformo, kiel montrite en la suba video:
Alivorte, ĉiuj Kubernetes API-oj estas plene haveblaj en OpenShift konservante 100% kongruon. Tial .
OpenShift aldonas utilajn funkciojn al Kubernetes
Kubernetes API-oj estas 100% haveblaj en OpenShift, sed la norma Kubernetes-utilo kubectl klare mankas funkcieco kaj oportuno. Tial Red Hat aldonis utilajn funkciojn kaj komandliniajn ilojn al Kubernetes, kiel OC (mallongigo de OpenShift-kliento) kaj ODO (OpenShift DO, ĉi tiu utileco estas celita al programistoj).
1. OC-utilo - pli potenca kaj oportuna versio de Kubectl
Ekzemple, male al kubectl, ĝi ebligas al vi krei novajn nomspacojn kaj facile ŝanĝi kuntekstojn, kaj ankaŭ ofertas kelkajn utilajn komandojn por programistoj, kiel konstrui ujajn bildojn kaj deploji aplikaĵojn rekte de fontkodo aŭ binaroj (Fonto-al-bildo, s2i).
Ni rigardu ekzemplojn pri kiel la enkonstruitaj helpantoj kaj altnivela funkcieco de la OC-utilo helpas simpligi ĉiutagan laboron.
La unua ekzemplo estas administrado de nomspaco. Ĉiu Kubernetes-areto ĉiam havas plurajn nomspacojn. Ili estas kutime uzataj por krei evoluajn kaj produktadajn mediojn, sed ankaŭ povas esti uzataj por, ekzemple, provizi al ĉiu programisto personan sablokeston. En praktiko, tio rezultigas, ke la programisto devas ofte ŝanĝi inter nomspacoj, ĉar kubectl funkcias en la kunteksto de la nuna spaco. Tial, en la kazo de kubectl, homoj aktive uzas helpajn skriptojn por ĉi tio. Sed kiam vi uzas OC, por ŝanĝi al la dezirata spaco, simple diru "oc-projekta nomspaco".
Ĉu vi ne memoras kiel nomiĝas la nomspaco, kiun vi bezonas? Neniu problemo, simple tajpu "oc get projects" por montri la plenan liston. Ĉu vi scivolas kiel ĉi tio funkcios se vi nur havas aliron al limigita subaro de nomspacoj sur la areto? Nu, ĉar kubectl nur faras tion ĝuste se RBAC permesas al vi vidi ĉiujn spacojn sur la areto, kaj en grandaj aretoj ne ĉiuj ricevas tiajn permesojn. Do, ni respondas: por la OC tio tute ne estas problemo kaj ĝi facile produktos kompletan liston en tia situacio. Estas ĉi tiuj etaj aferoj, kiuj konsistigas la kompanian orientiĝon de Openshift kaj la bonan skaleblon de ĉi tiu platformo laŭ uzantoj kaj aplikoj.
2. ODO - plibonigita versio de kubectl por programistoj
Alia ekzemplo de la plibonigoj de Red Hat OpenShift super Kubernetes estas la ODO komandlinia utileco. Ĝi estas desegnita por programistoj kaj permesas vin rapide deploji lokan kodon al fora OpenShift-areto. Ĝi ankaŭ povas plifaciligi internajn procezojn por tuj sinkronigi ĉiujn kodŝanĝojn al ujoj sur fora OpenShift-areto sen devi rekonstrui, registri kaj redeploji bildojn.
Ni rigardu kiel OC kaj ODO faciligas labori kun ujoj kaj Kubernetes.
Nur komparu kelkajn laborfluojn kiam ili estas konstruitaj surbaze de kubectl, kaj kiam OC aŭ ODO estas uzataj.
• Disvolviĝo de kodo sur OpenShift por tiuj, kiuj ne parolas YAML:
Kubernetes/kubectl
$>git-klono
1- Kreu Dockerfile, kiu konstruas la bildon el kodo
-----
DE nodo
LABORODIR /usr/src/app
KOPIU pako*.json ./
KOPIU index.js ./
KOPIU ./app ./app
RUN npm instali
EKPONI 3000
CMD [ "npm", "komenco" ] ————–
2- Ni konstruas la bildon
$>podman konstruo...
3- Ensalutu al la registro
podman ensaluto...
4- Metu la bildon en la registron
podman push
5- Kreu yaml-dosierojn por aplikaĵo-deplojo (deployment.yaml, service.yaml, ingress.yaml) - ĉi tio estas la absoluta minimumo
6- Disvolvi manifestajn dosierojn:
Kubectl apliki -f .
OpenShift/oc
$> oc new-app – nia_aplika_nomo
OpenShift/odo
$>git-klono
$> odo krei komponenton nodejs myapp
$>odo push
• Kunteksta ŝaltilo: ŝanĝu labornomspacon aŭ laborgrupon.
Kubernetes/kubectl
1- Kreu kuntekston en kubeconfig por la projekto "mia projekto"
2- kubectl aro-kunteksto...
OpenShift/oc
oc-projekto "mia projekto"
Kvalita kontrolo: "Unu interesa funkcio aperis ĉi tie, ankoraŭ en alfa versio. Eble ni povas meti ĝin en produktadon?"
Imagu, ke oni sidas en konkursaŭto kaj oni diras: „Ni instalis novan specon de bremsoj kaj, sincere, ilia fidindeco ankoraŭ ne estas en ordo... Sed ne maltrankviliĝu, ni aktive plibonigos ilin dum la kurso. de la ĉampioneco.” Kiel vi ŝatas ĉi tiun perspektivon? Ni ĉe Red Hat estas iel ne tre feliĉaj. 🙂
Tial ni provas reteni alfajn versiojn ĝis ili estas sufiĉe maturaj kaj ni faris ĝisfundajn bataltestojn kaj sentas, ke ili estas sekure uzi. Kutime, ĉio pasas tra la Dev Preview etapo unue, poste tra kaj nur tiam aperas kiel publika eldono (GA), kiu jam estas tiel stabila ke ĝi taŭgas por produktado.
Kial estas tio? Ĉar, kiel kun la evoluo de iu ajn alia programaro, ne ĉiuj komencaj ideoj en Kubernetes atingas la finan eldonon. Aŭ ili atingas ĝin kaj eĉ konservas la celitan funkciecon, sed ilia efektivigo estas radikale malsama ol tiu en la alfa versio. Kun miloj kaj miloj da klientoj de Red Hat uzantaj OpenShift por subteni misi-kritikajn laborŝarĝojn, ni metas specialan emfazon de la stabileco de nia platformo kaj longdaŭra subteno.
Red Hat kompromitas liberigi OpenShift ofte kaj ĝisdatigi la version de Kubernetes kiu venas kun ĝi. Ekzemple, la nuna GA-eldono de OpenShift 4.3 en la momento de ĉi tiu skribado inkluzivas Kubernetes 1.16, kiu estas nur unu unuo malantaŭ la kontraŭflua versio de Kubernetes numerita 1.17. Tiel, ni provas provizi la klienton per entreprena klaso Kubernetes kaj provizi plian kvalitan kontrolon dum ni publikigas novajn versiojn de OpenShift.
Programaro korektas: "Estis truo en la versio de Kubernetes, kiun ni havas en produktado. Kaj vi povas fermi ĝin nur ĝisdatigante tri versiojn. Aŭ ĉu ekzistas ebloj?
En la malfermfonteca projekto de Kubernetes, programaj korektoj estas kutime liberigitaj kiel parto de la sekva eldono, foje kovrante unu aŭ du antaŭajn mejloŝtonajn eldonojn, donante priraportadon nur 6 monatojn.
Red Hat fieras pri publikigado de kritikaj korektoj pli frue ol aliaj kaj liverado de subteno por multe pli longe. Prenu ekzemple la vundeblecon de eskalado de privilegioj de Kubernetes (): ĝi estis malkovrita en Kubernetes 1.11, kaj korektoj por antaŭaj eldonoj estis publikigitaj nur ĝis versio 1.10.11, lasante ĉi tiun en la truo en ĉiuj antaŭaj Kubernetes eldonoj, de 1.x ĝis 1.9.
Siavice, (Kubernetes 1.2 estas tie), kaptante naŭ eldonojn de OpenShift kaj klare pruvante prizorgon por klientoj (pli da detaloj ).
Kiel OpenShift kaj Red Hat antaŭeniras Kubernetes
Red Hat estas la dua plej granda programaro kontribuanto al la malfermfonta Kubernetes-projekto, malantaŭ nur Google, kun 3 el la 5 plej produktivaj programistoj venantaj de Red Hat. Alia malmulte konata fakto: multaj kritikaj funkcioj aperis en Kubernetes ĝuste laŭ iniciato de Red Hat, precipe, kiel:
- RBAC. Kubernetes ne havis RBAC-funkciojn (ClusterRole, ClusterRoleBinding) ĝis Red Hat-inĝenieroj decidis efektivigi ilin kiel parton de la platformo mem, kaj ne kiel kroman OpenShift-funkciecon. Ĉu Red Hat timas plibonigi Kubernetes? Kompreneble ne, ĉar Red Hat strikte sekvas malfermfontajn principojn kaj ne ludas Open Core-ludojn. Pliboniĝoj kaj novigoj kiuj estas pelitaj de evolukomunumoj, prefere ol proprietaj, estas pli realigeblaj kaj pli vaste adoptitaj, kio kongruas bone kun nia kerna celo fari malfermfontecan programaron pli utila al niaj klientoj.
- Sekurecpolitikoj por podoj (Pod Security Policies). Ĉi tiu koncepto pri rulado de aplikoj sekure en podoj estis origine efektivigita en OpenShift sub la nomo SCC (Security Context Constraints). Kaj kiel en la antaŭa ekzemplo, Red Hat decidis enkonduki ĉi tiujn evoluojn en la malfermitan projekton Kubernetes por ke ĉiuj povu uzi ilin.
Ĉi tiu serio de ekzemploj povus esti daŭrigita, sed ni nur volis montri, ke Red Hat vere kompromitas disvolvi Kubernetes kaj plibonigi ĝin por ĉiuj.
Estas klare, ke OpenShift estas Kubernetes. Kio estas la diferencoj? 🙂
Ni esperas, ke legante ĉi tien vi rimarkis, ke Kubernetes estas la kerna komponanto de OpenShift. La ĉefa, sed malproksime de la sola. Alivorte, simple instali Kubernetes ne donos al vi entreprenan klasan platformon. Vi devos aldoni aŭtentikigon, reton, sekurecon, monitoradon, protokolon kaj pli. Krome, vi devos fari kelkajn malfacilajn elektojn el la granda nombro da disponeblaj iloj (por aprezi la diversecon de la ekosistemo, nur rigardu ) kaj iel certigi konsistencon kaj koherecon por ke ili funkciu kiel unu. Krome, vi regule devos plenumi ĝisdatigojn kaj regresajn provojn kiam ajn nova versio de iu ajn el la komponantoj, kiujn vi uzas, estas publikigita. Tio estas, krom krei kaj konservi la platformon mem, vi ankaŭ devos trakti ĉi tiun tutan programaron. Estas neverŝajne, ke restos multe da tempo por solvi komercajn problemojn kaj atingi konkurencivajn avantaĝojn.
Sed en la kazo de OpenShift, Red Hat prenas sur si ĉiujn ĉi tiujn kompleksaĵojn kaj simple donas al vi funkcie kompletan platformon, kiu inkluzivas ne nur Kubernetes mem, sed ankaŭ la tutan aron de necesaj malfermfontaj iloj, kiuj igas Kubernetes vera entreprena klaso. solvo, kiun vi povas tuj kaj tute trankvile lanĉi en produktadon. Kaj kompreneble, se vi havas kelkajn el viaj propraj teknologiaj stakoj, tiam vi povas integri OpenShift en ekzistantajn solvojn.
Rigardu la supran bildon: ĉio, kio estas ekster la Kubernetes-rektangulo, estas kie Red Hat aldonas funkciojn, kiujn Kubernetes ne havas, kiel oni diras, laŭdezajne. Kaj nun ni rigardos la ĉefajn el ĉi tiuj areoj.
1. Fortika OS kiel bazo: RHEL CoreOS aŭ RHEL
Red Hat estas ĉefa provizanto de Linukso-distribuoj por komercaj kritikaj aplikoj dum pli ol 20 jaroj. Nia amasigita kaj konstante ĝisdatigita sperto en ĉi tiu areo permesas al ni proponi vere fidindan kaj fidindan bazon por la industria funkciado de ujoj. RHEL CoreOS uzas la saman kernon kiel RHEL, sed estas optimumigita ĉefe por taskoj kiel funkciigado de ujoj kaj funkciigado de Kubernetes-aretoj: ĝia reduktita grandeco kaj neŝanĝebleco faciligas agordi aretojn, aŭtoskalon, deploji diakilojn, ktp. Ĉiuj ĉi tiuj funkcioj faras ĝin. ideala fundamento por liveri la saman uzantan sperton kun OpenShift tra larĝa gamo de komputikmedioj, de nuda metalo ĝis privata kaj publika nubo.
2. Aŭtomatigo de IT-operacioj
Aŭtomatigo de instalprocezoj kaj tagaj operacioj (tio estas, ĉiutagaj operacioj) estas la forta punkto de OpenShift, faciligante administri, ĝisdatigi kaj konservi la agadon de la ujplatformo ĉe la plej alta nivelo. Ĉi tio estas atingita per subteno por Kubernetes-funkciigistoj ĉe la OpenShift 4-kernnivelo.
OpenShift 4 ankaŭ estas tuta ekosistemo de solvoj bazitaj sur Kubernetes-funkciigistoj, evoluigitaj kaj de Red Hat mem kaj de triaj partneroj (vidu. Red Hat, aŭ operaciisto vendejo , kreita de Red Hat por triapartaj programistoj).
La integra OpenShift 4 katalogo inkluzivas pli ol 180 Kubernetes-funkciigistojn
3. Iloj por programistoj
Ekde 2011, OpenShift estas disponebla kiel platformo PaaS (Platform-as-a-Service), kiu faciligas la vivon al programistoj, helpas ilin koncentriĝi pri kodado kaj ofertas denaskan subtenon por programlingvoj kiel Java, Node.js. , PHP, Ruby, Python, Go, same kiel CI/CD kontinua integriĝo kaj liveroservoj, datumbazoj, ktp OpenShift 4 proponoj , kiu inkluzivas pli ol 100 servojn bazitajn sur Kubernetes-funkciigistoj evoluigitaj de Red Hat kaj niaj partneroj.
Male al Kubernetes, OpenShift 4 havas dediĉitan GUI (), kiu helpas programistoj senpene deploji aplikaĵojn de diversaj fontoj (git, eksteraj registroj, Dockerfile, ktp.) en siajn nomspacojn kaj klare bildigas la rilatojn inter aplikaĵokomponentoj.
Krome, OpenShift ofertas aron de Codeready-disvolvaj iloj, kiuj, precipe, inkluzivas , plene kontenerigita IDE kun interreta interfaco kiu funkcias rekte sur OpenShift kaj efektivigas IDE-kiel-servan aliron. Aliflanke, por tiuj, kiuj volas labori strikte en loka reĝimo, ekzistas Codeready Containers, plene funkcia versio de OpenShift 4 kiu povas esti deplojita sur tekkomputilo.
Integrita IDE kiel servo por efika disvolviĝo sur la platformo Kubernetes/OpenShift
OpenShift ofertas plenan CI/KD-sistemon tuj el la skatolo, ĉu bazita sur kontenerigita Jenkins kaj kromaĵo por labori kun duktoj, aŭ Kubernetes-orientita CI/KD-sistemo (nuntempe en Tech-antaŭprezentversio). Ambaŭ ĉi tiuj solvoj plene integriĝas kun la OpenShift-konzolo, permesante al vi ruli duktilojn, vidi deplojojn, protokolojn kaj pli.
4. Aplikaj Iloj
OpenShift permesas vin disfaldi kaj tradiciajn ŝtatajn aplikojn kaj nub-bazitajn solvojn bazitajn sur novaj arkitekturoj, kiel ekzemple mikroservoj aŭ senservilo. La solvo OpenShift Service Mesh venas tuj el la skatolo kun ŝlosilaj iloj por konservi mikroservojn, kiel Istio, Kiali kaj Jaeger. Siavice, la solvo OpenShift Serverless inkluzivas ne nur Knative, sed ankaŭ ilojn kiel Keda kreitajn kiel parto de komuna iniciato kun Mikrosofto por provizi Azure-funkciojn sur la platformo OpenShift.
La integra solvo OpenShift ServiceMesh (Istio, Kiali, Jaeger) estos utila dum disvolvado de mikroservoj
Por limigi la interspacon inter heredaj aplikoj kaj ujoj, OpenShift nun permesas virtualan maŝinan migradon al la platformo OpenShift uzante Container Native Virtualization (nuntempe en TechPreview), farante hibridajn aplikojn realaĵon kaj faciligante ilian migradon inter malsamaj nuboj, kaj privataj kaj publikaj.
Vindoza 2019 Virtuala virtuala maŝino funkcianta sur OpenShift per Container Native Virtualization (nuntempe en Tech-antaŭprezentversio)
5. Iloj por aretoj
Ajna entreprena klaso platformo devas havi monitoradon kaj centralizitajn registradajn servojn, sekurecajn mekanismojn, aŭtentikigon kaj rajtigon, kaj retajn administrajn ilojn. Kaj OpenShift provizas ĉion ĉi ekstere de la skatolo, kaj ĉio estas 100% malferma fonto, inkluzive de solvoj kiel ElasticSearch, Prometheus, Grafana. Ĉiuj ĉi tiuj solvoj venas kun paneloj, metrikoj kaj atentigoj, kiuj jam estas konstruitaj kaj agorditaj uzante la ampleksan kompetentecon pri monitorado de grapoloj de Red Hat, permesante al vi efike kontroli kaj kontroli vian produktadmedion tuj de la komenco.
OpenShift ankaŭ venas norma kun tiaj gravaj aferoj por kompaniaj klientoj kiel aŭtentigo kun enkonstruita aŭuth-provizanto, integriĝo kun akreditprovizantoj, inkluzive de LDAP, ActiveDirectory, OpenID Connect, kaj multe pli.
Antaŭ-agordita Grafana panelo por OpenShift-grupo-monitorado
Pli ol 150 antaŭkonfiguritaj Prometheus-metrikoj kaj atentigoj por OpenShift-grupo-monitorado
Daŭrigi
La riĉa funkcieco de la solvo kaj la ampleksa sperto de Red Hat en la kampo de Kubernetes estas la kialoj kial OpenShift atingis dominan pozicion en la merkato, kiel montrite en la figuro sube (legu pli ).
"Red Hat nuntempe gvidas la merkaton kun 44%-parto.
La firmao rikoltas la avantaĝojn de sia klient-centrigita venda strategio, kie ĝi unue konsultas kaj trejnas entreprenajn programistojn kaj poste moviĝas al monetigo kiam la entrepreno komencas deploji ujojn en produktadon."
(Fonto: )
Ni esperas, ke vi ĝuis ĉi tiun artikolon. En estontaj afiŝoj en ĉi tiu serio, ni rigardos pli detale la avantaĝojn de OpenShift super Kubernetes en ĉiu el la kategorioj diskutitaj ĉi tie.
fonto: www.habr.com