Kubernetesでアプリケーションを動かすとき、DeploymentやService、ConfigMapといった複数のYAMLファイルを手作業で管理するのは大変です。環境ごとに設定値を変えたり、バージョンアップやロールバックを安全に行いたい場面も出てきます。こうした課題を解決してくれるのがHelmです。この記事では、Kubernetesをkubectlで触った経験はあるもののHelmは初めてという方向けに、基礎用語の整理から、実際にHelm Chartを使ってアプリケーションをデプロイするところまでを解説します。
Helmとは何か
HelmはKubernetes向けのパッケージマネージャーです。よく「Kubernetesにおけるapt(Debian系Linuxのパッケージ管理ツール)やHomebrew(macOS用パッケージ管理ツール)のような存在」と説明されます。apt installでソフトウェアを簡単に導入できるように、helm installコマンド一つでデータベースやWebサーバーなどの複雑なアプリケーションをKubernetesクラスタ上に展開できます。
Helmを使うと、次のようなことが実現できます。
- 複数のYAMLマニフェストを一つのパッケージ(Chart)としてまとめて管理する
- 環境ごとに異なる設定値をテンプレートとして切り替える
- アプリケーションのバージョン管理、アップグレード、ロールバックをコマンド一つで行う
- Artifact Hubなどで公開されている既成のChartを再利用し、ゼロから設定を書く手間を省く
現在Helmは大きくバージョン3系とバージョン4系があります。バージョン3は2025年11月に登場した4系への移行期にあり、バグ修正は2026年7月、セキュリティ修正は2026年11月まで提供される予定です。これから新規に学ぶ場合はHelm 4系を使うのがおすすめですが、コマンド体系や基本概念は3系から大きく変わっていないため、この記事の内容はどちらのバージョンでも通用します。
前提知識:Helmを理解するためのKubernetes基礎用語
Helmの説明に入る前に、関連するKubernetesの用語を簡単におさらいしておきます。
Podはコンテナを実行する最小単位です。Deploymentは複数のPodを管理し、指定した数のPodが常に稼働するよう保証する仕組みです。ServiceはPod群への通信経路を提供し、外部やクラスタ内の他のコンポーネントからアクセスできるようにします。これらの設定はすべてYAML形式のマニフェストファイルに記述し、kubectl applyコマンドでクラスタに適用します。
アプリケーション一つをデプロイするだけでも、Deployment、Service、ConfigMap、Secretなど複数のYAMLファイルが必要になることが珍しくありません。これらを毎回手作業で書いたり、環境ごとにコピーして値だけ書き換えたりするのは非効率かつミスの元です。Helmはこの問題を、テンプレート化とパッケージ化によって解決します。
Helmの基本概念
Helmを使いこなす上で押さえておきたい4つの概念があります。
Chart(チャート)
Kubernetesリソースの定義をまとめたパッケージです。DeploymentやServiceなどのYAMLテンプレートに加えて、デフォルト設定値や説明書きが含まれています。いわばアプリケーションの設計図兼インストーラーです。
Release(リリース)
Chartを実際にクラスタへインストールした際の、一つのインスタンスを指します。同じChartでも、リリース名を変えれば同一クラスタ内に複数回インストールできます。例えば同じnginxのChartから、開発用と検証用のリリースを別々に作ることが可能です。
Repository(リポジトリ)
Chartを配布・保管しておく場所です。従来はhelm repo addで独自のHTTPリポジトリを登録する方式が主流でしたが、近年はDocker HubなどのOCI(Open Container Initiative)レジストリを使ってChartを配布する方式が標準になりつつあります。
Values(バリュー)
Chartの動作をカスタマイズするための設定値です。Chartにはvalues.yamlというデフォルト設定ファイルが同梱されており、インストール時に自分の環境に合わせて値を上書きできます。レプリカ数やイメージのバージョン、リソース制限などを、Chart本体を書き換えずに変更できるのがポイントです。
Helmをインストールする
Helmはコマンドラインツールとして提供されており、主要OSごとにインストール方法が用意されています。
公式サイトのインストール方法を参照してください。
https://helm.sh/ja/docs/intro/install
インストール後、バージョンを確認して正しく導入されたかチェックします。
helm versionなお、Helmを使うにはあらかじめkubectlが設定済みで、Kubernetesクラスタに接続できる状態になっている必要があります。ローカルで試す場合はminikubeやKindなどでクラスタを用意しておきましょう。
実践:HelmでnginxのChartをデプロイする
ここからは実際にHelmを使って、Webサーバーのnginxをクラスタにデプロイしてみます。例として、Bitnami社が提供する公開Chartを使用します。
Chartを探す
Helm用の公開Chartは、Artifact Hub(artifacthub.io)というサイトで検索できます。ブラウザでArtifact Hubにアクセスし「nginx」と検索すると、Bitnamiが提供するnginx Chartが見つかります。このChartには、nginxのDeployment、Service、ConfigMapなどの定義一式があらかじめ用意されています。
Bitnamiの公開Chartは2024年以降、従来のHTTPリポジトリ形式ではなくOCIレジストリ形式での配布が標準になっています。そのためhelm repo addは不要で、OCI形式のURLを直接指定してインストールします。
インストールする
次のコマンドで、Bitnamiのnginx Chartをクラスタにインストールしてみます。
helm install my-nginx oci://registry-1.docker.io/bitnamicharts/nginxmy-nginxの部分がリリース名です。任意の名前を付けられます。インストールが完了すると、Podやアクセス方法などの情報がターミナルに出力されます。
デプロイされたリソースを確認してみましょう。
kubectl get pods
kubectl get svcnginxのPodがRunning状態になっていれば成功です。
2026/08現在、OCIレジストリを使う方法が推奨されていますが、HTTP配布されているものは、HTTPリポジトリとして登録して使います。
helm repo add <リポジトリ名> <リポジトリURL>
helm repo update
helm search repo <リポジトリ名>Kubernetes公式のingress-nginxなら、次のように指定します。
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm search repo ingress-nginx
helm install my-ingress ingress-nginx/ingress-nginx設定値をカスタマイズする
デフォルト設定のままではなく、レプリカ数やサービスの公開方法を変更したい場合は、values.yamlを使ってカスタマイズします。まずデフォルトの設定値を確認します。
helm show values oci://registry-1.docker.io/bitnamicharts/nginx > my-values.yaml出力されたmy-values.yamlを開くと、replicaCountやservice.typeなど数百行にわたる設定項目が確認できます。この中から変更したい項目だけを残し、他は削除してシンプルなファイルにしておくのがおすすめです。例えば、レプリカ数を2にしてServiceの公開方式をNodePortにする場合は次のように記述します。
replicaCount: 2
service:
type: NodePort
このファイルを使ってインストールする場合は–valuesオプションを指定します。
helm install my-nginx oci://registry-1.docker.io/bitnamicharts/nginx --values my-values.yamlちょっとした値だけを変えたい場合は、ファイルを作らず–setオプションでその場で指定することもできます。
helm install my-nginx oci://registry-1.docker.io/bitnamicharts/nginx --set replicaCount=2アップグレードする
設定を変更したい、あるいはChartの新しいバージョンが出た場合は、helm upgradeで既存のリリースを更新します。
helm upgrade my-nginx oci://registry-1.docker.io/bitnamicharts/nginx --values my-values.yamlアップグレードのたびにHelmはリビジョン番号を記録するため、変更履歴を追跡できます。
ロールバックする
アップグレード後に問題が発生した場合、以前の状態に戻せます。まずリビジョン履歴を確認します。
helm history my-nginx戻したいリビジョン番号を指定してロールバックします。
helm rollback my-nginx 1手作業でYAMLを書き直す必要がなく、安全に前の状態へ戻せるのはHelmの大きな利点です。
過去のリビジョン番号のvaluesを見るには、–revisionを付けます。
helm get values my-nginx --revision 1アンインストールする
不要になったリリースは、helm uninstallで関連するすべてのリソースをまとめて削除できます。
helm uninstall my-nginx個別にkubectl deleteでリソースを消していく必要がなく、インストール時に作られたものが一括で片付きます。
自分でChartを作ってみる
既成のChartをカスタマイズするだけでなく、自分のアプリケーション用にChartをゼロから作ることもできます。helm createコマンドを使うと、基本的なディレクトリ構成を持つひな形が生成されます。
helm create mychart生成されるmychartディレクトリには、Chart.yaml(Chartの名前やバージョンなどのメタ情報)、values.yaml(デフォルト設定値)、templates/ディレクトリ(DeploymentやServiceなどのテンプレートファイル)が含まれています。テンプレート内では{{ .Values.replicaCount }}のような記法で、values.yamlの値を差し込めます。この仕組みにより、一つのテンプレートから環境ごとに異なる設定のマニフェストを生成できるわけです。
作成したChartを実際に適用する前に、生成されるYAMLを確認したい場合はhelm templateコマンドが便利です。
helm template mychartクラスタには反映せず、レンダリング結果だけを標準出力に表示してくれるため、意図通りのYAMLが生成されているか事前にチェックできます。
まとめ
Helmは、複数のKubernetesマニフェストをChartという単位でパッケージ化し、インストール・アップグレード・ロールバックといったライフサイクル管理をシンプルなコマンドで行えるようにするツールです。Artifact Hubで公開されている既成のChartを使えば、複雑なアプリケーションでもコマンド一つで環境に導入できますし、helm createを使えば自分のアプリケーション用のChartを一から構築することもできます。
まずはこの記事で紹介したbitnami/nginxのような公開Chartをローカルのクラスタで試し、helm install、helm upgrade、helm rollbackといった基本操作に慣れてみてください。操作に慣れてきたら、次のステップとして自作Chartのテンプレート機能や、複数のChartを組み合わせるDependency機能にも挑戦してみると、Helmの理解がさらに深まります。
コメント