Управление релизами Helm: установка, обновление, откат и восстановление

В этой статье показано, как работать с релизами Helm: установить chart из репозитория, создать свой chart, выпустить релиз, обновить его, выполнить откат и восстановить историю после удаления. Примеры основаны на Apache и Nginx; команды оставлены в оригинальном виде для практического повторения.

В этой статье мы продолжим тему Helm и разберём практические шаги по выпуску (release) приложений в Kubernetes с помощью Helm. Если вы новичок в Helm, рекомендуется сначала прочитать вводную статью «What is Helm and how to install it on Ubuntu 20.04 server?». Здесь мы: выпустим Apache из удалённого репозитория, создадим локальный chart, выполним установку, обновление, откат, удаление и восстановление релиза.

Кратко — основные команды Helm и их назначение:

• helm search — поиск Helm chart’ов
• helm repo — управление репозиториями (add, list, remove, update, index)
• helm install — установить chart и создать объекты Kubernetes
• helm upgrade — обновить существующий релиз
• helm delete — удалить релиз и связанные объекты
• helm status — показать статус релиза
• helm history — история релиза (ревизии)
• helm rollback — откат к указанной ревизии

Важно: в статье предполагается, что у вас уже есть настроенный Kubernetes-кластер и установлен клиент Helm.

Предварительные условия

• Kubernetes-кластер с хотя бы одним рабочим узлом.
• Helm установлен на узле, с которого вы управляете релизами. Для установки Helm см. вводную статью автора.

Примечание. В некоторых примерах используется конфигурация 1 master + 2 worker, но это не обязательно — Helm работает с любым работающим кластером.

Что мы сделаем

1. Установим готовый chart Apache из репозитория.
2. Создадим локальный chart и выпустим тестовое приложение (Nginx).
3. Обновим релиз (изменим replicaCount) и проверим ревизии.
4. Удалим релиз и затем восстановим его историю с флагом –keep-history.

Быстрый пример: установка Apache из хаба

Сначала убедимся, что Helm доступен на сервере:

helm version

Далее выполним поиск chart’а Apache в hub:

helm search hub apache

Скопируйте URL одного из результатов. При переходе по URL вы увидите страницу с командами для добавления репозитория и установки chart’а.

Добавим репозиторий Bitnami и проверим список репозиториев:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo list

Теперь установим Apache из добавленного репозитория:

helm install my-release bitnami/apache

Успешная установка создаст объекты в кластере. Проверим узлы, поды и сервисы Kubernetes:

kubectl get nodes
kubectl get pods
kubectl get pods -o wide
kubectl get svc

Полученный IP пода можно использовать для обращения к приложению (пример с curl):

curl 10.244.1.2:8080

Если нужно удалить релиз:

helm delete my-release

Проверим список релизов и статус:

helm ls
helm status my-release

Создание chart’а и развёртывание локального приложения

Можно создать собственный chart с шаблоном приложения Nginx командой:

helm create my-first-chart

Посмотрим структуру созданного chart’а:

cd my-first-chart/
ls -l
ls -l charts/
ls -l templates/
ls -l templates/tests/

Откроем содержимое Chart.yaml и values.yaml для понимания метаданных и параметров по умолчанию:

ls -lt
cat Chart.yaml
ls -lt
cat values.yaml

Теперь установим релиз из локального chart’а:

cd ..
ls -l | grep my-first-chart
kubectl get pods
helm install my-first-release my-first-chart/

Проверим поды и сервисы, затем обратимся к Nginx через сервис:

kubectl get pods
kubectl get svc
curl 10.104.229.187

Информацию о релизе можно получить командами:

helm ls
helm status my-first-release

Обновление релиза

В локальном chart’е есть параметр replicaCount в values.yaml. По умолчанию он равен 1. Чтобы увеличить число реплик, измените значение в values.yaml:

cat my-first-chart/values.yaml | grep replica
vim my-first-chart/values.yaml
cat my-first-chart/values.yaml | grep replica

После сохранения изменений обновим релиз:

helm upgrade my-first-release my-first-chart/

Проверим список релизов — ревизия должна увеличиться, а в кластере появится больше подов:

helm ls
kubectl get pods

Историю релиза можно посмотреть командой:

helm history my-first-release

Если нужно откатиться к предыдущей ревизии (например, с 2 на 1):

helm rollback my-first-release 1

После отката создаётся новая ревизия (например, 3), в которой применяется конфигурация из ревизии 1.

helm ls
helm history my-first-release
kubectl get pods

Для удаления релиза:

helm delete my-first-release
helm ls

Восстановление релиза после удаления

По умолчанию при удалении релиза Helm очищает историю релизов, и восстановить предыдущие ревизии нельзя. Чтобы сохранить историю при удалении, используйте флаг –keep-history:

helm install my-second-release my-first-chart/
helm delete my-second-release --keep-history
helm ls
helm ls -a
helm history my-second-release
helm rollback my-second-release 1
helm ls
helm history my-second-release

Практическое руководство — шаги и чеклист

Ролевая проверка перед деплоем:

• Администратор кластера: проверяет доступность API-сервера и полномочия kubectl/helm.
• DevOps-инженер: проверяет values.yaml, шаблоны и CI/CD пайплайн.
• Разработчик: тестирует приложение локально и в тестовом namespace.

Playbook для стандартного релиза:

