The Next Era of Kubernetes Traffic: Why Gateway API is the Future (and How to Master It with F5 NGINX Gateway Fabric)

Articles F5 Technical Articles
, , , , , ,
1

The Next Era of Kubernetes Traffic: Why Gateway API is the Future (and How to Master It with NGINX Gateway Fabric)

Kubernetes Traffic Management at a Crossroads

If you have operated Kubernetes clusters over the past several years, you are almost certainly familiar with the Ingress resource. Introduced in the early days of Kubernetes, Ingress provided a standard way to expose HTTP and HTTPS services from outside the cluster to services within. It served the community well as cloud-native architectures exploded in adoption.

However, as production microservices matured, the limitations of Ingress became painfully clear:

  • Annotation Overload: Because the Ingress API only defined basic path and host matching, every ingress controller vendor had to invent custom annotations for essential enterprise features like header rewrites, rate limiting, traffic splitting, TLS settings, and WAF rules. Manifests quickly devolved into hundreds of lines of fragile, vendor-locked annotations.
  • Monolithic Ownership: Ingress forced infrastructure engineers, security operators, and application developers to edit the exact same API object. A single typo by an application developer in an Ingress object could jeopardize cluster-wide routing.
  • Protocol & Direction Constraints: Ingress was fundamentally designed for basic HTTP/HTTPS North-South ingress. Handling gRPC, TCP/UDP, egress traffic, or internal East-West routing required out-of-band hacks or entirely disjointed service mesh tools.

Enter the Kubernetes Gateway API.

Designed by the Kubernetes community, the Gateway API is not merely a replacement for Ingress: it is an evolutionary leap forward. In this article, we’ll explore why the Gateway API is the future-proof standard for managing, controlling, and securing Kubernetes application traffic. Then, we’ll introduce the F5 DevCentral NGINX Gateway Fabric Lab at https://github.com/f5devcentral/NGINX-Gateway-Fabric-Lab: a hands-on repository that lets you deploy and test real-world Gateway API use cases in minutes.

Why Kubernetes Gateway API is the Future-Proof Standard

The Kubernetes Gateway API provides an expressive, extensible, and role-oriented infrastructure for modern networking. Here is why platform teams across the industry are standardizing on it.

Gateway API Role-Oriented Architecture

flowchart TD
    subgraph IP["INFRASTRUCTURE PROVIDER"]
        direction TB
        IP_DESC["Defines GatewayClass (e.g., NGINX Gateway Fabric)"]
    end

    subgraph CO["CLUSTER OPERATOR"]
        direction TB
        CO_DESC["Configures Gateway (Listeners, Ports, Domain Secrets, WAF and Auth Policies)"]
    end

    subgraph AD1["APP DEVELOPER (App A)"]
        direction TB
        AD1_DESC["Configures HTTPRoute / GRPCRoute"]
    end

    subgraph AD2["APP DEVELOPER (App B)"]
        direction TB
        AD2_DESC["Configures HTTPRoute / GRPCRoute"]
    end

    IP --> CO
    CO --> AD1
    CO --> AD2

    classDef provider stroke:#0066cc,stroke-width:2px,fill:#f0f7ff,color:#004080;
    classDef operator stroke:#009933,stroke-width:2px,fill:#f0fff4,color:#006622;
    classDef devA stroke:#0088cc,stroke-width:2px,fill:#f0f9ff,color:#005580;
    classDef devB stroke:#cc0033,stroke-width:2px,fill:#fff0f3,color:#800020;

    class IP,IP_DESC provider;
    class CO,CO_DESC operator;
    class AD1,AD1_DESC devA;
    class AD2,AD2_DESC devB;

1. True Role-Oriented Architecture

The Gateway API cleanly splits cluster networking into distinct, decoupled Custom Resources (CRDs) tailored to real organizational roles:

  • GatewayClass (Infrastructure Provider): Defines the underlying controller implementation (e.g., NGINX Gateway Fabric). Managed by platform engineers.
  • Gateway (Cluster / Network Operator): Defines where and how traffic enters the cluster (IP addresses, ports, protocols, TLS certificates). Managed by operations or security teams.
  • HTTPRoute / GRPCRoute / TLSRoute (Application Developer): Defines how requests matching specific hosts, paths, or headers are routed to backend Kubernetes Services. Managed independently by application teams without touching cluster infrastructure.

