Red Hat’s Fleet Survey Turns Kubernetes Sprawl Into a Governance Problem

Kubernetes fleets are growing faster than the teams running them can govern, according to a new Red Hat survey. In the past year, 85% of organizations scaled their Kubernetes cluster fleets, and 70% now run workloads across multiple cloud providers. That growth did not bring matching visibility: only 17% of IT leaders say they have real-time visibility across all of their clusters, and the resulting blind spots are already showing up as configuration drift, security policy overrides, and burned-out operations teams.

The numbers come from Red Hat’s new State of Kubernetes Fleet Management report, summarized in a July 13 Red Hat blog post by Dan Bettinger, Red Hat’s principal product marketing manager for OpenShift. Red Hat has an obvious commercial interest in the findings: the post’s own prescription is Red Hat Advanced Cluster Management (RHACM), the company’s fleet management product. But the operational pain the survey describes (configuration drift, policy overrides, constant firefighting) is qualitatively familiar to anyone who has run more than a handful of Kubernetes clusters, and it points to a real gap in how most organizations operate at fleet scale.

What Red Hat’s Survey Found

Red Hat frames the core problem as an execution gap: organizations scaled their Kubernetes footprint faster than they matured the practices needed to run it. Once an organization scales past a handful of clusters, the report’s data shows visibility breaking down first: just 17% of IT leaders report real-time visibility across their entire fleet. Without that visibility, configuration drift sets in; the report puts drift at 76% of organizations, with four out of five infrastructure issues tracing back to configuration or change management failures. Under that pressure, governance becomes negotiable: 75% of operators admit they regularly override their own security policies just to keep services running. The human cost follows the same curve. Engineers report burning 65% of their day on unplanned firefighting instead of planned work, 57% describe themselves as burned out, and 62% of IT leaders say Kubernetes complexity is now actively stalling business initiatives, not just slowing down operations teams.

Reactive Teams vs. Policy-Driven Teams

Red Hat’s report draws a sharp line between two operating modes. Reactive teams, the ones firefighting drift and overriding policy to keep things running, report only 12% confidence in their ability to manage Kubernetes predictably. Policy-driven teams, which centralize visibility and enforce configuration and security policy automatically instead of manually, report 89% confidence and suffer three times fewer service disruptions. Red Hat’s prescription for closing that gap is centralized visibility, automated lifecycle management, and consistent policy enforcement, which is also, not coincidentally, the feature list behind Red Hat Advanced Cluster Management: unified observability across any CNCF-conformant distribution (OpenShift, Amazon EKS, Microsoft Azure AKS, Google GKE), automated multi-cluster provisioning and day-2 operations, policy-as-code guardrails, and workload placement that redeploys applications automatically if a cluster fails.

What “Policy-Driven” Fleet Management Actually Means

RHACM’s pitch leans on phrases like “unified control plane” and “guardrails,” language that can sound like marketing shorthand until you look at the architecture most fleet management tools are built around. The pattern is called hub-spoke, and it is documented in detail by Open Cluster Management (OCM), an independent open source project for Kubernetes multi-cluster orchestration.

Hub, Spoke, and Why the Split Matters

In a hub-spoke setup, one lightweight cluster, called the hub, runs the multi-cluster control plane. Every other cluster under management is a managed cluster, and it runs an agent, which OCM calls a Klusterlet, that pulls its configuration from the hub rather than waiting for the hub to push changes down to it. OCM’s own architecture documentation explains the reasoning by analogy to how a single Kubernetes cluster already works: “Imagine in a world where there’s no kubelet in Kubernetes and its control plane is directly operating the container daemons, it will be extremely hard for a centric controller to manage a cluster of 5k+ nodes.” Hub-spoke applies the same fix at fleet scale. The hub only has to persist its intent (this policy applies here, this workload runs there); each managed cluster’s agent is responsible for pulling that intent and making it real locally. Registering a new cluster to the hub is a “double opt-in” handshake: the hub has to accept the cluster, and the cluster has to accept the hub, so a security team can answer “which clusters can actually receive policy from this control plane” with certainty instead of a best guess.

What Happens When the Hub Goes Down

