Шлем устанавливаем в определенном порядке
Я пытаюсь создать Helm Chart со следующими ресурсами:
- Секрет
- ConfigMap
- обслуживание
- Работа
- Развертывание
Они также находятся в том порядке, в котором я хотел бы, чтобы они были развернуты. Я добавил ловушку в развертывание, чтобы оно выполнялось после установки, но тогда Helm не видит его как ресурс, и мне приходится управлять им вручную.
Для Job нужна информация в Secret и ConfigMap, иначе я бы сделал это перед установкой. Но я не могу все сделать приколом, иначе в моем выпуске ничего не получится.
Есть ли у кого-нибудь решение или идея, позволяющие управлять всеми ресурсами в выпуске Helm И убедиться, что задание завершено до начала развертывания?
Моя единственная мысль сейчас - два сделать два графика: один с 1-4, а второй с 5, что будет зависеть от первого.
Из интереса, что делает Работа?
Я спрашиваю отчасти потому, что мне интересно, могли бы вы поместить initContainer в Deployment и вместо этого переместить туда логику Job. В любом случае сначала должны быть созданы configmap и secret с упорядочиванием ресурсов helm.
@RyanDawson Задание подготавливает базу данных, и я бы не хотел, чтобы она выполнялась для каждого модуля развертывания.
Если вы решите сделать это, вы можете сделать его идемпотентным с помощью проверки в начале. Примеры этого из официального репозитория helm / charts см. В любом из github.com/helm/charts/… или github.com/helm/charts/blob/master/stable/keycloak/templates /….
Ответы 1
Helm собирает все ресурсы в данной диаграмме и ее зависимости, группирует их по типу ресурсов, а затем устанавливает их в следующем порядке (см. здесь - Helm 2.10):
- Пространство имен
- ResourceQuota
- LimitRange
- PodSecurityPolicy
- Секрет
- ConfigMap
- StorageClass
- PersistentVolume
- PersistentVolumeClaim
- ServiceAccount
- CustomResourceDefinition
- ClusterRole
- ClusterRoleBinding
- Роль
- RoleBinding
- обслуживание
- DaemonSet
- Стручок
- ReplicationController
- ReplicaSet
- Развертывание
- StatefulSet
- Работа
- CronJob
- Ingress
- APIService
При удалении выпуска порядок меняется на противоположный (см. здесь).
Следуя этой логике, в вашем случае, когда ваш ресурс Job создан, как Secret, так и ConfigMap уже будут применены, но Helm не будет ждать завершения Job перед применением Deployment. Если вы разделите диаграмму на две части (1-4, 5) и установите их последовательно, у вас все равно будет проблема, связанная с возможным применением развертывания до того, как задание будет завершено. Я бы посоветовал разделить вашу диаграмму на две части (1-3, 4-5), в которых задание имеет предварительную установку, которая обеспечит его завершение до того, как будет применено ваше развертывание.
спасибо за ваше предложение, я узнаю больше о зависимостях диаграмм и попробую разбить их на (1-3,4-5). Тогда мой последующий вопрос: является ли это «лучшей практикой» или я уже отклоняюсь от этого идеала с моей проблемой с самого начала? Также спасибо за ссылки на код, мне сложно найти такие полезные вещи!
Я не уверен, что здесь лучше всего, но, насколько я понимаю, есть два варианта - разделение вашей диаграммы или использование контейнеров инициализации, чтобы сделать ваш ресурс k8s идемпотентным. У обоих есть свои плюсы и минусы (в основном наличие более простых ресурсов k8s с менее сложной логикой при выборе разделения ваших диаграмм, но требует более сложной логики при применении диаграмм Helm и управлении выпусками). ИМХО я бы пошел с разбивкой графиков в вашем случае.
Хороший ответ и простое объяснение
Ссылка на исходный код v3 helm: github.com/helm/helm/blob/release-3.0/pkg/releaseutil/…
какой заказ типа List?
А если у меня есть другой вид, которого нет в этом списке, например SecretProviderClass?
@Alexsandro У меня в голове был тот же вопрос, и, похоже, здесь есть ответ: github.com/helm/helm/blob/…
Вы уже пробовали использовать многодокументный файл YAML? Многодокументный YAML - это упорядоченный список, но я не знаю, являются ли они применяемый в этом порядке. Я бы надеюсь на это, но я надеюсь на многое