Helmとは

Helmでは、数十もの個別の設定ファイルを手作業で作成・管理する代わりに、アプリケーションに必要なすべてを「Helmチャート」と呼ばれる再利用可能な単一パッケージにまとめます。

Kubernetesとは、複数のサーバー間でコンテナ化されたアプリケーションのデプロイメントと運用を自動化するオープンソースのプラットフォームです。Kubernetesは強力ですが、アプリケーションの実行方法や接続方法、必要なリソースを指定する詳細な設定をYAMLファイルで記述する必要があり、作業が煩雑になることがあります。

これらの設定を開発者、システム管理者、DevOpsエンジニアが手作業で管理することは、特に開発、試験、本番といった複数の環境にまたがる場合、非常に時間がかかり、ミスが発生しやすくなります。Helmは、ロールバックや環境ごとのカスタマイズ機能などを備え、標準化、再利用性、バージョン管理を導入することで、この課題に対応します。

Helmを理解する前に、Kubernetesや最新のクラウドネイティブ・ツールの基盤であるコンテナ化を理解することが重要です。

コンテナ化とは、アプリケーションを実行するために必要なコード、ライブラリ、設定などをすべてまとめ、コンテナと呼ばれる軽量で持ち運び可能な単位にパッケージ化することです。この機能により、ソフトウェアは開発者のノートパソコンから本番クラウド環境に至るまで、さまざまな環境で一貫して実行できるようになります。

コンテナは通常、Linuxをベースに構築されており、従来の仮想マシンよりも高速で効率的に動作します。また、コンテナはマイクロサービス・アーキテクチャーにも適しており、アプリケーションを小さく独立してデプロイ可能なコンポーネントに分割し、必要に応じてスケールさせることができます。Kubernetesでは、これらのコンテナ化されたワークロードはクラスター上で実行されます。クラスターは、システムを管理するコントロールプレーンと、インフラストラクチャー全体でアプリケーションを実行するワーカー・ノードから構成される複数のマシンの集合です。

Dockerは、2013年に公開されたオープンソース・プラットフォームで、最も広く利用されているコンテナ化ツールです。現在、コンテナ化はオープンソースのクラウド・ネイティブ・エコシステムの中核を成しており、より迅速な開発、より信頼性の高いデプロイメント、そしてより大きな運用の柔軟性を可能にしています。

Kubernetesは、コンテナのデプロイメント、スケーリング、リソース管理を自動化することで、大規模なコンテナ運用をオーケストレーションします。しかし、Kubernetesの設定を直接管理することは複雑で、エラーが発生しやすくなります。Helmは、コンテナ化されたアプリケーションのデプロイメントと保守を簡素化、標準化、効率化することで、ここで重要な役割を果たします。

Deis（後にMicrosoft社が買収）は、Kubernetesアプリケーション管理を簡素化する最初期のツールの1つとして、2016年にHelmを開発しました。2018年、チームはこのプロジェクトをCloud Native Computing Foundation（CNCF）に寄贈し、2020年に正式なCNCFプロジェクトとして認定されました。

Helmのオープンソース開発はGitHub上で積極的に維持されており、世界中の貢献者がその進化に協力しています。公式サイト（helm.sh）では、包括的なドキュメント、ダウンロード、リソースが提供されており、ユーザーが利用を開始し、最新情報を把握するのに役立つでしょう。

重要な節目として、2019年末にHelm 3がリリースされました。このバージョンではHelm 2のTillerコンポーネントが削除され、Kubernetesのアプリケーション・プログラミング・インターフェース（API）と直接やり取りすることで、セキュリティーが向上しアクセス制御が簡素化されました。Helm 3では、アップグレード・プロセス、依存関係管理、ライブラリー・チャートのサポートも強化され、企業での利用においてよりセキュリティーが高く、柔軟で使いやすくなりました。

Helmはクラウドネイティブ・エコシステム全体で大規模に採用されています。最近のCNCFの調査によると、HelmはKubernetesパッケージ・マネージャーとして最も支持されており、Kubernetesを運用する組織の75％が採用しています。¹

Artifact Hub（元のHelm Hubに代わるもの）には数千のチャートが掲載されており、大手ソフトウェアベンダーはHelmチャートを主要なKubernetes配布方法として定期的に提供しています。

Helmは、Kubernetesのマニフェスト（構成ファイル）、構成テンプレート、メタデータをまとめ、Helmチャートと呼ばれる再利用可能なパッケージにすることで、Kubernetesアプリケーションの管理を簡素化します。これらのチャートには、アプリケーションを構成するKubernetesリソース（デプロイメント、サービス、Ingressコントローラー、永続ボリューム、ConfigMap、シークレットなど）に対応する適切なYAMLファイルを生成するために必要なすべての仕様が含まれています。

「YAML」は、「YAML Ain't Markup Language（YAMLはマークアップ言語ではない）」または「Yet Another Markup Language（また別のマークアップ言語）」の略です。これは、人間にとって読みやすいデータ形式で、構成ファイルの作成に使用されます。情報を明確かつ構造化された方法で表現できるため、人間とプログラムの両方が読み取ることができます。

チャートがインストールされると、Helmはこれらのリソースを対象のKubernetesクラスターに自動的に適用し、バージョニングやロールバック、依存関係管理もあわせて実行します。

Helmは主にクライアント側ツールとして動作し、KubernetesのAPIサーバーと直接やり取りしながらアプリケーションのデプロイメントを管理します。

