List vs Cluster Generators: Choosing the Right ApplicationSet for Sync Latency

Short answer

For a 100-item workload across 10 clusters, the Cluster generator will usually produce fewer Application CRs (one per cluster, ~10) than the List generator (one per element, ~100), and fewer CRs generally means less reconciliation work per sync loop. Whether that translates into a consistently lower median sync duration depends on your environment — the generator affects object count, but sync time is dominated by API server latency, repo-server fetches, and cluster state. Measure both under identical conditions before concluding anything.

Likely explanation vs. confirmed facts

Confirmed, well-established behavior:

• The List generator emits one Application per element in elements. The Cluster generator emits one Application per registered cluster secret (labelled argocd.argoproj.io/secret-type=cluster), optionally filtered by a selector.
• The application controller reconciles each Application independently, so total workqueue pressure scales with CR count. All else equal, 10 CRs reconcile faster and with less memory than 100.
• Argo CD exposes controller metrics on the metrics endpoint, including sync duration histograms (available in the 2.x line; exact metric names and labels vary by version, so confirm against your running version's metrics docs).

Likely, but environment-dependent:

• That the Cluster generator's median and p95 sync durations are consistently lower at 100 items/10 clusters. Plausible, but any specific numbers (e.g., "2.3s vs 1.9s median") are illustrative only — do not treat published figures as reproducible without running the comparison yourself.
• Memory savings from fewer CRs. Direction is right; magnitude (claims of 15–30%) is unverified and workload-specific.

How to measure for your case

1. Create two ApplicationSets with identical templates and targets, one List (100 elements) and one Cluster (10 clusters), applied at different times to avoid overlap.
2. Query the sync duration histogram in Prometheus. Check which labels your version exposes — if a generator label is not present, filter by ApplicationSet name instead:

   histogram_quantile(0.95,
     sum(rate(argocd_app_controller_sync_duration_seconds_bucket[10m])) by (le)
   )

3. Compare median and p95 over at least several full reconcile windows, with identical repo content and cluster load.
4. Watch workqueue depth and controller RSS (kubectl top pod -n argocd or container memory metrics) during each run.

Finalizer question

With argocd app delete --cascade=false, the resources-finalizer.argocd.argoproj.io finalizer is expected to be removed by the controller after it processes the deletion without cascading to child resources. If it hangs, the usual causes are the controller being down, the Application's destination cluster being unreachable, or another finalizer/admission webhook blocking removal — not the generator type. Verify with:

argocd app delete myapp --cascade=false
kubectl get app myapp -n argocd -o jsonpath='{.metadata.finalizers}'
kubectl get events -n argocd -w

If the finalizer persists for more than a couple of minutes with a healthy controller, capture kubectl describe app myapp -n argocd and controller logs before forcing removal.

Recommendation

If your 100 list entries are really "the same app deployed to 10 clusters with 10 variants each," prefer the Cluster generator combined with template parameters or a matrix generator — fewer CRs, less controller load, simpler blast radius. Keep the List generator when each element is a genuinely distinct application. One missing detail that would change this: are your 100 items homogeneous (same repo/chart, different values) or distinct apps? If distinct, the Cluster generator alone won't model them.