A fleet is simply a group of Kubernetes clusters that you want to manage together, as one thing instead of many separate things.

A Kubernetes cluster is a group of machines that run your applications under the control of Kubernetes. When a company is young, it usually has one cluster, and the team knows every corner of it. As the company grows, one cluster becomes two, then five, then fifty. There might be one for testing and one for production, clusters in different countries, clusters for different business units and clusters at far away shops or factories. Each new cluster seems reasonable on the day it is created. Together they become a fleet, and a fleet behaves very differently from a single cluster.

The trouble is that every cluster needs the same chores. Each one must be created, upgraded, secured, monitored, backed up and eventually retired. Each one needs the same company rules and the same shared tools installed. Doing these chores by hand for one cluster is fine. Doing them by hand for fifty clusters is slow, error-prone and impossible to keep consistent. Fleet management tools exist to turn those chores into something automatic and repeatable.

Nobody plans to manage fifty clusters. They arrive one sensible decision at a time.

Understanding why fleets form helps you design for them. Each reason below is valid on its own, and most organizations have several of them at once. Once you accept that many clusters are normal, the question changes from “how do we avoid this?” to “how do we manage this well?”

Problems that were invisible with one cluster become daily pain with many.

With a single cluster, a skilled team knows its history and its quirks. With many clusters, quirks multiply. One cluster has an older version. Another has a tool installed by hand last year. A third was changed during an emergency and nobody wrote down how. The clusters slowly drift apart until no two are the same, and nobody can say with confidence what is running where.

A handful of words appear in every tool’s documentation. Learn them once and the tools become easier to compare.

No single tool does everything. Fleet management is a stack of layers, and each layer has its own family of tools.

Beginners often search for the one tool that manages a fleet. In practice, the work divides into layers. Some tools create and upgrade the clusters themselves. Others deliver applications and configuration to them. Others enforce rules, connect their networks, collect their metrics and watch their cost. Understanding the layers lets you pick the right tool for each job and avoid expecting one tool to do the work of five.

flowchart TD
  A["Fleet inventory and identity: which clusters exist, who owns them"]
  B["Cluster lifecycle: create, upgrade, scale, retire"]
  C["Delivery: applications and configuration to every cluster"]
  D["Policy and security: rules applied and proven everywhere"]
  E["Networking: services and traffic across clusters"]
  F["Observability and cost: one view of health and spending"]
  G["Backup and recovery: restore and fail over between clusters"]
  A --> B
  B --> C
  C --> D
  D --> E
  E --> F
  F --> G
        

Before anything can be managed, clusters must be created, and created the same way every time.

The first layer of fleet management is the lifecycle of the clusters themselves. Building a cluster by clicking through a cloud console or running a long sequence of commands produces a unique snowflake that nobody can reproduce. Fleet teams instead describe clusters as data: how many machines, which Kubernetes version, which network, which add-ons. A tool reads that description and builds the cluster to match. If a cluster is damaged, the same description can build a replacement.

Cluster API uses the same declarative style as Kubernetes itself, but the things it manages are other clusters.

Cluster API is a project from the Kubernetes community, developed by a special interest group that focuses on cluster lifecycle. Its big idea is elegant. Instead of inventing a separate system for building clusters, it reuses Kubernetes. A small cluster, called the management cluster, runs controllers that understand new resource types such as Cluster, Machine and control plane definitions. You write a resource that says “I want a cluster with three control machines and five worker machines at this version”, and the controllers create the real thing in a cloud or a data center.

flowchart LR
  A["Engineer or pipeline writes cluster description"] --> B["Management cluster with Cluster API controllers"]
  B --> C["Infrastructure provider for a cloud or data center"]
  C --> D["Workload cluster 1"]
  C --> E["Workload cluster 2"]
  C --> F["Workload cluster 3"]
        

Strengths and cautions

Cloud providers and platform vendors package fleet features into managed products, which can save a lot of work.

If most of your clusters run in a single public cloud, the provider’s own fleet features may be the shortest path. Major providers offer ways to group clusters, orchestrate upgrades across them, share configuration and see them in one console. There are also vendor platforms that manage clusters across many clouds and on-premises environments, and products that attach clusters running anywhere to a central management service. The exact names and features change often, so always check the provider’s current documentation before deciding.

Every delivery tool must choose between pushing changes out from the center and letting each cluster pull them in.