• Helmクライアント
• Helmチャート
• Helmリリース
• Helmリポジトリー

Helmクライアントは、Kubernetesクラスターとやり取りし、チャートやリリースを管理するコマンドライン（CLI）ツールです。このツールは、開発者や運用担当者が日常的に使用するものです。Kubernetesのネイティブ・コマンド・ツールであるkubectlとは異なり、Helmは個々のコンポーネントではなく、アプリケーション全体を管理します。

Helmチャートは、Kubernetes上でアプリケーションを実行するために必要なすべてのリソース定義を含むパッケージ形式です。チャートには、テンプレート、デフォルトの構成値、およびメタデータが含まれます。

Helmリリースは、Kubernetesクラスター上で実行されているチャートのインスタンスです。各リリースには固有の名前があり、個別に管理できます。

Helmリポジトリーは、チャートを共有・配布できるコレクションで、他のエコシステムにおけるアプリストアやパッケージ・ライブラリーに似ています。

Helmチャートは、関連するKubernetesリソースのセットを記述したファイルのコレクションです。チャートの構造には以下が含まれます。

• Helmテンプレートは、構成可能なパラメーターを使用して、開発・試験・本番などさまざまなデプロイ環境に対応するテンプレート化されたKubernetesマニフェストです。

• 値ファイル（values.yaml）は、異なるデプロイメントで上書きできるデフォルトの構成値です。値はYAML形式またはJSON形式で指定できます。

• グラフのメタデータ（chart.yaml）には、チャートの名前、バージョン、apiVersion、依存関係、管理者が記載されています。

• ドキュメントには、ユーザーがチャートのデプロイ方法や運用方法を理解できるよう、readmeファイル、クイックスタート・ガイド、使用手順などの人間向けの内容が含まれます。

Kubernetesの開発者、システム管理者、その他の企業組織における IT オペレーション（ITOps） の専門家は、Helmを使用して次のようなタスクを実行します。

• 運用効率
• リスク緩和
• ガバナンスとコンプライアンス
• 開発者の生産性

Helm は、Kubernetesのデプロイメント管理に伴う運用上の複雑さを大幅に軽減します。Helmは構成管理を自動化・標準化することで、複雑でミスが起こりやすい手動のYAML編集を伴うワークフローを効率化します。

この効率性は、組織がクラウドネイティブ環境を拡張し、人工知能（AI）や機械学習（ML）のワークロード、エッジ・コンピューティングなどの新興テクノロジーを導入する際に特に重要になります。

Helmの組み込みのロールバック機能は、本番環境へのデプロイメントにおいて重要な安全策を提供します。アップグレードが失敗したり問題が発生した場合でも、チームは単一のコマンドで前の正常に動作していたバージョンに即座に戻すことができます。この機能により、デプロイメント関連のインシデントにおける平均復旧時間（MTTR）が短縮されます。これは、高可用性アプリケーションやリアルタイムのAI推論サービスにとって不可欠な要件です。

Helmチャートやスキーマは、他のソフトウェア成果物と同様に、バージョン管理やコード・レビューが可能です。この方法により、デプロイの監査証跡を残すことができ、変更が適切な承認プロセスを経ることを保証します。多くの組織では、HelmをGitOpsワークフローと組み合わせて利用し、ガバナンスを強化しています。これにより、クラウドネイティブ・アーキテクチャーを採用する規制対象の業界のコンプライアンス要件を満たすことが可能になります。

HelmはKubernetesの複雑さを抽象化することで、開発者がインフラ構成ではなくアプリケーションのロジックに集中できるようにします。チームは事前に承認されたチャートを使用したデプロイメントをセルフサービスで実行できるため、プラットフォーム・チームへの依存を減らし、競争力のあるAIやデジタル・トランスフォーメーションの取り組みに必要な開発のスピードを加速できます。

• アプリケーション・ライフサイクル管理
• サードパーティー製ソフトウェアのデプロイメント
• マルチテナント環境
• CI/CDの統合とスケーリング
• AI/MLおよびGPUワークロード

Kustomizeは、Kubernetes構成を管理するために広く採用されているもう1つのソリューションですが、Helmとは異なるアプローチを取ります。Helmがテンプレートを使用してマニフェストを生成するのに対し、Kustomizeはパッチやオーバーレイを用いた宣言型のアプローチによってベース構成を変更します。

Kustomizeはよりシンプルで学習コストも低い一方で、Helmのようなパッケージ管理機能やバージョニング、ロールバック機能を備えていません。多くの組織は両方のツールを併用しており、Kustomizeで構成のバリエーションを扱い、Helmでアプリケーション全体のライフサイクルを管理しています。

Kubernetesオペレーターは、複雑なアプリケーションを管理するためにKubernetes APIを拡張するアプリケーション固有のコントローラーです。Helmがパッケージ化とデプロイメントに重点を置くのに対し、オペレーターは継続的なライフサイクル管理を提供します。オペレーターは、バックアップ、スケーリング、アップグレードといったアプリケーション固有の運用タスクを処理できます。

Helmは、一般的なアプリケーションのデプロイメントやシンプルなワークロードにより適しています。同時に、オペレーターは複雑な運用要件を持つステートフル・アプリケーションの管理に優れています。多くの組織は、オペレーター自体のデプロイメントにHelmを利用しています。