同一クラスタ上でのFluxCDとArgoCDのリソース最適化の話

Transcript

1. 同一クラスタ上での FluxCDとArgoCDの リソース最適化の話 石川雲(Kumo Ishikawa) 株式会社サイバーエージェント メディア統括本部 サービスリライアビリティグループ(SRG) ishikawa_kumo@cyberagent.co.jp
2. 自己紹介 • 石川 雲(いしかわ くも) • 2023年11月サイバーエージェント中途入社 • 全社横断SRE組織に所属 • 現在Ameba Platformチームで活動中 x: @ishikawa_kumo
3. テーマ: 水平スケーリングと Podの分散
4. スコープ: AmebaのEKS
5. 1.現状 2.問題 3.解決 4.まとめ
6. 現状 AmebaのEKS運用 ❏ Develop/Staging/Production ❏ AmebaBlogと関連サービス ❏ Shared ❏ CI/CD関連ワークロード
7. 現状 AmebaのCI/CD
8. 現状 AmebaのCI/CD Platform Team Dev Team
9. 現状 AmebaのCI/CD ① ② ③ ④ ⑤
10. 現状 AmebaのArgoCD Applicationの構造 ❏ ArgoCD Applicationの単位: MicroService ❏ MicroService Appsの単位: KubeVela Application MicroService App 1 App 2
11. 現状 KubeVelaのメリット ❏ Dev Team: 最小の知識でコンテナを管理する ❏ Platform Team: テンプレート管理する CNDT 2021 シングルクラスターマルチテナン シーを目指しているEKS上で kubevelaの運用をしてみた
12. 現状 KubeVelaのメリット ❏ Dev Team: 最小の知識でコンテナを管理する ❏ Platform Team: テンプレート管理する KubeVelaのデメリット ❏ ArgoCD Image Updaterが使えない ⇨ 代わりにFluxCD Image Updaterを使った
13. 現状 ArgoCD Image Updaterが使えない ❏ 2021~2022: ArgoCD Image UpdaterはCustomResourceに対応していない ❏ Kustomize/Helmにのみ対応 ❏ 当時は本番で使えないと判断 ❏ 2023~: Kustomize Image Transformerで頑張ればなんとかなりそう ❏ Custom image field type: image=xxx:yy O ❏ Custom image field type: image: xxx, tag: yy X ⇨ 今でもFluxCD Image Updaterを使っている
14. 1.現状 2.問題 3.解決 4.まとめ
15. 問題 Ameba EKS上の変化 ⇨ 処理限界が来ている
16. 問題 問題1: ArgoCD UI上パフォーマンス悪い、同期が遅い ➢ パフォーマンスチューニングが足りない チューニングに関しては以下の記事と動画 CloudNative Days Winter 2024 プレイベント 記事: HA構成のArgoCDパ フォーマンス最適化への道
17. 問題 問題2: FluxCDのコンポーネントがよく落ちる・Image更新されない (本題) ➢ Node メモリ不足でFluxCD Evict ❏ ArgoCD Application Controller Pod単体のメモリが2~3GB超え ❏ 開発目的でNodeのサイズが小さい(4GB) ❏ FluxCD Pod分散配置がない、ArgoCDと同NodeにスケジュールされるとEvict
18. 1.現状 2.問題 3.解決 4.まとめ
19. 解決 1. 利用可能のメモリを増やす ❏ Nodeサイズアップ ❏ Argo/FluxはNodeAffinityで制限 2. Podのメモリを分散させる ❏ Argo/Flux 水平スケーリング ❏ メモリ消費が多いPodはPodAntiAffinityで制限
20. 解決 1. 利用可能のメモリを増やす ❏ Nodeサイズアップ ❏ Argo/FluxはNodeAffinityで制限 2. Podのメモリを分散させる ⇦ 採択 ❏ Argo/Flux 水平スケーリング ❏ メモリ消費が多いPodはPodAntiAffinityで制限
21. 解決 Podのメモリを分散させる3つのステップ 1. Argo 水平スケーリング 2. Flux 水平スケーリング 3. Argo/FluxのPod分散
22. 解決 - ArgoCD水平スケーリング ArgoCD主要コンポーネントの水平スケーリング ❏ Deployment(Repo, Api, ApplicationSet) ❏ Replica数変更+ENV変更(Apiのみ) ❏ StatefulSet(ApplicationController, Redis/Redis HAProxy) Sharding ❏ Replica数+ENV変更 ❏ Redisは変更できない
23. 解決 - ArgoCD水平スケーリング ArgoCDのSharding ❏ Sharding方法: 簡単 ❏ Replica数、ENVなど変更するだけ ❏ Sharding対象: application-controllerのみ ❏ Sharding単位: クラスタ ❏ ShardへResource Assign: 自動・手動
24. 解決 - ArgoCD水平スケーリング Resource Assign: Sharding Algorithmについて ❏ Legacy(v1.8以降): ClusterIDのハッシュでShard決定 ❏ シンプルさを優先する場合 ❏ Round-Robin(v2.8以降, Alpha): ClusterIDでソート後、均等にShard決定 ❏ クラスタ数において均等な負荷分散を求める場合 ❏ Consistent-Hash(v2.12以降, Alpha): 特殊ハッシュでShard決定 ❏ クラスタ数の変更に対する耐性と安定性を求める場合 ❏ 手動Sharding指定: shard-num手動指定 ❏ クラスタ間のリソース数・優先度が不均等な場合
25. 解決 - FluxCD水平スケーリング FluxCD主要コンポーネントの水平スケーリング(Sharding) ❏ Sharding方法: かなり複雑 ❏ 公式のbootstrap用kustomize templateあり ❏ Sharding対象: 全てのController ❏ Sharding単位: Flux Custom Resource ❏ ShardへResource Assign: 手動
26. 解決 - FluxCD水平スケーリング 詳細 ❏ 複数deploymentの作成が必要 ❏ 構成: Main Controller + Shard Controller ❏ Format: <controller>-<shard-num>
27. 解決 - FluxCD水平スケーリング 詳細 ❏ Command Arguments、matchLabelsなどで調整 ❏ annotationでshard/mainロール区別
28. 解決 - FluxCD水平スケーリング 詳細 ❏ ShardへのResource Assignは手動のみ ❏ Shard指定のないリソースはMain Controllerで管理
29. 解決 - Podの分散 ArgoCDのPodAntiAffinity(デフォルト) 例: application-controller 1. application-controllerのPodをそれぞれ異なる Node に分散配置 2. ArgoCDの全てのPodをそれぞれ異なる Node に分散配置
30. 解決 - Podの分散 FluxCDのPodAntiAffinity デフォルト設定がないので、以下のルールを追加 1. 各Shardは異なるNodeに分散配置 2. argocd-application-controllerとは異なるNodeに分散配置 ただし、ShardとMain Controllerは別々で設定
31. 解決 - Podの分散 ShardとMain Controllerは別々で設定 main controller shard1
32. 1.現状 2.問題 3.解決 4.まとめ
33. まとめ ❏ Amebaの特殊ニーズにより、ArgoCD/FluxCDの併用が必要 ❏ FluxCD落ちるの根本原因: Nodeメモリの使い方 ❏ 水平スケーリングでPodごとのメモリ負荷を減らす ❏ PodAntiAffinityの活用で分散配置
34. ありがとうございました