KustomizeとHelmの比較

K8s は、コンテナ化されたアプリケーションの展開、スケーリング、管理を自動化するオープンソースのコンテナ オーケストレーション プラットフォームです。近年、K8s はクラウドネイティブ アーキテクチャとコンテナ化テクノロジーを採用する組織の標準となっています。

ただし、K8s の複雑さのため、使用しきい値を簡素化するためのツールが多数作成されています。ほとんどの企業が使用する2つのツールは、Kustomize（K8sの構成マネージャー）とHelm（K8sのパッケージマネージャー）です。

この記事では、Helm と Kustomize の機能、使用方法、およびこれらのツールの違いについて説明します。

Kustomize とは何ですか?

Kustomize は、k8s クラスターの構成カスタマイズ ツールです。これにより、管理者は元のマニフェスト ファイルに影響を与えずに、テンプレート以外のファイルを使用して宣言的な変更を加えることができます。

すべてのカスタム仕様は kustomization.yaml ファイルに含まれており、既存のマニフェストの上に仕様をオーバーレイして、リソースのカスタマイズされたバージョンを生成します。

たとえば、本番環境とテスト環境にデプロイする必要があるアプリケーションがあり、その YAML 構成がほとんど同じで、いくつかのフィールドのみが異なる場合は、kustomize を使用してこの問題を解決できます。

構造をカスタマイズする

Kustomize は共有の基本リソースとオーバーライドを使用して、再利用性と構成生成を実現します。 Kustomize プロジェクトの一般的なディレクトリ構造は次のとおりです。

写真

Kustomize プロジェクト構造は通常、ベース ディレクトリとオーバーライド ディレクトリで構成されます。上記の構造では、ベース ディレクトリに kustomization.yaml というファイルと共有リソースのマニフェスト ファイルが含まれています。

base/kustomization.yamlファイルは、すべての環境に含まれるファイルを宣言します。

Overlays ディレクトリには、ベース フォルダー内の yaml ファイルを参照し、カスタム変更を加えてパーソナライズされたリソースを構築する kustomization.yaml も含まれています。 Overlays ディレクトリには、Kustomize が環境固有のリソースを作成するために使用する個別の yaml ファイルも含まれています。

カスタム展開の例

次の一般的な例は、最小限の K8s デプロイメントに Kustomize を使用して、開発環境と本番環境にリソースをデプロイする方法を示しています。

事前依存関係

• k8s クラスター (1.14+)
• Kubectl クライアント

次のコマンドを使用して、サンプル Git リポジトリをクローンし、必要なマニフェストを作業環境にダウンロードします。

 git clone https://github.com/dongweizhao/kustomize-demo.git

写真

構造は次の通りです

写真

この例では、さまざまな環境での httpd の dp と svc の展開をシミュレートします。 dev は名前の前に dev- を追加し、prod は名前の前に prod- を追加し、base はデフォルト名 httpd を使用します。

1. ベース

resources: - deployment.yaml - service.yaml

1. 製品

bases: - ../../base namePrefix: prod-

1. 開発

bases: - ../../base namePrefix: dev-

展開する

cd base && kubectl apply -k .

実行が完了すると、次の結果が出力されます。

写真

注: kubectlはKustomizeを認識するために-kまたは--kustomizeフラグを使用します

前と同様に、以下に示すように、「/overlays/dev」フォルダーに移動してデプロイを実行します。

 cd overlays/dev && kubectl apply -k .

出力

写真

本番環境の導入

cd overlays/prod && kubectl apply -k .

出力

写真

検証

kubectl get pods|grep http

写真

kubectl get svc|grep http

写真

上記の結果から、設定が有効になっていることがわかります。

Helm とは何ですか?

Helm は、K8s 上でアプリケーションをパッケージ化、デプロイ、管理できるツールです。最も複雑な K8s アプリケーションの定義、インストール、アップグレードにも役立ちます。 Helm も CNCF の卒業プロジェクトです。

写真

Helmにおける以下の概念

Helm Charts: 事前設定された YAML テンプレート (ここでは Charts と呼びます)。K8s アプリケーションの YAML と構成を記述するために使用されます。

Helmクライアント: Helmと対話し、これらのチャートのバージョンを管理するためのコマンドラインインターフェース

Chart Warehouse: チャートを管理するウェアハウス。Maven の Nexus と同じです。たとえば、社内環境でチャートを構築してアップロードし、顧客のコンピュータルームの Chart Warehouse に接続してチャートをダウンロードし、k8s にデプロイすることができます。

Helm の例

事前依存関係

• k8s クラスター
• Kubectl クライアント
• ヘルムクライアント

Helm Charts は、事前構成された K8s リソース パッケージです。 Helm チャートには、K8s マニフェスト、環境変数、その他の構成など、特定のアプリケーションまたはサービスをデプロイするために必要なすべての情報が含まれています。

ディレクトリ名はチャートの名前です。 Helm のドキュメントに示されているように、 helm create helm-demo コマンドを使用して Chart を作成します。実行後、以下に示すように、nginxチャートがデフォルトで生成されます。

写真

チャート.yaml

