"Wat is it ferskil tusken Kubernetes en OpenShift?" - dizze fraach ûntstiet mei oergeunstige konsistinsje. Hoewol dit yn werklikheid is as freegje hoe't in auto ferskilt fan in motor. As wy de analogy trochgean, dan is in auto in klear produkt, jo kinne it direkt brûke, letterlik: yn en gean. Oan de oare kant, om in motor jin earne te bringen, moat dy earst noch in soad oare dingen oanfolle wurde om úteinlik deselde auto te krijen.
Dêrom is Kubernetes de motor wêryn't de auto (platfoarm) fan it merk OpenShift is gearstald, dy't jo nei jo doel bringt.
Yn dit artikel wolle wy jo herinnerje en de folgjende wichtige punten yn in bytsje mear detail ûndersykje:
- Kubernetes is it hert fan it OpenShift-platfoarm en it is 100% sertifisearre Kubernetes, folslein iepen boarne en sûnder de minste eigen aard. Koartsein:
- De OpenShift cluster API is XNUMX% Kubernetes.
- As de kontener rint op in oar Kubernetes-systeem, dan sil it sûnder feroaringen op OpenShift rinne. D'r is gjin ferlet om wizigingen oan 'e applikaasjes te meitsjen.
- OpenShift foeget net allinich nuttige funksjes en funksjonaliteit ta oan Kubernetes. Lykas in auto is OpenShift út 'e doaze, kin fuortendaliks yn produksje wurde brocht, en, lykas wy hjirûnder sille sjen litte, makket it libben fan in ûntwikkelder in stik makliker. Dêrom is OpenShift ferienige yn twa persoanen. It is sawol in súksesfol as bekend PaaS-platfoarm fan ûndernimmingsklasse út in perspektyf fan ûntwikkelders. En tagelyk is it in superbetroubere Container-as-a-Service-oplossing út it eachpunt fan yndustriële operaasje.
OpenShift is Kubernetes mei 100% CNCF-sertifikaasje
OpenShift is basearre op . Dêrom, nei goede training, brûkers binne fernuvere troch de krêft fan kubectl. En dejingen dy't oerstapten nei OpenShift fan Kubernetes Cluster sizze faak hoefolle se dat echt leuk fine, nei't se kubeconfig nei it OpenShift-kluster trochferwizing hawwe, wurkje alle besteande skripts feilloos.
Jo hawwe wierskynlik heard oer OpenShift's kommandorigelprogramma neamd OC. It is folslein kommando-kompatibel mei kubectl, plus it biedt ferskate nuttige helpers dy't handich sille komme by it útfieren fan in oantal taken. Mar earst in bytsje mear oer de kompatibiliteit fan OC en kubectl:
kubectl kommando
OC Teams
kubectl krije pods
oc krije pods
kubectl krije nammeromten
oc krije nammeromten
kubectl meitsje -f deployment.yaml
oc meitsje -f deployment.yaml
Hjir is hoe't de resultaten fan it brûken fan kubectl op 'e OpenShift API der útsjen:
• kubectl krije pods - jout pods as ferwachte.
• kubectl krije nammeromten - jout nammeromten werom as ferwachte.
It kommando kubectl create -f mydeployment.yaml makket kubernetes-boarnen krekt lykas op elk oar Kubernetes-platfoarm, lykas werjûn yn 'e fideo hjirûnder:
Mei oare wurden, alle Kubernetes API's binne folslein beskikber yn OpenShift, wylst se 100% kompatibiliteit behâlde. Dêrom .
OpenShift foeget nuttige funksjes ta oan Kubernetes
Kubernetes API's binne 100% beskikber yn OpenShift, mar de standert Kubernetes utility kubectl mist dúdlik funksjonaliteit en gemak. Dêrom hat Red Hat nuttige funksjes en kommando-rigelark oan Kubernetes tafoege, lykas OC (koart foar OpenShift client) en ODO (OpenShift DO, dit hulpprogramma is rjochte op ûntwikkelders).
1. OC-hulpprogramma - in krêftiger en handiger ferzje fan Kubectl
Bygelyks, yn tsjinstelling ta kubectl, kinne jo nije nammeromten oanmeitsje en maklik kontekst feroarje, en biedt ek in oantal nuttige kommando's foar ûntwikkelders, lykas it bouwen fan kontenerôfbyldings en it ynsetten fan applikaasjes direkt fan boarnekoade of binaries (Boarne-nei-ôfbylding, s2i).
Litte wy nei foarbylden sjen hoe't de ynboude helpers en avansearre funksjonaliteit fan it OC-hulpprogramma helpe it deistich wurk te ferienfâldigjen.
It earste foarbyld is nammeromtebehear. Elk Kubernetes-kluster hat altyd meardere nammeromten. Se wurde meast brûkt om ûntwikkelings- en produksjeomjouwings te meitsjen, mar kinne ek brûkt wurde om bygelyks elke ûntwikkelder in persoanlike sânbak te jaan. Yn 'e praktyk bringt dit ta dat de ûntwikkelder faak moat wikselje tusken nammeromten, om't kubectl rint yn' e kontekst fan 'e hjoeddeistige romte. Dêrom brûke minsken yn it gefal fan kubectl aktyf helperskripts foar dit. Mar as jo OC brûke, om te wikseljen nei de winske romte, sis gewoan "oc project namespace".
Unthâld net wat de nammeromte dy't jo nedich hawwe hjit? Gjin probleem, typ gewoan "oc get projects" om de folsleine list wer te jaan. Skeptysk ôffreegje hoe't dit sil wurkje as jo allinich tagong hawwe ta in beheinde subset fan nammeromten op it kluster? No, om't kubectl dit allinich goed docht as RBAC jo alle romten op it kluster sjen lit, en yn grutte klusters net elkenien sokke tagongsrjochten krije. Dat, wy antwurdzje: foar de OC is dit hielendal gjin probleem en it sil maklik in folsleine list meitsje yn sa'n situaasje. It binne dizze lytse dingen dy't de bedriuwsoriïntaasje fan Openshift foarmje en de goede skalberens fan dit platfoarm yn termen fan brûkers en applikaasjes
2. ODO - in ferbettere ferzje fan kubectl foar ûntwikkelders
In oar foarbyld fan Red Hat OpenShift's ferbetteringen oer Kubernetes is it ODO kommandorigelprogramma. It is ûntworpen foar ûntwikkelders en lit jo lokale koade fluch ynsette nei in OpenShift-kluster op ôfstân. It kin ek ynterne prosessen streamlynje om alle koadewizigingen direkt te syngronisearjen nei konteners op in OpenShift-kluster op ôfstân sûnder ôfbyldings opnij op te bouwen, te registrearjen en opnij yn te setten.
Litte wy sjen hoe't OC en ODO wurkje mei konteners en Kubernetes makliker meitsje.
Fergelykje gewoan in pear workflows as se binne boud op basis fan kubectl, en as OC of ODO wurde brûkt.
• Ynset fan koade op OpenShift foar dyjingen dy't gjin YAML prate:
Kubernetes/kubectl
$>git clone
1- Meitsje in Dockerfile dy't de ôfbylding bout fan koade
-----
FROM node
WORKDIR /usr/src/app
COPY pakket*.json ./
COPY index.js ./
COPY ./app ./app
RUN npm ynstallearje
EXPOSE 3000
CMD [ "npm", "start" ] ————–
2- Wy bouwe it byld
$>podman bouwe...
3- Oanmelde by it register
podman login...
4- Plak de ôfbylding yn it register
podman druk
5- Meitsje yaml-bestannen foar applikaasje-ynset (deployment.yaml, service.yaml, ingress.yaml) - dit is it absolute minimum
6- Manifestbestannen ynsette:
Kubectl tapasse -f.
OpenShift/oc
$> oc nije-app - ús_applikaasje_namme
OpenShift/odo
$>git clone
$> odo meitsje komponint nodejs myapp
$>odo druk
• Context switch: feroarje wurk nammeromte of wurk kluster.
Kubernetes/kubectl
1- Meitsje in kontekst yn kubeconfig foar it projekt "myproject"
2- kubectl set-kontekst...
OpenShift/oc
oc projekt "myproject"
Kwaliteitskontrôle: "Ien nijsgjirrige funksje is hjir ferskynd, noch yn alfa-ferzje. Miskien kinne wy it yn produksje sette?"
Stel jo foar dat jo yn in raceauto sitte en wurde ferteld: "Wy hawwe in nij type remmen ynstalleare en om earlik te wêzen, de betrouberens is noch net goed ... Mar meitsje jo gjin soargen, wy sille se aktyf ferbetterje yn 'e kursus fan it kampioenskip." Hoe fynsto dit perspektyf? Wy by Red Hat binne op ien of oare manier net hiel bliid. 🙂
Dêrom besykje wy alfa-ferzjes ôf te hâlden oant se genôch folwoeksen binne en wy hawwe yngeande slachtesten dien en fiele dat se feilich binne te brûken. Normaal giet alles earst troch it Dev Preview-poadium, dan troch en pas dan komt út as in iepenbiere frijlitting (GA), dy't al sa stabyl is dat it geskikt is foar produksje.
Wêrom is dat? Om't, lykas by de ûntwikkeling fan elke oare software, net alle earste ideeën yn Kubernetes de definitive release berikke. Of se berikke it en behâlde sels de bedoelde funksjonaliteit, mar har ymplemintaasje is radikaal oars as dy yn 'e alfaferzje. Mei tûzenen en tûzenen Red Hat-klanten dy't OpenShift brûke om missy-krityske workloads te stypjen, lizze wy spesjaal klam op 'e stabiliteit fan ús platfoarm en stipe op lange termyn.
Red Hat set har yn foar it frijlitten fan OpenShift faak en it bywurkjen fan de ferzje fan Kubernetes dy't derby komt. Bygelyks, de hjoeddeistige GA-útjefte fan OpenShift 4.3 op it stuit fan dit skriuwen omfettet Kubernetes 1.16, dy't mar ien ienheid is efter de streamopferzje fan Kubernetes nûmere 1.17. Sa besykje wy de klant te foarsjen Kubernetes fan ûndernimmingsklasse en ekstra kwaliteitskontrôle te leverjen tidens de frijlitting fan nije ferzjes fan OpenShift.
Software fixes: "D'r wie in gat yn 'e ferzje fan Kubernetes dy't wy yn produksje hawwe. En jo kinne it allinich slute troch trije ferzjes te aktualisearjen. Of binne d'r opsjes?
Yn it Kubernetes-iepenboarne-projekt wurde softwarefixes normaal frijlitten as ûnderdiel fan 'e folgjende release, dy't soms ien of twa eardere mylpealreleases dekke, en jouwe dekking sa min as 6 moannen werom.
Red Hat is grutsk op it frijjaan fan krityske fixes earder dan oaren en it leverjen fan stipe foar folle langer. Nim bygelyks de kwetsberens foar eskalaasje fan privileges fan Kubernetes (): it waard ûntdutsen yn Kubernetes 1.11, en reparaasjes foar eardere releases waarden allinich frijlitten oant ferzje 1.10.11, wêrtroch dizze yn it gat yn alle eardere Kubernetes releases, fan 1.x oant 1.9.
Oan 'e oare kant, (Kubernetes 1.2 is d'r), njoggen OpenShift-releases fêstlizze en dúdlik sjen litte soarch foar klanten (mear details ).
Hoe OpenShift en Red Hat Kubernetes foarút bringe
Red Hat is de twadde grutste software-bydrager oan it iepen boarne Kubernetes-projekt, efter allinich Google, mei 3 fan 'e 5 meast produktive ûntwikkelders dy't komme fan Red Hat. In oar lyts bekend feit: in protte krityske funksjes ferskynden yn Kubernetes krekt op inisjatyf fan Red Hat, benammen, lykas:
- RBAC. Kubernetes hie gjin RBAC-funksjes (ClusterRole, ClusterRoleBinding) oant Red Hat-yngenieurs besletten se te ymplementearjen as diel fan it platfoarm sels, en net as ekstra OpenShift-funksjonaliteit. Is Red Hat bang om Kubernetes te ferbetterjen? Fansels net, om't Red Hat strikt iepen boarneprinsipes folget en gjin Open Core-spultsjes spielet. Ferbetteringen en ynnovaasjes dy't wurde oandreaun troch ûntwikkelingsmienskippen, yn stee fan proprietêre, binne libbensfetberder en mear wiid oannommen, wat goed slút oan by ús kearndoel om iepen boarne software brûkber te meitsjen foar ús klanten.
- Feiligensbelied foar pods (Pod Security Policies). Dit konsept fan it feilich útfieren fan applikaasjes yn pods waard oarspronklik ymplementearre yn OpenShift ûnder de namme SCC (Security Context Constraints). En lykas yn it foarige foarbyld besleat Red Hat dizze ûntjouwings yn te fieren yn it iepen Kubernetes-projekt, sadat elkenien se brûke koe.
Dizze searje foarbylden koe wurde fuortset, mar wy woene gewoan sjen litte dat Red Hat wirklik ynsette is foar it ûntwikkeljen fan Kubernetes en it better meitsje foar elkenien.
It is dúdlik dat OpenShift Kubernetes is. Wat binne de ferskillen? 🙂
Wy hoopje dat jo troch it lêzen fan sa fier hawwe realisearre dat Kubernetes de kearnkomponint fan OpenShift is. De wichtichste, mar fier fan de ienige. Mei oare wurden, it gewoan ynstallearjen fan Kubernetes sil jo gjin platfoarm fan bedriuwsklasse jaan. Jo moatte autentikaasje, netwurking, feiligens, tafersjoch, logboekbehear, en mear taheakje. Plus, jo moatte wat lestige karren meitsje út it grutte oantal beskikbere ark (om it ferskaat fan it ekosysteem te wurdearjen, sjoch gewoan ) en op ien of oare manier foar konsistinsje en gearhing soargje dat se as ien wurkje. Derneist sille jo regelmjittich updates en regressiontesten moatte útfiere as in nije ferzje fan ien fan 'e komponinten dy't jo brûke wurdt frijlitten. Dat is, neist it meitsjen en ûnderhâlden fan it platfoarm sels, sille jo ek mei al dizze software moatte omgean. It is net wierskynlik dat d'r in protte tiid oerbliuwt om saaklike problemen op te lossen en kompetitive foardielen te berikken.
Mar yn it gefal fan OpenShift nimt Red Hat al dizze kompleksiteiten op himsels en jout jo gewoan in funksjoneel folslein platfoarm, dat net allinich Kubernetes sels omfettet, mar ek de heule set fan nedige iepen boarne-ark dy't Kubernetes yn in echte ûndernimmingsklasse meitsje. oplossing dy't jo fuortendaliks en folslein rêstich yn produksje kinne lansearje. En fansels, as jo wat fan jo eigen technologystapels hawwe, dan kinne jo OpenShift yntegrearje yn besteande oplossingen.
Besjoch de foto hjirboppe: alles wat bûten it Kubernetes-rjochthoek is, is wêr't Red Hat funksjonaliteit tafoeget dy't Kubernetes net hat, sa't se sizze, by-ûntwerp. En no sille wy sjen nei de wichtichste fan dizze gebieten.
1. Robuste OS as basis: RHEL CoreOS of RHEL
Red Hat is al mear dan 20 jier in liedende leveransier fan Linux-distribúsjes foar saaklike krityske applikaasjes. Us opboude en konstant bywurke ûnderfining op dit gebiet lit ús in wirklik betroubere en fertroude basis oanbiede foar de yndustriële operaasje fan konteners. RHEL CoreOS brûkt deselde kearn as RHEL, mar is primêr optimalisearre foar taken lykas it útfieren fan konteners en it útfieren fan Kubernetes-klusters: de fermindere grutte en ûnferoarlikens meitsje it makliker om klusters op te setten, autoskalearjen, patches yn te setten, ensfh. Al dizze funksjes meitsje it in ideale basis foar it leverjen fan deselde brûkersûnderfining mei OpenShift oer in breed skala oan komputeromjouwings, fan bleate metaal oant privee en iepenbiere wolk.
2. Automatisearring fan IT operaasjes
Automatisearring fan ynstallaasjeprosessen en dei-4 operaasjes (dat is, deistige operaasjes) is it sterke punt fan OpenShift, wêrtroch it folle makliker is om de prestaasjes fan it kontenerplatfoarm op it heechste nivo te behearjen, te aktualisearjen en te ûnderhâlden. Dit wurdt berikt troch stipe foar Kubernetes-operators op it OpenShift XNUMX-kernelnivo.
OpenShift 4 is ek in hiel ekosysteem fan oplossingen basearre op Kubernetes-operators, ûntwikkele sawol troch Red Hat sels as troch partners fan tredden (sjoch. Red Hat, of operator winkel , makke troch Red Hat foar ûntwikkelders fan tredden).
De yntegreare OpenShift 4-katalogus omfettet mear dan 180 Kubernetes-operators
3. Developer Tools
Sûnt 2011 is OpenShift beskikber as in PaaS (Platform-as-a-Service) platfoarm dat it libben folle makliker makket foar ûntwikkelders, helpt har te fokusjen op kodearring, en biedt native stipe foar programmeartalen lykas Java, Node.js , PHP, Ruby, Python, Go, lykas CI/CD trochgeande yntegraasje- en leveringstsjinsten, databases, ensfh. OpenShift 4 biedt , dy't mear as 100 tsjinsten omfettet basearre op Kubernetes-operators ûntwikkele troch Red Hat en ús partners.
Oars as Kubernetes hat OpenShift 4 in tawijd GUI (), dy't ûntwikkelders helpt om applikaasjes út ferskate boarnen (git, eksterne registraasjes, Dockerfile, ensfh.) yn har nammeromten maklik yn te setten en de relaasjes tusken applikaasjekomponinten dúdlik te visualisearjen.
Derneist biedt OpenShift in set fan Codeready-ûntwikkelingsark, dy't benammen omfettet , in folslein containerisearre IDE mei in webynterface dy't direkt boppe op OpenShift rint en in IDE-as-a-service-oanpak ymplementearret. Oan 'e oare kant, foar dyjingen dy't strikt yn lokale modus wolle wurkje, is d'r Codeready Containers, in folslein funksjonele ferzje fan OpenShift 4 dy't kin wurde ynset op in laptop.
Yntegreare IDE as in tsjinst foar effisjinte ûntwikkeling op it Kubernetes/OpenShift-platfoarm
OpenShift biedt in folslein CI / CD-systeem direkt út 'e doaze, itsij basearre op containerized Jenkins en in plugin foar wurkjen mei pipelines, of in Kubernetes-rjochte CI / CD systeem (op it stuit yn Tech preview ferzje). Beide fan dizze oplossingen yntegrearje folslein mei de OpenShift-konsole, wêrtroch jo pipeline-triggers kinne útfiere, ynset, logs, en mear besjen.
4. Applikaasje Tools
OpenShift lit jo sawol tradisjonele stateful applikaasjes as cloud-basearre oplossingen ynsette op basis fan nije arsjitektueren, lykas mikrotsjinsten of serverless. De OpenShift Service Mesh-oplossing komt direkt út it fak mei wichtige ark foar it behâld fan mikrotsjinsten, lykas Istio, Kiali en Jaeger. Op syn beurt omfettet de OpenShift Serverless-oplossing net allinich Knative, mar ek ark lykas Keda makke as ûnderdiel fan in mienskiplik inisjatyf mei Microsoft om Azure-funksjes te leverjen op it OpenShift-platfoarm.
De yntegreare oplossing OpenShift ServiceMesh (Istio, Kiali, Jaeger) sil nuttich wêze by it ûntwikkeljen fan mikrotsjinsten
Om de kloof tusken legacy-applikaasjes en konteners te oerbrêgjen, lit OpenShift no migraasje fan firtuele masines nei it OpenShift-platfoarm mei help fan Container Native Virtualization (op it stuit yn TechPreview), wêrtroch hybride applikaasjes in realiteit meitsje en har migraasje tusken ferskate wolken fasilitearje, sawol privee as iepenbier.
Windows 2019 Firtuele firtuele masine dy't rint op OpenShift fia Container Native Virtualization (op it stuit yn Tech preview ferzje)
5. Tools foar klusters
Elk platfoarm fan ûndernimmingsklasse moat tafersjoch en sintralisearre loggingtsjinsten hawwe, befeiligingsmeganismen, autentikaasje en autorisaasje, en ark foar netwurkbehear. En OpenShift jout dit alles út 'e doaze, en it is allegear 100% iepen boarne, ynklusyf oplossings lykas ElasticSearch, Prometheus, Grafana. Al dizze oplossingen komme mei dashboards, metriken en warskôgings dy't al binne boud en konfigureare mei Red Hat's wiidweidige klustermonitoringekspertize, wêrtroch jo jo produksjeomjouwing fanôf it begjin effektyf kinne kontrolearje en kontrolearje.
OpenShift komt ek standert mei sokke wichtige dingen foar bedriuwsklanten as autentikaasje mei in ynboude oauth-provider, yntegraasje mei credential-providers, ynklusyf LDAP, ActiveDirectory, OpenID Connect, en folle mear.
Pre-konfigureare Grafana-dashboard foar OpenShift-klustermonitoring
Mear dan 150 foarôf konfigureare Prometheus-metriken en warskôgings foar OpenShift-klustermonitoring
To continue
De rike funksjonaliteit fan 'e oplossing en de wiidweidige ûnderfining fan Red Hat op it mêd fan Kubernetes binne de redenen wêrom't OpenShift in dominante posysje yn' e merk hat berikt, lykas werjûn yn 'e ôfbylding hjirûnder (lês mear ).
"Red Hat liedt op it stuit de merk mei in oandiel fan 44%.
It bedriuw plukt de foardielen fan har klant-sintraal ferkeapstrategy, wêr't it earst ûndernimmersûntwikkelders konsultearret en traint en dan oergiet nei monetarisaasje as it bedriuw begjint konteners yn produksje yn te setten.
(Boarne: )
Wy hoopje dat jo genoaten hawwe fan dit artikel. Yn takomstige berjochten yn dizze searje sille wy de foardielen fan OpenShift boppe Kubernetes yn elk fan 'e hjir besprutsen kategoryen besjen.
Boarne: www.habr.com