第10章：Helm運用とアンチパターン
この章の学習目標（3〜5）
- Helm-only 運用のデメリットを説明できる
- Kustomize→Helm の学習・運用メリットを整理できる
- 運用アンチパターンを回避するためのチェック観点を持てる
前提
- Helm の基本操作（template/install/upgrade/rollback）を理解している（第9章）
Helm-only のデメリット（具体例）
Helm は強力ですが、Helm “だけ” に寄せると運用コストが増える典型があります。
1) テンプレートが複雑化するとレビューが破綻する
values の分岐をテンプレートへ寄せすぎると、変更の影響範囲が追えなくなります。 結果として「レンダリングして初めて分かる」状態になり、レビューが形骸化します。
対策:
- 分岐を増やす前に「values の粒度」を見直す（環境差分ファイルに寄せる）
helm templateの出力をレビュー対象に含める
2) values が増えすぎて “何が効いているか” が不透明になる
values が肥大化すると、次の事故が起きやすくなります。
- 似たキーが増え、実際に参照されていない値が残る
- デフォルト値に引きずられ、本番差分が埋もれる
対策:
- values を「環境差分（dev/prod）」と「共通（base）」へ分離する
helm get values/helm get manifestで “実際の適用結果” を追える状態にする
3) template 条件分岐が増え、意図せぬ差分が出る
if/range の組み合わせが増えると「条件が満たされない場合の出力」が見落とされます。 特に RBAC/NetworkPolicy など “有無が意味を持つ” リソースで事故につながります。
対策:
helm templateの出力を差分比較する（CI でのチェック対象にする）- 可能なら Chart を分割し、責務を小さくする
Kustomize→Helm の学習メリット（運用・レビュー・保守）
- “素の YAML” の理解が先に固まるため、障害時にテンプレへ依存せず切り分けできる
- overlay 思考（差分）→ values 思考（パラメータ）への移行が自然で、運用ルールを作りやすい
- Kustomize の「差分最小化」の感覚が、Helm の values 設計（増やしすぎない）に効く
実務の落とし所（どこまでを Helm 化するか）
組織要件により最適解は変わりますが、典型は次です。
- ベンダ提供/OSS の “配布単位” は Helm（Chart が正）
- 自社アプリは Kustomize で差分を固めてから Helm 化（もしくは Helm を Kustomize でラップ）
- いずれも「レンダリング結果」をレビュー/CI の対象にする
公式ドキュメント（参照）
まとめ
Helm は強力ですが、運用を誤ると「変更が読めない」「戻せない」に繋がります。アンチパターンを先に潰します。
章末チェックリスト（3〜10）
- Helm-only のリスク（可読性/差分/検証）を説明できる
- レンダリング結果の検証手順を用意する方針を決めた
- 変更レビューの観点（values/テンプレート）を整理した