LINUX.ORG.RU

Helm vs Operator

 , ,


0

3

При упаковке приложения в helm chart неизменно возникает вопрос: а не слишком ли глубоко в эту кроличью нору я залез и точно ли это кроличья нора, потому что запашок вокруг подсказывает что-то другое.

Как часто у вас возникает вопрос, что эту галиматью из ямлей надо выкинуть и заменить на тестируемый код на голанге?

Где проводите границу между «это дадим настраивать другому человеку» и «тут лучше сделать всё понадежнее и тестами покрыть»

Первое, helm-unittest в помощь.

Второе, в каком виде они вообще пересекаются? Helm chart служит для поставки и статичного создания ресурсов. K8S operator — для динамичного управления если вдруг условия работы поменялись, например сказать процессу перечитать конфиг при изменении ConfigMap или Secrets. Это вообще разные вещи, для разных задач.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

совершенно не соглашусь про разные вещи.

Они пересекаются, особенно там, где надо какие-то реакции добавлять.

Существует довольно четкий процесс, когда разросшийся хельм чарт пора перетаскивать в оператор, хранящий где-то состояние.

max_lapshin ★★★★★
() автор топика
Ответ на: комментарий от max_lapshin

Если есть какое-то динамическое поведение, создание и управление k8s (и не только) ресурсами, то вам нужен оператор. Однако оператор (и ресурсы для него) нужно в кластер как-то установить. И для этого нужен helm chart.

Короче, chart подходит для всего, что работает в режиме «запустил и забыл». operator — «запустил и приглядываю».

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

с одной стороны - да.

С другой стороны есть вопрос в сложности. Когда она увеличивается, есть стойкое ощущение, что нужен уже оператор вместо 20 ямлей

max_lapshin ★★★★★
() автор топика
Ответ на: комментарий от max_lapshin

Вы что-то делаете не то. У меня у самого много претензий к helm’у, но оператор решение иного класса. Да и 20 yamlей это не так уж и много.

Возможно вам зайдёт cdk8s. Я сам с ним не работал, но от AWS CDK у меня самые положительные воспоминания, а этот проект устроен по похожему принципу.

ugoday ★★★★★
()

Мне кажется, это больше всего зависит от вашего приложения, которое вы там запускаете. Оператор хорошо подходит для сложных действий, либо когда нужно что-то там перенастроить на лету, а само оно не поднимется, если просто чартом попытаться. В общем, кроме тебя никто на вопрос не ответит, поскольку твоего приложения лучше тебя никто не знает

George
()
Ответ на: комментарий от no-dashi-v2

генератор манифестов деплоя

проблема в том, что в него просачивается вариативность.

Вот у меня ситуация: урлы, роуты и конфигурация сильно зависят от клиентской ситуации: есть у него на каждую ноду отдельный хостнейм с HTTP redirect балансировкой или мы весь трафик проксируем с головной машины.

Куда пихать знания о том, как себя вести в том или ином случае?

max_lapshin ★★★★★
() автор топика
Ответ на: комментарий от max_lapshin

урлы, роуты и конфигурация сильно зависят от клиентской ситуации

Если эта информация известна на стадии развёртывания, то создаёшь values.yaml для общих настроек и values/values-cluster.yaml, которые переопределяют настройки в зависимости от кластера. CI/CD (мы используем ArgoCD) следит, чтобы настройки из git’а попадали в приложение. Всё.

ugoday ★★★★★
()