- PVSM.RU - https://www.pvsm.ru -
Open Source-проект shell-operator [1] был создан с целью упростить создание полноценных Kubernetes-операторов и представлен [2] нами два года назад. За минувшее время он прошёл длинный путь, оброс интересными функциями и, как мы уже недавно писали [3], созрел для использования в production*.
Несмотря на это, его версия, долгое время «блуждавшая» в диапазоне бета- и RC-релизов будущей v1.0.0, вносила смуту для сторонних наблюдателей (и пользователей). С этим финальным релизом shell-operator мы ликвидируем это недоразумение, ещё более официально объявляя о зрелости проекта, а заодно — принеся в него новые возможности.
* И даже более того: он (а точнее — его «старший брат», addon-operator [4]) является одним из кирпичиков для нашей внутренней Kubernetes-платформы Deckhouse [5], которая станет доступной публично уже в мае.
Для знакомства с тем, как устроен shell-operator и как с ним работать, рекомендуем доклад на KubeCon EU’2020 [6], а эта статья сфокусирована только на последних новшествах (с момента нашей январской публикации [3]).
Релиз v1.0.0 [7] не стал формальным событием для проекта shell-operator. Он также принёс весьма значимые обновления, которыми уже сегодня можно воспользоваться.
Мы пишем много хуков для shell-operator (и addon-operator) и давно столкнулись с тем, что побочные эффекты в хуках усложняют тестирование и мешают восприятию логики работы хука.
Чтобы получить хуки без побочных эффектов — «чистые хуки», которые взаимодействуют только с shell-operator, — мы начали с устранения вызовов kubectl
.
Для замены «читающим» вызовам kubectl
в shell-operator появились настройки includeSnapshotsFrom
и group
, а результат работы выражения jqFilter
доступен в объектах в binding context — таким образом можно получать нужные объекты из кластера через файл и использовать их в работе хука. Эти возможности были добавлены в версию beta.6 [8] и уже с тех пор мы пишем хуки без «читающих» вызовов kubectl
.
Вторую часть — замену «пишущим» вызовам kubectl
— мы реализовали как внутреннюю библиотеку и пожили с ней какое-то время. И вот в версии v1.0.0 появился так называемый Object Patcher Framework. Он представляет возможность вернуть из хука декларативный набор действий над объектами в кластере.
Как это работает? Допустим, хук создаёт сертификат и помещает его в секрет. Это можно сделать таким вызовом kubectl
:
cat <<EOF | kubectl -n default apply -f -
apiVersion: v1
kind: Secret
metadata:
name: certs
type: kubernetes.io/tls
data:
tls.crt: |
${CERT}
tls.key: |
${KEY}
EOF
Вроде не сложно, однако:
хорошо бы проверить, что такого секрета не существует, а если существует, то обновить его ключи;
написать тест для такого хука сложно, т.к. нужен кластер и проверка состояния кластера после работы хука. Либо нужно подменить kubectl на что-то управляемое из тестов.
Как эти задачи решает Object Patcher Framework? Согласно документации [9], чтобы заменить такой вызов kubectl
, нужно записать в файл $KUBERNETES_PATCH_PATH
действие с операцией CreateOrUpdate
:
cat <<EOF > $KUBERNETES_PATCH_PATH
---
operation: CreateOrUpdate
object:
apiVersion: v1
kind: Secret
metadata:
name: certs
namespace: default
type: kubernetes.io/tls
data:
tls.crt: |
${CERT}
tls.key: |
${KEY}
EOF
Теперь shell-operator попытается создать секрет, а если секрет уже существует, то обновит его. И тестировать хук стало проще: в тесте достаточно проверить содержимое файла $KUBERNETES_PATCH_PATH
.
Подытоживая это краткое описание Object Patcher Framework, можно сказать, что начиная с shell-operator v1.0.0 хуки можно разрабатывать без вызовов kubectl
(и даже убрать этот файл из образа!).
А если вы любите jq так же, как и мы, то вам точно понравится операция JQPatch [10].
У хуков появились настройки, позволяющие замедлять их запуск, чтобы «накопить» события в очереди. Это нужно в тех случаях, когда хук умеет обрабатывать актуальное состояние набора объектов за один вызов, а запускать его на каждое изменение накладно. Если изменения приходят слишком часто, то очередь забивается и одно из решений — ограничить частоту запуска такого хука.
Пример конфигурации:
cat <<EOF
configVersion: v1
settings:
executionMinInterval: 5s
executionBurst: 2
kubernetes:
- name: pods
kind: Pod
group: pods
EOF
Такой хук будет запускаться раз в 5 секунд, позволяя хуку выполняться два раза без задержек. Обратите внимание, что в подписке указана group
: с этим параметром в хук будет передан один binding context с актуальными объектами. Без group
в хук попадёт массив binding context’ов с промежуточными изменениями за 5 секунд и ускорить хук не получится. Подробнее о group
можно прочитать в документации [11].
shell-operator при старте начинает следить за изменениями в Kubernetes-объектах и запускает хук, передавая ему список существующих объектов на момент запуска. Мы назвали такой первый запуск Synchronization. Если во время работы хука случается ошибка, то он перезапускается, а в случае Synchronization происходила ошибка: хук на каждый такой перезапуск получал всё тот же набор объектов, что был при первом запуске, несмотря на изменения в кластере.
для Object Patcher Framework создаётся отдельный Kubernetes client и для него можно настроить таймаут и замедление (--object-patcher-kube-client-timeout
, --object-patcher-kube-client-qps
, --object-patcher-kube-client-burst
);
актуализирована документация про group
;
добавлен флаг для включения отладочной информации от Kubernetes client.
Мы видим, что конфигурация хуков в shell-operator усложнилась, появилось много дополнительных рычагов и крутилок: executeHookOnEvent
и executeHookOnSynchronization
, includeSnapshotsFrom
и group
, keepFullObjectsInMemory
, queue
(и его отсутствие), а ещё есть waitForSynchronization
… И эти настройки не нужны по отдельности, а только определённые наборы их значений, чтобы установить нужный режим подписки.
Поэтому мы создали milestone v2 [12] в addon-operator и приглашаем вас дать обратную связь о сложностях в работе (и с shell-operator, и с addon-operator) — можно здесь в комментариях, а можно через issue на GitHub [1] или через Telegram-чат [13].
Читайте также в нашем блоге:
«Go? Bash! Встречайте shell-operator (обзор и видео доклада с KubeCon EU'2020) [6]»;
«Прогресс shell-operator и addon-operator: хуки как admission webhooks, Helm 3, OpenAPI, хуки на Go и многое другое [3]» (январь 2021);
«Простое создание Kubernetes-операторов с shell-operator: прогресс проекта за год [14]» (июль 2020);
«Представляем shell-operator: создавать операторы для Kubernetes стало ещё проще [2]» (апрель 2019).
Автор: Иван Михейкин
Источник [15]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/open-source/363221
Ссылки в тексте:
[1] shell-operator: https://github.com/flant/shell-operator
[2] представлен: https://habr.com/ru/company/flant/blog/447442/
[3] писали: https://habr.com/ru/company/flant/blog/537794/
[4] addon-operator: https://github.com/flant/addon-operator
[5] Deckhouse: https://deckhouse.io/
[6] доклад на KubeCon EU’2020: https://habr.com/ru/company/flant/blog/519208/
[7] Релиз v1.0.0: https://github.com/flant/shell-operator/releases/tag/v1.0.0
[8] beta.6: https://github.com/flant/shell-operator/releases/tag/v1.0.0-beta.6
[9] документации: https://github.com/flant/shell-operator/blob/master/KUBERNETES.md
[10] JQPatch: https://github.com/flant/shell-operator/blob/master/KUBERNETES.md#jqpatch
[11] документации: https://github.com/flant/shell-operator/blob/master/HOOKS.md#binding-context-of-grouped-bindings
[12] milestone v2: https://github.com/flant/addon-operator/milestone/9
[13] Telegram-чат: https://t.me/kubeoperator
[14] Простое создание Kubernetes-операторов с shell-operator: прогресс проекта за год: https://habr.com/ru/company/flant/blog/509896/
[15] Источник: https://habr.com/ru/post/551456/?utm_source=habrahabr&utm_medium=rss&utm_campaign=551456
Нажмите здесь для печати.