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.

В operator-sdk не понравилось то, что он тащит локально много зависимостей и кладет их в проект в vendor/ в т.ч. и client-go. Это не красиво, но судя по всему ему нужны определенные версии. Проблемы начинаются тогда, когда захочется использовать типы своего кастомного ресурса в другом приложении, т.к. в последнем будет использоваться «родной» client-go, который лежит в /GO_HOME/src/. В этом случае с точки зрения другого приложения эти типы не будут имплементировать runtime.Object.

Привет. Вроде, использовать vendor/ для зависимостей, является практически стандартом для go проектов.


Касательно сборки приложений, у operator-sdk, мне кажется другие минусы. Во-первых, по умолчанию он привязан к dep, для управления зависимостями. У dep есть сложности с управлением зависимостями, которые лежат в приватных репозиториях, поэтому, во всех go проектах мы используем glide. Он с ними работает хорошо;) Наш оператор тоже использует зависимости из приватного репозитория, поэтому пришлось повозиться, чтобы перевести его на glide.


Во-вторых, по сути, зависимости разбросаны по двум местам, в vendor/(зависимости самого оператора) и в GOPATH(зависимости operator-sdk). Это ок, если сборку оператора делать локально, через operator-sdk build. Но, например, если использовать самописный Dockerfile с многоэтапной сборкой, приходится вручную искать и добавлять зависимости для оператора.

У dep есть сложности с управлением зависимостями, которые лежат в приватных репозиториях

А какие там сложности?
Используем, не наблюдаем. Поделись, может не знаем чего.
Only those users with full accounts are able to leave comments. Log in, please.