Лесно и удобно ли е да се създава Kubernetes клъстер? Обявяваме addon-operator

След shell-operator представяме неговия по-голям брат — addon-operator. Това е проект с отворен код, който се използва за инсталиране на системни компоненти в Kubernetes клъстера, които можем да наречем с общото наименование — добавки.

Защо изобщо са нужни добавки?

Не е тайна, че Kubernetes не е готов продукт "всичко в едно" и за изграждането на "зрял" клъстер ще са необходими различни добавки. Addon-operator ще помогне за инсталиране, конфигуриране и поддържане на актуалността на тези добавки.

Необходимостта от допълнителни компоненти в клъстера е разкрита в доклад на колегата driusha. В кратце, ситуацията с Kubernetes в момента е такава, че за простата инсталация "за игра" може да се разчита на компонентите от кутията, за разработчици и тестване може да се добави Ingress, но за пълна инсталация, за която можем да кажем "вашият production е готов", трябва да добавим около дузина различни добавки: нещо за мониторинг, нещо за логове, да не забравим ingress и cert-manager, да определим групи от възли, да добавим мрежови политики и да подправим с настройки sysctl и pod autoscaler...

Каква е спецификата на работа с тях?

Както показва практиката, просто инсталиране не е достатъчно. За това удобно работа с клъстера, добавките ще трябва да бъдат актуализирани, отключвани (премахвани от клъстера), а нещо ще се иска да се тества преди инсталацията в production клъстера.

Така че, може би, и Ansible е достатъчен? Възможно е. Но пълноценните добавки обикновено не могат да функционират без настройки. Тези настройки могат да се различават в зависимост от варианта на клъстера (aws, gce, azure, bare-metal, do, …). Някои настройки не могат да бъдат зададени предварително — те трябва да се получат от клъстера. А клъстерът не е статичен: за някои настройки ще трябва да следите промените. И тук Ansible вече не е достатъчен: нужна е програма, която живее в клъстера, т.е. Kubernetes Operator.

Тези, които са опитали на практика shell-operator, ще кажат, че задачите по инсталиране и актуализиране на добавките и следене за настройките могат да бъдат решени с помощта на хукове за shell-operator. Може да се напише скрипт, който да прави условен kubectl apply и да следи, например, ConfigMap, където ще се съ храняват настройките. Примерно това е реализирано в addon-operator.

Как е организирано в addon-operator?

При създаването на ново решение, се ръководехме от следните принципи:

• Инсталаторът на разширения трябва да поддържа шаблонизация и декларативна конфигурация. Не правим магически скриптове, които инсталират разширения. Addon-операторът използва Helm за инсталиране на разширения. За инсталирането е необходимо да се създаде чарт и да се определят values, които ще се използват за конфигуриране.
• Настройките могат да се генерират при инсталирането, те могат да се получават от кластера, или да получават актуализации, следейки ресурсите на кластера. Тези операции могат да се реализират с помощта на хукове.
• Настройките могат да се да се съхраняват в кластера. За съхранение на настройките в кластера се създава ConfigMap/addon-оператор и Addon-операторът следи за промените в този ConfigMap. Addon-операторът дава на хуковете достъп до настройките с помощта на прости споразумения.
• Разширението зависи от настройките. Ако настройките се променят, Addon-операторът разгръща Helm-чарт с новите values. Обединението на Helm-чарт, values за него и хуковете нарекохме модул (повече информация по-долу).
• Стадият. Няма магически скриптове за релиз. Механизмът за актуализации е подобен на обикновено приложение — събиране на разширения и addon-оператора в образ, тагване и разгръщане.
• Контрол на резултата. Addon-операторът може да предоставя метрики за Prometheus.

Какво представлява разширението в addon-оператора?

Разширението може да се разглежда като всичко, което добавя нови функции в кластера. Например, инсталирането на Ingress е отличен пример за разширение. Това може да бъде всеки оператор или контролер със собствен CRD: prometheus-оператор, cert-manager, kube-controller-manager и др. Или нещо малко, но опростяващо експлоатацията — например, secret copier, който копира секрета на регистъра в нови пространства от имена, или sysctl tuner, настроиващ параметрите на sysctl на новите възли.

За реализиране на разширения Addon-операторът предоставя няколко концепции:

• Helm-чарт се използва за инсталиране на различен софтуер в клъстера — например, Prometheus, Grafana, nginx-ingress. Ако нужният компонент има Helm-чарт, инсталирането му с помощта на Addon-оператора ще бъде много просто.
• Склад на values. Helm-чартовете обикновено имат много различни настройки, които могат да се променят с времето. Addon-операторът поддържа съхранението на тези настройки и може да следи за техните промени, за да преинсталира Helm-чарта с новите стойности.
• Хукове — това са изпълними файлове, които Addon-operator стартира при събития и които имат достъп до хранилището values. Хукът може да следи промените в клъстера и да актуализира стойностите в хранилището values. Тоест, с помощта на хук можете да направите discovery, за да събирате стойности от клъстера при стартирането или по график, а също и continuous discovery, събирайки стойности от клъстера при промените в него.
• Модул — това е обединение на Helm-чарта, хранилището values и хукове. Модулите могат да бъдат включвани и изключвани. Изключването на модул е премахване на всички релизи на Helm-чарта. Модулите могат динамично да се включват сами, например, ако са включени всички необходими им модули или ако discovery в хуковете е намерил нужните параметри — това става чрез помощния enabled-скрипт.
• Глобални хукове. Това са „самостоятелни“ хукове, те не са включени в модулите и имат достъп до глобалното хранилище values, стойностите от което са достъпни за всички хукове в модулите.

