ArgoCD各設定のTierランキング作ってみました
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
今回は、ArgoCD の設定について深掘りし、各設定の重要性や有用性に基づいて Tier ランキングを作成してみました。ArgoCD を既に使用している方や、これから使用を検討している方は、ぜひこの記事を参考にして、有効化すべきArgoCDの設定を検討してみてください。
なぜ Tier ランキング？Tierランキング一覧Tier 1: デフォルト設定にすべきTier2: 常に有用Tier3: 場合によって有用Tier4: あまり重要でないTier5: 誰も必要としない終わりに
なぜ Tier ランキング？
ArgoCD は非常に強力なGitOpsツールですが、その設定オプションも非常に多いです。どの設定が本当に重要で、どれが特定のユースケースに限定されるのか、あるいはほとんど使用されない設定なのかを見極めることが重要です。
このランキングは、KubeCon NA 2024のLightning Talk Ranking Argo CD Settings in a Tier List - Gerald Nunn, Red Hat の内容と、その場の聴講者(私もその一人)たちの意見に基づいています。 Lightning Talk は時間の制約により半分しか進行しませんでしたので、この記事がその内容を補完する役割を果たせればと考えています。
Tierランキング一覧
Lightning TalkでプレゼンしたTier List Makerを日本語で再現しました。
Tier 1: デフォルト設定にすべき
Resource Tracking(Annotation)
にAnnotationを使用する設定です。これは非常に重要な設定で、デフォルトで有効にすべきです。 その理由の一つは、デフォルトの 方式である Label が持つ制約にあります。Kubernetes の Label には 63文字という制限があり、長い名前のリソースや深くネストされたリソースを扱う際、この制限に簡単に達してしまうことがあります。
にAnnotationを使用する設定です。これは非常に重要な設定で、デフォルトで有効にすべきです。 その理由の一つは、デフォルトの 方式である Label が持つ制約にあります。Kubernetes の Label には 63文字という制限があり、長い名前のリソースや深くネストされたリソースを扱う際、この制限に簡単に達してしまうことがあります。
もう一つの理由は、Label がコピーされる性質にあります。例えば、ArgoCD で大きめの Operator コンポーネントを管理する場合、「なぜ のリソースが発生するのか」と疑問に思うことがあるでしょう。この原因の一つは、Tracking 用の Label がコピーされることで、ArgoCD Application の SourcePathに存在しないリソースまでTracking 対象になってしまうからです。このような問題を防ぐためにも、Annotation を用いる設定が推奨されます。
Persist Health in Redis
ApplicationのStatus情報を Redis に保存する設定です。これもデフォルトで使うべき重要な設定です。
この設定は最初はCLIオプションとして提供されており、Application の Status 情報を に保存する代わりに Redis に保持します。この設定を有効にすることで、 を介さずに直接管理できるため、 や の負荷を約 削減できるとされています。
ほとんどのケースでは、Application の Status 情報を ArgoCD 以外のツールで管理する必要はないため、この設定を有効化するのが適切と考えられます。
の関連実装はこちらです。この設定がまだデフォルトになっていない理由は、in-memory の Redis に Health 情報を保持する場合、と直接やり取りする他のコンポーネントに影響を与える可能性があるためです。そのため、ArgoCD までの間はデフォルト設定化を見送る方針となっています。
Persist Health in Redisの有効化設定は以下の方法で変更可能です。
実はGitOpsCon 2024でも、似ている話がありました。Adobe社の運用事例では、を有効化しただけでなく、 の Timeout を延長する対応も必要だったそうです。これにより、大規模なスケーラビリティ環境での影響を抑えることができたとのことです。
FailOnSharedResource
同じリソースが複数のApplicationで使用・管理されている場合にSyncを失敗させるの一つです。意図しないリソースの共有や競合を防ぐには、この設定は必須になります。
例えば、2つの異なるチームが同じ名前の や を異なる ArgoCD Application で使用しようとした場合、この設定が有効でないと、一方のチームによる変更が他方の Application に予期せぬ影響を与える可能性があります。
このようなリソースの重複管理はあまり頻繁には発生しないかもしれませんが、この設定を有効にすることで問題を早期に検出し、未然に防ぐことができます。
Tier2: 常に有用
IgnoreDifferences
この設定は、リソースの特定フィールドの差異を無視する設定です。他のコントローラーがリソースを変更する場合に特に有用です。
RespectIngnoreDifferences
この設定は、手動同期時にも 設定に従う設定です。
デフォルトでは、手動同期を実行すると 設定が無視され、すべての差異が同期対象となります。
IgnoreResourceUpdates
リソースのstatusフィールドの更新を無視する設定です。
不必要なフィールドの更新を無視することで、 の負荷を軽減できます。ただし、この設定を適用する場合、無視されるリソースの更新が本当に安全であることを十分に確認する必要があります。
具体例として、以下のフィールドを無視できます：
さらに、ArgoCD によって直接トラッキングされていないリソース（例: CronJob によって生成される Pod）についても、設定を活用することで、適切に管理することが可能です。
ServerSideApply
で同期するの一つです。
特に、大規模な Application を適用する場合や、ArgoCD Application が Helm を使用したコンポーネントで構成されている場合に有効です。このようなケースでは、ArgoCD が Tracking 外のリソースを変更適用することがあり、 を利用しないとエラーが発生しやすくなります。
自体もより、競合フィールドを検出しやすいなどのメリットがあります。
ServerSideDiff
v2.10から追加されたの一つです。この設定を使えば、Diffの比較時、をdry-runモードで実行されます。
Tier3: 場合によって有用
InstanceLabelKey
この設定は、用のLabelを変更する設定です。
デフォルトでは、ArgoCD は というLabelを使用します。これは4年前には適切だったかもしれませんが、今はHelmなども同じキーが頻繁に使われています、競合が発生する可能性があります。方式をAnnotationに変更できない場合、せめて使用するLabelを変更すべきです。
この設定を「不要」にしたい気持ちもありますが、現実的には Tier3 の「場合によって有用」に分類すべきでしょう。
IgnoreAggregatedRoles
この設定は、のRuleフィールドの差分を検知したくない場合に使用します。
SelectiveSync
Application内の特定のリソースのみを同期することができます。
多くのリソースを持つApplicationでは、全リソースの同期に時間がかかることがあります。 を使用することで、重要なリソースのみを迅速に更新することができます。
ただし、以下の注意が必要です。
- 同期は履歴に記録されないため、ロールバックはできません
- は実行されません
CreateNamespace
この設定は、ApplicationのSync時に必要なNamespaceを自動的に作成する設定です。手動で名前空間を作成する必要がなくなりますので、場合によって有用です。
しかし、弊社での ArgoCD 運用経験に基づくと、セキュリティの観点から Namespace は厳密に管理されており、この 設定が活用できる場面はほとんどありませんでした。
LightningTalkの会場では、多くの人がをTier2に上げることを支持していましたが、私はTier3が妥当だと考えています。
kustomize build options
をカスタマイズする設定です。特定のユースケースで必要な場合に役立ちます。一般的に利用されるのは、 と です。
をカスタマイズする設定です。特定のユースケースで必要な場合に役立ちます。一般的に利用されるのは、 と です。
ui.banner
この設定を利用すれば、UI上にカスタムバナーを表示することができます。ArgoCD利用者に重要な情報や警告を表示するのに役立ちます。
ArgoCDの利用者が多い場合、この設定は非常に有用です。
ui.cssurl
UIのカスタムCSSを適用する設定です。ブランディングや特別な要件がある場合に有用ですが、ほとんどの組織は使わないと思います。
過去では、ダークモードのために導入した覚えがあったのですが、からダークモードが標準実装されたので、この機能を使わなくなりました。
Sharding(Consistent-hashing)
この設定はv2.13から導入された Shardingアルゴリズムの一つです。
CNOE のブログでは、このアルゴリズムが最もパフォーマンスに優れていると結論づけられています。しかし、過去に Ameba で実施した ArgoCD のチューニング実験では、このアルゴリズムは期待したほどの効果を得られませんでした。
詳細や他のケースでの結果に興味がある方は、関連ブログを参考にしてみてください。
Force
リソースの強制的な更新を行うの一つです。
実行される場合、コマンドが使用され、Applicationにダウンタイムが発生する可能性があるため、慎重に使用する必要があります。
Replace
Forceと似ている設定です。裏では コマンドが使用されるため、Applicationにダウンタイムが発生する可能性があるため、慎重に使用する必要があります。
SkipDryRun
一部存在しないリソースを無視するの一つです。とを別々で同期する場合、この設定を使えば、ArgoCDが失敗しにくくなります。
EventLabelKeys
Argo CD Applicationsのために生成されるKubernetesイベントに、指定したのキーを追加する設定です。Kubernetesイベントの監視を行う場合、この設定は簡単にイベントを分類することができます。
AutoRespectRBAC
の権限を Kubernetes RBACに基づいて自動的に制限する設定です
ArgoCDが権限のないリソースの監視を自動的に停止し、リソース発見/同期範囲が動的に調整することができます。組織のセキュリティ規定次第、この設定が有用になることがあります。
Resource Exclusions Inclusions
とほぼ同じ目的の設定です。リソース発見と同期範囲を静的に調整することができます。
Tier4: あまり重要でない
Resource CustomLabels
リソースの管理や識別の用途で利用するCustom Labelsです。
Lightning Talk では、発表者自身も利用したことがなく、「各チーム所有のリソースを識別できる」と述べられていました。この設定について調査したところ、ドキュメントには以下の一行のみ記載されています。
Custom Labels configured with resource.customLabels (comma separated string) will be displayed in the UI (for any resource that defines them).
また、ソースコード内での利用箇所は の際のみ確認できます。
実際の用途が不明なため、Lightning Talk では Tier3 に分類されましたが、私としては Tier4に分類するのが妥当だと考えます。
Tier5: 誰も必要としない
Resource Tracking(Label)
デフォルトの 方式である Label ですが、前述の でも触れたように、デメリットが多いです。ただし、すでに Label 方式で運用しているプロジェクトでは、Annotation 方式に移行する際に大きな労力が必要になる可能性があります。
弊社でも Label 方式を利用しているプロジェクトが多く残っていますが、Lightning Talk の会場では、この設定を唯一のTier5に分類することが満場一致で決まりました。そのため、私も同様に Tier5 としました。
終わりに
以上、ArgoCD の各設定について詳細に見てきました。これらの Tier 分けは、一般的な使用状況を想定したものですが、実際の重要性は組織やプロジェクトの要件によって異なる場合があります。この記事が皆様の参考になれば幸いです。
SRG では一緒に働く仲間を募集しています。
ご興味ありましたらぜひこちらからご連絡ください。
