自宅のKubernetesクラスタのArgo CDは100以上のApplicationを管理しており、1core / 1GB程度のリソースを常時占有しています。 特に、全てのManifestをJsonnetで記述しているため、Manifestの生成が重く、Reconcileの遅延も大きい状況が続いています。
リソース使用量削減とReconcileの高速化を目指すため、Application ControllerのShardingを試したいのですが、既存のApplicationの移行が面倒なのでまだ手をつけられていません。
そこで、簡単にできる負荷軽減策としてManifest Paths Annotationを試してみたので紹介します。
概要
Argo CDは生成されたマニフェストをコミットハッシュでキャッシュしています。 ここで、リポジトリに新しいコミットが行われると、同じリポジトリを指す全てのApplicationのキャッシュを無効化し、再度Manifestを生成してReconcile処理を行います。
Argo CDのManifest Paths Annotation機能を利用すると、指定したパス以外の変更は無視され、Manifest Cacheも維持されるため、ApplicationのReconcile処理を最小限に抑えることができるようになります。
設定
各Applicationにargocd.argoproj.io/manifest-generate-pathsというAnnotationを追加し、valueとして変更を監視したいパスを書きます。
パスはリポジトリの絶対パスでも、.spec.source.pathからの相対パスでも、どちらでも記述することができます。
基本的には.spec.source.path自体を監視したいと思うので、argocd.argoproj.io/manifest-generate-paths: .とすれば良いでしょう。
また、Shared Componentなどの他のディレクトリも監視対象としたい場合は、セミコロン区切りで記述すると良いです。
私は../componentsによく使うlibsonnetを置いてあるので argocd.argoproj.io/manifest-generate-paths: .;../components のように設定しました。
ApplicationSetを用いている場合は、.spec.template.metadata.annotationsに設定すればOKです。
結果
Application ControllerのCPU使用量を見ると、だいたい半分以下になっていることがわかります。 メモリ使用量はほとんど変わりませんでした。
また、Reconcile回数や所要時間も少なくなっていることがわかります。
まとめ
5秒でできる簡単な変更によってApplication Controllerのパフォーマンスを改善することができました。
Application ControllerのShardingについてもいつか試してみようと思います。
（´-`）.｡oO（既存のリソースを削除することなく別のNamespaceに移すの面倒そうだな〜）
