Kubernetes Helm Charts 完全ガイド 2026:パッケージング、デプロイメント、面接対策

Helm 3を使用したKubernetesアプリケーションのパッケージングとデプロイメント手法を解説。チャート構造、テンプレート作成、依存関係管理、そして技術面接で頻出する質問と回答例を網羅的に紹介します。

Kubernetes Helm Charts 2026 チュートリアルと面接対策

Kubernetes Helm Chartsは、すべてのKubernetesリソースを単一のバージョン管理されたアーティファクトにパッケージ化し、アプリケーションのデプロイメントを簡素化します。現在の安定版であるHelm 3は、Tillerの必要性を排除し、OCIレジストリのサポートを導入することで、チャートの配布をより安全かつ標準化されたものにしています。本チュートリアルでは、チャートの作成、テンプレート化、デプロイメント戦略、そして採用チームから最も頻繁に質問される面接のポイントについて解説します。

Helm 3 クイックリファレンス

Helmチャートには、Chart.yaml(メタデータ)、values.yaml(デフォルト値)、およびKubernetesマニフェストを含むtemplates/ディレクトリが含まれます。helm installコマンドはテンプレートを値でレンダリングし、クラスターに適用します。

Helmチャートの構造とコンポーネントを理解する

Helmチャートは、事前定義された構造を持つディレクトリです。チャート名がディレクトリ名となり、各ファイルはパッケージングとデプロイメントプロセスにおいて特定の役割を果たします。

yaml
# Chart.yaml
apiVersion: v2
name: my-application
description: A production-ready web application
type: application
version: 1.0.0
appVersion: "2.1.0"
dependencies:
  - name: postgresql
    version: "15.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: postgresql.enabled

apiVersion: v2はHelm 3との互換性を示します。versionフィールドはチャートの変更を追跡し、appVersionはデプロイされるアプリケーションのバージョンを反映します。依存関係は、このチャートが必要とする他のチャートを宣言し、オプションで有効化・無効化の条件を設定できます。

yaml
# values.yaml
replicaCount: 3

image:
  repository: myregistry.io/app
  tag: "2.1.0"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 8080

resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 100m
    memory: 128Mi

postgresql:
  enabled: true
  auth:
    database: appdb

values.yamlは、インストール時にユーザーが上書きできる設定のデフォルト値を定義します。意味のあるキーの下に値をネストすることで、設定が整理され、自己文書化されます。

HelmテンプレートによるKubernetesデプロイメントの作成

Helmテンプレートは、GoテンプレートとSprig関数を使用して、Kubernetesマニフェストを動的に生成します。{{ .Values }}オブジェクトはvalues.yamlの内容へのアクセスを提供し、{{ .Release }}にはデプロイメントのメタデータが含まれます。

