CASE STUDY

Ashnik Delivers Automated Application Delivery with F5 CIS, IPAM and NGINX for a Leading Telecom Provider

Ashnik

Customer identity is not disclosed in this case study. Details reflect a solution engagement delivered for a telecommunications sector customer.

  • Industry :
    Telecommunications
  • Technology :
    F5 BIG-IP, F5 CIS, F5 IPAM, NGINX Ingress Controller, NGINX Gateway Fabric
  • Engagement :
    End-to-End Design & Deployment
THE CUSTOMER

A leading telecommunications service provider running enterprise application platforms that increasingly rely on Kubernetes.

THE SOLUTION

A controller-driven integration — F5 CIS and F5 IPAM automating BIG-IP configuration and VIP allocation for both NGINX Ingress Controller and NGINX Gateway Fabric.

THE CHALLENGE

Kubernetes moved fast; network provisioning was ticket-driven and manual, requiring cross-team coordination for every VIP and routing change.

THE RESULT

Automated VIP allocation through IPAM, static and dynamic publishing validated side by side, central BIG-IP governance retained throughout.

0

Manual BIG-IP tickets required for standard onboarding

100%

BIG-IP governance retained by the network team

2 in 1

Routing models — Ingress and Gateway API — governed through a single BIG-IP layer

4

Governance controls enforced throughout automation

Customer Overview

The customer’s application platforms increasingly run on Kubernetes, while F5 BIG-IP has long served as the organization’s established external load-balancing and application-delivery layer. Kubernetes workloads change on a materially faster cycle than traditional network infrastructure.

The organization required its application platforms to remain reliable, scalable, and centrally governed — without requiring network teams to manage every new service through a fully manual process. Ashnik was engaged to design, deploy, and validate that balance in practice, keeping BIG-IP as the enterprise entry point while Kubernetes teams gained the automation their release cycle demanded.

The Challenge

Kubernetes moves fast. Network processes often don’t.

Manual, multi-team coordination

Every new application required application, Kubernetes, and network teams to coordinate on VIP allocation and routing changes.

Governed IP allocation

External addresses had to be drawn from approved pools, with no risk of duplication or unauthorized assignment.

Ingress and Gateway API, side by side

Established Ingress workloads required continued support as newer platforms adopted the Gateway API.

Consistency at scale

Repeated manual changes carried the risk of naming drift, missed pool members, incorrect ports, and stale BIG-IP objects.

Solution Overview

A controller-driven bridge between BIG-IP and Kubernetes. Kubernetes resources drive BIG-IP configuration automatically, with BIG-IP retained as the enterprise entry point for application traffic.

F5 BIG-IP

Serves as the external entry point for application traffic, providing the enterprise-grade virtual-server and load-balancing capabilities the organization already relies on.

F5 CIS

Continuously observes approved Kubernetes resources and translates them into the corresponding BIG-IP application-delivery configuration.

F5 IPAM Controller

Maintains defined IP address pools and allocates an available external VIP automatically when a resource requests one through an IPAM label.

NGINX Ingress Controller

Manages application routing for Kubernetes Ingress resources and connects to BIG-IP through IngressLink.

NGINX Gateway Fabric

Implements the Kubernetes Gateway API using GatewayClass, Gateway, and HTTPRoute resources.

Kubernetes

Hosts the application Services and Pods, providing the desired-state configuration that the integrated controllers continuously reconcile against.

Technical View — For Platform and Network Engineering Teams

CIS watches the Kubernetes resources it is approved to observe — including Ingress, LoadBalancer Services, and IngressLink configuration — and reconciles the corresponding BIG-IP objects using AS3. F5 IPAM allocates addresses from configured pools when a supported resource carries the cis.f5.com/ipamLabel annotation, or accepts a pre-defined address through cis.f5.com/ip for static assignment. NGINX Ingress Controller integrates with BIG-IP through IngressLink, with BIG-IP forwarding traffic to the NGINX data plane over the Kubernetes node and NodePort. NGINX Gateway Fabric exposes its data plane through a Kubernetes LoadBalancer Service and NodePort, with GatewayClass, Gateway, and HTTPRoute resources describing the routing intent. Both paths terminate at a standard Kubernetes Service, which forwards traffic to the application Pod on port 80.

Static and Dynamic VIP Allocation

Two allocation models, both implemented and validated end to end. The choice depends on application criticality, whether an address is already reserved, and expected onboarding volume.

Static VIP

A predefined external IP supplied in advance, for addresses already reserved or externally registered. Configured explicitly using cis.f5.com/ip — suited to applications that require a known, fixed address.
Implemented & validated

Dynamic VIP

An available address selected automatically from an approved IPAM range, requested through the cis.f5.com/ipamLabel annotation. Removes repeated manual address assignment and supports a repeatable, Kubernetes-driven provisioning model.
Implemented & validated

Both approaches were implemented and validated end to end. The two models are not mutually exclusive — reserved addresses remain available for critical or externally governed applications, while standard workloads draw addresses automatically from controlled IPAM pools.

The Approach

Executed in controlled, independently tested stages. Each integration point was validated on its own before the complete traffic path was tested end to end.

01
F5 CIS and F5 IPAM deployed into the Kubernetes environment
CIS was provisioned with the required BIG-IP credentials and cluster permissions to observe approved Kubernetes resources and reconcile BIG-IP configuration through AS3. IPAM was configured with approved address pools for dynamic allocation.
02
NGINX Ingress Controller connected to BIG-IP through IngressLink
Existing Ingress-based workloads were exposed through Kubernetes Ingress, with BIG-IP forwarding traffic to the NGINX data plane over the Kubernetes node and NodePort.
03
NGINX Gateway Fabric deployed for Gateway API workloads
GatewayClass, Gateway, and HTTPRoute resources were created to expose a service through a BIG-IP-managed LoadBalancer Service, extending the same BIG-IP estate to newer, API-based platforms.
04
Static and dynamic VIP allocation, supported side by side
Applications requiring a known, pre-approved address use cis.f5.com/ip. Standard onboarding draws automatically from an approved IPAM pool using cis.f5.com/ipamLabel. Both models were validated end to end without reducing network-team governance.
05
Governance controls scoped for this phase
RBAC-controlled Kubernetes access, BIG-IP credentials managed through Kubernetes Secrets, address allocation restricted to approved IPAM pools, and defined namespace and resource scope for each controller. TLS design, WAF policy, and deeper network segmentation are scoped for production-readiness work in the next phase.
06
End-to-end validation and troubleshooting
During Gateway API testing, traffic reached NGINX but returned a 502 Bad Gateway. Root cause: a port mismatch between the container, the Kubernetes Service, and the HTTPRoute backend. Resolution: aligning all four to port 80, after which end-to-end access was confirmed.

Architecture

Two validated paths, one BIG-IP and IPAM automation layer.

case study ashnik

A client reaches the application through an external VIP on F5 BIG-IP, using either a static IP or a dynamic IP allocated by F5 IPAM. F5 CIS and F5 IPAM automatically configure BIG-IP in response to Kubernetes activity. Inside the Kubernetes environment, traffic reaches the application through NGINX Ingress Controller for existing applications, or NGINX Gateway Fabric for new, API-based applications — both landing on the application Service and Pod on port 80.

Technical Validation

This phase focused on the core integration and end-to-end traffic flow. High-availability sizing, performance benchmarking, WAF policy design, and multi-cluster scaling are scoped for the customer’s next phase of rollout.

VALIDATION AREA RESULT
F5 CIS connectivity to BIG-IP Successful
F5 IPAM dynamic VIP allocation Successful
Static VIP publishing Successful
NGINX Ingress Controller via IngressLink Successful
NGINX Gateway Fabric via Gateway API Successful
Backend connectivity to Kubernetes Pod Successful
End-to-end application access Successful
COMPONENT VERSION
F5 BIG-IP 17.5.1.1
F5 Container Ingress Services (CIS) 2.20.4
F5 IPAM Controller 0.1.13
NGINX Ingress Controller 5.5.4
NGINX Gateway Fabric 2.6.7
Kubernetes 1.33.7 (upstream)

Outcome

BIG-IP integrated with Kubernetes-native delivery

Kubernetes resources drive BIG-IP configuration automatically, with BIG-IP retained as the enterprise entry point.

Automated VIP allocation through F5 IPAM

Addresses are drawn only from approved pools, eliminating manual, repeated allocation work.

Static and dynamic publishing, side by side

Reserved addresses serve critical applications; automatic allocation serves standard onboarding — the models are not mutually exclusive.

Ingress and Gateway API supported together

Existing Ingress-based applications and newer Gateway API platforms run through the same BIG-IP and IPAM layer.

End-to-end routing confirmed for both paths

Application access was validated through the external VIP and hostname-based routing on each path.

Central governance retained throughout

Network teams retain visibility and control at the BIG-IP layer, regardless of which routing model an application team chooses.

