Comments 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