HelmとKustomize：直接比較

はじめに

Kubernetesは、アプリケーションのデプロイを管理するために必要なコアツールをネイティブに提供します。ただし、生のYAMLマニフェストを適用するのは簡単なプロセスですが、マイクロサービス環境での開発は、システム全体をサポートするために必要な数のデプロイですぐに制御不能になります。

この記事では、アプリケーションのデプロイ管理を簡素化することを目的とした2つの一般的なツールであるHelmとKustomizeを比較します。

ヘルム：主な機能

HelmはKubernetesのパッケージマネージャーです。ヘルムチャート、Goテンプレート言語を使用して変更されたYAMLファイルを含むパッケージ、およびSprigライブラリのテンプレート関数を使用することで、Kubernetesアプリケーションのインストールと管理を支援します。

テンプレートと動的な値を採用することにより、Helmはソフトウェア開発ライフサイクル全体で構成を微調整する機能を提供します。

Helm 3の導入により、Helmは動的構成ファイルの生成をTillerに依存することをやめました。これにより、Helm 2の主なセキュリティ上の懸念の1つ、つまりTillerにアクセスできるすべての人にデフォルトで付与される幅広い権限が排除されます。 Helmは、役割ベースのアクセス制御（RBAC）とカスタムリソース定義（CRD）を備えた特権アクセス管理コンポーネントを備えています。

Helmテンプレートのもう1つの便利なプロパティは、カプセル化です。 Deployment、Service、ConfigMap、Kubernetes SecretなどのKubernetesオブジェクトのYAML定義は、単一のテンプレートにカプセル化できます。このプロパティは、デプロイ時の構成に役立ちます。

単純なヘルムチャートは次のもので構成されます：

Chart.yaml チャートを宣言するファイル。
values.yaml テンプレートで使用するチャートパラメータを含むファイル。
チャートのコンテンツを作成するためのテンプレートファイルを含むテンプレートディレクトリ。

テンプレートファイルはYAMLファイルの構造を持っていますが、デプロイ時に values.yamlで提供される値に置き換えられるテンプレート変数も含まれていますファイル。

これは、典型的な deployment.yamlの内容です。次のようになります：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.test }}
  labels:
    app: {{ .Values.test }}
spec:
  selector:
    matchLabels:
      app: {{ .Values.test }}
  template:
    metadata:
      labels:
        app: {{ .Values.test }}
        tier: web
    spec:
      containers:
      - name: {{ .Values.test }}
        image: {{ .Values.test }}     
        ports:
        - containerPort: 8080

上記の例では、Helmは values.yamlを調べます testの値のファイル 変数。関連するvalues.yaml ファイルには変数定義が含まれています：

test: default

values.yamlに基づく定義では、Helmは次の deployment.yamlをビルドしますファイル：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: default
  labels:
    app: default
spec:
  selector:
    matchLabels:
      app: default
  template:
    metadata:
      labels:
        app: default
        tier: web
    spec:
      containers:
      - name: default
        image: default     
        ports:
        - containerPort: 8080

Helmは、 values.yamlの値をオーバーライドする機能を備えています --setを使用する CLIでビルドコマンドを発行するときにフラグを立てます。

helm lintも含まれています チャートに問題がないか調べ、標準に従って設計されていることを確認するコマンド。

Kustomize：主な機能

Kustomizeは、テンプレートの代わりにレイヤーとパッチを使用してKubernetesオブジェクトをカスタマイズするツールです。 kustomization.yamlを紹介しますマニフェストファイル。ユーザーはデプロイメント固有の構成を保存します。

このツールはバージョン1.14の時点でkubectlに組み込まれています。つまり、Kubernetesでネイティブになっています。ただし、個別にインストールすることもできます。

Kustomizeを使用すると、ユーザーは宣言型アプローチを使用して、それぞれ独自のカスタマイズを使用して、任意の数のKubernetes構成を管理できます。これにより、開発者はアプリケーションの複数のバージョンを定義し、それらをサブディレクトリで管理できます。ベースディレクトリには一般的な構成が含まれ、サブディレクトリにはバージョン固有のパッチが含まれます。

各ディレクトリには、その kustomization.yamlが含まれています構成に加える必要のある変更と、使用する必要のあるリソースを指定するファイル。たとえば、次の kustomization.yaml ファイルは共通のラベルを追加しますapp:test 両方のdeployment.yaml およびservice.yaml ベースディレクトリ内：

