"Wat is die verskil tussen Kubernetes en OpenShift?" – hierdie vraag ontstaan met benydenswaardige konsekwentheid. Alhoewel dit in werklikheid is soos om te vra hoe 'n motor van 'n enjin verskil. As ons voortgaan met die analogie, dan is 'n motor 'n voltooide produk, jy kan dit dadelik gebruik, letterlik: klim in en gaan. Aan die ander kant, sodat ’n enjin jou iewers heen kan neem, moet dit eers met ’n klomp ander goed aangevul word om uiteindelik dieselfde kar te kry.
Daarom is Kubernetes die enjin waarom die OpenShift-handelsmerkmotor (platform) saamgestel word, wat jou na jou doelwit neem.
In hierdie artikel wil ons u herinner en die volgende sleutelpunte in 'n bietjie meer detail ondersoek:
- Kubernetes is die hart van die OpenShift-platform en dit is 100% gesertifiseerde Kubernetes, heeltemal oopbron en sonder die geringste eie aard. Kortliks:
- Die OpenShift-kluster-API is XNUMX% Kubernetes.
- As die houer op enige ander Kubernetes-stelsel loop, sal dit sonder enige veranderinge op OpenShift loop. Dit is nie nodig om veranderinge aan die toepassings aan te bring nie.
- OpenShift voeg nie net nuttige kenmerke en funksionaliteit by Kubernetes nie. Soos 'n motor, is OpenShift gereed om uit die boks te gebruik, kan onmiddellik in produksie geplaas word, en, soos ons hieronder sal wys, maak 'n ontwikkelaar se lewe baie makliker. Dit is hoekom OpenShift een uit twee persone is. Dit is beide 'n suksesvolle en bekende ondernemingsklas PaaS-platform vanuit 'n ontwikkelaar se perspektief. En terselfdertyd is dit 'n superbetroubare houer-as-'n-diens-oplossing vanuit die oogpunt van industriële bedryf.
OpenShift is 100% CNCF-gesertifiseerde Kubernetes
OpenShift is gebaseer op . Daarom, na behoorlike opleiding, is gebruikers verbaas oor die krag van kubectl. En diegene wat van Kubernetes Cluster na OpenShift oorgeskakel het, sê dikwels hoeveel hulle regtig daarvan hou nadat hulle kubeconfig na die OpenShift-kluster herlei het, werk alle bestaande skrifte foutloos.
Jy het waarskynlik gehoor van OpenShift se opdragreëlprogram genaamd OC. Dit is ten volle opdragversoenbaar met kubectl, en dit bied verskeie nuttige helpers wat handig te pas sal kom wanneer u 'n aantal take uitvoer. Maar eers 'n bietjie meer oor die verenigbaarheid van OC en kubectl:
kubectl opdragte
OC-spanne
kubectl kry peule
oc kry peule
kubectl kry naamruimtes
oc kry naamruimtes
kubectl skep -f deployment.yaml
oc skep -f deployment.yaml
Hier is hoe die resultate van die gebruik van kubectl op die OpenShift API lyk:
• kubectl get peule – gee peule terug soos verwag.
• kubectl kry naamruimtes – gee naamruimtes terug soos verwag.
Die opdrag kubectl create -f mydeployment.yaml skep kubernetes-hulpbronne net soos op enige ander Kubernetes-platform, soos in die video hieronder getoon:
Met ander woorde, alle Kubernetes API's is ten volle beskikbaar in OpenShift terwyl dit 100% versoenbaarheid behou. Dit is hoekom .
OpenShift voeg nuttige kenmerke by Kubernetes
Kubernetes API's is 100% beskikbaar in OpenShift, maar die standaard Kubernetes-hulpmiddel kubectl het duidelik nie funksionaliteit en gerief nie. Dit is hoekom Red Hat nuttige kenmerke en opdragreëlnutsgoed by Kubernetes gevoeg het, soos OC (kort vir OpenShift-kliënt) en ODO (OpenShift DO, hierdie nutsprogram is op ontwikkelaars gemik).
1. OC nut - 'n kragtiger en geriefliker weergawe van Kubectl
Byvoorbeeld, anders as kubectl, laat dit jou toe om nuwe naamruimtes te skep en maklik kontekste te wissel, en bied ook 'n aantal nuttige opdragte vir ontwikkelaars, soos die bou van houerbeelde en die implementering van toepassings direk vanaf bronkode of binaries (Bron-na-beeld, s2i).
Kom ons kyk na voorbeelde van hoe die ingeboude helpers en gevorderde funksionaliteit van die OC-nutsmiddel help om alledaagse werk te vereenvoudig.
Die eerste voorbeeld is naamruimtebestuur. Elke Kubernetes-kluster het altyd veelvuldige naamruimtes. Hulle word gewoonlik gebruik om ontwikkelings- en produksieomgewings te skep, maar kan ook gebruik word om byvoorbeeld elke ontwikkelaar van 'n persoonlike sandbox te voorsien. In die praktyk lei dit daartoe dat die ontwikkelaar gereeld tussen naamruimtes moet wissel, aangesien kubectl in die konteks van die huidige spasie loop. Daarom, in die geval van kubectl, gebruik mense aktief helper skrifte hiervoor. Maar wanneer jy OC gebruik, om na die verlangde spasie oor te skakel, sê net "oc project namespace".
Onthou jy nie wat die naamruimte genoem word wat jy nodig het nie? Geen probleem nie, tik net "oc get projects" om die volledige lys te vertoon. Wonder jy skepties hoe dit sal werk as jy net toegang het tot 'n beperkte subset van naamruimtes op die groepie? Wel, want kubectl doen dit net korrek as RBAC jou toelaat om al die spasies op die cluster te sien, en in groot clusters word nie aan almal sulke toestemmings gegee nie. So, ons antwoord: vir die OC is dit glad nie 'n probleem nie en dit sal maklik 'n volledige lys in so 'n situasie oplewer. Dit is hierdie klein dingetjies wat die korporatiewe oriëntasie van Openshift uitmaak en die goeie skaalbaarheid van hierdie platform in terme van gebruikers en toepassings
2. ODO - 'n verbeterde weergawe van kubectl vir ontwikkelaars
Nog 'n voorbeeld van Red Hat OpenShift se verbeterings oor Kubernetes is die ODO-opdragreël-nutsding. Dit is ontwerp vir ontwikkelaars en stel jou in staat om vinnig plaaslike kode na 'n afgeleë OpenShift-kluster te ontplooi. Dit kan ook interne prosesse stroomlyn om alle kodeveranderings onmiddellik na houers op 'n afgeleë OpenShift-kluster te sinkroniseer sonder om beelde te herbou, te registreer en te herontplooi.
Kom ons kyk hoe OC en ODO werk met houers en Kubernetes makliker maak.
Vergelyk net 'n paar werkstrome wanneer hulle gebou is op die basis van kubectl, en wanneer OC of ODO gebruik word.
• Ontplooiing van kode op OpenShift vir diegene wat nie YAML praat nie:
Kubernetes/kubectl
$>git kloon
1- Skep 'n Docker-lêer wat die beeld van kode bou
-----
VAN knooppunt
WORKDIR /usr/src/app
KOPIE pakket*.json ./
COPY index.js ./
KOPIE ./app ./app
RUN npm installeer
BLOOTSTELLING 3000
CMD [ "npm", "begin" ] ————–
2- Ons bou die beeld
$>podman bou...
3- Teken in op die register
podman login...
4- Plaas die prent in die register
podman druk
5- Skep yaml-lêers vir toepassing-ontplooiing (deployment.yaml, service.yaml, ingress.yaml) - dit is die absolute minimum
6- Ontplooi manifeslêers:
Kubectl toepas -f .
OpenShift/oc
$> oc nuwe toepassing – ons_toepassing_naam
OpenShift/odo
$>git kloon
$> odo skep komponent nodejs myapp
$>odo druk
• Konteksskakelaar: verander werknaamruimte of werkgroepering.
Kubernetes/kubectl
1- Skep 'n konteks in kubeconfig vir die projek "myproject"
2- kubectl stel-konteks...
OpenShift/oc
oc projek "myprojek"
Gehaltebeheer: “Een interessante kenmerk het hier verskyn, steeds in alfa-weergawe. Miskien kan ons dit in produksie plaas?”
Stel jou voor dat jy in 'n renmotor sit en gesê word: “Ons het 'n nuwe tipe remme geïnstalleer en, om eerlik te wees, is hul betroubaarheid nog nie reg nie... Maar moenie bekommerd wees nie, ons sal dit aktief verbeter tydens die kursus van die kampioenskap.” Hoe hou jy van hierdie vooruitsig? Ons by Red Hat is op een of ander manier nie baie gelukkig nie. 🙂
Daarom probeer ons om alfa-weergawes uit te hou totdat hulle voldoende volwasse is en ons deeglike gevegstoetse gedoen het en voel hulle is veilig om te gebruik. Gewoonlik gaan alles eers deur die Dev Preview stadium, dan deur en kom eers dan uit as 'n openbare vrystelling (GA), wat reeds so stabiel is dat dit geskik is vir produksie.
Hoekom is dit? Want, soos met die ontwikkeling van enige ander sagteware, bereik nie alle aanvanklike idees in Kubernetes die finale vrystelling nie. Of hulle bereik dit en behou selfs die beoogde funksionaliteit, maar die implementering daarvan verskil radikaal van dié in die alfa-weergawe. Met duisende der duisende Red Hat-kliënte wat OpenShift gebruik om missiekritieke werkladings te ondersteun, plaas ons spesiale klem op die stabiliteit van ons platform en langtermyn-ondersteuning.
Red Hat is daartoe verbind om OpenShift gereeld vry te stel en die ingeslote weergawe van Kubernetes op te dateer. Byvoorbeeld, die huidige GA-vrystelling van OpenShift 4.3 ten tyde van hierdie skrywe sluit Kubernetes 1.16 in, wat slegs een agter die stroomop weergawe van Kubernetes genommer 1.17 is. Ons probeer dus om die kliënt van ondernemingsklas Kubernetes te voorsien en bied addisionele gehaltebeheer namate ons nuwe weergawes van OpenShift vrystel.
Sagtewareoplossings: “Daar was 'n gat in die weergawe van Kubernetes wat ons in produksie het. En jy kan dit net sluit deur drie weergawes op te dateer. Of is daar enige opsies?
In die Kubernetes oopbronprojek word sagteware-oplossings gewoonlik vrygestel as deel van die volgende vrystelling, wat soms een of twee vorige mylpaalvrystellings dek, wat dekking so min as 6 maande terug gee.
Red Hat is trots daarop om kritieke oplossings vroeër as ander vry te stel en om baie langer ondersteuning te bied. Neem byvoorbeeld die Kubernetes-voorregte-eskalasie kwesbaarheid (): dit is ontdek in Kubernetes 1.11, en regstellings vir vorige vrystellings is slegs vrygestel tot weergawe 1.10.11, wat hierdie een in die gat gelaat het in alle vorige Kubernetes-vrystellings, van 1.x tot 1.9.
Op sy beurt, (Kubernetes 1.2 is daar), neem nege OpenShift-vrystellings vas en toon duidelik sorg vir kliënte (meer besonderhede ).
Hoe OpenShift en Red Hat Kubernetes vorentoe beweeg
Red Hat is die tweede grootste sagtewarebydraer tot die oopbron Kubernetes-projek, agter slegs Google, met 3 van die 5 mees produktiewe ontwikkelaars wat van Red Hat af kom. Nog 'n min bekende feit: baie kritieke funksies het in Kubernetes verskyn, juis op inisiatief van veral Red Hat, soos:
- RBAC. Kubernetes het nie RBAC-funksies (ClusterRole, ClusterRoleBinding) gehad nie totdat Red Hat-ingenieurs besluit het om dit as deel van die platform self te implementeer, en nie as bykomende OpenShift-funksionaliteit nie. Is Red Hat bang om Kubernetes te verbeter? Natuurlik nie, want Red Hat volg oopbronbeginsels streng en speel nie Open Core-speletjies nie. Verbeterings en innovasies wat aangedryf word deur ontwikkelingsgemeenskappe, eerder as eie gemeenskappe, is meer lewensvatbaar en meer algemeen aangeneem, wat goed aansluit by ons kerndoelwit om oopbronsagteware meer bruikbaar vir ons kliënte te maak.
- Sekuriteitsbeleide vir peule (Pod Security Policies). Hierdie konsep om toepassings veilig binne peule te laat loop, is oorspronklik in OpenShift geïmplementeer onder die naam SCC (Security Context Constraints). En soos in die vorige voorbeeld, het Red Hat besluit om hierdie ontwikkelings in die oop Kubernetes-projek in te voer sodat almal dit kan gebruik.
Hierdie reeks voorbeelde kan voortgesit word, maar ons wou net wys dat Red Hat werklik daartoe verbind is om Kubernetes te ontwikkel en dit vir almal beter te maak.
Dit is duidelik dat OpenShift Kubernetes is. Wat is die verskille? 🙂
Ons hoop dat u deur tot dusver te lees het besef dat Kubernetes die kernkomponent van OpenShift is. Die hoof een, maar ver van die enigste. Met ander woorde, die installering van Kubernetes sal jou nie 'n ondernemingklasplatform gee nie. Jy sal stawing, netwerk, sekuriteit, monitering, logboekbestuur en meer moet byvoeg. Boonop sal jy 'n paar moeilike keuses moet maak uit die groot aantal gereedskap wat beskikbaar is (om die diversiteit van die ekosisteem te waardeer, kyk net ) en op een of ander manier konsekwentheid en samehang verseker sodat hulle as een werk. Daarbenewens sal jy gereeld opdaterings en regressietoetsing moet uitvoer wanneer 'n nuwe weergawe van enige van die komponente wat jy gebruik vrygestel word. Dit wil sê, benewens die skep en instandhouding van die platform self, sal jy ook al hierdie sagteware moet hanteer. Dit is onwaarskynlik dat daar baie tyd oor sal wees om sakeprobleme op te los en mededingende voordele te behaal.
Maar in die geval van OpenShift, neem Red Hat al hierdie kompleksiteite op homself en gee jou eenvoudig 'n funksioneel volledige platform, wat nie net Kubernetes self insluit nie, maar ook die hele stel nodige oopbronnutsgoed wat Kubernetes in 'n ware ondernemingsklas omskep oplossing wat jy dadelik en heeltemal rustig in produksie kan begin. En natuurlik, as u van u eie tegnologiestapels het, kan u OpenShift in bestaande oplossings integreer.
Kyk na die prentjie hierbo: alles wat buite die Kubernetes-reghoek is, is waar Red Hat funksionaliteit byvoeg wat Kubernetes nie, soos hulle sê, by-ontwerp het nie. En nou sal ons kyk na die belangrikste van hierdie gebiede.
1. Robuuste bedryfstelsel as 'n basis: RHEL CoreOS of RHEL
Red Hat is al meer as 20 jaar 'n toonaangewende verskaffer van Linux-verspreidings vir besigheidskritiese toepassings. Ons opgehoopte en voortdurend opgedateerde ervaring op hierdie gebied stel ons in staat om 'n werklik betroubare en betroubare basis vir die industriële bedryf van houers te bied. RHEL CoreOS gebruik dieselfde kern as RHEL, maar is hoofsaaklik geoptimaliseer vir take soos om houers te laat loop en Kubernetes-klusters te laat loop: die verminderde grootte en onveranderlikheid daarvan maak dit makliker om groepe op te stel, outoskaal, ontplooiing van kolle, ens. Al hierdie kenmerke maak dit makliker 'n ideale basis vir die lewering van dieselfde gebruikerservaring met OpenShift oor 'n wye reeks rekenaaromgewings, van kaal metaal tot private en publieke wolk.
2. Outomatisering van IT-bedrywighede
Die outomatisering van installasieprosesse en dag-4-bedrywighede (dit wil sê dag-tot-dag-bedrywighede) is OpenShift se sterk punt, wat dit baie makliker maak om die houerplatform op sy hoogste vlak te administreer, op te dateer en in stand te hou. Dit word bereik deur ondersteuning vir Kubernetes-operateurs op die OpenShift XNUMX-kernvlak.
OpenShift 4 is ook 'n hele ekosisteem van oplossings gebaseer op Kubernetes-operateurs, ontwikkel beide deur Red Hat self en deur derdeparty-vennote (sien. Red Hat, of operateur winkel , geskep deur Red Hat vir derdeparty-ontwikkelaars).
Die geïntegreerde OpenShift 4-katalogus bevat meer as 180 Kubernetes-operateurs
3. Ontwikkelaarnutsgoed
Sedert 2011 is OpenShift beskikbaar as 'n PaaS-platform (Platform-as-a-Service) wat die lewe vir ontwikkelaars baie makliker maak, hulle help om op kodering te fokus en inheemse ondersteuning bied vir programmeertale soos Java, Node.js , PHP, Ruby, Python, Go, sowel as CI/CD deurlopende integrasie en afleweringsdienste, databasisse, ens. OpenShift 4 bied , wat meer as 100 dienste insluit gebaseer op Kubernetes-operateurs wat deur Red Hat en ons vennote ontwikkel is.
Anders as Kubernetes, het OpenShift 4 'n toegewyde GUI (), wat ontwikkelaars help om toepassings van verskeie bronne (git, eksterne registers, Dockerfile, ens.) moeiteloos in hul naamruimtes te ontplooi en die verwantskappe tussen toepassingkomponente duidelik te visualiseer.
Boonop bied OpenShift 'n stel Codeready-ontwikkelingsinstrumente, wat veral insluit , 'n ten volle gehouerde IDE met 'n webkoppelvlak wat direk bo-op OpenShift loop en 'n IDE-as-'n-diens-benadering implementeer. Aan die ander kant, vir diegene wat streng in die plaaslike modus wil werk, is daar Codeready Containers, 'n ten volle funksionele weergawe van OpenShift 4 wat op 'n skootrekenaar ontplooi kan word.
Geïntegreerde IDE as 'n diens vir doeltreffende ontwikkeling op die Kubernetes/OpenShift-platform
OpenShift bied 'n volledige CI/CD-stelsel reg uit die boks, óf gebaseer op houer Jenkins en 'n inprop vir werk met pyplyne, of 'n Kubernetes-georiënteerde CI/CD-stelsel (tans in Tech-voorskouweergawe). Albei hierdie oplossings integreer ten volle met die OpenShift-konsole, wat jou toelaat om pyplyn-snellers te laat loop, ontplooiings, logboeke en meer te sien.
4. Toepassingshulpmiddels
OpenShift laat jou toe om beide tradisionele stateful-toepassings en wolkgebaseerde oplossings te ontplooi wat gebaseer is op nuwe argitekture, soos mikrodienste of bedienerloos. Die OpenShift Service Mesh-oplossing kom reg uit die boks met sleutelinstrumente vir die instandhouding van mikrodienste, soos Istio, Kiali en Jaeger. Op sy beurt bevat die OpenShift Serverless-oplossing nie net Knative nie, maar ook instrumente soos Keda wat geskep is as deel van 'n gesamentlike inisiatief met Microsoft om Azure-funksies op die OpenShift-platform te verskaf.
Die geïntegreerde oplossing OpenShift ServiceMesh (Istio, Kiali, Jaeger) sal nuttig wees wanneer mikrodienste ontwikkel word
Om die gaping tussen verouderde toepassings en houers te oorbrug, laat OpenShift nou virtuele masjienmigrasie na die OpenShift-platform toe met behulp van Container Native Virtualization (tans in TechPreview), wat hibriede toepassings 'n werklikheid maak en hul migrasie tussen verskillende wolke, beide privaat en publiek, vergemaklik.
Windows 2019 Virtuele virtuele masjien wat op OpenShift loop via Container Native Virtualization (tans in Tech-voorskouweergawe)
5. Gereedskap vir trosse
Enige ondernemingsklasplatform moet monitering en gesentraliseerde logdienste, sekuriteitsmeganismes, verifikasie en magtiging en netwerkbestuurnutsmiddels hê. En OpenShift verskaf dit alles uit die boks, en dit is alles 100% oopbron, insluitend oplossings soos ElasticSearch, Prometheus, Grafana. Al hierdie oplossings kom met dashboards, maatstawwe en waarskuwings wat reeds gebou en gekonfigureer is met behulp van Red Hat se uitgebreide klustermonitering-kundigheid, wat jou in staat stel om jou produksie-omgewing van die begin af doeltreffend te beheer en te monitor.
OpenShift kom ook standaard met sulke belangrike dinge vir korporatiewe kliënte soos verifikasie met 'n ingeboude OAuth-verskaffer, integrasie met geloofsbrieweverskaffers, insluitend LDAP, ActiveDirectory, OpenID Connect, en nog baie meer.
Vooraf gekonfigureerde Grafana-kontroleskerm vir OpenShift-klustermonitering
Meer as 150 vooraf gekonfigureerde Prometheus-statistieke en waarskuwings vir OpenShift-klustermonitering
Voortgesit moet word
Die ryk funksionaliteit van die oplossing en Red Hat se uitgebreide ervaring op die gebied van Kubernetes is die redes waarom OpenShift 'n dominante posisie in die mark behaal het, soos in die figuur hieronder getoon (lees meer ).
“Red Hat lei tans die mark met 'n 44%-aandeel.
Die maatskappy pluk die vrugte van sy kliëntgesentreerde verkoopstrategie, waar hy eers ondernemingsontwikkelaars raadpleeg en oplei en dan na monetisering oorgaan soos die onderneming houers in produksie begin ontplooi.”
(Bron: )
Ons hoop jy het hierdie artikel geniet. In toekomstige plasings in hierdie reeks sal ons die voordele van OpenShift bo Kubernetes in elk van die kategorieë wat hier bespreek word, van nader bekyk.
Bron: will.com