はじめに

ChatworkではArgo CDを利用して、Kubernetes上のアプリケーションのデプロイを行っていますが、もともと複数のAWSアカウントに存在するEKSクラスタにそれぞれ個別にArgo CDを準備して、利用している状態でした。いろいろと問題があり、2023年6月に統合が完了したので、その背景や苦戦したところなどを連載として記事にしたいと思います。 (1)では主に背景を、(2),(3)では苦戦したところを、(4)では運用し始めてから調整したところやまとめ、を記載していきたいと思います。

Argo CDの統合の機運の高まり

Kubernetesのデプロイに関して、かなりユーザの多そうなArgo CDですが、弊社でもデプロイにArgo CDを導入しています。

Argo CD自体は結構前から利用していますが、Chatworkの1番大きなアプリケーションのデプロイでも昨年からArgo CDを利用するようになりました。デプロイツールの変更に関しては下記の資料をご確認ください。

speakerdeck.com

弊社におけるEKSクラスタの運用は、2022年の弊社の古屋の資料に記載しているように、新旧EKSクラスタを立ち上げて、Blue/Green方式でアプリケーションを移行しています。 https://pages.awscloud.com/rs/112-TZM-766/images/20220804-AWS-kubernetes_3_Chatwork.pdf

そしてArgo CDは、新旧それぞれのEKSクラスタに個別にインストールして、利用していました。

Argo CDがそのクラスタ内に閉じるので、運用の局所化はできますが、いくつかの問題がありました。

Argo CDのURLがクラスタ移行のたびに変わる
- Argo CDの認証にはGitHub OAuth Appを利用していますが、callbackの設定などがあり、個別に設定する必要がありました
GitHub OAuth AppにAPIがないために、手動で作るしかない
- EKSクラスタは、EKSのバージョンごとに7クラスタ(基本的にはマルチテナントですが、環境/用途でクラスタが分かれている)できますが、それぞれにArgo CDを入れるため、毎回OAuth Appを作成する必要があり(実際にはURLの命名規則に沿ってまとめてつくりますが)、非常に手間でした

また、恒常的に存在するEKSクラスタがないため、EKS移行の際、いくつかのJobなどで移行タイミングを調整したりする必要があり、固定して運用する(Kubernetesのバージョンアップもインプレースで行う)EKSクラスタが必要になりつつありました。さらに、今後EKSクラスタのアプリケーションで、次のバージョンのEKSを作成する構想もあり、その際、EKSを生成するアプリケーションを動かすEKSをどうするのか、という問題がありました。

そのため、Chatworkでは、下記の対応を行い、Argo CDを統合することにしました。

Kubernetesのバージョンアップの際も、Blue/Greeenではなく、インプレースアップグレードを行い、固定して運用するEKSクラスタを作成する
そのクラスタでArgo CDや、固定して動かしたいアプリケーションを動かす

Argo CDの統合に向けて

統合前のArgo CDの構成

上記でも記載しましたが、Argo CDは各EKSクラスタで個別に動いています。またEKSクラスタはいくつかのAWSアカウントに存在しており、Argo CDから別のAWSアカウントのEKSを操作できるようにする必要があります。

また、弊社では、helmfileのvals機能*1を利用して、クレデンシャルなデータをAWS Systems Manager Parameter Storeから取得していますが、これもAWSの各アカウントに値があり、これをクロスアカウントで取得できるようにする必要があります。

ApplicationSetの導入

個別のEKSクラスタで動かしているArgo CDではin-clusterだけ見れればよいので、ApplicationSetを導入する必要がなく、個別にApplicationを作成していました。しかし、統合後は1つのArgo CDで複数のEKSクラスタを管理する必要があり、運用負荷を下げるために、ApplicationSetを導入して、各EKSクラスタのApplicationを自動で作成されるようにする必要がありました。

次回以降の(2),(3)の記事では、これらをどうやって対応したのかを記載したいと思います。