This role separation allows application developers to modify their routing rules safely in their own namespaces without requesting cluster-admin access or risking network outages for other services.

2. A Unified Spectrum: North-South, East-West, and Egress

While Ingress only solved North-South entry, the Gateway API is designed to unify all traffic flow under a single, declarative API:

  • North-South (Today): Ingress routing, TLS offloading, WAF enforcement, and API gateway routing.
  • East-West (Service Mesh): Standardized routing between internal microservices across namespaces using the Gateway API for Service Mesh (GAMMA initiative).
  • Egress (Future & Beyond): Explicit management and security policies for outbound cluster traffic.

Learning one API standard equips platform teams to manage traffic across the entire application lifecycle.

3. Native Portability and Extensible Security

Features that used to require custom vendor annotations such as request header modification, traffic splitting (canary releases), gRPC routing, and policy attachments (authentication, rate limiting, WAF) are now first-class citizens in the Gateway API specification.

Enter F5 NGINX Gateway Fabric

NGINX Gateway Fabric is an open-source implementation of the Kubernetes Gateway API, powered by the world’s most trusted data plane: NGINX (and NGINX Plus for enterprise capabilities).

Why choose F5 NGINX Gateway Fabric?

  • Blazing Fast Data Plane: Built on the lightweight, high-throughput F5 NGINX engine, delivering microsecond-level latency and minimal footprint.
  • 100% Conformance: Fully aligned with the official Kubernetes Gateway API specifications.
  • Enterprise Security & Policy: Integrates advanced capabilities like F5 WAF for NGINX, JWT and OIDC authentication, AI use cases support, and fine-grained rate-limiting directly into Gateway API policy attachments.

Hands-On: The NGINX Gateway Fabric Lab

Theory is great, but nothing beats hands-on experience. To help developers, DevOps engineers, and architects evaluate and master NGINX Gateway Fabric, F5 DevCentral has released the NGINX Gateway Fabric Lab GitHub repository at https://github.com/f5devcentral/NGINX-Gateway-Fabric-Lab.

This repository provides an end-to-end, step-by-step lab environment covering several practical use cases ranging from introductory URI routing to cutting-edge AI inference management, automated WAF policy governance (PLM), hybrid external load balancing with F5 BIG-IP, and automated DNS lifecycle management with ExternalDNS.

Getting Up and Running in Minutes

Deploying NGINX Gateway Fabric in the lab is straightforward.

Prerequisites

  • A running Kubernetes cluster (Minikube, Kind, k3s, or any cloud K8s cluster).
  • kubectl, jq, and grpcurl installed locally.
  • A valid F5 NGINX Plus license (you can easily request a free trial license via NGINX One).

Quick Deployment Steps

The lab repository provides clear, step-by-step instructions for deployment options depending on your architecture and security requirement.

Within two minutes, your cluster is equipped with a modern, Gateway-API-native ingress controller ready to handle traffic!

Exploring the Lab Use Cases

The lab repository is structured into modular exercises, making it easy to jump directly to the topic you want to learn:

