オーバーレイを実クラスタへ載せて昇格させる

目標

kustomizeのbaseとオーバーレイを実際のクラスターに載せ、namePrefix、共通ラベル、configMapGenerator、replicasとイメージのパッチが生み出す結果をkubectlで確認します。そして、イメージタグを1行変えるだけでprodへのプロモーションが完了する流れを、自分の手で再現します。

なぜ重要なのか

GitOpsエージェントの仕事の半分はレンダリングです。Argo CDのrepo-serverは、kustomization.yamlを見つけるとkustomize buildを、Chart.yamlを見つけるとhelm templateを実行して、最終的なマニフェストを作ります。つまり、ここでkubectl kustomizeで見る出力が、そのままエージェントが計算するdesired stateです。これを自分で作ってみないと、「Gitにはreplicasがないのに、クラスターには3が入っている」といった状況を説明できません。特にconfigMapGeneratorのハッシュのサフィックスは、実務で非常に重要です。設定が変わるとConfigMapの名前が変わり、名前が変わるとDeploymentのスペックが変わって、ローリングアップデートが自動的に起こります。名前を固定しておくと、設定だけが変わったときにPodが再起動されず、静かに古い値のまま動き続ける事故が起きます。

ステップ

/root/cgoa-envs/ns.yamlにネームスペースcgoa-devとcgoa-prodを宣言し、クラスターに適用してください。
/root/cgoa-envs/base/にDeployment web(replicas 1、セレクターとPodラベルはapp: web、コンテナ名web、イメージnginx:1.27-alpine、envFromでConfigMap web-configを参照)とService web(port 80、targetPort 80)を作成してください。そしてbase/kustomization.yamlに、この2つのリソースとともに、すべてのオブジェクトにラベルapp.kubernetes.io/part-of: cgoa-shopを付ける設定と、configMapGeneratorで名前web-configにリテラルGREETING=helloを入れる設定を書いてください。まだ適用せず、kubectl kustomize /root/cgoa-envs/baseでレンダリングだけを確認してください。
/root/cgoa-envs/overlays/dev/kustomization.yamlにresources: [../../base]、namespace: cgoa-dev、namePrefix: dev-を書き、kubectl apply -kでクラスターに適用してください。
適用結果で、Deployment dev-webのenvFromが指すConfigMapの名前を確認し、同じ名前のConfigMapがcgoa-devネームスペースに実際に存在することを確認してください。(名前の後ろにハッシュのサフィックスが付いている必要があります。)
/root/cgoa-envs/overlays/prod/kustomization.yamlを作成してください。resources: [../../base]、namespace: cgoa-prod、namePrefix: prod-を書き、replicasでwebを3に、imagesでnginxのnewTagを1.27-alpineに固定します。そしてkubectl apply -kで適用してください。
プロモーションを実行してください。prodオーバーレイのイメージタグだけを1.28-alpineに変えて、もう一度適用します。適用後、cgoa-prodのprod-webはnginx:1.28-alpine、cgoa-devのdev-webは引き続きnginx:1.27-alpineになっている必要があります。
/root/cgoa-envs/diff-dev-prod.txtに、devオーバーレイのレンダリング結果とprodオーバーレイのレンダリング結果のdiffの出力を保存してください。

参考

kubectl apply -k <디렉터리>は、kubectl kustomizeの結果をそのまま適用します(プレースホルダーはディレクトリです)。
kustomizationの共通ラベルのフィールドは、kustomizeのバージョンによってlabels:またはcommonLabels:です。動作するほうを使えば構いません。採点は、結果として作られたオブジェクトのラベルを見ます。
diff a b > out.txtは、差があると終了コード1を返します。シェルで中断されないように|| trueを付けてください。
よくある間違い: baseにnamespace:を入れておくと、オーバーレイのネームスペースと衝突して混乱します。ネームスペースはオーバーレイだけで決めてください。

環境用のネームスペース2つ

/root/cgoa-envs/ns.yamlにネームスペースcgoa-devとcgoa-prodを宣言し、クラスターに適用してください。

ネームスペースも宣言型で作る習慣をつけてください。1つのファイルに2つのドキュメントを入れて一度に適用しても、ファイルを分けても構いません。

baseとconfigMapGenerator

/root/cgoa-envs/base/にDeployment web(replicas 1、セレクターとPodラベルはapp: web、コンテナ名web、イメージnginx:1.27-alpine、envFromでConfigMap web-configを参照)とService web(port 80、targetPort 80)を作成してください。そしてbase/kustomization.yamlに、この2つのリソースとともに、すべてのオブジェクトにラベルapp.kubernetes.io/part-of: cgoa-shopを付ける設定と、configMapGeneratorで名前web-configにリテラルGREETING=helloを入れる設定を書いてください。まだ適用せず、kubectl kustomize /root/cgoa-envs/baseでレンダリングだけを確認してください。

configMapGeneratorは、内容のハッシュを名前の後ろに付けます。まだクラスターには載せず、kubectl kustomizeでレンダリング結果だけを確認してください。

devオーバーレイをクラスターに適用

/root/cgoa-envs/overlays/dev/kustomization.yamlにresources: [../../base]、namespace: cgoa-dev、namePrefix: dev-を書き、kubectl apply -kでクラスターに適用してください。

kubectl apply -k <디렉터리>は、レンダリングと適用を一度に行います(プレースホルダーはディレクトリです)。namePrefixが付いた名前で照会しないと見えません。

ハッシュのサフィックスがワークロードにつながっているかの確認

適用結果で、Deployment dev-webのenvFromが指すConfigMapの名前を確認し、同じ名前のConfigMapがcgoa-devネームスペースに実際に存在することを確認してください。(名前の後ろにハッシュのサフィックスが付いている必要があります。)

kustomizeは、生成したConfigMapの名前を参照している箇所まで一緒に書き換えてくれます。DeploymentのenvFromがどの名前を指しているかを見て、その名前のConfigMapが実際にあるかを確認してください。

prodオーバーレイの適用

/root/cgoa-envs/overlays/prod/kustomization.yamlを作成してください。resources: [../../base]、namespace: cgoa-prod、namePrefix: prod-を書き、replicasでwebを3に、imagesでnginxのnewTagを1.27-alpineに固定します。そしてkubectl apply -kで適用してください。

同じbaseでも、replicasとイメージタグが違っている必要があります。オーバーレイのkustomization.yamlだけで解決してください。

イメージタグ1行でプロモーション

プロモーションを実行してください。prodオーバーレイのイメージタグだけを1.28-alpineに変えて、もう一度適用します。適用後、cgoa-prodのprod-webはnginx:1.28-alpine、cgoa-devのdev-webは引き続きnginx:1.27-alpineになっている必要があります。

プロモーションは新しいデプロイではありません。prodオーバーレイでタグの値を1つだけ変えて、もう一度適用すれば済みます。devには触れないでください。

2つの環境のレンダリング結果の差をファイルに保存

/root/cgoa-envs/diff-dev-prod.txtに、devオーバーレイのレンダリング結果とprodオーバーレイのレンダリング結果のdiffの出力を保存してください。

kubectl kustomizeの結果を2つ作り、diffで比較すれば済みます。diffは差があると終了コードが0にならないので、パイプラインで失敗として扱われないように注意してください。