Gateway API¶

The BIG-IP Next for Kubernetes can be set up with Gateway API CRs to balance low-latency TCP and UDP application traffic between networks using a virtual server and load-balancing pool. This is done by using a virtual server and a load-balancing pool.

Gateway API is an open-source project managed by the SIG-NETWORK community. It is an API (collection of resources) that model service networking in Kubernetes. These resources — GatewayClass, Gateway, L4Route, and so on, as well as the Kubernetes Service resource — aim to evolve Kubernetes service networking through expressive, extensible, and role-oriented interfaces that many vendors implement and have broad industry support.

Gateway API Architecture¶

This section provides details of Gateway API and the new CR types that will be monitored and processed by the CNE controller. It also explains the Kubernetes Gateway API resources, including Gateway, HTTPRoute, and GRPCRoute.

Gateway API Architecture diagram

Introduction to roles in Gateway API¶

The Infrastructure Provider is responsible for defining the GatewayClass, a cluster-scoped resource that represents a class of Gateways that can be instantiated.

The Cluster Operator manages the Gateway CR which acts as the entry point for external traffic and configures how incoming requests should be processed and forwarded to the right services within the cluster.

The Application Developer leverages resources such as HTTPRoute, L4Route, and gRPCRoute to define routing rules and manage traffic flow.

Benefits of Gateway API¶

Role-oriented: Gateway API kinds are modeled after organizational roles that are responsible for managing Kubernetes service networking:
- Infrastructure Provider: Manages infrastructure that allows multiple isolated clusters to serve multiple tenants, for example, a cloud provider.
- Cluster Operator: Manages clusters and is typically concerned with policies, network access, application permissions, and so on.
- Application Developer: Manages an application running in a cluster and is typically concerned with application-level configuration and Service composition.
Portable: Gateway API specifications are defined as custom resources and are supported by many implementations.
Expressive: Gateway API kinds support functionality for common traffic routing use cases such as header-based matching, traffic weighting, and others that were only possible in Ingress by using custom annotations.
Extensible: Gateway allows for custom resources to be linked at various layers of the API. This makes granular customization possible at the appropriate places within the API structure.

Prerequisite¶

Ensure the following requirements are met before configuring the Gateway API.

Obtain and execute Gateway API tarball
Install BIG-IP Next for Kubernetes
Install BIG-IP Next for Kubernetes Cert Manager
Install BIG-IP Next for Kubernetes CWC
Install the RabbitMQ Pod
A Linux-based workstation with Helm installed

CNE controller¶

The CNE controller supports GW API CRs to align with industry standards. The CNE controller design is modified to support both the CR types (F5 CRDs for L4 and L7 namely F5SPKIngressTCP, F5SPKIngressUDP, F5SPKIngressHTTP2 and Gateway CRs).

Gateway API CRs¶

This Gateway API supports the standard features of v1.0. The list of CRs that are managed by the CNE controller,

F5 CRs:

Community CRs:

Connection statistics¶

If you installed the Modular Controller with the Debug Sidecar enabled, connect to the sidecar to view virtual server and pool member connectivity statistics.

oc exec -it f5-tmm-86894fd76c-vznq4 -c debug -- bash

View the virtual server connection statistics:

tmctl -d /var/tmstat/blade virtual_server_stat

For example:

name
------------------------------------------------------
f5-apps-gatewayapi-f5-tcp-route-0-virtual-server

destination
-----------------------------------------------------------
00:00:00:00:00:00:00:00:00:00:FF:FF:16:16:16:98:00:00:00:00

source                                                          vs_index
-----------------------------------------------------------     --------
00:00:00:00:00:00:00:00:00:00:FF:FF:00:00:00:00:00:00:00:00            0

cs_min_conn_dur cs_max_conn_dur cs_mean_conn_dur no_nodes_errors cycle_count
--------------- --------------- ---------------- --------------- -----------
              0               0                0               0           0

delta_busy delta_cycles conf_status no_acl_match no_acl_match_accept
---------- ------------ ----------- ------------ -------------------
26790597918            0 OK                     0                   0

Gateway API Conformance tests¶

The Gateway API includes a comprehensive set of conformance tests. These tests check the implementation against the API specification by creating a series of Gateways and Routes with the specified GatewayClass.

Custom Resource Status (CR status)¶

You can verify the cr status to ensure whether the CR was applied successully or not.

An example of command and response,

kubectl get gateway -n spk-app-2

You can view the status in the PROGRAMMED column:

NAME                CLASS                   ADDRESS   PROGRAMMED   AGE
http-gateway        my-http-gateway-class             True         3d22h
my-tcp-l4-gateway   my-l4-gateway-class               True         11d

Note:

You cannot deploy the gateway API resources in the Controller namespace.

Currently, we support basic CR status.

Supplemental¶

For more information on Gateway API and CR, refer to

Feedback¶

Provide feedback to improve this document by emailing spkdocs@f5.com.

Previous Next