Комментарии 9
Статей из ряда «как начать использовать helm» = 100500. Вот бы кто рассказал зачем? С примерами в сравнении с kubectl.
При ~100 сервисов, лично я не увидел пользы от helm. Скорее минусы… Может толк станет заметен при 1000, 10000+ сервисах?
При ~100 сервисов, лично я не увидел пользы от helm. Скорее минусы… Может толк станет заметен при 1000, 10000+ сервисах?
Статей из ряда «как начать использовать helm» = 100500
Но на хабре их 0 (да и в рунете тоже). А ответ по теме нужности/полезности есть по ссылке в комментарии ниже (от коллеги и автора статьи, который, похоже, промахнулся при ответе).
Хм, на моем опыте даже если у нас всего пара-тройка деплойментов, их сервисов и конфигмапов, то это все менеджить одним Хелм чартом удобнее, чем yaml файлами для kubectl. Особенно в процессе разработки, когда изменения и редеплои проходят постоянно.
Удобней… чем? Какую проблему для вас решает helm?
— В helm мы можем экстернализировать любые параметры наших ресурсов, и они все храняться в одном месте, в values.yaml. Например если мы делаем чарт для другого типа платформ, то просто меняем в одном файле пару параметров. Сгружать же все ресурсы в один конфиг для kubectl и дальше искать и редактировать параметры во всех местах где они встречались руками — неудобно и чревато ошибками.
— В helm удобно сделан просмотр текущих состояний релизов. Сразу видно что у нас стоит в кластере, в каком неймспейсе и точная дата-время установки. В kubectl же выводить простыню через kubectl get all и потом разбираться какой ресурс к какому приложению относится, еще и отдельно для каждого неймспейса — неудобно.
— Допустим нам надо подправить конфиг на рабочем деплойменте и мы изменили конфигмап. kubectl не умеет подхватывать изменения в конфигмапах, нам надо вручную рескейлить деплоймент и руками удалять старые поды. В helm мы можем в metadata: annotations: деплоймента поставить проверку чексуммы конфигмапа. И дальше сделать всю работу одной командой helm upgrade
— Чисто субьективно, работать с разными версиями чартов как с артифактами удобнее, чем хранить kubectl конфиги в гите и версионировать все разными бранчами.
— В helm удобно сделан просмотр текущих состояний релизов. Сразу видно что у нас стоит в кластере, в каком неймспейсе и точная дата-время установки. В kubectl же выводить простыню через kubectl get all и потом разбираться какой ресурс к какому приложению относится, еще и отдельно для каждого неймспейса — неудобно.
— Допустим нам надо подправить конфиг на рабочем деплойменте и мы изменили конфигмап. kubectl не умеет подхватывать изменения в конфигмапах, нам надо вручную рескейлить деплоймент и руками удалять старые поды. В helm мы можем в metadata: annotations: деплоймента поставить проверку чексуммы конфигмапа. И дальше сделать всю работу одной командой helm upgrade
— Чисто субьективно, работать с разными версиями чартов как с артифактами удобнее, чем хранить kubectl конфиги в гите и версионировать все разными бранчами.
— темплейтинг манифестов будет нужен, пока что, сервисов с динамичными настройками мало, где нужно — обходимся sed'om в CI
— думаю тут дело привычки, на данный момент, мне удобней смотреть состояние через kubectl +сделал несколько алиасов
— решаем такие вещи добавлением в под конфиг-релоадера
— конфиги пишем 1:1 файл:kind, только rbac манифесты в одном yaml — разобраться/прочитать не составит труда
Для решения CI/CD + templateing есть альтернативы, тащить «package manager» для этого, не вижу смысла.
— думаю тут дело привычки, на данный момент, мне удобней смотреть состояние через kubectl +сделал несколько алиасов
— решаем такие вещи добавлением в под конфиг-релоадера
— конфиги пишем 1:1 файл:kind, только rbac манифесты в одном yaml — разобраться/прочитать не составит труда
Для решения CI/CD + templateing есть альтернативы, тащить «package manager» для этого, не вижу смысла.
Да и в целом Go-темплейтинг — крутая штука. Мы можем использовать традиционные конфиг файлы с отдельного репозитория и создавать из них конфигмапы на лету при установке чарта. Генерировать конфиги на лету для зависимых чартов в зависимости от параметров в родительском чарте. И т.д.
Чтобы не дублировать ответ на подобный комментарий предлагаю перейти по ссылке к прошлой статье.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Практическое знакомство с пакетным менеджером для Kubernetes — Helm