Certified Kubernetes Administrator (CKA) #21 Helm と Kustomize: マニフェスト管理

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

#20 Networking 3 では CoreDNS と NetworkPolicy まで扱い、ネットワーキングドメインを締めくくりました。今回はトラブルシューティングに移る前に、ひと束のマニフェストを 繰り返し可能で環境別に変形可能なかたちで 管理する 2 つのツールを整理します。Helm と Kustomize です。

CKA でこの 2 つのツールの比重は大きくありません。しかし両方とも実務でマニフェストを扱う標準ツールであり、試験でも「与えられた chart を install せよ」「kustomization で image tag を変えよ」といった短い作業として出ることがあります。核心コマンドとディレクトリ構造だけ手に覚えさせれば十分です。

なぜマニフェスト管理ツールが必要か #

ここまではマニフェストを手で書いて kubectl apply -f で適用してきました。しかし実務では同じアプリを dev・staging・prod 環境に少しずつ違うかたちでデプロイする必要があります。replica 数、image tag、リソース上限、環境変数が環境ごとに異なります。このとき環境の数だけマニフェストをコピーすると重複が積み上がり、変更漏れが生じます。

この問題を解くアプローチは 2 つに分かれます。

  • Helm: マニフェストを テンプレート にし、値 (values) を注入してレンダリングします。chart 単位でパッケージングしてバージョンを管理し、install・upgrade・rollback をコマンドで扱います。
  • Kustomize: 元のマニフェスト (base) はそのまま残し、環境別の差分だけを オーバーレイ で重ね合わせて合成します。テンプレート構文なしで純粋な YAML として動作し、kubectl に内蔵されています。

2 つのツールの哲学は異なりますが、目的は同じです。1 つの定義から複数環境のマニフェストを作り出すこと です。

Helm #

Helm は Kubernetes のパッケージマネージャーです。apt や brew がパッケージを扱うように、Helm は chart という単位で Kubernetes アプリをインストールしアップグレードします。chart はテンプレート化されたマニフェストとデフォルト値 (values.yaml) を収めたディレクトリです。

chart リポジトリの登録 #

公開 chart を使うには、まずリポジトリを登録してインデックスを更新します。

# リポジトリを追加
helm repo add bitnami https://charts.bitnami.com/bitnami

# インデックスを更新 (登録済みの全 repo の最新 chart 一覧)
helm repo update

# 登録済みのリポジトリを確認
helm repo list

# chart を検索
helm search repo nginx

chart のインストール #

helm install は chart をクラスターにインストールし、その結果を release という名前で追跡します。同じ chart を名前だけ変えて複数回インストールできます。

# <release 名> <chart> の順
helm install my-nginx bitnami/nginx

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

# 特定のネームスペースにインストール
helm install my-nginx bitnami/nginx -n web --create-namespace

値の注入: –set と -f #

chart のデフォルト値をそのまま使わず一部を変えるには、値を注入します。1〜2 個は --set で、複数は値ファイル (-f) で渡します。

# インラインで 1〜2 個の値を上書き
helm install my-nginx bitnami/nginx --set replicaCount=3

# 値ファイルでまとめて上書き
helm install my-nginx bitnami/nginx -f my-values.yaml

# 2 つの方法は併用でき、--set が優先される
helm install my-nginx bitnami/nginx -f my-values.yaml --set image.tag=1.25

my-values.yaml は chart の values.yaml 構造のうち変える部分だけ書けば済みます。

replicaCount: 3
image:
  tag: "1.25"
service:
  type: NodePort

インストールせずレンダリングだけ: helm template #

chart が実際にどんなマニフェストを作り出すのかを確認したいときは helm template を使います。クラスターに適用せず、レンダリング結果だけを標準出力に出します。試験で「この chart が作る Deployment の replica 数を確認せよ」といった作業に役立ちます。

# レンダリング結果を画面へ
helm template my-nginx bitnami/nginx --set replicaCount=3

# ファイルに保存して検討
helm template my-nginx bitnami/nginx > rendered.yaml

アップグレードとロールバック #

インストールした release の値や chart バージョンを変えるときは helm upgrade を使います。各変更は revision 番号で記録され、問題が起きたら以前の revision に戻します。

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

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

# revision 履歴を確認
helm history my-nginx

# 直前の revision にロールバック
helm rollback my-nginx

# 特定の revision にロールバック
helm rollback my-nginx 2

状態確認と削除 #

# release の詳細状態
helm status my-nginx

# release が適用した実際のマニフェスト
helm get manifest my-nginx

# release の削除 (関連リソースをすべて除去)
helm uninstall my-nginx

helm uninstall はその release が作ったすべての Kubernetes リソースを一度に除去します。kubectl delete で 1 つずつ消すよりきれいです。

Kustomize #

Kustomize はテンプレート構文なしの 純粋な YAML 合成 でマニフェストを変形します。元は base に置き、環境別の差分を overlay に置いて両者を重ねます。Kustomize は kubectl に内蔵されているので、別途インストールなしで kubectl apply -k で直接適用します。

kustomization.yaml #

すべての Kustomize ディレクトリには kustomization.yaml があります。このファイルがどのマニフェスト (resources) をまとめ、どんな変形を加えるかを宣言します。

# base/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
  - service.yaml

base/deployment.yaml と base/service.yaml は普通のマニフェストです。手で書いていたそのままで、特別な構文はありません。

base と overlays の構造 #

環境別の差分を overlay ディレクトリに分離します。overlay の kustomization.yaml は base を参照し、その上に変形だけを加えます。

myapp/
├── base/
│   ├── kustomization.yaml
│   ├── deployment.yaml
│   └── service.yaml
└── overlays/
    ├── dev/
    │   └── kustomization.yaml
    └── prod/
        └── kustomization.yaml