1. Проверить статус кластера: kubectl get nodes, kubectl get cs.
2. Проверить версию Helm: helm version.
3. Обновить репозитории: helm repo update.
4. Выполнить dry-run и шаблонизацию: helm install –dry-run –debug ./chart или helm template ./chart.
5. Установить релиз: helm install release-name chart-path.
6. Проверить объекты: kubectl get pods, kubectl get svc, kubectl describe pod .
7. Наблюдать логи: kubectl logs -f .
8. При ошибках — выполнить helm rollback release-name .

Критерии приёмки

• Все поды в namespace имеют статус Running.
• Сервис возвращает ожидаемый HTTP-код и тело ответа.
• Количество реплик соответствует replicaCount.
• Логи приложения содержат отсутствие критических ошибок за N минут тестирования.

Runbook для быстрого отката и восстановления

Цель: быстро вернуть рабочее состояние при падении после обновления.

1. Оценка инцидента: проверить статус релиза — helm status .
2. Просмотреть ревизии — helm history .
3. Откат к рабочей ревизии: helm rollback
4. Проверить состояние подов и логов: kubectl get pods, kubectl logs.
5. Если откат невозможен (histories отсутствуют), восстановить из бэкапа манифестов или переустановить chart с нужными values.
6. Для удаления с сохранением истории использовать helm delete –keep-history.

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

Когда подход с Helm может не подойти

• Простая инфраструктура без шаблонов: если вы используете только статические манифесты, kubectl apply может быть проще.
• Очень тонкая кастомизация одного ресурса: ручные правки манифестов иногда удобнее.
• Требования к управлению несколькими релизами/композитами: рассмотрите Helmfile, Flux или ArgoCD для GitOps.

Альтернативы и дополнения

• Kustomize — подходит для наложения патчей поверх YAML.
• kubectl apply — прямое применение YAML манифестов.
• Helmfile, Flux, ArgoCD — для GitOps и управления несколькими chart’ами.

Шаблоны, сниппеты и контрольные блоки

Минимальный Chart.yaml для simple chart:

apiVersion: v2
name: simple-app
description: Пример простого chart'а
type: application
version: 0.1.0
appVersion: "1.0"

Минимальная часть values.yaml (фрагмент):

replicaCount: 1
image:
  repository: nginx
  tag: stable
  pullPolicy: IfNotPresent
service:
  type: ClusterIP
  port: 80

Проверка шаблонов перед деплоем:

helm template ./my-first-chart | kubectl apply --dry-run=client -f -
helm lint ./my-first-chart

Краткий чеклист безопасности

• Проверяйте права RBAC, используемые chart’ом.
• Используйте imagePullPolicy и подписанные образы, где возможно.
• Ограничивайте ресурсы с помощью requests/limits.

Тесты и критерии приёмки

Примеры тест-кейсов для CI:

1. Lint chart: helm lint ./chart — ожидаемый результат: PASS.
2. Dry-run install: helm install –dry-run –debug ./chart — шаблонизация без ошибок.
3. Функциональный тест: развернуть в test-namespace и выполнить curl к сервису — ожидаемый HTTP 200.
4. Миграции: проверить, завершились ли миграции без ошибок в логах.

Ментальные модели и рекомендации

• Представьте релиз как версию приложения с идентификатором и набором Kubernetes-ресурсов.
• Ревизии — это снимки изменений; каждая операция upgrade/delete (с опциями) увеличивает историю.
• Используйте values.yaml для параметризации; шаблоны используйте для структурирования ресурсов.

Факт-бокс

• Helm создаёт релиз и управляет связанной конфигурацией через шаблоны и values.
• Ревизии позволяют вернуться к предыдущему состоянию при корректной конфигурации history.
• Флаг –keep-history сохраняет ревизии после удаления релиза.

Терминология

• chart — пакет ресурсов Kubernetes (шаблоны + метаданные + значения).
• release — инстанс установленного chart’а в кластере.
• values.yaml — файл значений по умолчанию, который задаёт параметры для шаблонов.
• ревизия — версия релиза в истории изменений.

Рольовые чеклисты

Для разработчика:

• Локально протестировать приложение.
• Подготовить values.yaml для окружения.
• Прописать readiness/liveness probes.

Для DevOps:

• Написать pipeline для lint/template/install.
• Настроить мониторинг и алерты для релиза.
• Обеспечить безопасность и RBAC.

Для SRE:

• План отката и runbook на случай регресса.
• Резервные копии конфигураций и секретов.
• Пост-даунтайм анализ и отчёт.

Заключение

Мы показали полный жизненный цикл релиза Helm: поиск и установка chart’а из репозитория, создание локального chart’а, установка, обновление с увеличением replicaCount, откат к предыдущей ревизии и восстановление истории релиза при удалении с флагом –keep-history. Helm упрощает управление релизами, но требует внимания к безопасности, версиям и процессам отката. Следуйте чеклистам и тестам перед деплоем в production.

Ключевые команды, использованные в статье:

helm search hub apache
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo list
helm install my-release bitnami/apache
helm create my-first-chart
helm install my-first-release my-first-chart/
helm upgrade my-first-release my-first-chart/
helm history my-first-release
helm rollback my-first-release 1
helm delete my-second-release --keep-history
helm ls -a

Дополнительные ресурсы и дальнейшие шаги

• Подумайте о внедрении GitOps с ArgoCD или Flux для управления chart’ами через репозиторий.
• Автоматизируйте тесты chart’ов в CI (helm lint, helm template, интеграционные тесты).
• Документируйте runbook для быстрого реагирования на инциденты.