gitを直せばクラスタが追ってくる

このラボは本物のArgo CD上で動きます

VMの中でk3s + Argo CD + gitサーバーが実際に動いています。gitにコミットすると、 Argo CDがそれを読んで本当にデプロイし、誰かが手で直すと本当に元に戻します。

CGOAコースのほかのラボが動く偽物のクラスターには、Argo CDがありません。そのため、ドリフトも自己修復も起こり得ませんでした。GitOpsで学ぶべきことのすべてが抜け落ちていたわけです。

最初に起動するまで4–5分かかります。

用意されているもの

작업 사본   /srv/gitops              여기서 고치고 커밋·푸시합니다
원격        git://gitd.gitsrv.svc.cluster.local:9418/app.git
Argo CD     argocd 네임스페이스

gitサーバーはクラスター内のPodです。/srv/bareをhostPathとしてマウントしているので、VMからプッシュするとArgo CDがすぐにそれを見ます。

目標

GitOpsの4つの動作を自分で起こして確認します。デプロイ、変更の追跡、ドリフトの検知、自己修復です。

なぜ重要なのか

GitOpsの核となる主張は1つです。gitが唯一の信頼できる情報源であり、クラスターはそのコピーです。

その主張が成り立つには、2つのことが必要です。

gitを直すとクラスターが追従しなければなりません(同期)
クラスターを直すと元に戻らなければなりません(自己修復)

2つ目が特に重要です。自己修復がないと、kubectlで直接直したものがそのまま残り、gitとクラスターが静かに分かれていきます。そうなると、gitはもはや信頼できる情報源ではなく、次のデプロイのときにその差が一度に噴き出します。

ステップ

/srv/gitopsに次のファイルを作成してプッシュし(ファイル: app/deploy.yaml、ネームスペースshop、Deployment web、レプリカ2)、gitサーバーがそれを返すかどうかを記録してください(保存先: /root/cgo/repo.txt)。
Application(名前: shop)を作成し(automated・prune・selfHeal)、実際にデプロイされることを記録してください(保存先: /root/cgo/app.txt)。
gitでレプリカを3に直してプッシュし、クラスターが追従することを記録してください(保存先: /root/cgo/gitchange.txt)。kubectlで直接直さないでください。
selfHealを切ってkubectlでレプリカを変え、OutOfSyncになることを記録してください(保存先: /root/cgo/drift.txt)。
selfHealを再び有効にして元に戻ることを記録してください(保存先: /root/cgo/selfheal.txt)。
gitにConfigMap extraを入れてデプロイしたあと、gitから削除してpruneがクラスターからも削除することを記録してください(保存先: /root/cgo/prune.txt)。
デプロイ履歴を確認して記録し(保存先: /root/cgo/history.txt)、GitOpsでのロールバックとは何かを書いてください。
selfheal=yes、prune=yes、replicas=の3行と説明を書いてください(保存先: /root/cgo/report.md)。

参考

プッシュはgit -C /srv/gitops push origin mainです。リモートはすでに設定されています。
Argoがgitを読み直す周期は、デフォルトで3分です。待ちたくないときは、argocd app get shop --refreshか、kubectl -n argocd patch app shop --type merge -p '{"metadata":{"annotations":{"argocd.argoproj.io/refresh":"hard"}}}'を使ってください。
状態はkubectl -n argocd get app shop -o jsonpath='{.status.sync.status}'で見ます。
selfHealの切り替えは、kubectl -n argocd patch app shop --type merge -p '{"spec":{"syncPolicy":{"automated":{"selfHeal":false}}}}'です。
よくある間違い1: ステップ4でselfHealを有効にしたままドリフトを作ることです。数秒で元に戻ってしまい、OutOfSyncを見られません。
よくある間違い2: pruneを有効にしたまま、gitで誤ってファイルを削除することです。クラスターからも削除されます。そのため、デフォルトは無効です。

gitが信頼できる情報源になるには

/srv/gitopsに次のファイルを作成してプッシュし(ファイル: app/deploy.yaml、ネームスペースshop、Deployment web、レプリカ2)、gitサーバーがそれを返すかどうかを記録してください(保存先: /root/cgo/repo.txt)。

/srv/gitopsで直してコミットしてから、プッシュします。リモートは、クラスター内のgitサーバーです。

Argoがgitを読んでデプロイする

Application(名前: shop)を作成し(automated・prune・selfHeal)、実際にデプロイされることを記録してください(保存先: /root/cgo/app.txt)。

ApplicationにsyncPolicy.automatedを指定すれば、人がsyncを押さなくても済みます。

gitを直せば追従する

gitでレプリカを3に直してプッシュし、クラスターが追従することを記録してください(保存先: /root/cgo/gitchange.txt)。kubectlで直接直さないでください。

kubectlは使わないでください。gitを直してプッシュしたあと、Argoが追従するのを待ちます。

手で直すと分かれる

selfHealを切ってkubectlでレプリカを変え、OutOfSyncになることを記録してください(保存先: /root/cgo/drift.txt)。

selfHealを切ってドリフトを作ってください。有効にしたままだと、数秒で元に戻ってしまい、見られません。

再び有効にすると元に戻る

selfHealを再び有効にして元に戻ることを記録してください(保存先: /root/cgo/selfheal.txt)。

selfHealを有効にすると、Argoがgitの値に戻します。数秒で済みます。

gitから削除するとクラスターからも削除される

gitにConfigMap extraを入れてデプロイしたあと、gitから削除してpruneがクラスターからも削除することを記録してください(保存先: /root/cgo/prune.txt)。

ConfigMapをgitに入れてデプロイしたあと、gitからファイルを削除してプッシュしてください。

ロールバックとはgitを元に戻すこと

デプロイ履歴を確認して記録し(保存先: /root/cgo/history.txt)、GitOpsでのロールバックとは何かを書いてください。

.status.historyにデプロイ履歴があります。ただし、GitOpsで元に戻す方法は別にあります。

何を学んだか

selfheal=yes、prune=yes、replicas=の3行と説明を書いてください(保存先: /root/cgo/report.md)。

selfheal=、prune=、replicas=の3行と一緒に、gitがなぜ信頼できる情報源なのかを書いてください。