[DevOps, Kubernetes, Open source, Системное администрирование] Простое создание Kubernetes-операторов с shell-operator: прогресс проекта за год
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
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.
Читайте также в нашем блоге:
- «Представляем shell-operator: создавать операторы для Kubernetes стало ещё проще»;
- «Готовить Kubernetes-кластер просто и удобно? Анонсируем addon-operator»;
- «Расширяем и дополняем Kubernetes» (обзор и видео доклада).
===========
Источник:
habr.com
===========
Похожие новости:
- [DIY или Сделай сам, Open source, Разработка на Raspberry Pi, Электроника для начинающих] babooshka tv, как самодельный видео-показатор сместил «точку сборки» моих пожилых родителей
- [Open source, PHP, JavaScript] readable — еще один линтер для PHP
- [Open source, Системы обмена сообщениями, Управление проектами, Учебный процесс в IT] 5 опенсорсных альтернатив Slack для группового чата (перевод)
- [DevOps] Развитие сообщества Open DevOps Community. Тимур Гильмуллин. Александр Паздников
- [IT-стандарты, Конференции, DevOps] Как я не съездил в Лондон, но поучаствовал в London DevOps Enterprise Summit
- [Информационная безопасность, Сетевые технологии, Системное администрирование] Как проверить IPS? Infection Monkey vs Check Point
- [Отладка, Системное администрирование, Хостинг] HTTP Error 503. Service Unavailable: случай в поддержке хостинга
- [IT-инфраструктура, Open source, Виртуализация, Серверное администрирование, Сетевые технологии] Автоматизация сетевых сервисов или как собрать виртуальную лабораторию при помощи OpenDaylight, Postman и Vrnetlab
- [DevOps, Open source, Управление разработкой, Учебный процесс в IT] Руководство для начинающих: создаем DevOps-пайплайн (перевод)
- [IT-инфраструктура, Серверное администрирование, Системное администрирование, Хранение данных] Dell EMC PowerStore: коротко о нашей новейшей СХД корпоративного класса
Теги для поиска: #_devops, #_kubernetes, #_open_source, #_sistemnoe_administrirovanie (Системное администрирование), #_kubernetes, #_kubernetes_operator, #_open_source, #_flant (Флант), #_blog_kompanii_flant (
Блог компании Флант
), #_devops, #_kubernetes, #_open_source, #_sistemnoe_administrirovanie (
Системное администрирование
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:06
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
Kubernetes-операторы — удобный механизм для расширения возможностей этой контейнерной платформы, по праву снискавший широкое признание в среде инженеров эксплуатации и им сочувствующих. О том, как они устроены и работают, мы рассказывали в уже далёком 2017-м. А в апреле прошлого года мы представили Open Source-проект shell-operator, который значительно упростил процесс создания Kubernetes-операторов. Для этого был разработан фреймворк, позволяющий запускать произвольные скрипты (на Bash, Python и т.п.) в случае наступления определённых событий в K8s-кластере. За минувшее время shell-operator обрёл свою пользовательскую базу (см. подробности в конце статьи) и, конечно, новые возможности. По случаю недавнего релиза v1.0.0-beta.11 (о бета-статусе см. дальше) мы решили рассказать о том, к чему проект пришёл за время своего существования, с момента анонса первой публичной версии. Об устройстве и назначении Но начнем с краткого пояснения, как работает shell-operator и для чего в принципе он может понадобиться. Shell-operator запускается в pod’е Kubernetes-кластера. Он представлен там как:
Хуки:
Таким образом, 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 и тем самым ускорить работу хуков, реализовано несколько возможностей получить доступ к актуальным спискам объектов:
Другие значительные нововведения:
Менее значимые изменения
Статус и планы Проект shell-operator всё ещё официально имеет статус бета-версии. Несмотря на это, как уже отмечалось выше, мы весьма интенсивно используем его как основу для addon-operator — инструмента, который постоянно эксплуатируется во множестве (100+) K8s-кластеров. Для стабильного релиза shell-operator как публичного проекта мы планируем (как минимум):
Признание сообществом За прошедшее время мы увидели явный интерес сообщества к shell-operator:
Спасибо за интерес к shell-operator! Задавайте вопросы, если они у вас появились. P.S. Читайте также в нашем блоге:
=========== Источник: habr.com =========== Похожие новости:
Блог компании Флант ), #_devops, #_kubernetes, #_open_source, #_sistemnoe_administrirovanie ( Системное администрирование ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:06
Часовой пояс: UTC + 5