F5 Container Connector - Kubernetes

See also

Learn about using the BIG-IP Controller in OpenShift.

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

Overview

The BIG-IP Controller for Kubernetes (k8s-bigip-ctlr) is a cloud-native connector. It enables use of an F5 BIG-IP device as an Application Delivery Controller (ADC) serving North-South traffic in a Kubernetes Cluster.

See the Container Connector compatibility table for platform compatibility information.

The BIG-IP Controller watches the Kubernetes API for specially-formatted resources and updates the BIG-IP system configurations accordingly.

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

General Prerequisites

The BIG-IP Controller 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.

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

Upgrade

To upgrade an existing k8s-bigip-ctlr instance to a newer version, take the steps below.

  1. Edit the Controller Deployment.
    • Update the image property to use the desired version.
    • Add/edit configuration parameters as desired.
  2. If using ConfigMap resources, you may also need to update the f5schemadb version.
  3. 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.

Applying BIG-IP Services to Kubernetes Resources

The BIG-IP Controller enables ingress into the cluster via F5 Resources and Kubernetes Ingress resources. For all ingress traffic, the BIG-IP Controller creates a front-end virtual server that passes incoming requests to the appropriate endpoint(s) within the Cluster.

When using F5 Resources or Kubernetes Ingresses, 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); and
  • how to configure those 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.

What BIG-IP Objects can the Controller Manage?

You can deploy BIG-IP objects for Services and Ingresses in Kubernetes. In OpenShift, you can deploy BIG-IP objects for Services and Routes. The BIG-IP Controller can create, update, remove, and/or manage BIG-IP objects as noted in the table below.

Type Create New Object Use Existing Object Notes
health monitor X X

The BIG-IP Controller can use existing health monitors for all supported Kubernetes resources.

The BIG-IP Controller can create health monitors for certain types of Kubernetes resources, as described in the deployment guides.
iApp   X The BIG-IP Controller can deploy any iApp that already exists on the BIG-IP system. [1]
node X   Applies to all supported Kubernetes resources.
partition   X The BIG-IP Controller cannot create or destroy BIG-IP partitions.
pool X   Applies to all supported Kubernetes resources.
pool member X   Applies to all supported Kubernetes resources.
self IP   X Applies to all supported Kubernetes resources.
profiles [2]
  HTTP   X Kubernetes Ingress resources (L7) only
  SSL X X Supported functionality varies by resource and platform. See note below.
  TCP   X F5 Resources (L4) only
  UDP   X F5 Resources (L4) only
traffic policy [3] X   Kubernetes Ingress resources (L7) only; the Controller creates a BIG-IP traffic policy to use for routing.
virtual server X   Applies to all supported Kubernetes resources.

Note

The BIG-IP Controller support for SSL profiles varies based on resource type:

BIG-IP Controller support for all profiles applies to basic profiles only. Optimized and/or customized versions aren’t supported.

BIG-IP Object Naming

Note

The BIG-IP Controller prefaces all BIG-IP virtual server objects with [namespace]_[resource-name].

For example, if default is the namespace and k8s.vs is the ConfigMap name, the object preface is default_k8s.vs_173.16.2.2:80.

BIG-IP High Availability and Multi-tenancy

If you’re using a BIG-IP device pair or cluster, F5 recommends deploying multiple BIG-IP Controller instances – one Controller per BIG-IP device. You can also deploy multiple Controller instances to manage separate BIG-IP partitions (for example, one Controller:one namespace:one partition).

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.

“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.

See also

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 of k8s-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

Beta feature

Introduced in k8s-bigip-ctlr v1.5.0.

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.

Footnotes

[1]Custom configurations required. See k8s-bigip-ctlr iApp configuration parameters for more information.
[2]See the BIG-IP Local Traffic Management - Profiles Reference Guide for more information.
[3]See BIG-IP Local Traffic Management - Getting Started with Policies for more information.
Previous Next