現在のチャートのバージョンを定義し、現在のチャートの目的を説明します。 name パラメータは、後続のアップロードとダウンロードに使用されるチャート名を示します。

 apiVersion: v2 name: helm-demo description: A Helm chart for K8s # A chart can be either an 'application' or a 'library' chart. # # Application charts are a collection of templates that can be packaged into versioned archives # to be deployed. # # Library charts provide useful utilities or functions for the chart developer. They're included as # a dependency of application charts to inject those utilities and functions into the rendering # pipeline. Library charts do not define any templates and therefore cannot be deployed. type: application # This is the chart version. This version number should be incremented each time you make changes # to the chart and its templates, including the app version. # Versions are expected to follow Semantic Versioning (https://semver.org/) version: 0.1.0 # This is the version number of the application being deployed. This version number should be # incremented each time you make changes to the application. Versions are not expected to # follow Semantic Versioning. They should reflect the version the application is using. # It is recommended to use it with quotes. appVersion: "1.16.0"

値.yaml

変数パラメータはこのファイルで定義され、image.repositoryなどのYAMLテンプレートで参照され、以下に示すように.Values + 変数名を通じて参照されます。

写真

_helpers.tpl

共通コードブロックを定義し、yamlファイルはincludeを通じて参照される。

意味

{{- define "helm-demo.name" -}} {{- default .Chart.Name .Values.nameOverride | trunc 63 | trimSuffix "-" }} {{- end }}

参考文献

{{ include "helm-demo.fullname" . }}

テンプレート

このディレクトリには主にデプロイされる yaml ファイル テンプレートが格納され、_helpers.tpl ファイルも含まれています。テンプレートは、values.yamlとChart.yamlで定義されたパラメータと、_helpers.tplで定義された共通コードブロックを参照します。

写真

展開する

helm package helm-demo

写真

次のコマンドは、set を通じて 2 つのレプリカ ポッドのデプロイを指定します。このパラメータはvalues.yamlで定義されています

helm install helm-demo helm-demo-0.1.0.tgz --set replicaCount=2

写真

検証

2つのコピーが展開されていることがわかります

kubectl get pods|grep helm

写真

主な違い

操作方法

Kustomize は、ディレクトリ固有の kustomization.yaml ファイルを使用して、個々のリソースを構築し、変更を加えます。これらのファイルは、共有ベース フォルダーで宣言されたリソースにパッチとオーバーライドを適用し、自動化されたマルチ環境構成を提供します。

Helm はテンプレートを使用して、value.yaml ファイルを変数ソースとして参照し、有効な K8s 構成を生成します。テンプレート ディレクトリは、デプロイ中にリソースを作成するために Helm チャートが使用するファイルをホストします。

利便性

K8s バージョン 1.14 以降では、Kustomize は kubectl CLI にバンドルされているため、追加のツールを習得する必要はありません。 Kustomize は宣言型のデプロイメントをサポートし、各ファイルに純粋な YAML を使用するため、使いやすくなります。

Helm は、K8s パッケージ管理タスクに抽象化レイヤーを追加し、クラスター構成とリリースの自動化を簡素化したいチームの学習曲線を加速します。 Helm Chart は Kustomize よりも複雑ですが、より強力です。

パック

Kustomize にはパッケージ化機能がないため、各リソースはベース フォルダーで宣言し、バリアントはオーバーレイの kustomization.yaml ファイルで個別に宣言する必要があります。

Helm は必要なすべての K8s リソースを 1 つのフォルダーにパッケージ化し、必要に応じて再利用できるようにします。 Helm では、参照される yaml ファイルに挿入できる values.yaml ファイルを使用して、アプリケーションのデフォルトを設定したり、パラメータを変更したりすることもできます。

ネイティブ kubectl 統合

K8s バージョン 1.14 以降、Kustomize には kubectl がプリインストールされています。 Helm は K8s と事前に統合されていないため、Helm を手動でインストールする必要があります。

Kustomize vs. Helm - どちらを使うべきか

Kustomize を使用する場合

Kustomize を使用すると、元のファイルを変更せずに正確な変更を加えることができます。したがって、次のようなシナリオが考えられます

• アプリケーション構成のバリアント管理: Kustomize は、複数の環境 (開発、テスト、本番など) でアプリケーションのバリアントを管理する必要がある場合に適しています。異なる環境に対して異なる構成を作成し、基本構成を使用して共通部分を定義できます。
• 継続的インテグレーションと継続的デプロイメント (CI/CD) パイプライン: Kustomize は CI/CD ツールと統合して、デプロイメントの自動化に役立ちます。パイプラインで Kustomize を使用すると、必要に応じて環境固有の構成を生成し、クラスターに適用できます。

Helm を使用する場合

Helm はすべての K8s オブジェクトを 1 つのパッケージにカプセル化し、各 yaml ファイルとのやり取りを減らします。これ以外にも、ほとんどのサードパーティベンダーは、自社製品を K8s にデプロイするプロセスを簡素化するために、事前に構築された Helm チャートも提供しています。したがって、監視、データベース、メッセージング ミドルウェアなどの既成ソリューションをインストールする場合、Helm が最初の選択肢となることがよくあります。