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

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

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

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

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

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

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

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

Хуки:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо за интерес к shell-operator! Задавайте вопросы, если они у вас появились.

P.S.

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