There are two basic shapes for delivering configuration to a fleet. In the push model, the central hub holds credentials to every member cluster and applies changes to them directly. In the pull model, each member cluster runs a small agent that reaches out to a trusted source, such as a Git repository or the hub, and applies what it finds. Both work, and each has strengths and weaknesses that matter a great deal at scale and in sensitive networks.

flowchart LR
  subgraph PUSH["Push model"]
    H1["Hub with credentials"] --> M1["Member cluster A"]
    H1 --> M2["Member cluster B"]
  end
  subgraph PULL["Pull model"]
    G["Git or hub source"] --> A1["Agent in cluster C"]
    G --> A2["Agent in cluster D"]
  end
        

Most fleet delivery tools are built on one idea: Git holds the truth, and software makes reality match it.

GitOps means that the desired state of your systems is stored in a version control repository. Software running in or near the cluster continuously compares the repository with the cluster and corrects any difference. Every change is a reviewed commit, every commit has an author and a time, and rolling back means reverting a commit. For one cluster this is neat. For a fleet it is transformative, because one repository can describe every cluster, and the same review process protects them all.

How repositories are organized for fleets

Argo CD is one of the most widely used GitOps tools, and its generator feature turns one template into many cluster deployments.

Argo CD is a GitOps delivery tool and a graduated project of the Cloud Native Computing Foundation. It watches Git repositories and applies what it finds to clusters. A single Argo CD installation can be told about many clusters by registering them, which makes it a natural hub in a push-style fleet design. Its friendly web interface shows every application, its health and whether it matches Git, which is a big help for people who are new to GitOps.

For fleets, the key feature is the ApplicationSet. Instead of writing one application definition for every cluster, you write a single template and a generator. The generator produces a list of targets, and the template is filled in once for each target. When a new cluster is registered and carries the right labels, the generator notices, and the applications appear on the new cluster automatically.

flowchart LR
  A["One ApplicationSet template"] --> B["Generator finds clusters by label"]
  B --> C["Application for cluster 1"]
  B --> D["Application for cluster 2"]
  B --> E["Application for cluster 3"]
  C --> F["Cluster 1 matches Git"]
  D --> G["Cluster 2 matches Git"]
  E --> H["Cluster 3 matches Git"]
        

Things to plan for

Flux takes the pull approach: every cluster runs its own small set of controllers that read from Git.

Flux is another graduated Cloud Native Computing Foundation project for GitOps. Its design is a set of focused controllers that run inside each cluster. One controller fetches sources such as Git repositories or container registries that hold configuration. Others apply plain configuration, render package-style templates and watch for new image versions. Because each cluster reaches out for its own configuration, the central point does not need credentials to every cluster, and clusters behind firewalls or at the edge are easy to include.

Fleet layouts with Flux

For fleets, the common pattern is a repository with a shared base for add-ons and applications, and a small set of folders describing each cluster or group of clusters. Each cluster is bootstrapped once to point at its own folder. Flux also has a feature for managing remote clusters from one place, using stored access, for teams that prefer a hub-style design, so the choice of push or pull is flexible.

Some tools are designed from the start for thousands of clusters, and Fleet from the Rancher ecosystem is one of them.

Fleet is a GitOps engine that comes from the Rancher project, now stewarded by SUSE. It is designed for managing very large numbers of clusters, including small ones at the edge. A central manager reads Git repositories and turns their contents into bundles. A small agent in each downstream cluster pulls the bundles meant for it and applies them. Clusters are organized into groups using labels, and bundles are targeted at groups, so adding a cluster with the right label is enough to give it the standard setup.

GitOps tools copy files to clusters. Propagation tools go further and treat the whole fleet as one place to run workloads.

There is a second family of fleet tools that thinks differently. Instead of syncing a repository to each cluster, they let you create an ordinary Kubernetes resource once in a central control plane and then use policies to spread it to member clusters. The tool takes care of where it runs, can adjust it for each cluster, can collect status from all of them and can move work between clusters when one fails. This feels like using one big virtual cluster made out of many real ones.

Karmada is a well-known example. According to news reports in September 2026, it reached graduated status in the Cloud Native Computing Foundation, the highest maturity level. It keeps ordinary Kubernetes manifests unchanged and adds two main policy resources: a propagation policy that decides which clusters get a workload, and an override policy that adjusts the workload per cluster, region or provider. Open Cluster Management is another community project built around a hub and spokes. It uses an agent in each managed cluster, work resources that carry manifests to a cluster and placement resources that choose which clusters should receive them.

