Why most enterprises haven’t reached Kubernetes maturity

Buu LamDirector, Community Evangelism

Over 10 years ago, as a Solutions Engineer, I watched organizations start deploying Kubernetes as a side project. It was a skunkworks effort, often run alongside tests of other container schedulers. The real workloads still ran on virtual machines in vSphere, an environment built around service level and recovery time objectives. Everyone played a role in it, not just the server admins. That, if you will, was enterprise-grade.

Then things moved. The public cloud took off, applications were modernized, and Kubernetes became the default way enterprises run containerized applications. The driver was the same as always: commerce, which needed to scale at speed. Businesses wanted to move faster, and I joined many early customers as they tried to make Kubernetes an enterprise platform.

For those customers, the destination was set by the expectations of the business. A skunkworks project is best effort, if that. An enterprise platform has to move with the business and ideally becomes critical to how it competes. Kubernetes has reached that level of expectation, but on its own it isn’t a complete platform the way vSphere is. Its open source foundation is beautiful, but it’s only the start.

New research that F5 commissioned from SlashData shows how big the gap to enterprise is. Of enterprises running Kubernetes in production, 61% hold it to the same or a higher standard than the rest of their IT estate, yet only 38% reach enterprise-grade maturity.

Only 38% of enterprises running Kubernetes in production reach enterprise-grade maturity.

In the report, enterprise-grade means more than a high score. It requires automated admission control, enforced tenant isolation, centralized observability, documented recovery objectives, and failover tested within the last 12 months. The survey scored what teams actually do, not how mature they believe they are, using 445 responses from hands-on practitioners at organizations with more than 500 employees, collected in August 2026.

Most estates are established, not mature

I see the report’s definitions as markers on a journey that everyone is on. I doubt any organization is ever complete, and there are always trade-offs in priorities. The report gives us a snapshot of where enterprises are today. Half of enterprises (51%) land in the established tier, where standards are defined and largely enforced but with visible gaps. Another 11% are still standardizing. Nearly nine in ten (88%) reach the top band in at least one domain, but only 22% do in all four. Even among the 51% of enterprises that score 80 or higher overall, one in four (24%) misses a single prerequisite, which keeps them out of the top tier.

Observability is the piece most often missing. Among those near misses, 36% lack centralized observability and 31% lack automated admission control. Both match what I saw in the field. With most of my customers, whether or not Kubernetes was involved, the gap was observability. Troubleshooting was hard, it pulled in far more people than it should have, and it too often turned into finger pointing.

Admission control matters because of scale. One customer relied heavily on it to govern vSphere because of the size ofits environment. Kubernetes environments scale quickly, and the most-cited challenge in the report is the complexity of managing clusters and environments (39%). Controls that matter at scale matter earlier than most teams expect. Yet only 28% plan to invest in observability in the next 12 months, compared with 42% who plan to invest in security and policy enforcement.

Maturity is a team sport

Over the years, the roles mattered more than I expected. I met the Platform and DevOps teams because they knew and trusted NGINX and wanted to use it. I also met the network and security teams, who wanted to be sure Kubernetes could fit into their enterprise NetOps and SecOps practices instead of creating entirely separate workflows.

One customer did something unnatural at the time: the customer gave its DevOps engineer his own F5 BIG-IP. He learned its ins and outs and got it to do things I’d rarely seen traditional BIG-IP administrators do themselves (shout out to Steven!). That was trust in practice. Success always came from partnership and trust, because enterprise-grade outcomes depend on teams relying on each other, not working around each other.

The research points the same way. Where a dedicated platform engineering team operates Kubernetes and a separate central security team sets policy, 66% of enterprises reach enterprise-grade maturity, roughly double the rate for other arrangements. Only 19% work this way. Breadth matters too: 53% of enterprises that run Kubernetes as a standard platform across the organization reach the top tier, against 25% of those where it sits with a single team.

This is correlation, not proof of cause. Larger, more committed organizations may simply be more likely to divide the work this way. Still, it matches my experience: the teams that share the load, and trust each other with their part of it, are the ones that get to enterprise grade.

AI is getting ahead of governance

I saw the early version of this, too. One company was rapidly deploying machine learning workloads that were becoming critical to the business, and that part of the business was at the center of innovation for an otherwise older company. Speed like that can leave governance behind.

Among enterprises running Kubernetes in production, 45% deploy or serve models, and 86% of those have extended their existing web application firewall (WAF) or API protection to that traffic. AI-specific controls lag. Only 43% inspect agent tools and Model Context Protocol (MCP) traffic, though 49% plan to within 12 months. Mature estates lead on rate limiting and token quotas (80% versus 50%), but that advantage disappears for prompt inspection and MCP traffic. Governance habits built for traditional workloads help, but they don’t cover everything yet.

What the research implies for your stack

The research doesn’t point to a single product. It points to gaps, and the gaps map to roles. Observability starts with telemetry at the edge, which is a platform and network concern. Web application and API protection (WAAP) shows one of the widest technology gaps between tiers, with 69% of enterprise-grade estates using it versus 50% of the rest. It’s policy that security teams own and every cluster must inherit. Failover has to be tested across clusters, which takes network and platform teams working together.

F5’s approach follows how these teams actually work. Open source is where Kubernetes teams start, because a software stack like Kubernetes makes that the default. They can begin with projects like NGINX Ingress Controller, which is a long-term supported Ingress solution despite the retirement of the community ingress-nginx project, or NGINX Gateway Fabric, which is fully Gateway API conformant.

Eventually, they want the assurance that comes with a commercial solution, and that’s when they move to F5 NGINX Enterprise for hardened images, edge identity, per-application security policies, support SLAs, or fleet scale.

Network and security teams want Kubernetes to fit their existing practices, so F5 BIG-IP with Container Ingress Services (CIS) lets them apply central traffic and security policies and cross-cluster failover from BIG-IP while platform teams keep working in Kubernetes.

For AI workloads running at the scale of a neocloud or AI factory, F5 BIG-IP Next for Kubernetes extends this approach with traffic management and security built for AI in Kubernetes. Each team keeps the tools natural to them, and the shared control point keeps them in step.

Our companion white paper turns this into four phases, each with exit criteria. The timeline is illustrative, so start in the phase that matches your current maturity and adjust the schedule to your circumstances.

1. Standardize (months 0–3): one supported ingress pattern in every cluster, edge telemetry, and defined platform and security roles.
2. Establish (months 3–9): a Gateway API standard, a WAF for inherited security, and centralized telemetry.
3. Enterprise-grade (months 9–18): automated admission control, one control point for traffic and policy, and tested failover.
4. Optimize (month 18 onward): AI guardrails, policy as code, and quarterly reassessment of maturity.

Phase 4 is where AI comes back into the picture, like the machine learning workloads I mentioned earlier. Teams get there on the foundation they’ve already built with F5 NGINX Enterprise and BIG-IP with CIS. For neocloud and AI factory scale, that foundation can extend to BIG-IP Next for Kubernetes. Whatever the scale, the technology only works as well as the partnerships underneath it.

Find your starting point. Download a roadmap for achieving enterprise-grade Kubernetes maturity for a self-assessment and a step-by-step plan. Then read The State of Enterprise Kubernetes Strategy 2026 for the full research.

Also, be sure to check out our blog, “Cloud-native traffic control and security for Kubernetes—built for every team.”

About the Author

Buu LamDirector, Community Evangelism

More blogs by Buu Lam