Best GitOps stack for multi-cluster Kubernetes?

The "best" GitOps stack for multi-cluster Kubernetes depends heavily on whether you lean toward centralized governance (one control panel ruling everything) or decentralized autonomy (local agents managing themselves).

The industry standard relies on a core GitOps engine paired with cluster lifecycle and secret management tools.

The Two Core Engine Contenders

• Argo CD (Centralized Hub-and-Spoke): Best if your team craves a single pane of glass. A central management cluster holds the credentials and pushes/pulls state to all spoke clusters. It features an incredible UI, granular RBAC, and handles massive application scales, though it concentrates cluster credentials in one central control plane.
• Flux CD (Decentralized Push/Pull Agents): Best for edge computing, high-security zones, and platform engineering. Flux runs modular agents inside every target cluster. Because credentials never leave the local cluster, it provides a tighter security blast radius and requires zero inbound network connectivity to the managed clusters.

The Recommended Multi-Cluster Stacks

1. The Enterprise Centralized Stack: Argo CD + App-of-Apps / ApplicationSets + External Secrets

• Core Engine: Argo CD using ApplicationSets to automatically target and template deployments across dozens or hundreds of clusters dynamically.
• Secret Management: External Secrets Operator or Bitnami Sealed Secrets to safely inject secrets from AWS Secrets Manager, Vault, or GCP into your clusters.
• Cluster Provisioning Layer: Rancher or Cluster API (CAPI) to spin up the underlying Kubernetes infrastructure.
• Why it shines: Unmatched visibility, rich UI out of the box, and perfect for centralized platform teams that need developers to see and manage application delivery from a single dashboard.

2. The Edge & High-Security Decentralized Stack: Flux CD + Flagger + SOPS

• Core Engine: Flux CD utilizing its multi-tenant and OCI artifact capabilities to synchronize cluster state independently.
• Progressive Delivery: Flagger for automated canary releases and blue/green deployments natively integrated with your service mesh/ingress.
• Secret Management: Mozilla SOPS with KMS/PGP encryption, allowing encrypted secrets to live safely right inside your Git repository.
• Why it shines: Complete isolation. If a management cluster goes down or is compromised, your spoke clusters keep running autonomously using their local cached states without needing a central controller calling back home.

The Verdict: Which should you pick?

• Choose Argo CD if you prioritize developer experience, need a powerful web UI, and operate in a trusted cloud environment where a central control plane is easy to secure.
• Choose Flux CD if you run multi-cloud, hybrid, or edge infrastructure (IoT, telecom, manufacturing) where local cluster autonomy and strict inside-out network security are non-negotiable.

To help narrow down the ideal architecture for your setup, tell me:

• Are you deploying across cloud-only (AWS/GCP/Azure), on-prem/hybrid , or edge environments?
• Do you prefer a centralized dashboard for developers, or do you require strict cluster isolation?

For multi-cluster Kubernetes, my default stack in 2026 would be:

Recommended stack

• GitOps/CD:
• Multi-cluster deployment model: Argo CD ApplicationSets + cluster generator. This is specifically recommended by the Argo CD docs for bootstrapping many clusters.
• Networking:
• Cross-cluster networking/service discovery: Cilium Cluster Mesh only if you actually need cross-cluster pod/service connectivity. It supports cross-cluster connectivity, service discovery/load-balancing, and network policy.
• Packaging: Helm + Kustomize
• Secrets: External Secrets Operator + your cloud/Vault secret manager
• Policy: Kyverno or OPA Gatekeeper
• Observability: Prometheus/Grafana + Loki + OpenTelemetry
• Infrastructure provisioning: Terraform/OpenTofu, kept separate from application GitOps

A useful architecture is:

                    Git
                     │
              ┌──────▼──────┐
              │   Argo CD   │
              │  Application│
              │    Sets     │
              └──────┬──────┘
                     │
          ┌──────────┼──────────┐
          ▼          ▼          ▼
       Cluster A  Cluster B  Cluster C
          │          │          │
       Cilium      Cilium      Cilium
          │          │          │
       Apps        Apps        Apps

