で、AWSのクロスアカウントまわりの話と、ApplicationSetの話を記載しましたが、そのほか細々と対応しつつ、無事に移行目前まで来ました。 (4)では移行目前で、調整した内容に関して記載したいと思います。
主にArgo CDの負荷が高すぎ！問題です。
負荷問題
application controller
Argo CDのapplicaiton controllerはクラスタごとにシャード化して、それぞれの担当クラスタを管理しますが、下記のissueにあるように、きれいに分散せず、偏りが大きくなります。 もちろん台数を増やせばよいのですが、あまり台数を増やしてももったいないので、そのあたりの台数とリソースの調整を行いました。
本番で管理しているアプリケーションの数は250を超えており、EKSクラスタ移行時は一時的に倍になるので、かなり負荷が高い状態になります。 アプリケーションをまとめて減らしたり、Webhookに対応させたり(今まではURLが変わるのでGitHubからのWebhookも対応しにくかった)、負荷を減らす対応も検討しましたが、一旦は横と縦にスケールさせることで対応しています。
結局台数を増やしただけなので、根本的な解決にはいたっていませんが、2.8からはシャーディングのアルゴリズムをラウンドロビンに変えられるようなので、こちらに期待したいと思います。
repo server
こちらもapplication controllerと同様に管理するリソースが多いので、単純に負荷が高くなりがちです。特に(2)で記載したようにpluginの中で、Assume Roleしたりしているので、(おそらく)waitになりがちでもあり、repo-server、helmfile-pluginともにそれぞれのコンテナの負荷が高くなりがちです。
repo serverはautoscaleに対応しているので、それの導入と、そもそもminをあげておく、などの対応を行いました。
まとめ
(1) - (4)と長めの連載になりましたが、複数存在していたArgo CDを無事に統合することができました。
AWSのクロスアカウントまわりの対応は(特にParameter StoreのAssume Roleへの対応)、事例もなく、どのような方法を取るべきなのかが大変でしたが、既存のApplicationやhelmfile側の構成を変えることなく、Argo CD(正確にはplugin)側で吸収できたことで、スムーズに移行できました。
"統合"と記載しましたが、Argo CD自体の機能を試したい場面もあるだろう、ということで、テスト用のArgo CD(EKSのテスト環境を管理するArgo CD)と本番用のArgo CD(EKSの本番環境、stg環境を管理するArgo CD)の2つに落ち着きました。
いろいろと細かい対応は実際にやってみるまでわからなかった問題も多く、また、既存の環境を維持しつつの統合でしたので、なかなか大変でしたが、無事にユーザ利用の移行も完了し、現在では、1つのArgo CDで複数のEKSやアプリケーションを管理している状態です。
