BIG-IP Next for Kubernetes CRDs

The BIG-IP Next for Kubernetes Custom Resource Definitions (CRDs) extend the Kubernetes API, allowing the Traffic Management Microkernel (TMM) to be setup using BIG-IP Next for Kubernetes Custom Resources (CRs). These CRs enable TMM to handle low-latency application traffic, and implement networking configurations such as interface IP addresses and static routes. For information on the specific CRs and complete list of parameters available for creating a CR, refer the corresponding CRD. Users can now install all F5 Use Case Custom Resource Definitions (CRDs) by following the instructions in the Install F5 Use Case Custom Resource Definitions section.

Networking CRs

Networking CRs configure the networking components of TMM, such as network interfaces and static routes.

Available network management CRs:

  • F5SPKVlan - TMM interface configuration: VLANs, Self IP addresses, MTU sizes, and so on.

  • F5SPKStaticRoute - TMM static routing table management.

  • F5SPKSnatpool - Allocate IP addresses for egress Pod connections.

Application traffic CRs

When an application traffic CR is applied, the TMM is configured to act as a proxy and distribute application traffic through protocols like TCP and UDP. This results in the TMM receiving various objects related to managing application traffic. The BIG-IP Next for Kubernetes supports the Gateway API open source standards and utilize its route resources such as HTTPRoute and GRPCRoute to configure BIG-IP Next for Kubernetes to route Ingress traffic. For more information, see Gateway API.

Object

Description

Virtual Server

An IP address and service port that receives and processes ingress or egress application traffic.

Network Virtual Server

An IP address subnet representing a range of destination IP addresses to receive and process ingress application traffic.

Protocol Profile

Provide application traffic intelligence, and options to adapt how connections are handled.

Load Balancing Pool

The Service object Endpoints that TMM distributes traffic to using round robin load balancing.

Available traffic management CRs:

  • Ingress Load Balancing

    • F5 CRs:

      • The F5 L4Route CR is applied to act as an application developer.

    • Gateway API Community CRs:

      BIG-IP Next for Kubernetes supports these community-based CRs,

      • Gateway: Gateway CR is applied to act as an entry point to manage internal and external traffic. This takes on the role of the cluster operator.

      • HTTPRoute: HTTPRoute CR is used to define and manage routing rules for HTTP traffic within a Kubernetes cluster. This takes on the role of the application developer.

      • GRPCRoute: GRPCRoute CR is used to handle GRPC traffic within a Kubernetes cluster. This takes on the role of the application developer.

      • F5BigCneIrule: Enables iRules to extend the TMM Proxy Pod’s traffic processing capabilities.

  • Egress Load Balancing

    • F5SPKEgress - Egress application traffic for pods using SNAT, Shared SNAT with Flow Forwarding, Security Protection, PseudoCNI and VXLAN creation.

Protection CRs

Traffic Management CRs can utilize Protection CRs to safeguard applications against unauthorized and malicious network traffic.

  • F5BigFwPolicy - Granular stateful-flow filtering based on access control list (ACL) policies. To understand the Firewall policy support in Gateway API, see Firewall policy in Gateway API.

  • F5BigFwRulelist - A collection of firewall rules used to define and enforce traffic filtering and security policy.

  • F5BigDdosGlobal - Configures the TMM proxy pod to inspect and protect applications from DoS/DDoS attacks.

Common CRs

Define global options and reference objects consumed by multiple traffic, security, and firewall CRs.

  • F5BigGlobalOptions - Includes configurable options to enable or disable crypto hardware acceleration on the BlueField-3 Data Processing Unit (DPU).

The following CRs are used for BIG-IP Next for Kubernetes Firewall Logging:

Adapter CRs

Bridge Gateway API resources to BIG-IP Next for Kubernetes (DPU) features by attaching traffic-management and security policies to Gateways, listeners, and routes.

  • NetPolicy - Defines policies using the policy attachment pattern, integrating iRule CRDs with Gateway API CRDs to configure traffic management for Gateways and listeners.

  • SecPolicy - Attaches security policies like ACLs, DOS, and logging profiles to Gateway API objects, aligning with GEP 2648 for policy management and status tracking.

Infrastructure CRs

Define the cluster’s BIG-IP Next for Kubernetes (DPU) or Gateway infrastructure entry points and controller ownership.

Intelligent load balancing CRs

Enable metric-driven, adaptive pool weighting to automatically optimize backend traffic distribution.

  • F5BigAnalyzer: Monitors GPU and LLM performance metrics to recommend traffic weights for backend pool load balancing, using either built-in NIM metrics or custom scripts, and updates weights via HTTPRoute annotations.

Finalizers

The finalizers prevent the deletion of Custom Resources (CRs) until backend configurations are safely removed, ensuring reliable cleanup and consistency.

  • Finalizers are namespaced keys that instruct Kubernetes to wait until specific conditions are met before completely deleting resources marked for deletion. The BIG-IP Next for Kubernetes Controller utilizes Kubernetes finalizers to ensure consistency between CRs and backend configurations.

  • The BIG-IP Next for Kubernetes Controller adds a finalizer to any newly created CR.

  • Upon CR deletion, the BIG-IP Next for Kubernetes Controller first removes the respective configuration from the backends and then eliminates the finalizer, permitting Kubernetes to complete the deletion process. As long as the finalizer is present in the CR, it will not be completely deleted.

  • When a CR is deleted, finalizers prevent it from being deleted if the BIG-IP Next for Kubernetes Controller is offline. When the controller comes back online, it takes out the configuration from the backend and then removes the finalizer. This makes sure that CRs are only deleted after the configuration is removed from the backends.