Why Argo CD over Flux?

For lots of clusters, I'd lean Argo CD because its multi-cluster model is particularly strong: clusters can be registered centrally, and ApplicationSets can select clusters based on labels such as env, region, cloud, or team.

For example:

generators:
  - clusters:
      selector:
        matchLabels:
          env: production
          region: us-east

template:
  spec:
    destination:
      server: '{{server}}'

That gives you a nice separation:

Git repository
  ├── platform/
  │   ├── cilium/
  │   ├── cert-manager/
  │   └── external-secrets/
  │
  └── applications/
      ├── payments/
      ├── frontend/
      └── api/

Cluster metadata
  ├── prod/us-east
  ├── prod/us-west
  ├── staging/us-east
  └── dev/eu-west

Then cluster labels determine placement, rather than maintaining a giant pile of per-cluster manifests.

One important distinction

Don't automatically make all your clusters a Cilium Cluster Mesh. Cluster Mesh creates a shared trust domain and requires mutually trusted clusters; it's excellent when you need cross-cluster networking, but unnecessary if your clusters are deliberately isolated.

If your clusters are independent failure/security domains, I'd use:

Argo CD + ApplicationSets + Cilium (without Cluster Mesh)

If they're effectively one distributed platform:

Argo CD + ApplicationSets + Cilium Cluster Mesh

My picks by scenario

For production, I'd also run Argo CD in HA mode; the current documentation explicitly recommends the HA installation for production.

Bottom line: if I were building a new multi-cluster platform today, I'd start with Argo CD + ApplicationSets + Cilium + Helm/Kustomize + External Secrets + Kyverno, and add Cluster Mesh only when there's a concrete cross-cluster networking requirement.

For multi-cluster Kubernetes, my default recommendation in 2026 is:

🥇 Argo CD + ApplicationSet

Argo CD is the strongest general-purpose choice if you have anything from ~3 to hundreds of clusters.

Why:

• ApplicationSet is specifically designed for multi-cluster application automation. It can generate Applications from cluster metadata, Git directories/files, matrices, and other generators.
• You can label clusters (env=prod, region=us-west, team=payments) and use those labels to decide what gets deployed where.
• Excellent UI for seeing health, sync state, drift, and rollout status across clusters.
• Works naturally with Helm, Kustomize, plain YAML, and OCI-based workflows.
• Strong ecosystem around progressive delivery, policy, secrets, observability, and CI integration.
• ApplicationSet's RollingSync functionality can stage changes across groups of clusters rather than updating everything simultaneously.

A typical stack I'd use:

                    Git
                     │
          ┌──────────┴──────────┐
          │                     │
    Platform repo           App repos
          │                     │
          └──────────┬──────────┘
                     ▼
                 Argo CD
                     │
              ApplicationSet
                     │
        ┌────────────┼────────────┐
        ▼            ▼            ▼
    cluster-a    cluster-b    cluster-c
      prod         prod          dev

My preferred stack

When I'd choose Flux instead

Flux CD is an excellent alternative, particularly if you want a Kubernetes-native, highly composable GitOps system and don't care as much about having Argo's centralized application dashboard.

Flux is especially attractive when you want each cluster to be relatively autonomous. Its multi-tenancy model also has built-in namespace/RBAC isolation mechanisms.

I'd roughly choose:

Argo CD → platform team, many clusters, rich UI, centralized fleet management, application-centric workflows.

Flux → infrastructure/platform engineering team, Kubernetes-native primitives, decentralized cluster ownership, composability.

What I would not do

For a serious fleet, I wouldn't create hundreds of manually maintained Argo Application objects.

Instead, use ApplicationSet + cluster labels:

clusters
├── prod-us-east
│   ├── env=prod
│   └── region=us-east
├── prod-us-west
│   ├── env=prod
│   └── region=us-west
└── dev-us-west
    ├── env=dev
    └── region=us-west

Then ApplicationSets express policies such as:

"Install ingress-nginx on every cluster"
"Install monitoring on every prod cluster"
"Deploy payments to clusters labeled team=payments"
"Deploy this version to 10% of prod clusters first"

The cluster generator can automatically use clusters registered with Argo CD and their labels/annotations, which makes this pattern particularly clean.

Bottom line: If you asked me to build a new multi-cluster Kubernetes platform today, I'd start with Argo CD + ApplicationSet + Helm/Kustomize + External Secrets + Kyverno, and add Argo Rollouts if progressive delivery is important.

If you tell me whether you're managing 5, 50, or 500+ clusters, and whether they're EKS/GKE/AKS/on-prem, I can narrow this down to a concrete architecture.

The industry-standard GitOps stack for multi-cluster Kubernetes relies on a combination of a core continuous delivery engine—either Argo CD or Flux CD —paired with Kustomize or Helm for configuration management, and optionally Crossplane or Cluster API (CAPI) for infrastructure orchestration . The consensus "best" stack depends heavily on whether you prefer a centralized push/hub-and-spoke model or a decentralized pull model across your cluster fleet.

Core Stack Components

• Continuous Delivery Engine: Argo CD (best for centralized visibility, rich UI, and ApplicationSets) or Flux CD (best for lightweight, pure pull-based, highly secure native Kubernetes controllers).
• Configuration Management: Kustomize (template-free base/overlay patching) or Helm (parameterized packaged charts) to structure environment and cluster variations without manifest duplication.
• Infrastructure & Provisioning Bridge: Crossplane or Cluster API (CAPI) to provision the actual multi-cloud/on-prem clusters and cloud resources declaratively via Kubernetes custom resources.

Comparison of Leading Multi-Cluster Approaches

ArgoCD's ApplicationSets with matrix/list generators completely changed how we handle cluster promotion. Pointing a single control plane at 40+ downstream clusters saved us from maintaining separate manifest pipelines for every region.

Flux feels much more robust when you treat Kubernetes as the ultimate API. Having each cluster responsible for pulling its own state means a central outage doesn't stop local reconciliation loops.

To help narrow down the ideal layout for your organization, please share:

• Are you using a central management/hub cluster or looking for fully independent cluster agents?
• What is your preferred template/configuration tool (Kustomize vs Helm)?
• How many clusters are you planning to manage?

There is no single "one-size-fits-all" stack, because the best multi-cluster GitOps architecture depends entirely on your topology, security posture, and team structure.

The two reigning champions of the CNCF landscape—Argo CD and Flux CD —approach multi-cluster management via fundamentally opposing topologies: Centralized Hub-and-Spoke vs. Decentralized In-Cluster Agents.

The Two Core Multi-Cluster Stacks

1. The Centralized Stack: Argo CD + ApplicationSets (+ optional Kargo)

• How it works: A central management (hub) cluster runs Argo CD, holding credentials and connecting outbound to all managed (spoke) clusters.
• Standout Multi-Cluster Feature: ApplicationSets . Using generators (like list, matrix, or cluster generators), a single ApplicationSet manifest can dynamically target and deploy applications across dozens or hundreds of clusters based on labels or server lists.
• Best for: Organizations prioritizing a single pane of glass , developer-facing dashboards, visual drift detection, and centralized RBAC/SSO.
• Trade-offs: The management cluster holds the "keys to the kingdom"—if compromised, the blast radius spans your entire fleet. It also requires inbound network access from the hub to every spoke cluster's API server.

2. The Decentralized Stack: Flux CD + Helm/Kustomize controllers (+ Weave GitOps / Grafana)

• How it works: Independent, modular Flux agents run inside every target cluster, pulling configuration directly from Git/OCI repositories via an inside-out network model.
• Standout Multi-Cluster Feature: Zero Inbound Connectivity / Edge Isolation . Clusters don't need to expose their APIs to a central hub; credentials never leave the local cluster boundaries.
• Best for: High-security/regulated sectors, edge/IoT footprints, air-gapped environments, or platform teams who prefer pure Kubernetes-native custom resource definitions (CRDs) over monolithic UI control planes.
• Trade-offs: Lacks a powerful built-in GUI out of the box (though layers like Weave GitOps or Portainer can bridge this gap); aggregating cross-cluster sync errors requires external observability tooling.

