Certified Kubernetes Application Developer (CKAD) #9 Helm: install, upgrade, rollback, values

インフラ Kubernetes コンテナオーケストレーション Certification
読了 9分

#8 Deployment 戦略 では blue-green と canary で無停止デプロイのパターンを手で作ってみました。ところが実務でアプリケーション 1 つをデプロイするには、Deployment 1 つだけでは終わりません。Deployment・Service・ConfigMap・Secret・Ingress が 1 つの束として付いてまわり、環境ごとに値だけ少しずつ異なるマニフェストを繰り返し管理しなければなりません。このマニフェストの束を 1 つのパッケージとしてインストールし、バージョンを付けて上げたり戻したりする ツールが Helm です。

CKAD で Helm の出題比重そのものは大きくありません。しかし Application Deployment ドメインに含まれているため、チャートをインストールし、values を変えて再適用し、問題が起きたらロールバックする という基本の流れは試験範囲です。今回の記事は深いチャート作成よりも helm コマンドの運用に焦点を当て、手で打ち込みながら覚えます。

Helm が解く問題 #

K8s 実務トラック #2 ではマニフェストを kubectl apply -f で適用する流れを扱いました。単純なアプリならそれで十分ですが、現実のアプリケーションは次のような負担を伴います。

  • 1 つのアプリが Deployment・Service・ConfigMap・Secret・Ingress など 複数のマニフェスト で構成される
  • dev・staging・prod の環境ごとに replica 数・イメージタグ・ドメイン といった値だけが異なる
  • 新しいバージョンをデプロイして問題が起きたら 以前の状態へ一度に戻さなければならない
  • 外部で作られたアプリケーション (例: PostgreSQL、Redis) を 検証済みの設定でインストールしたい

Helm はこのマニフェストの束を chart というパッケージにし、そこに値を注入してクラスターにインストールした結果を release として管理します。パッケージマネージャーがソフトウェアをインストールしアップグレードし削除するように、Helm は Kubernetes アプリケーションを同じ方式で扱います。

コアの概念: chart、release、repository #

3 つの単語を正確に区別すれば Helm コマンドが一目で頭に入ります。

概念説明
chartマニフェストのテンプレートとデフォルト値を収めたパッケージ。インストールの材料
releasechart を特定の値でクラスターにインストールした結果。名前とバージョン (revision) を持つ
repositorychart を集めて配布するストア。helm repo add で登録
valueschart のテンプレートに注入される設定値。values.yaml または --set で指定

同じ chart を名前だけ変えて何度もインストールすると、それぞれ別個の release になります。release はインストールするたびに revision 番号が 1 ずつ上がり、この番号が rollback の基準になります。

chart のディレクトリ構造 #

chart は決まったディレクトリ構造を持つ束です。自分で作成する機会は少ないですが、構造を知っておくと values がどこから来るのかが理解できます。

mychart/
  Chart.yaml          # チャートのメタデータ (name, version, appVersion)
  values.yaml         # デフォルト値。--set や -f で上書きする前の出発点
  templates/          # Go テンプレートで書かれたマニフェスト
    deployment.yaml
    service.yaml
    _helpers.tpl      # テンプレートヘルパー (命名規則など)
  charts/             # 依存チャート (subchart) を保管

templates/ 内のマニフェストは {{ .Values.replicaCount }} のように値を参照し、その値は values.yaml のデフォルト値から始まって --set や -f で上書きされます。この流れが Helm のすべてと言ってもよいでしょう。

helm create で標準の骨格を一度に作れます。

helm create mychart

repository の登録と検索 #

外部の chart を使うには、まずストアを登録してインデックスを更新します。

# ストアを登録
helm repo add bitnami https://charts.bitnami.com/bitnami

# 登録したストアのインデックスを更新 (常に install の前に)
helm repo update

# 登録済みストアの一覧
helm repo list

# ストアから chart を検索
helm search repo nginx
helm search repo bitnami/postgresql

helm repo update を抜かすと古いインデックスを見てインストールすることになるので、install の前に一度更新する習慣が安全です。chart のどの値を変えられるかを確認するには helm show values が便利です。

# chart のデフォルト values.yaml をそのまま出力
helm show values bitnami/nginx

install: chart を release としてインストール #

インストールは helm install <release 名> <chart> の形式です。release 名を自分で決める点が核心です。

# bitnami/nginx を myweb という release としてインストール
helm install myweb bitnami/nginx

# 名前空間を指定してインストール (なければ作成)
helm install myweb bitnami/nginx --namespace web --create-namespace

# インストール済み release の一覧
helm list

# すべての名前空間の release
helm list -A

# 特定の release の状態
helm status myweb

helm list に release 名・revision・状態 (deployed)・chart バージョンが表示されます。release が正常なら kubectl get all -n web で chart が作り出した Pod と Service を確認できます。

release 名を自動で #

名前を決めるのが面倒なときは --generate-name で Helm に名前を作らせることができます。ただし試験では通常 release 名を指定するよう求められるので、自分で決める形式に慣れておく方がよいでしょう。

helm install bitnami/nginx --generate-name

values のオーバーライド: 同じ chart、異なる設定 #

chart の本当の価値は 値だけ変えて環境別に異なるインストールをする ところにあります。値を上書きする方法は 2 つです。

--set でインライン指定 #

簡単な値を 1 つか 2 つ変えるときに使います。

# 単一の値
helm install myweb bitnami/nginx --set replicaCount=3

# ドット表記で入れ子の値、カンマで複数
helm install myweb bitnami/nginx \
  --set replicaCount=3 \
  --set image.tag=1.27

