#helm #kubernetes

Три прыжка.

Как же идёт порядок генерации манифестов по шаблону, сортировка и применение в кластере при использовании Helm v3?  

Прыжок в воду 1.

Можно просто почитать официальную документацию на версию 3.19
Немного лукавит из-за нерегулярного обновления, но в целом 90% инженерам этого достаточно.
Мы теперь знаем, что перед деплойментом у нас есть секрет, перед ним PVC, а ещё раньше их неймспейс.
Это логично и не рождает проблем в стандартных чартах.

Прыжок в воду 2.

Так же можно посмотреть в исходном коде на версию 3.19
Там видно настоящий список, а так же указаны логические операторы про анноун ресурсам и сортировке.
Всякие CRD, хуки и весы.
Чуть точнее и глубже, этого достаточно ещё 5% людей.

Прыжок в воду 3.

Побудем сегодня любопытными инженерами и узнаем всё до конца, нырнув глубже.

В общем и целом есть несколько основных категорий:
- pre-* хуки
- post-* хуки
- Standard ресурсы
- CRD
- Unknown ресурсы

При запуске helm install/helm upgrade --install у нас идёт такой порядок:
1) CRD. Всегда первым. Из директории <чарт>/crds/.
Они не шаблонизируются, а применяются как есть.
https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/

2) pre-install hooks.
Если есть. ("helm.sh/hook": *)
Внутри группы хуков сначала сортируются по весу("helm.sh/hook-weight"):
- отрицательный
- ноль (по умолчанию)
- положительный
- по имени
Внутри одного веса сортировка идёт по имени ресурса (алфавитно).
https://helm.sh/docs/topics/charts_hooks/

3) standard ресурсы, по порядку в исходном коде в kind_sorter.go
Сортировка происходит после рендеринга шаблонов, но до их применения к кластеру.
Рендеринг -> сортировка -> применение.
- PriorityClass
- Namespace
..
- ClusterRoleBinding
..
- Deployment
..

4) Unknown ресурсы
Так сказать всё остальное бесчисленное множество.
Важно понимать, что внутри группы Unknown ресурсов порядок детерминирован и следует правилу: сначала сортировка по Kind (алфавитно) (например, ApplicationSet перед PostgreSQL), а затем по имени ресурса (алфавитно).
- ApplicationsSet (ArgoCD)
- PostgreSQL (Zalando)
..
- ScaledObject (KEDA)
Этот алфавитный порядок зачастую не совпадает с требуемым логическим порядком зависимостей.

5) post-install хуки.
Если есть. ("helm.sh/hook": *)
Внутри группы хуков сначала сортируются по весу("helm.sh/hook-weight"):
- отрицательный
- ноль (по умолчанию)
- положительный
- по имени
Внутри одного веса сортировка идёт по имени ресурса (алфавитно).
https://helm.sh/docs/topics/charts_hooks/
Вот теперь картина полная и мы славные инженеры.

- - -
Для чего же мы ныряем так глубоко? Зачем нам это?

Иногда прилетают задачи о оптимизации имеющегося чарта.
Например (это. лишь. пример), у нас сложная технологическая платформа, а в чарте есть и cert-manager с выпуском сертификатов, и externalsecrets и issuer, и многое другое.
Все ресурсы категории Unknown и нам нужен строгий порядок или, что хуже, тайминг(чтобы успело создаться что-то до следующего ресурса).

Нет ишшуера/не будет выпущен серт - не будет его куда запушить/примонтировать - не будет секрета/пушсикрета - проблема платформы. Да и серт не мгновенно выпускается. Нужно время. Как быть?
Тот же issuer по алфавиту идёт после certificate, хотя должно быть и иначе, а pushsecret ничего не сможет прокинуть, потому что серт ещё не выпущен. И всё обёрнуто через ArgoCD.

Как раз тут и пригодятся нам эти глубокие знания.
Зная правила мы спокойно решаем задачу.

- Алекс, а что там с Арго?
Под капотом ArgoCD использует как раз helm template.
https://argo-cd.readthedocs.io/en/stable/user-guide/helm/
- А что там с хуками?
Argo CD автоматически конвертирует эту логику в свои Hooks и Waves, сохраняя ваш строгий контроль над порядком.
- helm.sh/hook -> Resource Hooks
- helm.sh/hook-weight -> Sync Waves
https://argo-cd.readthedocs.io/en/release-2.14/user-guide/resource_hooks/
https://argo-cd.readthedocs.io/en/stable/user-guide/sync-waves/

Занимательное:
- при helm upgrade CRD из crds/ не обновляются (Helm не изменяет их содержимое, нужно делать вручную), только при helm install