Turn GPU capacity into a managed Kubernetes business
Neoclouds offering managed Kubernetes and GPU-as-a-service need every tenant isolated in the network, with its own controlled path in and out, and confidence that no other tenant can reach them. F5 delivers this and more.
Enterprise tenants ask first how they are isolated
A neocloud that moves up from bare metal takes on the networking its tenants used to build themselves: isolation between customers, controlled ingress and egress, firewalling, and the elogs to prove it. Open source proxies and scripts get a first cluster running, but each new tenant becomes a new build. F5 delivers this layer as a supported component of the F5 Application Delivery and Security Platform.
Isolate tenants in the network
Per-tenant routing domains with EVPN-VXLAN and VRFs, not just namespaces and labels.
Control what goes in and out
Per-tenant ingress, egress with stable source addresses, and a node-edge firewall.
Return host cores to sale
In DPU mode, host cores fell from 12 to 2 in testing validated by The Tolly Group.
Start on the servers you have
Runs on standard host CPUs; add BlueField DPUs when host cores are worth more.
How F5 helps neoclouds sell more than GPU hours
Tenant isolation
Namespaces and network policies separate tenants inside Kubernetes, but tenants still share the network underneath, and enterprise security teams know it. BIG-IP Next for Kubernetes maps each tenant to its own routing domain using BGP EVPN-VXLAN with VRFs, so each tenant's traffic enters and leaves the cluster through its own VRF. Adding a tenant becomes configuration rather than a new build, and the platform team runs one layer instead of a proxy, a router, and a firewall per customer.
Explore networking for KubernetesPRODUCT
BIG-IP Next for Kubernetes
Network-level tenant isolation and per-tenant policy at the cluster border.
PRODUCT
BIG-IP Next for Kubernetes deployed on NVIDIA BlueField DPUs
Tenant enforcement on the DPU, separate from the host operating system.
Ingress, egress, and firewall
Every tenant needs a controlled way in and out. BIG-IP Next for Kubernetes provides per-tenant ingress through the Kubernetes Gateway API, egress through stable per-tenant source addresses that outside systems can allowlist, and a node-edge firewall with a log stream for each tenant. By default, pod egress leaves with the node's address, so outside systems cannot tell tenants apart. With F5, tenants get the controls their security teams ask for, and the provider gets evidence to show them.
Explore networking for KubernetesPRODUCT
BIG-IP Next for Kubernetes
Network-level tenant isolation and per-tenant policy at the cluster border.
PRODUCT
NGINX Gateway Fabric
Gateway API implementation for application traffic inside tenant clusters.
Host cores back on revenue
On a standard server, networking, encryption, and policy run on host CPU cores that are never billed. Deployed on NVIDIA BlueField DPUs in DPU mode, BIG-IP Next for Kubernetes moves that data path onto the DPU. In testing validated by The Tolly Group, host cores consumed fell from 12 to 2 per server, measured on a small model. Across a rack, that is capacity you can sell instead of spend. Start on the host, and move to the DPU when those cores are worth more as sellable capacity.
Read the Tolly reportPRODUCT
BIG-IP Next for Kubernetes deployed on NVIDIA BlueField DPUs
Tenant enforcement on the DPU, separate from the host operating system.
PRODUCT
BIG-IP Next for Kubernetes
Network-level tenant isolation and per-tenant policy at the cluster border.
Feed and protect the factory
Training tenants pull data from object storage across sites and clouds, and a stalled data path leaves their GPUs waiting on your clock. Public inference endpoints and tenant APIs face the internet and are expensive to overload. F5 BIG-IP balances and secures S3 data paths to the GPUs, and provides DDoS protection, firewalling, and global traffic steering at the factory border, on hardware built for service provider scale.
Explore AI data deliveryPRODUCT
BIG-IP LTM
Load balancing and failover across S3 storage endpoints.
PRODUCT
BIG-IP DNS
Global steering of users and data traffic across sites.
PRODUCT
BIG-IP DNS
Global steering of users and data traffic across sites.
PRODUCT
BIG-IP DNS
Global steering of users and data traffic across sites.
PRODUCT
BIG-IP DNS
Global steering of users and data traffic across sites.
PRODUCT
BIG-IP DNS
Global steering of users and data traffic across sites.
Resources
Reference architectures
REFERENCE ARCHITECTURE
NVIDIA Cloud Partner and F5 BIG-IP Next for Kubernetes common networking
REFERENCE ARCHITECTURE
Explore the AI reference architecture
Reports
Solution overviews
SOLUTION OVERVIEW
Powering GPUaaS and AI inferencing services with F5 and NVIDIA
SOLUTION OVERVIEW
Accelerating and optimizing networking for AI infrastructure
FAQs
A neocloud is a cloud provider built around GPU capacity for AI rather than general-purpose compute. Most started by leasing bare-metal GPU servers by the hour and are now adding managed Kubernetes, GPU-as-a-service, and in some cases inference services, so that enterprise customers get a platform instead of raw servers. That move raises what each GPU hour can earn, and raises what tenants expect from the network underneath.
Isolation works in layers. Namespaces and role-based access control scope what each tenant manages, and virtual clusters add a control plane per tenant. Network-level isolation, typically EVPN-VXLAN with a dedicated VRF per tenant, keeps each tenant's traffic in its own routing domain as it enters and leaves the cluster. Per-tenant ingress, egress, and firewall policy at the cluster border then govern what each tenant can reach.
Bare metal leases whole servers, and the tenant brings and runs its own software stack. GPU as a service and managed Kubernetes add the platform on top: scheduling, networking, tenant isolation, ingress and egress, and support. The provider takes on more responsibility and can charge more per GPU hour, and enterprise tenants increasingly expect that platform rather than raw servers.
Give each tenant its own outbound path. Per-tenant egress with stable source addresses lets outside systems allowlist a tenant by address, keeps one tenant's traffic from appearing to come from another, and makes outbound connections easy to log and audit by destination. Kubernetes network policies help, but they work at the level of pods and IP blocks inside the cluster.
No. BIG-IP Next for Kubernetes runs on standard host CPUs, and tenant isolation, ingress, and egress work there. NVIDIA BlueField DPUs move the data path off the host and enforce policy outside the host operating system, which becomes worthwhile as tenant count grows and host cores become more valuable as sellable capacity. Results measured in DPU mode do not carry over to host deployments.