flowchart TD
  A["User creates a normal workload on the control plane"] --> B["Propagation policy chooses clusters"]
  B --> C["Override policy adjusts per cluster"]
  C --> D["Workload runs in cluster in region A"]
  C --> E["Workload runs in cluster in region B"]
  C --> F["Workload runs in cluster at the edge"]
  D --> G["Status collected back to control plane"]
  E --> G
  F --> G
        

With many clusters, the question of where a workload should run becomes a design decision of its own.

Placement is the set of rules that decide which clusters receive a workload. The simplest rule is “all clusters”. More useful rules look at labels such as environment, region, provider or capability. A workload that needs a graphics processor should only be placed on clusters labeled as having one. A service that must stay in a country should only be placed on clusters in that country. Good placement rules are readable, based on labels and safe by default.

Clusters are never completely identical. Overrides let you keep one shared definition and describe only the differences.

A production cluster in Europe may need more replicas than one in a small region. A cluster in one cloud may need a different storage class than a cluster in another. A cluster in a regulated country may need different logging settings. Writing a complete separate definition for each cluster invites mistakes. A better approach is one shared base definition plus small overrides that change only what must differ.

flowchart LR
  A["Shared base definition"] --> B["Override for region A"]
  A --> C["Override for region B"]
  A --> D["Override for edge sites"]
  B --> E["Final definition cluster A"]
  C --> F["Final definition cluster B"]
  D --> G["Final definition edge sites"]
        

The power to change fifty clusters at once is also the power to break fifty clusters at once. Waves make it safe.

The most important fleet safety habit is to never change every cluster at the same moment. Instead, changes move through the fleet in rings. The first ring is a small group of low-risk clusters, such as development or internal ones. If the change behaves well there for some time, it moves to the next ring, and so on until production clusters are updated last. If a problem appears early, the rollout stops while only a few clusters are affected.

flowchart LR
  A["Ring 0: lab and test clusters"] --> B["Wait and verify"]
  B --> C["Ring 1: internal and low-risk clusters"]
  C --> D["Wait and verify"]
  D --> E["Ring 2: small share of production"]
  E --> F["Wait and verify"]
  F --> G["Ring 3: remaining production"]
        

What to check between waves

Even with the best tools, someone will eventually change a cluster by hand. A good fleet notices.

Drift is any difference between the desired state in Git and the live state in a cluster. It usually begins innocently. An engineer fixes an urgent problem directly in a cluster, intending to update Git later, and forgets. Over time, the clusters differ from the plan, and the next automated change may fail or silently undo the fix. Fleet tools can detect drift continuously and respond in different ways.

Emergency access without chaos

Banning all manual changes is unrealistic, because real emergencies demand speed. A sensible approach is a documented break-glass process. Engineers may change a cluster directly in an emergency, the access is logged and time-limited, and the fix must be copied into Git within an agreed time, after which drift detection is clean again. This keeps both speed and discipline.

Rules written once should protect every cluster, and you should be able to prove it.

Security and compliance rules are only as strong as their weakest cluster. Policy engines for Kubernetes, such as Kyverno and Gatekeeper, let you write rules such as “no privileged containers” or “all images must come from approved registries”. In a fleet, those policies are delivered like any other configuration: stored in Git, distributed by your delivery tools and installed on each cluster. Reports from each cluster flow back, so the center can see which clusters comply.

Who may do what, on which cluster, is much harder to answer when there are fifty clusters.

Every cluster has its own access rules, called role-based access control. Maintaining them by hand across many clusters leads to people with leftover access, inconsistent roles and slow removal when someone leaves. Fleet security therefore starts with connecting every cluster to one identity system, so that a person logs in with their company account and receives roles based on group membership. Removing someone from a group removes access everywhere.

GitOps wants everything in Git, but passwords and keys must never sit in Git as plain text.

A fleet needs secrets such as database passwords, access tokens and certificates, and every cluster may need a different set. The tension is clear: the whole fleet idea is to keep desired state in Git, yet secrets cannot be stored openly there. Several patterns solve this, and choosing among them is one of the most important fleet design decisions.

Rotation matters more than storage

Where secrets are stored is only half the question. The other half is how quickly you can change them. When a secret leaks, you must replace it everywhere it is used, fast. Fleets that fetch secrets from a central store can rotate them in one place. Fleets with secrets baked into each cluster face a slow, manual scramble.

By default, clusters are islands. Fleet networking builds bridges when services in different clusters must talk.

Inside one cluster, pods find each other easily. Between clusters, there is no such automatic discovery. If a service in one cluster needs to call a service in another, you must decide how. Some fleets keep clusters fully independent and expose shared services through ordinary public or private addresses. Others connect cluster networks so that pods can reach each other directly and a service can be discovered across clusters as if it were local.

