Есеп Kubernetes-те операторды дамытудың практикалық мәселелеріне, оның архитектурасын жобалауға және жұмыс істеудің негізгі принциптеріне арналған.
Есептің бірінші бөлігінде біз мыналарды қарастырамыз:
- Kubernetes-те оператор дегеніміз не және ол не үшін қажет;
- оператор күрделі жүйелерді басқаруды қалай нақты жеңілдетеді;
- оператор не істей алады, нені оператор алмайды.
Әрі қарай біз оператордың ішкі құрылымын талқылауға көшеміз. Оператордың архитектурасы мен жұмысын кезең-кезеңімен қарастырыңыз. Егжей-тегжейлі талдап көрейік:
- оператор мен Кубернетес арасындағы өзара әрекеттесу;
- оператор қандай функцияларды қабылдайды және Kubernetes-ке қандай өкілдер береді.
Kubernetes жүйесінде бөлшектер мен дерекқор репликаларын басқаруды қарастырыңыз.
Әрі қарай деректерді сақтау мәселелерін талқылаймыз:
- оператордың көзқарасы бойынша Persistent Storage-мен қалай жұмыс істеу керек;
- Жергілікті жадты пайдаланудың қателері.
Есептің қорытынды бөлімінде біз қолданудың практикалық мысалдарын қарастырамыз Amazon немесе Google Cloud қызметі арқылы. Есеп ClickHouse үшін оператордың дамуы мен жұмыс тәжірибесінің мысалына негізделген.
Бейне:
Менің атым Владислав Клименко. Бүгін мен операторды әзірлеу және пайдалану тәжірибеміз туралы айтқым келді, бұл дерекқор кластерлерін басқаруға арналған мамандандырылған оператор. Мысалы ClickHouse кластерін басқару үшін.
Неліктен бізде оператор және ClickHouse туралы сөйлесуге мүмкіндік бар?
- Біз ClickHouse қолданбасын қолдаймыз және дамытамыз.
- Қазіргі уақытта біз ClickHouse дамуына өз үлесімізді баяу қосуға тырысамыз. Ал ClickHouse-те енгізілген өзгерістер көлемі бойынша біз Яндекстен кейінгі екінші орындамыз.
- Біз ClickHouse экожүйесі үшін қосымша жобалар жасауға тырысамыз.
Мен осы жобалардың бірі туралы айтқым келеді. Бұл Kubernetes үшін ClickHouse-операторы туралы.
Өз баяндамамда мен екі тақырыпқа тоқталғым келеді:
- Бірінші тақырып - біздің ClickHouse дерекқор операторы Kubernetes-те қалай жұмыс істейді.
- Екінші тақырып - кез келген оператор қалай жұмыс істейді, яғни Кубернетеспен қалай әрекеттеседі.
Дегенмен, бұл екі сұрақ менің баяндамамның ішінде тоғысады.
Менің айтайын деп жатқанымды кім тыңдағысы келеді?
- Ең қызықтысы операторларды пайдаланатындар болады.
- Немесе оның ішінде қалай жұмыс істейтінін, оператордың Кубернетеспен қалай әрекеттесетінін және қандай тұзақтар пайда болуы мүмкін екенін түсіну үшін өз бетінше жасағысы келетіндер үшін.
Бүгін біз нені талқылайтынымызды жақсы түсіну үшін Кубернетес қалай жұмыс істейтінін және бұлттық есептеулерде негізгі білімі бар екенін білу жақсы болар еді.
ClickHouse дегеніміз не? Бұл аналитикалық сұрауларды онлайн өңдеу ерекшеліктері бар бағандық дерекқор. Және бұл толығымен ашық бастапқы код.
Ал бізге тек екі нәрсені білу керек. Сіз бұл дерекқор екенін білуіңіз керек, сондықтан мен сізге айтатын нәрсе кез келген дерекқорға жарамды болады. ClickHouse ДҚБЖ өте жақсы масштабталатындығы масштабтауға дерлік сызықтық береді. Сондықтан кластердің күйі ClickHouse үшін табиғи күй болып табылады. Бізді Kubernetes-те ClickHouse кластеріне қалай қызмет көрсету керектігін талқылау қызықтырады.
Ол сонда не үшін керек? Неліктен біз оны өзіміз басқара алмаймыз? Ал жауаптар жартылай техникалық, ішінара ұйымдастырушылық.
- Іс жүзінде, біз үлкен компанияларда барлық дерлік компоненттер Kubernetes-те болған кезде мұндай жағдайды жиі кездестіреміз. Дерекқорларды сыртта қалдырыңыз.
- «Оны ішіне қоюға бола ма?» деген сұрақ жиі қойылады. Сондықтан ірі компаниялар өздерінің деректер қоймаларын жылдам басқара алу үшін менеджменттің максималды унификациясын жасауға тырысады.
- Және бұл, әсіресе, сізге бірдей нәрсені жаңа жерде қайталаудың максималды мүмкіндігі, яғни максималды тасымалдану қажет болса көмектеседі.
Бұл қаншалықты оңай немесе қиын? Мұны, әрине, қолмен жасауға болады. Бірақ бұл оңай емес, өйткені біз Kubernetes-ті басқарудың күрделілігін қосамыз, бірақ сонымен бірге ClickHouse ерекшеліктері жүктеледі. Және мұндай жинақтау болып шығады.
Барлығымен бірге бұл басқару қиынға соғатын технологиялардың жеткілікті үлкен жиынтығын береді, өйткені Кубернетес өзінің күнделікті мәселелерін іске қосады, ал ClickHouse өз мәселелерін күнделікті жұмысқа шығарады. Әсіресе, егер бізде бірнеше ClickHouse болса және олармен үнемі бірдеңе істеу керек болса.
Динамикалық конфигурациясы бар ClickHouse-да DevOps жүйесінде тұрақты жүктемені тудыратын көптеген мәселелер бар:
- Біз ClickHouse ішінде бір нәрсені өзгерткіміз келгенде, мысалы, репликаны, үзіндіні қосқымыз келсе, конфигурацияны басқаруымыз керек.
- Содан кейін деректер схемасын өзгертіңіз, себебі ClickHouse бағдарламасында белгілі бір бөлу әдісі бар. Онда деректер схемасын орналастыру, конфигурацияларды орналастыру қажет.
- Мониторинг орнату керек.
- Жаңа үзінділер, жаңа көшірмелер үшін журналдар жинағы.
- Қалпына келтіру туралы қамқорлық жасаңыз.
- Және қайта іске қосыңыз.
Бұл кәдімгі жұмыстар, мен оны пайдалануды жеңілдеткім келеді.
Кубернетестің өзі жұмыста көп көмектеседі, бірақ негізгі жүйеде.
Кубернетес келесідей нәрселерді жеңілдету және автоматтандыруда тамаша:
- Қалпына келтіру.
- Қайтадан қосу.
- Сақтауды басқару.
Бұл жақсы, бұл дұрыс бағыт, бірақ ол дерекқор кластерін қалай басқаруға болатынын мүлдем білмейді.
Мен көбірек алғым келеді, мен бүкіл дерекқор біз үшін Кубернетесте жұмыс істегенін қалаймын.
Мен сіз басқан үлкен бір сиқырлы қызыл түйме сияқты нәрсені алғым келеді және сізде шешуді қажет ететін күнделікті тапсырмалары бар бүкіл өмірлік цикл бойы орналастырылған және қызмет көрсететін кластер бар. Kubernetes ішіндегі ClickHouse кластері.
Және біз жұмысты жеңілдететін шешім қабылдауға тырыстық. Бұл Altinity ұсынған Kubernetes үшін ClickHouse-операторы.
Оператор – негізгі міндеті басқа программаларды басқару болып табылатын программа, яғни ол менеджер.
Және ол мінез-құлық үлгілерін қамтиды. Оны пәндік аймақ туралы кодталған білім деп атауға болады.
Оның негізгі міндеті - DevOps-тың өмірін жеңілдету және микроменеджментті азайту, ол (DevOps) қазірдің өзінде жоғары деңгейде ойлайтындай етіп, яғни ол (DevOps) микроменеджмент жасамайтындай етіп, ол барлық параметрлерді қолмен конфигурацияламайды. егжей.
Тек оператор микротапсырмалармен күресетін және DevOps-қа көмектесетін робот көмекшісі.
Оператор не үшін қажет? Ол екі салада үздік:
- ClickHouse маманының тәжірибесі жеткіліксіз болса, бірақ ClickHouse-ты басқару қажет болса, оператор операцияны жеңілдетеді және оның ішінде барлығы қалай жұмыс істейтіні туралы тым көп егжей-тегжейлі айтпай-ақ күрделі конфигурациямен ClickHouse кластерін басқаруға мүмкіндік береді. . Сіз оған тек жоғары деңгейлі тапсырмалар бересіз және ол жұмыс істейді.
- Ал ол өзін жақсы көрсететін екінші тапсырма - бұл көптеген типтік тапсырмаларды автоматтандыру қажет болғанда. Жүйелік басқарушылардан микротапсырмаларды жояды.
Бұл саяхатын енді бастағандарға немесе көп автоматтандыруды қажет ететіндерге өте қажет.
Операторлық тәсілдің басқа жүйелерден айырмашылығы неде? Хельм де бар. Бұл сонымен қатар ClickHouse орнатуға көмектеседі, сіз тіпті бүкіл ClickHouse кластерін орнататын руль диаграммаларын сала аласыз. Оператордың, мысалы, Helm операторынан айырмашылығы неде?
Негізгі іргелі айырмашылық - Helm пакетті басқаруға қатысты және оператор одан әрі қадам жасайды. Бұл бүкіл өмірлік циклдің тірегі. Бұл тек орнату ғана емес, бұл масштабтауды, бөлшектеуді, яғни өмірлік циклде жасалуы керек барлық нәрселерді (қажет болса, жоюды да) қамтитын күнделікті тапсырмалар - мұның барлығын оператор шешеді. Ол бүкіл бағдарламалық жасақтаманың өмірлік циклін автоматтандыруға және қызмет көрсетуге тырысады. Бұл оның ұсынылған басқа шешімдерден түбегейлі айырмашылығы.
Бұл кіріспе бөлім болатын, әрі қарай жалғастырайық.
Біз операторымызды қалай құрастырамыз? ClickHouse кластерін бір ресурс ретінде басқару үшін мәселені шешуге тырысамыз.
Мұнда суреттің сол жағындағы кіріс деректері бар. Бұл кластерлік спецификациясы бар YAML, ол kubectl арқылы классикалық түрде Kubernetes-ке беріледі. Онда біздің оператор оны алады, өзінің сиқырын жасайды. Нәтижесінде біз осындай схеманы аламыз. Бұл Kubernetes-те ClickHouse іске асыру.
Содан кейін біз оператордың қалай жұмыс істейтінін, қандай типтік тапсырмаларды шешуге болатынын баяу қарастырамыз. Біз тек типтік тапсырмаларды қарастырамыз, өйткені уақытымыз шектеулі. Оператор шеше алатын барлық нәрсе туралы айтылмайды.
Тәжірибеден бастайық. Біздің жоба толығымен ашық бастапқы коды болып табылады, сондықтан оның GitHub сайтында қалай жұмыс істейтінін көре аласыз. Ал сіз ойларды жалғастыра аласыз, егер сіз жай ғана бастағыңыз келсе, онда сіз жылдам бастау нұсқаулығынан бастай аласыз.
Егер сіз егжей-тегжейлі түсінгіңіз келсе, біз құжаттаманы азды-көпті лайықты түрде сақтауға тырысамыз.
Практикалық есептен бастайық. Біз бәріміз бастағымыз келетін бірінші тапсырма - бірінші мысалды қандай да бір жолмен іске қосу. ClickHouse қалай жұмыс істейтінін білмей, оператордың көмегімен қалай іске қосуға болады? Біз манифест жазып жатырмыз, өйткені k8s-пен барлық байланыс - бұл манифест арқылы байланыс.
Міне, осындай күрделі манифест. Біз қызыл түспен белгілеген нәрсеге назар аударуымыз керек. Біз оператордан демо деп аталатын кластерді құруды сұраймыз.
Әзірге бұл негізгі мысалдар. Сақтау орны әлі сипатталған жоқ, бірақ біз сақтауға сәл кейінірек ораламыз. Әзірге біз кластердің дамуын динамика бойынша бақылайтын боламыз.
Біз бұл манифестті жасадық. Біз оны операторымызға береміз. Ол жұмыс істеді, сиқыр жасады.
Біз консольге қараймыз. Үш компонент қызығушылық тудырады - бұл Pod, екі Service-a, StatefulSet.
Оператор жұмыс істеді, біз оның нақты не жасағанын көреміз.
Ол осындай нәрсені жасайды. Бізде әрбір реплика үшін StatefulSet, Pod, ConfigMap, бүкіл кластер үшін ConfigMap бар. Міндетті түрде кластерге кіру нүктелері ретінде қызметтер.
Қызметтер орталық Load Balancer қызметі болып табылады және ол әрбір көшірме үшін, әрбір үзінді үшін мүмкін.
Міне, біздің базалық кластеріміз осылай көрінеді. Ол бір түйіннен.
Әрі қарай жүрейік, күрделендіреміз. Сізге кластерді бөлу керек.
Біздің міндеттеріміз өсуде, динамика басталады. Біз үзінді қосқымыз келеді. Біз дамуды қадағалаймыз. Біз спецификациямызды өзгертеміз. Біз екі сынық керек екенін көрсетеміз.
Бұл жүйенің өсуімен динамикалық түрде дамытатын файл. Сақтау жоқ, сақтау одан әрі талқыланады, бұл бөлек мәселе.
Біз YAML операторын береміз және не болатынын көреміз.
Оператор ойланып, келесі нысандарды жасады. Бізде екі Pod, үш қызмет және кенеттен 2 StatefulSets бар. Неліктен 2 StatefulSets?
Диаграммада осылай болды - бұл біздің бастапқы күйіміз, бізде бір шұңқыр болған кезде.
Осылай болып кетті. Әзірге бәрі қарапайым, ол қайталанды.
Неліктен StatefulSet екіге айналды? Мұнда біз Kubernetes-те Pods қалай басқарылатыны туралы сұрақты шегініс және талқылауымыз керек.
Үлгіден Pod жиынын жасауға мүмкіндік беретін StatefulSet деп аталатын нысан бар. Мұнда негізгі фактор - Үлгі. Және бір үлгіге сәйкес бір StatefulSet ішінде көптеген подкасттарды іске қосуға болады. Мұнда негізгі сөз тіркесі - «бір үлгіде көп Pod».
Бүкіл кластерді бір StatefulSet жинағына жинақтауға үлкен азғыру болды. Ол жұмыс істейді, онда ешқандай проблема жоқ. Бірақ бір ескерту бар. Егер біз гетерогенді кластерді, яғни ClickHouse-тың бірнеше нұсқаларынан құрастырғымыз келсе, онда біздің сұрақтарымыз басталады. Иә, StatefulSet жылжымалы жаңартуды жасай алады, бірақ ол жерде сіз жаңа нұсқаны шығара аласыз, бір уақытта көп түйіндерді қолданып көру керек екенін түсіндіре аласыз.
Бірақ егер біз тапсырманы экстраполяциялайтын болсақ және біз толығымен гетерогенді кластерді жасағымыз келетінін және жылжымалы жаңарту арқылы ескі нұсқадан жаңасына ауысқымыз келмейтінін айтсақ, жай ғана әртүрлі нұсқалар тұрғысынан да гетерогенді кластерді жасағымыз келеді. ClickHouse және әртүрлі сақтау тұрғысынан. Біз, мысалы, жеке дискілерде, баяу дискілерде бірнеше көшірме жасауды, тұтастай алғанда, гетерогенді кластерді толығымен құруды қалаймыз. StatefulSet бір үлгіден стандартталған шешімді жасайтындықтан, мұны істеудің ешқандай жолы жоқ.
Біраз ойланып, біз осылай істейміз деп шешті. Бізде әрбір көшірме өзінің StatefulSet жүйесінде бар. Бұл шешімнің кейбір кемшіліктері бар, бірақ іс жүзінде бәрі операторды толығымен қамтиды. Ал пайдасы көп. Біз толығымен осындай кластерді қалауымызша құра аламыз, мысалы, абсолютті гетерогенді. Сондықтан, бізде бір репликасы бар екі бөлік бар кластерде бізде 2 StatefulSets және 2 Pod болады, өйткені біз гетерогенді кластерді құру мүмкіндігінің жоғарыда аталған себептеріне байланысты осы тәсілді таңдадық.
Практикалық тапсырмаларға оралайық. Біздің кластерімізде біз пайдаланушыларды конфигурациялауымыз керек, яғни. сізге Kubernetes ішіндегі ClickHouse конфигурациясын жасау керек. Бұл үшін оператор барлық мүмкіндіктерді ұсынады.
Біз қалаған нәрсені YAML-де тікелей жаза аламыз. Барлық конфигурация опциялары осы YAML ішінен ClickHouse конфигурацияларына тікелей салыстырылады, содан кейін олар кластерде орналастырылады.
Сіз де осылай жаза аласыз. Бұл мысал үшін. Құпия сөзді шифрлауға болады. Барлық ClickHouse конфигурация опцияларына қолдау көрсетіледі. Міне, бір ғана мысал.
Кластер конфигурациясы ConfigMap ретінде таратылады. Іс жүзінде ConfigMap жаңартуы бірден болмайды, сондықтан үлкен кластер болса, конфигурацияны итеру процесі біраз уақытты алады. Бірақ мұның бәрі қолдануға өте ыңғайлы.
Біз тапсырманы күрделендіреміз. Кластер дамып келеді. Біз деректерді көшіргіміз келеді. Яғни, бізде екі бөлік бар, әрқайсысы бір көшірме, пайдаланушылар конфигурацияланған. Біз өсіп жатырмыз және қайталанғымыз келеді.
Көшіру үшін бізге не қажет?
Бізге ZooKeeper керек. ClickHouse бағдарламасында репликация ZooKeeper көмегімен құрастырылады. ZooKeeper әр түрлі ClickHouse көшірмелері қай ClickHouse деректер блоктары туралы консенсусқа ие болуы үшін қажет.
ZooKeeper кез келген адам пайдалана алады. Егер кәсіпорында сыртқы ZooKeeper болса, оны пайдалануға болады. Олай болмаса, біздің репозиторийден орнатуға болады. Барлығын жеңілдететін орнатушы бар.
Ал бүкіл жүйенің өзара әрекеттесу схемасы былай болып шығады. Бізде платформа ретінде Kubernetes бар. Ол ClickHouse операторын орындайды. ZooKeeper Мен мұнда суретке түстім. Ал оператор ClickHouse және ZooKeeper екеуімен де әрекеттеседі. Яғни, өзара әрекеттесу алынады.
Мұның бәрі ClickHouse үшін деректерді k8s-ге сәтті көшіру үшін қажет.
Енді репликация манифесті қалай көрінетін тапсырманың өзін қарастырайық.
Манифестімізге екі бөлім қосамыз. Біріншісі, Kubernetes ішінде немесе сыртқы болуы мүмкін ZooKeeper-ді қайдан алуға болады. Бұл жай ғана сипаттама. Ал біз көшірмелерге тапсырыс береміз. Анау. бізге екі көшірме керек. Барлығында бізде 4 шұңқыр болуы керек. Сақтау туралы есімізде, ол сәл әрі қарай оралады. Сақтау - бұл бөлек ән.
Мынадай болды.
Осылай болады. Көшірмелер қосылады. 4-і сәйкес келмеді, олардың көп болуы мүмкін деп ойлаймыз. Ал ZooKeeper жағына қосылған. Үлгілер күрделене түсуде.
Ал келесі тапсырманы қосу уақыты келді. Біз тұрақты сақтауды қосамыз.
Тұрақты сақтау үшін бізде әртүрлі опциялар бар.
Егер біз бұлт провайдерінде жұмыс істейтін болсақ, мысалы, Amazon, Google арқылы жұмыс істейтін болсақ, онда бұлтты сақтауды пайдаланудың керемет азғырулары бар. Бұл өте ыңғайлы, жақсы.
Және екінші нұсқа бар. Бұл әрбір түйінде жергілікті дискілер болған кезде жергілікті сақтау үшін. Бұл опцияны жүзеге асыру әлдеқайда қиын, бірақ сонымен бірге ол өнімдірек.
Бұлтты сақтауға қатысты бізде не бар екенін көрейік.
Сыйлықтар бар. Оны конфигурациялау өте оңай. Біз жай ғана бұлттық провайдерден тапсырыс береміз, ол бізге осындай және осындай сыйымдылықты, осындай және осындай классты сақтауды береді. Сабақтарды провайдерлер дербес бояйды.
Және кемшілігі бар. Кейбіреулер үшін бұл сын көтермейтін кемшілік. Әрине, кейбір өнімділік қабаттары болады. Пайдалану өте ыңғайлы, сенімді, бірақ өнімділікте кейбір ықтимал кемшіліктер бар.
Ал содан бері ClickHouse өнімділікке баса назар аударады, тіпті мүмкін болатынның бәрін сығады деп айтуға болады, сондықтан көптеген клиенттер максималды өнімділікті сығуға тырысады.
Ал одан барынша пайда алу үшін бізге жергілікті қойма қажет.
Kubernetes Kubernetes жергілікті жадты пайдалану үшін үш абстракцияны ұсынады. Бұл:
- EmptyDir
- HostPath.
- жергілікті
Олардың қалай ерекшеленетінін, қалай ұқсас екенін қарастырыңыз.
Біріншіден, барлық үш тәсілде бізде сақтау орны бар - бұл бірдей физикалық k8s түйінінде орналасқан жергілікті дискілер. Бірақ олардың кейбір айырмашылықтары бар.
Ең қарапайымнан бастайық, яғни emptyDir. Іс жүзінде бұл не? Біз контейнерлеу жүйесінен (көбінесе Docker) спецификациямыздан жергілікті дискідегі қалтаға қол жеткізуді сұраймыз.
Іс жүзінде докер өз жолдарында уақытша қалтаны жасайды, оны ұзақ хэш деп атайды. Және оған қол жеткізу үшін интерфейсті қамтамасыз етеді.
Ол өнімділік тұрғысынан қалай орындалады? Бұл жергілікті дискінің жылдамдығымен жұмыс істейді, яғни. бұл сіздің бұрандаңызға толық қол жетімділік.
Бірақ бұл істің кемшілігі бар. Бұл жағдайда тұрақтылық өте күмәнді. Контейнерлері бар докердің бірінші қозғалысы кезінде Persistent жоғалады. Егер Kubernetes бұл Pod-ды қандай да бір себептермен басқа дискіге жылжытқысы келсе, деректер жоғалады.
Бұл әдіс сынақтар үшін жақсы, өйткені ол қалыпты жылдамдықты көрсетеді, бірақ бұл опция маңызды нәрсеге жарамайды.
Сондықтан екінші көзқарас бар. Бұл hostPath. Егер сіз алдыңғы және осы слайдты қарасаңыз, тек бір ғана айырмашылықты көре аласыз. Біздің қалта докерді тікелей Kubernetes түйініне қалдырды. Бұл жерде сәл жылдамырақ. Біз деректерді сақтағымыз келетін жергілікті файлдық жүйеге жолды тікелей жазамыз.
Бұл әдістің артықшылықтары бар. Бұл қазірдің өзінде нағыз Persistent және классикалық. Біздің дискімізде деректер белгілі бір мекенжайға жазылады.
Кемшіліктері де бар. Бұл басқарудың күрделілігі. Біздің кубернеттер Pod-ды басқа физикалық түйінге жылжытқысы келуі мүмкін. Дәл осы жерде DevOps ойнайды. Ол бүкіл жүйеге осы жолдар бойында бірдеңе орнатылған түйіндерге ғана осы подкасттарды жылжытуға болатынын және бір уақытта бір түйіннен артық болмайтынын дұрыс түсіндіруі керек. Бұл жеткілікті қиын.
Әсіресе осы мақсаттар үшін біз осы күрделілікті жасыру үшін операторымызда шаблондар жасадық. Сіз жай ғана айта аласыз: «Мен физикалық түйінде және осындай және осындай жол бойында ClickHouse бір данасын алғым келеді».
Бірақ бұл қажеттілік біз үшін ғана емес, сондықтан Кубернетес мырзаларының өзі де адамдар физикалық дискілерге қол жеткізгісі келетінін түсінеді, сондықтан олар үшінші деңгейді қамтамасыз етеді.
Жергілікті деп аталады. Алдыңғы слайдтан іс жүзінде ешқандай айырмашылық жоқ. Тек бұрын ғана қолмен орындау керек еді, біз бұл түйіндерді түйіннен түйінге көшіре алмаймыз, өйткені олар жергілікті физикалық дискіге осындай және осындай жол бойымен қосылуы керек, ал қазір бұл білімнің барлығы Кубернетестің өзінде инкапсулирленген. Және конфигурациялау әлдеқайда оңай.
Практикалық тапсырмамызға оралайық. YAML үлгісіне оралайық. Мұнда бізде нақты қойма бар. Біз бұған қайта оралдық. Біз классикалық VolumeClaim үлгісін k8s сияқты орнаттық. Және біз қандай сақтауды қалайтынымызды сипаттаймыз.
Осыдан кейін k8s сақтауды сұрайды. Оны бізге StatefulSet ішінде бөліңіз. Ақыр соңында, ол ClickHouse-тің иелігінде болады.
Бізде осындай схема болды. Біздің тұрақты сақтау орнымыз қызыл түсті, бұл мұны істеу керек дегенді білдіретін сияқты.
Және ол жасылға айналады. Енді k8s кластеріндегі ClickHouse схемасы толығымен аяқталды. Бізде сынықтар, репликалар, ZooKeeper бар, бізде бір жолмен жүзеге асырылатын нақты Persistent бар. Схема қазірдің өзінде толығымен жұмыс істейді.
Біз өмір сүруді жалғастырамыз. Біздің кластер өсіп келеді. Ал Алексей ClickHouse-тың жаңа нұсқасын шығаруға тырысып жатыр.
Практикалық тапсырма туындайды - біздің кластерімізде ClickHouse жаңа нұсқасын сынау. Және, әрине, мен мұның бәрін шығарғым келмейді, мен жаңа нұсқаны бір көшірменің алыс бұрышында орналастырғым келеді немесе мүмкін бір жаңа нұсқа емес, бірден екеуі, өйткені олар жиі шығады.
Бұл туралы не айта аламыз?
Міне, бізде дәл осындай мүмкіндік бар. Бұл подкаст үлгілері. Сіз бояуға болады, біздің оператор толығымен гетерогенді кластерді құруға мүмкіндік береді. Анау. конфигурациялау, топтағы барлық көшірмелерден бастап, әрбір жеке репликамен аяқталатын, ClickHouse нұсқасын қалаймыз, қай нұсқаны сақтауды қалаймыз. Біз кластерді өзімізге қажет конфигурацияда толығымен конфигурациялай аламыз.
Ішіне біраз тереңірек үңілейік. Бұған дейін ClickHouse-операторының ClickHouse ерекшеліктеріне қатысты қалай жұмыс істейтіні туралы айтқан болатынбыз.
Енді мен кез келген оператордың жалпы қалай жұмыс істейтіні, сондай-ақ оның K8-мен өзара әрекеттесуі туралы бірнеше сөз айтқым келеді.
Бастау үшін K8-мен өзара әрекеттесуді қарастырыңыз. kubectl қолданбасын қолданғанда не болады? API арқылы біздің нысандар etcd ішінде пайда болады.
Мысалы, негізгі Kubernetes нысандары: pod, StatefulSet, қызмет және тізім арқылы т.б.
Дегенмен, әлі физикалық ештеңе жоқ. Бұл нысандар кластерде материалдандырылуы керек.
Бұл ретте контроллер кіреді. Контроллер бұл сипаттамаларды жүзеге асыра алатын арнайы k8s компоненті болып табылады. Ол физикалық түрде қалай және не істеу керектігін біледі. Ол контейнерлерді қалай іске қосу керектігін, сервер жұмыс істеуі үшін не конфигурациялау керектігін біледі.
Және ол біздің нысандарды K8-де материалдандырады.
Бірақ біз тек қана подкасттармен, StatefulSets-пен жұмыс істегіміз келмейді, сонымен бірге тұтастай жұмыс істеу үшін ClickHouseInstallation, яғни ClickHouse түрінің нысанын жасағымыз келеді. Әзірге мұндай мүмкіндік жоқ.
Бірақ K8-де тағы бір жақсы нәрсе бар. Біз бір жерде кластеріміз подкасттардан және StatefulSet-тен жиналған осындай күрделі нысанның болғанын қалаймыз.
Және бұл үшін не істеу керек? Алдымен, пайдаланушы ресурсының анықтамасы көрініске кіреді. Бұл не? Бұл K8 құрылғыларына арналған сипаттама, біз подкастқа қосқымыз келетін басқа деректер түрі болады, StatefulSet, ішінде күрделі болатын реттелетін ресурс. Бұл деректер құрылымының сипаттамасы.
Біз оны kubectl application арқылы жібереміз. Кубернетес қуана қабылдады.
Енді біздің қоймада etcd нысанында ClickHouseInstallation деп аталатын реттелетін ресурс жазу мүмкіндігі бар.
Бірақ әзірге басқа ештеңе болмайды. Яғни, егер біз қазір бөлшектің, көшірмелердің сипаттамасымен қарастыратын YAML файлын жасасақ және «kubectl қолданылады» десек, Кубернетес оны қабылдап, etcd ішіне қойып: «Тамаша, бірақ мен білмеймін» дейді. онымен не істеу керек. Мен ClickHouseInstallation қызметін қалай сақтау керектігін білмеймін."
Тиісінше, бізге Kubernetes жаңа деректер түріне қызмет көрсетуге көмектесетін біреу қажет. Сол жақта бізде қор деректер түрлерімен жұмыс істейтін қор Kubernetes контроллері бар. Ал оң жақта бізде реттелетін деректер түрлерімен жұмыс істей алатын реттелетін контроллер болуы керек.
Ал басқаша ол оператор деп аталады. Мен оны Kubernetes үшін арнайы осында шығардым, өйткені оны K8-ден тыс жерде де орындауға болады. Көбінесе, әрине, барлық мәлімдемелер Kubernetes-те орындалады, бірақ оның сыртта тұруына ештеңе кедергі келтірмейді, сондықтан мұнда ол арнайы шығарылады.
Ал қазірдің өзінде, өз кезегінде, оператор ретінде белгілі пайдаланушы контроллері API арқылы Kubernetes-пен әрекеттеседі. Ол API интерфейсімен қалай әрекеттесу керектігін біледі. Және ол біз реттелетін ресурстан жасағымыз келетін күрделі схеманы қалай жүзеге асыру керектігін біледі. Оператор дәл осылай жасайды.
Оператор қалай жұмыс істейді? Оның қалай істейтінін көру үшін оң жағын қарастырайық. Оператор мұның бәрін қалай жүзеге асыратынын және K8s-мен одан әрі әрекеттесу қалай жүзеге асатынын анықтаймыз.
Оператор – бағдарлама. Ол оқиғаға бағытталған. Оператор Kubernetes API арқылы оқиғаларға жазылады. Kubernetes API-де оқиғаларға жазылуға болатын кіру нүктелері бар. Егер K8-де бірдеңе өзгерсе, Кубернетес оқиғаларды барлығына жібереді, яғни. осы API нүктесіне жазылғандар хабарландыруларды алады.
Оператор оқиғаларға жазылады және қандай да бір реакция жасауы керек. Оның міндеті - пайда болған оқиғаларға жауап беру.
Оқиғалар кейбір жаңартулар арқылы жасалады. Біздің YAML файлымыз ClickHouseInstallation сипаттамасымен бірге келеді. Ол kubectl application арқылы etcd сайтына барды. Онда оқиға жұмыс істеді, нәтижесінде бұл оқиға ClickHouse-операторына келді. Оператор бұл сипаттаманы алды. Және ол бірдеңе істеу керек. ClickHouseInstallation нысанына жаңарту келсе, кластерді жаңарту қажет. Ал оператордың міндеті – кластерді жаңарту.
Ол не істеп жатыр? Біріншіден, біз осы жаңартумен не істейтініміз туралы әрекет жоспарын жасауымыз керек. Жаңартулар өте аз болуы мүмкін, яғни. YAML орындауында аз, бірақ кластерде өте үлкен өзгерістерге әкелуі мүмкін. Сондықтан оператор жоспар жасайды, содан кейін ол оны ұстанады.
Ол бастайды, осы жоспарға сәйкес, бұл құрылымды ішінде қайнату үшін бөтелкелерді, қызметтерді, т.б. оның негізгі міндетін орындау. Бұл Kubernetes-те ClickHouse кластерін құру сияқты.
Енді осындай қызықты жайтқа тоқталайық. Бұл Кубернетес пен оператор арасындағы жауапкершілікті бөлу, яғни. Кубернетес не істейді, оператор не істейді және олар бір-бірімен қалай әрекеттеседі.
Кубернетес жүйелік заттарға жауапты, яғни. жүйелік аумақ ретінде түсіндіруге болатын объектілердің негізгі жиынтығы үшін. Кубернетес подкасттарды қалай іске қосу керектігін, контейнерлерді қайта іске қосуды, монтаждау томдарын қалай жасау керектігін, ConfigMap-пен қалай жұмыс істеу керектігін біледі, яғни. жүйе деп атауға болатын кез келген нәрсе.
Операторлар тақырыптық аймақтарда жұмыс істейді. Әрбір оператор өзінің пәндік аймағына арналған. Біз ClickHouse үшін жасадық.
Ал оператор репликаны қосу, схеманы құру, мониторингті орнату сияқты пәндік аймақ тұрғысынан дәл өзара әрекеттеседі. Мұндай бөліну бар.
Көшірме қосу әрекетін орындаған кезде алаңдаушылықтардың бұл бөлінуінің практикалық мысалын қарастырайық.
Тапсырма операторға келеді - репликаны қосу. Оператор не істеп жатыр? Оператор жаңа StatefulSet жасау қажет екенін есептейді, онда осындай және осындай үлгілерді, көлемдік шағымды сипаттау қажет.
Барлығын дайындап, K8-ге береді. Ол ConfigMap, StatefulSet, Volume қажет екенін айтады. Кубернетес жұмыс істейді. Ол өзі жұмыс істейтін негізгі бірліктерді материалдандырады.
Содан кейін ClickHouse-оператор қайтадан іске қосылады. Оның қазірдің өзінде бірдеңе істеуге болатын физикалық подколькасы бар. Ал ClickHouse-оператор қайтадан тақырыптық аймақ бойынша жұмыс істейді. Анау. Атап айтқанда, ClickHouse, репликаны кластерге қосу үшін, біріншіден, осы кластерде бар деректер схемасын теңшеу керек. Ал, екіншіден, бұл ескерту анық қадағалануы үшін мониторингке енгізілуі керек. Оператор оны орнатып қойған.
Осыдан кейін ғана ClickHouse өзі іске қосылады, яғни. басқа жоғары деңгейдегі ұйым. Бұл қазірдің өзінде дерекқор. Оның өз данасы бар, кластерге қосылуға дайын келесі конфигурацияланған көшірме.
Көшірмені қосу кезінде жауапкершілікті бөлу және орындау тізбегі жеткілікті ұзақ болады.
Біз практикалық тапсырмаларымызды жалғастырамыз. Кластер бұрыннан бар болса, конфигурацияны тасымалдауға болады.
Біз мұны ClickHouse түсінетін бар xml ішіне өтуге болатындай етіп жасадық.
ClickHouse параметрін дәл баптай аласыз. Жай аймақтарға бөлінген орналастыру - бұл hostPath, жергілікті сақтауды түсіндіру кезінде айтқаным. Аймақтық орналастыруды осылай дұрыс орындау керек.
Келесі практикалық тапсырма – бақылау.
Кластеріміз өзгерсе, мониторингті мезгіл-мезгіл конфигурациялау қажет.
Диаграммаға назар аударайық. Біз мұнда жасыл жебелерді қарастырдық. Енді қызыл жебелерді қарастырайық. Біз кластерімізді осылай бақылап отырғымыз келеді. ClickHouse кластеріндегі көрсеткіштер Прометейге, содан кейін Графанаға қалай түседі.
Мониторингте қандай проблема бар? Неліктен бұл қандай да бір жетістік ретінде ұсынылған? Күрделілігі динамикада. Бізде бір кластер болса және ол статикалық болса, бақылауды бір рет орната аласыз және енді алаңдамайсыз.
Бірақ егер бізде кластерлер көп болса немесе бір нәрсе үнемі өзгеріп отырса, онда процесс динамикалық болады. Ал мониторингті үнемі қайта конфигурациялау – ресурстар мен уақытты босқа кетіру; тіпті жалқау. Мұны автоматтандыру қажет. Қиындық процестің динамикасында. Ал оператор мұны өте жақсы автоматтандырады.
Біздің кластер қалай дамыды? Басында ол солай болды.
Сосын ол осылай болды.
Ақырында ол осылай болды.
Ал бақылауды оператор автоматты түрде жасайды. Бір кіру нүктесі.
Біз жай ғана Grafana бақылау тақтасындағы шығуға қараймыз, біздің кластердің өмірі қалай қайнап жатыр.
Айтпақшы, Grafana бақылау тақтасы біздің оператормен тікелей бастапқы кодта таратылады. Сіз қосылып, пайдалана аласыз. Бұл скриншотты маған DevOps берді.
Әрі қарай қайда барғымыз келеді? Бұл:
- Сынақтарды автоматтандыруды дамыту. Негізгі міндет – жаңа нұсқаларды автоматтандырылған тестілеу.
- Біз сондай-ақ ZooKeeper-пен интеграцияны автоматтандыруды қалаймыз. Және ZooKeeper-операторымен біріктіруді жоспарлап отыр. Анау. ZooKeeper үшін оператор жазылған және ыңғайлырақ шешімді құру үшін екі оператордың біріктіруді бастағаны қисынды.
- Біз күрделірек өмірлік тексерулер жасағымыз келеді.
- Мен жасыл түспен бізде үлгілердің мұрагерлік жолында бар екенін атап өттім - ДАЙЫНДЫ, яғни оператордың келесі шығарылымында бізде үлгі мұрагерлік болады. Бұл бөліктерден күрделі конфигурацияларды құруға мүмкіндік беретін қуатты құрал.
- Ал біз күрделі тапсырмаларды автоматтандырғымыз келеді. Ең бастысы - қайта бөлу.
Кейбір аралық нәтижелер жасайық.
Нәтижесінде біз не аламыз? Және бұл тұр ма, жоқ па? Маған дерекқорды Kubernetes ішіне апарып, жалпы операторды, атап айтқанда Alitnity операторын қолдануға тырысуым керек пе?
Шығу кезінде біз мынаны аламыз:
- Конфигурацияны, орналастыруды және техникалық қызмет көрсетуді айтарлықтай жеңілдетіңіз және автоматтандырыңыз.
- Бірден кірістірілген бақылау.
- Күрделі жағдайлар үшін пайдалануға дайын кодталған үлгілер. Көшірмені қосу түріндегі әрекетті қолмен орындау қажет емес. Мұны оператор жасайды.
Тек соңғы сұрақ қалды. Бізде Kubernetes-те дерекқор бар, виртуализация. Әсіресе ClickHouse өнімділік үшін оңтайландырылғандықтан, мұндай шешімнің өнімділігі туралы не деуге болады?
Жауап - бәрі жақсы! Мен егжей-тегжейлі сипаттамаймын, бұл жеке баяндаманың тақырыбы.
Бірақ TSBS сияқты жоба бар. Оның негізгі міндеті қандай? Бұл дерекқор өнімділігі сынағы. Бұл жылы мен жылы, жұмсақ пен жұмсақ салыстыру әрекеті.
Ол қалай жұмыс істейді? Бір деректер жинағы жасалады. Содан кейін бір сынақ жиынындағы бұл деректер жиынтығы әртүрлі дерекқорларда іске қосылады. Әр дерекқор бір мәселені мүмкіндігінше шешеді. Содан кейін нәтижелерді салыстыруға болады.
Ол қазірдің өзінде көптеген деректер қорын қолдайды. Мен негізгі үшеуін анықтадым. Бұл:
- уақыт шкаласыb.
- InfluxDB.
- кликхаус.
Басқа ұқсас шешіммен салыстыру да жүргізілді. RedShift-пен салыстыру. Салыстыру Amazon-да жүргізілді. ClickHouse да бұл мәселеде барлығынан алда келеді.
Менің айтқанымнан қандай қорытынды жасауға болады?
- Кубернетестегі DB мүмкін. Мүмкін, қолыңнан бәрі келеді, бірақ жалпы алғанда қолыңнан келетін сияқты. Kubernetes-тегі ClickHouse біздің операторымыздың көмегімен мүмкін екені сөзсіз.
- Оператор процестерді автоматтандыруға көмектеседі және өмірді шынымен жеңілдетеді.
- Өнімділік қалыпты.
- Ал, бізге оны қолдануға болады және керек сияқты.
Ашық дереккөз - бізге қосылыңыз!
Мен айтқанымдай, оператор толығымен ашық бастапқы өнім, сондықтан оны ең көп адамдар пайдаланса, өте жақсы болар еді. Қазір қосылыңыз! Барлығыңызды күтеміз!
Барлығыңа Рақмет!
Сіздің сұрақтарыңыз
Есеп үшін рахмет! Менің атым Антон. Мен SEMrush-тенмін. Мен ағаш кесу не болды деп ойлаймын. Біз бақылау туралы естиміз, бірақ бүкіл кластер туралы айтатын болсақ, тіркеу туралы ештеңе жоқ. Мысалы, бізде аппараттық құралда кластер бар. Ал біз орталықтандырылған каротажды қолданамыз, оны стандартты құралдармен ортақ үйіндіге жинаймыз. Содан кейін біз үшін қызықты деректерді аламыз.
Жақсы сұрақ, яғни тапсырмалар тізіміне кіру. Біздің оператор мұны әлі автоматтандырмаған. Ол әлі де дамып келеді, жоба әлі жас. Біз ағаш кесу қажеттілігін түсінеміз. Бұл да өте маңызды тақырып. Және оның маңыздылығы бақылаудан кем емес шығар. Бірақ іске асыру тізімінде бірінші кезекте мониторинг болды. Тіркеу болады. Әрине, біз кластер өмірінің барлық аспектілерін автоматтандыруға тырысамыз. Сондықтан жауап, қазіргі уақытта оператор, өкінішке орай, мұны қалай жасау керектігін білмейді, бірақ бұл жоспарда бар, біз мұны істейміз. Егер сіз қосылғыңыз келсе, өтінімді алыңыз.
Сәлеметсіз бе! Есеп үшін рахмет! Менде тұрақты томдарға қатысты стандартты сұрағым бар. Біз осы оператормен конфигурацияны жасағанда, оператор қай түйінде дискі немесе қалта бар екенін қалай анықтайды? Біз оған алдымен ClickHouse-ды дискі бар осы түйіндерге орналастыратынын түсіндіруіміз керек пе?
Менің түсінуімше, бұл сұрақ жергілікті сақтаудың жалғасы, әсіресе оның hostPath бөлігі. Бұл бүкіл жүйеге подкасттың дәл осындай және осындай түйінде іске қосылуы қажет екенін түсіндіру сияқты, бізде физикалық қосылған диск бар, ол осындай және осындай жолға орнатылған. Бұл мен өте үстірт қозғаған тұтас бөлім, өйткені онда жауап өте үлкен.
Қысқаша айтқанда, бұл осылай көрінеді. Әрине, біз бұл көлемдерді қамтамасыз етуіміз керек. Қазіргі уақытта жергілікті жадта динамикалық қамтамасыз ету жоқ, сондықтан DevOps дискілерді өздері кесіп тастауы керек, міне, бұл томдар. Және олар Kubernetes провизиясын түсіндіруі керек, сізде осындай және осындай түйіндерде орналасқан осындай сыныптың тұрақты томдары болады. Содан кейін Кубернетеске жергілікті сақтау класын талап ететін подкасттарды тек осындай және осындай түйіндерге арналған белгілерге сәйкес жоспарлау керектігін түсіндіру қажет. Осы мақсаттар үшін операторда белгінің қандай да бір түрін және әрбір хост данасын тағайындау мүмкіндігі бар. Қарапайым тілмен айтқанда, талаптарға, белгілерге сәйкес келетін түйіндерде ғана іске қосу үшін подкасттарды Kubernetes бағыттайтыны белгілі болды. Әкімшілер белгілерді тағайындайды, дискілерді қолмен қамтамасыз етеді. Содан кейін ол таралады.
Жергілікті үшінші нұсқа ғана оны біршама жеңілдетуге көмектеседі. Мен жоғарыда атап өткенімдей, бұл ең көп өнімділікке қол жеткізуге көмектесетін баптаудың қиын жұмысы.
Осыған байланысты екінші сұрағым бар. Кубернетес түйінді жоғалту немесе жоғалтпау бізге маңызды емес етіп жасалған. Егер бізде сынық бар түйінді жоғалтып алған болсақ, бұл жағдайда не істеуіміз керек?
Иә, Кубернетес бастапқыда біздің бұршақтармен қарым-қатынасымыз ірі қара мал сияқты деп тұжырымдады, бірақ мұнда әрбір диск үй жануарларына ұқсайды. Біз оларды тастап кете алмайтын мәселе бар. Ал Кубернетестің дамуы оны толығымен жойылған ресурс ретінде философиялық тұрғыдан қарау мүмкін емес деген бағытта жүреді.
Енді практикалық сұрақ. Диск орналасқан түйінді жоғалтып алсаңыз не істеу керек? Мұнда мәселе жоғары деңгейде шешіледі. ClickHouse жағдайында бізде жоғары деңгейде жұмыс істейтін көшірмелер бар, яғни. ClickHouse деңгейінде.
Ерекшелік дегеніміз не? DevOps деректердің жоғалмауын қамтамасыз етуге жауапты. Ол репликацияны дұрыс орнатуы керек және репликацияның іске қосылуын қамтамасыз етуі керек. ClickHouse деңгейіндегі репликада деректер қайталануы керек. Бұл оператор шешетін тапсырма емес. Кубернетес өзі шешетін тапсырма емес. Бұл ClickHouse деңгейінде.
Егер сіздің темір түйініңіз құлап кетсе не істеу керек? Ал екіншісін қою, дискіні дұрыс жылжыту, этикеткаларды қою керек болады. Осыдан кейін ол Kubernetes под данасын іске қоса алатын талаптарды қанағаттандырады. Кубернетес оны іске қосады. Бөлшектердің саны көрсетілгенге жеткіліксіз. Ол мен көрсеткен цикл арқылы өтеді. Ең жоғары деңгейде ClickHouse бізде көшірме енгізілгенін, ол әлі бос екенін және оған деректерді тасымалдауды бастау керек екенін түсінеді. Анау. бұл процесс әлі де нашар автоматтандырылған.
Есеп үшін рахмет! Кез келген жағымсыз жағдайлар орын алғанда, оператор бұзылып, қайта іске қосылады және сол сәтте оқиғалар пайда болады, сіз мұны қандай да бір жолмен өңдейсіз бе?
Оператор бұзылып, қайта іске қосылса не болады, иә?
Иә. Міне, сол сәтте оқиғалар болды.
Бұл жағдайда не істеу керектігі туралы тапсырма оператор мен Кубернетес арасында жартылай бөлінген. Кубернетес болған оқиғаны қайталау мүмкіндігі бар. Ол қайталайды. Оператордың міндеті - оқиғалар журналы онда қайта ойнатылғанда, бұл оқиғалар идемпотентті екеніне көз жеткізу. Сол оқиғаның қайталануы біз үшін жүйемізді бұзбауы үшін. Ал біздің оператор бұл тапсырманы орындауда.
Сәлеметсіз бе! Есеп үшін рахмет! Дмитрий Завиалов, компания Смедов. Операторға хапрокси көмегімен теңшеу опцияларын қосу жоспарлануда ма? Стандарттыдан басқа кейбір басқа теңдестіргіш қызықты, сондықтан ол ақылды және ClickHouse бар екенін түсінеді.
Сіз Ingress туралы айтып отырсыз ба?
Иә, Ingress сөзін гапроксимен ауыстырыңыз. Хапроксиде сіз оның көшірмелері бар кластер топологиясын көрсете аласыз.
Әзірге бұл туралы ойланбадық. Егер сізге қажет болса және оның не үшін қажет екенін түсіндіре алсаңыз, оны жүзеге асыруға болады, әсіресе қатысқыңыз келсе. Біз опцияны қарастыруға қуаныштымыз. Қысқа жауап - жоқ, бізде қазір мұндай функция жоқ. Кеңесіңізге рахмет, біз мұны қарастырамыз. Егер сіз сондай-ақ пайдалану жағдайын түсіндірсеңіз және оның іс жүзінде не үшін қажет екенін түсіндірсеңіз, мысалы, GitHub-та мәселелерді жасасаңыз, бұл тамаша болады.
Енді бар.
Жақсы. Біз кез келген ұсыныстарға ашықпыз. Ал гапрокси тапсырмалар тізіміне енгізілген. Тапсырмалар тізімі әлі де азаймай, өсіп келеді. Бірақ бұл жақсы, бұл өнімнің сұранысқа ие екенін білдіреді.
Ақпарат көзі: www.habr.com