commonLabels:  
  app: my-wordpress
resources:
- deployment.yaml
- service.yaml

次に、コマンドラインに次のコマンドを入力して変更を適用します。

kubectl apply -k base

Kustomizeをスタンドアロンツールとして使用する場合、コマンドは異なります。

kustomize build base | kubectl apply -f -

HelmとKubernetes：長所と短所

長所

Helmは、パッケージ化、フック、ロールバックなど、単純なアプリ展開構成管理を超える多くの機能を提供します。
ユーザーがデフォルトを設定できるようにすることでアプリのインストールを簡素化し、必要に応じて値を使用してさらに構成できるようにします。
Helmは開発者によく知られており、多くのユーザーと優れたオンラインサポートがあります。
Helmテンプレート関数を使用すると、条件とループを導入したり、ヘルパーを定義したり、Sprig関数ライブラリにアクセスしたりできます。
最も一般的に使用されるアプリケーションでは、Helmチャートをオンラインで利用できるため、時間を節約し、生産性を向上させることができます。

短所

ヘルムはより多くの抽象化レイヤーを追加し、急な学習曲線を持っています。
アプリケーションのカスタマイズを既存の構成オプションに制限します。
テンプレートは、特にYAMLの適切な配置に関して、エラーが発生しやすくなります。
HelmはKubernetesでネイティブにサポートされていないため、外部依存関係が作成されます。
それはしばしば必須です。 Helmは実行時に値をテンプレートに挿入するため、テンプレートが変更されると、システムがユーザーの期待とは異なる場合があります。
グラフは依然として実行時のカスタマイズが必要であるため、CI/CDパイプラインを実装する際の管理が困難です。
読みにくいテンプレートは、必然的に時間の経過とともにカスタマイズ性が低下します。
アプリのインストール中の可視性と透明性の欠如に起因するセキュリティの問題に悩まされています。

KustomizeとKubernetes：長所と短所

長所

Kustomizeは簡単に使用できます。
これは宣言型であり、Kubernetesの哲学に沿っています。
Kustomizeは継承ベースモデルをサポートしているため、Helmよりも拡張性が高くなります。
kubectlに統合されたネイティブバージョンを使用すると、外部の依存関係がなくなります。
既成のアプリを使いやすくします。
プレーンなYAMLファイルのみを使用します。

短所

Kustomizeは多くの機能を提供していません。
DRY（Do n’t Repeat Yourself）の原則に従うようには設計されていません。
ユーザーはkustomization.yamlでリソースとパッチを手動で宣言する必要があります、および新しいファイルが追加されるたびにファイルを手動で更新する必要があります。
kubectlに組み込まれているネイティブバージョンは、現在のスタンドアロンバージョンよりもはるかに古いものです。
Kustomizeのオンラインサポートを見つけるのは困難です。

Kustomize vs Helm：比較表

機能	ヘルム	Kustomize
テンプレート	はい	いいえ
オーバーレイ	いいえ	はい
パッケージング	はい	いいえ
検証フック	はい	いいえ
ロールバック	はい	いいえ
ネイティブK8s統合	いいえ	はい
宣言型の性質	ほとんどの場合必須	はい
可視性と透明性	弱い	強い

選択方法

HelmとKustomizeのどちらを選択するかを決定するには、次のことを考慮してください。

すべての構成を自分で作成することを計画していて、YAMLがどのように機能するかを十分に理解している場合は、Kustomizeを選択します。 Kustomizeを使用すると、複雑なカスタマイズをすばやく実行できますが、パッチとレイヤーがどのように組み合わされているかを視覚化できる必要があります。
一方、開発者が安全で簡単な方法で新しいアプリやサービスを追加できるようにする場合は、Helmチャートを作成することをお勧めします。
Helmを選択するもう1つの理由は、YAMLファイルで費やす時間を減らす必要があることです。 Helmテンプレートには、YAMLを深く掘り下げることなく、サービスがどのように機能するかを簡単に理解できるようにする引数があります。

HelmとKustomizeの両方がツール固有の利点を提供し、互いに補完し合うことを考えると、最善の行動は2つのツールを並べて使用することです。 Helmは、明確に定義されたアプリのパッケージ化、共有、インストールに特に役立ちますが、Kustomizeは、既存のKubernetesアプリの直前の変更に最適です。