伞形图中的Helm Subchart执行顺序 [英] Helm Subchart order of execution in an umbrella chart

问题描述

我有一个包含多个子图的总括图，我只是想确保subchart1在subchart2之前运行，等等.我们如何定义子图的执行顺序?

I have an umbrella chart with multiple sub-charts, I simply want to make sure that subchart1 runs before subchart2, etc. How can we define the order of subchart execution?

像权重之类的东西似乎仅适用于声明它们的图表.

Seems like hook-weights only apply relative to the chart that declares them.

推荐答案

以下是Helm的一部分

Here is a part of the Helm documentation related to execution order of charts:

以上各节说明了如何指定图表依存关系，但如何 这会影响使用helm install和helm的图表安装吗 升级?

The above sections explain how to specify chart dependencies, but how does this affect chart installation using helm install and helm upgrade?

假设一个名为"A"的图表创建了以下Kubernetes 对象

Suppose that a chart named "A" creates the following Kubernetes objects

命名空间"A-命名空间"
statefulset"A-StatefulSet"
服务"A服务"

namespace "A-Namespace"
statefulset "A-StatefulSet"
service "A-Service"

此外，A依赖于创建的图表B 对象

Furthermore, A is dependent on chart B that creates objects

命名空间"B-命名空间"
复制集"B-ReplicaSet"
服务"B服务"

namespace "B-Namespace"
replicaset "B-ReplicaSet"
service "B-Service"

安装/升级图表后，将发布单个Helm版本 创建/修改.该版本将创建/更新以上所有内容 Kubernetes对象的顺序如下:

After installation/upgrade of chart A a single Helm release is created/modified. The release will create/update all of the above Kubernetes objects in the following order:

名称空间
B命名空间
A-StatefulSet
B-ReplicaSet
A服务
B服务

A-Namespace
B-Namespace
A-StatefulSet
B-ReplicaSet
A-Service
B-Service

这是因为当Helm安装/升级图表时，Kubernetes 图表中的对象及其所有依存关系被聚集到一个集合中；然后按类型排序，再按名称排序； 然后以该顺序创建/更新.
因此，将创建一个包含图表的所有对象及其依赖项的单个发行版.

This is because when Helm installs/upgrades charts, the Kubernetes objects from the charts and all its dependencies are aggregrated into a single set; then sorted by type followed by name; and then created/updated in that order.
Hence a single release is created with all the objects for the chart and its dependencies.

Kubernetes类型的安装顺序由枚举给出 kind_sorter.go( Helm v2源文件 Helm v2源文件).

The install order of Kubernetes types is given by the enumeration InstallOrder in kind_sorter.go (Helm v2 source file).

kind_sorter.go的一部分( Helm v3源)与安装图表有关:

Part of kind_sorter.go (Helm v3 source) is related to install charts:

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

有一个变通办法，可以更改默认行为，由 elementalvoid 在此问题:

There is a workaround, that can change the default behaviour, shared by elementalvoid in this issue:

我已经将我的服务，机密和configmap设置为预安装 钩子来实现此行为.

I've been setting my services, secrets, and configmaps as pre-install hooks to achieve this behavior.

示例:

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

-

可以为钩子定义一个重量，这将有助于构建一个钩子. 确定性的执行顺序.权重使用以下定义 注释:

It is possible to define a weight for a hook which will help build a deterministic executing order. Weights are defined using the following annotation:

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

挂钩重量可以为正数或负数，但必须为 表示为字符串.当蒂勒开始执行的周期 特定种类的钩子将按升序对这些钩子进行排序 订单.

Hook weights can be positive or negative numbers but must be represented as strings. When Tiller starts the execution cycle of hooks of a particular Kind it will sort those hooks in ascending order.

有关钩子的更多详细信息，请参见此处( v2 doc ， v3 doc )和源文件中(头盔v2源，

More detailed information about hooks can be found here (v2 doc, v3 doc) and in the source file (helm v2 source, helm v3 source)

这篇关于伞形图中的Helm Subchart执行顺序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！