LTM for CNFs¶

Overview¶

Cloud-Native Network Functions (CNFs) includes Local Traffic Manager (LTM) capabilities that you can deploy and manage using Kubernetes Custom Resource Definitions (CRDs). These CRDs let you configure virtual servers, pools, traffic profiles, and related objects directly in your Kubernetes environment.

LTM for CNF gives you the same core traffic management features you use in BIG-IP, delivered as cloud-native resources that run in any Kubernetes namespace.

Key features¶

LTM for CNF supports the following features:

Virtual servers: Create and configure virtual servers using the F5VirtualServer CRD. Virtual servers accept client traffic and distribute it to pools of backend resources.
Pools and pool members: Define backend resources using the F5BigCnePool CRD. You can add pool members by entering them directly (static members) or by pointing to a Kubernetes service for automatic discovery (dynamic members).
Load balancing: Balance traffic over IPv4 or IPv6.
Source Network Address Translation (SNAT): Configure SNAT on a virtual server as none, automap, or pool.
Traffic profiles: Attach profiles to virtual servers to control how traffic is handled. Supported profiles include:
- TCP F5BigTcpSetting
- UDP
- FastL4
- HTTP
- HTTP/2
- Client SSL
- Server SSL
Persistence profiles: Use the F5BigPersistenceProfile CRD to maintain client connections to the same pool member across multiple requests.
Generic messaging: Configure protocol routing for messaging workloads using the F5GenericMsgSetting CRD. This CRD supports protocol settings, routes, peers, and transport configurations.
iRules: Attach iRules to virtual servers for custom traffic handling logic.
Virtual Routing and Forwarding (VRF): Assign pool members to specific routing domains using VRF references in the Virtual Server, Snatpool, and Pool CRDs.

How it works¶

LTM for CNF uses a set of Kubernetes CRDs to represent traffic management objects. You create Custom Resource (CR) instances of these CRDs in your cluster, and the CNF controller translates them into the corresponding LTM configuration.

The main CRDs and their relationships are:

CRD	Purpose
F5VirtualServer	Defines a virtual server that receives and distributes traffic
F5BigCnePool	Defines a pool of backend members (static or dynamically discovered)
F5BigTcpSetting	Configures TCP profile settings
F5BigPersistenceProfile	Configures session persistence behavior
F5GenericMsgSetting	Configures generic message routing (protocol, routes, peers)
F5BigHttpSetting	HTTP options to fine-tune how application traffic is managed
F5BigHttp2Setting	HTTP2 options to fine-tune how application traffic is managed
F5BigCneIrule	Defines an iRule that can be attached to a virtual server for custom traffic handling logic
VRF	Defines a Virtual Routing and Forwarding instance for routing domain separation
F5BigUdpSetting	Configures UDP profile settings
F5BigClientSslSetting	Configures Client SSL profile settings
F5BigServerSslSetting	Configures Server SSL profile settings
F5BigFastl4Setting	Configures FastL4 profile settings
F5BigCneSnatpool	Defines a SNAT pool for source address translation when `snat.type=snat` is configured on a virtual server

A virtual server references other objects using soft references. For example, the virtual server’s pool field contains the name of a F5BigCnePool CR, and its persistence field contains the name of a F5BigPersistenceProfile CR. This design keeps each resource focused on a single concern and lets you reuse pools and profiles across multiple virtual servers.

Configure a virtual server in BIG-IP Next CNF¶

Learn how to configure a virtual server in F5 BIG-IP Next Cloud-Native Network Functions (CNF) using Kubernetes Custom Resource Definitions (CRDs). By the end of this section, you will have a working virtual server that distributes traffic to a pool of backend resources.

Before you begin¶

Make sure you have the following:

A running Kubernetes cluster with BIG-IP Next CNF installed.
kubectl access to the cluster with permissions to create Custom Resources.
Backend services or endpoints available to receive traffic.

Create a pool¶

Define your backend resources by creating a F5BigCnePool Custom Resource (CR).

You can define pool members in two ways:

Static members: List each endpoint directly.
Dynamic members: Point to a Kubernetes service and let CNF discover the endpoints automatically.

Create a YAML file named my-pool.yaml:

apiVersion: k8s.f5net.com/v1
kind: F5BigCnePool
metadata:
  name: test-pool
  namespace: cnf-gateway
spec:
  dynamicMembers:
    - serviceNamespace: watch-ns-1
      serviceName: service-1
  members:
    - address: 22.22.22.100
      port: 8080

Apply the pool CR to your cluster:
```
kubectl apply -f my-pool.yaml
```

Verify the pool was created:

kubectl get F5BigCnePool my-app-pool -n cnf-gateway

(Optional) Create a persistence profile¶

If you need client sessions to stay connected to the same pool member, create a F5BigPersistenceProfile CR.

Create a YAML file named my-persistence.yaml:

apiVersion: k8s.f5net.com/v1
kind: F5BigPersistenceProfile
metadata:
  name: my-persistence
  namespace: cnf-gateway
spec:
  type: src_addr

Apply the persistence profile:
```
kubectl apply -f my-persistence.yaml
```

(Optional) Create a TCP profile¶

If you need to customize TCP behavior for your virtual server, create a F5BigTcpSetting CR. This lets you tune TCP settings such as idle timeout, buffer size, and congestion control to match your workload requirements.

Create a YAML file named my-tcp-profile.yaml:

apiVersion: k8s.f5net.com/v1
kind: F5BigTcpSetting
metadata:
  name: my-tcp-profile
  namespace: cnf-gateway
spec:
  proxyBufferHigh: 128000
  proxyBufferLow: 128000
  idleTimeout: 150
  receiveWindowSize: 128000
  resetOnTimeout: false

Apply the TCP settings CR to your cluster:
```
kubectl apply -f my-tcp-profile.yaml
```
Verify the TCP settings profile was created:

kubectl get f5bigtcpsetting my-tcp-profile -n cnf-gateway

After you create the TCP profile, reference it in your virtual server CR by adding the profile name to the virtual server spec.

Create a virtual server¶

Create an F5VirtualServer CR that references your pool and any optional profiles.

Create a YAML file named my-virtual-server.yaml:

apiVersion: k8s.f5net.com/v1
kind: F5VirtualServer
metadata:
  name: my-virtual-server
  namespace: cnf-gateway
spec:
  pool: test-pool
  snat:
    type: automap
  persistence: my-persistence
  protocolProfile:
    clientside: my-tcp-profile
    serverside: my-tcp-profile
  protocol: tcp
  destinationAddress: "192.0.2.10"
  destinationPort: 80

Apply the virtual server CR:

kubectl apply -f my-virtual-server.yaml

Verify the virtual server was created:

kubectl get f5virtualserver my-virtual-server

Previous Next