Как работят тези части заедно? Нека разгледаме изображението от документацията:

Има два сценария на работа:

1. Глобалният хук се стартира при събитие — например, при промяна на ресурса в клъстера. Този хук обработва промените и записва новите стойности в глобалното хранилище values. Addon-operator забелязва, че глобалното хранилище е променено и стартира всички модули. Всеки модул с помощта на своите хукове определя дали да се включи и актуализира своето хранилище values. Ако модулът е включен, Addon-operator стартира инсталацията на Helm-чарта. На Helm-чарта са достъпни стойностите от хранилището на модула и от глобалното хранилище.
2. Вторият сценарий е по-прост: модулният хук се стартира при събитие, променя стойностите в хранилището values на модула. Addon-operator забелязва това и стартира Helm-чарта с актуализираните стойности.

Допълнението може да бъде реализирано под формата на един единствен хук или като един Helm-чарт, или дори като няколко зависими модули — това зависи от сложността на инсталирания в клъстера компонент и от необходимото ниво на гъвкавост на настройките. Например, в репозиторията (/examples) има допълнение sysctl-tuner, което е реализирано както в проста форма с хук и Helm-чарт, така и с използването на хранилището values, което дава възможност за добавяне на настройки чрез редактиране на ConfigMap.

Доставка на обновления

Няколко думи за организацията на обновленията на компонентите, които инсталира Addon-операторът.

За да стартирате Addon-оператора в клъстера, трябва да съберете образ с добавки под формата на хук файлове и Helm графики, да добавите бинарен файл addon-operator и всичко, което е необходимо за хук: bash, kubectl, jq, python и т.н. След това този образ може да се разпространява в клъстера като обикновено приложение и вероятно ще искате да организирате някаква схема за означаване. Ако клъстерите не са много, може да е подходящ същия подход, както с приложенията: нова версия, нова версия, да преминете през всички клъстери и да промените image на Pod-овете. Въпреки това, в случай на разпространение на значителен брой клъстери, концепцията за самообновление от канала се оказа по-приложима.

При нас това е организирано по следния начин:

• Каналът всъщност е идентификатор, който може да бъде зададен произвольно (например, dev/stage/ea/stable).
• Името на канала е означението на образа. Когато е необходимо да се разпространят обновления в канала, се събира нов образ и се означава с името на канала.
• Когато в регистрационния офис се появи нов образ, Addon-операторът се рестартира и стартира с новия образ.

Това не е добра практика, за което се пише в документацията на Kubernetes. Не се препоръчва да се прави така, но става дума за обикновено приложение, което живее в един клъстер. В случай на Addon-оператора приложението е множество Deployments, разпределени по клъстери, а самообновлението значително помага и опростява живота.

Каналите помагат и в тестването: ако има помощен клъстер, може да го настроите на каналаstage и да разпространявате обновления в него преди разпространението в каналите ea stable и . Ако се е появила грешка с клъстера на канала, може да го превключите на, докато протича разследването на проблема с този клъстер. Ако клъстерът е изведен от активна поддръжка, той се превключва на своя „замразен“ канал — например, stable freeze-2019-03-20 . Ако се е появила грешка с клъстера на канала, може да го превключите наОсвен обновленията на хук файловете и Helm графиките, може да се наложи да обновите и трети компонент.

. Например, забелязали сте грешка в условния node-exporter и дори сте измислили как да го поправите. След това сте отворили PR и чакате ново издание, за да минете през всички клъстери и да увеличите версията на образа. За да не чакате неопределено време, можете да съберете своя node-exporter и да се превключите на него до приемането на PR. ..

Всъщност, това може да стане и без Addon-operator, но с Addon-operator модулът за инсталиране на node-exporter ще бъде на видимо място в един репозиторий, Dockerfile за изграждане на собствен образ може да се държи точно тук, а на участниците в процеса става по-лесно да разберат какво се случва… А ако има няколко клъстера, става по-лесно както да се тества своя PR, така и да се инсталира нова версия!

Цялата ни система за актуализиране на компонентите работи успешно, но може да се реализира и всяка друга подходяща схема — все пак в този случай Addon-operator е прост бинарен файл..

Заключение

Принципите, реализирани в Addon-operator, позволяват изграждането на прозрачен процес за създаване, тестване, инсталиране и актуализиране на добавки в клъстера, подобен на процесите на разработка на обикновени приложения.

Добавките за Addon-operator във формат модули (Helm-чарт + хукове) могат да бъдат публикувани за широко ползване. Ние, компанията Флант, планираме да публикуваме нашите разработки под формата на такива добавки през лятото. Присъединете се към разработката в GitHub (shell-operator, addon-operator), опитайте да създадете своя добавка на базата на примерите и документацията, очаквайте новини на Хабре и на нашия канал в YouTube!

P.S.

Прочетете също в нашия блог:

• «Разширяваме и допълваме Kubernetes (преглед и видео на доклада)»;
• «Представяме shell-operator: създаването на оператори за Kubernetes стана още по-лесно».

Източник: habr.com