Cloud-native traffic control and security for Kubernetes—built for every team

Karthik KrishnaswamyDirector, Product Marketing | F5

Buu LamDirector, Community Evangelism

Kubernetes is no longer an experimental sandbox for early adopters. It's the operating system of modern enterprises. Nearly 20 million cloud-native developers are building on it worldwide. Over 90% of global organizations are projected to run containerized applications in production by 2027. And two-thirds of generative AI adopters are already running inference workloads on Kubernetes. Container orchestration is officially mission-critical.

But here's the uncomfortable truth: only 38% of organizations running Kubernetes in production have achieved enterprise-grade maturity, according to The State of Enterprise Kubernetes Strategy 2026, based on SlashData research sponsored by F5. About half—51%—are "established" but stuck with critical gaps in governance, observability, resilience, or their software supply chain. The remaining 11% are still standardizing.

To help enterprises reach the enterprise-grade Kubernetes maturity they need, The F5 Application Delivery and Security Platform (ADSP) delivers a unified architecture that eliminates the operational divide between external load balancers and in-cluster ingress, replacing brittle multi-vendor toolchains with a cohesive, enterprise-grade architecture.

A common foundation that brings teams together

Kubernetes does its job remarkably well. It schedules workloads, scales compute elastically, self-heals failed pods, and abstracts underlying hardware across hybrid and multicloud environments. But orchestrating containers is only half the equation. Controlling and securing the traffic is the other half.

Kubernetes was never designed to govern how application and AI traffic behaves across distributed enterprise environments. It doesn't make real-time routing decisions based on global network conditions, enforce enterprise security policies consistently across ingress and egress paths, or guarantee strict multi-tenant traffic isolation at scale.

And here's what makes the problem even harder: Kubernetes traffic and security aren't owned by a single persona. A platform engineer exposing microservices via GitOps, a network architect managing multi-cluster border gateway protocol (BGP) peering and DPU offload, and a CISO defending against AI-driven zero-day exploits all have fundamentally different operational requirements.

Forcing every stakeholder into a single, one-size-fits-all tool always fails—it's either too heavyweight for developers or too shallow for enterprise infrastructure teams. F5 ADSP takes a different approach, delivering purpose-built, cloud-native solutions tailored to how each persona actually controls and secures traffic, all backed by a common foundation that brings teams together without forcing anyone to compromise.

Different teams, distinct traffic and security priorities

As Kubernetes scales—especially as organizations transition from stateless web apps to stateful, high-throughput AI workloads—four distinct personas emerge, each with very different pain points.

• The platform and DevOps lead prioritizes speed, self-service, and Kubernetes-native YAML workflows. Too often, they start with a free community controller—like the recently retired community ingress-nginx project—only to find themselves maintaining unsupported software across dozens of production clusters, burning engineering headcount on operational toil.
• The head of NetOps and infrastructure demands efficient routing, high-capacity TLS offload, strict multi-tenant isolation, and end-to-end visibility. When traffic enters a cluster, network teams often lose sight of what's happening, leading to four-hour war rooms trying to prove whether an outage is in the network or the pod.
• The AI infrastructure owner has invested millions in GPU clusters that often sit underutilized—not because compute is lacking, but because the bottleneck is getting tokens in and out efficiently, routing requests intelligently across models, and isolating multi-tenant GPU traffic.
• The CISO and SecOps lead worries about unquantifiable exposure across ephemeral clusters, inconsistent web application firewall (WAF) and API security policies, and the speed at which modern vulnerabilities are exploited.

Rather than asking DevOps to think like NetOps—or asking NetOps to manage application YAML—F5 provides the right cloud-native data plane and control plane for each team.

For DevOps and Platform teams: lightweight, Kubernetes-native agility

Platform engineers and developers want a lightweight, high-velocity solution that lives natively inside Kubernetes and integrates frictionlessly into CI/CD and GitOps pipelines. That's the exact role of F5 Ingress Controller for NGINX and F5 Gateway Fabric for NGINX, both a part of F5 ADSP.

