こちらの記事にも記載していますが、DROBE では kubernetes (以下 k8s) のバージョンアップなどを安全に行いたいといったニーズから、クラスターを新しく作って DNS の切り替えでクラスターやその他 OSS のバージョンを更新するという形で運用しています

この記事では、ArgoCD で管理しているクラスター環境下において ArgoWorkflow の Cron 切り替えをどうやって行うかを解説します

ArgoCD とは k8s で GitOps を行うための CD (Continuous Delivery) tool です

ArgoCD を導入すると、Git の特定の repository の状態をクラスターの状態を Sync する事が出来ますが、ArgoCD の UI 上から k8s object を削除することで object が作られていない状態にする事ができます

下記は ArgoCD で管理している ArgoWorkflow の一部のスクリーンショットです 図のように Git で定義されている状態と乖離している Object は黄色いアイコンで表示され、状態がシンクしている Object は緑のアイコンで表示されます

Git の状態はクラスターの理想状態を定義していますが、UI 上からカジュアルにオブジェクトを削除したり再度作ったりする事が出来るので運用時に一時的に object を削除したいというようなオペレーションを簡単に行う事が出来ます

Cluster を複数作って移行するという状況で ArgoWorkflow を Cluster 1 から Cluster 2 に切り替える方法を解説します (といっても内容は非常にシンプルです)

初期状態を Cluster 1 のみが動いている状態とします

切り替え先である新しい Cluster 2 を作ります この時点で ArgoWorkflow の中の CronWorkflow は Cluster 2 には作らないでおきます

これは Cluster 2 が監視している git に CronWorkflow を commit しないという事でも可能ですが、git 的には CronWorkflow を定義してしまい、一度 Sync してしまってから ArgoCD の UI から削除しておくといった形でも簡単に実現可能です

この時点で CronWorkflow の実行時間がくると、まだ Cluster 1 の Workflow が実行されます

Cluster 1 の CronWorkflow を削除して、Cluster 2 の ArgoCD で CronWorkflow を sync します 削除と Sync も git の状態を更新するという型でも可能ですが、ArgoCD の UI からも簡単に行う事が出来ます

これにより、この後に cron の実行時刻がくると Cluster 1 では何も実行されず Cluster 2 で Workflow が実行されるようになり、Cluster 1 の Workflow は実行されません

この状態で挙動を確認し、問題が無い事を確認します もしここで問題があれば Cluster 1 の CronWorkflow を再度 Sync し、そちらを実行するという事も可能です

Step 3 の状態で動作確認を行い問題なければ Cluster 1 を削除します

これで Cluster の移行は完了です

ArgoCD で管理している k8s Cluster の切り替え時に DROBE が行なっている ArgoWorkflow の切り替えオペレーションについて解説しました

ArgoCD が非常に柔軟に k8s object の管理が出来るのでうまく利用する事で、視覚的にも非常にわかりやすい形でシンプルでかつ柔軟なオペレーションが可能になっていると思います

移行の複雑性や好みにもよりますが ArgoCD 上の UI から Object を削除したり Sync したりする事は簡単に出来るので、branch や repo を複数作らなくても Cluster の移行が可能なので、他の構成を変えずに k8s のバージョンだけを更新したいような場合にはこういった方法で移行してしまうのもアリなのではと考えています (Git ops の思想からは多少ずれるかもしれませんが)