About SRGArticlesRecruitment Information
About SRGArticlesRecruitment Information
HOME/Articles/I made a tier ranking for each ArgoCD setting

I made a tier ranking for each ArgoCD setting

Media Headquarters Service Reliability Group (SRG)@ishikawa_kumo)is.
#SRG(Service Reliability Group) mainly provides cross-sectional support for the infrastructure of our media services, improving existing services, launching new ones, contributing to OSS, etc.
This article isCyberAgent Group SRE Advent Calendar 2024This is the 9th day's article.
This time, we will take a deeper look at the settings of ArgoCD and create a tier ranking based on the importance and usefulness of each setting. If you are already using ArgoCD or are considering using it, please use this article as a reference to consider which ArgoCD settings you should enable.
 

Why Tier Rankings?

ArgoCD is a very powerful GitOps tool, but it has a lot of configuration options. Which settings are really important?Which ones are specific to certain use cases?It is important to determine whether the settings are used in the most common scenarios or rarely used. This ranking was created based on a Lightning Talk given at KubeCon NA 2024.Ranking Argo CD Settings in a Tier List - Gerald Nunn, Red HatThis article is based on the content of the talk and the opinions of the audience (including me). Due to time constraints, the Lightning Talk was only half-completed, so I hope this article will serve as a complement to the content.

Tier Ranking List

I have recreated the Tier List Maker that I presented in the Lightning Talk in Japanese.

Tier 1: Should be the default setting

Resource Tracking
OutOfSync
Persist Health in Redis This setting stores application status information in Redis. This is also an important setting that should be used by default.
5～10%
In most cases, you will not need to manage Application Status information with tools other than ArgoCD, so it is appropriate to enable this setting.
v3.0
The Persist Health in Redis setting can be changed in the following ways:
Self Heal
Scaling a GitOps Platform at Adobe - Aaren J & Ko Uchiyama, Adobe
Don't miss out! Join us at our next Flagship Conference: KubeCon + CloudNativeCon North America in Salt Lake City from November 12 - 15, 2024. Connect with our current graduated, incubating, and sandbox projects as the community gathers to further the education and advancement of cloud native computing. Learn more at https://kubecon.io Scaling a GitOps Platform at Adobe - Aaren J & Ko Uchiyama, Adobe GitOps is a fantastic paradigm to manage your application lifecycle with, but its requirements, especially regarding continuous reconciliation of state, are complex at scale. At Adobe we went from 0 to 10,000 Kubernetes services, composed of dozens of resources each, being continuously reconciled across over 350 clusters in 28 different geos. The journey thus far wasn't without its challenges. The lessons learned provided a wealth of information that will help us tackle the unknowns ahead and we'd like to share them with you. We've gathered technical learnings - such as limitations and scaling requirements of our Kubernetes clusters and ArgoCD - and non-technical - such as effective disaster response and vendor engagement. In this talk I'll show the learnings we've found to be valuable for others who are on their own journey to build and scale a GitOps-driven platform, with some focus on the scaling of our ArgoCD and Argo Workflows based platform through dynamic routing of workloads. Attendees will leave with an understanding of how they might implement and scale a GitOps-driven platform at their organization, so that they can drive their platform to success.
https://www.youtube.com/watch?v=MDXrc_cLVns&t=404s
SyncOption
ExternalSecret
Although this type of overlapping resource management may not occur very often, enabling this setting can help you detect the problem early and prevent it from occurring.

Tier 2: Always useful

IgnoreDifferences This setting allows you to ignore differences in certain fields of a resource. This is especially useful when other controllers modify resources.
IgnoreDifferences
IgnoreResourceUpdates This setting ignores updates to the resource's status field.
argocd-application-controller
For example, you can ignore the following fields:
  • .metadata.ownerReferences
  • .status.refreshTime
IgnoreResourceUpdate
ServerSideApply
SyncOption
ServerSideApply
ClientSideApply
ServerSideDiff
ServerSideApply

Tier 3: Sometimes useful

Resource Tracking
Although it would be nice to make this setting "unnecessary," realistically it should be classified as Tier 3, "occasionally useful."
Aggregated ClusterRole
SelectiveSync
However, please note the following:
  • Syncs are not recorded in history and cannot be rolled back
  • Resource Hooks
CreateNamespace
--reorder none
ui.banner This setting allows you to display a custom banner on the UI. It is useful for displaying important information or warnings to ArgoCD users.
This setting is very useful if you have a large number of ArgoCD users.
v2.8
argocd-application-controller
The CNOE blog concludes that this algorithm has the best performance, but past tuning experiments with ArgoCD conducted by Ameba have shown that this algorithm does not produce the expected results.
If you are interested in more details or results in other cases, please refer to our related blog.
SyncOption
kubectl delete/create
Replace
kubectl replace/create
SkipDryRun
CustomResource
EventLabelKeys
.metadata.labels
AutoRespectRBAC
argocd-application-controller
This setting can be useful depending on your organization's security regulations, as it allows ArgoCD to automatically stop monitoring unauthorized resources and dynamically adjusts resource discovery/sync scope.
Resource Exclusions Inclusions
AutoRespectRBAC

Tier 4: Not very important

Resource CustomLabels Custom labels are used for resource management and identification purposes.
In the Lightning Talk, the presenter said that "you can identify resources owned by each team" even though he has never used it himself. When I researched this setting, the documentation only said the following line:
Custom Labels configured with resource.customLabels (comma separated string) will be displayed in the UI (for any resource that defines them).
getCluster()
Because the actual use is unknown, Lightning Talk classified it as Tier 3, but I think it would be more appropriate to classify it as Tier 4.

Tier 5: Nobody needs it

Resource Tracking(Label)
Resource Tracking (Annotation)
Although we still have many projects that use the Label method, at the Lightning Talk, it was unanimously decided that this setting should be classified as the only Tier 5. Therefore, I also classified it as Tier 5.

Conclusion

We have looked at each of the ArgoCD settings in detail. These tiers are intended for general use cases, but their actual importance may vary depending on your organization or project requirements. We hope this article was helpful to you.
SRG is looking for people to work with us. If you are interested, please contact us here.