Trusted across millions of cloud-native deployments, F5 NGINX is the natural choice for standardizing in-cluster application and API traffic management. Whether your teams use Kubernetes Ingress resources or the modern Kubernetes Gateway API standard—including the Gateway API Inference Extension for AI workloads—F5's NGINX solutions deliver an ultra-fast, developer-friendly footprint.

On the resource efficiency front, competing proxies see their memory footprints balloon when handling long-context AI prompts or streaming payloads. F5 Gateway Fabric for NGINX, by contrast, maintains a flat, predictable memory footprint regardless of payload size.

For organizations migrating off the retired community ingress-nginx project, F5 provides an enterprise-supported, SLA-backed path forward with automated configuration translation—so the move doesn't have to be painful.

And security isn't bolted on after the fact. Teams can embed F5 WAF products, API security, authentication (OIDC, JWT), rate limiting, and real-time AI prompt/response guardrails directly into their Kubernetes manifests, securing app and LLM traffic at the speed of code.

For infrastructure and AI architects: multi-cluster isolation and egress

A lightweight in-cluster proxy is ideal for application teams, but large-scale enterprise environments, telcos, and AI factories need carrier-grade scale, strict tenant isolation, and bidirectional traffic control. That's where F5 BIG-IP Next for Kubernetes comes in.

Built on F5's container-native Traffic Management Microkernel (TMM) and engineered to run on standard worker nodes or offloaded onto NVIDIA BlueField-3 DPUs, BIG-IP Next for Kubernetes brings infrastructure-grade traffic control and security directly into Kubernetes.

Most Kubernetes tools focus solely on ingress. BIG-IP Next for Kubernetes governs and secures both ingress and egress traffic. As microservices and AI agents reach out to external APIs, upstream databases, Model Context Protocol (MCP) servers, and cross-cluster services, unmanaged egress becomes a major blind spot for data exfiltration. BIG-IP Next for Kubernetes enforces deterministic egress routing, SNAT, namespace-based firewalling, and zero-trust micro-segmentation.

For multi-cluster and multi-tenant environments, BIG-IP Next for Kubernetes peers directly with core networks via BGP and accelerates L4–L7 traffic management, mTLS crypto offload, and prefix-aware token routing on DPUs. The result: strict tenant boundaries, freed-up host CPUs, and maximized GPU utilization.

Bringing NetOps and Platform teams together

So what happens when NetOps manages F5 BIG-IP at the perimeter—handling hardware-grade DDoS mitigation, global traffic management, and compliance—while the Platform team runs F5 Gateway Fabric for NGINX or F5 Ingress Controller for NGINX inside the cluster?

F5 BIG-IP Container Ingress Services (CIS) connects their workflows automatically.

Acting as an automated, Kubernetes-native connector, BIG-IP CIS watches Kubernetes and OpenShift APIs—including Ingress, Gateway API, Routes, and F5 IngressLink/GatewayLink resources—and dynamically programs external BIG-IP systems in real time.

Developers stay in Kubernetes, defining in-cluster traffic routing, TLS, and L7 policies in standard YAML. NetOps retains perimeter governance, with CIS automatically detecting cluster changes and updating virtual servers, pool members, and multi-cluster DNS/GTM on the external BIG-IP—no manual tickets required. Both teams keep ownership of their domains while sharing end-to-end telemetry from the perimeter VIP to the pod, with an upgrade path toBIG-IP Next for Kubernetes as needs evolve.

For SecOps and CISOs: hardened releases across open source and enterprise

Giving every persona the right traffic architecture is essential, but your data plane software also has to withstand an AI-accelerated threat landscape.

Consider the math. In 2018, defenders had an average of 771 days after a CVE disclosure before an exploit was weaponized. Today, offensive AI agents can weaponize vulnerabilities within minutes, while the average enterprise still takes several weeks to deploy a patch. In public open source repositories, every security commit is essentially a roadmap for attackers; AI tools can diff the code and generate exploits weeks before downstream distributions rebuild packages.

