«Ո՞րն է տարբերությունը Kubernetes-ի և OpenShift-ի միջև»: – այս հարցը ծագում է նախանձելի հետեւողականությամբ։ Չնայած իրականում սա նման է այն հարցին, թե ինչով է մեքենան տարբերվում շարժիչից։ Եթե շարունակենք անալոգիան, ապա մեքենան պատրաստի արտադրանք է, դուք կարող եք օգտագործել այն անմիջապես, բառացիորեն. մտեք և գնացեք: Մյուս կողմից, որպեսզի շարժիչը ձեզ ինչ-որ տեղ տանի, նախ պետք է այն լրացնել շատ այլ բաներով, որպեսզի ի վերջո ստանաք նույն մեքենան:
Ուստի Kubernetes-ն այն շարժիչն է, որի շուրջ հավաքվում է OpenShift ապրանքանիշի մեքենան (հարթակը), որը ձեզ տանում է դեպի ձեր նպատակը։
Այս հոդվածում մենք ուզում ենք հիշեցնել ձեզ և մի փոքր ավելի մանրամասն ուսումնասիրել հետևյալ հիմնական կետերը.
- Kubernetes-ը OpenShift պլատֆորմի սիրտն է, և այն 100% հավաստագրված Kubernetes է, ամբողջովին բաց կոդով և առանց նվազագույն սեփականության բնույթի: Համառոտ.
- OpenShift կլաստերի API-ն XNUMX% Kubernetes է:
- Եթե կոնտեյները աշխատում է ցանկացած այլ Kubernetes համակարգով, ապա այն կաշխատի OpenShift-ով առանց որևէ փոփոխության: Հավելվածներում փոփոխություններ կատարելու կարիք չկա։
- OpenShift-ը ոչ միայն օգտակար հատկություններ և գործառույթներ է ավելացնում Kubernetes-ին: Մեքենայի նման, OpenShift-ը դուրս է եկել տուփից, կարող է անմիջապես արտադրվել և, ինչպես ցույց կտանք ստորև, շատ ավելի հեշտացնում է ծրագրավորողի կյանքը: Այդ իսկ պատճառով OpenShift-ը միավորված է երկու անձի մեջ։ Դա և՛ հաջող, և՛ հայտնի ձեռնարկատիրական դասի PaaS հարթակ է մշակողի տեսանկյունից: Եվ միևնույն ժամանակ, այն գերհուսալի Container-as-a-Service լուծում է արդյունաբերական շահագործման տեսանկյունից։
OpenShift-ը Kubernetes-ն է՝ 100% CNCF հավաստագրմամբ
OpenShift-ը հիմնված է . Հետևաբար, պատշաճ մարզվելուց հետո օգտատերերը զարմանում են kubectl-ի հզորությամբ։ Եվ նրանք, ովքեր անցել են OpenShift-ին Kubernetes Cluster-ից, հաճախ ասում են, թե որքան են իրենց իսկապես դուր գալիս kubeconfig-ը OpenShift կլաստերին վերահասցեավորելուց հետո, բոլոր առկա սկրիպտներն աշխատում են անթերի:
Դուք հավանաբար լսել եք OpenShift-ի հրամանի տող OC կոչվող օգտակար ծրագրի մասին: Այն լիովին համատեղելի է kubectl-ի հետ, ինչպես նաև առաջարկում է մի քանի օգտակար օգնականներ, որոնք օգտակար կլինեն մի շարք առաջադրանքներ կատարելիս: Բայց նախ, մի փոքր ավելին OC-ի և kubectl-ի համատեղելիության մասին.
kubectl հրամանները
OC թիմեր
kubectl- ը պատիճներ ստացեք
oc ստանալ pods
kubectl-ը ստանում է անունների տարածքներ
oc ստանալ անունների տարածքներ
kubectl ստեղծել -f deployment.yaml
oc ստեղծել -f deployment.yaml
Ահա թե ինչպիսին են OpenShift API-ում kubectl-ի օգտագործման արդյունքները.
• kubectl get pods – վերադարձնում է պատիճները, ինչպես սպասվում էր:
• kubectl get namespaces – վերադարձնում է անունների տարածքները, ինչպես սպասվում էր:
Kubectl create -f mydeployment.yaml հրամանը ստեղծում է kubernetes ռեսուրսներ այնպես, ինչպես ցանկացած այլ Kubernetes հարթակում, ինչպես ցույց է տրված ստորև ներկայացված տեսանյութում.
Այլ կերպ ասած, բոլոր Kubernetes API-ները լիովին հասանելի են OpenShift-ում՝ պահպանելով 100% համատեղելիությունը: Ահա թե ինչու .
OpenShift-ը օգտակար հատկություններ է ավելացնում Kubernetes-ին
Kubernetes API-ները 100% հասանելի են OpenShift-ում, սակայն ստանդարտ Kubernetes կոմունալ kubectl-ն ակնհայտորեն չունի ֆունկցիոնալություն և հարմարավետություն: Ահա թե ինչու Red Hat-ն ավելացրել է օգտակար գործառույթներ և հրամանների տող գործիքներ Kubernetes-ում, ինչպիսիք են OC (կրճատ՝ OpenShift հաճախորդը) և ODO (OpenShift DO, այս օգտակար ծրագիրը նախատեսված է մշակողների համար):
1. OC կոմունալ - Kubectl-ի ավելի հզոր և հարմար տարբերակ
Օրինակ, ի տարբերություն kubectl-ի, այն թույլ է տալիս ստեղծել նոր անունների տարածքներ և հեշտությամբ փոխարկել համատեքստերը, ինչպես նաև առաջարկում է մի շարք օգտակար հրամաններ ծրագրավորողների համար, ինչպիսիք են կոնտեյների պատկերների կառուցումը և հավելվածների տեղակայումը անմիջապես աղբյուրի կոդից կամ երկուականներից (Աղբյուր-պատկեր, s2i):
Եկեք նայենք օրինակներին, թե ինչպես են ներկառուցված օգնականները և OC կոմունալ հավելվածի առաջադեմ ֆունկցիոնալությունը օգնում պարզեցնել ամենօրյա աշխատանքը:
Առաջին օրինակը անվանատարածքի կառավարումն է: Յուրաքանչյուր Kubernetes կլաստեր միշտ ունի բազմաթիվ անունների տարածքներ: Դրանք սովորաբար օգտագործվում են զարգացման և արտադրության միջավայրեր ստեղծելու համար, բայց կարող են օգտագործվել նաև, օրինակ, յուրաքանչյուր ծրագրավորողի անձնական ավազատուփ տրամադրելու համար: Գործնականում դա հանգեցնում է նրան, որ մշակողը ստիպված է լինում հաճախակի անցնել անունների տարածքների միջև, քանի որ kubectl-ն աշխատում է ընթացիկ տարածության համատեքստում: Հետեւաբար, kubectl-ի դեպքում մարդիկ դրա համար ակտիվորեն օգտագործում են օգնական սկրիպտներ։ Բայց երբ օգտագործում եք OC, ցանկալի տարածքին անցնելու համար պարզապես ասեք «oc project namespace»:
Չե՞ք հիշում, թե ինչ է կոչվում ձեզ անհրաժեշտ անվանատարածքը: Խնդիր չկա, պարզապես մուտքագրեք «oc get projects»՝ ամբողջական ցանկը ցուցադրելու համար: Թերահավատորեն մտածում եք, թե ինչպես դա կաշխատի, եթե դուք մուտք ունեք միայն կլաստերի անունների տարածքների սահմանափակ ենթաբազմության: Դե, քանի որ kubectl-ը դա ճիշտ է անում միայն այն դեպքում, եթե RBAC-ը թույլ է տալիս տեսնել կլաստերի բոլոր տարածքները, իսկ մեծ կլաստերներում ոչ բոլորին են տրված նման թույլտվություններ: Այսպիսով, մենք պատասխանում ենք. OC-ի համար դա ամենևին էլ խնդիր չէ, և այն հեշտությամբ կստեղծի ամբողջական ցուցակը նման իրավիճակում: Հենց այս փոքրիկ բաներն են կազմում Openshift-ի կորպորատիվ կողմնորոշումը և այս հարթակի լավ լայնածավալությունը օգտատերերի և հավելվածների առումով:
2. ODO - kubectl-ի բարելավված տարբերակ մշակողների համար
Red Hat OpenShift-ի Kubernetes-ի նկատմամբ բարելավումների մեկ այլ օրինակ է ODO հրամանի տողի օգտակար ծրագիրը: Այն նախատեսված է մշակողների համար և թույլ է տալիս արագ տեղակայել տեղական ծածկագիրը հեռավոր OpenShift կլաստերի վրա: Այն կարող է նաև պարզեցնել ներքին գործընթացները՝ կոդի բոլոր փոփոխությունները ակնթարթորեն համաժամեցնելու հեռավոր OpenShift կլաստերի բեռնարկղերի հետ՝ առանց պատկերների վերակառուցման, գրանցման և վերաբաշխման:
Եկեք տեսնենք, թե ինչպես են OC-ն և ODO-ն հեշտացնում բեռնարկղերի և Kubernetes-ի հետ աշխատանքը:
Պարզապես համեմատեք մի քանի աշխատանքային հոսքեր, երբ դրանք կառուցված են kubectl-ի հիման վրա, և երբ օգտագործվում են OC կամ ODO:
• Կոդի տեղակայում OpenShift-ում նրանց համար, ովքեր չեն խոսում YAML.
Kubernetes / kubectl
$>git կլոն
1- Ստեղծեք Dockerfile, որը պատկերը կառուցում է կոդից
-----
FROM հանգույցից
WORKDIR /usr/src/app
COPY փաթեթը*.json ./
COPY index.js ./
COPY ./app ./app
RUN npm տեղադրում
ԲԱՑԱՀԱՅՏՈՒՄ 3000
CMD [ «npm», «start»] ————–
2- Կառուցում ենք պատկերը
$>podman build...
3- Մուտք գործեք գրանցամատյան
podman մուտք...
4- Տեղադրեք պատկերը գրանցամատյանում
podman հրում
5- Ստեղծեք yaml ֆայլեր հավելվածների տեղակայման համար (deployment.yaml, service.yaml, ingress.yaml) - սա բացարձակ նվազագույնն է
6- Տեղադրեք մանիֆեստի ֆայլերը.
Kubectl դիմել -f .
OpenShift/oc
$> oc նոր հավելված – մեր_հայտի_անունը
OpenShift/odo
$>git կլոն
$> odo ստեղծել բաղադրիչ nodejs myapp
$>odo հրում
• Համատեքստային փոխարկիչ. փոխել աշխատանքային անվանատարածքը կամ աշխատանքային կլաստերը:
Kubernetes / kubectl
1- Ստեղծեք համատեքստ kubeconfig-ում «myproject» նախագծի համար
2- kubectl set-context…
OpenShift/oc
oc նախագիծ «myproject»
Որակի վերահսկում. «Այստեղ հայտնվեց մեկ հետաքրքիր առանձնահատկություն, որը դեռ ալֆա տարբերակում է: Միգուցե մենք այն թողարկե՞նք արտադրության մեջ»։
Պատկերացրեք, որ նստած եք մրցարշավային մեքենայում և ձեզ ասում են. «Մենք նոր տեսակի արգելակներ ենք տեղադրել, և, ճիշտն ասած, դրանց հուսալիությունը դեռևս լավ չէ... Բայց մի անհանգստացեք, մենք ակտիվորեն կբարելավենք դրանք հենց այդ ընթացքում։ առաջնությունը»։ Ինչպե՞ս եք սիրում այս հեռանկարը: Մենք Red Hat-ում ինչ-որ կերպ այնքան էլ երջանիկ չենք: 🙂
Հետևաբար, մենք փորձում ենք զսպել ալֆա տարբերակները, քանի դեռ դրանք բավականաչափ հասուն չեն, և մենք կատարել ենք մարտական մանրակրկիտ փորձարկում և զգալ, որ դրանք անվտանգ են օգտագործելու համար: Սովորաբար, ամեն ինչ սկզբում անցնում է Dev Preview փուլով, այնուհետև և միայն դրանից հետո դուրս է գալիս որպես հրապարակային թողարկում (GA), որն արդեն այնքան կայուն է, որ հարմար է արտադրության համար։
Ինչո՞ւ է այդպես։ Քանի որ, ինչպես ցանկացած այլ ծրագրաշարի մշակման դեպքում, Kubernetes-ում ոչ բոլոր սկզբնական գաղափարներն են հասնում վերջնական թողարկմանը: Կամ նրանք հասնում են դրան և նույնիսկ պահպանում են նախատեսված ֆունկցիոնալությունը, սակայն դրանց իրականացումը արմատապես տարբերվում է ալֆա տարբերակում եղածից: Քանի որ հազարավոր հազարավոր Red Hat-ի հաճախորդներ օգտագործում են OpenShift-ը՝ առաքելության համար կարևոր աշխատանքային բեռները աջակցելու համար, մենք հատուկ շեշտը դնում ենք մեր հարթակի կայունության և երկարաժամկետ աջակցության վրա:
Red Hat-ը պարտավորվում է հաճախակի թողարկել OpenShift-ը և թարմացնել Kubernetes-ի այն տարբերակը, որը գալիս է դրան: Օրինակ՝ OpenShift 4.3-ի ընթացիկ GA թողարկումը այս գրելու պահին ներառում է Kubernetes 1.16-ը, որը միայն մեկ միավոր է զիջում Kubernetes-ի վերին հոսանքով տարբերակին՝ 1.17 համարով: Այսպիսով, մենք փորձում ենք հաճախորդին տրամադրել ձեռնարկատիրական կարգի Kubernetes և ապահովել որակի լրացուցիչ հսկողություն OpenShift-ի նոր տարբերակների թողարկման ժամանակ։
Ծրագրային ապահովման ուղղումներ. Եվ դուք կարող եք փակել այն միայն թարմացնելով երեք տարբերակ: Կամ կա՞ն տարբերակներ։
Kubernetes-ի բաց կոդով նախագծում ծրագրային ապահովման շտկումները սովորաբար թողարկվում են որպես հաջորդ թողարկման մաս՝ երբեմն ընդգրկելով մեկ կամ երկու նախորդ հանգրվանային թողարկումները՝ ապահովելով ծածկույթը մինչև 6 ամիս:
Red Hat-ը հպարտանում է նրանով, որ թողարկել է կարևոր ուղղումներ ավելի վաղ, քան մյուսները և տրամադրել աջակցություն շատ ավելի երկար: Օրինակ վերցրեք Kubernetes արտոնությունների սրման խոցելիությունը (): այն հայտնաբերվել է Kubernetes 1.11-ում, իսկ նախորդ թողարկումների շտկումները թողարկվել են միայն մինչև 1.10.11 տարբերակը՝ թողնելով այս մեկը Kubernetes-ի բոլոր նախորդ թողարկումներում՝ 1.x-ից մինչև 1.9:
Իր հերթին, (Kubernetes 1.2-ն այնտեղ է), գրավելով ինը OpenShift թողարկում և հստակորեն ցուցաբերելով հոգատարություն հաճախորդների նկատմամբ (ավելի մանրամասն ).
Ինչպես են OpenShift-ը և Red Hat-ը առաջ մղում Kubernetes-ը
Red Hat-ը երկրորդ խոշորագույն ծրագրային ներդրողն է բաց կոդով Kubernetes նախագծին, զիջելով միայն Google-ին, 3 ամենաարդյունավետ մշակողներից 5-ը գալիս են Red Hat-ից: Մեկ այլ քիչ հայտնի փաստ. Kubernetes-ում հայտնվեցին շատ կարևոր գործառույթներ հենց Red Hat-ի նախաձեռնությամբ, մասնավորապես, ինչպիսիք են.
- RBAC. Kubernetes-ը չուներ RBAC գործառույթներ (ClusterRole, ClusterRoleBinding), քանի դեռ Red Hat-ի ինժեներները որոշել էին դրանք իրականացնել որպես հարթակի մաս, այլ ոչ որպես լրացուցիչ OpenShift գործառույթ: Red Hat-ը վախենում է բարելավել Kubernetes-ը: Իհարկե ոչ, քանի որ Red Hat-ը խստորեն հետևում է բաց կոդով սկզբունքներին և չի խաղում Open Core խաղեր: Բարելավումները և նորամուծությունները, որոնք առաջնորդվում են զարգացման համայնքներով, այլ ոչ թե սեփականության, ավելի կենսունակ են և ավելի լայնորեն ընդունված, ինչը լավ համահունչ է մեր հիմնական նպատակին՝ բաց կոդով ծրագրակազմն ավելի օգտակար դարձնել մեր հաճախորդների համար:
- Անվտանգության քաղաքականություն pods-ի համար (Pod Security Policies): Հավելվածների անվտանգ գործարկման այս հայեցակարգը սկզբնապես ներդրվել է OpenShift-ում SCC (Անվտանգության համատեքստի սահմանափակումներ) անվան տակ: Եվ ինչպես նախորդ օրինակում, Red Hat-ը որոշեց այս զարգացումները ներմուծել բաց Kubernetes նախագծում, որպեսզի բոլորը կարողանան օգտագործել դրանք:
Օրինակների այս շարքը կարելի է շարունակել, բայց մենք պարզապես ուզում էինք ցույց տալ, որ Red Hat-ը իսկապես հավատարիմ է Kubernetes-ի զարգացմանը և այն ավելի լավը դարձնելու բոլորի համար:
Պարզ է, որ OpenShift-ը Kubernetes է: Որո՞նք են տարբերությունները: 🙂
Հուսով ենք, որ այսքանը կարդալով դուք հասկացաք, որ Kubernetes-ը OpenShift-ի հիմնական բաղադրիչն է: Հիմնականը, բայց հեռու միակից։ Այլ կերպ ասած, պարզապես Kubernetes տեղադրելը ձեզ չի տա ձեռնարկության կարգի հարթակ: Դուք պետք է ավելացնեք նույնականացում, ցանց, անվտանգություն, մոնիտորինգ, գրանցամատյանների կառավարում և այլն: Բացի այդ, դուք պետք է որոշ կոշտ ընտրություն կատարեք առկա մեծ թվով գործիքներից (էկոհամակարգի բազմազանությունը գնահատելու համար պարզապես նայեք ) և ինչ-որ կերպ ապահովել հետևողականություն և համախմբվածություն, որպեսզի նրանք աշխատեն որպես մեկ: Բացի այդ, դուք պարբերաբար պետք է կատարեք թարմացումներ և ռեգրեսիայի թեստավորում, երբ թողարկվի ձեր օգտագործած որևէ բաղադրիչի նոր տարբերակը: Այսինքն, բացի բուն հարթակը ստեղծելուց և պահպանելուց, դուք նույնպես պետք է գործ ունենաք այս ամբողջ ծրագրաշարի հետ: Դժվար թե շատ ժամանակ մնա բիզնեսի խնդիրները լուծելու և մրցակցային առավելությունների հասնելու համար։
Բայց OpenShift-ի դեպքում Red Hat-ն իր վրա վերցնում է այս բոլոր բարդությունները և պարզապես ձեզ տալիս է ֆունկցիոնալ ամբողջական հարթակ, որը ներառում է ոչ միայն Kubernetes-ը, այլև անհրաժեշտ բաց կոդով գործիքների ամբողջ փաթեթը, որը Kubernetes-ը վերածում է իրական ձեռնարկատիրական դասի: լուծում, որը դուք կարող եք անմիջապես և ամբողջովին հանգիստ գործարկել արտադրության մեջ: Եվ, իհարկե, եթե դուք ունեք ձեր սեփական տեխնոլոգիական կույտերը, ապա կարող եք ինտեգրել OpenShift-ը գոյություն ունեցող լուծումների մեջ:
Նայեք վերևի նկարին. այն ամենը, ինչ գտնվում է Kubernetes-ի ուղղանկյունից դուրս, այնտեղ է, որտեղ Red Hat-ն ավելացնում է գործառույթներ, որոնք Kubernetes-ը չունի, ինչպես ասում են, ըստ դիզայնի: Եվ հիմա մենք կանդրադառնանք այս ոլորտներից հիմնականին:
1. Կայուն ՕՀ որպես հիմք՝ RHEL CoreOS կամ RHEL
Red Hat-ը եղել է Linux բաշխումների առաջատար մատակարարը բիզնեսի համար կարևոր հավելվածների համար ավելի քան 20 տարի: Այս ոլորտում մեր կուտակված և մշտապես թարմացվող փորձը թույլ է տալիս մեզ առաջարկել իսկապես հուսալի և վստահելի հիմք բեռնարկղերի արդյունաբերական շահագործման համար: RHEL CoreOS-ն օգտագործում է նույն միջուկը, ինչ RHEL-ը, սակայն օպտիմիզացված է հիմնականում այնպիսի առաջադրանքների համար, ինչպիսիք են բեռնարկղերի գործարկումը և Kubernetes կլաստերների գործարկումը. դրա կրճատված չափը և անփոփոխելիությունը հեշտացնում են կլաստերների տեղադրումը, ավտոմատ մասշտաբավորումը, տեղակայումը և այլն: Այս բոլոր հատկանիշները դարձնում են այն: իդեալական հիմք OpenShift-ով օգտատերերի միևնույն փորձառությունն ապահովելու համար հաշվողական միջավայրերի լայն շրջանակում՝ մերկ մետաղից մինչև մասնավոր և հանրային ամպ:
2. ՏՏ գործառնությունների ավտոմատացում
Տեղադրման գործընթացների և օրվա երկրորդ գործողությունների ավտոմատացումը (այսինքն՝ ամենօրյա գործողությունները) OpenShift-ի ուժեղ կողմն է, ինչը շատ ավելի հեշտ է դարձնում կոնտեյների հարթակի կառավարումը, թարմացումը և ամենաբարձր մակարդակի պահպանումը: Սա ձեռք է բերվում Kubernetes օպերատորների աջակցության միջոցով OpenShift 4 միջուկի մակարդակում:
OpenShift 4-ը նաև լուծումների մի ամբողջ էկոհամակարգ է, որը հիմնված է Kubernetes օպերատորների վրա, որը մշակվել է ինչպես Red Hat-ի, այնպես էլ երրորդ կողմի գործընկերների կողմից (տես. Red Hat, կամ օպերատորի խանութ , ստեղծված Red Hat-ի կողմից երրորդ կողմի մշակողների համար):
Ինտեգրված OpenShift 4 կատալոգը ներառում է ավելի քան 180 Kubernetes օպերատորներ
3. Մշակողի գործիքներ
2011 թվականից OpenShift-ը հասանելի է որպես PaaS (Platform-as-a-Service) հարթակ, որը շատ ավելի հեշտ է դարձնում ծրագրավորողների կյանքը, օգնում է նրանց կենտրոնանալ կոդավորման վրա և առաջարկում է բնիկ աջակցություն ծրագրավորման լեզուների համար, ինչպիսիք են Java-ն, Node.js-ը: , PHP, Ruby, Python, Go, ինչպես նաև CI/CD շարունակական ինտեգրման և առաքման ծառայություններ, տվյալների բազաներ և այլն: OpenShift 4-ի առաջարկները , որը ներառում է ավելի քան 100 ծառայություններ՝ հիմնված Kubernetes օպերատորների վրա, որոնք մշակվել են Red Hat-ի և մեր գործընկերների կողմից։
Ի տարբերություն Kubernetes-ի, OpenShift 4-ն ունի հատուկ GUI (), որն օգնում է մշակողներին առանց ջանքերի տեղակայել հավելվածներ տարբեր աղբյուրներից (git, արտաքին ռեգիստրներ, Dockerfile և այլն) իրենց անվանատարածքներում և հստակ պատկերացնել հավելվածի բաղադրիչների միջև փոխհարաբերությունները:
Բացի այդ, OpenShift-ն առաջարկում է Codeready մշակման գործիքների հավաքածու, որը, մասնավորապես, ներառում է , լիովին կոնտեյներացված IDE՝ վեբ ինտերֆեյսով, որն աշխատում է անմիջապես OpenShift-ի վերևում և իրականացնում է IDE-որպես ծառայություն: Մյուս կողմից, նրանց համար, ովքեր ցանկանում են խստորեն աշխատել տեղական ռեժիմով, կա Codeready Containers՝ OpenShift 4-ի լիարժեք ֆունկցիոնալ տարբերակը, որը կարող է տեղակայվել նոութբուքի վրա:
Ինտեգրված IDE որպես ծառայություն արդյունավետ զարգացման համար Kubernetes/OpenShift հարթակում
OpenShift-ն առաջարկում է ամբողջական CI/CD համակարգ անմիջապես տուփից դուրս՝ հիմնված կոնտեյներային Jenkins-ի և plugin-ի վրա: խողովակաշարերի կամ Kubernetes-ի վրա հիմնված CI/CD համակարգի հետ աշխատելու համար (ներկայումս Tech նախադիտման տարբերակում): Այս երկու լուծումներն էլ լիովին ինտեգրվում են OpenShift վահանակի հետ՝ թույլ տալով գործարկել խողովակաշարի գործարկիչները, դիտել տեղակայումները, տեղեկամատյանները և այլն:
4. Կիրառական գործիքներ
OpenShift-ը թույլ է տալիս տեղակայել ինչպես ավանդական պետական հավելվածներ, այնպես էլ ամպի վրա հիմնված լուծումներ՝ հիմնված նոր ճարտարապետությունների վրա, ինչպիսիք են միկրոծառայությունները կամ առանց սերվերի: OpenShift Service Mesh լուծումը գալիս է անմիջապես տուփից միկրոծառայությունների պահպանման հիմնական գործիքներով, ինչպիսիք են Istio-ն, Kiali-ն և Jaeger-ը: Իր հերթին, OpenShift Serverless լուծումը ներառում է ոչ միայն Knative-ը, այլ նաև այնպիսի գործիքներ, ինչպիսին Keda-ն է, որը ստեղծվել է Microsoft-ի հետ համատեղ նախաձեռնության շրջանակներում՝ OpenShift հարթակում Azure գործառույթներ ապահովելու համար:
Ինտեգրված OpenShift ServiceMesh լուծումը (Istio, Kiali, Jaeger) օգտակար կլինի միկրոսերվիսներ մշակելիս։
Հնացած հավելվածների և կոնտեյներների միջև բացը կամրջելու համար OpenShift-ն այժմ թույլ է տալիս վիրտուալ մեքենաների միգրացիան OpenShift հարթակ՝ օգտագործելով Container Native Virtualization (ներկայումս TechPreview-ում)՝ իրականություն դարձնելով հիբրիդային հավելվածները և հեշտացնելով դրանց միգրացիան տարբեր ամպերի միջև՝ մասնավոր և հանրային:
Windows 2019 Վիրտուալ վիրտուալ մեքենա, որն աշխատում է OpenShift-ով Container Native Virtualization-ի միջոցով (ներկայումս Tech նախադիտման տարբերակում)
5. Կլաստերների համար գործիքներ
Ձեռնարկությունների կարգի ցանկացած հարթակ պետք է ունենա մոնիտորինգի և կենտրոնացված գրանցման ծառայություններ, անվտանգության մեխանիզմներ, նույնականացում և թույլտվություն, ինչպես նաև ցանցի կառավարման գործիքներ: Եվ OpenShift-ն այս ամենը տրամադրում է առանց տուփի, և այդ ամենը 100% բաց կոդով է, ներառյալ լուծումները, ինչպիսիք են ElasticSearch, Prometheus, Grafana: Այս բոլոր լուծումներն ունեն վահանակներ, չափումներ և ազդանշաններ, որոնք արդեն կառուցված և կազմաձևված են՝ օգտագործելով Red Hat-ի կլաստերի մոնիտորինգի լայն փորձը, ինչը թույլ է տալիս արդյունավետորեն վերահսկել և վերահսկել ձեր արտադրական միջավայրը հենց սկզբից:
OpenShift-ը նաև ստանդարտ է կորպորատիվ հաճախորդների համար այնպիսի կարևոր բաների հետ, ինչպիսիք են նույնականացումը ներկառուցված oauth մատակարարի հետ, ինտեգրումը հավատարմագրերի մատակարարների հետ, ներառյալ LDAP, ActiveDirectory, OpenID Connect և շատ ավելին:
Նախապես կազմաձևված Grafana վահանակ OpenShift կլաստերի մոնիտորինգի համար
Ավելի քան 150 նախապես կազմաձևված Պրոմեթևսի չափումներ և ծանուցումներ OpenShift կլաստերի մոնիտորինգի համար
Շարունակելի
Լուծման հարուստ ֆունկցիոնալությունը և Red Hat-ի մեծ փորձը Kubernetes-ի ոլորտում հանդիսանում են պատճառ, թե ինչու OpenShift-ը գերիշխող դիրք է ձեռք բերել շուկայում, ինչպես ցույց է տրված ստորև նկարում (կարդալ ավելին ).
«Red Hat-ը ներկայումս առաջատարն է շուկայում՝ 44% բաժնեմասով:
Ընկերությունը քաղում է իր հաճախորդակենտրոն վաճառքի ռազմավարության օգուտները, որտեղ նախ խորհրդակցում և վերապատրաստում է ձեռնարկությունների ծրագրավորողներին, այնուհետև անցնում է դրամայնացման, քանի որ ձեռնարկությունը սկսում է բեռնարկղեր տեղակայել արտադրության մեջ»:
(Աղբյուր. )
Հուսով ենք, որ ձեզ դուր է եկել այս հոդվածը: Այս շարքի հետագա գրառումներում մենք ավելի մանրամասն կանդրադառնանք OpenShift-ի առավելություններին Kubernetes-ի նկատմամբ այստեղ քննարկված յուրաքանչյուր կատեգորիայում:
Source: www.habr.com