Հարթակ թույլ է տալիս պարզեցնել ստեղծագործությունը , այդ թվում՝ ամպային ծառայություններ մատուցողների ենթակառուցվածքում, վիրտուալացման հարթակներում կամ մերկ մետաղական համակարգերում։ Իսկապես ամպի վրա հիմնված հարթակ ստեղծելու համար մենք պետք է խստորեն վերահսկեինք օգտագործվող բոլոր տարրերը և այդպիսով մեծացնեինք բարդ ավտոմատացման գործընթացի հուսալիությունը:
Ակնհայտ լուծումը Red Hat Enterprise Linux CoreOS-ի (Red Hat Enterprise Linux-ի տարբերակ) և CRI-O-ի որպես ստանդարտ օգտագործելն էր, և ահա թե ինչու...
Քանի որ նավարկության թեման շատ լավ է Kubernetes-ի և բեռնարկղերի աշխատանքը բացատրելիս անալոգիաներ գտնելու համար, եկեք փորձենք խոսել բիզնես խնդիրների մասին, որոնք լուծում են CoreOS-ը և CRI-O-ն՝ օգտագործելով օրինակ: . 1803 թվականին Մարկ Բրունելին հանձնարարվել է արտադրել 100 բլոկ՝ աճող բրիտանական նավատորմի կարիքների համար: Կեղտոտման բլոկը սարքավորման տեսակ է, որն օգտագործվում է առագաստներին պարաններ ամրացնելու համար: Մինչև 19-րդ դարի ամենասկզբները այս բլոկները պատրաստվում էին ձեռքով, բայց Բրունելին հաջողվեց ավտոմատացնել արտադրությունը և սկսեց արտադրել ստանդարտացված բլոկներ՝ օգտագործելով հաստոցներ։ Այս գործընթացի ավտոմատացումը նշանակում էր, որ ստացված բլոկները ըստ էության նույնական էին, կարող էին հեշտությամբ փոխարինվել կոտրվելու դեպքում և կարող էին արտադրվել մեծ քանակությամբ:
Հիմա պատկերացրեք, եթե Բրունելը ստիպված լիներ կատարել այս աշխատանքը 20 տարբեր նավերի մոդելների համար (Kubernetes տարբերակներ) և հինգ տարբեր մոլորակների համար՝ բոլորովին տարբեր ծովային հոսանքներով և քամիներով (ամպային մատակարարներ): Բացի այդ, պահանջվում էր, որ բոլոր նավերը (OpenShift կլաստերները), անկախ այն մոլորակներից, որոնց վրա իրականացվում է նավարկություն, կապիտանների տեսանկյունից (օպերատորներ, ովքեր ղեկավարում են կլաստերների աշխատանքը) նույն վարքագիծը: Շարունակելու համար ծովային անալոգիան, նավերի կապիտաններին ընդհանրապես չի հետաքրքրում, թե ինչ տեսակի բլոկներ (CRI-O) են օգտագործվում իրենց նավերի վրա, նրանց համար գլխավորն այն է, որ այդ բլոկները ամուր և հուսալի են:
OpenShift 4-ը, որպես ամպային հարթակ, բախվում է շատ նմանատիպ բիզնես մարտահրավերի: Նոր հանգույցները պետք է ստեղծվեն կլաստերի ստեղծման պահին, հանգույցներից մեկի ձախողման դեպքում կամ կլաստերի մասշտաբավորման ժամանակ: Երբ ստեղծվում և սկզբնավորվում է նոր հանգույց, կարևորագույն հյուրընկալող բաղադրիչները, ներառյալ CRI-O-ն, պետք է համապատասխանաբար կազմաձևվեն: Ինչպես ցանկացած այլ արտադրությունում, «հումքը» պետք է մատակարարվի սկզբում։ Նավերի դեպքում հումքը մետաղն ու փայտն են։ Այնուամենայնիվ, OpenShift 4 կլաստերում բեռնարկղերի տեղակայման համար հոսթ ստեղծելու դեպքում դուք պետք է ունենաք կազմաձևման ֆայլեր և API-ով տրամադրված սերվերներ որպես մուտքագրում: OpenShift-ն այնուհետև կապահովի ավտոմատացման անհրաժեշտ մակարդակը ողջ կյանքի ցիկլի ընթացքում՝ առաջարկելով արտադրանքի անհրաժեշտ աջակցություն վերջնական օգտագործողներին և այդպիսով փոխհատուցելով ներդրումները հարթակում:
OpenShift 4-ը ստեղծվել է այնպես, որ հնարավորություն ընձեռի համակարգը հարմար կերպով թարմացնել պլատֆորմի ողջ կյանքի ցիկլի ընթացքում (4.X տարբերակների համար) ամպային հաշվարկման բոլոր խոշոր մատակարարների, վիրտուալացման հարթակների և նույնիսկ մերկ մետաղական համակարգերի համար: Դա անելու համար հանգույցները պետք է ստեղծվեն փոխանակելի տարրերի հիման վրա: Երբ կլաստերը պահանջում է Kubernetes-ի նոր տարբերակ, այն նաև ստանում է CRI-O-ի համապատասխան տարբերակը CoreOS-ում: Քանի որ CRI-O տարբերակը ուղղակիորեն կապված է Kubernetes-ի հետ, սա մեծապես հեշտացնում է փորձարկման, անսարքությունների վերացման կամ աջակցության նպատակներով ցանկացած փոխարկում: Բացի այդ, այս մոտեցումը նվազեցնում է վերջնական օգտագործողների և Red Hat-ի ծախսերը:
Սա սկզբունքորեն նոր մտածելակերպ է Kubernetes կլաստերների մասին և հիմք է դնում որոշ շատ օգտակար և ազդեցիկ նոր առանձնահատկություններ պլանավորելու համար: CRI-O-ն (Container Runtime Interface - Open Container Initiative, կրճատ՝ CRI-OCI) պարզվեց, որ ամենահաջող ընտրությունն է հանգույցների զանգվածային ստեղծման համար, որոնք անհրաժեշտ են OpenShift-ի հետ աշխատելու համար: CRI-O-ն կփոխարինի նախկինում օգտագործված Docker շարժիչին՝ առաջարկելով OpenShift օգտվողներին – այո, ճիշտ եք լսել – ձանձրալի բեռնարկղային շարժիչ, որը ստեղծվել է հատուկ Kubernetes-ի հետ աշխատելու համար:
Բաց տարաների աշխարհը
Աշխարհը վաղուց է շարժվում դեպի բաց տարաներ։ Անկախ նրանից, թե Kubernetes-ում, թե ավելի ցածր մակարդակներում, հանգեցնում է նորարարության էկոհամակարգի յուրաքանչյուր մակարդակում:
Ամեն ինչ սկսվեց Open Containers Initiative-ի ստեղծմամբ . Աշխատանքի այս վաղ փուլում ձևավորվել են բեռնարկղերի բնութագրերը и . Սա երաշխավորեց, որ գործիքները կարող են օգտագործել մեկ ստանդարտ և նրանց հետ աշխատելու միասնական ձևաչափ: Տեխնիկական բնութագրերը հետագայում ավելացվել են , թույլ տալով օգտվողներին հեշտությամբ կիսվել .
Այնուհետև Kubernetes համայնքը մշակեց միակ չափանիշը խցանվող ինտերֆեյսի համար, որը կոչվում է . Դրա շնորհիվ Kubernetes-ի օգտատերերը կարողացան միացնել տարբեր շարժիչներ՝ բացի Docker-ից կոնտեյներների հետ աշխատելու համար։
Red Hat-ի և Google-ի ինժեներները տեսան, որ շուկայական անհրաժեշտություն կա կոնտեյներային շարժիչի համար, որը կարող է ընդունել Kubelet-ի հարցումները CRI արձանագրության միջոցով և ներկայացրել բեռնարկղեր, որոնք համատեղելի են վերը նշված OCI բնութագրերի հետ: Այսպիսով . Բայց կներեք, չէ՞ որ մենք ասում էինք, որ այս նյութը նվիրված կլինի CRI-O-ին: Իրականում այդպես է, հենց թողարկումով նախագիծը վերանվանվեց CRI-O:
Բրինձ 1
Նորարարություն CRI-O-ի և CoreOS-ի հետ
OpenShift 4 պլատֆորմի գործարկումով այն փոխվեց , որն օգտագործվում էր լռելյայնորեն հարթակում, և Docker-ը փոխարինվեց CRI-O-ով, որն առաջարկում էր ծախսարդյունավետ, կայուն, պարզ և ձանձրալի միջավայր՝ Kubernetes-ի հետ զուգահեռ զարգացող կոնտեյների գործարկման համար։ Սա մեծապես հեշտացնում է կլաստերի աջակցությունը և կազմաձևումը: Բեռնարկղային շարժիչի և հոսթի կազմաձևումը, ինչպես նաև դրանց կառավարումը ավտոմատացված է դառնում OpenShift 4-ում:
Սպասեք, ինչպե՞ս է սա:
Ճիշտ է, OpenShift 4-ի գալուստով այլևս կարիք չկա միանալու առանձին հոսթներին և տեղադրել կոնտեյներային շարժիչ, կարգավորել պահեստը, կարգավորել որոնման սերվերները կամ կարգավորել ցանցը: OpenShift 4 պլատֆորմը ամբողջությամբ վերափոխվել է օգտագործելու համար ոչ միայն վերջնական օգտագործողի հավելվածների, այլ նաև հարթակի մակարդակի հիմնական գործառնությունների առումով, ինչպիսիք են պատկերների տեղակայումը, համակարգի կազմաձևումը կամ թարմացումների տեղադրումը:
Kubernetes-ը միշտ թույլ է տվել օգտատերերին կառավարել հավելվածները՝ սահմանելով ցանկալի վիճակը և օգտագործելով , ապահովելու, որ իրական վիճակը հնարավորինս սերտորեն համընկնի թիրախային վիճակի հետ: Սա բացում է մեծ հնարավորություններ ինչպես զարգացման, այնպես էլ գործունեության տեսանկյունից: Մշակողները կարող են սահմանել պահանջվող վիճակը ըստ օպերատորին YAML կամ JSON ֆայլի տեսքով, այնուհետև օպերատորը կարող է ստեղծել անհրաժեշտ հավելվածի օրինակ արտադրական միջավայրում, և այս օրինակի գործառնական վիճակը լիովին կհամապատասխանի նշվածին:
Օգտագործելով օպերատորները հարթակում՝ OpenShift 4-ը բերում է այս նոր պարադիգմը (օգտագործելով սահմանված և փաստացի վիճակի հայեցակարգը) RHEL CoreOS-ի և CRI-O-ի կառավարմանը: Օպերացիոն համակարգի և բեռնարկղային շարժիչի տարբերակների կազմաձևման և կառավարման խնդիրները ավտոմատացված են՝ օգտագործելով այսպես կոչված. . MCO-ն մեծապես հեշտացնում է կլաստերի ադմինիստրատորի աշխատանքը՝ ըստ էության ավտոմատացնելով տեղադրման վերջին փուլերը, ինչպես նաև հետագա հետտեղադրման գործողությունները (օրվա երկրորդ գործողություն): Այս ամենը OpenShift 4-ը դարձնում է իսկական ամպային հարթակ: Սրան կանդրադառնանք մի փոքր ուշ:
Գործող կոնտեյներներ
Օգտատերերը հնարավորություն են ունեցել օգտագործել CRI-O շարժիչը OpenShift հարթակում սկսած 3.7 տարբերակից՝ Tech Preview կարգավիճակում և 3.9 տարբերակից՝ Generally Available կարգավիճակում (ներկայումս աջակցվում է): Բացի այդ, Red Hat-ը զանգվածաբար օգտագործում է OpenShift Online-ում 3.10 տարբերակից սկսած: Այս ամենը թույլ տվեց CRI-O-ի վրա աշխատող թիմին մեծ փորձ ձեռք բերել մեծ Kubernetes կլաստերների վրա բեռնարկղերի զանգվածային արձակման գործում: Որպեսզի հասկանանք, թե ինչպես է Kubernetes-ը օգտագործում CRI-O-ն, եկեք նայենք հետևյալ նկարազարդմանը, որը ցույց է տալիս, թե ինչպես է աշխատում ճարտարապետությունը:
Բրինձ. 2. Ինչպես են բեռնարկղերը աշխատում Kubernetes կլաստերում
CRI-O-ն պարզեցնում է նոր կոնտեյներների ստեղծումը՝ համաժամացնելով ամբողջ վերին մակարդակը նոր հանգույցներ սկզբնավորելիս և OpenShift հարթակի նոր տարբերակները թողարկելիս: Ամբողջ հարթակի վերանայումը թույլ է տալիս գործարքային թարմացումներ/վերադարձումներ կատարել, ինչպես նաև կանխում է փակուղիները կոնտեյների պոչերի միջուկի, կոնտեյների շարժիչի, հանգույցների (Kubelets) և Kubernetes Master հանգույցի միջև կախվածության մեջ: Պլատֆորմի բոլոր բաղադրիչները կենտրոնացված կառավարելով՝ հսկողությամբ և տարբերակներով, միշտ կա հստակ ճանապարհ A վիճակից B վիճակ: Սա հեշտացնում է թարմացման գործընթացը, բարելավում է անվտանգությունը, բարելավում է կատարողականի հաշվետվությունը և օգնում է նվազեցնել թարմացումների և նոր տարբերակների տեղադրման ծախսերը: .
Փոխարինվող տարրերի հզորության ցուցադրում
Ինչպես նշվեց ավելի վաղ, OpenShift 4-ում բեռնարկղային հոսթն ու կոնտեյների շարժիչը կառավարելու համար Machine Config օպերատորի օգտագործումը ապահովում է ավտոմատացման նոր մակարդակ, որը նախկինում հնարավոր չէր Kubernetes հարթակում: Նոր հնարավորությունները ցուցադրելու համար մենք ցույց կտանք, թե ինչպես կարող եք փոփոխություններ կատարել crio.conf ֆայլում: Տերմինաբանության մեջ շփոթվելուց խուսափելու համար փորձեք կենտրոնանալ արդյունքների վրա։
Նախ, եկեք ստեղծենք այն, ինչը կոչվում է կոնտեյների գործարկման ժամանակի կոնֆիգուրացիա՝ Container Runtime Config: Մտածեք դրա մասին որպես Kubernetes ռեսուրս, որը ներկայացնում է CRI-O-ի կոնֆիգուրացիան: Իրականում, դա MachineConfig կոչվող մի բանի մասնագիտացված տարբերակն է, որը ցանկացած կոնֆիգուրացիա է, որը տեղակայվում է RHEL CoreOS մեքենայի վրա՝ որպես OpenShift կլաստերի մաս:
Այս հատուկ ռեսուրսը, որը կոչվում է ContainerRuntimeConfig, ստեղծվել է կլաստերի ադմինիստրատորների համար CRI-O-ի կազմաձևումը հեշտացնելու համար: Այս գործիքը բավականաչափ հզոր է, որ այն կարող է կիրառվել միայն որոշակի հանգույցների վրա՝ կախված MachineConfigPool-ի կարգավորումներից: Մտածեք դրա մասին որպես մեքենաների խումբ, որոնք ծառայում են նույն նպատակին:
Ուշադրություն դարձրեք վերջին երկու տողերին, որոնք մենք պատրաստվում ենք փոխել /etc/crio/crio.conf ֆայլում: Այս երկու տողերը շատ նման են crio.conf ֆայլի տողերին, դրանք են.
vi ContainerRuntimeConfig.yaml
Եզրակացություն.
apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
name: set-log-and-pid
spec:
machineConfigPoolSelector:
matchLabels:
debug-crio: config-log-and-pid
containerRuntimeConfig:
pidsLimit: 2048
logLevel: debug
Այժմ եկեք այս ֆայլը տեղափոխենք Kubernetes կլաստեր և ստուգենք, որ այն իրականում ստեղծվել է: Խնդրում ենք նկատի ունենալ, որ գործողությունը ճիշտ նույնն է, ինչ Kubernetes-ի ցանկացած այլ ռեսուրսի դեպքում.
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Եզրակացություն.
NAME AGE
set-log-and-pid 22h
Երբ մենք ստեղծենք ContainerRuntimeConfig-ը, մենք պետք է փոփոխենք MachineConfigPools-ից մեկը, որպեսզի ազդարարենք Kubernetes-ին, որ ցանկանում ենք կիրառել այս կոնֆիգուրացիան կլաստերի մեքենաների որոշակի խմբի վրա: Այս դեպքում մենք կփոխենք MachineConfigPool-ը հիմնական հանգույցների համար.
oc edit MachineConfigPool/master
Եզրակացություն (հստակության համար մնում է հիմնական էությունը).
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Այս պահին MCO-ն սկսում է ստեղծել նոր crio.conf ֆայլ կլաստերի համար: Այս դեպքում ամբողջովին ավարտված կազմաձևման ֆայլը կարելի է դիտել Kubernetes API-ի միջոցով: Հիշեք, որ ContainerRuntimeConfig-ը պարզապես MachineConfig-ի մասնագիտացված տարբերակն է, այնպես որ մենք կարող ենք արդյունքը տեսնել՝ նայելով MachineConfigs-ի համապատասխան տողերին.
oc get MachineConfigs | grep rendered
Եզրակացություն.
rendered-master-c923f24f01a0e38c77a05acfd631910b 4.0.22-201904011459-dirty 2.2.0 16h
rendered-master-f722b027a98ac5b8e0b41d71e992f626 4.0.22-201904011459-dirty 2.2.0 4m
rendered-worker-9777325797fe7e74c3f2dd11d359bc62 4.0.22-201904011459-dirty 2.2.0 16h
Խնդրում ենք նկատի ունենալ, որ ստացված կազմաձևման ֆայլը հիմնական հանգույցների համար ավելի նոր տարբերակ էր, քան սկզբնական կազմաձևերը: Այն դիտելու համար գործարկեք հետևյալ հրամանը. Ընթացքում մենք նշում ենք, որ սա, թերևս, Կուբերնետեսի պատմության լավագույն միակողմանիներից մեկն է.
python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.argv[1]))" $(oc get MachineConfig/rendered-master-f722b027a98ac5b8e0b41d71e992f626 -o YAML | grep -B4 crio.conf | grep source | tail -n 1 | cut -d, -f2) | grep pid
Եզրակացություն.
pids_limit = 2048
Այժմ եկեք համոզվենք, որ կոնֆիգուրացիան կիրառվել է բոլոր հիմնական հանգույցների վրա: Սկզբում մենք ստանում ենք կլաստերի հանգույցների ցանկը.
oc get node | grep master
Output:
ip-10-0-135-153.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ip-10-0-154-0.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ip-10-0-166-79.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
Հիմա եկեք նայենք տեղադրված ֆայլին: Դուք կտեսնեք, որ ֆայլը թարմացվել է pid և debug հրահանգների նոր արժեքներով, որոնք մենք նշել ենք ContainerRuntimeConfig ռեսուրսում: Շքեղությունն ինքնին.
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Եզրակացություն.
...
pids_limit = 2048
...
log_level = "debug"
...
Կլաստերի այս բոլոր փոփոխությունները կատարվել են առանց նույնիսկ SSH գործարկելու: Ամբողջ աշխատանքը կատարվել է Kuberentes-ի գլխավոր հանգույց մուտք գործելու միջոցով: Այսինքն, այս նոր պարամետրերը կազմաձևվել են միայն հիմնական հանգույցների վրա: Աշխատող հանգույցները չեն փոխվել, ինչը ցույց է տալիս Kubernetes մեթոդաբանության առավելությունները՝ կոնկրետ և փաստացի վիճակների օգտագործման հետ կապված բեռնարկղերի հյուրընկալող սարքերի և փոխարկվող տարրերով բեռնարկղերի շարժիչների հետ:
Վերոնշյալ օրինակը ցույց է տալիս փոփոխություններ կատարելու հնարավորությունը փոքր OpenShift Container Platform 4 կլաստերում երեք արտադրական հանգույցներով կամ հսկայական արտադրական կլաստերի մեջ՝ 3000 հանգույցներով: Ամեն դեպքում, աշխատանքի ծավալը կլինի նույնը և շատ փոքր, պարզապես կարգավորեք ContainerRuntimeConfig ֆայլը և փոխեք մեկ պիտակ MachineConfigPool-ում: Եվ դուք կարող եք դա անել OpenShift Container Platform 4.X-ի ցանկացած տարբերակով, որն աշխատում է Kubernetes-ի ողջ կյանքի ընթացքում:
Հաճախ տեխնոլոգիական ընկերությունները զարգանում են այնքան արագ, որ մենք չենք կարողանում բացատրել, թե ինչու ենք մենք ընտրում որոշակի տեխնոլոգիաներ հիմքում ընկած բաղադրիչների համար: Կոնտեյներային շարժիչները պատմականորեն եղել են այն բաղադրիչը, որի հետ օգտվողներն ուղղակիորեն շփվում են: Քանի որ բեռնարկղերի հանրաճանաչությունը, բնականաբար, սկսվել է բեռնարկղային շարժիչների հայտնվելով, օգտվողները հաճախ հետաքրքրություն են ցուցաբերում դրանց նկատմամբ: Սա ևս մեկ պատճառ է, թե ինչու Red Hat-ն ընտրեց CRI-O-ն: Կոնտեյներներն այժմ զարգանում են՝ կենտրոնանալով նվագախմբի վրա, և մենք պարզել ենք, որ CRI-O-ն ապահովում է լավագույն փորձը OpenShift 4-ի հետ աշխատելիս:
Source: www.habr.com