Helm vs Terraform：Kubernetes管理に最適なツールの選び方

コンテナ化の普及に伴い、Kubernetes（K8sまたはkube）クラスタを効率的に管理、スケジュール、制御する必要性が高まりました。K8s環境とインターフェースするためのツールは市場に多数ありますが、HelmとTerraform以上の機能を提供する選択肢は多くありません。

本記事では、HelmとTerraformの直接比較を行います。両プロビジョニングツールの長所と短所を分析し、K8sセットアップの管理における機能を説明し、開発チームに適したオプションの特定を支援します。

Terraform：主な特徴

TerraformはオープンソースのInfrastructure as Code（IaC）ツールで、チームがインフラストラクチャ、プラットフォーム、サービスを管理および自動化できるようにします。このツールは、コードを通じてインフラストラクチャの構築、変更、バージョン管理を支援し、エンジニアが迅速かつ容易に以下を実行できるようにします：

• 仮想マシンとコンテナの起動
• サーバーのセットアップ
• セキュリティスキームとコントロールの作成
• ユーザーの追加・削除と権限設定
• クラウドリソースの管理
• Dockerコンテナのインストールと管理

2017年、Terraformの開発元HashiCorpがKubernetesプロバイダのリリースを発表しました。その結果、必要な数のクラウドプロバイダ間でK8sクラスタを管理する機能がツールに追加されました。

Terraformは、インフラストラクチャのプロビジョニングやKubernetesの管理時に宣言型言語を使用します。エンジニアはインフラストラクチャのセットアップ手順をすべて定義する必要はありません。代わりに、開発者はセットアップの望ましい最終状態を提供し、ツールが環境をプロビジョニングする方法を計画します。例えば、VM、K8sクラスタ、VPC、特定のファイアウォールの引数セットを、プロビジョニング手順を提供せずに記述できます。

宣言型設定ファイルは、チームが以下を行うのに役立ちます：

• インフラストラクチャ変更時に命令を編集せずにファイルを簡単に調整
• ファイルをきれいで短く保つ
• セットアップを迅速に編集
• 設定ファイルを見るだけで現在の構成を把握

エンジニアがプロビジョニングをリクエストすると、コマンドterraform planがツールに既存のセットアップ（初日なら何も存在しない状態）と比較させ、望ましいインフラストラクチャをセットアップする方法を計画させます。terraform applyコマンドが、クラウドプロバイダのAPIを通じてリソースを起動します。

TerraformはDevOpsチームに人気があり、エンジニアはCI/CDパイプライン全体で環境を迅速に起動および編集するためにこのツールを使用できます。

Terraformの主な機能

• インフラストラクチャとデプロイを単一ツールで管理できるKubernetesプロバイダ
• 宣言型言語を使用
• IaCアプローチにより、エンジニアがインフラストラクチャを他のコードと同様に記述、扱い、バージョン管理可能
• クラウドプロバイダのAPIと連携してスムーズで効果的、安全なプロビジョニングを実現
• パブリック、社内プライベート、ハイブリッド、マルチクラウドを問わず、あらゆるクラウドベースのセットアップで動作
• サーバーを変更する代わりに置き換える不変インフラストラクチャ（このアプローチにより運用が簡素化され、エラー、脅威、構成ドリフトが減少）
• changesetsをインフラストラクチャに自動適用してリソースを節約し、エラーを回避
• 現在の状態と望ましい状態の差分を常に表示する高度なドリフト検出機能
• プラグイン可能な設計により、チームがセットアップをカスタマイズし機能を追加可能
• リソース間の関係を理解し、スケジューリングに役立ち、バグを最小限に抑制。すべてのリソースのグラフを構築可能

Helm：主な特徴

Helmは、クラスタへの繰り返し可能なアプリとサービスのデプロイに最適なKubernetesパッケージマネージャーです。このツールを使用すると、ユーザーはHelm Chartsを通じてアプリを管理でき、K8s環境の定義、インストール、アップグレードが簡素化されます。

Helm Chartsは、Kubernetesマニフェストファイルに変換されるファイルとテンプレートのパッケージです。チャートは再利用可能で、以下のYAMLベースのテンプレートを含めることができます：

• さまざまなデプロイメント
• ConfigMaps
• サービス

