F5BigAnalyzer¶
The Analyzer pod monitors GPU and LLM performance metrics and recommends updated traffic weights for each backend pool member to optimise load balancing. It can operate in two ways:
Built-in script: Collects NIM metrics from Prometheus to automatically calculate optimal weights that will be used to load balance traffic to backend pool members. (See Integrating NIM with Prometheus for more details on configuring NIM with Prometheus).
Custom script: A user-provided Python script (deployed via ConfigMap) that can use any external data source (e.g: InfluxDB), metrics, and custom logic to generate traffic weights.
The Analyzer pod—using either a built-in or custom script—generates weight recommendations, which are applied as HTTPRoute annotations. The ingress controller recognizes these annotations and passes the updated weights to TMM for dynamic load balancing.
CR parameters¶
The following tables describes the F5BigAnalyzer CR parameters:
metadata¶
Parameter |
Description |
|---|---|
name |
The name of the F5BigAnalyzer CR |
spec¶
Parameter |
Description |
Default |
|---|---|---|
|
The name of the Analyzer resource. |
|
|
List of Gateway API resources that this analyzer monitors. Each entry specifies which routes or services the analyzer should collect metrics for. At least one must be defined. |
|
|
The type of Gateway API resource being referenced. Supported values: HTTPRoute or L4Route. |
|
|
API group of the referenced resource. For HTTPRoute this must be gateway.networking.k8s.io. For L4Route, it must be gateway.k8s.f5net.com. |
|
|
Name of the referenced resource. Must follow Kubernetes RFC-1123 naming rules. |
|
|
Namespace where the referenced resource is deployed. |
|
|
Defines the script that the analyzer will execute. Scripts determine how metrics are collected, analyzed, and turned into weight adjustments. |
|
|
Specifies the script type: builtin or custom (user-provided script stored in a ConfigMap). |
|
|
Configuration for using built-in traffic analyzer scripts predefined by the system. |
|
|
The built-in script name when type is set to builtin. Ensure name is set to LLMLoadMonitor. |
|
|
Configuration for using custom user-provided scripts stored in the ConfigMaps. |
|
|
Reference to the ConfigMap containing the custom analyzer script (used when type = custom). |
|
|
The name of the ConfigMap that contains the custom script. |
|
|
The name of the Python file that will be injected into the ConfigMap and contain the actual script content. |
|
|
Optional list of key-value pairs passed to the custom script at runtime. Used to parameterize or tune custom analyzer logic without changing the script itself. |
|
|
Unique parameter name that identifies the input used by the custom script during execution or analysis. |
|
|
Value assigned to the corresponding parameter key, providing dynamic input to the custom script logic. |
|
|
List of external data sources that analyzers can query to retrieve runtime metrics (e.g., Prometheus, custom telemetry systems). Each entry describes one data source. |
|
|
A unique identifier for the data source entry. Used by the analyzer script to reference the correct data source when running queries. Other fields such as type, endpoint, optional auth (username and password) can be added as needed under this object. |
|
|
Defines how often the analyzer runs. Must be one of: Xs (seconds, minimum 10s), Xm (minutes), Xh (hours), or Xd (days). For example: 15m = every 15 minutes, 2h = every 2 hours. |
|
|
Specifies the metric sources to collect load metrics. Supports |
|
|
Allows automatic connection throttling when pool/cluster health metrics fail to improve. Uses preset aggressiveness levels with predefined step patterns and timing. |
|
|
Enables automatic dynamic capacity reduction based on pool or cluster health metrics evaluation. |
|
|
Throttling aggressiveness level. Determines step sizes and evaluation speed. |
|
Enabling IntelligentLB and Verifying Deployment¶
After setting the intelligentLB field to true in the CNEInstance CR, confirm that:
- The Analyzer pod starts successfully.
- The Ingress pod (f5-cne-controller) restarts automatically.
Run the following command to check pod status:
kubectl get pods
Example output:
NAME READY STATUS RESTARTS AGE
cert-manager-77cf4df568-w7vwb 1/1 Running 0 10d
cert-manager-cainjector-7fd47454bd-qzhvx 1/1 Running 0 10d
cert-manager-webhook-5679f5fc7c-d7rv6 1/1 Running 0 10d
client 1/1 Running 0 10d
f5-afm-8657bc566c-9dphb 2/2 Running 0 10d
f5-analyzer-5cff47d47f-brnjs 1/1 Running 0 32s # Ensure this is up and running
f5-cne-controller-5df5d8b86-d7r45 4/4 Running 0 32s # Ingress pod restarted
f5-observer-0 2/2 Running 0 10d
f5-observer-operator-6f465bf8b4-jmkq5 2/2 Running 0 10d
f5-observer-receiver-0 2/2 Running 0 10d
f5-tmm-6dmsm 7/7 Running 0 6d7h
f5-tmm-j22jw 7/7 Running 0 6d7h
flo-f5-lifecycle-operator-69b76f6c77-5ngwf 1/1 Running 0 10d
otel-collector-7484b9785f-s6l9r 1/1 Running 0 10d
router 2/2 Running 0 10d
server 1/1 Running 0 10d