flowchart LR
  subgraph C1["Cluster 1"]
    A["Client pod"]
    S1["Service backends"]
  end
  subgraph C2["Cluster 2"]
    S2["Service backends"]
  end
  A --> S1
  A -- "cross-cluster link" --> S2
        

When the same application runs in several clusters, something must decide where each user’s request goes.

If an application runs in clusters in three regions, users need to be sent to the best one. That decision happens above the clusters, using global load balancing, geographic DNS or an edge network. The system checks the health of each region and sends users to the nearest healthy one. If a whole region fails, traffic shifts to the others. This is the user-facing half of multi-cluster resilience, and it needs to be tested as carefully as the cluster half.

flowchart TD
  U["Users"] --> G["Global traffic layer with health checks"]
  G --> R1["Cluster in region 1"]
  G --> R2["Cluster in region 2"]
  G --> R3["Cluster in region 3"]
  R2 -. "region fails" .-> X["Marked unhealthy, traffic moves to others"]
        

You need to see every cluster at once, without jumping between fifty separate dashboards.

Each cluster produces metrics, logs and traces. If each cluster keeps its own data in its own tools, understanding the fleet means opening dozens of screens. Fleet observability gathers data into shared places. A common design keeps a small collector in each cluster that forwards data to a central platform, or keeps data locally and lets a central query layer search across all clusters. Both approaches aim at the same result: one dashboard where you can compare clusters side by side.

flowchart LR
  A["Cluster 1 collectors"] --> D["Central metrics store"]
  B["Cluster 2 collectors"] --> D
  C["Cluster 3 collectors"] --> D
  A --> E["Central log store"]
  B --> E
  C --> E
  D --> F["Fleet dashboards and alerts"]
  E --> F
        

Labels make fleet data useful

Every metric and log line should carry the name of the cluster, its region, its environment and its owner. Without these labels, data from many clusters becomes a muddle. With them, you can ask fleet questions such as which clusters in Europe have the highest error rate, or which clusters have restarted pods in the last hour.

A fleet can hide a lot of waste. Seeing cost by cluster, team and workload is the first step to reducing it.

Every cluster has a baseline cost before any application runs: control plane fees, base machines, load balancers, monitoring and storage. Multiply that by fifty clusters and the baseline is substantial. On top of that, over-sized machines, idle test clusters and forgotten experiments quietly add up. Fleet cost management starts with allocation: tagging every resource so you know which team or product owns each cluster, then measuring how much of the paid capacity is actually used.

A fleet gives you more places to run, which only helps if you can actually recover into them.

Disaster recovery in a fleet has several layers. First, you must be able to rebuild a cluster from its description, which declarative lifecycle tools provide. Second, you must be able to restore its applications and configuration, which GitOps provides. Third, you must be able to restore its data, which needs backups and replication. Many teams have the first two and forget the third, which is where the real loss occurs.

The way you connect management clusters to member clusters shapes your reliability, security and scale.

flowchart TD
  subgraph T1["Single hub"]
    H1["Hub"] --> A1["Members"]
  end
  subgraph T2["Regional hubs"]
    H2["Global control"] --> R1["Regional hub 1"]
    H2 --> R2["Regional hub 2"]
    R1 --> A2["Members in region 1"]
    R2 --> A3["Members in region 2"]
  end
  subgraph T3["Peer clusters with no hub"]
    P1["Cluster"] --- P2["Cluster"]
    P2 --- P3["Cluster"]
  end
        

The hub is the most powerful and most dangerous part of a fleet. Treat it that way.

The management plane holds the desired state, credentials or agents for every cluster, and the power to change them all. Losing it means losing control. Compromising it means an attacker controls everything. Yet teams often treat the management cluster casually, running it with the same care as a test cluster. A mature fleet protects it more carefully than any other cluster.

Clusters in shops, factories and vehicles live in conditions that cloud data centers never face.

An edge fleet may contain hundreds or thousands of small clusters, sometimes a single machine each, in places with weak or intermittent connectivity. Nobody is there to fix them physically. Power cuts happen. Connections drop for hours. The management design must assume that a cluster is often unreachable and must still behave sensibly, and that every operation must be safe to repeat.

Many fleets exist only because of isolation. There are cheaper ways to isolate than a new cluster.