Architectural Recommendations by Use Case

• The Enterprise Developer-First Standard: Go with Argo CD + ApplicationSets + Argo Rollouts . Use this stack if your app developers need self-service visibility, easy troubleshooting through a web UI, and progressive delivery (canary/blue-green) managed visually.
• The Scale, Edge, & Zero-Trust Standard: Go with Flux CD + Flagger + SOPS (for secrets) . Choose this if you manage massive, highly distributed cluster fleets, on-premises infrastructure, or edge nodes where a centralized hub is a security risk or network liability.
• The Hybrid Pragmatist Pattern: Many large enterprises run both by splitting responsibilities: Flux CD bootstraps and manages core infrastructure/add-ons per cluster (networking, cert-manager, security agents) because of its resilience, while Argo CD is made available for product engineering teams to handle application-layer continuous delivery.

Community Perspectives

Argo CD for Visibility

“Argo CD is easier for users to understand, but it requires maintaining a central control plane: access, projects, SSO, cluster permissions, and synchronization policies.”

Flux CD for Decentralization

“Flux CD conversely operates as a set of independent modular agents residing within every single target cluster. it's a completely decentralized GitOps toolkit.”

“For enterprises running thousands of clusters, strict security boundaries, or requiring a lightweight agent model, Flux provides a more scalable and secure architecture.”

To help narrow down the ideal configuration for your infrastructure, tell me:

• Are you deploying across public cloud (EKS, GKE, AKS), on-premises/edge , or a hybrid mix?
• Do your application developers need direct UI access to see deployment statuses, or is everything managed strictly by platform engineers via CLI/CI?

For multi-cluster Kubernetes, the best GitOps stack depends on whether you want a central control plane or a distributed fleet model. The two strongest open-source choices are Argo CD and Flux CD. Both are mature Kubernetes GitOps controllers; the architectural choice matters more than feature checklists.

My default production recommendation for a platform team:

Recommended multi-cluster stack

Git
 |
 |-- app manifests
 |-- cluster config
 |-- policies
 |
 v
GitOps controller
 |
 +--> dev clusters
 +--> staging clusters
 +--> prod clusters


+ Supporting services:
  - Helm/Kustomize
  - SOPS + age/KMS for secrets
  - Kyverno or Gatekeeper for policy
  - Prometheus/Grafana for observability
  - Argo Rollouts or Flagger for progressive delivery

Option A: Argo CD-centric stack (best default for most enterprises)

Use when: you have many application teams, need visibility, RBAC, approvals, and a self-service developer experience.

Stack:

• Argo CD — deployment reconciliation
• ApplicationSets — generate apps across clusters/environments
• Helm + Kustomize — packaging/config overlays
• Argo Rollouts — canary/blue-green deployments
• Kyverno — admission policy
• SOPS — encrypted secrets
• Prometheus + Grafana — health metrics

Strengths:

• Excellent UI and drift visibility
• Centralized multi-cluster management
• Strong app ownership model
• Easier onboarding for developers

Tradeoffs:

• Central control plane becomes an important component to operate
• More opinionated model than Flux

Argo CD's ApplicationSet pattern is particularly useful for fleets where the same app must be deployed across many clusters.

---

Option B: Flux-centric stack (best for platform engineering)

Use when: you want Kubernetes-native, decentralized clusters that reconcile themselves.

Stack:

• Flux CD
• HelmRelease resources
• Kustomizations
• OCI artifact support
• Image automation
• SOPS integration
• Kyverno/Gatekeeper
• Prometheus/Grafana

Strengths:

• Very Kubernetes-native
• Lightweight controllers
• Great for clusters that should operate independently
• Strong fit for edge and large fleets

Tradeoffs:

• Less polished UI experience
• More assembly required for developer self-service

Flux's model is closer to "every cluster owns its own reconciliation loop," which many platform teams prefer for large fleets.

