След представяме неговия по-голям брат — . Това е Open Source проект, който се използва за инсталиране в кластера Kubernetes на системни компоненти, които могат да бъдат обобщени с общото понятие — добавки.
Защо изобщо са нужни добавки?
Не е тайна, че Kubernetes не е готов продукт за всичко и за изграждане на "възрастен" клъстер ще са необходими различни добавки. Addon-operator ще помогне за инсталирането, настройването и поддържането на тези добавки в актуално състояние.
Необходимостта от допълнителни компоненти в клъстера е разгледана в колеги . Вкратце, ситуацията с Kubernetes в момента е такава, че за проста инсталация "да се поиграе" може да се разчита на компонентите от кутията, за разработчици и тестване може да се добави Ingress, но за пълна инсталация, за която може да се каже "вашият production е готов", е необходимо да се добавят поне десетина различни добавки: нещо за мониторинг, нещо за логове, да не се забрави ingress и cert-manager, да се определят групи от възли, да се добавят мрежови политики, да се добавят настройки за sysctl и pod autoscaler...
Каква е спецификата на работата с тях?
Както показва опитът, само инсталирането не е достатъчно. За комфортна работа с клъстера добавките трябва да бъдат обновявани, деактивирани (премахвани от клъстера) и нещо може да искате да тествате преди инсталиране в production клъстера.
Така че, може би, и Ansible ще е достатъчен? Възможно е. Но пълноценните добавки обикновено не съществуват без настройки.Тези настройки могат да варират в зависимост от вида на клъстера (aws, gce, azure, bare-metal, do и т.н.). Някои настройки не могат да бъдат зададени предварително — те трябва да се получават от клъстера. А клъстерът не е статичен: за някои настройки ще трябва да се следят промените. И тук вече Ansible не е достатъчен: необходима е програма, която живее в клъстера, т.е. Kubernetes Operator.
Тези, които са опитали в работа , ще кажат, че задачите за инсталиране и обновление на добавките и следенето на настройките могат да бъдат решени с помощта на за shell-operator. Може да се напише скрипт, който да извършва условен kubectl apply и да следи, например, за ConfigMap, където ще се съхраняват настройките. Приблизително това е реализирано в addon-operator.
Как е организирано в addon-operator?
Създавайки ново решение, се ръководихме от следните принципи:
- Инсталаторът на добавки трябва да поддържа шаблонизация и декларативна конфигурация.. Не използваме магически скриптове за инсталиране на добавки. Addon-operator използва Helm за инсталиране на добавки. За инсталиране е необходимо да се създаде chart и да се зададат values, които ще се използват за конфигурация.
- Настройките могат да се генерират при инсталация, те могат да се получат от клъстера, или да получават актуализации, следейки ресурсите на клъстера. Тези операции могат да се реализират с помощта на хукове.
- Настройките могат да се съхраняват в клъстера. За съхраняване на настройките в клъстера се създава ConfigMap/addon-operator и Addon-operator следи за промените в този ConfigMap. Addon-operator предоставя на хуковете достъп до настройките чрез простите споразумения.
- Добавката зависи от настройките. Ако настройките са се променили, Addon-operator пуска Helm chart с нови values. Обединението на Helm chart, values за него и хуковете нарекохме модул (повече информация по-долу).
- Сцената. Няма магически релиз-скриптове. Механизмът за актуализация е аналогичен на обикновено приложение — да се съберат добавките и addon-operator в образ, да се тагне и да се пусне.
- Контрол на резултата. Addon-operator умее да предоставя метрики за Prometheus.
Какво представлява добавката в addon-operator?
Добавката може да се счита за всичко, което добавя нови функции в клъстера. Например, инсталирането на Ingress — отличен пример за добавка. Това може да бъде всякакъв оператор или контролер с неговия CRD: prometheus-operator, cert-manager, kube-controller-manager и т.н. Или нещо малко, но улесняващо експлоатацията — например, secret copier, който копира registry-секрети в нови пространства имена, или sysctl tuner, който настройва параметрите sysctl на новите възли.
За реализиране на добавки Addon-operator предоставя няколко концепции:
- Helm-чарт използва се, за да инсталира различен софтуер в клъстера — например, Prometheus, Grafana, nginx-ingress. Ако желаният компонент разполага с Helm chart, то инсталирането му с помощта на Addon-operator ще бъде много просто.
- Хранилище на values. Helm chart-овете обикновено имат много различни настройки, които могат да се променят с времето. Addon-operator поддържа съхранение на тези настройки и умее да следи за промените, за да преинсталира Helm chart с нови стойности.
- Хукове — това са изпълними файлове, които Addon-оператора стартира при събития и които получават достъп до хранилището values. Хукът може да следи промените в кластера и да обновява стойностите в хранилището values. Тоест, с помощта на хукове може да се направи discovery, за да се събират стойности от кластера при стартиране или по график, или може да се извърши continuous discovery, събирайки стойности от кластера по изменения в него.
- Модулът — това е обединение на Helm-чарт, хранилище values и хукове. Модулите могат да се включват и изключват. Изключването на модул е премахване на всички релизи на Helm-чарта. Модулите могат динамично да включват сами себе си, например, ако всички необходими модули са включени или ако discovery в хуковете е намерил нужните параметри — това се прави с помощта на спомагателен enabled-скрипт.
- Глобални хукове. Това са хукове „сами по себе си“, те не са включени в модулите и имат достъп до глобалното хранилище values, стойностите от което са достъпни за всички хукове в модулите.
Как работят заедно тези части? Нека разгледаме картинката от документацията:
Има два сценария на работа:
- Глобалният хук се стартира при събитие — например, при промяна на ресурса в кластера. Този хук обработва промените и записва новите стойности в глобалното хранилище values. Addon-оператора забелязва, че глобалното хранилище е променено и стартира всички модули. Всеки модул с помощта на своите хукове определя дали да се включи и обновява своето хранилище values. Ако модулът е включен, Addon-оператора стартира инсталацията на Helm-чарт. Helm-чартът има достъп до стойностите от хранилището на модула и от глобалното хранилище.
- Вторият сценарий е по-прост: модулният хук се стартира при събитие и променя стойностите в хранилището values на модула. Addon-оператора това забелязва и стартира Helm-чарта с обновените стойности.
Допълнението може да бъде реализирано под формата на един единствен хук или като един Helm-чарт, или дори като няколко зависими модули — това зависи от сложността на компонента, който се инсталира в кластера, и от необходимото ниво на гъвкавост на настройките. Например, в репозитория () има допълнение sysctl-tuner, което е реализирано както под формата на прост модул с хук и Helm-чарт, така и с използването на хранилище values, което създава възможност за добавяне на настройки чрез редактиране на ConfigMap.
Доставка на актуализации
Няколко думи за организацията на обновленията на компонентите, инсталирани от Addon-оператора.
За да стартирате Addon-оператора в клъстера, трябва да съберете образ с добавки под формата на файлове с хукове и Helm-чартове, да добавите бинарния файл addon-operator и всичко необходимо за хуковете: bash, kubectl, jq, python и т.н. След това този образ може да се внедри в клъстера като обикновено приложение и вероятно ще искате да организирате някаква схема на тагиране. Ако клъстерите не са много, може да е подходящ същият подход, както с приложенията: нова версия, ново издание, да преминете през всички клъстери и да поправите image на Pod-овете. Обаче, при внедряване на значителен брой клъстери, концепцията за самообновление от канала е по-подходяща.
При нас това е организирано така:
- Каналът е по същество идентификатор, който може да се задава произволно (например, dev/stage/ea/stable).
- Името на канала е таг на образа. Когато трябва да внедрите обновления в канала, се събира нов образ и се тагира с името на канала.
- Когато в хранилището се появи нов образ, Addon-операторът се рестартира и се стартира с новия образ.
Това не е най-добра практика, за което е написано в . Не се препоръчва да се прави така, но става въпрос за обикновено приложение, което съществува в един клъстер. В случая с Addon-оператора, приложението е множество Deployments, разпръснати из клъстери, и самообновлението много помага и опростява живота.
Каналите помагат и при тестването: ако имате помощен клъстер, можете да го настроите на канала stage и да внедрявате обновления в него преди да влезете в каналите ea и stable. Ако с клъстера на канала ea се е случила грешка, можете да го превключите на stable, докато се разследва проблемът с този клъстер. Ако клъстерът бъде изключен от активна поддръжка, той се превключва на своя "замръзнал" канал — например, freeze-2019-03-20.
В допълнение към обновленията на хукове и Helm-чартове, може да е необходимо да обновите и външен компонент. Например, забелязали сте грешка в условен node-exporter и дори сте измислили как да я патчнете. После сте отворили PR и чакате ново издание, за да обиколите всички клъстери и да увеличите версията на образа. За да не чакате неопределено време, можете да съберете своя node-exporter и да преминете на него до приемането на PR.
В общем, можно обойтись и без Addon-operator, но с ним модуль для установки node-exporter будет в одном репозитории. Dockerfile для сборки собственного образа можно хранить тут же, всем участникам процесса становится проще понимать, что происходит… А если кластеров несколько, то тестировать свой PR и внедрять новую версию становится легче!
Эта система обновления компонентов успешно работает у нас, но можно реализовать и любую другую подходящую схему — ведь в данном случае Addon-operator является простым бинарным файлом..
Заключение
Принципы, реализованные в Addon-operator, позволяют создать прозрачный процесс разработки, тестирования, установки и обновления дополнений в кластере, аналогичный тому, что применяется в разработке обычных приложений.
Дополнения для Addon-operator в формате модулей (Helm-чарт + хуки) можно будет выложить в открытый доступ. Мы, компания Флант, планируем опубликовать наши разработки в виде таких дополнений в течение лета. Присоединяйтесь к разработке на GitHub (, ), попробуйте создать своё дополнение на основе и , ждите новостей на Хабре и на нашем !
P.S.
Прочетете също в нашия блог:
- «»;
- «».
Източник: habr.com
