On this page
Kubernetes is moving from Ingress to Gateway API, a role-based standard for publishing applications. F5's BIG-IP controller for Kubernetes, Container Ingress Services (CIS), does not implement Gateway API. So where does a BIG-IP fit in a Gateway API world? I built the answer on a real data-centre fabric (Dell SONiC switches running EVPN/VXLAN, a Palo Alto firewall, one BIG-IP and a three-node Kubernetes cluster), recorded every step, and measured it. This post goes with a video on the LevelUP I.T. YouTube channel.
The design is two tiers. The BIG-IP stays the front door: the public address, TLS towards the outside, the WAF, health monitors. Gateway API runs inside the cluster, implemented by Cilium, and owns layer 7 routing to the pods. BGP joins the two: every Kubernetes node announces its pod subnet and the Gateway's address to the leaf switches, and the BIG-IP learns them from the same fabric. Measured: an Ingress migrated to an HTTPRoute with 90 of 90 probe requests answered; a 90/10 canary that split 180 / 20 of 200 requests; a second proxy that cost 0.2 ms at the median; and one request captured at every hop, from the user's PC to a pod and back.
What you'll see
- Kubernetes networking and Gateway API from first principles: pods, Services, Ingress, and why Gateway API splits the job into GatewayClass, Gateway and HTTPRoute.
- What F5 ships for Gateway API today, and the design that follows for a BIG-IP VE.
- The lab built from one command, with Kubernetes nodes as VMs (and why).
- Cilium as the pod network, kube-proxy replacement, BGP speaker and Gateway API implementation.
- Pod routes carried by eBGP and EVPN type-5 routes all the way to the BIG-IP, filtered at every hop.
- An Ingress through CIS, a failure that shows exactly how SNAT automap chooses its address, and the fix.
- The Gateway, and the BIG-IP in front of it built in the web UI.
- One request followed hop by hop, with the tables and a capture at every device.
- A make-before-break migration, weights, header matching, ReferenceGrant and a node drain, all measured.
Fundamentals first
Kubernetes networking in five sentences
A pod is one or more containers sharing one IP address, and pods (with their addresses) come and go all the time. The network plugin, the CNI, gives every pod an address and makes every pod reach every other pod on any node. A Service is the stable part: a name and a virtual address in front of whatever pods currently match it. A ClusterIP Service is reachable inside the cluster only, a NodePort Service opens the same port on every node, and a LoadBalancer Service asks for an address reachable from outside. In a public cloud the cloud provides that address; on your own hardware nothing does by default, so something must allocate it and make the network route to it. In this lab Cilium does both: it allocates the address from a pool and announces it with BGP.
Ingress, and why Gateway API replaced it
An Ingress lists host names and paths and the Service behind each: HTTP routing and nothing more. Everything else (the address, TLS settings, timeouts, rewrites) is an annotation, and every controller invents its own: virtual-server.f5.com/ip for CIS on a BIG-IP, a different family for NGINX. So an Ingress is not portable, and one object mixes the jobs of three teams: which load balancer, which address and port, and which routes. There is no weighting, no header matching, no safe cross-namespace reference and no status that says why a route does not work.
Gateway API splits the job into resources with separate owners. A GatewayClass names the implementation (the infrastructure provider). A Gateway is a listener: address, port, protocol and which routes may attach (the cluster operator). An HTTPRoute holds hosts, matches, weights and backends (the application team, in its own namespace). A ReferenceGrant lets a namespace agree before routes elsewhere use its Services. And every object reports status conditions (Accepted, ResolvedRefs, Programmed) with a reason when false. Gateway API has been GA since v1.0 (October 2023); this lab installs the v1.4.1 standard channel.
What F5 ships for Gateway API (November 2026)
- CIS 2.20.4.1 (k8s-bigip-ctlr): Ingress, its own custom resources, AS3 ConfigMaps and OpenShift Routes. Its release notes, through 2.20.4.1, never mention Gateway API.
- The community BIG-IP Gateway API controller (f5devcentral/bigip-kubernetes-gateway): archived on 2 December 2025, and "community supported and is not supported by F5".
- BIG-IP Next for Kubernetes: F5's Gateway API product for BIG-IP, deployed on NVIDIA BlueField-3 DPUs, not on BIG-IP VE.
- F5 NGINX Gateway Fabric: a Gateway API implementation inside the cluster.
So on a BIG-IP VE the design is: the BIG-IP as the front door, Gateway API inside the cluster. This lab uses Cilium's Gateway API, because Cilium is also the CNI and the BGP speaker.