さらに、チャートを依存関係として定義したり、より柔軟性を持たせるためにチャートをネストしたりできます。チャートの管理は単一のコマンドラインインターフェース（CLI）を通じて行われ、運用が簡素化されます。ほとんどのチャートは公開されていますが、企業は社内専用のカスタムチャートを作成することがよくあります。

Helmはシンプルなアーキテクチャを持ち、クライアントとクラスタ内のTillerサーバーで構成されます：

• Helm Clientは、ユーザーがHelm Chartsを操作し、Tillerサーバーとやり取りするためのCLIを提供。クライアントを使用して、チャートのインストール、アップグレード、ロールバックなどのさまざまな操作を実行可能。
• Tiller Serverはクラスタ内で動作し、K8s APIサーバーとやり取りしてKubernetesリソースのインストール、アップグレード、削除を行う。

Helmには、以下のような多くのメリットがあります：

• K8sマニフェストを異なる環境でデプロイおよび管理
• 複雑なアプリケーションをまとめてパッケージ化
• 複数のオブジェクトをまとめてロールバックまたはアップグレード
• セットアップパラメータを迅速に変更
• 単一コマンドで複数の環境にデプロイ

Helmとそのテンプレートエンジンは、K8sリソースに依存するCI/CDプロセスに最適です。マイクロサービスごとにファイルを編集する代わりに、エンジニアは標準的なブループリントを定義し、動的な値のプレースホルダーを使用できます。チームはチャートを作成し、同じアプリを1つのコマンドで異なるクラスタに再デプロイできます。

Helmの主な機能

• Helm Chartsを使用：インフラストラクチャの迅速なプロビジョニングとKubernetesリソースの管理のための再利用可能なテンプレート
• シンプルなクラスタ管理：アプリケーションの依存関係の処理とインスタンスのデプロイが容易
• クラスタ内にインストールされるTillerサーバーにより、ユーザーがKubernetes APIと直接インターフェース可能
• 継続的なリリースを追跡可能
• 複数のオブジェクトをまとめてロールバックまたはアップグレード可能
• チャートのシンプルなアップグレードとアンインストールプロセス
• プライベート、パブリック、ハイブリッドクラウドでのコンテナ管理をサポート

TerraformとKubernetes：長所と短所

TerraformのKubernetesプロバイダには多くのメリットがありますが、Helmと比較するとまだ比較的新しい機能です。時折発生するバグと一部機能の欠如が課題をもたらします。

Terraformの長所

• インフラストラクチャとクラスタ管理に同じツールとコードベースを使用可能
• 開発者はKubernetesアーキテクチャのプロビジョニングとクラスタへのアプリデプロイに同じ言語を使用可能
• リソーススケジューラをプロバイダとして設定可能
• アクションの結果を変更適用前に確認できる計画フェーズがある
• TerraformのKubernetesプロバイダは強力なコミュニティの支援を受けており、K8sの問題解決は通常数回のGoogle検索で可能
• Terraformに精通したチームなら、Kubernetesクラスタの管理を簡単かつ迅速に習得可能

Terraformの短所

• TerraformのKubernetesプロバイダはまだ比較的新しい
• ベータオブジェクトのサポート不足により、K8sクラスタ内のアプリとリソースの管理が複雑に。ベータリソース（daemonset、statefulsetなど）を扱う場合、Terraformの導入は困難
• 複数のモジュールがプロバイダベースの依存関係を持つ場合、管理が困難
• Google Kubernetes Engine（GKE）への完全なサポートなし
• K8sクラスタ内にコンポーネントをインストールしないため、実行中のPodのリアルタイム管理ができない

TerraformとKubernetesの詳細と違いについては、記事「Terraform vs Kubernetes」を参照してください。

HelmとKubernetes：長所と短所

Terraformと同様に、Helmも多くのK8sメリットを提供しますが、ツールのKubernetes機能はすでによく確立されています。しかし、企業はHelmを使用する際のいくつかの短所も考慮すべきです。

Helmの長所

