Слідом за ми представляємо його старшого брата . Це 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-оператор. Можна написати скрипт, який робитиме умовний kubectl apply і слідкувати, наприклад, за ConfigMap, де зберігатимуться налаштування. Приблизно це реалізовано в addon-operator.
Як це організовано в addon-operator?
Створюючи нове рішення, ми виходили з наступних принципів:
- Інсталятор додатків повинен підтримувати шаблонизацію та декларативну конфігурацію. Чи не робимо магічних скриптів, які встановлюють доповнення. Addon-operator використовує Helm для встановлення додатків. Для встановлення потрібно створити чарт та виділити values, які будуть використані для налаштування.
- Налаштування можна генерувати при встановленні, Їх можна отримати з кластера, або отримувати оновленняслідкуючи за ресурсами кластера. Ці операції можна реалізувати за допомогою хуків.
- Налаштування можна зберігати у кластері. Для збереження налаштувань у кластері створюється ConfigMap/addon-operator та Addon-operator стежить за змінами цього ConfigMap. Addon-operator дає хукам доступ до налаштувань за допомогою простих угод.
- Додаток залежить від налаштувань. Якщо налаштування змінилися, Addon-operator викочує Helm-чарт з новими values. Об'єднання Helm-чарта, 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-чарт, то встановити його за допомогою Addon-operator буде дуже просто.
- Сховище values. Helm-чарти зазвичай мають багато різних налаштувань, які можуть змінюватися з часом. Addon-operator підтримує зберігання цих налаштувань і вміє стежити за їх змінами, щоб перевстановити Helm-чарт із новими значеннями.
- Хукі — це файли, які Addon-operator запускає за подіями і які отримують доступ до сховища values. Хук може стежити за змінами у кластері та оновлювати значення у сховищі values. Тобто. за допомогою хуків можна зробити discovery, щоб збирати значення із кластера при старті або за розкладом, а можна і continuous discovery, збираючи значення із кластера за змінами у кластері.
- модуль - це об'єднання Helm-чарта, сховища values та хуків. Модулі можна вмикати та вимикати. Вимкнення модуля — видалення всіх релізів Helm-чарта. Модулі можуть включати себе динамічно, наприклад, якщо включені всі необхідні йому модулі або якщо discovery в хуках знайшов потрібні параметри - це робиться за допомогою допоміжного enabled-скрипта.
- Глобальні хуки. Це хуки «самі по собі», вони не включені в модулі і мають доступ до глобального сховища values, значення якого доступно всім хукам в модулях.
Як ці частини працюють разом? Розглянемо картинку з документації:
Сценарія роботи два:
- Глобальний хук запускається за подією, наприклад, при зміні ресурсу в кластері. Цей хук обробляє зміни та записує нові значення у глобальне сховище values. Addon-operator зауважує, що глобальне сховище змінилося і запускає всі модулі. Кожен модуль за допомогою своїх хуків визначає, чи потрібно йому вмикатись, і оновлює своє сховище values. Якщо модуль увімкнений, Addon-operator запускає установку Helm-чарта. Helm-чарту при цьому доступні values зі сховища модуля та глобального сховища.
- Другий сценарій простіше: модульний хук запускається за подією, змінює значення сховища values модуля. Addon-operator це помічає та запускає Helm-чарт з оновленими values.
Додаток може бути реалізований у вигляді одного єдиного хука або як один Helm-чарт, або навіть як кілька залежних модулів — це залежить від складності компонента, що встановлюється в кластер, і від потрібного рівня гнучкості налаштувань. Наприклад, у репозиторії () є доповнення sysctl-tuner, яке реалізовано як у вигляді простого модуля з хуком та Helm-чартом, так і з використанням сховища values, що дає можливість додавати налаштування через редагування ConfigMap.
Доставка оновлень
Декілька слів про організацію оновлень компонентів, які встановлює Addon-operator.
Щоб запустити Addon-operator у кластері, потрібно зібрати образ із доповненнями у вигляді файлів хуків та Helm-чартів, додати бінарний файл addon-operator і все, що знадобиться для хуків: bash, kubectl, jq, python і т.д. Далі цей образ можна викочувати в кластер як звичайний додаток і швидше за все ви захочете організувати ту чи іншу схему тегування. Якщо кластерів небагато, може підійти той самий підхід, що і з додатками: новий реліз, нова версія, піти всім кластерам і поправити image у Pod'ов. Однак, у разі викочування на відчутну кількість кластерів, нам більше підійшла концепція самооновлення з каналу.
У нас це влаштовано так:
- Канал – це, по суті, ідентифікатор, який можна задавати будь-яким (наприклад, dev/stage/ea/stable).
- Ім'я каналу це тег образу. Коли потрібно викотити оновлення до каналу, то збирається новий образ і тегується ім'ям каналу.
- Коли registry з'являється новий образ, Addon-operator рестартується і запускається з новим образом.
Це не best practice, про що написано в . Так робити не рекомендується, але йдеться про звичайний додаток, який живе в одному кластері. У випадку Addon-operator додаток - це безліч Deployments, розкиданих по кластерах, і самооновлення дуже допомагає і спрощує життя.
Канали допомагають і у тестуванні: якщо є допоміжний кластер, можна налаштувати його на канал stage і катати оновлення до нього перед викатом у канали ea и stable. Якщо з кластером на каналі ea сталася помилка, можна його переключити на 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 (, ), спробуйте зробити свій додаток на основі и , чекайте новин на Хабре та на нашому !
PS
Читайте також у нашому блозі:
- «»;
- «».
Джерело: habr.com