F5 ships hardened releases so you can ship with confidence, protecting both commercial customers and the open source community. F5 continuously runs an internal AI security harness across BIG-IP, BIG_IP Next for Kubernetes, and NGINX codebases to find and fix vulnerabilities proactively.

Confidential hardened releases go out to commercial customers across NGINX Enterprise, BIG-IP, and BIG-IP Next for Kubernetes as surgical, security-only updates with zero feature changes or API deprecations. Then, roughly six weeks later—giving enterprise infrastructure a safe head start to patch—F5 publishes its security notification, simultaneously releasing CVE details and patches to NGINX Open Source.

How it all comes together: scaling a multi-tenant GPU-as-a-service platform

To see how these pieces fit in practice, consider the recent deployment by a leading Asia-Pacific e-commerce and logistics giant.

After years of running massive internal AI workloads, the company set out to launch a commercial GPU-as-a-Service (GPUaaS) cloud built on large-scale, on-premises Kubernetes clusters powered by NVIDIA DGX systems. Turning internal clusters into a multi-tenant cloud created three immediate challenges.

First, external enterprise tenants needed simultaneous access to shared clusters without cross-tenant traffic bleed. Second, the platform team needed cloud-native L7 routing, TLS termination, and namespace isolation across 100-plus nodes without manual network tickets. And third, community open source controllers simply lacked the robust traffic management and 24/7 support required to back a commercial SLA.

The company deployed a two-tier Kubernetes traffic architecture combining F5 BIG-IP rSeries LTM, BIG-IP CIS, and F5 Ingress Controller for NGINX across 100 Kubernetes nodes. At the edge, BIG-IP rSeries appliances deliver high-throughput L4 load balancing and strict virtual load balancer isolation—dedicated vCPU, memory, and routing partitions—mapping each tenant domain one-to-one to an isolated Virtual IP.

Using F5 IngressLink, BIG-IP CIS watches the Kubernetes API and automatically links external BIG-IP virtual servers to in-cluster NGINX pods with zero manual tickets. Inside the cluster, tenant-dedicated NGINX Ingress Controller pods terminate TLS, perform decryption, and enforce L7 routing and authentication, steering traffic into each tenant's isolated namespace and GPU resources.

By providing NetOps with BIG-IP hardware isolation at the edge, giving its Platform engineers cloud-native NGINX agility inside the cluster, and connecting the two with BIG-IP CIS, the company launched its GPUaaS platform on schedule—while establishing a path to BIG-IP Next for Kubernetes as its AI factory scales.

Traffic control and security built for how your teams work

According to The State of Enterprise Kubernetes Strategy 2026, 24% of enterprises are held back from reaching Kubernetes maturity by a single gap—most often observability or admission control. The distance between "established" and "enterprise-grade" isn't a platform problem. It's a traffic control, security, and team alignment problem.

F5 closes that gap across every persona. Migrate off the retired community ingress-nginx with an enterprise-supported path. Bridge NetOps and platform workflows automatically with BIG-IP CIS. Govern multi-tenant AI cluster traffic—ingress and egress—with BIG-IP Next for Kubernetes. And harden everything with security-only releases that ship weeks before public CVE disclosure. With a unified architecture that meets the needs of different teams, F5 ADSP delivers the Kubernetes operational maturity enterprises need to run Kubernetes securely and efficiently at scale.

Want to go deeper? Come to F5 Booth #100 at KubeCon in Salt Lake City, Nov 9–12 and connect directly with our engineers to work through your Kubernetes networking bottlenecks, experience interactive demos, get practical briefings, and work through your Kubernetes bottlenecks.

Read our blog, “Why most enterprises haven’t reached enterprise security.”

Also, be sure to register for our webinar, “What separates enterprise-grade Kubernetes strategy from the rest.”

About the Authors

Karthik KrishnaswamyDirector, Product Marketing | F5

More blogs by Karthik Krishnaswamy

Buu LamDirector, Community Evangelism

More blogs by Buu Lam