• HelmのK8sサポートは成熟しており機能が豊富で、ツールの導入がスムーズ
• さまざまなアプリとサービス向けの便利なチャートを豊富に揃えた事前構築リポジトリ
• 再利用可能なチャート、インプレースアップグレード、アップデート用のカスタムフックにより、複雑なアプリの管理が簡素化
• TillerサーバーがK8sクラスタ内で動作し、直接APIコールを通じて機能
• Tillerによりランタイムリソースを効率的に管理可能
• ロールバックがシンプルで扱いやすい
• 高度な構造（フロー制御、パイプラインなど）により柔軟なデプロイテンプレートを実現
• 変数を定義し、異なる環境とクラスタでアプリをデプロイ可能
• Helm Chartsの柔軟性により、チームがKubernetesでテンプレートを標準化可能
• 豊富なユーザーコミュニティと業界大手（Microsoft、Google、Bitnami）からのサポート

Helmの短所

• HelmはTerraformより管理が複雑で、K8sセットアップにおいて相当な責任を伴う
• ツールの経験がないチームにとって、Helmの習得には時間がかかる
• プロジェクトごとに新しいイメージを作成する必要があり、コマンド実行時の混乱を防ぐ
• VM容量がコンテナのスケーラビリティにとって重要

Helm vs Terraform：比較表

HelmとTerraformには多くの類似点があり、両オープンソースツールともエンジニアが以下を可能にします：

• K8sオブジェクトをコードとして記述および維持
• さまざまなレベルと環境で変数を使用および上書き
• 複数のソース（ローカルディレクトリ、gitリポジトリなど）からインストール
• アクションの結果を実行前に確認するドライランを設定（Helmは--dry-runフラグ、Terraformはplanサブコマンド）
• 厳選されたパッケージリストにアクセス
• 活発なユーザーコミュニティから支援を受ける
• すべての主要クラウドプロバイダのサポートを享受

似ていますが、2つのツールには異なるユースケースに適した違いがあります。以下の表は、TerraformとHelmの主な違いを示しています。

Terraform	Helm
比較的新しいKubernetesプロバイダ（だが急速に改善中）	試行錯誤で実証済みのK8s機能を持つ成熟したツール
Kubernetesクラスタ内に何もインストールしない	クラスタ内にTillerサーバーをインストールし、K8s APIと接続
Kubernetesクラスタをインストール可能	Kubernetesクラスタをインストール不可
モジュールでモジュール性を実現	サブチャートでモジュール性を実現
JSON/HCLファイル形式でKubernetesオブジェクトを記述・維持	標準K8sマニフェストとGoテンプレートでK8sオブジェクトを記述・維持
ベータリソースのサポート不足により、既存環境へのTerraform移行が複雑	K8sサポートがより成熟しており、ツール導入がより簡単
ランタイムでのオプションが限定的	Tillerがランタイムで多くの機能を提供
環境変数をサポート	環境変数のオプションが限定的
レジストリにKubernetesで動作するTerraformモジュールなし	StableとIncubatorチャートが豊富なパッケージセットを提供
Kubernetesプロバイダはカスタムリソースをまだ処理できない	カスタムリソースを管理可能
複雑なロールバックだがリソースは少ない	ロールバックは簡単だがより多くのリソースを必要とする

HelmとTerraform：併用する

HelmとTerraformは相互排他的ではなく、同じK8sセットアップで両ツールを使用できます。両プラットフォームには広範な機能があるため、エンジニアは以下のようにできます：

• Terraformを使用してHelmリソースを作成および管理
• Terraform内でHelmを使用してクラスタ関連アプリケーションをデプロイ
• Terraformで事前プロビジョニングされたKubernetesクラスタにHelmチャートをデプロイ

両ツールに依存するほとんどのチームは、TerraformでK8sクラスタを処理し、Helmでクラスタに入るリソースを管理する傾向があります。ただし、両プラットフォームを使用するとプロジェクトが複雑になるため、マルチツール環境を構築する前に1つのプラットフォームに頼ることを検討してください。

Helm vs Terraform：K8sツールチェーンにおける2つの強力な選択肢

TerraformとHelmの両方は、Kubernetes管理をより簡単、高速、信頼性の高いものにする堅牢なツールです。しかし、上記で強調したニュアンスにより、各プラットフォームは異なるユースケースに適しています。チームとプロジェクトにより適した方を選択してください。

IaCツールとそれらの比較について学びを続けるには、Ansible、Terraform、Puppetの比較記事を参照してください。