---

My preferred architecture for 50+ clusters

I would usually choose:

Example repo:

platform-gitops/
├── clusters/
│   ├── prod-us-east/
│   ├── prod-us-west/
│   └── staging/
│
├── apps/
│   ├── payments/
│   ├── frontend/
│   └── api/
│
├── infrastructure/
│   ├── ingress/
│   ├── cert-manager/
│   └── observability/
│
└── policies/
    ├── kyverno/
    └── security/

---

Quick decision guide

Choose Argo CD if:

• Developers need a UI
• You want centralized fleet visibility
• You run hundreds of applications
• You need application-level RBAC

Choose Flux if:

• Platform engineers own Kubernetes
• Clusters should be autonomous
• You prefer pure Kubernetes primitives
• You manage edge/isolated environments

Choose both only with clear boundaries (for example Flux for cluster infrastructure and Argo CD for application delivery). Running two GitOps controllers against the same resources usually creates unnecessary complexity.

For a new enterprise multi-cluster platform today, I would start with Argo CD + ApplicationSets + Helm/Kustomize + Kyverno + SOPS + Prometheus/Grafana unless there is a strong reason to prefer a decentralized model.

There is no single "one-size-fits-all" stack, because the best multi-cluster GitOps architecture depends heavily on your team culture, security constraints, and scale . The ecosystem is dominated by two distinct philosophies: Centralized Orchestration (via Argo CD) and Decentralized/Edge-Native (via Flux CD).

Stack Option 1: The Centralized Enterprise Standard (Argo CD-Centric)

Best for organizations that require a single pane of glass , visual feedback, and heavy developer self-service across many regions or cloud providers.

• Core Engine: Argo CD (runs on a management/hub cluster and connects to spoke clusters via secret credentials).
• Multi-Cluster Scaling: Argo CD ApplicationSets (utilizes cluster generators and label selectors to template deployments across dozens of clusters without managing individual application definitions).
• Promotion & Lifecycle: Kargo (orchestrates complex promotion pipelines, moving approved "freight"—images and manifests—across staging, UAT, and multi-region production clusters).
• Progressive Delivery: Argo Rollouts (handles canary and blue/green traffic shifts tied directly to Prometheus/Datadog metrics).
• Config Management: Helm + Kustomize (Argo natively renders Helm and applies Kustomize overlays).

“I’ve deployed both in production at scale. If your users are not Kubernetes experts, the Argo UI is non-negotiable. It bridges the gap between ‘Code’ and ‘Running Pod.’”

Stack Option 2: The Zero-Trust & Edge-Native Fleet (Flux CD-Centric)

Best for platform engineering teams managing large numbers of independent, high-security, or air-gapped/edge clusters where a central control plane shouldn't hold credentials to every spoke cluster.

