Argo CD は、クラスタの中で動き、Git リポジトリにある YAML を Kubernetes に反映し続けるプログラム。自分で kubectl apply を打つ運用で何に困るか、Argo CD を使うと何が変わるか、何ができて何ではないか、どこで何が動くかを、公式ドキュメントをもとに整理する。

自分で書いた HTTP API（Go）をコンテナの image にして、kind で作ったローカルクラスタに載せる。Dockerfile で image を作って Node に入れ、ConfigMap と Secret の値を環境変数で渡し、Deployment で 3 つ動かし、Service と Ingress でクラスタの外から api.example.com という名前で届くところまでを、実行結果とあわせて確認する。

クラスタの外から Pod までリクエストを届ける。Service の名前で Pod に届くこと、kind のポート転送で Mac から Node に届くこと、Ingress は作っただけでは何も起きず Ingress Controller（Contour）を入れると動くこと、1 つの入口からホスト名ごとに別の Service に振り分けられることを、kind で作ったローカルクラスタで実行結果とあわせて確認する。

Deployment の image を新しいバージョンに書き換えると、Kubernetes は古い Pod を 1 つずつ新しい Pod に入れ替える（Rolling Update）。入れ替えの間もアクセスが途切れないこと、新旧 2 つの ReplicaSet の数が交互に動くこと、存在しない image で入れ替えが止まってもアプリは止まらないこと、kubectl rollout undo で前の revision に戻せることを、kind で作ったローカルクラスタで実行結果とあわせて確認する。

Deployment の replicas は Pod をいくつ動かすかの数。kubectl scale や YAML の書き換えで自分の手で変える方法と、HPA（HorizontalPodAutoscaler）に CPU 使用率を見て自動で変えさせる方法を、kind で作ったローカルクラスタで確認する。減らすときにどの Pod が消えるか、使用率の分母が requests.cpu であること、負荷をかけてから増えるまでの時間と止めてから減るまでの時間の違いを、実行結果とあわせて確認する。

nginx のように動き続けるのではなく、1 回やって終わる処理を Kubernetes で動かす。終了するコンテナを Deployment にすると、起動し直され続けて CrashLoopBackOff になる。Job はコンテナが正常終了するまで面倒を見るデータ、CronJob は決まった時刻に Job を作るデータ。kind で作ったローカルクラスタで、正常終了・失敗とやり直し・毎分の実行・古い Job の削除を、実行結果とあわせて確認する。