F5 Container Integrations v1.1

Current Page

Application Services Proxy

Cloud Foundry


Mesos Marathon





Cloud Docs Home > F5 Container Integrations Index

F5 Kubernetes Container Integration


The F5 Container Integration for Kubernetes consists of the F5 BIG-IP Controller for Kubernetes and the F5 Application Services Proxy (ASP).

The BIG-IP Controller for Kubernetes configures BIG-IP Local Traffic Manager (LTM) objects for applications in a Kubernetes cluster, serving North-South traffic.

The Application Services Proxy provides load balancing and telemetry for containerized applications, serving East-West traffic.

F5 Container Solution for Kubernetes

General Prerequisites

The F5 Integration for Kubernetes documentation set assumes that you:

[1](1, 2) Not required for the Application Services Proxy and ASP controllers (F5-proxy, ASP Controller).

Application Services Proxy

The Application Services Proxy (ASP) provides container-to-container load balancing, traffic visibility, and inline programmability for applications. Its light form factor allows for rapid deployment in datacenters and across cloud services. The ASP integrates with container environment management and orchestration systems and enables application delivery service automation.

The Application Services Proxy collects traffic statistics for the Services it load balances; these stats are either logged locally or sent to an external analytics application. You can set the location and type of the analytics application in the stats section of the Service annotation.


In Kubernetes, the ASP runs as a forward, or client-side, proxy.

F5-proxy for Kubernetes

The F5-proxy for Kubernetes – F5-proxy – replaces the standard Kubernetes network proxy, or kube-proxy. The asp and F5-proxy work together to proxy traffic for Kubernetes Services as follows:

By default, the F5-proxy forwards traffic to ASP on port 10000. You can change this, if needed, to avoid port conflicts. See the f5-kube-proxy product documentation for more information.

BIG-IP Controller for Kubernetes

The BIG-IP Controller for Kubernetes is a Docker container that runs on a Kubernetes Pod. To launch the BIG-IP Controller application in Kubernetes, create a Deployment.

Once the BIG-IP Controller pod is running, it watches the Kubernetes API for special Kubernetes “F5 Resource” ConfigMap s. These ConfigMaps contain an F5 Resource JSON blob that tells BIG-IP Controller:

  • what Kubernetes Service we want it to manage, and
  • what BIG-IP LTM objects we want to create for that specific Service.

When the BIG-IP Controller discovers new or updated virtual server F5 Resource ConfigMaps, it dynamically applies the desired settings to the BIG-IP device.


  • The BIG-IP Controller for Kubernetes cannot manage objects in the /Common partition on a BIG-IP device.
  • The BIG-IP partition must exist before you launch a BIG-IP Controller for Kubernetes to manage it.
  • The BIG-IP Controller for Kubernetes can’t create or destroy BIG-IP partitions.
  • Each BIG-IP Controller instance must manage a different BIG-IP partition.
  • Each virtual server F5 Resource defines a BIG-IP LTM virtual server object for one (1) port associated with one (1) Service. Create a separate virtual server F5 Resource ConfigMap for each Service port you wish to expose.

The BIG-IP Controller for Kubernetes can:

Key Kubernetes Concepts


The Kubernetes namespace allows you to create/manage multiple environments within a cluster. 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 Kubernetes Service, you can:

  • specify a single namespace to watch (this is the only supported mode prior to BIG-IP Controller v1.1.0-beta.1);
  • specify multiple namespaces (pass in each as a separate flag); or
  • don’t specify any namespace (meaning you want to watch all namespaces; this is the default setting as of BIG-IP Controller v1.1.0-beta.1).

F5 Resource Properties

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

The virtual server F5 Resource JSON blob must contain the following properties.

Property Description

a label property defining the type of resource to create on the BIG-IP;

e.g., f5type: virtual-server

schema identifies the schema BIG-IP Controller uses to interpret the encoded data


  • frontend
  • backend

a JSON blob

  • a subset of data; defines BIG-IP LTM objects
  • a subset of data; identifies the Kubernetes Service to proxy


As of k8s-bigip-ctlr v1.1.0, you must use F5 schema v0.1.3.


The frontend property defines how to expose a Service on a BIG-IP device. You can define frontend using the standard k8s-bigip-ctlr virtualServer parameters or the k8s-bigip-ctlr iApp parameters.

The frontend iApp configuration parameters include a set of customizable iappVariables parameters. These custom user-defined parameters must correspond to fields in the iApp template you want to launch. In addition, you’ll need to define the iApp Pool Member Table that the iApp creates on the BIG-IP device.

The backend property identifies the Kubernetes Service that makes up the server pool. You can also define health monitors for your BIG-IP LTM virtual server(s) and pool(s) in this section.

Kubernetes and OpenShift Origin

See F5 OpenShift Origin Integration.

Monitors and Node Health

When the BIG-IP Controller for Kubernetes runs with pool-member-type set to nodeport – the default setting – the BIG-IP Controller is not aware that Kubernetes nodes are down. This means that all pool members on a down Kubernetes node remain active even if the node itself is unavailable. When using nodeport mode, it’s important to configure a BIG-IP health monitor for the virtual server to mark the Kubernetes node as unhealthy if it’s rebooting or otherwise unavailable.