Извештај је посвећен практичним питањима развоја оператера у Кубернетесу, пројектовању његове архитектуре и основних принципа рада.
У првом делу извештаја размотрићемо:
- шта је оператор у Кубернетесу и зашто је потребан;
- како тачно оператер поједностављује управљање сложеним системима;
- шта оператер може, а шта не може.
Затим, пређимо на дискусију о унутрашњој структури оператера. Хајде да погледамо архитектуру и рад оператера корак по корак. Погледајмо то детаљно:
- интеракција између оператера и Кубернетеса;
- које функције оператер преузима и које функције делегира Кубернетесу.
Хајде да погледамо управљање деловима и репликама базе података у Кубернетесу.
Затим ћемо разговарати о питањима складиштења података:
- како радити са Персистент Стораге са тачке гледишта оператера;
- замке коришћења локалног складишта.
У завршном делу извештаја размотрићемо практичне примере примене са Амазоном или Гоогле Цлоуд сервисом. Извештај је заснован на примеру развоја и радног искуства оператера за ЦлицкХоусе.
Видео:
Моје име је Владислав Клименко. Данас сам желео да причам о нашем искуству у развоју и раду оператера, а ово је специјализовани оператер за управљање кластерима база података. На пример за управљање ЦлицкХоусе кластером.
Зашто имамо прилику да причамо о оператеру и ЦлицкХоусе-у?
- Подржавамо и развијамо ЦлицкХоусе.
- Тренутно покушавамо да полако дамо свој допринос развоју ЦлицкХоусе-а. И ми смо други после Иандек-а по обиму измена у ЦлицкХоусе-у.
- Покушавамо да урадимо додатне пројекте за ЦлицкХоусе екосистем.
Желео бих да вам испричам о једном од ових пројеката. Овде се ради о ЦлицкХоусе-оператору за Кубернетес.
У свом извештају желео бих да се дотакнем две теме:
- Прва тема је како наш ЦлицкХоусе оператер за управљање базом података функционише у Кубернетесу.
- Друга тема је како функционише било који оператор, односно како је у интеракцији са Кубернетес-ом.
Међутим, ова два питања ће се укрштати у мом извештају.
Ко би био заинтересован да слуша оно што покушавам да кажем?
- Највише ће занимати оне који управљају оператерима.
- Или за оне који желе да направе своје како би разумели како интерно функционише, како оператер комуницира са Кубернетесом и које замке се могу појавити.
Да бисте најбоље разумели о чему ћемо данас разговарати, добра је идеја да знате како Кубернетес функционише и да имате основну обуку у облаку.
Шта је ЦлицкХоусе? Ово је колонска база података са специфичним карактеристикама за онлајн обраду аналитичких упита. И потпуно је отвореног кода.
А важно нам је да знамо само две ствари. Морате знати да је ово база података, тако да ће оно што ћу вам рећи биће применљиво на скоро сваку базу података. А чињеница да се ЦлицкХоусе ДБМС веома добро скалира, даје скоро линеарну скалабилност. И стога, стање кластера је природно стање за ЦлицкХоусе. А највише смо заинтересовани да разговарамо о томе како да служимо ЦлицкХоусе кластеру у Кубернетесу.
Зашто је он тамо потребан? Зашто не можемо сами да наставимо да га управљамо? А одговори су делом технички, а делом организациони.
- У пракси се све чешће сусрећемо са ситуацијом да су у великим компанијама скоро све компоненте већ у Кубернетесу. Базе података остају напољу.
- И све чешће се поставља питање: „Може ли се ово ставити унутра?“ Због тога велике компаније покушавају да остваре максимално уједињење менаџмента како би брзо могле да управљају својим складиштима података.
- А ово посебно помаже ако вам је потребна максимална прилика да поновите исту ствар на новом месту, односно максималну преносивост.
Колико је то лако или тешко? Ово се, наравно, може урадити ручно. Али то није тако једноставно, јер имамо додатну сложеност управљања самим Кубернетес-ом, али су у исто време специфичности ЦлицкХоусе-а суперпониране. И таква агрегација резултира.
А све заједно ово даје прилично велики скуп технологија, којима постаје прилично тешко управљати, јер Кубернетес доноси своје свакодневне проблеме у рад, а ЦлицкХоусе доноси своје проблеме у свакодневни рад. Поготово ако имамо неколико ЦлицкХоусе-а, и треба стално нешто да радимо са њима.
Са динамичком конфигурацијом, ЦлицкХоусе има прилично велики број проблема који стварају константно оптерећење на ДевОпс-у:
- Када желимо да променимо нешто у ЦлицкХоусе-у, на пример, додамо реплику или шард, онда морамо да управљамо конфигурацијом.
- Затим промените шему података, јер ЦлицкХоусе има специфичан метод дељења. Тамо треба да поставите дијаграм података, поставите конфигурације.
- Морате да подесите надзор.
- Сакупљање дневника за нове делове, за нове реплике.
- Водите рачуна о рестаурацији.
- И поново покрените.
Ово су рутински задаци које бих заиста желео да олакшам коришћење.
Сам Кубернетес добро помаже у раду, али на основним системским стварима.
Кубернетес је добар у олакшавању и аутоматизацији ствари као што су:
- Опоравак.
- Поново покренути.
- Управљање системом за складиштење.
То је добро, то је у правом смеру, али он потпуно не зна како да управља кластером базе података.
Желимо више, желимо да цела база података ради у Кубернетесу.
Желео бих да добијем нешто попут једног великог магичног црвеног дугмета које притиснете и кластер са свакодневним задацима које треба решити је распоређен и одржаван током целог животног циклуса. ЦлицкХоусе кластер у Кубернетесу.
И покушали смо да направимо решење које би помогло да се посао олакша. Ово је ЦлицкХоусе-оператор за Кубернетес из Алтинити-а.
Оператер је програм чији је главни задатак управљање другим програмима, односно менаџер је.
И садржи обрасце понашања. Ово можете назвати кодификованим знањем о предметној области.
А његов главни задатак је да олакша живот ДевОпс-у и смањи микроменаџмент, тако да он (ДевОпс) већ размишља на високом нивоу, односно да се он (ДевОпс) не бави микроменаџментом, тако да не конфигурише све детаље ручно.
А управо је оператер роботски асистент који се бави микрозадацима и помаже ДевОпс-у.
Зашто вам треба оператер? Посебно добро се понаша у две области:
- Када специјалиста који се бави ЦлицкХоусе-ом нема довољно искуства, али већ треба да управља ЦлицкХоусе-ом, оператер олакшава рад и омогућава вам да управљате ЦлицкХоусе кластером са прилично сложеном конфигурацијом, не улазећи превише у детаље о томе како све функционише у. Само му дате задатке високог нивоа, и то функционише.
- А други задатак у којем се најбоље сналази је када је потребно аутоматизовати велики број типичних задатака. Уклања микрозадатке од системских администратора.
Ово је најпотребније или онима који тек почињу своје путовање, или онима који треба да ураде доста аутоматизације.
Како се приступ заснован на оператеру разликује од других система? Ту је Хелм. Такође помаже инсталирање ЦлицкХоусе-а; можете нацртати дијаграме кормила, који ће чак инсталирати цео ЦлицкХоусе кластер. Која је онда разлика између оператера и истог, на пример, Хелма?
Главна фундаментална разлика је у томе што је Хелм управљање пакетима, а Оператор иде корак даље. Ово је подршка за цео животни циклус. Ово није само инсталација, то су свакодневни задаци који укључују скалирање, шардовање, односно све што треба да се уради током животног циклуса (ако је потребно, онда и брисање) - о томе одлучује оператер. Покушава да аутоматизује и одржава цео животни циклус софтвера. То је његова суштинска разлика од осталих решења која су представљена.
То је био уводни део, идемо даље.
Како да изградимо нашег оператера? Покушавамо да приступимо овом питању како бисмо управљали ЦлицкХоусе кластером као јединственим ресурсом.
Овде имамо улазне податке на левој страни слике. Ово је ИАМЛ са спецификацијом кластера, која се прослеђује Кубернетесу на класичан начин преко кубецтл-а. Тамо га наш оператер преузима и чини своју магију. И на излазу добијамо следећу шему. Ово је имплементација ЦлицкХоусе-а у Кубернетесу.
А онда ћемо полако гледати како тачно оператер ради, који типични задаци се могу решити. Размотрићемо само типичне задатке јер имамо ограничено време. И неће се расправљати о свему што оператер може да одлучи.
Пођимо од праксе. Наш пројекат је потпуно отвореног кода, тако да можете видети како функционише на ГитХубу. И можете поћи од разматрања да ако само желите да га покренете, онда можете почети са Водичем за брзи почетак.
Ако желите да разумете детаљно, онда се трудимо да документацију одржавамо у мање-више пристојном облику.
Почнимо са практичним проблемом. Први задатак, од кога сви желимо да почнемо, је да некако покренемо први пример. Како могу да покренем ЦлицкХоусе помоћу оператера, чак и ако не знам како то функционише? Пишемо манифест, јер... Сва комуникација са к8с је комуникација кроз манифесте.
Ово је тако сложен манифест. Оно што смо означили црвеном бојом је оно на шта треба да се фокусирамо. Тражимо од оператера да креира кластер под називом демо.
Ово су за сада основни примери. Складиштење још није описано, али ћемо се вратити на складиште нешто касније. За сада ћемо посматрати динамику развоја кластера.
Направили смо овај манифест. Дајемо то нашем оператеру. Радио је, правио магију.
Гледамо у конзолу. Три компоненте су од интереса: Под, две услуге и СтатефулСет.
Оператер је прорадио, а видимо шта је тачно направио.
Он ствара овако нешто. Имамо СтатефулСет, Под, ЦонфигМап за сваку реплику, ЦонфигМап за цео кластер. Услуге су потребне као улазне тачке у кластер.
Услуге су централна услуга балансирања оптерећења и такође се могу користити за сваку реплику, за сваки шард.
Наш основни кластер изгледа отприлике овако. То је из једног јединог чвора.
Хајдемо даље и закомпликовати ствари. Морамо да разбијемо кластер.
Наши задаци расту, почиње динамика. Желимо да додамо комадић. Пратимо развој. Ми мењамо нашу спецификацију. Назначавамо да желимо две крхотине.
Ово је исти фајл који се динамички развија са растом система. Складиште не, о складиштењу ће се даље разговарати, ово је посебна тема.
Нахранимо ИАМЛ оператера и видимо шта се дешава.
Оператер је смислио и направио следеће ентитете. Већ имамо два Пода, три услуге и, одједном, 2 СтатефулСета. Зашто 2 СтатефулСетс?
На дијаграму је било овако - ово је наше почетно стање, када смо имали једну махуну.
Постало је овако. До сада је све једноставно, дуплирано.
И зашто су настала два СтатефулСета? Овде треба да одступимо и продискутујемо питање како се управља подовима у Кубернетесу.
Постоји објекат под називом СтатефулСет који вам омогућава да креирате скуп подова из шаблона. Кључни фактор овде је шаблон. И можете покренути много Подова користећи један шаблон у једном СтатефулСет-у. А кључна фраза овде је „много подова за један шаблон“.
И било је велико искушење да се направи цео кластер, спакујући га у један СтатефулСет. Радиће, нема проблема са тим. Али постоји једно упозорење. Ако желимо да саставимо хетерогени кластер, односно од неколико верзија ЦлицкХоусе-а, онда почињу да се постављају питања. Да, СтатефулСет може да изврши ажурирање, и тамо можете да избаците нову верзију, објасните да не морате да испробате више од толико чворова у исто време.
Али ако екстраполирамо задатак и кажемо да желимо да направимо потпуно хетероген кластер и да не желимо да прелазимо са старе верзије на нову користећи ажурирање, већ једноставно желимо да направимо хетерогени кластер и у смислу различитих верзија ЦлицкХоусе-а иу смислу различитог складишта. Желимо, на пример, да направимо неке реплике на одвојеним дисковима, на спорим, уопште, да у потпуности изградимо хетерогени кластер. А због чињенице да СтатефулСет прави стандардизовано решење из једног шаблона, не постоји начин да се то уради.
Након мало размишљања, одлучено је да то урадимо на овај начин. Сваку реплику имамо у сопственом СтатефулСет-у. Постоје неки недостаци овог решења, али у пракси је све то потпуно инкапсулирано од стране оператера. И има много предности. Можемо да изградимо тачан кластер какав желимо, на пример, апсолутно хетероген. Дакле, у кластеру у којем имамо два шарда са једном репликом, имаћемо 2 СтатефулСета и 2 Пода управо зато што смо изабрали овај приступ из горе наведених разлога да бисмо могли да направимо хетерогени кластер.
Вратимо се практичним проблемима. У нашем кластеру треба да конфигуришемо кориснике, тј. потребно је да урадите неку конфигурацију ЦлицкХоусе-а у Кубернетесу. Оператер пружа све могућности за то.
Можемо писати шта желимо директно у ИАМЛ-у. Све опције конфигурације се мапирају директно из овог ИАМЛ-а у ЦлицкХоусе конфигурације, које се затим дистрибуирају по целом кластеру.
Можете то написати овако. Ово је на пример. Лозинка се може шифровати. Подржане су апсолутно све опције конфигурације ЦлицкХоусе-а. Ево само примера.
Конфигурација кластера се дистрибуира као ЦонфигМап. У пракси, ажурирање ЦонфигМап-а се не дешава одмах, тако да ако је кластер велики, онда процес гурања конфигурације траје неко време. Али све ово је веома згодно за употребу.
Хајде да закомпликујемо задатак. Кластер се развија. Желимо да реплицирамо податке. То јест, већ имамо два шарда, по једну реплику, а корисници су конфигурисани. Растемо и желимо да урадимо репликацију.
Шта нам је потребно за репликацију?
Потребан нам је ЗооКеепер. У ЦлицкХоусе-у, репликација је направљена помоћу ЗооКеепер-а. ЗооКеепер је потребан да би различите ЦлицкХоусе реплике имале консензус о томе који блокови података се налазе на ком ЦлицкХоусе-у.
ЗооКеепер може да користи свако. Ако предузеће има екстерни ЗооКеепер, онда се може користити. Ако не, можете га инсталирати из нашег спремишта. Постоји инсталатер који олакшава целу ову ствар.
И дијаграм интеракције целог система испада овако. Имамо Кубернетес као платформу. Извршава ЦлицкХоусе оператор. Замислио сам ЗооКеепер овде. А оператер је у интеракцији са ЦлицкХоусе и ЗооКеепер-ом. То јест, резултати интеракције.
А све ово је неопходно да би ЦлицкХоусе успешно реплицирао податке у к8с.
Погледајмо сада сам задатак, како ће изгледати манифест за репликацију.
Додајемо два одељка нашем манифесту. Први је где да набавите ЗооКеепер, који може бити унутар Кубернетеса или екстерни. Ово је само опис. И наручујемо реплике. Оне. желимо две реплике. Укупно, требало би да имамо 4 махуне на излазу. Сетимо се складиштења, вратиће се мало касније. Складиштење је посебна прича.
Било је овако.
Постаје овако. Додају се реплике. 4. није одговарао, верујемо да би их могло бити много. И ЗооКеепер је додат са стране. Шеме постају сложеније.
И време је да додате следећи задатак. Додаћемо трајно складиште.
За трајно складиштење имамо различите опције.
Ако радимо у провајдеру облака, на пример, користећи Амазон, Гоогле, онда постоји велико искушење да користимо складиште у облаку. Веома је згодно, добро је.
А постоји и друга опција. Ово је за локално складиште, када имамо локалне дискове на сваком чвору. Ова опција је много тежа за имплементацију, али је истовремено и продуктивнија.
Хајде да видимо шта имамо у вези са складиштењем у облаку.
Има предности. Веома је лако конфигурисати. Једноставно наручујемо од провајдера облака да нам да складиште таквог и таквог капацитета, те и такве класе. Наставу заказују провајдери самостално.
И постоји недостатак. За неке, ово није критичан недостатак. Наравно, биће проблема са перформансама. Веома је згодан за употребу и поуздан, али има неких потенцијалних недостатака у перформансама.
И због ЦлицкХоусе се посебно фокусира на продуктивност, чак би се могло рећи да истискује све што може, због чега многи клијенти покушавају да истисну максималну продуктивност.
А да бисмо извукли максимум из тога, потребно нам је локално складиште.
Кубернетес обезбеђује три апстракције за коришћење локалног складишта у Кубернетесу. ово:
- ЕмптиДир
- ХостПатх.
- Lokalna
Погледајмо како се разликују и у чему су слични.
Прво, у сва три приступа имамо складиште - то су локални дискови који се налазе на истом физичком к8с чвору. Али они имају неке разлике.
Почнимо са најједноставнијим, односно празним Дир. Шта је ово у пракси? У нашој спецификацији тражимо од система контејнеризације (најчешће Доцкер) да нам омогући приступ фасцикли на локалном диску.
У пракси, Доцкер креира привремену фасциклу негде дуж сопствених путања и назива је дугим хешом. И обезбеђује интерфејс за приступ.
Како ће ово функционисати у смислу перформанси? Ово ће радити при брзини локалног диска, тј. Ово је потпуни приступ вашем завртњу.
Али овај случај има свој недостатак. Персистент је прилично сумњив по овом питању. Први пут када се Доцкер помера са контејнерима, Персистент се губи. Ако Кубернетес жели да премести овај Под на други диск из неког разлога, подаци ће бити изгубљени.
Овај приступ је добар за тестове, јер већ показује нормалну брзину, али за нешто озбиљно ова опција није погодна.
Стога постоји други приступ. Ово је хостПатх. Ако погледате претходни и овај слајд, можете видети само једну разлику. Наша фасцикла је премештена из Доцкер-а директно у Кубернетес чвор. Овде је мало једноставније. Директно наводимо путању на локалном систему датотека где желимо да ускладиштимо наше податке.
Овај метод има предности. Ово је већ прави Персистент, и то класичан. Имаћемо податке забележене на диску на некој адреси.
Постоје и недостаци. Ово је сложеност управљања. Наш Кубернетес ће можда желети да премести Под на други физички чвор. И ту на сцену ступа ДевОпс. Он мора исправно да објасни целом систему да се ове махуне могу померити само на оне чворове на којима имате нешто монтирано дуж ових путања, и то не више од једног чвора у исто време. Прилично је тешко.
Посебно за ове сврхе, направили смо шаблоне у нашем оператору како бисмо сакрили сву ову сложеност. И можете једноставно рећи: „Желим да имам једну инстанцу ЦлицкХоусе-а за сваки физички чвор и дуж тог и таквог пута.“
Али нисмо једини којима је ова потреба потребна, па и господа из Кубернетеса разумеју да људи желе да имају приступ физичким дисковима, па обезбеђују трећи слој.
Зове се локално. Практично нема разлике у односу на претходни слајд. Само раније је било потребно ручно потврдити да не можемо пренети ове подове од чвора до чвора, јер морају бити прикључени дуж неке путање до локалног физичког диска, али сада је све ово знање инкапсулирано у самом Кубернетесу. И испоставило се да је много лакше конфигурисати.
Вратимо се нашем практичном проблему. Вратимо се на ИАМЛ шаблон. Овде имамо право складиште. Вратили смо се на то. Поставили смо класични ВолумеЦлаим шаблон као у к8с. И описујемо какво складиште желимо.
Након тога, к8с ће захтевати складиштење. Доделиће нам га у СтатефулСет-у. И на крају ће бити на располагању ЦлицкХоусе-у.
Имали смо ову шему. Наше Персистент Стораге је било црвено, што као да је наговештавало да то треба да се уради.
И постаје зелено. Сада је ЦлицкХоусе на к8с шема кластера у потпуности финализована. Имамо шардове, реплике, ЗооКеепер, имамо прави Персистент, који је имплементиран на овај или онај начин. Шема је већ у потпуности оперативна.
Настављамо да живимо. Наш кластер се развија. И Алексеј покушава, и издаје нову верзију ЦлицкХоусе-а.
Појављује се практичан задатак - тестирати нову верзију ЦлицкХоусе-а на нашем кластеру. И, наравно, не желите да све то избаците; желите да ставите нову верзију у једну реплику негде у крајњем углу, и можда не једну нову верзију, већ две одједном, јер често излазе.
Шта можемо рећи о овоме?
Овде имамо управо такву прилику. Ово су шаблони под. Можете написати да вам наш оператер у потпуности омогућава да изградите хетерогени кластер. Оне. конфигуришите, почевши од свих реплика у гомили, завршавајући са сваком личном репликом, коју верзију желимо ЦлицкХоусе, коју верзију желимо складиште. Можемо у потпуности да конфигуришемо кластер са конфигурацијом која нам је потребна.
Хајдемо мало дубље унутра. Пре овога смо причали о томе како ЦлицкХоусе-оператор функционише у односу на специфичности ЦлицкХоусе-а.
Сада бих желео да кажем неколико речи о томе како било који оператер уопште ради, као ио томе како је у интеракцији са К8с.
Хајде да прво погледамо интеракцију са К8с. Шта се дешава када применимо кубецтл? Наши објекти се појављују у етцд-у преко АПИ-ја.
На пример, основни Кубернетес објекти: под, СтатефулСет, услуга и тако даље низ листу.
У исто време, још се ништа физичко не дешава. Ови објекти морају бити материјализовани у кластеру.
У ту сврху се појављује контролер. Контролер је посебна к8с компонента која може материјализовати ове описе. Зна како и шта да ради физички. Зна како да покрене контејнере, шта тамо треба да се конфигурише да би сервер радио.
И материјализује наше објекте у К8с.
Али желимо да радимо не само са подовима и СтатефулСетовима, већ желимо да креирамо ЦлицкХоусеИнсталлатион, односно објекат типа ЦлицкХоусе, да бисмо њиме оперисали као јединственом целином. За сада не постоји таква могућност.
Али К8с има следећу лепу ствар. Желимо да имамо негде попут овог сложеног ентитета у којем би се наш кластер састављао од подова и СтатефулСет-а.
И шта треба учинити за ово? Прво, на слику долази прилагођена дефиниција ресурса. Шта је то? Ово је опис за К8с, да ћете имати још један тип података, да желимо да додамо прилагођени ресурс у под, СтатефулСет, који ће бити сложен изнутра. Ово је опис структуре података.
Такође га шаљемо тамо путем кубецтл аппли. Кубернетес је то са задовољством узео.
И сада у нашем складишту, објекат у етцд-у има прилику да сними прилагођени ресурс под називом ЦлицкХоусеИнсталлатион.
Али за сада се ништа даље неће догодити. То јест, ако сада креирамо ИАМЛ датотеку коју смо погледали описујући делове и реплике и кажемо „кубецтл аппли“, онда ће Кубернетес то прихватити, ставити у етцд и рећи: „Одлично, али не знам шта да радим с тим. Не знам како да одржавам ЦлицкХоусеИнсталлатион."
Сходно томе, потребан нам је неко да помогне Кубернетесу да опслужује нови тип података. Са леве стране имамо домаћи Кубернетес контролер који ради са изворним типовима података. А са десне стране би требало да имамо прилагођени контролер који може да ради са прилагођеним типовима података.
И на други начин се зове оператор. Посебно сам га укључио овде као Кубернетес, јер се може извршити и ван К8с-а. Најчешће се, наравно, сви оператори извршавају у Кубернетесу, али ништа га не спречава да стоји напољу, па се овде посебно помера напоље.
Заузврат, прилагођени контролер, такође познат као оператор, комуницира са Кубернетес-ом преко АПИ-ја. Већ зна како да комуницира са АПИ-јем. И он већ зна како да материјализује сложено коло које желимо да направимо од прилагођеног ресурса. То је управо оно што оператер ради.
Како ради оператер? Хајде да погледамо десну страну да видимо како то ради. Хајде да сазнамо како оператер све ово материјализује и како долази до даље интеракције са К8с.
Оператор је програм. Она је оријентисана на догађаје. Оператер се претплаћује на догађаје користећи Кубернетес АПИ. Кубернетес АПИ има улазне тачке где се можете претплатити на догађаје. А ако се нешто промени у К8с, онда Кубернетес шаље догађаје свима, тј. ко се претплатио на ову АПИ тачку добиће обавештења.
Оператер се пријављује на догађаје и мора да реагује. Његов задатак је да одговори на догађаје који се појављују.
Догађаји се генеришу одређеним ажурирањима. Стиже наша ИАМЛ датотека са описом ЦлицкХоусеИнсталлатион. Отишао је на етцд преко кубецтл аппли. Тамо је покренут догађај и као резултат је овај догађај дошао до ЦлицкХоусе-оператора. Оператер је добио овај опис. И он мора нешто да уради. Ако је стигло ажурирање за објекат ЦлицкХоусеИнсталлатион, онда морате да ажурирате кластер. А задатак оператера је да ажурира кластер.
Шта он то ради? Прво, морамо да направимо акциони план шта ћемо урадити са овим ажурирањем. Ажурирања могу бити веома мала, тј. мали у извршавању ИАМЛ-а, али може довести до веома великих промена на кластеру. Стога, оператер креира план, а затим га се придржава.
По овом плану, он почиње да кува ову структуру унутра да би материјализовао махуне, услуге, тј. ради оно што му је главни задатак. Овако можете да направите ЦлицкХоусе кластер у Кубернетесу.
Хајде сада да се дотакнемо једне тако занимљиве ствари. Ово је подела одговорности између Кубернетеса и оператера, тј. шта ради Кубернетес, шта ради оператер и како они међусобно комуницирају.
Кубернетес је одговоран за системске ствари, тј. за основни скуп објеката који се могу тумачити као системски опсег. Кубернетес зна како да покрене подове, како да рестартује контејнере, како да монтира волумене, како да ради са ЦонфигМап-ом, тј. све што се може назвати системом.
Оператери раде у доменима. Сваки оператер је направљен за своју предметну област. Урадили смо то за ЦлицкХоусе.
А оператер је у интеракцији управо у смислу предметне области, као што је додавање реплике, прављење дијаграма, подешавање праћења. Ово резултира поделом.
Погледајмо практичан пример како се ова подела одговорности дешава када извршимо акцију додавања реплике.
Оператер добија задатак - да дода реплику. Шта ради оператер? Оператор ће израчунати да је потребно креирати нови СтатефулСет у коме се морају описати такви и такви шаблони, захтев за запремину.
Он је све то припремио и предао К8с. Каже да му треба ЦонфигМап, СтатефулСет, Волуме. Кубернетес ради. Он материјализује основне јединице са којима оперише.
А онда ЦлицкХоусе-оператер поново ступа у игру. Он већ има физичку подлогу на којој већ може нешто да уради. И ЦлицкХоусе-оператор опет ради у домену. Оне. Конкретно, ЦлицкХоусе, да бисте укључили реплику у кластер, морате прво да конфигуришете шему података која постоји у овом кластеру. И, друго, ова реплика мора бити укључена у мониторинг како би се могла јасно пратити. Оператер је ово већ конфигурисао.
И тек након тога на сцену ступа сам ЦлицкХоусе, тј. други ентитет вишег нивоа. Ово је већ база података. Има сопствену инстанцу, још једну конфигурисану реплику која је спремна да се придружи кластеру.
Испоставило се да је ланац извршења и поделе одговорности приликом додавања реплике прилично дуг.
Настављамо са практичним задацима. Ако већ имате кластер, можете да мигрирате конфигурацију.
Направили смо тако да можете да налепите постојећи кмл, који ЦлицкХоусе разуме.
Можете фино подесити ЦлицкХоусе. Само зонирана примена је оно о чему сам говорио када сам објашњавао хостПатх, локално складиште. Овако се правилно ради зонско распоређивање.
Следећи практични задатак је праћење.
Ако се наш кластер промени, онда морамо периодично да конфигуришемо праћење.
Погледајмо дијаграм. Овде смо већ погледали зелене стрелице. Сада погледајмо црвене стрелице. Овако желимо да надгледамо наш кластер. Како метрике из ЦлицкХоусе кластера доспевају у Прометеј, а затим у Графану.
Која је потешкоћа са праћењем? Зашто се ово представља као нека врста достигнућа? Тешкоћа лежи у динамици. Када имамо један кластер и он је статичан, можемо једном да подесимо праћење и да се више не мучимо.
Али ако имамо много кластера, или се нешто стално мења, онда је процес динамичан. А стално реконфигурисање надзора је губљење ресурса и времена, тј. чак и само лењост. Ово треба аутоматизовати. Тешкоћа лежи у динамици процеса. А оператер ово веома добро аутоматизује.
Како се развијао наш кластер? У почетку је био такав.
Онда је био овакав.
На крају је постао овакав.
А надзор се врши аутоматски од стране оператера. Једна улазна тачка.
И тек на излазу гледамо у контролну таблу Графане да видимо како живот нашег кластера кључа унутра.
Иначе, Графана контролна табла се такође дистрибуира код нашег оператера директно у изворном коду. Можете се повезати и користити. Наш ДевОпс ми је дао овај снимак екрана.
Где бисмо желели да идемо даље? ово:
- Развити аутоматизацију тестирања. Главни задатак је аутоматизовано тестирање нових верзија.
- Такође заиста желимо да аутоматизујемо интеграцију са ЗооКеепер-ом. И постоје планови за интеграцију са ЗооКеепер-оператором. Оне. Оператер је написан за ЗооКеепер и логично је да два оператера почну да се интегришу како би направили погодније решење.
- Желимо да урадимо сложеније виталне знакове.
- Означио сам зеленом бојом да се приближавамо наслеђивању шаблона - ГОТОВО, односно са следећим издањем оператора већ ћемо имати наслеђивање шаблона. Ово је моћан алат који вам омогућава да направите сложене конфигурације од делова.
- И желимо аутоматизацију сложених задатака. Главни је Ре-схардинг.
Узмимо неке међурезултате.
Шта добијамо као резултат? И да ли је вредно радити или не? Да ли је уопште потребно покушати превући базу података у Кубернетес и користити оператор уопште и Алитнити оператор посебно?
На излазу добијамо:
- Значајно поједностављење и аутоматизација конфигурације, примене и одржавања.
- Одмах уграђени надзор.
- И кодификовани шаблони спремни за употребу за сложене ситуације. Радња као што је додавање реплике не мора да се ради ручно. Оператер то ради.
Остало је само једно последње питање. Већ имамо базу података у Кубернетесу, виртуелизација. Шта је са перформансама таквог решења, поготово што је ЦлицкХоусе оптимизован за перформансе?
Одговор је све је у реду! Нећу улазити у детаље, ово је тема посебног извештаја.
Али постоји такав пројекат као ТСБС. Шта је њен главни задатак? Ово је тест перформанси базе података. Ово је покушај да се упореди топло са топлим, меко са меким.
Како он ради? Генерише се један скуп података. Затим се овај скуп података покреће на различитим базама података користећи исти скуп тестова. И свака база података решава један проблем на начин на који зна. А онда можете упоредити резултате.
Већ подржава велику гомилу база података. Идентификовао сам три главна. ово:
- ТимесцалеДБ.
- ИнфлукДБ.
- ЦлицкХоусе.
Такође је направљено поређење са другим сличним решењем. Поређење са РедСхифт. Поређење је направљено на Амазону. ЦлицкХоусе је такође далеко испред свих по овом питању.
Који се закључци могу извући из онога што сам рекао?
- ДБ у Кубернетесу је могућа. Вероватно је било шта могуће, али генерално изгледа да је могуће. ЦлицкХоусе у Кубернетесу је дефинитивно могућ уз помоћ нашег оператера.
- Оператер помаже у аутоматизацији процеса и заиста олакшава живот.
- Перформансе су нормалне.
- И чини нам се да се то може и треба искористити.
Отворени код - придружите нам се!
Као што сам већ рекао, оператер је потпуно опен соурце производ, тако да би било јако добро да га користи максималан број људи. Придружи нам се! Чекамо вас све!
Хвала вам свима!
pitanja
Хвала на извештају! Моје име је Антон. Ја сам из СЕМрусх. Питам се шта је са логовањем. Слушамо о мониторингу, али ништа о логовању, ако говоримо о целом кластеру. На пример, подигли смо кластер на хардверу. И ми користимо централизовано евидентирање, прикупљајући их у заједничку гомилу користећи стандардна средства. И онда одатле добијамо податке који нас занимају.
Добро питање, тј. пријављивање на листу обавеза. Наш оператер ово још увек не аутоматизује. Још се развија, пројекат је још прилично млад. Разумемо потребу за евидентирањем. Ово је такође веома важна тема. И вероватно није ништа мање важно од праћења. Али прво на листи за имплементацију било је праћење. Биће сече. Наравно, покушавамо да аутоматизујемо све аспекте живота кластера. Дакле, одговор је да тренутно оператер, нажалост, не зна како то да уради, али је то у плану, ми ћемо то урадити. Ако желите да се придружите, молимо вас да повучете захтев.
Здраво! Хвала на извештају! Имам стандардно питање у вези са трајним волуменима. Када креирамо конфигурацију са овим оператором, како оператор одређује на ком чвору имамо прикачен одређени диск или фасциклу? Морамо му прво објаснити да молим да поставимо наш ЦлицкХоусе на ове чворове који имају диск?
Колико сам разумео, ово питање је наставак локалног складиштења, посебно његовог дела хостПатх. Ово је као да објашњавате целом систему да под треба да се покрене на том и том чвору, на који имамо физички повезан диск, који је монтиран дуж те и такве путање. Ово је цео део који сам се дотакао врло површно јер је одговор тамо прилично широк.
Укратко то изгледа овако. Наравно, морамо да обезбедимо ове количине. Тренутно не постоји динамичка одредба у локалном складишту, тако да ДевОпс мора да исече саме дискове, ове волумене. И они морају да објасне Кубернетес провизију да ћете имати Перзистентне волумене те и такве класе, који се налазе на таквим и таквим чворовима. Затим ћете морати да објасните Кубернетесу да подови који захтевају ту и такву локалну класу складиштења треба да буду усмерени само на те и такве чворове користећи ознаке. За ове сврхе, оператер има могућност да додели неку врсту ознаке и једну по инстанци хоста. И испоставило се да ће Кубернетес рутирати подове да раде само на чворовима који испуњавају захтеве, ознаке, једноставним речима. Администратори ручно додељују ознаке и дискове. А онда се скалира.
И то је трећа опција, локална, која помаже да се ово мало олакша. Као што сам већ нагласио, ово је мукотрпан рад на подешавању, који на крају помаже да се постижу максималне перформансе.
Имам друго питање у вези са овим. Кубернетес је дизајниран на такав начин да нам није битно да ли ћемо изгубити чвор или не. Шта да радимо у овом случају ако смо изгубили чвор на коме виси наша крхотина?
Да, Кубернетес је првобитно био позициониран да је наш однос са нашим махунама као стока, али овде са нама сваки диск постаје нешто попут кућног љубимца. Постоји такав проблем да их не можемо тек тако бацити. А развој Кубернетеса иде у правцу да га је немогуће потпуно филозофски третирати, као да је потпуно одбачен ресурс.
Сада на практично питање. Шта да радите ако сте изгубили чвор на којем се налазио диск? Овде се проблем решава на вишем нивоу. У случају ЦлицкХоусе-а имамо реплике које раде на вишем нивоу, тј. на нивоу ЦлицкХоусе.
Каква је резултујућа диспозиција? ДевОпс је одговоран да обезбеди да подаци не буду изгубљени. Он мора правилно да подеси репликацију и мора да обезбеди да репликација ради. Реплика на нивоу ЦлицкХоусе мора имати дуплиране податке. Ово није задатак који оператер решава. А не проблем који сам Кубернетес решава. Ово је на нивоу ЦлицкХоусе.
Шта да радите ако вам гвоздени чвор отпадне? И испоставило се да ћете морати да инсталирате други, правилно обезбедите диск на њему и примените налепнице. А након тога ће испунити услове да Кубернетес може покренути инстанцу под на њему. Кубернетес ће га покренути. Ваш број махуна није довољан да испуните наведени број. Проћи ће кроз циклус који сам показао. А на највишем нивоу, ЦлицкХоусе ће схватити да смо унели реплику, она је и даље празна и треба да почнемо да преносимо податке на њу. Оне. Овај процес још није добро аутоматизован.
Хвала на извештају! Када се догоде свакакве гадне ствари, оператер се сруши и рестартује, и у том тренутку стигну догађаји, да ли се некако носите са овим?
Шта се дешава ако се оператер сруши и поново покрене, зар не?
Да. И у том тренутку су стигли догађаји.
Задатак шта да се ради у овом случају делимично деле оператер и Кубернетес. Кубернетес има могућност да понови догађај који се догодио. Он понавља. А задатак оператера је да се увери да су ови догађаји идемпотентни када се на њему репродуцира дневник догађаја. И тако да поновљена појава истог догађаја не сломи наш систем. И наш оператер се носи са овим задатком.
Здраво! Хвала на извештају! Дмитриј Завјалов, компанија Смедова. Да ли постоје планови да се оператеру дода могућност конфигурисања помоћу хапроксија? Занимао би ме још неки балансер осим стандардног, да буде паметан и да схвати да је ЦлицкХоусе заиста ту.
Да ли говорите о Ингрессу?
Да, замените Ингресс са хапроки. У хапроки-ју можете одредити топологију кластера где има реплике.
Нисмо још размишљали о томе. Ако вам је то потребно и можете објаснити зашто је потребно, онда ће то бити могуће спровести, посебно ако желите да учествујете. Радо ћемо размотрити опцију. Кратак одговор је не, тренутно немамо такву функционалност. Хвала на савету, размотрићемо ову ствар. А ако такође објасните случај употребе и зашто је то потребно у пракси, на пример, креирате проблеме на ГитХуб-у, онда ће то бити сјајно.
Је већ.
У реду. Отворени смо за све сугестије. А хапрокси се додаје на листу задатака. Листа обавеза расте, још се не смањује. Али ово је добро, значи да је производ тражен.
Извор: ввв.хабр.цом