Helm: пакетный менеджер для Kubernetes

Рейтинг: 64.6% · 12 голосов
Kubernetes для разработчиков: поды, деплойменты, сервисы, ingress, конфиги и отладка. Уроки по главам с обсуждением.
Ответить
Аватара пользователя
anton_k8s
Сообщения: 26
Зарегистрирован: 12 май 2026, 03:23

Helm: пакетный менеджер для Kubernetes

Сообщение anton_k8s »

АкадемияKubernetes на практикеГлава 12 из 19
Оглавление курса (19)
  1. Зачем нужен Kubernetes и из чего состоит кластер
  2. Поднимаем локальный кластер: minikube и kind
  3. Поды: базовая единица запуска
  4. Deployment и ReplicaSet: управляем репликами
  5. Service: сетевой доступ к подам
  6. ConfigMap и Secret: выносим конфигурацию
  7. Ingress: пускаем трафик снаружи
  8. Хранилище: Volumes и PersistentVolumeClaim
  9. Namespaces, requests и limits
  10. Health checks: liveness и readiness пробы
  11. Отладка: почему под не стартует
  12. Helm: пакетный менеджер для Kubernetes (вы здесь)
  13. Базовая безопасность: RBAC и доступы
  14. Job и CronJob: разовые и периодические задачи
  15. StatefulSet и DaemonSet: stateful-нагрузки и системные агенты
  16. Стратегии обновления и планирование: rollout и rollback, graceful shutdown, nodeSelector, affinity, taints
  17. Автомасштабирование: HPA по метрикам, обзор VPA и Cluster Autoscaler
  18. Наблюдаемость: логи, метрики, events, обзор Prometheus и Grafana
  19. Безопасность глубже: securityContext, Pod Security Standards, NetworkPolicy, шифрование секретов
К этому моменту вы написали руками с десяток манифестов: Deployment, Service, ConfigMap, Ingress, PVC. Для одного приложения терпимо. Но когда сервисов пять, а окружений три (dev, stage, prod), копипаста yaml превращается в боль: поменял лимиты в одном файле, забыл в четырех других. Helm решает это шаблонами: один пакет манифестов, разные наборы значений.

Основные понятия:

Чарт (chart) это пакет из шаблонов манифестов и файла значений по умолчанию. Релиз (release) это установленный в кластер экземпляр чарта с конкретными значениями. Один чарт можно поставить несколько раз под разными именами, скажем webapp-dev и webapp-stage в разных namespace.

Helm 3 работает без серверной части (Tiller остался во второй версии), история релизов хранится прямо в кластере в виде Secret в namespace релиза. Ставится одним бинарником: на macOS через brew, на Linux пакетом дистрибутива или скриптом установки.

Собственный чарт:

Код: Выделить всё

helm create webapp

webapp/
  Chart.yaml        # имя и версия чарта, версия приложения
  values.yaml       # значения по умолчанию
  templates/        # шаблоны манифестов
    deployment.yaml
    service.yaml
    ingress.yaml
    _helpers.tpl    # вспомогательные куски шаблонов
Шаблоны это обычные манифесты с подстановками на Go templates. Фрагмент deployment.yaml и значения к нему:

Код: Выделить всё

# templates/deployment.yaml (фрагмент)
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

# values.yaml
replicaCount: 2
image:
  repository: registry.example.ru/shop/webapp
  tag: "1.4.2"
Под каждое окружение заводится свой файл, например values-prod.yaml, и в нем переопределяется только то, что отличается: реплики, хост в Ingress, размер PVC. Остальное берется из values.yaml.

Рабочий цикл:

Код: Выделить всё

helm lint ./webapp
helm template webapp ./webapp -f webapp/values-prod.yaml

helm upgrade --install webapp ./webapp \
  -n shop --create-namespace \
  -f webapp/values-prod.yaml \
  --set image.tag=1.4.3 \
  --atomic --timeout 3m

helm history webapp -n shop
helm rollback webapp 2 -n shop
lint ловит ошибки в шаблонах. template рендерит итоговые манифесты локально, без кластера: удобно для ревью, видно ровно то, что уедет в API-сервер.

Ставить лучше через upgrade --install, а не чистый install: команда идемпотентна, нет релиза, создаст, есть, обновит. Одна и та же строка в CI работает и для первого деплоя, и для сотого. Флаг --atomic откатит релиз, если поды не поднялись за timeout. rollback возвращает манифесты любой прошлой ревизии из history. Откатываются только объекты Kubernetes: миграции базы Helm за вас не отменит, это ваша забота.

Чужие чарты:

Вторая половина пользы Helm, готовые чарты для инфраструктуры. Ingress-контроллер из седьмой главы в реальных кластерах ставят именно так:

