Готовить Kubernetes-кластер просто и удобно? Анонсируем addon-operator

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.


Вслед за shell-operator мы представляем его старшего брата — addon-operator. Это Open Source-проект, который используется для установки в кластер 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-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, значения из которого доступно всем хукам в модулях.

Как эти части работают вместе? Рассмотрим картинку из документации:



Сценария работы два:

  1. Глобальный хук запускается по событию — например, при изменении ресурса в кластере. Этот хук обрабатывает изменения и записывает новые значения в глобальное хранилище values. Addon-operator замечает, что глобальное хранилище изменилось и запускает все модули. Каждый модуль с помощью своих хуков определяет, нужно ли ему включаться, и обновляет своё хранилище values. Если модуль включен, то Addon-operator запускает установку Helm-чарта. Helm-чарту при этом доступны values из хранилища модуля и из глобального хранилища.
  2. Второй сценарий проще: модульный хук запускается по событию, изменяет значения в хранилище values модуля. Addon-operator это замечает и запускает Helm-чарт с обновлёнными values.

Дополнение может быть реализовано виде одного единственного хука или как один Helm-чарт, или даже как несколько зависимых модулей — это зависит от сложности устанавливаемого в кластер компонента и от нужного уровня гибкости настроек. Например, в репозитории (/examples) есть дополнение 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, о чем написано в документации Kubernetes. Так делать не рекомендуется, но речь идёт про обычное приложение, которое живёт в одном кластере. В случае Addon-operator приложение — это множество Deployments, разбросанных по кластерам, и самообновление очень сильно помогает и упрощает жизнь.

Каналы помогают и в тестировании: если есть вспомогательный кластер, можно настроить его на канал stage и катать обновления в него перед выкатом в каналы ea и stable. Если c кластером на канале 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 (shell-operator, addon-operator), пробуйте сделать своё дополнение на основе примеров и документации, ждите новостей на Хабре и на нашем канале в YouTube!

P.S.


Читайте также в нашем блоге:

  • «Расширяем и дополняем Kubernetes (обзор и видео доклада)»;
  • «Представляем shell-operator: создавать операторы для Kubernetes стало ещё проще».
Источник: https://habr.com/ru/company/flant/blog/455543/


Интересные статьи

Интересные статьи

ESD лицензия – это отличный выбор для быстрой покупки подлинного программного обеспечения: оплатили счёт – через пару часов получили заветный подлинный ключ. Но даже если вы покупаете её ...
Все рассказывают про процессы разработки и тестирования, обучения персонала, повышение мотивации, но этих процессов мало, когда минута простоя сервиса стоит космических денег. Что делать, когда в...
В процессе разработки электронных устройств под управлением микроконтроллеров, часто возникает задача передать какие-то данные с устройства на компьютер или наоборот. Вероятно самым простым спосо...
Cтатья будет полезна тем, кто думает какую выбрать CMS для интернет-магазина, сравнивает различные движки, ищет в них плюсы и минусы важные для себя.
Хабр, привет! Так получилось, что меня давно просили сделать старую настольную игру из СССР — «Сражение». Вот пришло время выполнять обещание, заодно решила показать как создавать макеты для ...