web-dev-qa-db-ja.com

アンブレラチャートでのヘルムサブチャートの実行順序

複数のサブチャートを含むアンブレラチャートがあります。subchart1がsubchart2などの前に実行されるようにするだけです。サブチャートの実行順序を定義するにはどうすればよいですか。

フックの重みは、それらを宣言するチャートに対してのみ適用されるようです。

11
Z Y .

以下はHelmの一部です ドキュメント チャートの実行順序に関連しています:

上記のセクションでは、チャートの依存関係を指定する方法について説明しましたが、これはhelmインストールおよびhelmアップグレードを使用したチャートのインストールにどのように影響しますか?

「A」という名前のチャートが次のKubernetesオブジェクトを作成するとします。

名前空間「A-Namespace」
statefulset "A-StatefulSet"
service "A-Service"

さらに、Aはオブジェクトを作成するチャートBに依存しています

名前空間「B-Namespace」
replicaset "B-ReplicaSet"
service "B-Service"

チャートAのインストール/アップグレード後、単一のHelmリリースが作成/変更されます。このリリースでは、上記のすべてのKubernetesオブジェクトを次の順序で作成/更新します。

名前空間
B名前空間
A-StatefulSet
B-レプリカセット
サービス
Bサービス

これは、Helmがチャートをインストール/アップグレードすると、チャートのKubernetesオブジェクトとそのすべての依存関係が単一のセットに集約されるためです。次に、タイプ、名前の順にソートされます。そして、その順序で作成/更新されます。
したがって、チャートのすべてのオブジェクトとその依存関係を含む単一のリリースが作成されます。

Kubernetesタイプのインストール順序は、kind_sorter.goの列挙InstallOrderによって指定されます( The Helm source file を参照)。

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",
}

この issueelementalvoidによって共有されるデフォルトの動作を変更できる回避策があります。

この動作を実現するために、サービス、シークレット、および構成マップをインストール前のフックとして設定しています。

例:

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

-

決定的な実行順序の構築に役立つフックの重みを定義することができます。重みは、次の注釈を使用して定義されます。

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

フックの重みは正または負の数値にすることができますが、文字列として表現する必要があります。 Tillerが特定の種類のフックの実行サイクルを開始すると、それらのフックは昇順にソートされます。

フックに関する詳細情報は here およびソースファイル hooks.go にあります。

7
VAS

注文することはできませんし、必要になるとは思いません。ヘルスチェックに頼ることができるので、あるチャートが別のチャートに依存している場合、ヘルスチェックに合格するまで失敗して再起動する可能性があります。

3
Alen Komljen

注文を行うことはできませんが、Init Containersを使用して、実際に実行する前に実行する必要があるすべてのポッドをPodで検証できます。 https://kubernetes.io/docs/concepts/workloads/pods/init-containers /

3
tal952