yaml
# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "my-application.fullname" . }}
  labels:
    {{- include "my-application.labels" . | nindent 4 }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      {{- include "my-application.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      labels:
        {{- include "my-application.selectorLabels" . | nindent 8 }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          ports:
            - containerPort: {{ .Values.service.port }}
          resources:
            {{- toYaml .Values.resources | nindent 12 }}

nindent関数は改行とインデントを追加し、YAML生成において重要な役割を果たします。_helpers.tplで定義された名前付きテンプレートとincludeを使用することで、テンプレートをDRYに保ち、保守性を高めます。

yaml
# templates/_helpers.tpl
{{- define "my-application.fullname" -}}
{{- if .Values.fullnameOverride }}
{{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" }}
{{- else }}
{{- $name := default .Chart.Name .Values.nameOverride }}
{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" }}
{{- end }}
{{- end }}

{{- define "my-application.labels" -}}
helm.sh/chart: {{ include "my-application.chart" . }}
app.kubernetes.io/name: {{ include "my-application.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end }}

ヘルパーテンプレートは、すべてのリソースにわたって命名規則とラベルを標準化し、Kubernetesの推奨ラベルとの一貫性を確保します。

Helmチャートの依存関係とサブチャート

複雑なアプリケーションは、多くの場合、データベース、キャッシュ、またはメッセージキューに依存します。Helmの依存関係により、これらをサブチャートとして埋め込み、インストール中に自動的に管理することができます。

bash
# パッケージング前に依存関係を更新
helm dependency update ./my-application

# 依存関係をビルド(charts/ディレクトリを作成)
helm dependency build ./my-application

helm dependency updateコマンドは依存関係をcharts/ディレクトリにダウンロードします。条件付き依存関係は、値を使用して有効化を切り替えます:

yaml
# values.yaml
postgresql:
  enabled: true

redis:
  enabled: false
yaml
# Chart.yaml
dependencies:
  - name: postgresql
    version: "15.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: postgresql.enabled
  - name: redis
    version: "19.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: redis.enabled

このパターンにより、本番環境ではマネージドサービスを使用し、開発環境ではクラスタ内データベースを使用するような、環境固有の設定が可能になります。

OCIレジストリサポート

Helm 3.8以降は、Docker Hub、GitHub Container Registry、AWS ECRなどのOCI準拠のレジストリへのチャート保存をサポートしています。helm push my-app-1.0.0.tgz oci://registry.example.com/chartsでチャートをプッシュできます。

リリース管理によるHelmチャートのデプロイ

Helmはデプロイメントをリリースとして追跡し、バージョン管理されたロールバックとアップグレードを可能にします。各リリースは監査と復旧のための履歴を維持します。

bash
# カスタム値でチャートをインストール
helm install my-release ./my-application \
  --namespace production \
  --create-namespace \
  --values production-values.yaml \
  --set image.tag=2.1.1

# 既存のリリースをアップグレード
helm upgrade my-release ./my-application \
  --namespace production \
  --values production-values.yaml \
  --set image.tag=2.2.0 \
  --atomic \
  --timeout 5m

--atomicフラグは、アップグレードが失敗した場合に自動的にロールバックすることを保証します。--timeoutフラグは、Helmがリソースの準備完了を待機する時間を設定します。

bash
# リリース履歴を表示
helm history my-release -n production

# 以前のリビジョンにロールバック
helm rollback my-release 2 -n production

# リリースをアンインストール
helm uninstall my-release -n production --keep-history

--keep-historyフラグは、アンインストール後もリリースレコードを保持します。これはコンプライアンスとデバッグに役立ちます。

DevOpsの面接対策はできていますか?

インタラクティブなシミュレーター、flashcards、技術テストで練習しましょう。

Helmチャートのテストと検証戦略

デプロイ前にHelmチャートをテストすることで、テンプレートエラーや設定の問題を早期に発見できます。Helmにはリンティングとドライランテストのための組み込みツールが用意されています。

bash
# チャートのエラーとベストプラクティスをリント
helm lint ./my-application

# デプロイせずにテンプレートをローカルでレンダリング
helm template my-release ./my-application \
  --values production-values.yaml \
  > rendered-manifests.yaml

# クラスターAPIに対してドライラン
helm install my-release ./my-application \
  --dry-run \
  --debug \
  --namespace production

helm templateコマンドはマニフェストをローカルでレンダリングし、生成されたYAMLを検証するCIパイプラインに便利です。--dry-runフラグはマニフェストをKubernetes APIサーバーに送信して検証しますが、リソースは作成しません。

yaml
# templates/tests/test-connection.yaml
apiVersion: v1
kind: Pod
metadata:
  name: "{{ include "my-application.fullname" . }}-test"
  labels:
    {{- include "my-application.labels" . | nindent 4 }}
  annotations:
    "helm.sh/hook": test
spec:
  containers:
    - name: curl
      image: curlimages/curl:8.7.1
      command: ['curl']
      args: ['{{ include "my-application.fullname" . }}:{{ .Values.service.port }}/health']
  restartPolicy: Never

helm.sh/hook: testを持つHelmフックは、helm test my-releaseの後に実行され、インストール後のデプロイメントが正しく動作することを検証します。

高度なHelmテンプレート技術

本番チャートでは、条件付きロジック、ループ、およびデータ変換が必要になります。Sprig関数は、文字列操作、エンコーディング、およびフロー制御のためのユーティリティでGoテンプレートを拡張します。

yaml
# templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ include "my-application.fullname" . }}-config
data:
  {{- range $key, $value := .Values.config }}
  {{ $key }}: {{ $value | quote }}
  {{- end }}
  
  {{- if .Values.features.enabled }}
  FEATURE_FLAGS: {{ .Values.features.flags | join "," | quote }}
  {{- end }}
yaml
# templates/secrets.yaml
apiVersion: v1
kind: Secret
metadata:
  name: {{ include "my-application.fullname" . }}-secrets
type: Opaque
data:
  {{- range $key, $value := .Values.secrets }}
  {{ $key }}: {{ $value | b64enc }}
  {{- end }}

range関数はマップとリストを反復処理します。b64enc関数はKubernetesシークレット用に値をbase64エンコードします。パイプ演算子はデータ変換のために関数をチェーンします。

シークレット管理

values.yamlにシークレットを保存すると、バージョン管理で公開されてしまいます。本番デプロイメントでは、HashiCorp Vault、External Secrets OperatorとAWS Secrets Manager、またはSOPSで暗号化されたvaluesファイルなどの外部シークレットマネージャーを使用してください。

Helmチャートの面接質問と回答

技術面接では、概念的および実践的な質問を通じてHelmの知識が頻繁にテストされます。以下に最も頻繁に質問されるトピックについて解説します。

helm installhelm upgrade --installの違いは何ですか?

helm installは新しいリリースを作成し、リリースがすでに存在する場合は失敗します。helm upgrade --install--installフラグ付き)は、リリースが存在しない場合は新しいリリースを作成し、存在する場合はアップグレードします。CI/CDパイプラインでは通常、冪等なデプロイメントのためにhelm upgrade --installを使用します。

Helmチャートにセンシティブなデータを渡すにはどうすればよいですか?

3つのアプローチがあります:外部シークレットマネージャー(Vault、AWS Secrets Manager)、暗号化されたvaluesファイル(SOPS、sealed-secrets)、またはHelm外で作成され、テンプレートで参照されるKubernetesシークレットです。バージョン管理にコミットされるプレーンテキストのvalues.yamlファイルにシークレットを保存することは避けてください。

Helmフックとは何ですか?いつ使用すべきですか?

フックはリリースライフサイクルの特定のポイントで実行されます:pre-installpost-installpre-upgradepost-upgradepre-deletepost-deletepre-rollbackpost-rollback、およびtest。一般的な使用例には、アップグレード前のデータベースマイグレーション、デプロイメント後の通知送信、または統合テストの実行が含まれます。

チャートのバージョニングはどのように処理しますか?

Chart.yamlのversionフィールドは、セマンティックバージョニングを使用してチャートの変更を追跡します。appVersionフィールドは、デプロイされるアプリケーションのバージョンを追跡します。アプリケーションのバージョンが同じままでも、チャートの変更があればversionをインクリメントしてください。

.helmignoreの目的は何ですか?

.gitignoreと同様に、.helmignoreはチャートパッケージングからファイルを除外します。一般的なエントリには、*.tgz(以前のビルドのパッケージングを回避)、.git/、ランタイムで不要な*.mdドキュメント、およびCI設定ファイルが含まれます。

Kubernetesの面接対策をさらに進めたい場合は、SharpSkillのKubernetes基礎およびKubernetes応用の質問モジュールをご覧ください。

まとめ

Helmチャートを使用する際の実践的なポイントは以下の通りです:

  • Chart.yamlメタデータ、values.yamlデフォルト、およびKubernetesマニフェストを含むtemplatesディレクトリを明確に分離してチャートを構成する
  • _helpers.tplのヘルパーテンプレートを使用して、すべてのリソースにわたって命名とラベルを標準化する
  • 環境固有の設定のために、Chart.yamlで条件付き有効化を使用して依存関係を管理する
  • 本番環境にデプロイする前に、helm linthelm template、およびhelm install --dry-runでチャートをテストする
  • 意味のある名前でリリースを追跡し、アップグレード失敗時の自動ロールバックのために--atomicフラグを使用する
  • プレーンテキストのvaluesファイルではなく、外部マネージャーにシークレットを保存する

今すぐ練習を始めましょう!

面接シミュレーターと技術テストで知識をテストしましょう。

今日のチャレンジ

DevOps のバグを見つけられますか

実際のコード、隠れたバグ、1日1回。アカウントなしで試せます。

Anthony Fillion-Maillet

執筆

Anthony Fillion-Maillet

SharpSkill 創業者

10 年以上フルスタック開発に携わっています。SharpSkill を運営し、ここで公開される内容に責任を負っています。

2026年7月23日 更新

タグ

#kubernetes
#helm
#devops
#面接対策
#デプロイメント

共有

関連記事