同じアプリを Helm と Kustomize で二度パッケージする

目標

同じDeploymentを、2つの配信ツールでパッケージングしてみます。Helmでチャートを作ってvaluesを変更し、テンプレート展開・インストール・アップグレードを行い、Kustomizeでbaseを組んでからprodオーバーレイでreplicasとラベルを上書きします。「どのマニフェストが実際にクラスターへ適用されたのか」を、helmのリリースとkustomizeの出力の両方から確認します。

なぜ重要なのか

Kubernetesのマニフェストは、手書きのYAML1つで終わりではありません。環境ごとにreplicas・イメージ・ラベルが変わり、その違いを管理する方法こそが「アプリの配信(delivery)」の核心です。Helmは値(values)を差し込むテンプレートで、Kustomizeはbaseの上にオーバーレイを重ねる方式で、同じ問題を解きます。2つの考え方は違いますが、成果物は同じくAPIサーバーへ送られるマニフェストです。

helm installとhelm upgradeがリリースという単位で変更履歴を残すこと、Kustomizeが元のファイルに手を加えず、オーバーレイだけで差分を表現することを実際に触ってみると、デプロイパイプラインで「今何が適用されているのか」を、リリースのリビジョンと組み立て結果から辿る感覚が身につきます。

ステップ

ネームスペースkcna-pkgを作成してください。
helm createでwebappチャートの雛形を生成してください。
replicaCountを3に変更し、helm templateの結果をファイルに保存してください。
リリースwebとしてチャートをインストールしてください。
--set replicaCount=5でアップグレードし、リビジョンとreplicasを上げてください。
Kustomizeのbase(storeDeployment)を手で組み、kubectl kustomizeで組み立てを確認してください。
prodオーバーレイでreplicasを4にし、env=prodラベルを上書きして適用してください。
helmとkustomizeの結果を/root/kcna-pkg/report.txtに帳簿として残してください。

参考

helm list -n kcna-pkg -o jsonとhelm history web -n kcna-pkgで、リリースの状態とリビジョンを確認します。
kubectl kustomize <디렉터리>はクラスターに手を加えず組み立て結果だけを表示するので、適用前の確認に向いています(プレースホルダーはディレクトリです)。
公式ドキュメント: Helm Charts・Kustomizeリファレンス

パッケージング作業場のネームスペースを開く

ネームスペースkcna-pkgを作成してください。以降、helmのリリースとkustomizeの出力は、すべてこのネームスペースにデプロイされます。

ネームスペースはkubectl create namespaceで作成できます。何度実行しても安全にするには、--dry-run=client -o yaml | kubectl apply -f -のパターンを使ってください。

helmでチャートの雛形を生成する

/root/kcna-pkg/webappの位置に、helmのデフォルトチャートを新規作成してください(チャート名はwebapp)。Chart.yamlとtemplates/deployment.yamlが生成されている必要があります。

helm create <경로>は、values.yaml・Chart.yaml・templates/を備えた標準的なチャートの雛形を作ってくれます(プレースホルダーはパスです)。パスの最後の名前がチャート名になります。

valuesを変更して3つでテンプレート展開する

/root/kcna-pkg/webapp/values.yamlのreplicaCountを3に変更したうえで、helm template web /root/kcna-pkg/webappの結果を/root/kcna-pkg/rendered.yamlに保存してください。レンダリングされたDeploymentにreplicas: 3が出ている必要があります。

helm templateは、クラスターに触れずにvaluesを差し込んで、最終的なマニフェストを文字列として出力します。デフォルトのチャートは、replicaCountの値をDeploymentのreplicasに流し込みます。値はsedやyqで修正できます。

チャートをクラスターにインストールする

チャートをリリース名webでネームスペースkcna-pkgにインストールしてください(helm install web /root/kcna-pkg/webapp -n kcna-pkg)。helmのリリース一覧にwebがdeployed状態で表示され、そのリリースが作ったDeploymentが実際に存在している必要があります。

helm install <릴리스> <차트> -n <네임스페이스>は、レンダリングされたマニフェストをクラスターに適用し、リリースを記録します(プレースホルダーは順にリリース、チャート、ネームスペースです)。helm list -n <ns> -o jsonで状態を確認できます。helmが作ったオブジェクトには、meta.helm.sh/release-nameアノテーションが付きます。

アップグレードで5つに増やす

リリースwebを--set replicaCount=5でアップグレードしてください(helm upgrade web /root/kcna-pkg/webapp -n kcna-pkg --set replicaCount=5)。アップグレード後、リリースのリビジョンは2以上になり、該当Deploymentのspec.replicasは5になっている必要があります。

helm upgradeは、同じリリースの新しいリビジョンを作ります。--setは、valuesファイルを書き換えずに特定の値だけを上書きします。helm history <릴리스> -n <ns>で、リビジョンが上がったかを確認できます(プレースホルダーはリリースです)。

Kustomizeのbaseを手で組む

/root/kcna-pkg/kustomize/baseにkustomization.yamlとdeployment.yamlを作成してください。Deploymentの名前はstore、イメージはnginx:1.27-alpine、replicasは1、セレクターとラベルはapp: storeにそろえます。kustomizationのresourcesは[deployment.yaml]です。kubectl kustomize /root/kcna-pkg/kustomize/baseが成功し、結果にDeploymentstoreが出ている必要があります。

Kustomizeのbaseは、元のマニフェストと、それを指すkustomization.yamlで構成されます。resources:にファイル名を並べます。kubectl kustomize <디렉터리>で、組み立て結果を事前に確認できます(プレースホルダーはディレクトリです)。Deploymentのselector.matchLabelsとtemplateのラベルは、互いに一致している必要があります。

prodオーバーレイで4つ・env=prodを上書きする

/root/kcna-pkg/kustomize/overlays/prodにオーバーレイを作成してください。../../baseをresourcesとして参照し、replicasを4にするパッチと、共通ラベルenv=prodを追加します。そのあとkubectl apply -k /root/kcna-pkg/kustomize/overlays/prod -n kcna-pkgで適用してください。結果として、ネームスペースkcna-pkgのDeploymentstoreは、spec.replicasが4で、ラベルenv=prodを持っている必要があります。

オーバーレイは、baseをresources: [../../base]で取り込み、その上に変更を重ねます。replicasは同じ名前のDeploymentを含むパッチで変更し(patches:)、共通ラベルはcommonLabels:で一度に付けます。kubectl apply -kは、オーバーレイを組み立ててそのまま適用します。

何をどのようにパッケージングしたかを帳簿に残す

/root/kcna-pkg/report.txtに、ちょうど4行を書いてください。helm-release=web、helm-replicas=5、kustomize-replicas=4、kustomize-label=env=prodです。値は実際のクラスターの状態と一致している必要があります。

採点ツールは、この4行を実際の状態と照合します。helmのリリースが作ったDeploymentの現在のreplicas、kustomizeでデプロイしたstoreのreplicasとenvラベルを確認して写してください。推測せず、kubectl get deploy -n kcna-pkgで読み取った値を書いてください。