The Fleet Management Gap: What Existing Kubernetes Tools Solve, and What They Don't
Carolyn King
The first post in this series argued that the cluster is no longer the unit platform teams operate at, the fleet is. Mercedes-Benz scaled from 200 to roughly 1,000 clusters. CoreWeave runs GPU infrastructure spanning 250,000+ GPUs. That shift is measurable at the industry level too: teams that once managed a handful of clusters now run more than 20 clusters across five or more clouds and environments, according to Spectro Cloud's 2025 State of Production Kubernetes.
It also surfaced the tooling gap this creates: most platform tools were built for individual clusters, not fleets. While fleets can span more than clusters, including VMs, GPU nodes, and edge devices, this post focuses on the Kubernetes tooling landscape. This is where the existing tooling ecosystem is most mature and where the promotion gap is most visible today. It maps the tools that exist today, what each category actually does, and where they stop short.
TL;DR
GPU-scale compute, multi-cloud strategy, data residency requirements, edge deployment, and regulatory pressure are pushing teams to manage a growing footprint of deploy targets. Of those targets, Kubernetes clusters are where teams are feeling the most operational pressure today.
The Kubernetes ecosystem includes a wide range of tools, covering jobs like cluster provisioning, add-on delivery across clusters, and multi-cluster abstraction. They provide different capabilities than what is needed for fleet management.
Argo CD ApplicationSets and Rancher Fleet provide some fleet management capabilities, but they do not offer a fleet-wide failure threshold, progressive delivery controls, or a way to roll back across the fleet as a single unit.
Cluster management versus fleet management
Cluster management and Fleet Management are different problems, solved by different tools. Cluster management covers the clusters themselves: creating them, upgrading them, distributing add-ons to them, and presenting them through a single interface. Fleet Management covers what runs on them: how a release moves across the fleet, in what order, under what failure tolerance, and with what recourse when a rollout goes wrong. The first is a cluster configuration problem. The second is a workload delivery problem.
The market blurs the two. Rancher Fleet uses the word fleet in its name, yet it handles add-on delivery, not rollout progression or recovering a rollout once it's underway. SpectroCloud and Rafay both market their own cluster provisioning and lifecycle platforms as "fleet management" too. The term "fleet" is doing a lot of work, and not always the same work twice.
The four categories, only one of which is fleet management
Of the four categories below, three are forms of cluster management. The fourth, fleet management, is not.
1. Cluster provisioning and lifecycle: Creating, upgrading, and deleting clusters. Cluster API, an open-source CNCF project, brings declarative, provider-agnostic APIs to cluster lifecycle management. SpectroCloud manages full-stack Kubernetes lifecycle from cloud to edge. Rafay's Kubernetes Operations Platform adds governance, security, and multi-cluster lifecycle management across data centers, clouds, and edge environments.
2. Cluster app and add-on delivery: Pushing applications and add-ons out across many clusters at once. Rancher Fleet, from SUSE, is a GitOps-based delivery tool that syncs Git repositories out to large numbers of clusters using its GitRepo and Bundle resources.
3. Multi-cluster abstraction: Presenting many clusters through one interface so a single application can run across them. Open Cluster Management, a CNCF project, provides APIs for orchestrating workloads and policies across multiple clusters from a single hub. Karmada, a CNCF incubating project, extends native Kubernetes APIs to schedule and run applications across multiple clusters and clouds without modifying the applications.
4. Fleet management: Moving a new version through the fleet safely. Which clusters go first, how many failures halt the rollout, and what happens to the clusters already updated when it does. No tool in the first three categories answers those questions.
A closer look at cluster app and add-on delivery: ApplicationSets and Rancher Fleet
From the cluster management tools above, cluster app and add-on delivery (category #2) comes closest to what fleet management needs, since it's already in the business of getting workloads out across many clusters. It falls short in a few key ways, covered in detail further down.
ApplicationSets solve templated deployment across many clusters from a single source of truth. Define a generator, a cluster list, label selector, or Git directory structure, and Argo CD produces and syncs an Application per cluster automatically, so adding a cluster means updating the generator, not hand-authoring a new Application. Adoption grew from 66% to 76% of respondents year over year in Argo CD's 2026 user survey, making it one of the most widely used patterns in the ecosystem.
Its beta Progressive Syncs feature can stage rollout order by label, waiting for each group to report healthy before advancing, though it's disabled by default and offers limited visibility beyond individual Application health.
Rancher Fleet solves the same core problem: GitOps-based delivery of apps and add-ons across many clusters via GitRepo and Bundle resources, and its native rollout controls are more mature than ApplicationSets' in one respect: a rolloutStrategy with maxUnavailable, autoPartitionSize, and autoPartitionThreshold supports canary-first, staged batch rollout out of the box, not as a beta feature. Fleet also maintains an audit trail of changes for compliance purposes.
Where both tools break down is everything past getting a release safely staged and rolling:
No fleet-wide failure threshold: Both can limit how many clusters go unavailable within a single rollout batch, but neither has a concept of halting the entire fleet-wide rollout once cumulative failures cross a defined percentage.
No rollback-as-a-unit: Rolling back in either tool means reverting the Git source and letting reconciliation catch up cluster by cluster, with no fleet-scoped view of rollback progress and no single action that halts and reverses a rollout across the fleet as a unit.
No aggregate promotion observability: Both provide per-cluster or per-bundle status, but neither aggregates that into a single view of an in-progress promotion: what percentage of the fleet is on the new version, where failures are concentrated, whether the rollout is proceeding within expected parameters.
Where ApplicationSets and Rancher Fleet Stop
Capability | ApplicationSets | Rancher Fleet |
|---|---|---|
GOVERNING THE PROMOTION | ||
Cumulative failure budget across the whole promotion | ✕ Not available | ✕ Not available |
Automated verification between stages | ✕ Not available explicitly out of scope | ✕ Not available |
Manual approval gate between stages | ✓ Built in manual sync step | ~ Limited paused bundle |
Timeout on a stalled stage | ✕ Not available waits indefinitely | ✕ Not available |
RECOVERING | ||
Halt and reverse across the fleet in one action | ✕ Not available revert Git, reconcile per target | ✕ Not available revert Git, reconcile per target |
Rollback progress visible as one operation | ✕ Not available | ✕ Not available |
FLEET-WIDE VISIBILITY | ||
Aggregate view of an in-flight promotion | ✕ Not available | ~ Limited Prometheus metrics only |
✓ Built in ~ Limited ✕ Not available
Across the organizations already evaluating this space, a few patterns keep showing up: teams treating ApplicationSets or Rancher Fleet as the finish line rather than a starting point, custom scripts quietly filling the failure-threshold gap, and platform teams building their own ad hoc rollback playbooks because no tool does it for them yet. Others have moved past the patchwork entirely: they've identified this gap and are actively evaluating the right technology to ensure successful fleet-wide rollouts.
Where this leaves platform teams
Modern infrastructure can span hundreds or thousands of clusters, much more than existing tools were designed to handle. In fact, according to Argo CD's 2026 user survey, scaling and performance are the top reported challenges among Argo CD users.
As shared in the first post, many orgs are already hitting this scale. A rollout across ten clusters can absorb a lot of manual oversight. A rollout across a thousand cannot.
"Every tool we built to scale Argo CD solved the scale problem we had at the time. App of Apps worked until we had dozens of clusters. ApplicationSet worked until enterprise customers needed real governance: gating, verification, and control over rollback. At some point, patching Argo CD stops being the answer. It's time to think outside the box: keep Argo CD doing what it does best, and let Kargo take on fleet management directly."
— Hong Wang, CEO and co-creator of Argo CD
The next post in this series moves from framework to practice: real-world fleet management scenarios spanning different deployment targets, clusters, VMs, and more, showing what these gaps look like when a rollout is actually underway.
Want to talk through fleet management for your own environment? Book time with an Akuity solutions architect.
