# Shard the application controller across replicas
env:
- name: ARGOCD_CONTROLLER_REPLICAS
value: "3"
ArgoCD
Topics in this category
ArgoCD
Multi-cluster
Scale with sharding: the application controller can be sharded across replicas, each handling a subset of clusters, and repo-server/redis are scaled for throughput. Tune reconciliation intervals, use webhooks to reduce polling, and use ApplicationSets to manage app sprawl. Monitoring controller load and shard balance is key at large scale.
Real-world example
At 300 clusters, the application controller is sharded across replicas so each handles a portion of the fleet.
Applications
App of Apps
Multi-cluster
The management or hub cluster is where the ArgoCD control plane runs and from which it deploys to other (spoke) clusters. It holds Application definitions and cluster credentials and pushes desired state outward, giving a single control point for the fleet.
Real-world example
One hub cluster runs ArgoCD and deploys to five workload clusters across regions.
Applications
App of Apps
Multi-cluster
Use `argocd cluster list` to see registered clusters with their server URLs, names, and connection status, or view them in the UI settings. Each corresponds to a cluster Secret in the argocd namespace.
argocd cluster list
Real-world example
An operator runs argocd cluster list to confirm the new prod cluster registered and is reachable.
Applications
RBAC
Multi-cluster
Cluster secrets can carry labels (env, region, tier) that ApplicationSet cluster generators select on, so you target subsets and auto-include new matching clusters. Labels turn the fleet into queryable groups for placement decisions.
metadata:
labels: { env: prod, region: eu }
Real-world example
Labeling clusters env=prod lets one ApplicationSet deploy only to production clusters automatically.
Applications
App of Apps
Multi-cluster
The hub's application controller must reach each spoke's Kubernetes API endpoint over the network with valid credentials. Firewalls, VPNs/peering, and private endpoints must permit this. If a spoke API is unreachable, its apps show Unknown and can't sync until connectivity is restored.
Real-world example
A misconfigured security group blocks the hub from a spoke's API, so its apps go Unknown until the rule is fixed.
Applications
Sync & Health
Multi-cluster
Automate rotation of the service-account tokens/kubeconfigs stored in cluster Secrets, prefer short-lived credentials via cloud identity (IRSA, Workload Identity), and manage the Secrets through External Secrets so rotation happens centrally without manual edits. Monitor for expired credentials causing Unknown status.
Real-world example
Cluster access uses workload identity so tokens are short-lived and rotate automatically without manual Secret edits.
RBAC
Applications
Multi-cluster
Drive configuration from cluster metadata: an ApplicationSet template can select values files or overlays by region label, injecting region-appropriate endpoints, sizes, and settings. One template plus per-region values yields correct config per cluster.
template:
spec:
source:
helm: { valueFiles: [ 'values-{{metadata.labels.region}}.yaml' ] }
Real-world example
EU clusters load values-eu.yaml (EU endpoints) while US clusters load values-us.yaml from the same template.
Applications
App of Apps
Multi-cluster
Run ArgoCD in HA mode: multiple replicas of the API server, repo-server, and application controller (sharded), plus a redis HA/sentinel setup. Spread across nodes/zones. This ensures the control plane tolerates node failures and continues reconciling the fleet.
Real-world example
The hub runs HA ArgoCD with redis-ha and multiple controller shards so a node failure doesn't stop deployments.
Applications
RBAC
Multi-cluster
destination.server uses the exact API server URL; destination.name uses the human-friendly cluster name from its Secret. Names are more portable and readable (URLs can change), so referencing clusters by name is often preferred in templates and manifests.
destination:
name: prod-eu # portable; vs server: https://...
Real-world example
Apps reference clusters by name so a changed API endpoint doesn't require editing every Application.
Applications
App of Apps
Multi-cluster
Use AppProjects to restrict which clusters/namespaces each tenant can target, RBAC to scope who can act, and possibly dedicated clusters per sensitive tenant. Network policies and separate credentials further isolate. This limits both accidental and malicious cross-tenant impact in a shared control plane.
Real-world example
A regulated tenant is confined by its project to its own cluster and namespaces, unable to deploy elsewhere.
RBAC
App of Apps
Multi-cluster