Простое создание Kubernetes-операторов с shell-operator: прогресс проекта за год

Kubernetes-операторы — удобный механизм для расширения возможностей этой контейнерной платформы, по праву снискавший широкое признание в среде инженеров эксплуатации и им сочувствующих. О том, как они устроены и работают, мы рассказывали ^[1] в уже далёком 2017-м. А в апреле прошлого года мы представили ^[2] Open Source-проект shell-operator ^[3], который значительно упростил процесс создания Kubernetes-операторов.

Для этого был разработан фреймворк, позволяющий запускать произвольные скрипты (на Bash, Python и т.п.) в случае наступления определённых событий в K8s-кластере.

За минувшее время shell-operator обрёл свою пользовательскую базу (см. подробности в конце статьи) и, конечно, новые возможности. По случаю недавнего релиза v1.0.0-beta.11 ^[4] (о бета-статусе см. дальше) мы решили рассказать о том, к чему проект пришёл за время своего существования, с момента анонса первой публичной версии.

Об устройстве и назначении

Но начнем с краткого пояснения, как работает shell-operator и для чего в принципе он может понадобиться.

Shell-operator запускается в pod’е Kubernetes-кластера. Он представлен там как:

• Go-бинарник, который подписывается на события в K8s API и запускает хуки (передавая им подробности о случившемся);
• набор хуков, каждый из которых — скрипт на Bash, Python или любой другой исполняемый файл.

Хуки:

• сами определяют, какие события и для каких объектов им нужны;
• выполняют необходимые действия в случае наступления этих событий в K8s.

Таким образом, shell-operator — это прослойка между событиями в Kubernetes API и скриптами для их обработки.

Зачем вообще был создан shell-operator? Операторы — это стандарт для «правильной автоматизации» в рамках Kubernetes, однако их полноценная разработка (на Go с привлечением соответствующего SDK ^[5]) не так проста. Наличие такого простого фреймворка, как shell-operator, значительно снижает порог вхождения в эту область, позволяя быстро и эффективно решать небольшие эксплуатационные задачи* внутри кластера. И, что не менее важно, делать это правильным путём.

О каких задачах идёт речь? Готовые примеры использования shell-operator можно найти в репозитории проекта ^[6]. У нас же, в компании «Флант», мы его применяем как библиотеку (да, так тоже можно было!). Он стал основой для addon-operator ^[7], управляющего дополнительными компонентами в Kubernetes.

NB: Анонс этого Open Source-проекта (addon-operator) можно найти здесь ^[8]. А в докладе «Расширяем и дополняем Kubernetes ^[9]» мы подробно рассказывали о причинах его появления, взаимосвязи с shell-operator и принципах функционирования.

Теперь — о главных изменениях, представленных в shell-operator за последний год.

Основные новшества

В первых версиях shell-operator для хука был доступен только один объект — тот, который связан с событием от кластера. Развитие хуков, используемых в рамках addon-operator, привело к тому, что хук подписывался на изменение объекта, но вызывал kubectl чтобы получить актуальный список других объектов. Чтобы убрать лишние вызовы kubectl и тем самым ускорить работу хуков, реализовано несколько возможностей получить доступ к актуальным спискам объектов:

• Режим Synchronization ^[10] + Event, когда хук при старте получает список актуальных объектов, а затем работает только с одним объектом. Этот режим включен по умолчанию — можно сказать, что получился аналог reconcile loop ^[11] из operator-sdk.
• Режим с получением snapshot'ов ^[12], когда хук получает полные актуальные списки объектов при каждом запуске. (Snapshot’ы используются для кэширования объектов Kubernetes, используемых в хуках.)
• Режим получения группы snapshot'ов ^[13]. Может использоваться в случаях, когда хук подписан на разные типы ресурсов, а реагировать на изменения нужно на основе актуальной информации о всех ресурсах независимо от того, что изменилось.
• Также появилась возможность следить за ресурсом, но не реагировать на его изменения, т.е. «накапливать snapshot». Например, хук может реагировать на изменения в CustomResource ^[14] и при этом получать актуальный объект ConfigMap без дополнительного вызова kubectl. (Для подробностей см. флаги executeHookOnSynchronization и executeHookOnEvent.)