When teams need to be kept apart, the instinctive answer is one cluster per team. That gives strong isolation but costs overhead and adds to the fleet. There are two lighter options. Namespaces divide one cluster into logical sections with quotas and access rules. Virtual clusters create a lightweight, separate Kubernetes control plane for each tenant inside a shared host cluster, which feels like a private cluster at much lower cost. Choosing among the three is a trade between isolation strength and cost.

Each fleet tool grew from a different need, so each one is strongest at a different job.

No single product covers every fleet task. Some tools are excellent at delivering applications, some at creating and upgrading clusters, some at spreading one object to many clusters, and some at enforcing rules. The table below compares the families discussed in this guide. Treat it as a map of strengths, not a ranking, because the best choice depends on your size, your team and your existing habits.

Choose by answering a few honest questions about your size, your people and your risks.

Picking a tool because it is popular is a common way to end up with a platform nobody wants to run. A better way is to start from your own situation. The questions below lead you toward a sensible starting point, and you can always change later because the desired state lives in Git rather than inside the tool.

Nobody builds a fleet in a day. A staged path keeps risk low and lets the team learn as the fleet grows.

Most fleets begin as a single cluster that gradually became several. The goal is to add structure step by step, proving each step before taking the next. The path below works for most organizations, whether they are starting fresh or tidying an untidy collection of clusters.

Setting up a fleet is the easy part. Living with it every day is where the real work lives.

Once the fleet exists, the platform team’s life is made of repeating tasks: upgrading versions, rotating certificates, onboarding new teams, retiring old clusters and answering alerts. Good fleets turn each of these into a written, rehearsed routine called a runbook. A runbook is simply a clear list of steps that anyone on the team can follow, even at three in the morning.

Keep the runbooks alive

A runbook that is never used goes stale. Schedule regular rehearsals where a person who did not write the runbook follows it exactly. Every confusing line gets fixed. Store runbooks next to the fleet configuration so that changes to one prompt changes to the other.

Regulated organizations must prove that every cluster follows the rules. A fleet can produce that proof almost automatically.

Auditors ask simple questions: who can access production, which versions are running, were changes approved, and are the rules enforced everywhere? In a hand-built collection of clusters, answering takes weeks of screenshots. In a well-run fleet, the answers are already recorded, because the desired state is in Git, every change is a reviewed commit and the policy engine keeps reports.

A few proven shapes appear again and again in healthy fleets. Learning them saves you from reinventing them.

Many fleet failures repeat the same few mistakes. Recognize them early and avoid the pain.

If you remember only a short list, remember these habits.

When something goes wrong in a fleet, the same few causes explain most cases. Check them in order.

The shape of fleets differs by industry, but the lessons are surprisingly similar.

Quick answers to questions beginners ask most often.

You do not need a heavy platform, but a GitOps tool and consistent labels pay off even at three. They are the habits that make growth painless.

It is simpler to manage but riskier, because one failure or one bad upgrade affects everything. Many organizations choose several clusters for isolation, regions and legal reasons.

Pull is usually safer and scales better because members need no inbound access and hold their own credentials. Push is simpler to picture and fine when the network is open and the fleet small.

Yes, if each handles a different job, such as one for creating clusters, one for delivering applications and one for policy. Avoid two tools managing the same objects.

In well-designed fleets, members keep running their workloads with the last known state. You lose the ability to make fleet-wide changes until the hub returns, which is why backups and recovery rehearsals matter.

Keep secret values in a dedicated secret store and let each cluster fetch what it needs, or store them encrypted in Git. Never place plain values in repositories.

By upgrading one ring at a time, starting with development, checking health between rings and keeping a way back. Never upgrade the whole fleet on one day.

A fleet is about managing clusters: creating, configuring and governing them. Multi-cluster networking is about letting applications in different clusters talk to each other. You can have one without the other.

Label everything with owner and purpose, report cost per cluster and team, remove idle clusters and share common services instead of duplicating them.

Only if you want to create and upgrade clusters as Kubernetes objects. If your cloud provider’s managed service already does that well, you may not need it.

Offer templates for clusters and namespaces, enforce rules with policy, and give teams limited access to only what they own.

List your clusters, give each a name, an owner and labels, and start describing the shared baseline in Git. Everything else builds on that.

Managing many clusters is a discipline of describing, placing, rolling out and watching.

A fleet is a group of clusters managed as one. Its tools fall into layers: creating clusters, delivering content, propagating objects, enforcing rules, connecting networks and observing everything. Choose one tool per job, describe everything in Git, use labels to choose targets, roll out in rings and protect the small hub that coordinates it all. Do these things and the number of clusters stops mattering to the people running them.