Lab Module Key Gateway API Concepts Covered
1. Basic App Deploying a Gateway and simple HTTPRoute rules for host/path routing.
2. Advanced Routing Multi-condition matching using paths, HTTP headers, and query parameters.
3. HTTP Headers Modifying HTTP request/response headers dynamically via HTTPRoute filters.
4. TLS Offloading Managing HTTPS listeners, SNI, and Kubernetes secrets for SSL termination.
5. Traffic Splitting Native weighted canary deployments (e.g., 80/20 traffic splits) without extra plugins.
6. gRPC Support Routing microservice gRPC calls using GRPCRoute with method and header matching.
7. FastCGI Integration Integrating legacy or PHP backends using custom SnippetsFilter extensions.
8. Authentication (JWT) Securing routes with JSON Web Token (JWT) validation (AuthenticationFilter).
9. Rate Limiting Protecting backend services against abuse using declarative rate limiting policies.
10. AI Inference Extensions Routing and managing AI/LLM traffic using the Gateway API Inference Extension.
11. Web Application Firewall (WAF) Attaching F5 WAF for NGINX policies to gateways and overriding rules per route.
12. WAF with Policy Lifecycle Manager (PLM) Enterprise WAF policy automation using f5-waf-policy-controller, out-of-band compilation to SeaweedFS bundles, cross-namespace ReferenceGrant, and Gateway-level inheritance with HTTPRoute DataGuard overrides.
13. GatewayLink (F5 BIG-IP Load Balancing) Production two-tier ingress architecture integrating F5 BIG-IP with F5 NGINX Gateway Fabric via ExternalLoadBalancer, F5 CIS, IPAM Controller, AS3, and client IP preservation using PROXY protocol v2.
14. ExternalDNS Integration Automated DNS record lifecycle management by synchronizing HTTPRoute hostnames with external DNS providers (PowerDNS) via Kubernetes ExternalDNS (gateway-httproute source).

A Taste of the Lab: Native Traffic Splitting (Canary Release)

To appreciate how clean the Gateway API is compared to legacy Ingress annotations, let’s look at Lab 5 (Traffic Splitting) from the repository.

Imagine you have two versions of a microservice: cafe-v1 (stable) and cafe-v2 (canary). You want to send 80% of incoming requests to v1 and 20% to v2.

In the Gateway API, this is expressed natively right inside the HTTPRoute spec: no custom annotations or service mesh required:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: cafe-split
  namespace: default
spec:
  parentRefs:
  - name: cafe-gateway
  hostnames:
  - "cafe.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /coffee
    backendRefs:
    - name: coffee-v1-svc
      port: 80
      weight: 80
    - name: coffee-v2-svc
      port: 80
      weight: 20

By simply adjusting the weight fields, F5 NGINX Gateway Fabric immediately reconfigures the underlying NGINX routing engine in real time.

Advanced Enterprise Features: AI, Automated WAF Governance, Hybrid BIG-IP, & Automated DNS Lifecycle

What makes F5 NGINX Gateway Fabric and this lab stand out is their forward-looking support for next-generation enterprise workloads:

1. Gateway API Inference Extensions (Lab 10)

As teams deploy Generative AI models and LLMs inside Kubernetes, traffic management needs to account for model endpoints, token rates, and inference backends. Lab 10 demonstrates how NGINX Gateway Fabric uses the Gateway API Inference Extension to manage traffic destined for AI workloads seamlessly.

2. Native F5 WAF for NGINX Enforcement (Lab 11)

Security cannot be an afterthought. In Lab 11, you learn how cluster operators can attach an F5 WAF for NGINX policy at the Gateway level to protect every incoming endpoint by default, while allowing application teams to customize or override specific security profiles at the individual HTTPRoute level.

3. Automated WAF Governance with Policy Lifecycle Manager (Lab 12)

In enterprise-scale Kubernetes clusters, managing Web Application Firewall (WAF) policies across dozens of teams and hundreds of microservices quickly becomes an operational bottleneck. Compiling complex WAF rule sets inside every ingress gateway container increases CPU overhead, inflates memory footprints, and introduces latency during pod scale-out events. Furthermore, enterprise SecOps teams require strict separation of duties: they must govern baseline security policies centrally without handing cluster-admin privileges to developers or modifying application routes directly.

Lab 12 addresses this by introducing F5 WAF for NGINX with Policy Lifecycle Manager (PLM) (f5-waf-policy-controller). Instead of compiling policies within the data plane, PLM offloads policy compilation to an out-of-band compiler service. Compiled binary policy bundles are stored on a distributed, S3-compatible storage cluster (SeaweedFS) managed by the SeaweedFS operator and secured end-to-end with TLS certificates provisioned by cert-manager.

The lab showcases a production-ready, role-oriented security workflow leveraging Kubernetes Gateway API primitives:

  • Centralized Security Governance (APPolicy & APLogConf): Security operators define declarative baseline policies (attack-signatures) and audit logging configurations (log-illegal) in a dedicated security namespace.
  • Cross-Namespace Authorization (ReferenceGrant): A ReferenceGrant resource explicitly authorizes the application namespace to consume security bundles from the security namespace, preserving strict security boundaries.
  • Gateway-Level Policy Attachment (WAFPolicy): Platform administrators attach a single WAFPolicy (with type: PLM) targeting the Gateway. Instantly, all downstream HTTPRoute resources automatically inherit enterprise attack protection and centralized Syslog logging.
apiVersion: gateway.nginx.org/v1alpha1
kind: WAFPolicy
metadata:
  name: gateway-base-protection
  namespace: default
spec:
  type: PLM
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: gateway
  policyRef:
    apPolicyRef:
      name: attack-signatures
      namespace: security
  securityLogs:
  - type: syslog
    destination:
      syslog:
        server: syslog-svc.default.svc.cluster.local:514
    logRef:
      apLogConfRef:
        name: log-illegal
        namespace: security

The lab also demonstrates fine-grained policy specialization: application teams can override or augment baseline protections at their specific HTTPRoute level. For example, for sensitive endpoints such as /customers, teams can apply a specialized policy enabling DataGuard to automatically mask credit card numbers and Social Security numbers in response payloads. When malicious requests (like SQL injection or XSS) are executed against the gateway, F5 NGINX Gateway Fabric blocks the attempt in real time, displays a custom rejection page with an F5 support ID, and logs detailed forensics to Syslog.

4. Enterprise Two-Tier Load Balancing with F5 BIG-IP and GatewayLink (Lab 13)

In enterprise data centers and hybrid multi-cloud topologies, Kubernetes clusters rarely face the public internet directly. Instead, organizations overwhelmingly implement a two-tier ingress architecture:

  • Tier 1 (Perimeter / Network Edge): Hardware or virtual F5 BIG-IP Application Delivery Controllers (ADCs) operate at the perimeter, handling multi-gigabit DDoS mitigation, hardware SSL offloading, network firewalling, and data center IP address management.
  • Tier 2 (Cluster / Application Edge): F5 NGINX Gateway Fabric operates inside the Kubernetes cluster, delivering microsecond-level L7 application routing (HTTPRoute), canary releases, header transformations, and fine-grained microservice traffic management.

Historically, keeping external perimeter ADCs synchronized with dynamic Kubernetes container endpoints required complex manual scripting or brittle static configurations. Lab 13 introduces GatewayLink, the Gateway-API-native successor to IngressLink providing seamless, declarative orchestration between F5 BIG-IP and F5 NGINX Gateway Fabric.

  • Declarative Edge Orchestration (ExternalLoadBalancer): Cluster operators declare an ExternalLoadBalancer resource targeting their Gateway, specifying the target BIG-IP partition, IPAM label, and iRules.
  • Automated Discovery via CIS & IPAM Controller: F5 Container Ingress Services (CIS) and the F5 IPAM Controller automatically discover F5 NGINX Gateway Fabric instances, dynamically allocate a Virtual Server IP from enterprise IP pools, and push declarative AS3 (Application Services 3 Extension) configurations to F5 BIG-IP. As gateway replicas scale up or down, BIG-IP pool members update in real time with zero manual intervention.
  • Client IP Preservation via PROXY Protocol v2: To ensure downstream security policies, rate limiters, and audit logs retain visibility into the true client IP, the lab configures PROXY protocol v2 between F5 BIG-IP and F5 NGINX Gateway Fabric using the NginxProxy CRD and an F5 BIG-IP iRule (/Common/Proxy_Protocol_iRule).
apiVersion: gateway.nginx.org/v1alpha1
kind: ExternalLoadBalancer
metadata:
  name: gateway-elb
  namespace: default
spec:
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: Gateway
    name: gateway
  gatewayLink:
    partition: k8s
    ipamLabel: production
    iRules:
    - /Common/Proxy_Protocol_iRule