# 配列インデックス表記
helm install myweb bitnami/nginx --set ingress.hosts[0].host=example.com

-f で values ファイルを指定 #

変える値が多いときや環境ごとにファイルを分けておきたいときは、別の YAML ファイルを渡します。

# myvalues.yaml
replicaCount: 3
image:
  tag: "1.27"
service:
  type: ClusterIP
helm install myweb bitnami/nginx -f myvalues.yaml

# 複数のファイルを重ねて適用 (後ろが優先)
helm install myweb bitnami/nginx -f base.yaml -f prod.yaml

値の優先順位 #

同じキーが複数の場所で指定されると、決まった順序で上書きされます。後ろにいくほど優先順位が高くなります。

  1. chart の values.yaml (最も低い、デフォルト値)
  2. -f で渡したファイル (複数なら後のファイルが優先)
  3. --set で指定した値 (最も高い)

つまり --set はどのファイルの値よりも強く上書きします。1 つのキーを -f ファイルと --set の両方で指定すると --set の値が適用されます。適用された最終的な値が紛らわしいときは helm get values で確認します。

# release に実際に適用されたユーザー指定の値
helm get values myweb

# デフォルト値まで含めた全体の値
helm get values myweb -a

upgrade と rollback #

インストール後に値や chart バージョンを変えるには helm upgrade を使います。upgrade するたびに revision が上がり、その履歴でいつでも戻すことができます。

# 値を変えてアップグレード (revision が 2 に増加)
helm upgrade myweb bitnami/nginx --set replicaCount=5

# release がなければインストール、あればアップグレード
helm upgrade --install myweb bitnami/nginx -f prod.yaml

# release の revision 履歴
helm history myweb

helm upgrade --install は release の存在有無を気にせず 1 つのコマンドで処理するので、CI パイプラインでよく使われます。

rollback: 以前の revision へ戻す #

アップグレードが間違っていたら helm history で revision 番号を確認し helm rollback で戻します。

# 履歴を確認
helm history myweb
# REVISION  STATUS      CHART        ...
# 1         superseded  nginx-15.0.0
# 2         deployed    nginx-15.0.0

# revision 1 へ戻す (新しい revision 3 が作成される)
helm rollback myweb 1

# 番号を省略すると直前の revision へ
helm rollback myweb

rollback は過去の状態をそのまま復元しつつ 新しい revision を作ります。 したがって revision 1 へロールバックすると内容は 1 と同じですが、history には revision 3 として記録されます。この点を覚えておけば次の作業で番号を取り違えずに済みます。

適用前のプレビュー: template と dry-run #

#1 で kubectl --dry-run を強調したように、Helm にも適用前に結果を確認する手段があります。試験で誤ってインストールする前に一度のぞいておく習慣が時間を節約します。

# クラスターに適用せずレンダリング済みマニフェストだけ出力
helm template myweb bitnami/nginx -f myvalues.yaml

# 実際のインストール流れをそのまま辿りつつ適用はしない (サーバー検証を含む)
helm install myweb bitnami/nginx --dry-run --debug -f myvalues.yaml

helm template は純粋にローカルでテンプレートだけをレンダリングするので速く、--dry-run --debug は API サーバーに送って検証まで通すので実際のインストールにより近くなります。値が意図どおり入ったか確認するときは、レンダリング結果の replicas: や image: の行を直接見ます。

uninstall: release を削除 #

release を消すと、その release が作ったすべてのリソースが一緒に削除されます。

# release を削除
helm uninstall myweb

# 名前空間を指定して削除
helm uninstall myweb --namespace web

# 履歴は残して削除 (rollback 用)
helm uninstall myweb --keep-history

デフォルトの動作は history まで一緒に消します。後で戻す可能性があれば --keep-history を付けます。

試験ポイント #

  • 概念 3 種。chart (材料) · release (インストール結果、revision を保有) · repository (ストア) を正確に区別する
  • install の形式。helm install <release> <repo/chart>。release 名を入れる位置を覚える
  • 値の優先順位。values.yaml < -f ファイル < --set。--set が最も強い
  • upgrade と rollback。helm upgrade で revision 増加、helm history で番号を確認、helm rollback <release> <revision> で復元。rollback も新しい revision を作る
  • プレビュー。helm template はローカルレンダリング、helm install --dry-run --debug はサーバー検証を含む
  • 確認コマンド。helm list・helm status・helm get values でインストール状態と適用された値を点検する
  • repo 更新。install の前に helm repo update を抜かさない

まとめ #

この記事で押さえたこと:

  • Helm はマニフェストの束をパッケージとして扱うツール。chart を values と一緒にインストールした結果が release です
  • repo の流れ。helm repo add → helm repo update → helm search repo で chart を探す
  • install と values。helm install <release> <chart> に --set または -f で値を上書きします。--set が最優先
  • upgrade と rollback。helm upgrade で revision を上げ、helm history と helm rollback で戻す
  • プレビューと削除。helm template・--dry-run --debug で結果を確認し helm uninstall で片付ける

CKAD で Helm の比重は小さいですが、install・upgrade・values・rollback の基本コマンドは手に馴染ませておかないと詰まります。

次へ: Kustomize #

Helm がテンプレートと値の注入でマニフェストをパッケージ化するなら、同じ問題を テンプレートなしで patch で 解くツールが Kustomize です。

#10 Kustomize: overlay パターン、環境別マニフェスト では、base と overlay で環境別マニフェストを構成する方法、kustomization.yaml の構造、kubectl apply -k で適用する流れ、そして Helm と Kustomize をいつ選び分けるのかまで自分で作りながら整理します。

X