"Cili është ndryshimi midis Kubernetes dhe OpenShift?" – kjo pyetje lind me një qëndrueshmëri të lakmueshme. Edhe pse në realitet kjo është si të pyesësh se si ndryshon një makinë nga një motor. Nëse vazhdojmë analogjinë, atëherë një makinë është një produkt i përfunduar, mund ta përdorni menjëherë, fjalë për fjalë: futuni dhe shkoni. Nga ana tjetër, që një motor të të çojë diku, fillimisht duhet të plotësohet me shumë gjëra të tjera në mënyrë që të marrësh në fund të njëjtën makinë.
Prandaj, Kubernetes është motori rreth të cilit është montuar makina (platforma) e markës OpenShift, e cila ju çon drejt qëllimit tuaj.
Në këtë artikull ne duam t'ju kujtojmë dhe shqyrtojmë pikat kryesore të mëposhtme në pak më shumë detaje:
- Kubernetes është zemra e platformës OpenShift dhe është 100% e certifikuar Kubernetes, plotësisht me burim të hapur dhe pa natyrën më të vogël pronësore. Shkurtimisht:
- API-ja e grupit OpenShift është XNUMX% Kubernetes.
- Nëse kontejneri funksionon në ndonjë sistem tjetër Kubernetes, atëherë ai do të funksionojë në OpenShift pa asnjë ndryshim. Nuk ka nevojë të bëni ndryshime në aplikacione.
- OpenShift jo vetëm që shton veçori dhe funksionalitete të dobishme në Kubernetes. Ashtu si një makinë, OpenShift është jashtë kutisë, mund të vihet në prodhim menjëherë dhe, siç do të tregojmë më poshtë, e bën jetën e një zhvilluesi shumë më të lehtë. Kjo është arsyeja pse OpenShift është i bashkuar në dy persona. Është një platformë e suksesshme dhe e mirënjohur e klasit të ndërmarrjes PaaS nga këndvështrimi i një zhvilluesi. Dhe në të njëjtën kohë, është një zgjidhje super e besueshme Container-as-a-Service nga pikëpamja e funksionimit industrial.
OpenShift është Kubernetes me 100% certifikim CNCF
OpenShift bazohet në . Prandaj, pas trajnimit të duhur, përdoruesit mahniten nga fuqia e kubectl. Dhe ata që kaluan në OpenShift nga Kubernetes Cluster shpesh thonë se sa shumë u pëlqen që pas ridrejtimit të kubeconfig në grupin OpenShift, të gjithë skriptet ekzistuese funksionojnë pa të meta.
Ju ndoshta keni dëgjuar për programin e linjës së komandës të OpenShift të quajtur OC. Ai është plotësisht i përputhshëm me komandën kubectl, plus ofron disa ndihmës të dobishëm që do të jenë të dobishëm kur kryeni një sërë detyrash. Por së pari, pak më shumë rreth përputhshmërisë së OC dhe kubectl:
komandat kubectl
Ekipet OC
kubectl merrni pods
oc merrni pods
kubectl merr hapësirat e emrave
oc merrni hapësira emrash
kubectl krijoj -f vendosje.yaml
oc krijoj -f vendosje.yaml
Ja se si duken rezultatet e përdorimit të kubectl në OpenShift API:
• kubectl get pods – kthen pods siç pritej.
• kubectl get namespaces – kthen hapësirat e emrave siç pritej.
Komanda kubectl create -f mydeployment.yaml krijon burime kubernetes ashtu si në çdo platformë tjetër Kubernetes, siç tregohet në videon më poshtë:
Me fjalë të tjera, të gjitha API-të e Kubernetes janë plotësisht të disponueshme në OpenShift duke ruajtur përputhshmërinë 100%. Ja përse .
OpenShift shton veçori të dobishme në Kubernetes
API-të e Kubernetes janë 100% të disponueshme në OpenShift, por mjetit standard të Kubernetes kubectl i mungon qartë funksionaliteti dhe komoditeti. Kjo është arsyeja pse Red Hat ka shtuar veçori të dobishme dhe mjete të linjës së komandës në Kubernetes, të tilla si OC (shkurt për klientin OpenShift) dhe ODO (OpenShift DO, ky mjet u drejtohet zhvilluesve).
1. Shërbimi OC - një version më i fuqishëm dhe më i përshtatshëm i Kubectl
Për shembull, ndryshe nga kubectl, ai ju lejon të krijoni hapësira të reja emrash dhe të ndërroni lehtësisht kontekstet, dhe gjithashtu ofron një numër komandash të dobishme për zhvilluesit, të tilla si ndërtimi i imazheve të kontejnerëve dhe vendosja e aplikacioneve direkt nga kodi burim ose binarët (Burimi në imazh, s2i).
Le të shohim shembuj se si ndihmësit e integruar dhe funksionaliteti i avancuar i mjetit OC ndihmojnë në thjeshtimin e punës së përditshme.
Shembulli i parë është menaxhimi i hapësirës së emrave. Çdo grup Kubernetes ka gjithmonë hapësira të shumta emrash. Ato zakonisht përdoren për të krijuar mjedise zhvillimi dhe prodhimi, por gjithashtu mund të përdoren, për shembull, për t'i siguruar çdo zhvilluesi një sandbox personal. Në praktikë, kjo rezulton që zhvilluesi të duhet të kalojë shpesh midis hapësirave të emrave, pasi kubectl funksionon në kontekstin e hapësirës aktuale. Prandaj, në rastin e kubectl, njerëzit përdorin në mënyrë aktive skriptet ndihmëse për këtë. Por kur përdorni OC, për të kaluar në hapësirën e dëshiruar, thjesht thoni "oc project namespace".
Nuk e mbani mend si quhet hapësira e emrit që ju nevojitet? Nuk ka problem, thjesht shkruani "oc get projects" për të shfaqur listën e plotë. Pyes veten skeptik se si do të funksionojë kjo nëse keni akses vetëm në një nëngrup të kufizuar të hapësirave të emrave në grup? Epo, sepse kubectl e bën këtë saktë vetëm nëse RBAC ju lejon të shihni të gjitha hapësirat në grup, dhe në grupe të mëdha jo të gjithëve u jepen leje të tilla. Pra, ne përgjigjemi: për OC ky nuk është aspak problem dhe do të prodhojë lehtësisht një listë të plotë në një situatë të tillë. Janë këto gjëra të vogla që përbëjnë orientimin korporativ të Openshift dhe shkallëzueshmërinë e mirë të kësaj platforme për sa i përket përdoruesve dhe aplikacioneve
2. ODO - një version i përmirësuar i kubectl për zhvilluesit
Një shembull tjetër i përmirësimeve të Red Hat OpenShift mbi Kubernetes është mjeti i linjës së komandës ODO. Është krijuar për zhvilluesit dhe ju lejon të vendosni shpejt kodin lokal në një grup të largët OpenShift. Ai gjithashtu mund të thjeshtojë proceset e brendshme për të sinkronizuar menjëherë të gjitha ndryshimet e kodit në kontejnerë në një grup të largët OpenShift pa pasur nevojë të rindërtoni, regjistroni dhe rishpërndani imazhet.
Le të shohim se si OC dhe ODO e bëjnë më të lehtë punën me kontejnerë dhe Kubernetes.
Thjesht krahasoni disa flukse pune kur ato janë ndërtuar në bazë të kubectl dhe kur përdoren OC ose ODO.
• Vendosja e kodit në OpenShift për ata që nuk flasin YAML:
Kubernetes/kubectl
$> klon git
1- Krijoni një Dockerfile që ndërton imazhin nga kodi
-----
NGA nyja
WORKDIR /usr/src/app
KOPJONI paketën*.json ./
COPY index.js ./
KOPJE ./app ./app
RUN instalimin npm
EKSPOSTO 3000
CMD [ "npm", "fillimi"] ————–
2- Ne ndërtojmë imazhin
$>ndërtimi i podmanit...
3- Hyni në regjistër
hyrje në podman...
4- Vendosni imazhin në regjistër
shtytje e podmanit
5- Krijoni skedarë yaml për vendosjen e aplikacionit (deployment.yaml, service.yaml, ingress.yaml) - ky është minimumi absolut
6- Vendosni skedarët e manifestit:
Kubectl zbatoj -f .
OpenShift/oc
$> oc-aplikacion i ri – emri_aplikacioni ynë
OpenShift/odo
$> klon git
$> odo krijoni komponentin nodejs myapp
$>odo shtytje
• Ndërprerësi i kontekstit: ndryshoni hapësirën e emrave të punës ose grupin e punës.
Kubernetes/kubectl
1- Krijo një kontekst në kubeconfig për projektin "myproject"
2- kubectl set-context…
OpenShift/oc
oc projekti "projekti im"
Kontrolli i cilësisë: “Këtu është shfaqur një veçori interesante, ende në versionin alfa. Ndoshta mund ta hedhim në prodhim?”
Imagjinoni të jeni ulur në një makinë garash dhe t'ju thonë: “Ne kemi instaluar një lloj të ri frenash dhe, për të qenë i sinqertë, besueshmëria e tyre nuk është ende në rregull... Por mos u shqetësoni, ne do t'i përmirësojmë në mënyrë aktive gjatë kursit. të kampionatit.” Si ju pëlqen kjo perspektivë? Ne në Red Hat disi nuk jemi shumë të lumtur. 🙂
Prandaj, ne përpiqemi të frenojmë versionet alfa derisa ato të jenë mjaft të pjekura dhe të kemi bërë testime të plota të betejës dhe të ndjejmë se janë të sigurt për t'u përdorur. Zakonisht, gjithçka kalon në fazën e Parapamjes së Dev fillimisht, pastaj përmes dhe vetëm atëherë del si publikim (GA), e cila tashmë është aq e qëndrueshme sa është e përshtatshme për prodhim.
Pse eshte ajo? Sepse, si me zhvillimin e çdo softueri tjetër, jo të gjitha idetë fillestare në Kubernetes arrijnë në publikimin përfundimtar. Ose ata e arrijnë atë dhe madje ruajnë funksionalitetin e synuar, por zbatimi i tyre është rrënjësisht i ndryshëm nga ai në versionin alfa. Me mijëra e mijëra klientë të Red Hat që përdorin OpenShift për të mbështetur ngarkesat e punës kritike për misionin, ne i kushtojmë vëmendje të veçantë stabilitetit të platformës sonë dhe mbështetjes afatgjatë.
Red Hat është e angazhuar të lëshojë shpesh OpenShift dhe të përditësojë versionin e Kubernetes që vjen me të. Për shembull, lëshimi aktual GA i OpenShift 4.3 në kohën e këtij shkrimi përfshin Kubernetes 1.16, i cili është vetëm një njësi prapa versionit në rrjedhën e sipërme të Kubernetes me numër 1.17. Kështu, ne po përpiqemi t'i ofrojmë klientit Kubernetes të klasit të ndërmarrjes dhe të ofrojmë kontroll shtesë të cilësisë ndërsa lëshojmë versione të reja të OpenShift.
Rregullime të softuerit: “Kishte një vrimë në versionin e Kubernetes që kemi në prodhim. Dhe mund ta mbyllni vetëm duke përditësuar tre versione lart. Apo ka ndonjë opsion?
Në projektin me burim të hapur Kubernetes, rregullimet e softuerit zakonisht lëshohen si pjesë e versionit të ardhshëm, ndonjëherë duke mbuluar një ose dy lëshime të mëparshme historike, duke i dhënë mbulim deri në 6 muaj.
Red Hat krenohet me lëshimin e rregullimeve kritike më herët se të tjerët dhe duke ofruar mbështetje për shumë më gjatë. Merrni për shembull cenueshmërinë e përshkallëzimit të privilegjit Kubernetes (): u zbulua në Kubernetes 1.11 dhe rregullimet për lëshimet e mëparshme u lëshuan vetëm deri në versionin 1.10.11, duke e lënë këtë në vrimë në të gjitha versionet e mëparshme të Kubernetes, nga 1.x në 1.9.
Nga ana tjetër, (Kubernetes 1.2 është atje), duke kapur nëntë versione të OpenShift dhe duke demonstruar qartë kujdesin për klientët (më shumë detaje ).
Si OpenShift dhe Red Hat po e çojnë Kubernetes përpara
Red Hat është kontribuesi i dytë më i madh i softuerit në projektin Kubernetes me burim të hapur, pas vetëm Google, me 3 nga 5 zhvilluesit më pjellorë që vijnë nga Red Hat. Një tjetër fakt pak i njohur: shumë funksione kritike u shfaqën në Kubernetes pikërisht me iniciativën e Red Hat, në veçanti, siç janë:
- RBAC. Kubernetes nuk kishte funksione RBAC (ClusterRole, ClusterRoleBinding) derisa inxhinierët e Red Hat vendosën t'i zbatonin ato si pjesë e vetë platformës, dhe jo si funksione shtesë OpenShift. A ka frikë Red Hat të përmirësojë Kubernetes? Sigurisht që jo, sepse Red Hat ndjek në mënyrë rigoroze parimet e burimit të hapur dhe nuk luan lojëra Open Core. Përmirësimet dhe risitë që drejtohen nga komunitetet e zhvillimit, në vend të atyre të pronarit, janë më të zbatueshme dhe më gjerësisht të miratuara, gjë që përputhet mirë me qëllimin tonë kryesor për ta bërë softuerin me burim të hapur më të dobishëm për klientët tanë.
- Politikat e sigurisë për pods (Pod Security Policies). Ky koncept i ekzekutimit të sigurt të aplikacioneve brenda pods u zbatua fillimisht në OpenShift me emrin SCC (Security Context Constraints). Dhe si në shembullin e mëparshëm, Red Hat vendosi t'i prezantojë këto zhvillime në projektin e hapur Kubernetes në mënyrë që të gjithë t'i përdorin ato.
Kjo seri shembujsh mund të vazhdojë, por ne thjesht donim të tregonim se Red Hat është vërtet e përkushtuar për të zhvilluar Kubernetes dhe për ta bërë atë më të mirë për të gjithë.
Është e qartë se OpenShift është Kubernetes. Cilat janë dallimet? 🙂
Shpresojmë që duke lexuar deri këtu të keni kuptuar se Kubernetes është komponenti kryesor i OpenShift. Kryesorja, por larg nga e vetmja. Me fjalë të tjera, thjesht instalimi i Kubernetes nuk do t'ju japë një platformë të klasit të ndërmarrjes. Do t'ju duhet të shtoni vërtetimin, rrjetëzimin, sigurinë, monitorimin, menaxhimin e regjistrave dhe më shumë. Plus, do t'ju duhet të bëni disa zgjedhje të vështira nga numri i madh i mjeteve në dispozicion (për të vlerësuar diversitetin e ekosistemit, thjesht hidhni një sy ) dhe sigurojnë disi konsistencë dhe koherencë në mënyrë që ato të funksionojnë si një. Përveç kësaj, do t'ju duhet rregullisht të kryeni përditësime dhe testime të regresionit sa herë që lëshohet një version i ri i ndonjë prej komponentëve që përdorni. Domethënë, përveç krijimit dhe mirëmbajtjes së vetë platformës, do t'ju duhet të merreni edhe me të gjithë këtë softuer. Nuk ka gjasa që do të mbetet shumë kohë për të zgjidhur problemet e biznesit dhe për të arritur avantazhe konkurruese.
Por në rastin e OpenShift, Red Hat merr mbi vete të gjitha këto kompleksitete dhe thjesht ju jep një platformë të plotë funksionale, e cila përfshin jo vetëm vetë Kubernetes, por edhe të gjithë grupin e mjeteve të nevojshme me burim të hapur që e kthejnë Kubernetes në një klasë të vërtetë sipërmarrjeje. zgjidhje që mund ta lëshoni menjëherë dhe plotësisht me qetësi në prodhim. Dhe sigurisht, nëse keni disa nga grupet tuaja të teknologjisë, atëherë mund të integroni OpenShift në zgjidhjet ekzistuese.
Hidhini një sy fotografisë së mësipërme: gjithçka që është jashtë drejtkëndëshit të Kubernetes është ajo ku Red Hat shton funksionalitetin që Kubernetes nuk e ka, siç thonë ata, dizajn të veçantë. Dhe tani ne do të shikojmë në kryesore të këtyre zonave.
1. Sistemi operativ i fortë si bazë: RHEL CoreOS ose RHEL
Red Hat ka qenë ofruesi kryesor i shpërndarjeve Linux për aplikacione kritike për biznesin për më shumë se 20 vjet. Përvoja jonë e akumuluar dhe e përditësuar vazhdimisht në këtë fushë na lejon të ofrojmë një bazë vërtet të besueshme dhe të besueshme për funksionimin industrial të kontejnerëve. RHEL CoreOS përdor të njëjtin kernel si RHEL, por është i optimizuar kryesisht për detyra të tilla si drejtimi i kontejnerëve dhe ekzekutimi i grupeve Kubernetes: madhësia e reduktuar dhe pandryshueshmëria e tij e bëjnë më të lehtë konfigurimin e grupimeve, shkallëzimin automatik, vendosjen e arnimeve, etj. Të gjitha këto veçori e bëjnë atë një bazë ideale për të ofruar të njëjtën përvojë përdoruesi me OpenShift në një gamë të gjerë mjedisesh kompjuterike, nga metali i zhveshur në renë private dhe publike.
2. Automatizimi i operacioneve të TI
Automatizimi i proceseve të instalimit dhe operacioneve të ditës 4 (domethënë operacionet e përditshme) është pika e fortë e OpenShift, duke e bërë shumë më të lehtë administrimin, përditësimin dhe ruajtjen e performancës së platformës së kontejnerit në nivelin më të lartë. Kjo arrihet përmes mbështetjes për operatorët Kubernetes në nivelin e kernelit OpenShift XNUMX.
OpenShift 4 është gjithashtu një ekosistem i tërë zgjidhjesh i bazuar në operatorët Kubernetes, i zhvilluar si nga vetë Red Hat ashtu edhe nga partnerë të palëve të treta (shih. Red Hat, ose dyqan operatori , krijuar nga Red Hat për zhvilluesit e palëve të treta).
Katalogu i integruar OpenShift 4 përfshin më shumë se 180 operatorë Kubernetes
3. Mjetet e Zhvilluesit
Që nga viti 2011, OpenShift ka qenë i disponueshëm si një platformë PaaS (Platforma-as-a-Service) që e bën jetën shumë më të lehtë për zhvilluesit, i ndihmon ata të përqendrohen në kodim dhe ofron mbështetje vendase për gjuhë programimi si Java, Node.js , PHP, Ruby, Python, Go, si dhe shërbime të integrimit dhe shpërndarjes së vazhdueshme CI/CD, bazat e të dhënave, etj. Ofertat e OpenShift 4 , i cili përfshin më shumë se 100 shërbime të bazuara në operatorët Kubernetes të zhvilluara nga Red Hat dhe partnerët tanë.
Ndryshe nga Kubernetes, OpenShift 4 ka një GUI të dedikuar (), i cili i ndihmon zhvilluesit të vendosin pa mundim aplikacione nga burime të ndryshme (git, regjistrat e jashtëm, Dockerfile, etj.) në hapësirat e tyre të emrave dhe vizualizon qartë marrëdhëniet midis komponentëve të aplikacionit.
Për më tepër, OpenShift ofron një grup mjetesh zhvillimi Codeready, i cili, në veçanti, përfshin , një IDE plotësisht i kontejneruar me një ndërfaqe në internet që funksionon drejtpërdrejt në krye të OpenShift dhe zbaton një qasje IDE-si-një shërbim. Nga ana tjetër, për ata që duan të punojnë rreptësisht në modalitetin lokal, ekziston Codeready Containers, një version plotësisht funksional i OpenShift 4 që mund të vendoset në një laptop.
IDE e integruar si një shërbim për zhvillim efikas në platformën Kubernetes/OpenShift
OpenShift ofron një sistem të plotë CI/CD menjëherë nga kutia, ose bazuar në Jenkins të kontejneruar dhe një shtesë për të punuar me tubacione, ose një sistem CI/CD të orientuar nga Kubernetes (aktualisht në versionin paraprak Tech). Të dyja këto zgjidhje integrohen plotësisht me konsolën OpenShift, duke ju lejuar të ekzekutoni aktivizuesit e tubacionit, të shikoni vendosjet, regjistrat dhe më shumë.
4. Mjetet e aplikimit
OpenShift ju lejon të vendosni aplikacione tradicionale shtetërore dhe zgjidhje të bazuara në renë kompjuterike të bazuara në arkitektura të reja, të tilla si mikroshërbime ose pa server. Zgjidhja OpenShift Service Mesh vjen menjëherë nga kutia me mjetet kryesore për mirëmbajtjen e mikroshërbimeve, të tilla si Istio, Kiali dhe Jaeger. Nga ana tjetër, zgjidhja OpenShift Serverless përfshin jo vetëm Knative, por edhe mjete si Keda të krijuara si pjesë e një nisme të përbashkët me Microsoft për të ofruar funksione Azure në platformën OpenShift.
Zgjidhja e integruar OpenShift ServiceMesh (Istio, Kiali, Jaeger) do të jetë e dobishme gjatë zhvillimit të mikroshërbimeve
Për të kapërcyer hendekun midis aplikacioneve të vjetra dhe kontejnerëve, OpenShift tani lejon migrimin e makinës virtuale në platformën OpenShift duke përdorur Virtualizimin Native të Container (aktualisht në TechPreview), duke i bërë aplikacionet hibride realitet dhe duke lehtësuar migrimin e tyre midis reve të ndryshme, private dhe publike.
Makina virtuale virtuale Windows 2019 që funksionon në OpenShift nëpërmjet Virtualizimit Nativ të Kontejnerit (aktualisht në versionin e paraafishimit Tech)
5. Mjetet për grupime
Çdo platformë e klasës së ndërmarrjes duhet të ketë monitorim dhe shërbime të centralizuara të regjistrimit, mekanizma sigurie, vërtetim dhe autorizim dhe mjete të menaxhimit të rrjetit. Dhe OpenShift i ofron të gjitha këto jashtë kutisë, dhe është e gjitha 100% me burim të hapur, duke përfshirë zgjidhje të tilla si ElasticSearch, Prometheus, Grafana. Të gjitha këto zgjidhje vijnë me tabela, metrikë dhe sinjalizime që janë ndërtuar dhe konfiguruar tashmë duke përdorur ekspertizën e gjerë të monitorimit të grupeve të Red Hat, duke ju lejuar të kontrolloni dhe monitoroni në mënyrë efektive mjedisin tuaj të prodhimit që në fillim.
OpenShift gjithashtu vjen standard me gjëra kaq të rëndësishme për klientët e korporatave si vërtetimi me një ofrues të integruar oauth, integrimi me ofruesit e kredencialeve, duke përfshirë LDAP, ActiveDirectory, OpenID Connect dhe shumë më tepër.
Paneli i parakonfiguruar i Grafana për monitorimin e grupit OpenShift
Mbi 150 metrikë dhe sinjalizime të para-konfiguruara të Prometheus për monitorimin e grupit OpenShift
Për të vazhduar
Funksionaliteti i pasur i zgjidhjes dhe përvoja e gjerë e Red Hat në fushën e Kubernetes janë arsyet pse OpenShift ka arritur një pozicion dominues në treg, siç tregohet në figurën më poshtë (lexo më shumë ).
“Red Hat aktualisht kryeson tregun me një pjesë prej 44%.
Kompania po korr përfitimet e strategjisë së saj të shitjeve të përqendruara te klientët, ku fillimisht konsultohet dhe trajnon zhvilluesit e ndërmarrjeve dhe më pas kalon drejt fitimit të parave ndërsa ndërmarrja fillon të vendosë kontejnerë në prodhim.
(Një burim: )
Shpresojmë që ju ka pëlqyer ky artikull. Në postimet e ardhshme në këtë seri, ne do të hedhim një vështrim më të afërt në avantazhet e OpenShift ndaj Kubernetes në secilën nga kategoritë e diskutuara këtu.
Burimi: www.habr.com