Комментарии 7
Давно посматриваю в сторону операторов сам. Новый подвод посмотреть в их сторону.
Какие плюсы и минусы для себя определили при работе с операторами?
Привет! Основной минус, то, что не смотря на инициативы вроде Operator SDK и kubebuilder, разработка операторов, это все еще сложно. Документация фрагментарная, часто приходиться просто читать исходники того же client-go. Каких-то устоявшихся best practices тоже нет, приходится эксперементировать.
Из плюсов, собственно то, что оператор — first class citizen для kubernetes кластера) Если, для задачи, нужно получать события от apiserver'а, апдейтить ресурсы, etc, кажется, что это единственный "безкостыльный" способ делать это.
P.S. интересный анонс от Флант'а — shell-operator — это уже готовый оператор, который позволяет подписываться на k8s события, и по ним запускать bash скрипты. Имхо, очень интересная альтернатива написанию собственного оператора, для реализации простых сценариев.
А можно парочку примеров про обработку/получение событий от apiserver'а?
В контексте статьи, monitor_controller
подписывается на события по созданию/обновлению ресурса MonitoredService
. Первый аргумент source
, является оберткой над Informer
'ом — собственно, объект который периодически опрашивает apiserver
об изменениях, связанных с отслеживаемым ресурсом и создает событие для контроллера. Еще один аргумент, predicate, уже фильтрует события, которые получает Reconciler
.
Привет. Вроде, использовать vendor/
для зависимостей, является практически стандартом для go
проектов.
Касательно сборки приложений, у operator-sdk
, мне кажется другие минусы. Во-первых, по умолчанию он привязан к dep
, для управления зависимостями. У dep
есть сложности с управлением зависимостями, которые лежат в приватных репозиториях, поэтому, во всех go
проектах мы используем glide
. Он с ними работает хорошо;) Наш оператор тоже использует зависимости из приватного репозитория, поэтому пришлось повозиться, чтобы перевести его на glide
.
Во-вторых, по сути, зависимости разбросаны по двум местам, в vendor/
(зависимости самого оператора) и в GOPATH
(зависимости operator-sdk
). Это ок, если сборку оператора делать локально, через operator-sdk build
. Но, например, если использовать самописный Dockerfile
с многоэтапной сборкой, приходится вручную искать и добавлять зависимости для оператора.
Разработка Kubernetes оператора с Operator Framework