Код: Выделить всё

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm show values ingress-nginx/ingress-nginx > nginx-defaults.yaml
helm install ingress-nginx ingress-nginx/ingress-nginx \
  -n ingress-nginx --create-namespace
Перед установкой чужого чарта обязательно смотрите его values через helm show values. Там бывают сотни параметров, и дефолты рассчитаны на сферический кластер, а не на ваш. Чарты можно хранить и в OCI-реестрах рядом с docker-образами: helm push и helm install понимают адреса вида oci://, так что свой Harbor или GitLab Registry подходит без дополнительных сервисов.

Типичные грабли:

--set конвертирует типы по своим правилам. Версия 1.20 превратится в число 1.2, true станет булевым, хотя шаблон ждал строку. Для отдельных случаев есть --set-string, но в целом все, что сложнее одного простого флага, передавайте файлом значений.

Если поправить ресурс руками через kubectl edit, следующий helm upgrade может молча перезаписать правку. Правьте values и катите через Helm, иначе кластер разъедется с тем, что лежит в git, и отлаживать это будете долго.

CRD из папки crds чарта Helm ставит только при первой установке и никогда не обновляет сам. При апгрейде чарта с CRD читайте его changelog: обновление CRD почти всегда отдельный ручной шаг.

Не путайте version и appVersion в Chart.yaml: version это версия самого чарта, appVersion это версия приложения внутри. Поменяли шаблон, поднимайте version, даже если образ приложения тот же, иначе реестр чартов не примет пакет.

Что усвоили:

Helm убирает копипасту манифестов: чарт плюс свой values на окружение, идемпотентный деплой через upgrade --install, откат через rollback, готовые чарты для инфраструктуры. В последней главе закроем вопрос доступов: RBAC, ServiceAccount и кто вообще имеет право делать helm upgrade в вашем проде.
👍3 ❤️4 🔥2 😄 🤔1
✔ Лучший ответ сформирован автоматически — smith_kostya
anton_k8s писал(а):следующий helm upgrade может молча перезаписать правку справедливости ради helm 3 делает three-way merge, и часть ручных правок апгрейд переживает. но полагаться на это правда не стоит. у нас replicaCount из чарта подрался с HPA: каждый деплой сбрасывал реплики, потом hpa поднимал обратно. вылечили тем, что убрали replicas из шаблона совсем
Перейти к ответу →
Аватара пользователя
Esp32Wizard
Сообщения: 1
Зарегистрирован: 10 май 2026, 23:24

Re: Helm: пакетный менеджер для Kubernetes

Сообщение Esp32Wizard »

anton_k8s писал(а):Флаг --atomic откатит релиз, если поды не поднялись за timeout.
а с хуками как? у нас миграция базы крутится в pre-upgrade хуке. если она упадет, atomic откатит манифесты, но полуприменённую миграцию-то не вернёт. получается atomic безопасен только для stateless части, а миграции надо делать обратимыми самим?
👍 ❤️1 🔥 😄 🤔1
Аватара пользователя
kjs4567
Сообщения: 2
Зарегистрирован: 26 май 2026, 14:43

Re: Helm: пакетный менеджер для Kubernetes

Сообщение kjs4567 »

а чем плох вариант helm template ... | kubectl apply -f - ? у нас в CI исторически так, helm только рендерит. работает, но history и rollback понятно нет. есть еще минусы, ради которых стоит переезжать на upgrade --install, или можно жить?
👍 ❤️ 🔥 😄 🤔
Аватара пользователя
soliditykun
Сообщения: 1
Зарегистрирован: 07 июн 2026, 23:52

Re: Helm: пакетный менеджер для Kubernetes

Сообщение soliditykun »

спасибо за пункт про version в Chart.yaml, наступил на это пару недель назад. поменял шаблон, version не поднял, реестр не принял пакет с той же версией, а пайплайн это проглотил. два часа искал, почему в проде старый конфиг
👍 ❤️4 🔥 😄 🤔
Аватара пользователя
smith_kostya
Сообщения: 2
Зарегистрирован: 16 май 2026, 18:17

Re: Helm: пакетный менеджер для Kubernetes

Сообщение smith_kostya »

✔ Лучший ответ — сформирован автоматически
anton_k8s писал(а):следующий helm upgrade может молча перезаписать правку
справедливости ради helm 3 делает three-way merge, и часть ручных правок апгрейд переживает. но полагаться на это правда не стоит. у нас replicaCount из чарта подрался с HPA: каждый деплой сбрасывал реплики, потом hpa поднимал обратно. вылечили тем, что убрали replicas из шаблона совсем
👍 ❤️ 🔥 😄 🤔
Ответить
← Предыдущая глава
Отладка: почему под не стартует
Следующая глава →
Базовая безопасность: RBAC и доступы

Все главы курса «Kubernetes на практике»

Поделиться темой: ✈ Telegram VK

Вернуться в «Kubernetes на практике»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость