F5 BIG-IP is already the north-south entry point in most enterprise networks, with established controls for external addressing, traffic management, TLS, security policy and application availability. The question isn’t whether BIG-IP gets replaced as Kubernetes adoption grows. It’s how BIG-IP stays the enterprise traffic-management layer while Kubernetes teams get a native, automated application-delivery model underneath it.
The Gap Between BIG-IP and Kubernetes
BIG-IP and Kubernetes are usually run by different teams, with different tooling and different change processes. That gap — not either platform on its own — is the actual engineering problem.
Kubernetes has its own service discovery, ingress and routing model. Run the external BIG-IP environment and the Kubernetes application-delivery layer independently, and teams end up maintaining multiple configuration layers between the external VIP and the application Pod. Some legacy architectures insert an additional local load-balancing layer — typically VM-based — between BIG-IP and the Kubernetes workloads to bridge that gap.
This pattern usually has a legitimate origin: an existing VM-based load-balancing standard, a network team that isn’t yet Kubernetes-aware, or a cluster that predates a direct integration option. It isn’t a design mistake, but it carries real operational cost:
- Additional infrastructure to provision and secure
- Another availability layer that can itself fail
- Another configuration point that can drift from the other two
- Additional monitoring surface
- Another component lifecycle to patch and upgrade
- More troubleshooting boundaries between client and Pod
- Duplicated load-balancing responsibility across three layers instead of two
- Manual coordination between NetOps and Kubernetes teams for every application change
Kubernetes-native integration between BIG-IP and NGINX removes the layer that exists only to bridge the two. BIG-IP stays in place.
The Architecture: BIG-IP at the Edge, NGINX at the Workload
BIG-IP remains the enterprise north-south entry point. NGINX sits immediately behind it as the Kubernetes-native application-delivery layer, with no intermediate VM load balancer in between. F5 Container Ingress Services (CIS) keeps the two in sync:
Kubernetes (desired state) → F5 CIS → BIG-IP configuration
Where dynamic addressing is in use, F5 IPAM sits ahead of CIS in the same control relationship:
F5 IPAM (approved IP pool) → F5 CIS → BIG-IP VIP
The separation between these two flows — data plane and control plane — is the core idea in this architecture. Everything else builds on it.
The Full Reference Architecture
Before decomposing each component, here is the whole picture the rest of this piece builds on. Three layers, two flows:
Layer 1 — Enterprise Network Layer: Client → F5 BIG-IP (static IP or dynamic IP via F5 IPAM)
Layer 2 — Automation Layer: F5 CIS reconciles configuration with BIG-IP; F5 IPAM allocates addresses via CIS
Layer 3 — Kubernetes Application Delivery (two parallel paths):
- Path A (existing/stable Ingress workloads, via IngressLink): NGINX Ingress Controller → Ingress / VirtualServer → Application Workload (Service + Pods)
- Path B (Gateway API-based application delivery): NGINX Gateway Fabric → Gateway (GatewayClass: NGINX) → HTTPRoute (delegated to application teams) → Application Workload (Service + Pods)
Solid arrows represent application traffic; dashed arrows represent
controller/reconciliation/configuration flow. The sections that follow take each layer in turn — CIS reconciliation, NGINX’s routing role, IngressLink, IPAM and Gateway API — so this diagram is the map to return to.
The two paths connect to BIG-IP differently, and that distinction matters. Path A uses IngressLink, which binds BIG-IP pool membership directly to the NGINX Ingress Controller pods (covered in the IngressLink section below). Path B does not use IngressLink: NGINX Gateway Fabric is fronted by BIG-IP through a standard Virtual Server and pool, the same way BIG-IP fronts any backend. Both paths keep BIG-IP as the enterprise entry point; only the wiring beneath it differs.
Moving BIG-IP Configuration Closer to Kubernetes Desired State
Without an integration layer, Kubernetes configuration and BIG-IP configuration are two independently managed sources of truth. Each may be correct on its own, but nothing keeps them aligned as either changes. CIS closes that gap by letting selected Kubernetes resources participate in the BIG-IP configuration lifecycle. When application-delivery state changes in Kubernetes, CIS observes it and reconciles the required configuration on BIG-IP through AS3 — F5’s declarative configuration API for BIG-IP.
In practice, this removes a class of repetitive manual work: Virtual Server lifecycle, backend pool membership, service exposure, day-to-day application onboarding, and manually keeping two configuration stores in sync.
Network governance doesn’t disappear. The network team still controls the BIG-IP environment itself — address pools, partitions, security policies, and every governance boundary that existed before CIS. CIS operates strictly inside those boundaries. This is controlled automation, not open access from Kubernetes into the network estate.
NGINX as the Kubernetes-Native Application Delivery Layer
NGINX Ingress Controller handles application routing at the workload. It reads Kubernetes Services, Pods, Ingress and VirtualServer objects, host and path rules, and upstream endpoints natively, because it’s built against the Kubernetes API rather than layered on top of it. BIG-IP stays focused on the enterprise/external traffic boundary — it doesn’t need to track EndpointSlice churn or Pod rescheduling directly, because NGINX already owns that layer.
The pairing works because responsibilities split along a line that already matches how each platform is built, not because one product outperforms the other:
- BIG-IP: Enterprise entry point and external traffic governance — WAF, TLS, address management, availability at the network edge.
- NGINX: Kubernetes-native application routing — host/path rules, upstream selection, in-cluster traffic handling.
- CIS: Synchronization between Kubernetes desired state and BIG-IP configuration.
- IPAM: Controlled external address allocation within network-approved pools.
Each component keeps doing the job it already does well. NGINX doesn’t take on enterprise edge duties, and BIG-IP doesn’t need deep Kubernetes awareness.
Connecting BIG-IP and NGINX Directly: IngressLink
IngressLink is the F5-supported integration model that ties CIS/BIG-IP directly to an NGINX Ingress Controller deployment. It applies to Path A specifically — the NGINX Ingress Controller path. Path B (NGINX Gateway Fabric) is fronted by BIG-IP through a standard Virtual Server and pool rather than IngressLink.
At the architecture level, IngressLink lets BIG-IP pool membership track NGINX Ingress Controller pods directly, instead of routing through an intermediate NodePort or a manually maintained pool. BIG-IP keeps the external entry point; NGINX keeps the Kubernetes application-routing role. IngressLink is the wire between them, kept current automatically as pods scale, restart or get rescheduled.
Operational impact:
- One fewer manually maintained hop in the application-delivery path
- Kubernetes-aware backend lifecycle — pool membership follows the actual running pods
- Less dependency on manually maintained intermediate layers
- Clearer separation of responsibilities between network and platform teams
- Kubernetes-side scaling without a parallel BIG-IP change for every scale event
Illustrative CIS IngressLink resource:
apiVersion: cis.f5.com/v1
kind: IngressLink
metadata:
name: nginx-ingresslink
spec:
selector:
matchLabels:
app.kubernetes.io/name: nginx-ingress(Illustrative only: the selector binds a BIG-IP Virtual Server to a specific NGINX Ingress Controller deployment.)
Automating External Address Allocation Without Losing Network Control
Static VIP — for applications requiring:
- Predefined external addresses
- Firewall dependencies
- DNS dependencies
- Regulated or controlled address assignment
Dynamic VIP — for applications where:
- A specific IP is not required
- Faster application onboarding is the priority
- An address can be assigned from an approved pool
Allocation flow: Kubernetes resource → IPAM label → F5 IPAM → Approved IP pool → CIS → BIG-IP VIP
Dynamic IPAM does not hand application developers control over arbitrary enterprise IP addresses. The network team defines the pools and the governance model up front; automation runs strictly inside those boundaries. Static and dynamic allocation aren’t mutually exclusive — most environments run both, chosen per application.
Extending the Architecture Toward Kubernetes Gateway API
NGINX Gateway Fabric runs alongside existing NGINX Ingress Controller deployments, not in place of them. NGINX Ingress Controller continues serving existing, stable Ingress workloads; NGINX Gateway Fabric adds a second, Gateway API-based path for new application platforms and teams.
Gateway API flow: GatewayClass → Gateway → HTTPRoute → Service → Application
Gateway API matters to SRE teams beyond being newer: it gives a clearer ownership split. Infrastructure teams own the Gateway; application teams own the HTTPRoute that attaches to it, within policy boundaries the platform team already set. It’s a richer routing model than the original Ingress API, fits a cross-team platform operating model at scale, and is the direction Kubernetes networking is standardizing on — without requiring anyone to abandon what’s already running on NGINX Ingress Controller.
The Operational Difference
Fewer infrastructure layers. Removing a component that exists only to bridge BIG-IP and Kubernetes simplifies failure domains, patching, monitoring and capacity planning. Every layer removed is one fewer place an incident can hide.
Kubernetes becomes more declarative. Application-delivery changes originate from Kubernetes resources — an Ingress, a VirtualServer, a Gateway, an HTTPRoute — instead of a parallel, manually maintained configuration on a separate device.
BIG-IP remains governed. Network teams still control BIG-IP itself, the external network, approved address pools, security boundaries and enterprise traffic policy. Automation changes who does the repetitive work, not who owns the platform.
Troubleshooting boundaries get sharper. An SRE can work the request path as a sequence of questions instead of one opaque black box:
- External connectivity problem? → BIG-IP
- VIP allocation problem? → CIS / IPAM
- Routing problem? → NGINX / Gateway
- Backend problem? → Service / EndpointSlice / Pod
Following the Traffic Path, Not the Black Box
A short, real engineering example (details generalized, nothing customer-identifying):
Symptom: 502 Bad Gateway
Traffic path: BIG-IP → NGINX Gateway Fabric → HTTPRoute → Service → Pod
NGINX received the request — BIG-IP and external routing were already functioning and got ruled out immediately. NGINX’s logs showed connection refused, which pointed the investigation downstream of NGINX rather than upstream.
The backend path came next: the Service was forwarding to port 80, but the application container wasn’t listening consistently on that same port. Once the chain was aligned end to end — Container :80 → Service targetPort :80 → Service :80 → HTTPRoute backend :80 — the fault cleared.
The lesson generalizes: troubleshoot the traffic path, not BIG-IP, Kubernetes and NGINX as one undifferentiated black box.
How Ashnik Approaches This Architecture
Ashnik starts from the customer’s current baseline: current BIG-IP traffic model, current Kubernetes ingress model, service exposure, VIP allocation process, network/application ownership, security requirements, and operational tooling.
From that baseline, Ashnik evaluates where CIS automation, IPAM, IngressLink, NGINX Ingress Controller and Gateway Fabric can simplify the architecture already in place, rather than applying a fixed template regardless of environment. Sequencing and depth of engagement are scoped per customer.
Validated Approach: Proven in a Telecom Kubernetes Environment
Ashnik validated this application-delivery pattern with a leading telecommunications service provider, covering BIG-IP integration, F5 CIS, F5 IPAM, NGINX Ingress Controller, IngressLink, static VIP allocation, dynamic VIP allocation, NGINX Gateway Fabric, Gateway API, and end-to-end application connectivity.
Conclusion: A Cleaner Architecture, Not Another Layer
Organizations running BIG-IP don’t need to abandon their established enterprise application-delivery model to become Kubernetes-native. The more practical move is to connect the two operating models.
BIG-IP remains the enterprise entry point. NGINX provides Kubernetes-native application routing. CIS connects Kubernetes desired state with BIG-IP configuration. IPAM automates address assignment inside network-defined boundaries. Gateway Fabric provides a controlled path toward Gateway API.
The result isn’t another load-balancing layer — it’s a cleaner application-delivery architecture where each layer has a clearly defined responsibility. It pays off most as application onboarding scales across teams, clusters and environments.