• Core Engine: Flux CD (lightweight controllers installed independently inside each target cluster; uses an inside-out pull model requiring zero inbound cluster connectivity).
• Multi-Cluster / Fleet Management: Rancher or Plural.sh or Weave GitOps (adds an overarching management layer or UI dashboard to aggregate state and visibility without breaking Flux's localized security boundary).
• Progressive Delivery: Flagger (integrates with service meshes like Istio/Linkerd or Ingress controllers for automated canary releases).
• Config & Image Automation: Flux Helm/Kustomize controllers + Image reflector controllers (automatically detects new container images in your registry and commits/deploys tag updates back to Git).

“Flux CD conversely operates as a set of independent modular agents residing within every single target cluster. it's a completely decentralized GitOps toolkit.”

Key Architectural Trade-offs to Consider

• Security & Blast Radius: Argo CD's hub-and-spoke model means the central management cluster has admin access to all spoke clusters. If the hub is compromised, the entire fleet is at risk. Flux isolates credentials locally to each cluster, meaning a breach in one cluster cannot cascade outward via the GitOps agent.
• Visibility vs. Clutter: Argo CD wins outright on developer experience because of its built-in Web UI. Flux requires an extra layer (like Weave GitOps or Lens) if your non-SRE teams need a visual overview of app health.
• Repository Structure: For multi-cluster harmony, avoid managing a separate Git repository per cluster. Instead, adopt a hybrid or hierarchical repository pattern (e.g., a core platform repo for cluster bootstrapping and shared add-ons, coupled with dedicated app source repos).

To help narrow down the ideal stack for your environment, tell me:

• Are you managing dozens of clusters or thousands (including edge/on-prem)?
• Do application developers need a UI to debug deployments, or is your team CLI/terminal-first?
• Are you bound by strict zero-trust/air-gapped network policies?

If you mean a production multi-cluster Kubernetes platform, my default pick in 2026 is:

🥇 Argo CD + ApplicationSet + Kustomize/Helm

Argo CD is the strongest general-purpose choice when you have multiple clusters, environments, teams, and a need for visibility/RBAC. Its ApplicationSet controller is specifically designed to generate and manage applications across many clusters from templates and Git metadata.

Stack I'd use

Architecture

I'd generally do:

                    Git
                     │
          ┌──────────┴──────────┐
          │                     │
    app-config repo       platform-config repo
          │                     │
          └──────────┬──────────┘
                     │
                 Argo CD
                     │
              ApplicationSet
          ┌──────────┼──────────┐
          ▼          ▼          ▼
       cluster-a  cluster-b  cluster-c
          │          │          │
       K8s apps    K8s apps    K8s apps

A single ApplicationSet can template applications for multiple clusters, and generators can derive targets from cluster metadata or Git structure.

Argo vs Flux

I'd choose Flux instead if your platform team strongly prefers a minimal, Kubernetes-native controller model and doesn't care much about having Argo's UI/application model.

A useful rule:

• Argo CD → best default for platform/enterprise teams, lots of clusters, teams, RBAC, visibility.
• Flux → excellent if you want a more composable, Kubernetes-resource-centric architecture.
• Rancher Fleet → particularly attractive if you're already heavily invested in Rancher/RKE2.
• Sveltos → worth investigating for very large fleets where cluster-add-on/configuration propagation is the dominant problem.

At extreme fleet sizes, don't blindly assume "one giant Argo hub." Real-world community testing has found resource/scaling bottlenecks can emerge around tens of thousands of cached objects, so hub topology and workload partitioning become architectural decisions rather than simple tuning exercises.

My preferred repo structure

For, say, 20–100 clusters:

platform-git/
├── clusters/
│   ├── prod-us-east/
│   ├── prod-us-west/
│   ├── staging-us-east/
│   └── dev/
├── infrastructure/
│   ├── ingress/
│   ├── cert-manager/
│   ├── external-secrets/
│   └── monitoring/
└── apps/
    ├── payments/
    ├── orders/
    └── frontend/

Then use ApplicationSet to express fleet-wide intent, rather than creating hundreds of hand-written Application objects.

Bottom line: if I were starting a new multi-cluster platform today, I'd pick Argo CD + ApplicationSet + Kustomize + Helm + Kyverno + External Secrets + Argo Rollouts, with Terraform/OpenTofu handling infrastructure. It gives you a very strong separation between provisioning clusters, managing cluster configuration, and deploying applications.

If you tell me roughly how many clusters (5 / 50 / 500+), cloud/on-prem, and whether clusters are identical or heterogeneous, I can narrow this down to a concrete architecture.

The absolute best GitOps stack for multi-cluster Kubernetes depends on balancing centralization with fault isolation, but the industry-standard baseline is Argo CD combined with ApplicationSets and Kustomize/Helm , while the preferred lightweight/modular alternative is Flux CD with its Kustomize controllers . For enterprise fleet orchestration, pairing these with Cluster API (CAPI) for infrastructure and Pulumi or Crossplane for cloud resources creates a complete, production-grade platform.

Core GitOps Engine Comparison

• Argo CD : Best overall for visualization, rich web UI, multi-tenant RBAC, and dynamic fleet targeting via ApplicationSets.
• Flux CD : Best for minimal footprint, native Kubernetes extensibility, and decentralized push/pull security across massive edge or hybrid fleets.
• Kargo : Emerging standard for managing promotion pipelines (warehouses and stages) of artifacts and configurations across multi-stage, multi-cluster environments.

Recommended Multi-Cluster Architecture Layers

If you want to tailor this stack, tell me:

• Are you deploying across hyperscalers (AWS/GCP/Azure), on-premise , or edge locations?
• Do you prefer a centralized management cluster (Hub-and-Spoke) or decentralized controllers per cluster?

If you're building a multi-cluster Kubernetes platform today, the stack I'd recommend for most organizations is:

• Argo CD for GitOps reconciliation and application delivery
• ApplicationSets for fleet-wide deployments
• Crossplane for cloud infrastructure as Kubernetes resources
• External Secrets Operator or SOPS for secrets
• Kyverno (or OPA Gatekeeper) for policy
• Prometheus + Grafana + Loki for observability

That combination is widely adopted, scales well, and has a large ecosystem.

Option 1: Platform team managing dozens of clusters (my default recommendation)

GitHub/GitLab
      │
      ▼
 Argo CD (management cluster)
      │
      ├── Cluster A
      ├── Cluster B
      ├── Cluster C
      └── ...

Why it works:

• Excellent UI for operators
• Easy drift detection
• Strong RBAC
• ApplicationSets make it easy to deploy to hundreds of clusters
• Mature ecosystem (Rollouts, Notifications, Image Updater, etc.)

Typical repository layout:

platform/
  clusters/
    prod-us/
    prod-eu/
    staging/
  apps/
    payments/
    api/
    frontend/
  infrastructure/
    ingress/
    cert-manager/
    monitoring/

---

Option 2: Very large fleet (100+ clusters)

If you're operating hundreds of clusters, many platform teams prefer:

Git
 │
 ▼
Flux installed in every cluster

Advantages:

• No central control plane
• Better fault isolation
• Each cluster reconciles independently
• Kubernetes-native architecture

The trade-off is less built-in visibility because Flux intentionally avoids a centralized UI.

---

Option 3: Hybrid (increasingly common)

Many organizations actually run both:

• Flux manages cluster infrastructure

  • CNI
  • CSI
  • monitoring
  • ingress
  • operators

• Argo CD manages applications

This separation keeps platform lifecycle and application lifecycle independent, and practitioners frequently report this model working well in production.

---

Infrastructure provisioning

Rather than using Terraform from CI for everything, a modern GitOps stack often uses:

Git
  │
  ▼
Argo CD
  │
  ▼
Crossplane
  │
  ▼
AWS / Azure / GCP

Crossplane lets developers request resources declaratively:

apiVersion: platform.example.io/v1
kind: PostgreSQL
spec:
  size: medium

instead of writing provider-specific Terraform.

---

Secrets

Good options include:

• External Secrets Operator → best if you already use Vault, AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager
• SOPS + age → encrypted secrets stored directly in Git
• Sealed Secrets → still used, but less common in new deployments

---

Progressive delivery

For safe deployments:

• Argo Rollouts
• Flagger (especially with Flux)

These support canary and blue/green deployments.

---

Policy

For multi-cluster governance:

• Kyverno (simpler and Kubernetes-native)
• OPA Gatekeeper (more flexible with Rego)

Typical policies include:

• Require resource limits
• Block privileged containers
• Enforce image registries
• Require labels
• Restrict host networking

---

My recommended stack

This stack balances operational simplicity with strong support for managing many clusters.

Which GitOps controller should you choose?

• Choose Argo CD if you want a rich web UI, easier onboarding, centralized visibility, and strong multi-cluster application management.
• Choose Flux if you prefer a lightweight, Kubernetes-native, distributed model where each cluster operates independently.
• Choose both if you have separate platform and application teams and want to decouple infrastructure management from application delivery.

If you can share roughly how many clusters you're targeting (10, 50, 500+) and whether you're on EKS, GKE, AKS, or on-prem, I can suggest an architecture tailored to that scale.