Порядок подзаголовка руля в зонтичной диаграмме - PullRequest
0 голосов
/ 23 мая 2018

У меня есть зонтичная диаграмма с несколькими вложенными диаграммами, я просто хочу убедиться, что вложенная диаграмма 1 выполняется перед вложенной диаграммой 2 и т. Д. Как мы можем определить порядок выполнения вложенной диаграммы?

Похоже только на веса крюкаприменить относительно диаграммы, которая их объявляет.

Ответы [ 3 ]

0 голосов
/ 24 мая 2018

Вот часть документации Helm , относящаяся к порядку выполнения диаграмм:

В приведенных выше разделах объясняется, как указать зависимости диаграммы, но как это влияет на установку диаграммыиспользование установки helm и обновления helm?

Предположим, что диаграмма с именем "A" создает следующие объекты Kubernetes

пространство имен "A-Namespace"
statefulset "A-StatefulSet"
служба "A-Service"

Кроме того, A зависит от диаграммы B, которая создает объекты

пространство имен "B-Namespace"
репликационный набор "B-ReplicaSet"
служба "B-Сервис "

После установки / обновления диаграммы A создается / изменяется один релиз Helm.В этом выпуске будут созданы / обновлены все вышеперечисленные объекты Kubernetes в следующем порядке:

Пространство имен A
Пространство имен B
A-StatefulSet
B-ReplicaSet
A-Service
B-Service

Это происходит потому, что когда Helm устанавливает / обновляет диаграммы, объекты Kubernetes из диаграмм и все его зависимости объединяются в один набор;затем сортируется по типу с последующим именем;а затем создан / обновлен в этом порядке.
Следовательно, создается один выпуск со всеми объектами для диаграммы и ее зависимостями.

Порядок установки типов Kubernetes задается перечислением InstallOrder в kind_sorter.go (см. источник Helmfile ).

Часть helm / kind_sorder.go связана с диаграммами установки:

var InstallOrder SortOrder = []string{
    "Namespace",
    "ResourceQuota",
    "LimitRange",
    "PodSecurityPolicy",
    "Secret",
    "ConfigMap",
    "StorageClass",
    "PersistentVolume",
    "PersistentVolumeClaim",
    "ServiceAccount",
    "CustomResourceDefinition",
    "ClusterRole",
    "ClusterRoleBinding",
    "Role",
    "RoleBinding",
    "Service",
    "DaemonSet",
    "Pod",
    "ReplicationController",
    "ReplicaSet",
    "Deployment",
    "StatefulSet",
    "Job",
    "CronJob",
    "Ingress",
    "APIService",
}

Существует обходной путь, который может изменить поведение по умолчанию, общий доступ elementalvoid в этом выпуске :

Я устанавливал свои службы, секреты и конфигурационные карты в качестве предустановочных хуков для достижения этого поведения.

Пример:

apiVersion: v1
kind: Service
metadata:
  name: foo
  annotations:
    "helm.sh/hook": "pre-install"

-

Можно определить вес для крючка, который поможет построить детерминистический порядок выполнения.Весовые коэффициенты определяются с использованием следующей аннотации:

  annotations:
    "helm.sh/hook-weight": "5"

Весовые коэффициенты крючка могут быть положительными или отрицательными числами, но должны быть представлены в виде строк.Когда Tiller запускает цикл выполнения хуков определенного вида , он сортирует эти хуки в порядке возрастания.

Более подробную информацию о хуках можно найти здесь и в исходном файле hooks.go

0 голосов
/ 14 декабря 2018

Хотя вы не можете сделать заказ, вы можете использовать Init Containers для проверки того, что ваши Pod имеют все необходимое для запуска перед тем, как их запустить: https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

0 голосов
/ 23 мая 2018

Вы не можете сделать заказ, и я не думаю, что он вам понадобится.Вы можете полагаться на проверки работоспособности, поэтому, если одна диаграмма зависит от другой, она, вероятно, не будет работать и перезапустится, пока проверка работоспособности не пройдет.

...