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