Платформа жасауды ретке келтіруге мүмкіндік береді , соның ішінде бұлттық қызмет провайдерлерінің инфрақұрылымында, виртуализация платформаларында немесе жалаң металл жүйелерінде. Шынайы бұлтқа негізделген платформаны жасау үшін біз барлық пайдаланылатын элементтерді қатаң бақылауға алуымыз керек және осылайша күрделі автоматтандыру процесінің сенімділігін арттыруымыз керек.
Ашық шешім стандарт ретінде Red Hat Enterprise Linux CoreOS (Red Hat Enterprise Linux нұсқасы) және CRI-O пайдалану болды, сондықтан ...
Желкенді жүзу тақырыбы Кубернетес пен контейнерлердің жұмысын түсіндіру кезінде ұқсастықтарды табу үшін өте жақсы болғандықтан, мысалды қолдана отырып, CoreOS және CRI-O шешетін бизнес мәселелері туралы сөйлесуге тырысайық. . 1803 жылы Марк Брунелге өсіп келе жатқан британдық флоттың қажеттіліктері үшін 100 19 такелаждық блоктар шығару тапсырылды. Такелаждық блок - желкендерге арқандарды бекіту үшін қолданылатын такелаждың бір түрі. XNUMX ғасырдың басына дейін бұл блоктар қолмен жасалды, бірақ Брунель өндірісті автоматтандыруға қол жеткізді және станоктарды қолдану арқылы стандартталған блоктарды шығара бастады. Бұл процесті автоматтандыру нәтижесінде алынған блоктардың негізінен бірдей болатынын, сынған жағдайда оңай ауыстырылатынын және үлкен көлемде шығарылуын білдірді.
Енді елестетіп көріңізші, Брунел бұл жұмысты 20 түрлі кеме моделі (Кубернетес нұсқалары) және теңіз ағындары мен желдері мүлдем басқа бес түрлі планеталар үшін (бұлт провайдерлері) жасауы керек еді. Сонымен қатар, капитандардың (кластерлердің жұмысын басқаратын операторлардың) көзқарасы бойынша навигация жүзеге асырылатын планеталарға қарамастан, барлық кемелерден (OpenShift кластерлері) бірдей әрекет ету талап етілді. Теңіз аналогиясын жалғастыру үшін кеме капитандары өз кемелерінде қандай такелаждық блоктар (CRI-O) қолданылатынына мүлдем мән бермейді - олар үшін ең бастысы - бұл блоктардың берік және сенімді болуы.
OpenShift 4 бұлтты платформа ретінде өте ұқсас бизнес мәселесіне тап болады. Жаңа түйіндер кластерді жасау кезінде, түйіндердің бірінде ақаулық болған жағдайда немесе кластерді масштабтау кезінде жасалуы керек. Жаңа түйін жасалғанда және инициализацияланғанда, CRI-O қоса алғанда, маңызды хост құрамдастары сәйкесінше конфигурациялануы керек. Кез келген басқа өндірістегі сияқты, «шикізат» басында жеткізілуі керек. Кемелерде шикізат металл және ағаш болып табылады. Дегенмен, OpenShift 4 кластерінде контейнерлерді орналастыру үшін хостты жасау жағдайында кіріс ретінде конфигурация файлдары мен API қамтамасыз етілген серверлер болуы керек. Содан кейін OpenShift бүкіл өмірлік цикл бойы автоматтандырудың қажетті деңгейін қамтамасыз етеді, соңғы пайдаланушыларға қажетті өнім қолдауын ұсынады және осылайша платформаға салынған инвестицияны өтейді.
OpenShift 4 барлық негізгі бұлттық есептеулер провайдерлері, виртуализация платформалары және тіпті жалаң металл жүйелері үшін платформаның бүкіл өмірлік циклі бойы (4.X нұсқалары үшін) жүйені ыңғайлы жаңарту мүмкіндігін қамтамасыз ететіндей етіп жасалған. Ол үшін өзара ауыстырылатын элементтер негізінде түйіндер құрылуы керек. Кластерге Kubernetes бағдарламасының жаңа нұсқасы қажет болғанда, ол CoreOS жүйесіндегі сәйкес CRI-O нұсқасын да алады. CRI-O нұсқасы тікелей Kubernetes-пен байланыстырылғандықтан, бұл тестілеу, ақауларды жою немесе қолдау мақсаттары үшін кез келген ауыстыруларды айтарлықтай жеңілдетеді. Сонымен қатар, бұл тәсіл соңғы пайдаланушылар мен Red Hat үшін шығындарды азайтады.
Бұл Kubernetes кластерлері туралы түбегейлі жаңа ойлау тәсілі және кейбір өте пайдалы және тартымды жаңа мүмкіндіктерді жоспарлаудың негізін қалайды. CRI-O (Container Runtime Interface - Open Container Initiative, қысқартылған CRI-OCI) OpenShift-пен жұмыс істеу үшін қажет түйіндерді жаппай жасау үшін ең сәтті таңдау болып шықты. CRI-O OpenShift пайдаланушыларына бұрын қолданылған Docker қозғалтқышын ауыстырады – иә, сіз дұрыс естідіңіз – Кубернетеспен жұмыс істеу үшін арнайы жасалған қызық контейнер қозғалтқышы.
Ашық контейнерлер әлемі
Әлем ұзақ уақыт бойы ашық контейнерлерге бет бұрды. Кубернетеде немесе төменгі деңгейде болсын, барлық деңгейдегі инновациялар экожүйесін береді.
Барлығы ашық контейнерлер бастамасын құрудан басталды . Жұмыстың осы бастапқы кезеңінде контейнерлік спецификациялар қалыптастырылды и . Бұл құралдардың бір стандартты пайдалануына кепілдік берді және олармен жұмыс істеудің бірыңғай форматы. Техникалық сипаттамалар кейінірек қосылды , пайдаланушыларға оңай бөлісуге мүмкіндік береді .
Содан кейін Kubernetes қауымдастығы деп аталатын қосылатын интерфейс үшін бірыңғай стандарт әзірледі . Осының арқасында Kubernetes пайдаланушылары Docker-тен басқа контейнерлермен жұмыс істеу үшін әртүрлі қозғалтқыштарды қоса алды.
Red Hat және Google инженерлері CRI протоколы арқылы Kubelet сұрауларын қабылдай алатын контейнерлік қозғалтқыштың нарықтық қажеттілігін көрді және жоғарыда аталған 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 платформасында Tech Preview күйіндегі 3.7 нұсқасынан бастап және Жалпы қолжетімді күйдегі 3.9 нұсқасынан бастап (қазіргі уақытта қолдау көрсетіледі) пайдалану мүмкіндігіне ие болды. Сонымен қатар, Red Hat жаппай пайдаланады OpenShift Online жүйесінде 3.10 нұсқасынан бастап. Мұның бәрі CRI-O бойынша жұмыс істейтін топқа үлкен Кубернетес кластерлерінде контейнерлерді жаппай ұшыруда үлкен тәжірибе алуға мүмкіндік берді. Кубернетестің CRI-O қалай пайдаланатыны туралы негізгі түсінік алу үшін сәулет қалай жұмыс істейтінін көрсететін келесі суретті қарастырайық.
Күріш. 2. Кубернетес кластерінде контейнерлер қалай жұмыс істейді
CRI-O жаңа түйіндерді инициализациялау кезінде және OpenShift платформасының жаңа нұсқаларын шығару кезінде бүкіл жоғарғы деңгейді синхрондау арқылы жаңа контейнерлік хосттарды құруды жеңілдетеді. Бүкіл платформаны қайта қарау транзакциялық жаңартуларға/қайтаруға мүмкіндік береді, сонымен қатар контейнердің негізгі өзегі, контейнер қозғалтқышы, түйіндер (Кубелец) және Kubernetes Master түйіні арасындағы тәуелділіктердің тығырыққа тірелуіне жол бермейді. Басқару және нұсқалау арқылы барлық платформа құрамдастарын орталықтан басқару арқылы әрқашан А күйінен В күйіне дейін анық жол бар. Бұл жаңарту процесін жеңілдетеді, қауіпсіздікті жақсартады, өнімділік туралы есеп беруді жақсартады және жаңа нұсқаларды жаңарту мен орнату құнын төмендетуге көмектеседі. .
Ауыстырылатын элементтердің қуатын көрсету
Бұрын айтылғандай, OpenShift 4 жүйесінде контейнерлік хост пен контейнерлік қозғалтқышты басқару үшін Machine Config операторын пайдалану бұрын Kubernetes платформасында мүмкін болмаған автоматтандырудың жаңа деңгейін қамтамасыз етеді. Жаңа мүмкіндіктерді көрсету үшін crio.conf файлына қалай өзгертулер енгізуге болатынын көрсетеміз. Терминологиямен шатастырмау үшін нәтижелерге назар аударуға тырысыңыз.
Алдымен, контейнердің орындалу уақыты конфигурациясы деп аталатын нәрсені жасайық - Container Runtime Config. Оны CRI-O конфигурациясын көрсететін Кубернетес ресурсы ретінде елестетіп көріңіз. Шындығында, бұл OpenShift кластерінің бөлігі ретінде RHEL CoreOS құрылғысына орналастырылған кез келген конфигурация болып табылатын MachineConfig деп аталатын нәрсенің мамандандырылған нұсқасы.
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 жасағаннан кейін, бұл конфигурацияны кластердегі белгілі бір машиналар тобына қолданғымыз келетіні туралы Kubernetes-ке сигнал беру үшін MachineConfigPools бірін өзгертуіміз керек. Бұл жағдайда біз негізгі түйіндер үшін 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: ""
...
Осы кезде МКҰ кластер үшін жаңа 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
Енді орнатылған файлды қарастырайық. Сіз файлдың ContainerRuntimeConfig ресурсында көрсеткен pid және отладка директивалары үшін жаңа мәндермен жаңартылғанын көресіз. Талғампаздықтың өзі:
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 негізгі түйініне кіру арқылы жасалды. Яғни, бұл жаңа параметрлер тек негізгі түйіндерде конфигурацияланған. Жұмысшы түйіндері өзгермеді, бұл Кубернетес әдістемесінің контейнерлік хосттар мен ауыстырылатын элементтері бар контейнер қозғалтқыштарына қатысты көрсетілген және нақты күйлерді пайдаланудың артықшылықтарын көрсетеді.
Жоғарыдағы мысал үш өндірістік түйіні бар шағын OpenShift контейнер платформасы 4 кластеріне немесе 3000 түйіні бар үлкен өндірістік кластерге өзгертулер енгізу мүмкіндігін көрсетеді. Кез келген жағдайда жұмыс көлемі бірдей және өте аз болады - тек ContainerRuntimeConfig файлын конфигурациялаңыз және MachineConfigPool ішіндегі бір белгіні өзгертіңіз. Сіз мұны барлық қызмет мерзімі бойы Kubernetes іске қосатын OpenShift Container Platform 4.X нұсқасының кез келген нұсқасымен жасай аласыз.
Көбінесе технологиялық компаниялар соншалықты тез дамиды, сондықтан біз негізгі компоненттер үшін белгілі бір технологияларды неліктен таңдайтынымызды түсіндіре алмаймыз. Контейнер қозғалтқыштары тарихи түрде пайдаланушылармен тікелей әрекеттесетін компонент болды. Контейнерлердің танымалдығы, әрине, контейнерлік қозғалтқыштардың пайда болуымен басталғандықтан, пайдаланушылар оларға жиі қызығушылық танытады. Бұл Red Hat CRI-O таңдауының тағы бір себебі. Контейнерлер қазір оркестрлеуге назар аудара отырып дамып жатыр және біз CRI-O OpenShift 4-пен жұмыс істеу кезінде ең жақсы тәжірибені қамтамасыз ететінін анықтадық.
Ақпарат көзі: www.habr.com