Платформа дазваляе паставіць на паток стварэнне , у тым ліку ў інфраструктуры пастаўшчыкоў хмарных сэрвісаў, на платформах віртуалізацыі або ў bare-metal сістэмах. Каб стварыць у поўным сэнсе хмарную платформу, нам прыйшлося ўзяць пад цвёрды кантроль усе прымяняюцца элементы і такім чынам павысіць надзейнасць складанага працэсу аўтаматызацыі.
Відавочным рашэннем стала выкарыстанне ў якасці стандарту 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) для ўсіх асноўных пастаўшчыкоў хмарных вылічэнняў, платформаў віртуалізацыі і нават bare metal сістэм. Для гэтага вузлы павінны стварацца на базе ўзаемазаменных элементаў. Калі кластар патрабуе новую версію 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 распрацавала адзіны стандарт падключанага інтэрфейсу (pluggable interface), які атрымаў назву . Дзякуючы гэтаму карыстачы 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 была поўнасцю перапрацавана для выкарыстання the не толькі з пункту гледжання прыкладанняў канчатковых карыстальнікаў, але і з пункту гледжання базавых аперацый на ўзроўні платформы, такіх як разгортванне вобразаў, канфігураванне сістэмы або ўстаноўка абнаўленняў.
Kubernetes заўсёды дазваляў карыстальнікам кіраваць праграмамі, вызначаючы жаданае стан і выкарыстоўваючы , Каб гарантаваць, што фактычны стан максімальна адпавядае зададзенаму стану. Гэты адкрывае вялікія магчымасці як з пункту гледжання распрацоўкі, так і з пункту гледжання аперацый. Распрацоўнікі могуць вызначыць патрабаваны стан, аператару ў выглядзе YAML або JSON файла, а затым аператар можа стварыць у эксплуатацыйным асяроддзі неабходны асобнік прыкладання, пры гэтым працоўны стан гэтага асобніка будзе цалкам адпавядаць зададзенаму.
Выкарыстоўваючы аператары (Operators) у платформе, OpenShift 4 прыўносіць гэтую новую парадыгму (з выкарыстаннем канцэпцыі зададзенага і фактычнага стану) у кіраванне RHEL CoreOS і CRI-O. Задачы канфігуравання і кіраванні версіямі аперацыйнай сістэмы і кантэйнернага рухавічка аўтаматызуецца з дапамогай так званага . MCO значна спрашчае працу адміністратара кластара, у сутнасці аўтаматызуючы апошнія этапы ўстаноўкі, а таксама наступныя аперацыі пасля ўстаноўкі (day two operations). Усё гэта робіць 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. Гэта дазваляе спрасціць працэс абнаўленняў, падвышае бяспеку, паляпшае вядзенне справаздачнасці па прадукцыйнасці і дапамагае зменшыць выдаткі на абнаўленні і ўсталёўку новых версій.
Дэманстрацыя моцы зменных элементаў
Як было згадана раней, выкарыстанне Machine Config Operator для кіравання хастом кантэйнера і кантэйнерным рухавіком у OpenShift 4 забяспечвае новы ўзровень аўтаматызацыі, які не быў магчымы на платформе 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
Звярніце ўвагу, што атрыманы файл канфігурацый для майстар-вузлоў аказаўся навейшай версіяй, чым зыходныя канфігурацыі. Каб прагледзець яго, запусціце наступную каманду. Адначасна адзначым, што гэта, магчыма, адзін з лепшых аднарадковых скрыптоў за ўсю гісторыю Kubernetes:
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, і змяніць адну пазнаку (label) у MachineConfigPool. І вы можаце зрабіць гэта з любой версіяй выкарыстоўванай у Kubernetes платформы OpenShift Container Platform 4.X на працягу ўсяго яе жыццёвага цыклу.
Часцяком тэхналагічныя кампаніі развіваюцца настолькі хутка, што мы не ў стане растлумачыць, чаму мы выбіраем тыя ці іншыя тэхналогіі для базавых кампанентаў. Кантэйнерныя рухавічкі гістарычна былі тым кампанентам, з якім карыстачы ўзаемадзейнічаюць напроста. Паколькі папулярнасць кантэйнераў заканамерна пачыналася са з'яўлення кантэйнерных рухавічкоў, карыстачы нярэдка выяўляюць да іх зацікаўленасць. Гэта яшчэ адна прычына, чаму Red Hat спыніла свой выбар на CRI-O. Кантэйнеры развіваюцца, пры гэтым сёння асноўная ўвага надаецца аркестроўцы, і мы дашлі да высновы, што CRI-O забяспечвае найлепшы досвед пры працы з OpenShift 4.
Крыніца: habr.com