Argo CDがSyncしないみたいな状況になったけど直った一部始終
まとめ
- argocd-application-controllerは1podしかたててはいけない
- なんかSyncがおかしくなったらargocd-application-controllerの残骸が残ってないか確認する
一部始終
ある日、業務で日々使っているArgo CDの様子がおかしくなって、OutOfSyncが増えて、Sync Statusを見ても1日以上syncingみたいな状況でSyncするには、画面から何回かSynchorizeするとようやくsyncするみたいな状況になった。
argocdのコンポーネントの負荷の問題かなと思って、argocd-application-controllerのresourceを見てみると、CPUが2コアから3コアぐらいいっており、なにかがおかしいとissueを漁ってみると、CPUを異常に食ってるみたいのがあった。
I also realized that the application controller Pod is completely hogging the CPU while this is happening.
verupすれば直るみたいのもあったので、とりあえずverupしてみたが直らなかった。 redisがなんかおかしいのかと思って、flushDBしてみたがそれもダメだった。
ちなみに、このとき、argocd-application-controllerが なぜか2台立っていた がそういうものだと思いスルーしていた。(が、これが原因だったということがあとから分かった)
NAME READY STATUS RESTARTS AGE argocd-application-controller-6847958cc6-4ssdm 1/1 Running 0 15m argocd-application-controller-6847958cc6-vjzwg 1/1 Running 0 15m
改めて、ArgoCDでHA構成するには、argocd-application-controllerの起動オプションを変更したりするといいということが分かり、それも試してみたが、特に変わらず。
相変わらずargocd-application-controllerのCPUが異常に高いので、replicasを10個とかに増やしてみたが、やはりダメだった。
そして、なんかissueないかなと思って、見ていると、こんなissueが・・
controllerのreplicas増やしちゃダメじゃん!!!!!!!1111!!
ということで、argocd-application-controllerの数を1つにしたら、無事直りました。
Leader Electionの話
この問題は、別の部署の同僚が既に気づいており、issueにもなっていて、教えてもらいました。pod適当に増やせばいいだろって思ってたけど、裏では、こういうLeader Electionの仕組みで整合性が保たれていたんですね。各種controller様には頭が上がりません。
このissueだと、Leader Electionしても、1podだけしか処理できないから、どうせなら、分散して処理を分け合うみたいな方向がいいなーみたいな流れになっていたと理解しました。