Helm не дожидается, когда приложение начинает функционировать, все ресурсы переходят в состояние Running: при успешном выполнении install или upgrade, т.е. имея release в состоянии success, helm не гарантирует, что ресурсы приложения успешно выкатились (к примеру, нет ошибок типа ImagePullError).
На текущий момент состояние success говорит о том, что манифесты применились успешно. Если опустить множество деталей, то можно провести аналогию с командой kubectl apply.
Что касается логирования, то сейчас в helm оно "как-то" поддерживается для Hook-ов. Hook — механизм helm, который позволяет выполнять операции, привязываясь к различным этапам жизненного цикла релиза. К примеру, можно сделать дамп базы перед удалением или накатить фикстуры при инсталяции. Подробнее про них можно почитать здесь.
"Как-то" нас не устраивает, поэтому мы используем собственное решение при выкате приложений с dapp и параллельно пытаемся добавить этот функционал в helm (почитать можно в соответствующем issue).
Что касается отладки, то состояние всех ресурсов релиза можно посмотреть, выполнив команду helm status, а далее уже использовать kubectl logs.
Чего-то существенного от ошибок и сопутствующего вывода helm ждать не стоит.
Rollback
Helm позволяет откатываться до определённой ревизии релиза. Список всех ревизий можно посмотреть, выполнив команду helm history, а откатить версию командой helm rollback.
The release object contains information about a release, where a release is a particular installation of a named chart and values. This object describes the top-level metadata about a release.
At minimum, there are two necessary pieces of data a Release must track:
The name of the release
The curretly deployed version (release version Secret) of this release
The release object persists for the duration of an application lifecycle, and is the owner of all release version Secrets, as well as of all objects that are directly created by the Helm chart. (These relationships may be represented by owner references.)
With this change, release names can now be scoped to namespace, instead of globally scoped as they were with Helm 2.
Началом существования helm принято считать презентацию на KubeCon в San Francisco в ноябре 2015-го года. Менее чем через год вышла вторая версия и в настоящий момент она является актуальной.
Данная статья является анонсом следующей версии и нет никакой информации по дате выхода.
Основные принципы и задачи инструмента остаются прежними, поэтому переживать за пользователей не стоит.
Helm может использоваться для выката приложений в кластер kubernetes. Helm не обрабатывает исходный код приложения, а работает с образами, для создания которых потребуется инструмент CI/CD.
Q: Почему просто не использовать `kubectl apply -f`?
Обычно проблемы начинаются когда идёт автоматизация процесса выката, настройка процессов CI/CD. К примеру, рассмотрим задачу с выкатом в различные окружения.
Каждое окружение имеет свои потребности. Требуется различный набор kubernetes-ресурсов, отличаются параметры у ресурсов (сертификаты, доступы баз данных, сопутствующих сервисов, и т.д.). Опять же, продовые доступы и сертификаты не должны храниться в незашифрованном виде в репозитории.
Появляется потребность в шаблонизации и работе с секретами, и это только вершина айсберга.
Таким образов, требуется комплексный подход к выкату, так почему бы не использовать helm?
Helm содержит инструменты для создания, отладки, компоновки и сопровождения конфигураций kubernetes-ресурсов, а также упрощает управление выкатом приложений, за счёт хуков, версионирования, возможности многократного использования Chart-ов и многого другого.
Kubernetes-ресурсы:
Кастомизация и переиспользование за счёт шаблонизации.
Официальный репозиторий с готовыми решениями, из которых можно компоновать собственные приложения.
Версионирование, откат до определённой версии. К примеру, откат при неудавшемся выкате.
Хуки, позволяющие вмешиваться в жизненный цикл релиза. К примеру, делать дамп базы перед удалением инсталяции или выкатывать фикстурные данные после установки, оповещать по API сопутствующие сервисы об установке, обновлении, удалении и т.д.
Об этом и многом другом мы постараемся рассказать в этом цикле статей про helm.
По поводу ошибок и логирования
Helm не дожидается, когда приложение начинает функционировать, все ресурсы переходят в состояние
Running: при успешном выполнении install или upgrade, т.е. имея release в состоянии success, helm не гарантирует, что ресурсы приложения успешно выкатились (к примеру, нет ошибок типа ImagePullError).На текущий момент состояние success говорит о том, что манифесты применились успешно. Если опустить множество деталей, то можно провести аналогию с командой
kubectl apply.Что касается логирования, то сейчас в helm оно "как-то" поддерживается для Hook-ов. Hook — механизм helm, который позволяет выполнять операции, привязываясь к различным этапам жизненного цикла релиза. К примеру, можно сделать дамп базы перед удалением или накатить фикстуры при инсталяции. Подробнее про них можно почитать здесь.
"Как-то" нас не устраивает, поэтому мы используем собственное решение при выкате приложений с dapp и параллельно пытаемся добавить этот функционал в helm (почитать можно в соответствующем issue).
Что касается отладки, то состояние всех ресурсов релиза можно посмотреть, выполнив команду
helm status, а далее уже использоватьkubectl logs.Чего-то существенного от ошибок и сопутствующего вывода helm ждать не стоит.
Rollback
Helm позволяет откатываться до определённой ревизии релиза. Список всех ревизий можно посмотреть, выполнив команду
helm history, а откатить версию командойhelm rollback.Данная статья является анонсом следующей версии и нет никакой информации по дате выхода.
Основные принципы и задачи инструмента остаются прежними, поэтому переживать за пользователей не стоит.
Helm может использоваться для выката приложений в кластер kubernetes. Helm не обрабатывает исходный код приложения, а работает с образами, для создания которых потребуется инструмент CI/CD.
Q: Почему просто не использовать `kubectl apply -f`?
Обычно проблемы начинаются когда идёт автоматизация процесса выката, настройка процессов CI/CD. К примеру, рассмотрим задачу с выкатом в различные окружения.
Каждое окружение имеет свои потребности. Требуется различный набор kubernetes-ресурсов, отличаются параметры у ресурсов (сертификаты, доступы баз данных, сопутствующих сервисов, и т.д.). Опять же, продовые доступы и сертификаты не должны храниться в незашифрованном виде в репозитории.
Появляется потребность в шаблонизации и работе с секретами, и это только вершина айсберга.
Таким образов, требуется комплексный подход к выкату, так почему бы не использовать helm?
Helm содержит инструменты для создания, отладки, компоновки и сопровождения конфигураций kubernetes-ресурсов, а также упрощает управление выкатом приложений, за счёт хуков, версионирования, возможности многократного использования Chart-ов и многого другого.
Kubernetes-ресурсы:
Выкат:
Об этом и многом другом мы постараемся рассказать в этом цикле статей про helm.