Business Benefits

Translating the technical outcomes into business value.

Less dependency on manual network changes

Standard application requests move from Kubernetes to BIG-IP without repeating the same manual handoffs each time.

Faster, more consistent publishing

CIS translates Kubernetes desired state directly into BIG-IP configuration, eliminating repetitive manual object creation.

Better cross-team coordination

Network, platform, and application teams operate against a shared, automated integration point instead of separate manual processes.

Centralized control through BIG-IP

BIG-IP remains the enterprise traffic platform and governance layer as Kubernetes automation is introduced around it.

Controlled IP consumption

Dynamic addresses are drawn only from approved pools, ensuring consistency and preventing accidental duplication.

A reusable architecture

The validated pattern extends to additional clusters and applications, subject to production design and operational readiness.

Engagement Deep-Dive

Technical notes for engineering and audit review, one level deeper than the summary above. These notes maintain the same anonymized, factual approach as the rest of this document — no customer name, internal system names, IP ranges, or cluster and namespace details.

Provisioning Time and Workflow Change

Ticket-to-reachability time was not formally measured prior to this engagement, so no before/after figure is quoted here. What changed is the workflow itself. Application publishing previously required manual coordination between the application/platform team and the network team to prepare the external address and BIG-IP configuration. With the dynamic IPAM path, that same setup is now triggered automatically once the required Kubernetes resource and IPAM label are created — CIS and IPAM handle address allocation and BIG-IP configuration without a separate manual step. With a static VIP, the pre-approved address is referenced up front, and BIG-IP configuration continues to be handled automatically by CIS.

One issue surfaced during end-to-end testing: a sample application briefly returned a “bad gateway” error, despite the routing configuration having been accepted correctly. Root cause: the test application was not listening on the port expected by the Kubernetes and routing configuration. Resolution: aligning ports across the application, the Service, and the routing definition, after which traffic flowed through successfully. The finding confirmed the BIG-IP, CIS, IPAM, and NGINX integration was functioning correctly, and isolated the issue to the sample application rather than the automation layer.

This engagement validated the integration pattern rather than performing a large-scale migration. One representative application was tested end to end through the NGINX Ingress Controller / IngressLink path, and one representative service was tested end to end through the NGINX Gateway Fabric / Gateway API path. Both were validated fully — from external VIP allocation through BIG-IP configuration, NGINX routing, and backend connectivity.

Security hardening was not the primary objective of this phase; the focus was proving the integration itself. The following controls were applied as part of the setup: Kubernetes access governed through RBAC, permissions scoped by namespace, BIG-IP credentials stored as Kubernetes Secrets rather than plain configuration, and external addresses restricted to pre-approved IPAM pools. Detailed access-control design, network segmentation policy, WAF policy, production TLS architecture, and formal compliance validation are scoped for a dedicated production-readiness phase.

Several design decisions were guided by engineering judgment rather than a fixed specification. Ashnik validated the integration one layer at a time — connectivity, then Ingress, then static VIPs, then dynamic IPAM allocation, then Gateway Fabric, then full end-to-end traffic — isolating and resolving issues before introducing the next layer. Ashnik also recommended supporting both static and dynamic VIP allocation rather than standardizing on one: static addresses suit applications requiring a fixed, pre-reserved IP, while dynamic allocation suits standard applications that can request an address automatically from an approved pool. Throughout, BIG-IP was retained as the central enterprise traffic control point, so automation was introduced without reducing network-team oversight.

The engagement shifted application publishing from a ticket-driven process toward a model in which application teams request routing through native Kubernetes resources, and automation translates that request into BIG-IP configuration. This reduces the manual hand-offs between application/platform teams and the network team for routine application publishing. Network teams retain ownership of BIG-IP, address pools, and overall governance, without needing to manually configure every standard request.

Conclusion

Ashnik designed, deployed, and validated the integration of F5 CIS and F5 IPAM with both NGINX Ingress Controller and NGINX Gateway Fabric for the customer’s Kubernetes environment. Kubernetes teams now declare routing requirements through native resources, while BIG-IP continues to provide the enterprise entry point and network governance the organization already relies on.

This gives the customer a proven foundation for extending the same architecture to additional applications and clusters, guided by their production architecture, security, and operating-model requirements. Ashnik’s Application Delivery and Kubernetes practice works with enterprises applying this validated pattern to their own BIG-IP and Kubernetes environments. Ashnik is India’s first F5 Authorized Consulting Partner, delivering F5 and NGINX engagements end to end.