F5 Container Integrations

Current Page

Cloud Foundry

Kubernetes / OpenShift

Mesos Marathon




View related articles on DevCentral

Cloud Docs Home > F5 Container Integrations Index

F5 Container Integration - Kubernetes

This document provides general information regarding the F5 Integration for Kubernetes. For deployment and usage instructions, please refer to the guides below.


The BIG-IP Controller for Kubernetes (k8s-bigip-ctlr) configures BIG-IP objects for applications in a Kubernetes cluster, serving North-South traffic.

Solution design: The Container Connector runs as an App within the cluster; it configures the BIG-IP device as needed to handle traffic for Apps in the cluster

The BIG-IP Controller for Kubernetes is a Docker container that runs on a Kubernetes Pod. You can launch the k8s-bigip-ctlr application in Kubernetes using a Deployment. Once the BIG-IP Controller Pod is running, it watches the Kubernetes API for specially-formatted “F5 Resource” ConfigMaps. The ConfigMap contains a JSON blob that tells the BIG-IP Controller:

  • what Service it should manage, and
  • what objects it should create/update on the BIG-IP system for that Service.

You can use F5 Resource ConfigMaps to deploy BIG-IP virtual servers or iApps.

The BIG-IP Controller can:

General Prerequisites

The F5 Integration for Kubernetes documentation set assumes that you:

  • already have a Kubernetes cluster running;
  • are familiar with the Kubernetes dashboard and kubectl ;
  • already have a BIG-IP device licensed and provisioned for your requirements; and
  • are familiar with BIG-IP LTM concepts and tmsh commands.


When using the BIG-IP Controller in OpenShift, make sure your BIG-IP license includes SDN services.

F5 Resource Properties

The BIG-IP Controller for Kubernetes uses special ‘F5 Resources’ to identify what BIG-IP objects it should create. An F5 resource is a JSON blob defined in a Kubernetes ConfigMap.

An F5 Resource JSON blob may contain the properties shown below.

F5 Resource properties
Property Description Required
f5type A label property watched by the BIG-IP Controller. Optional
schema The schema BIG-IP Controller uses to interpret the encoded data. [1] Required
data A JSON object Required
frontend Defines the BIG-IP virtual server.  

Identifies the Service you want to proxy.

Defines BIG-IP health monitor(s) for the Service.

[1]See the F5 schema compatibility table for more information.

The BIG-IP Controller uses the f5type property differently depending on the use case.

  • When used in a virtual server F5 Resource ConfigMap, set f5type: virtual-server. This tells the BIG-IP Controller what type of resource you want to create.
  • When used in OpenShift Route definitions, you can define it any way you like. You can set the BIG-IP Controller to watch for Routes configured with a specific f5type label. For example: f5type: App1 [2]

The frontend property defines how to expose a Service on a BIG-IP device.

The backend property identifies the Kubernetes Service that makes up the server pool. You can define BIG-IP health monitors in this section.

Example F5 virtual server resource

The below example creates one (1) virtual server for the Service named “myService”, with one (1) health monitor and one (1) pool. The Controller will create the virtual server in the k8s partition on the BIG-IP system.

Example F5 Resource definition
  "virtualServer": {
    "backend": {
      "servicePort": 3000,
      "serviceName": "myService",
      "healthMonitors": [{
        "interval": 30,
        "protocol": "http",
        "send": "GET",
        "timeout": 86400
    "frontend": {
      "virtualAddress": {
        "port": 80,
        "bindAddr": ""
      "partition": "k8s",
      "balance": "least-connections-member",
      "mode": "http"
[2]The BIG-IP Controller supports Routes in OpenShift deployments. See OpenShift Routes for more information.

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 (platform or Virtual Edition) 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.


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 creating a BIG-IP front-end virtual server for a Service, you can:

  • specify a single namespace to watch (this is the only supported mode in ``k8s-bigip-ctlr`` v1.0.0);
  • specify multiple namespaces by passing each in as a separate flag; or
  • watch all namespaces (by omitting the namespace flag); this is the default setting as of k8s-bigip-ctlr v1.1.0.

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.


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.


The BIG-IP Controller provides additional functionality in OpenShift deployments, including support for Routes.

Learn about using the BIG-IP Controller in OpenShift.