The lab concludes with end-to-end traffic verification: retrieving the allocated BIG-IP Virtual Server IP address via kubectl get ingresslink gateway-nginx, validating the LTM virtual server status on the BIG-IP appliance, and routing live client traffic through the perimeter BIG-IP directly to F5 NGINX Gateway Fabric microservices.

5. Automated DNS Lifecycle Management with ExternalDNS (Lab 14)

In dynamic microservices environments, deploying application routes is only half the journey: client traffic cannot reach endpoints until external DNS records correctly resolve to the cluster ingress. In traditional architectures, managing DNS records for new services frequently relies on slow ticketing systems or static zone entries prone to DNS drift and dangling records when services are decommissioned.

Lab 14 tackles this operational challenge by integrating F5 NGINX Gateway Fabric with ExternalDNS using native Kubernetes Gateway API source support (gateway-httproute). Instead of maintaining DNS manually or relying on proprietary ingress annotations, ExternalDNS monitors HTTPRoute resources directly and automates the full DNS record lifecycle against authoritative DNS providers such as PowerDNS.

  • Gateway-API-Native Route Discovery (gateway-httproute): ExternalDNS inspects HTTPRoute manifests for declared hostnames (e.g., echo.example.com). It traverses the route’s parentRefs to find the associated Gateway, extracting its public or external LoadBalancer IP address (allocated in bare-metal environments via MetalLB).
  • Automated Authoritative Record Management: ExternalDNS connects to the PowerDNS Authoritative Server via its REST API (/api/v1), dynamically creating the necessary A records alongside registry TXT records that establish cluster ownership (txtOwnerId: my-cluster) to avoid collisions.
  • Full-Lifecycle Synchronization & Pruning (policy: sync): With the synchronization policy set to sync, ExternalDNS continuously reconciles DNS records with the active state of the cluster. When an HTTPRoute is applied, DNS resolves within seconds. When the HTTPRoute is deleted via kubectl delete, ExternalDNS automatically tears down the corresponding A and TXT records from PowerDNS, causing queries to immediately return NXDOMAIN and preventing stale routing.
# ExternalDNS configuration for Kubernetes Gateway API (Helm values)
provider:
  name: pdns
sources:
  - gateway-httproute
domainFilters:
  - example.com
policy: sync
registry: txt
txtOwnerId: my-cluster
interval: 15s
extraArgs:
  pdns-server: "http://powerdns-api.powerdns.svc.cluster.local:8081"
  pdns-server-id: "localhost"

Developers simply declare an HTTPRoute with their intended hostname:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: echo
  namespace: default
spec:
  parentRefs:
  - name: gateway
  hostnames:
  - "echo.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: echo
      port: 80

ExternalDNS immediately provisions echo.example.com in PowerDNS, pointing directly to NGINX Gateway Fabric’s load balancer IP. The lab verifies the end-to-end flow using dig queries to confirm A record publication, curl tests to validate application delivery, and route deletion to verify automated DNS record de-provisioning.

Conclusion & Next Steps

The Kubernetes Gateway API is rapidly becoming the universal standard for application traffic management in cloud-native environments. By combining role-based separation, multi-protocol support, and clean extensibility, it resolves the friction points that plagued legacy Ingress controllers for years.

With F5 NGINX Gateway Fabric, you get the best of both worlds: the modern declarative architecture of the Kubernetes Gateway API, powered by the battle-tested speed and security of F5 NGINX.

Ready to take your Kubernetes networking skills to the next level?

:backhand_index_pointing_right: Clone the repository and run the lab today:
https://github.com/f5devcentral/NGINX-Gateway-Fabric-Lab

Whether you are trying out your first HTTPRoute, configuring native canary traffic splits, routing Generative AI inference workloads, governing enterprise WAF policies with Policy Lifecycle Manager, integrating external F5 BIG-IP load balancers with GatewayLink, or synchronizing dynamic DNS records with ExternalDNS, this lab repository gives you a production-grade sandbox to learn and build with confidence.

Have questions or feedback about the lab? Star the repo, open an issue, or reach out to us on F5 DevCentral!