Докладът е посветен на практическите въпроси на разработването на оператор в Kubernetes, проектирането на неговата архитектура и основните принципи на работа.
В първата част на доклада ще разгледаме:
- какво е оператор в Kubernetes и защо е необходим;
- как точно операторът опростява управлението на сложни системи;
- какво операторът може и какво операторът не може.
След това нека да преминем към обсъждане на вътрешната структура на оператора. Разгледайте архитектурата и работата на оператора стъпка по стъпка. Нека анализираме подробно:
- взаимодействие между оператора и Kubernetes;
- какви функции поема операторът и какви делегира на Kubernetes.
Помислете за управление на сегменти и реплики на бази данни в Kubernetes.
След това ще обсъдим проблеми със съхранението на данни:
- как да работите с Persistent Storage от гледна точка на оператор;
- капани при използването на локално хранилище.
В последната част на доклада ще разгледаме практически примери за приложението с Amazon или Google Cloud Service. Докладът се основава на примера на разработката и експлоатационния опит на оператора за ClickHouse.
Video:
Казвам се Владислав Клименко. Днес исках да говоря за нашия опит в разработването и работата на оператор, а това е специализиран оператор за управление на клъстери от бази данни. Например за управление на клъстера ClickHouse.
Защо имаме възможност да говорим за оператора и ClickHouse?
- Ние поддържаме и развиваме ClickHouse.
- В момента се опитваме лека-полека да дадем своя принос към развитието на ClickHouse. И ние сме втори след Yandex по отношение на количеството промени, направени в ClickHouse.
- Опитваме се да направим допълнителни проекти за екосистемата на ClickHouse.
Бих искал да говоря за един от тези проекти. Става въпрос за ClickHouse-оператора за Kubernetes.
В моя доклад бих искал да засегна две теми:
- Първата тема е как нашият оператор на база данни ClickHouse работи в Kubernetes.
- Втората тема е как работи всеки оператор, т.е. как взаимодейства с Kubernetes.
Тези два въпроса обаче ще се пресичат в целия ми доклад.
Кой би се интересувал да чуе какво се опитвам да кажа?
- Най-интересни ще са тези, които експлоатират операторите.
- Или за тези, които искат да направят своя собствена, за да разберат как работи вътре, как операторът взаимодейства с Kubernetes и какви клопки могат да се появят.
За да разберем най-добре какво ще обсъдим днес, би било хубаво да знаем как работи Kubernetes и да имаме основен опит в облачните изчисления.
Какво е ClickHouse? Това е колонна база данни със специфика на онлайн обработка на аналитични заявки. И е с напълно отворен код.
И трябва да знаем само две неща. Трябва да знаете, че това е база данни, така че това, което ще ви кажа, ще бъде приложимо за почти всяка база данни. А фактът, че СУБД на ClickHouse се мащабира много добре, дава мащабируемостта почти линейна. И следователно състоянието на клъстера е естествено състояние за ClickHouse. И ние сме най-заинтересовани от обсъждането как да обслужваме клъстер ClickHouse в Kubernetes.
Защо е необходим там? Защо не можем да продължим да го управляваме сами? И отговорите са отчасти технически и отчасти организационни.
- На практика все по-често се сблъскваме със ситуация, при която в големите компании почти всички компоненти вече са в Kubernetes. Останете базите данни навън.
- И все по-често се задава въпросът: „Може ли да се постави вътре?“. Ето защо големите компании се опитват да произведат максимална унификация на управлението, за да могат бързо да управляват своите хранилища за данни.
- И това особено помага, ако имате нужда от максимална възможност да повторите едно и също нещо на ново място, тоест максимална преносимост.
Колко лесно или трудно е? Това, разбира се, може да се направи на ръка. Но това не е толкова лесно, защото сумираме сложността на управлението на самия Kubernetes, но в същото време се налага спецификата на ClickHouse. И се оказва такава агрегация.
И всичко взето заедно, това дава доста голям набор от технологии, които вече стават доста трудни за управление, защото Kubernetes пренася своите ежедневни проблеми в работата, а ClickHouse пренася своите проблеми в ежедневната работа. Особено ако имаме няколко ClickHouses и постоянно трябва да правим нещо с тях.
ClickHouse с динамична конфигурация има доста голям брой проблеми, които създават постоянно натоварване на DevOps:
- Когато искаме да променим нещо в ClickHouse, например да добавим реплика, шард, тогава трябва да управляваме конфигурацията.
- След това променете схемата за данни, тъй като ClickHouse има специфичен метод за шардинг. Там е необходимо да се изложи схемата на данните, да се очертаят конфигурации.
- Трябва да настроите мониторинг.
- Събиране на логове за нови шардове, за нови реплики.
- Погрижете се за възстановяването.
- И рестартирайте.
Това са такива рутинни работи, които много бих искал да улесня в работата.
Самият Kubernetes помага много в работата, но за основни системни неща.
Kubernetes е страхотен в улесняването и автоматизирането на неща като:
- Възстановяване.
- Рестартирам.
- Управление на съхранението.
Това е добре, това е правилната посока, но той не е напълно запознат с това как да работи с клъстер от база данни.
Искам повече, искам цялата база данни да работи за нас в Kubernetes.
Бих искал да получа нещо като един голям магически червен бутон, който натискате и имате клъстер, разгърнат и поддържан през целия жизнен цикъл с ежедневни задачи, които трябва да бъдат решени. Клъстер ClickHouse в Kubernetes.
И се опитахме да направим решение, което да улесни работата. Това е ClickHouse-операторът за Kubernetes от Altinity.
Операторът е програма, чиято основна задача е да управлява други програми, тоест това е мениджър.
И съдържа модели на поведение. Можете да го наречете кодифицирано знание за предметната област.
И основната му задача е да улесни живота на DevOps и да намали микроуправлението, така че той (DevOps) вече да мисли на високо ниво, тоест, така че той (DevOps) да не микроуправлява, така че да не конфигурира ръчно всички подробности.
И просто операторът е робот асистент, който се бори с микрозадачи и помага на DevOps.
Защо е необходим оператор? Той се отличава в две области:
- Когато специалистът на ClickHouse няма достатъчно опит, но вече е необходимо да управлява ClickHouse, операторът улеснява работата и ви позволява да управлявате клъстер ClickHouse с доста сложна конфигурация, без да навлизате в твърде много подробности за това как работи всичко вътре . Просто му давате задачи на високо ниво и работи.
- И втората задача, в която се показва най-добре, е когато е необходимо да се автоматизират голям брой типични задачи. Премахва микрозадачи от системните администратори.
Това е най-необходимо или от тези, които тепърва започват своето пътуване, или от тези, които трябва да направят много автоматизация.
Каква е разликата между операторския подход и други системи? Има и Хелм. Също така помага да инсталирате ClickHouse, можете да рисувате хелм диаграми, които дори ще инсталират цял ClickHouse клъстер. Каква тогава е разликата между оператора и от същия, например, Helm?
Основната фундаментална разлика е, че Helm се занимава изцяло с управление на пакети, а операторът отива крачка напред. Това е опората на целия жизнен цикъл. Това не е само инсталация, това са ежедневни задачи, които включват мащабиране, шардинг, т.е. всичко, което трябва да се направи по време на жизнения цикъл (ако е необходимо и премахване) - всичко това се решава от оператора. Той се опитва да автоматизира и обслужва целия жизнен цикъл на софтуера. Това е фундаменталната му разлика от другите представени решения.
Това беше уводната част, да продължим.
Как да изградим нашия оператор? Опитваме се да подходим към проблема, за да управляваме клъстера ClickHouse като единичен ресурс.
Тук имаме входните данни от лявата страна на картината. Това е YAML с клъстерна спецификация, която класически се предава през kubectl към Kubernetes. Там нашият оператор го взема, прави магията си. И в резултат на това получаваме такава схема. Това е внедряването на ClickHouse в Kubernetes.
И тогава бавно ще разгледаме как работи операторът, какви типични задачи могат да бъдат решени. Ще разгледаме само типични задачи, тъй като имаме ограничено време. И няма да се говори за всичко, което операторът може да реши.
Да започнем от практиката. Нашият проект е с напълно отворен код, така че можете да видите как работи в GitHub. И можете да продължите от съображенията, ако просто искате да започнете, тогава можете да започнете с Ръководството за бърз старт.
Ако искате да разберете подробно, тогава се опитваме да поддържаме документацията в повече или по-малко прилична форма.
Нека започнем с практически проблем. Първата задача, с която всички искаме да започнем, е да стартираме по някакъв начин първия пример. Как да стартирате ClickHouse с помощта на оператор, без дори да знаете как работи? Пишем манифест, т.к цялата комуникация с k8s е комуникация чрез манифести.
Ето такъв сложен манифест. Това, което сме подчертали в червено, е това, върху което трябва да се съсредоточим. Молим оператора да създаде клъстер с име demo.
Засега това са основни примери. Съхранението все още не е описано, но ще се върнем към съхранението малко по-късно. Засега ще наблюдаваме развитието на клъстера в динамика.
Ние създадохме този манифест. Подаваме го на нашия оператор. Той работеше, правеше магии.
Гледаме конзолата. Интерес представляват три компонента - това са Pod, два Service-a, StatefulSet.
Операторът е работил и виждаме какво точно е сътворил.
Той създава нещо подобно. Имаме StatefulSet, Pod, ConfigMap за всяка реплика, ConfigMap за целия клъстер. Необходими услуги като входни точки към клъстера.
Услугите са централната услуга за балансиране на натоварването и е възможно за всяка реплика, за всеки шард.
Ето нашият основен клъстер изглежда нещо подобно. Той е от един възел.
Да отидем по-нататък, ще усложним. Трябва да разделите клъстера.
Задачите ни растат, започва динамика. Искаме да добавим фрагмент. Следим развитието. Променяме нашата спецификация. Посочваме, че искаме два шарда.
Това е същият файл, който развиваме динамично с разрастването на системата. Няма съхранение, съхранението ще бъде обсъдено допълнително, това е отделен въпрос.
Захранваме YAML оператора и виждаме какво ще се случи.
Операторът помисли и направи следните обекти. Вече имаме два Pods, три Services и внезапно 2 StatefulSets. Защо 2 StatefulSets?
На диаграмата беше така - това е първоначалното ни състояние, когато имахме една шушулка.
Стана така. Дотук всичко е просто, дублирано е.
И защо StatefulSet стана два? Тук трябва да се отклоним и да обсъдим въпроса как се управляват Pods в Kubernetes.
Има такъв обект, наречен StatefulSet, който ви позволява да направите набор от Pods от шаблон. Ключовият фактор тук е шаблонът. И можете да стартирате много Pods в един StatefulSet според един шаблон. И ключовата фраза тук е „един шаблон много подове“.
И имаше голямо изкушение да направим целия клъстер, опаковайки го в един StatefulSet. Ще работи, няма проблем в това. Но има едно предупреждение. Ако искаме да сглобим разнороден клъстер, т.е. от няколко версии на ClickHouse, тогава започват нашите въпроси. Да, StatefulSet може да направи текуща актуализация, но там можете да пуснете нова версия, обяснете, че трябва да опитате не повече от толкова много възли едновременно.
Но ако екстраполираме задачата и кажем, че искаме да направим напълно хетерогенен клъстер и не искаме да преминем от старата версия към нова с помощта на текуща актуализация, а просто искаме да създадем хетерогенен клъстер както по отношение на различни версии, на ClickHouse и по отношение на различно съхранение. Искаме, например, да направим някои реплики на отделни дискове, на бавни, като цяло, да изградим напълно хетерогенен клъстер. И поради факта, че StatefulSet прави стандартизирано решение от един шаблон, така че няма начин да се направи това.
След известно мислене беше решено да направим така. Имаме всяка реплика в свой собствен StatefulSet. Има някои недостатъци на това решение, но на практика всичко напълно капсулира оператора. И има много ползи. Можем да изградим напълно такъв клъстер, какъвто искаме, например абсолютно разнороден. Следователно, в клъстер, в който имаме два шарда с една реплика, ще имаме 2 StatefulSets и 2 Pods именно защото избрахме този подход поради горните причини за възможността за изграждане на хетерогенен клъстер.
Да се върнем към практическите задачи. В нашия клъстер трябва да конфигурираме потребители, т.е. трябва да направите известна конфигурация на ClickHouse в Kubernetes. Операторът предоставя всички възможности за това.
Можем да пишем каквото искаме директно в YAML. Всички опции за конфигурация са директно картографирани от този YAML в конфигурации на ClickHouse, които след това се разполагат в целия клъстер.
Можете също да пишете така. Това е за пример. Паролата може да бъде криптирана. Поддържат се абсолютно всички опции за конфигуриране на ClickHouse. Ето само един пример.
Конфигурацията на клъстера се разпространява като ConfigMap. На практика актуализацията на ConfigMap не се случва моментално, така че ако има голям клъстер, процесът на натискане на конфигурацията отнема известно време. Но всичко това е много удобно за използване.
Ние усложняваме задачата. Клъстерът се развива. Искаме да копираме данни. Тоест вече имаме два шарда, по една реплика, потребителите са конфигурирани. Ние растем и искаме да повторим.
Какво ни трябва за репликация?
Имаме нужда от ZooKeeper. В ClickHouse репликацията се изгражда с помощта на ZooKeeper. ZooKeeper е необходим, така че различните реплики на ClickHouse да имат консенсус относно това кои блокове данни са на кой ClickHouse.
ZooKeeper може да се използва от всеки. Ако едно предприятие има външен ZooKeeper, той може да се използва. Ако не, тогава можете да инсталирате от нашето хранилище. Има инсталатор, който улеснява цялото това нещо.
И схемата на взаимодействие на цялата система се оказва така. Имаме Kubernetes като платформа. Той изпълнява оператора ClickHouse. ZooKeeper, който изобразих тук. И операторът взаимодейства както с ClickHouse, така и с ZooKeeper. Тоест получава се взаимодействие.
И всичко това е необходимо, за да може ClickHouse да репликира успешно данни на k8s.
Нека сега да разгледаме самата задача, как ще изглежда манифеста за репликация.
Добавяме два раздела към нашия манифест. Първият е откъде да получите ZooKeeper, който може да бъде вътре в Kubernetes или външен. Това е само описание. И поръчваме реплики. Тези. искаме две реплики. Общо трябва да имаме 4 шушулки на изхода. Спомняме си за съхранението, то ще се върне малко по-нататък. Съхранението е отделна песен.
Беше така.
Става така. Добавят се реплики. Четвъртият не пасна, вярваме, че може да има много от тях. И ZooKeeper се добавя отстрани. Моделите стават все по-сложни.
И е време да добавите следващата задача. Ще добавим постоянно хранилище.
За постоянно съхранение имаме различни опции.
Ако работим в облачен доставчик, например, използвайки Amazon, Google, тогава има голямо изкушение да използваме облачно хранилище. Много е удобно, добре е.
А има и втори вариант. Това е за локално съхранение, когато имаме локални дискове на всеки възел. Тази опция е много по-трудна за изпълнение, но в същото време е по-продуктивна.
Нека да видим какво имаме по отношение на облачното съхранение.
Има достойнства. Много лесно се конфигурира. Ние просто поръчваме от облачен доставчик, който, моля, ни предоставя хранилище с такъв и такъв капацитет, такъв и такъв клас. Класовете се рисуват от доставчиците независимо.
И има един недостатък. За някои това е некритичен недостатък. Разбира се, ще има някои наслагвания на производителността. Той е много удобен за използване, надежден, но има някои потенциални недостатъци в производителността.
И тъй като ClickHouse се фокусира върху производителността, дори можете да кажете, че изстисква всичко, което е възможно, така че много клиенти се опитват да изтръгнат максималната производителност.
И за да извлечем максимума от него, имаме нужда от локално хранилище.
Kubernetes предоставя три абстракции за използване на локално хранилище в Kubernetes. Това:
- EmptyDir
- HostPath.
- местен
Помислете как се различават, как си приличат.
Първо, и при трите подхода имаме съхранение - това са локални дискове, които се намират на един и същ физически k8s възел. Но те имат някои разлики.
Нека започнем с най-простия, т.е. празенДир. Какво е на практика? Ние сме тези, които искаме от системата за контейнеризация (най-често Docker) от нашата спецификация да ни предостави достъп до папка на локален диск.
На практика докерът създава временна папка някъде в собствените си пътища и я нарича дълъг хеш. И предоставя интерфейс за достъп до него.
Как ще се представи по отношение на производителността? Това ще работи със скоростта на локалния диск, т.е. това е пълен достъп до вашия винт.
Но този случай има своя недостатък. Устойчивостта в този случай е доста съмнителна. При първото движение на докера с контейнери, Persistent се губи. Ако Kubernetes иска да премести този Pod на друг диск по някаква причина, тогава данните ще бъдат загубени.
Този подход е добър за тестове, защото вече показва нормална скорост, но тази опция не е подходяща за нещо сериозно.
Следователно има втори подход. Това е hostPath. Ако погледнете предишния слайд и този, можете да видите само една разлика. Нашата папка напусна докера директно към възела Kubernetes. Тук е малко по-бързо. Ние директно записваме пътя в локалната файлова система, където бихме искали да съхраняваме нашите данни.
Този метод има предимства. Това вече е истински Persistent и то класически. На нашия диск данните ще бъдат записани на някакъв адрес.
Има и недостатъци. Това е сложността на управлението. Нашият Kubernetes може да иска да премести Pod в друг физически възел. Това е мястото, където DevOps влиза в игра. Трябва правилно да обясни на цялата система, че можете да местите тези подове само до такива възли, на които имате нещо монтирано по тези пътища, и не повече от един възел наведнъж. Достатъчно е трудно.
Специално за тези цели сме направили шаблони в нашия оператор, за да скрием цялата тази сложност. И можете просто да кажете: „Искам да имам едно копие на ClickHouse на физически възел и по такъв и такъв път.“
Но тази нужда не е само за нас, така че господата от самия Kubernetes също разбират, че хората искат да имат достъп до физически дискове, затова предоставят трето ниво.
Нарича се местно. На практика няма разлика от предишния слайд. Само по-рано беше необходимо да разберем с ръцете си, че не можем да прехвърляме тези подове от възел на възел, защото те трябва да бъдат прикрепени по такъв и такъв път към локалния физически диск, а сега цялото това знание е капсулирано в самия Kubernetes. И се оказва много по-лесно за конфигуриране.
Да се върнем към нашата практическа задача. Да се върнем към YAML шаблона. Тук имаме истински склад. Върнахме се към това. Задаваме класическия шаблон VolumeClaim като в k8s. И ние описваме какъв вид съхранение искаме.
След това k8s ще поиска съхранение. Разпределете ни го в StatefulSet. И в крайна сметка ще се окаже на разположение на ClickHouse.
Имахме такава схема. Нашето постоянно съхранение беше червено, което сякаш намекваше, че трябва да се направи.
И става зелено. Сега клъстерната схема ClickHouse на k8s е напълно финализирана. Имаме шардове, реплики, ZooKeeper, имаме истински Persistent, който е внедрен по един или друг начин. Схемата вече е напълно функционална.
Продължаваме да живеем. Нашият клъстер се разраства. И Алексей се опитва и пуска нова версия на ClickHouse.
Възниква практическа задача - да тестваме новата версия на ClickHouse на нашия клъстер. И, разбира се, не искам да пускам всичко, искам да сложа нова версия някъде в далечния ъгъл в една реплика или може би не една нова версия, а две наведнъж, защото излизат често.
Какво можем да кажем за това?
Тук имаме точно такава възможност. Това са шаблони за под. Можете да рисувате, нашият оператор напълно ви позволява да изградите разнороден клъстер. Тези. конфигуриране, започвайки от всички реплики в куп, завършвайки с всяка лична реплика, коя версия искаме ClickHouse, коя версия искаме съхранение. Можем напълно да конфигурираме клъстера в такава конфигурация, каквато ни е необходима.
Нека навлезем малко по-навътре. Преди това говорихме за това как работи ClickHouse-операторът във връзка със спецификата на ClickHouse.
Сега бих искал да кажа няколко думи за това как работи всеки оператор като цяло, както и как взаимодейства с K8s.
Помислете за взаимодействие с K8s като начало. Какво се случва, когато приложим kubectl? Чрез API нашите обекти се появяват в etcd.
Например основните обекти на Kubernetes: pod, StatefulSet, услуга и така нататък в списъка.
Все още обаче нищо физическо не се случва. Тези обекти трябва да бъдат материализирани в клъстер.
Тук се намесва контролерът. Контролерът е специален компонент k8s, който може да материализира тези описания. Той знае как и какво да прави физически. Знае как се пускат контейнери, какво трябва да се конфигурира там, за да работи сървъра.
И материализира нашите обекти в K8s.
Но ние искаме да работим не само с pods, StatefulSets, искаме да създадем ClickHouseInstallation, т.е. обект от типа ClickHouse, за да работим с него като цяло. Засега няма такава възможност.
Но K8s има и друго хубаво нещо. Искаме някъде да имаме такъв сложен обект, в който нашият клъстер ще бъде сглобен от pods и StatefulSet.
И какво трябва да се направи за това? Първо, Custom Resource Definition излиза на сцената. Какво е? Това е описание за K8s, че ще имате друг тип данни, който искаме да добавим към групата, StatefulSet, персонализиран ресурс, който ще бъде сложен отвътре. Това е описание на структурата на данните.
Ние също го изпращаме там чрез kubectl apply. Kubernetes го прие с радост.
И сега в нашето хранилище обектът в etcd има възможност да напише персонализиран ресурс, наречен ClickHouseInstallation.
Но засега нищо друго няма да се случи. Тоест, ако сега създадем YAML файл, който разгледахме с описание на шарда, репликите и кажем „kubectl apply“, тогава Kubernetes ще го приеме, ще го постави в etcd и ще каже: „Страхотно, но не знам какво да правя с него. Не знам как да поддържам ClickHouseInstallation."
Съответно имаме нужда от някой, който да помогне на Kubernetes да обслужва новия тип данни. Отляво имаме стоков контролер на Kubernetes, който работи с фондови типове данни. А отдясно трябва да имаме персонализиран контролер, който може да работи с потребителски типове данни.
И по друг начин се нарича оператор. Специално го извадих тук за Kubernetes, защото може да се изпълнява и извън K8s. Най-често, разбира се, всички инструкции се изпълняват в Kubernetes, но нищо не му пречи да стои отвън, така че тук е специално изведено.
И вече, на свой ред, персонализираният контролер, известен също като оператор, взаимодейства с Kubernetes чрез API. Той вече знае как да взаимодейства с API. И той вече знае как да материализира сложна схема, която искаме да направим от персонализиран ресурс. Точно това прави операторът.
Как работи операторът? Нека да погледнем дясната страна, за да видим как го прави. Ще разберем как операторът материализира всичко това и как се осъществява по-нататъшното взаимодействие с K8s.
Операторът е програмата. Тя е ориентирана към събития. Операторът се абонира за събития, използвайки Kubernetes API. API на Kubernetes има входни точки, където можете да се абонирате за събития. И ако нещо се промени в K8s, тогава Kubernetes изпраща събития на всички, т.е. които са се абонирали за тази API точка, ще получават известия.
Операторът се абонира за събития и трябва да реагира по някакъв начин. Неговата задача е да реагира на възникващи събития.
Събитията се генерират от някои актуализации. Нашият YAML файл пристига с описание на ClickHouseInstallation. Той отиде в etcd чрез kubectl apply. Там работи събитие, в резултат на което това събитие дойде до оператора ClickHouse. Операторът получи това описание. И той трябва да направи нещо. Ако дойде актуализация на обекта ClickHouseInstallation, тогава трябва да актуализирате клъстера. И задачата на оператора е да актуализира клъстера.
Какво прави той? Първо, трябва да изготвим план за действие какво ще правим с тази актуализация. Актуализациите могат да бъдат много малки, т.е. малък при YAML изпълнение, но може да доведе до много големи промени в клъстера. Затова операторът създава план и след това се придържа към него.
Той започва, според този план, да кипи тази структура отвътре, за да материализира подс, услуги, т.е. да прави това, което е основната му задача. Това е като изграждането на клъстер ClickHouse в Kubernetes.
Сега нека се докоснем до толкова интересно нещо. Това е разделение на отговорността между Kubernetes и оператора, т.е. какво прави Kubernetes, какво прави операторът и как взаимодействат помежду си.
Kubernetes отговаря за системните неща, т.е. за основен набор от обекти, които могат да се интерпретират като системен обхват. Kubernetes знае как да стартира pods, как да рестартира контейнери, как да прави томове за монтиране, как да работи с ConfigMap, т.е. всичко, което може да се нарече система.
Операторите работят в предметни области. Всеки оператор е създаден за своята предметна област. Направихме за ClickHouse.
И операторът взаимодейства точно по отношение на предметната област, като добавяне на реплика, изработване на схема, настройка на мониторинг. Има такова разделение.
Нека да разгледаме практически пример за това как се случва това разделяне на проблемите, когато извършваме действие за добавяне на реплика.
Задачата идва при оператора - да добави реплика. Какво прави операторът? Операторът ще изчисли, че е необходимо да се направи нов StatefulSet, в който е необходимо да се опишат такива и такива шаблони, заявка за обем.
Той го подготви всичко и го предава на K8s. Той казва, че има нужда от ConfigMap, StatefulSet, Volume. Kubernetes работи. Той материализира основните единици, с които оперира.
И тогава ClickHouse-операторът отново влиза в игра. Той вече има физическа капсула, на която вече можете да направите нещо. И ClickHouse-операторът отново работи по отношение на предметната област. Тези. По-конкретно, ClickHouse, за да включите реплика в клъстер, трябва първо да конфигурирате схемата за данни, която съществува в този клъстер. И, второ, тази забележка трябва да влезе в мониторинга, за да може ясно да се проследи. Операторът вече го настройва.
И едва след това влиза в действие самият ClickHouse, т.е. друг субект от по-високо ниво. Това вече е база данни. Той има свой собствен екземпляр, следващата конфигурирана реплика, която е готова да се присъедини към клъстера.
Оказва се, че веригата на изпълнение и разделяне на отговорността при добавяне на реплика е достатъчно дълга.
Продължаваме с нашите практически задачи. Ако клъстерът вече съществува, тогава можете да мигрирате конфигурацията.
Направихме го така, че да е възможно преминаването към съществуващия xml, което ClickHouse разбира.
Можете да настроите фино ClickHouse. Просто зонирано внедряване е това, за което говорих, когато обяснявах hostPath, локално съхранение. Ето как да направите правилно зонирано разполагане.
Следващата практическа задача е мониторингът.
Ако нашият клъстер се промени, тогава трябва периодично да конфигурираме мониторинга.
Нека да разгледаме диаграмата. Тук вече разгледахме зелените стрелки. Сега нека да разгледаме червените стрелки. Ето как искаме да наблюдаваме нашия клъстер. Как показателите от клъстера ClickHouse влизат в Prometheus и след това в Grafana.
Какъв е проблемът с наблюдението? Защо това се представя като някакво постижение? Трудността е в динамиката. Когато имаме един клъстер и той е статичен, тогава можете да настроите мониторинг веднъж и да не се занимавате повече.
Но ако имаме много клъстери или нещо постоянно се променя, тогава процесът е динамичен. И постоянното преконфигуриране на мониторинга е загуба на ресурси и време; дори просто мързелив. Това трябва да се автоматизира. Трудността е в динамиката на процеса. И операторът автоматизира това много добре.
Как се разви нашият клъстер? В началото той беше такъв.
Тогава той беше такъв.
Накрая стана такъв.
И мониторингът се извършва автоматично от оператора. Единична входна точка.
И само гледаме изхода в таблото на Графана, как кипи животът на нашия клъстер вътре.
Между другото, Grafana dashboard също се разпространява с нашия оператор направо в изходния код. Можете да свържете и използвате. Тази екранна снимка ми беше дадена от нашия DevOps.
Къде бихме искали да отидем след това? Това:
- Разработете автоматизация на тестовете. Основната задача е автоматизирано тестване на нови версии.
- Също така наистина искаме да автоматизираме интеграцията със ZooKeeper. И планира да се интегрира с ZooKeeper-оператор. Тези. е написан оператор за ZooKeeper и е логично двата оператора да започнат да се интегрират, за да изградят по-удобно решение.
- Искаме да направим по-сложни проверки на живота.
- Маркирах в зелено, че имаме наследяване на шаблони на път - ГОТОВО, т.е. със следващото издание на оператора вече ще имаме наследяване на шаблони. Това е мощен инструмент, който ви позволява да изграждате сложни конфигурации от части.
- И ние искаме да автоматизираме сложни задачи. Основният е Re-sharding.
Нека направим някои междинни резултати.
Какво получаваме в резултат? И струва ли си или не? Трябва ли дори да се опитам да плъзна базата данни в Kubernetes и да приложа оператора като цяло и оператора Alitnity в частност.
На изхода получаваме:
- Драматично опростете и автоматизирайте конфигурацията, внедряването и поддръжката.
- Незабавно вграден мониторинг.
- И готови за използване кодифицирани шаблони за сложни ситуации. Вече действието от типа за добавяне на реплика не е необходимо да се извършва на ръка. Това се прави от оператора.
Остава само последният въпрос. Вече имаме база данни в Kubernetes, виртуализация. Какво ще кажете за производителността на такова решение, особено след като ClickHouse е оптимизиран за производителност?
Отговорът е, че всичко е наред! Няма да описвам подробно, това е тема на отделен доклад.
Но има такъв проект като TSBS. Каква е основната му задача? Това е тест за ефективност на базата данни. Това е опит да се сравни топло с топло, меко с меко.
Как работи той? Генерира се един набор от данни. След това този набор от данни на същия набор от тестове се изпълнява в различни бази данни. И всяка база данни решава един проблем по начина, по който може. И тогава можете да сравните резултатите.
Той вече поддържа голям набор от бази данни. Набелязах три основни. Това:
- timescaledb.
- InfluxDB.
- clickhouse.
Направено е и сравнение с друго подобно решение. Сравнение с RedShift. Сравнението е направено в Amazon. ClickHouse също е доста пред всички по този въпрос.
Какви изводи могат да се направят от казаното от мен?
- DB в Kubernetes е възможен. Вероятно можете да направите всичко, но като цяло изглежда, че можете. ClickHouse в Kubernetes определено е възможен с помощта на нашия оператор.
- Операторът помага за автоматизиране на процесите и наистина опростява живота.
- Изпълнението е нормално.
- И ни се струва, че може и трябва да се използва.
Отворен код - присъединете се към нас!
Както казах, операторът е продукт с напълно отворен код, така че би било много добре, ако максимален брой хора го използват. Присъедини се сега! Очакваме ви всички!
Благодаря на всички!
Въпроси
Благодаря за доклада! Казвам се Антон. Аз съм от SEMrush. Чудя се какво става със сечта. Чуваме за мониторинг, но нищо за регистриране, ако говорим за целия клъстер. Например, имаме клъстер на хардуер. И ние използваме централизирано регистриране, събираме го в обща купчина по стандартни средства. И тогава оттам получаваме данни, които са интересни за нас.
Добър въпрос, т.е. влизане в списъка със задачи. Нашият оператор все още не автоматизира това. Все още се развива, проектът е все още доста млад. Разбираме необходимостта от дърводобив. Това също е много важна тема. И вероятно е не по-малко важно от наблюдението. Но първо в списъка за изпълнение беше мониторингът. Ще има сеч. Естествено, ние се опитваме да автоматизираме всички аспекти от живота на клъстера. Затова отговорът е, че в момента операторът, за съжаление, не знае как да стане това, но е в плановете, ние ще го направим. Ако искате да се присъедините, изтеглете заявка, моля.
Здравейте! Благодаря за доклада! Имам стандартен въпрос, свързан с постоянните томове. Когато създаваме конфигурация с този оператор, как операторът определя на кой възел имаме диск или папка? Първо трябва да му обясним, че моля, поставете нашия ClickHouse точно на тези възли, които имат диск?
Доколкото разбирам, този въпрос е продължение на локалното хранилище, особено частта от hostPath. Все едно да обясняваме на цялата система, че е необходимо подът да се стартира точно на такъв и такъв възел, на който имаме физически свързан диск, който е монтиран на такъв и такъв път. Това е цял раздел, който пипнах много повърхностно, защото там отговорът е доста голям.
Накратко изглежда така. Разбира се, трябва да осигурим тези обеми. В момента няма динамично осигуряване в локалното хранилище, така че DevOps трябва да изреже самите дискове, ето тези томове. И те трябва да обяснят осигуряването на Kubernetes, че ще имате постоянни томове от такъв и такъв клас, който се намира на такива и такива възли. Тогава ще е необходимо да се обясни на Kubernetes, че подовете, които изискват такъв и такъв локален клас за съхранение, трябва да бъдат планирани според етикети само за такива и такива възли. За тези цели операторът има възможност да присвои някакъв вид етикет и по един на екземпляр на хост. И се оказва, че подовете ще бъдат маршрутизирани от Kubernetes, за да работят само на възли, които отговарят на изискванията, етикетите, с прости думи. Администраторите присвояват етикети, извършват ръчно осигуряване на дискове. И тогава се мащабира.
И само третият вариант локален помага да се направи малко по-лесно. Както вече подчертах, това е старателна работа по настройка, която в крайна сметка помага да се постигне максимална производителност.
Имам втори въпрос свързан с това. Kubernetes е замислен по такъв начин, че за нас няма значение дали ще загубим възел или не. Какво трябва да направим в този случай, ако сме загубили възела, където имаме шард?
Да, Kubernetes първоначално беше позициониран, че връзката ни с нашите капсули е като добитък, но тук всеки диск се превръща в нещо като домашен любимец. Има такъв проблем, че не можем просто да ги изхвърлим. И развитието на Kubernetes върви в посока, че е невъзможно да се третира изцяло философски, като напълно изхвърлен ресурс.
Сега един практически въпрос. Какво да направите, ако сте загубили възела, на който е бил дискът? Тук проблемът е решен на по-високо ниво. В случая с ClickHouse имаме реплики, които работят на по-високо ниво, т.е. на ниво ClickHouse.
Какво е разположението? DevOps е отговорен за гарантирането, че данните не се губят. Той трябва правилно да настрои репликацията и трябва да гарантира, че репликацията работи. В репликата на ниво ClickHouse данните трябва да бъдат дублирани. Това не е задачата, която операторът решава. А не задачата, която решава самият Kubernetes. Това е на ниво ClickHouse.
Какво да направите, ако вашият железен възел е паднал? И се оказва, че ще е необходимо да поставите втория, правилно да преместите диска върху него, да приложите етикети. И след това ще удовлетвори изискванията Kubernetes върху него да може да изпълнява екземпляр на pod. Kubernetes ще го стартира. Вашият брой капсули не е достатъчен за посочения. Ще премине през цикъла, който показах. И на най-високо ниво ClickHouse ще разбере, че имаме въведена реплика, тя все още е празна и трябва да започнем да прехвърляме данни към нея. Тези. този процес все още е слабо автоматизиран.
Благодаря за доклада! Когато се случат какви ли не гадни неща, операторът забива и се рестартира и в този момент пристигат събития, обработвате ли това по някакъв начин?
Какво се случва, ако операторът се срине и се рестартира, да?
да И в този момент настъпиха събитията.
Задачата какво да се направи в този случай е частично разделена между оператора и Kubernetes. Kubernetes има способността да преиграе събитие, което се е случило. Той преиграва. И задачата на оператора е да се увери, че когато регистърът на събитията е възпроизведен върху него, тези събития са идемпотентни. И така, че повторната поява на едно и също събитие да не счупи нашата система за нас. И нашият оператор се справя с тази задача.
Здравейте! Благодаря за доклада! Дмитрий Завиалов, компания Смедов. Планира ли се добавяне на опции за персонализиране с haproxy към оператора? Интересен е някой друг балансьор освен стандартния, за да е умен и да разбере, че ClickHouse е реален там.
За Ingress ли говориш?
Да, замени Ingress с haproxy. В haproxy можете да посочите топологията на клъстера, където има реплики.
Досега не сме мислили за това. Ако имате нужда от това и можете да обясните защо е необходимо, тогава ще бъде възможно да го приложите, особено ако искате да участвате. Ще се радваме да разгледаме варианта. Краткият отговор е не, в момента нямаме такава функционалност. Благодаря за съвета, ще разгледаме това. И ако също така обясните случая на използване и защо е необходимо на практика, например, създавате проблеми в GitHub, тогава ще бъде страхотно.
Вече има.
Глоба. Отворени сме за всякакви предложения. И haproxy е поставен в списъка със задачи. Списъкът със задачи расте, все още не се свива. Но това е добре, това означава, че продуктът е в търсенето.
Източник: www.habr.com