prod overlay は base を取り込み、prod に必要な変更だけを宣言します。

# overlays/prod/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base
namePrefix: prod-
commonLabels:
  env: prod
images:
  - name: nginx
    newTag: "1.25.3"
replicas:
  - name: web
    count: 5

この overlay は base の Deployment 名に prod- 接頭辞を付け、すべてのリソースに env: prod ラベルを加え、image tag を 1.25.3 に、replica を 5 に変えます。base にはまったく手を付けません。

patchesStrategicMerge #

images や replicas のような内蔵変形では表現しにくい変更は patch で処理します。patchesStrategicMerge は変えるフィールドだけを書いた部分マニフェストを base にマージします。

# overlays/prod/kustomization.yaml の一部
patchesStrategicMerge:
  - resources-patch.yaml
# overlays/prod/resources-patch.yaml (変えるフィールドだけ)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  template:
    spec:
      containers:
        - name: web
          resources:
            requests: { cpu: "250m", memory: "256Mi" }
            limits: { cpu: "500m", memory: "512Mi" }

patch には識別に必要なキー (kind・name・container name) と変えるフィールドだけ書けば済みます。Kustomize が base と同じ位置を見つけてマージします。

configMapGenerator #

ConfigMap を直接書かずにファイルやリテラルから生成できます。configMapGenerator で作った ConfigMap は内容ハッシュが名前に付くので、内容が変わると名前も変わります。これを参照する Pod が自動でローリングアップデートされる利点があります。

configMapGenerator:
  - name: app-config
    literals:
      - LOG_LEVEL=info
      - TIMEOUT=30
  - name: app-files
    files:
      - config.properties

適用とレンダリング: kubectl -k #

Kustomize は kubectl に内蔵されているので、別途バイナリなしで使えます。

# 合成結果を画面で確認 (適用しない)
kubectl kustomize overlays/prod

# 合成結果をそのまま適用
kubectl apply -k overlays/prod

# 合成結果を削除
kubectl delete -k overlays/prod

kubectl kustomize でまず結果を確認してから kubectl apply -k で適用する流れが安全です。alias を使えば k apply -k overlays/prod そして k kustomize overlays/prod のように短く打てます。

Helm と Kustomize の比較 #

2 つのツールは同じ問題を異なる方式で解きます。

区分HelmKustomize
方式テンプレート + 値注入純粋な YAML オーバーレイ
構文Go テンプレート ({{ }}) の学習が必要追加構文なし
インストール別途バイナリをインストールkubectl に内蔵 (-k)
パッケージングchart で配布・共有・バージョン管理ディレクトリ構造
リリース追跡release・revision で管理なし (状態を持たない)
ロールバックhelm rollback を内蔵なし (VCS で戻す)
外部アプリのインストール公開 chart が豊富直接マニフェストを書く
適した場面サードパーティアプリのインストール、複雑なパラメータ化自前アプリの環境別変形

実務では 2 つを併用することもあります。外部アプリは Helm chart でインストールし、自前アプリは Kustomize で環境別変形を管理するやり方です。正解はなく、チームの標準に従えば済みます。

CKA 試験ポイント #

  • Helm と Kustomize は CKA の比重が小さいです。しかし短い作業として出ることがあるので、核心コマンドは覚えておく のが安全です。
  • Helm は helm install、helm upgrade --install、helm list、helm rollback、そして値を確認する helm template を手に覚えさせます。インストール前に何が作られるかを helm template で検証する習慣が誤答を減らします。
  • Kustomize は kubectl apply -k と kubectl kustomize だけ確実に覚えれば済みます。適用前に kubectl kustomize で合成結果をまず確認します。
  • 「image tag を変えよ」のような作業は、Kustomize なら overlay の images.newTag を、Helm なら --set image.tag を思い浮かべると速いです。
  • 試験環境に Helm バイナリがあるか、どの chart が事前登録されているかは問題が教えてくれます。指示文をまず正確に読みます。

マニフェスト管理ツールを直接手で習得するなら、Kubernetes 実戦演習 2 のシナリオで base/overlay を作ってみて、chart を install・upgrade・rollback してみるのが最も速い方法です。

まとめ #

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

  • マニフェスト管理ツールは 1 つの定義から複数環境のマニフェストを作り出す。Helm はテンプレート、Kustomize はオーバーレイでアプローチ
  • Helm。repo add/repo update でリポジトリ登録、install/upgrade/rollback で release 管理、--set と -f で値注入、helm template で適用前にレンダリング確認、helm list/history/uninstall
  • Kustomize。kustomization.yaml で base と overlays を構成、patchesStrategicMerge で部分マージ、configMapGenerator で ConfigMap 生成、kubectl apply -k で適用、kubectl kustomize で合成確認
  • 両者の違い。テンプレート対オーバーレイ、別途インストール対 kubectl 内蔵、release 追跡の有無。外部アプリは Helm、自前アプリの変形は Kustomize がよくある選択
  • 試験ポイント。比重は小さいが核心コマンドは覚えておく。適用前に helm template・kubectl kustomize で検証

次へ: Troubleshooting 1 #

マニフェスト管理まで整理し、ツールを扱うドメインを終えました。ここから CKA で最も比重が大きいトラブルシューティング (30%) に入ります。

#22 Troubleshooting 1: Pod とアプリ では、最もよく出会うアプリレベルの障害を扱います。Pending (スケジュール不可)、CrashLoopBackOff (コンテナの繰り返し終了)、ImagePullBackOff (イメージ取得失敗)、OOMKilled (メモリ上限超過) の症状を区別し、kubectl describe・kubectl logs・イベントで原因を追跡して直す手順を手に覚えさせます。

X