Как стать автором
Обновить

Комментарии 11

А кто-то из тех, кто использует Helm для деплоя единственной системы из пары десятков контейнеров в выделенный для неё кластер в разных окружения от дев до прод, использует его возможности менеджера пакетов, а не шаблонизатора? Я пока даже придумать особо не смог для таких кейсов.

Поясните, пожалуйста, мысль.
У меня пока складывается ощущение, что


  1. Хельм хорош, чтобы попробовать в кластере какой-то софт. Так же как и докер хорош именно для запуска некоей софтины в изолированном окружении в тестовом контуре.


  2. Мы деплоим в куб либо ручками, либо используя хельм как темплейтер и его выхлоп на kubectl apply.


  3. Фундаментальные две проблемы — что-то более сложное, чем получение и применение куб манифеста, например, роллинг релиз некоего продукта или очистку устаревших ресурсов — насколько я понял, хельм не решает.


Хельм хорош, чтобы попробовать в кластере какой-то софт. Так же как и докер хорош именно для
запуска некоей софтины в изолированном окружении в тестовом контуре.

Чем вас не устраивает helm для выката и в другие контуры, если не секрет?


Мы деплоим в куб либо ручками, либо используя хельм как темплейтер и его выхлоп на kubectl apply.

Вы используете исключительно kubectl или у вас есть ещё дополнительные инструменты?


роллинг релиз некоего продукта

Может быть я неправильно вас понимаю, но, а как иначе?
В helm даже сущность была новая введена — release. При первой инсталляции чарта создаётся релиз, а при последующих он обновляется.


очистку устаревших ресурсов

А что вы подразумеваете под устаревшими ресурсами и почему эта задача не может быть решена командой helm delete и, при необходимости, дополнена соответствующими хуками?

В целом я имел в виду активное использование как чартов из публичных репозиториев, так и создание своих репозиториев чартов на уровне организации/проекта в рамках реальных проектов. Пока встречался только с подходом таким: папка деплоя проекта c подпапкой charts, где описаны все-все темплейты для разворачивания, то есть ни одного ни то что стороннего чарта, а даже ни одного обособленного от проекта (кроме вложенного charts), хотя в теории что-то можно было бы и сгруппировать, например, стандартный для проекта подход для подов с реверс-прокси/веб-сервером со статикой перед апп-сервером на каждый сервис, только некоторые значения меняя

Chart repository — это то, кмк, что позволяет Helm обладать таким большим сообществом и оставаться всё ещё на плаву, несмотря на местами спорные приоритеты в развитии продукта.


В Helm хорошо подошли к управлению зависимостями:


dependencies:
- name: subchart1
  repository: http://localhost:10191
  version: 0.1.0
  condition: subchart1.enabled,global.subchart1.enabled
  tags:
  - front-end
  - subchart1

- name: subchart2
  repository: http://localhost:10191
  version: 0.1.0
  condition: subchart2.enabled,global.subchart2.enabled
  tags:
  - back-end
  - subchart2

Condition и tags отличная альтернатива для организации выката в различные окружения велосипедам на go шаблонах. К примеру, в тестовом окружение поднимаем базу данных и очередь в кластере, а в проде используем внешние — две/три дополнительные опции в .gitlab-ci.yml и чистые чарт шаблоны.


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

Если правильно понял вопрос, то речь идёт об использовании helm исключительно для генерации манифестов:


helm template . | kubectl apply --wait -f -

При использовании helm становится удобным сопровождение инсталляций. Помимо таких базовых операций, как установка, обновление и удаление, вдобавок доступен откат до определённой версии командой helm rollback (полезно, к примеру, при неудавшемся выкате).


Всегда есть возможность посмотреть какие релизы установлены в кластере (helm list), а также посмотреть текущее состояние ресурсов конкретного релиза (helm status).


Helm так же позволяет контролировать процесс выката. Речь идёт о порядке, зависимостях и хуках. В большинстве наших проектов мы используем хуки для фикстур и миграций баз данных, но область применения на этом не ограничивается.

  1. Хуки — будут работать только с тиллером. Без него — я попросту не понимаю, кто их будет выполнять. Про тиллер уже только ленивый не высказался


  2. Так как насчёт канареечного релиза? Без простыней в 100500 команд в пайплайне снаружи куба (если писать такое, то очевидно, что тиллер тоже не нужен, но выглядит как закат солнца вручную). Так же очевидно, что если есть миграция бд, то хельм, ну, никак не сделает ее из блокирующей бд в неблокирующую
    Виноват — неудачно ляпнул про роллинг — куб сам умеет в него с определенными ограничениями.
    Мое мнение — тип релиза должен описываться в некоем crd внутри кластера. Пока видится, что наиболее близко к этому подошли service mesh типа istio.


  3. Про паттерны. Если в ПО есть ломающее изменение (например, переход от v1 api к v2 api и это именно api для внешних клиентов), то есть большой соблазн оформить его как не два релиза одного пакета, а как два разных пакета. Интересно — как коллеги в таких случаях действуют.


  1. Tiller не так страшен, если его спрятать. Я, к примеру, использую следующий скрипт:

helm wrapper

Disclaimer: скрипт пишу без проверки, чтобы передать суть


#!/bin/bash

# здесь я упрощаю, на самом деле пространство имен берется из ~/.kube/config
TILLER_NAMESPACE=test /usr/local/bin/tiller --storage secret & 
TILLER_PID="$!"

# 44134 -- порт по-умолчанию
HELM_HOST=localhost:44134 /usr/local/bin/helm "$@"

kill "$TILLER_PID"

В этом случае:


  • в кластере Tiller не установлен, он поднимается на моей рабочей машине;
  • файлы релизов (н-р beauty-fox.v1) хранятся в секретах, а не в ConfigMap;
  • не нужно никаких плясок с RBAC, Tiller использует пользователя из ~/.kube/config.



Это я пишу безотносительно хуков, просто люди часто ругают Helm именно по поводу Tiller в kube-system. Однако есть и другие варианты.


Конечно же, я не спорю, что без Tiller не нужны были бы и костыли вроде описанного мной.

Хуки

— это исключительно про порядок. Вы с тем же успехом можете выкатывать *хуки, используя kubectl apply, дожидаться их завершения и выполнять следующий шаг (в Helm поддерживается около десяти типов хуков и организация подобного на bash выглядит не очень перспективным занятием). В Helm 2 tiller используется для установки ресурсов, в Helm 3 все функции выполняет клиент, поэтому мне совсем непонятно негодование будут работать только с тиллером.


Helm 2 можно использовать без tiller в кластере, если это для вас проблема. Этой теме посвящено много статей, они сгруппированы таким термином как tillerless (по сути всё сводится к тому, что описал коллега в первом комментарии). Мы пошли дальше и встроили helm в наше собственное решение, werf.


Канареечный релиз

У вас нет никаких ограничений при построенние процесса выката на основе helm и istio хороший тому пример.


Если есть миграция бд, то хельм, ну, никак не сделает ее из блокирующей бд в неблокирующую

В хуках вы можете использовать kubectl и тут полная свобода для творчества, хотите удаляйте ресурсы, хотите скейлите их в ноль.

Получается не точно выразился. Имеется в виду использование механизма шаблонизации и релизов, но без использования зависимостей

Это во многом зависит от проектов. Большинство web-студий используют единный стек технологий для всех своих продуктов, поэтому им уместно свести настройку выката к описанию файла с настройками, values.yaml, для своего или официального чарта:


helm install --name my-release -f values.yaml stable/drupal
Зарегистрируйтесь на Хабре , чтобы оставить комментарий