F5 Container Ingress Services - Kubernetes¶
| Current Release Notes | Releases and Versioning |
The F5 BIG-IP Controller (k8s-bigip-ctlr
) is a cloud-native connector that can use either Kubernetes or OpenShift as a BIG-IP orchestration platform.
The BIG-IP Controller watches the Kubernetes API for specially formatted resources, and updates the BIG-IP system configuration accordingly.

Features¶
- Dynamically create, and manage BIG-IP objects.
- Forward traffic from the BIG-IP device to Kubernetes clusters via NodePort or ClusterIP.
- Support F5 AS3 Extension declarations.
User Guides¶
- BIG-IP and flannel VXLAN Integration
- Add BIG-IP device to flannel VXLAN
- Install the BIG-IP Controller: Kubernetes
- Managed BIG-IP objects
- Attaching Virtual Servers to Services
- Using the BIG-IP Controller as an Ingress controller
- CIS and AS3 Extension integration
- Manage your BIG-IP virtual servers
- F5 Resources Explained
- Troubleshoot Your Kubernetes Deployment
Prerequisites¶
The BIG-IP Controller for Kubernetes documentation set assumes that you have:
- A running Kubernetes Cluster.
- Experience with the Kubernetes dashboard and kubectl.
- A BIG-IP device licensed and provisioned for your requirements.
- Experience with BIG-IP LTM concepts and
tmsh
commands.
Note
When using the BIG-IP Controller in Cluster mode, your BIG-IP license must include SDN services.
Important
The BIG-IP Controller requires Administrator permissions in order to provide full functionality.
Installation¶
You can install the k8s-bigip-ctlr
using a Kubernetes deployment, or the F5 Helm Chart.
Upgrades¶
You can upgrade your current k8s-bigip-ctlr
instance.
- Edit the Controller Deployment.
- Update the
image
property to use the desired version. - Add/edit configuration parameters as desired.
- Update the
- If using ConfigMap resources, you may also need to update the f5schemadb version.
- Upload the Deployment to the Kubernetes API server.
Danger
Version upgrades may cause service interruptions. F5 recommends deploying upgrades in a test environment prior to rolling out changes to live production environments.
Ingress services¶
The BIG-IP Controller enables ingress into the cluster using either F5 Resources, or F5 AS3 Extension declarations. For all ingress traffic, the BIG-IP Controller creates a front-end virtual server that routes incoming requests to the appropriate endpoints within the Cluster.
When using F5 Resources or AS3 Extensions, the definitions you provide tell the BIG-IP Controller:
- What Kubernetes resource(s) you want the BIG-IP Controller to manage.
- What objects to create on the BIG-IP device(s) for the specified resource(s).
- How to configure those BIG-IP objects.
For a list of managed BIG-IP objects, refer to Managed BIG-IP objects
Important
- The BIG-IP Controller cannot manage objects in the
/Common
partition. - The BIG-IP Controller cannot create or destroy BIG-IP partitions.
- The partition(s) in which you want to manage objects for your Kubernetes cluster must exist on the BIG-IP system before you deploy the BIG-IP Controller.
- CIS can use AS3 Extension declarations to create and use additional partitions. For more information, refer to Container Ingress Services and AS3 Extension integration.
Key Kubernetes Concepts¶
Cluster Network¶
The basic assumption of the Kubernetes Cluster Network is that Pods can communicate with other Pods, regardless of what host they’re on. You have a few different options when connecting your BIG-IP device to a Kubernetes cluster network and the BIG-IP Controller. How (or whether) you choose to integrate your BIG-IP device into the cluster network – and the framework you use – impacts how the BIG-IP system forwards traffic to your Kubernetes Services.
See Nodeport mode vs Cluster mode for more information.
“ingress” vs Ingress¶
It’s important to understand the difference between the term “ingress” and the Kubernetes “Ingress resource”:
- In general, “ingress” refers to all traffic to resources in the cloud (L4 or L7).
- In Kubernetes, “Ingress” (with a capital “I”) refers to a specific type of resource via which you can configure L7 HTTP traffic.
Namespaces¶
The Kubernetes Namespace allows you to create/manage multiple cluster environments. The BIG-IP Controller for Kubernetes can manage all namespaces; a single namespace; or pretty much anything in between.
When you deploy the BIG-IP Controller, you can:
- omit the
--namespace
flag to watch all namespaces (this is the default setting as ofk8s-bigip-ctlr v1.1.0
); - specify a single namespace to watch (this is the only supported mode in
k8s-bigip-ctlr v1.0.0
); or - specify multiple namespaces to watch.
Node Health¶
When the BIG-IP Controller for Kubernetes runs in Nodeport mode – the default setting – the BIG-IP Controller doesn’t have visibility into the health of individual Kubernetes Pods. It knows when Nodes are down and when all Pods are down. Because of this limited visibility, a pool member may remain active on the BIG-IP system even if the corresponding Pod isn’t available.
When running in Cluster mode, the BIG-IP Controller has visibility into the health of individual Pods.
Tip
In either mode of operation, it’s good practice to add a BIG-IP health monitor to the virtual server to ensure the BIG-IP system knows when resources go down.
Prometheus Support ¶
The BIG-IP Controller provides a basic integration with Prometheus that allows you to retrieve information about the running state of a Controller. Prometheus users can view the following Gauges for the BIG-IP Controller:
- monitored Nodes
- managed Services
- malformed configurations
- Controller health
Define the http-listen-address
arg in your Controller Deployment to tell Prometheus on which IP address and port it should listen.