Другие значительные нововведения:

• Благодаря переходу на использование динамического клиента ^[15] Kubernetes в shell-operator стало возможным подписываться на любой существующий kind (тип ресурса в Kubernetes API), в том числе и Custom Resources.
• Хуки можно запускать в разных очередях (см. параметр queue). В дальнейшем для диагностики состояния очередей хуков была добавлена команда и соответствующие endpoints ^[16].
• Добавлена возможность подписываться на несколько имён ресурсов.
• Появилась подписка с «динамическими пространствами имен», которая позволяет следить за ресурсами в namespace’ах с указанными лейблами.
• Хуки получили возможность экспортировать произвольные метрики ^[17] для их дальнейшего scraping'а Prometheus'ом. Можно указать отдельный порт ^[18] для этих метрик.
• Добавлен специальный фреймворк ^[19], который упрощает написание хуков на shell.

Менее значимые изменения

• Хук может возвращать конфигурацию в YAML-формате (в дополнение к JSON).
• Добавлено ^[20] логирование в формате JSON на базе logrus ^[21] (см. LOG_TYPE в переменных окружения ^[22]).
• Добавлена настройка listen-address для возможности запуска в режиме hostNetwork: true.
• Появились настройки rate limit (qps, burst) для клиента Kubernetes API.
• Представлен флаг kube-server для указания адреса сервера Kubernetes API.
• Убраны различные блокировки для ускорения параллельной работы хуков.
• Выражения jqFilter теперь выполняются с помощью библиотеки libjq-go ^[23], не требуя запуска отдельного процесса jq.
• Удалён ^[24] zombie reaper, обрабатывающий сигнал SIGCHLD и устраняющий процессы-сироты, которые могут порождаться Bash-скриптами. Вместо внутренней реализации теперь используется внешняя — tini ^[25].
• Реализованы разные упрощения для подключения shell-operator как библиотеки.
• Обновлена версия kubectl (с 1.13 до 1.17.4) и сделана сборка на основе alpine-3.11.

Статус и планы

Проект shell-operator всё ещё официально имеет статус бета-версии. Несмотря на это, как уже отмечалось выше, мы весьма интенсивно используем его как основу для addon-operator ^[7] — инструмента, который постоянно эксплуатируется во множестве (100+) K8s-кластеров.

Для стабильного релиза shell-operator как публичного проекта мы планируем (как минимум):

• добавить e2e-тестирование (#63 ^[26]),
• реализовать мульти-архитектурную сборку (#184 ^[27]),
• обновить client-go до 0.18.0, внедрить context и окончательно разобраться с кэшированием объектов в client-go (#188 ^[28]).

Признание сообществом

За прошедшее время мы увидели явный интерес сообщества к shell-operator:

• Проект упоминался не только в различных списках полезных утилит для Kubernetes (awesome-kubernetes ^[29], Cloud Zone ^[30]), но и на специализированных вебинарах (Weaveworks ^[31]), митапах (K8s Meetup Tokyo ^[32]) и даже в книге ^[33].
• Он нашёл свое практическое применение в реальных проектах (самый интересный из известных нам — это инсталлятор ^[34] для китайской K8s-платформы KubeSphere). На просторах GitHub можно найти множество простых операторов, реализованных на основе shell-operator (небольшую подборку из них мы приводили здесь ^[35]).
• У проекта появились сторонние контрибьюторы: их вклад пока не очень велик, но мы приветствуем всех желающих поучаствовать.
• На GitHub ^[3] собрано 600+ звёзд — конечно, будем рады и новым! ;-)

Спасибо за интерес к shell-operator! Если у вас появились вопросы — задавайте их здесь в комментариях или в tg-канале @kubeoperator ^[36].

P.S.

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

• «Представляем shell-operator: создавать операторы для Kubernetes стало ещё проще ^[2]»;
• «Готовить Kubernetes-кластер просто и удобно? Анонсируем addon-operator ^[8]»;
• «Расширяем и дополняем Kubernetes» (обзор и видео доклада) ^[9].

Автор: Иван Михейкин

Источник ^[37]