That split has a practical payoff directly relevant to Red Hat’s drift numbers. Per OCM’s documentation, if the hub goes down, for maintenance or a network partition, each managed cluster’s agent keeps actively managing its own cluster until the connection is restored, rather than freezing or reverting. A control plane outage does not have to turn into configuration drift by itself; drift comes from unmanaged manual changes, which is exactly the failure mode Red Hat’s survey is describing.

Where Red Hat’s Tooling Fits, and Where It Doesn’t Have To

None of this means a team has to buy RHACM to fix the problems Red Hat’s survey describes. The hub-spoke pattern OCM documents is available as open source, and Red Hat’s own data suggests the operative variable is not which product a team buys but whether visibility, drift detection, and policy enforcement are automated at all. A platform team evaluating fleet management, whether that means Red Hat Advanced Cluster Management, the upstream Open Cluster Management project directly, or another vendor’s control plane, should be asking the same three questions Red Hat’s own report implies: can we see every cluster’s real state right now, does a configuration change apply automatically everywhere it should, and can a security policy be enforced instead of merely documented.

The Vendor Pitch Deserves Some Scrutiny

Red Hat is not a neutral narrator here. It ran the survey, wrote up the results, and used them to market Red Hat Advanced Cluster Management in the same post. That does not make the underlying numbers wrong, but readers should be clear about what can and cannot be checked from the outside. Red Hat’s blog post does not disclose the survey’s sample size, respondent job titles, company sizes, or which firm fielded it, and the “full report” it links to is packaged as a downloadable ebook whose actual contents a standard fetch could not retrieve, so the methodology itself could not be independently reviewed for this piece. That is a common pattern for vendor-commissioned research, and it is a reason to treat the specific figures (85%, 76%, 62%, and the rest) as Red Hat’s characterization of its own respondent pool rather than an independently audited, industry-wide baseline.

None of that makes the pattern unfamiliar. Drift, overridden policy, and teams that spend their week firefighting instead of building are qualitatively recognizable failure modes for anyone who has operated more than a handful of Kubernetes clusters, regardless of whether the exact share is 76% or something else at a given organization. The more durable part of Red Hat’s report is not the precision of any single percentage; it is the shape of the gap between reactive and policy-driven teams, 12% confidence versus 89%, with three times fewer disruptions, because that gap describes a real operational choice every fleet-running team eventually has to make, regardless of who is selling the tool that helps them make it.

What This Means If You’re Running More Than a Few Clusters

The Warning Signs Are in Red Hat’s Own Numbers

You do not need Red Hat’s survey to tell you whether your organization is in the reactive bucket. If nobody on the team can state the current configuration of every cluster without logging into each one individually, that is the visibility gap the report’s 17% figure describes. If a postmortem keeps turning up “someone changed something and did not tell anyone” as a root cause, that is the drift the report puts at 76% of organizations. If security policies have documented exceptions that outnumber the policies themselves, that is the 75% override statistic playing out locally.

What Policy-Driven Actually Requires

Closing the gap does not require picking a specific vendor first. It requires, in order: an accurate inventory of every cluster and what is actually running on it right now, not in a spreadsheet updated quarterly; a mechanism that applies configuration and security policy declaratively, so a cluster’s state is reconciled back to policy automatically instead of drifting until the next audit catches it; and a placement layer that can move or restart workloads across clusters based on capacity and health without a human paging through a runbook first. Red Hat’s report sells RHACM as the way to get there. The hub-spoke architecture underneath is the actual mechanism, and it is documented as open source for teams that want to evaluate the pattern before committing to a specific product.

The stakes for getting this right are rising, not falling. Kubernetes fleets are getting bigger, not smaller, and every additional cluster added to a fleet is another candidate for the same drift and visibility problems the survey describes. The fix its own numbers point to, centralized visibility, automated policy enforcement, and a placement layer that does not wait for a human to notice, does not require anything more exotic than deciding, deliberately, to stop managing fleets by hand.

Sources

• Red Hat Blog: Results for Red Hat’s Kubernetes fleet management survey
• Red Hat: The State of Kubernetes Fleet Management 2026 (report)
• Red Hat Advanced Cluster Management for Kubernetes (product page)
• Open Cluster Management: Architecture documentation
• Featured image source: CERN Computer Center photograph on Wikimedia Commons

Image credit: CERN Computer Center photograph by SimonWaldherr, licensed CC BY-SA 4.0 via Wikimedia Commons; resized and converted to WebP for sxz.io.