ArgoCD Tracking IDについて
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
この記事では、ArgoCDのTracking IDを解説します。Resource Trackingドキュメントを補足するようなものです。後半には、Tracking IDを活用して「Non self-referencingリソース」の管理問題を解決する方法もご紹介します。
ArgoCDのトラッキング方式Label vs AnnotationTracking IDについてTracking IDのフォーマットTracking ID活用: Non self-referencingリソースのUI監視Non self-referencingリソースとはつまり、どういうこと？おまけ: ソースコードから理解するPrune終わりに
ArgoCDのトラッキング方式
ArgoCDでは、Kubernetesリソースを追跡するための主な方法として、以下3つのトラッキング方式が用意されています：
- Label
- デフォルト方式
- というLabelを使う
- Annotation
- おすすめ方式
- というAnnotationを使う
- Label+Annotation
- おすすめ方式
- LabelとTracking IDが同時に扱う
- Labelは情報を示すのみ、トラッキングはAnnotationで行う
詳細は公式ドキュメントをご参照ください：
Label vs Annotation
ArgoCDを利用する多くの現場では、デフォルト方式のLabelが利用されています。デフォルトのLabel は汎用的に使われており、リソースの管理時にオーナーの識別が悪くなる場合があります。
さらに、KubernetesリソースのLabelには63文字列の制限があります。もちろん、多くの組織は63文字列を超えるようなLabelを使用しないと思いますが、本記事で述べる「Non self-referencing」リソースの扱いで、AnnotationまたはLabel+AnnotationはLabel方式より優れる効果を発揮できるため、Annotation方式の使用を勧めます。
どうしてもLabelを使用しないといけない場合は、CustomLabelを利用することをおすすめします。例えば、 。以下はCustomLabelの設定例を示します。
参考情報ですが、2024年のArgoCon参加者による投票で、ArgoCD設定の「Tierランキング」では、Resource Tracking（Annotation方式）が満場一致で「デフォルト設定にすべき」として評価されました。詳細は以下の記事をご覧ください：
Tracking IDについて
argocd v2.2以降、Annotation方式のトラッキング機能が追加されました。Annotationまたは、Label+Annotationを利用しているArgoCDでは、全ての管理下リソースに というAnnotationが付与されます。
Tracking IDのフォーマット
Tracking IDの形式は以下の通りです。
そのうち、 の値が同じでるリソースは同一ArgoCD Applicationのリソースとして、UI上に表示されます。このフォーマットに適合していない場合、該当リソースはArgoCD UI上から表示が消えてしまいます。
Tracking ID活用: Non self-referencingリソースのUI監視
Non self-referencingリソースとは
ArgoCDの「Non self-referencing」リソースとは、Tracking IDがそのリソース自体を参照していないリソースを指します。
例えば、以下はTracking IDがリソース自身を指している場合（Self-referencing）の例です：
ご覧の通り、これはFluent BitのDaemonSetです。そのうち、以下の情報が得られます。
- ArgoCD Application名:
- (Kubernetes API )Group:
- (Kubernetes API) Kind:
- Namespace:
- DaemonSet Name:
このリソース自体も Namespaceにある名前がであるですので、このリソースはSelf-referencing リソースと言えます。
一方で、以下のように、Tracking IDが別のAPIリソースを指している例では、Non self-referencingリソースとなります：
YAML通り、これは Namespaceにあるというです。
しかし、が指すのは別API（KubeVelaのCustom Resource）であり、リソースそのものとの一致はありません。
実際、前述のKubeVelaのように、実リソースのマニフェストは別Application Controllerによって生成・管理され、ArgoCDはあくまでKubeVelaのCustom Resourceのみを管理しているケースでは、ほとんどのリソースがNon self-referencingリソースに該当します。
つまり、どういうこと？
ArgoCD Application Controllerの仕様上、Non self-referencingリソースはすべて監視対象から除外されます。つまり、Non self-referencingリソースはUI上で表示されるだけで、ArgoCD ApplicationのSync Statusには一切影響を与えません。
ただし、Resource Trackingの方式としてLabelを選択した場合は、すべてのリソースがSelf Referencingリソースとして扱われます。Non self-referencingリソースが識別されるのは、Resource Trackingの方式がAnnotationまたはLabel+Annotationの場合に限られます。
これは何を意味するかというと、Label方式を採用した場合、先述のKubeVelaを使用する構成では、ArgoCD ApplicationのSync Statusは常にとなり、KubeVelaによって生成されたリソースはPruneの対象となってしまいます。これは、KubeVelaによって生成されたリソースがArgoCD Applicationのmanifest pathに含まれていないためです。
以下はLabel方式とAnnotation方式を使った実例です
- Labelを使った場合、Sync Statusが、SyncOptionにPruneを指定すると、生成リソースが消されてしまいます。
- Annotationに変えたらオールグリーンです
おまけ: ソースコードから理解するPrune
Application Controllerの中に、Applicationの現在のマニフェストと実際のマニフェストを比較する関数CompareAppStateでは、RequiresPruneは以下のように判定されます：
このように、というブール変数が判定に重要な役割を果たしています。
次に関数の実装を見てみましょう。
この関数は、トラッキング方式がLabelの場合()は常にを返し、それ以外の場合は実リソースの情報とTracking IDを比較して判定を行います：
終わりに
以上で、Resource Trackingドキュメントの補足説明を終わります。Tracking IDは非常に有用な機能で、当社の多くのプロジェクトですでに活用されています。皆様のプロジェクトでもぜひ活用をご検討ください。
SRG では一緒に働く仲間を募集しています。
ご興味ありましたらぜひこちらからご連絡ください。