F5 Container Integrations v1.3

Current Page

Application Services Proxy

Cloud Foundry

Kubernetes / OpenShift

Mesos Marathon

Support

Troubleshooting

Tutorials

Cloud Docs Home > F5 Container Integrations Index

Manage BIG-IP virtual servers - Kubernetes/OpenShift

The BIG-IP Controller for Kubernetes and OpenShift watches the Kubernetes/OpenShift API for Services with associated F5 resources and creates/modifies BIG-IP Local Traffic Manager (LTM) objects accordingly. F5 resources provide the settings you want the BIG-IP Controller to apply when creating objects on the BIG-IP system.

Tip

The k8s-bigip-ctlr can also deploy iApps.

Create a BIG-IP front-end virtual server for a Service

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.

Take the steps below to create a new BIG-IP virtual server for a Service.

  1. Create a ConfigMap containing the virtual server F5 resource JSON blob.

    The example below creates one (1) HTTP virtual server and one (1) HTTPS virtual server for a Service, with health monitors defined for each.

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    kind: ConfigMap
    apiVersion: v1
    metadata:
      # name of the resource to create on the BIG-IP
      name: http.vs
      # The namespace to create the object in.
      # The k8s-bigip-ctlr watches all namespaces by default (as of v1.1).
      # If the k8s-bigip-ctlr is watching a specific namespace(s),
      # this setting must match the namespace of the Service you want to proxy
      # -AND- the namespace(s) the k8s-bigip-ctlr watches.
      namespace: default
      labels: 
        # tells the k8s-bigip-ctlr to watch this ConfigMap
        f5type: virtual-server
    data:
      # NOTE: schema v0.1.4 is required as of k8s-bigip-ctlr v1.3.0
      schema: "f5schemadb://bigip-virtual-server_v0.1.4.json"
      data: |
        {
          "virtualServer": {
            "backend": {
              "servicePort": 3000,
              "serviceName": "myService",
              "healthMonitors": [{
                "interval": 30,
                "protocol": "http",
                "send": "GET /\r\n",
                "timeout": 120
              }]
            },
            "frontend": {
              "virtualAddress": {
                "port": 80,
                "bindAddr": "173.16.2.2"
              },
              "partition": "kubernetes",
              "balance": "least-connections-node",
              "mode": "http"
            }
          }
        }
    ----
    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: https.vs
      labels:
        f5type: virtual-server
    data:
      schema: "f5schemadb://bigip-virtual-server_v0.1.4.json"
      data: |
        {
          "virtualServer": {
            "backend": {
              "servicePort": 3000,
              "serviceName": "myService",
              "healthMonitors": [{
                "interval": 30,
                "protocol": "https",
                "send": "GET /\r\n",
                "timeout": 120
              }]
            },
            "frontend": {
              "virtualAddress": {
                "port": 443,
                "bindAddr": "173.16.2.2"
              },
              "partition": "kubernetes",
              "balance": "least-connections-node",
              "mode": "http",
              "sslProfile": {
              "f5ProfileName": "Common/clientssl"
              }
            }
          }
        }
    

    f5-resource-vs-example.configmap.yaml

  2. Upload the ConfigMap to the Kubernetes/OpenShift API server. Be sure to provide the namespace the Service runs in (if something other than default).

    kubectl
    kubectl create -f f5-resource-vs-example.configmap.yaml [--namespace=<service-namespace>]
    configmap "http.vs" created
    configmap "https.vs" created
    
    openshift cli
    oc create -f f5-resource-vs-example.configmap.yaml [--namespace=<service-namespace>]
    configmap "http.vs" created
    configmap "https.vs" create
    
  3. Verify creation of the BIG-IP virtual server(s).

    admin@(bigip)(cfg-sync Standalone)(Active)(/kubernetes)(tmos)$ show ltm virtual
    ------------------------------------------------------------------
    Ltm::Virtual Server: frontend_173.16.2.2_80
    ------------------------------------------------------------------
    Status
      Availability     : available
      State            : enabled
      Reason           : The virtual server is available
      CMP              : enabled
      CMP Mode         : all-cpus
      Destination      : 173.16.2.2:80
    ...
    Ltm::Virtual Server: frontend_173.16.2.2_443
    ------------------------------------------------------------------
    Status
      Availability     : available
      State            : enabled
      Reason           : The virtual server is available
      CMP              : enabled
      CMP Mode         : all-cpus
      Destination      : 173.16.2.2:443
    ...
    

Update a Service’s BIG-IP virtual server

The same basic steps apply to any changes you may want to make to an existing Service’s virtual server’s configurations.

  1. Edit the ConfigMap and make your desired changes.

  2. Upload your changes to the Kubernetes/OpenShift API server using kubectl apply or oc apply.

    kubectl
    kubectl apply -f <myConfigMap.yaml> [--namespace <service-namespace>]
    
    openshift cli
    oc apply -f <myConfigMap.yaml> [--namespace <service-namespace>]
    

Add health monitors

Take the steps below to add a BIG-IP health monitor(s) to an existing virtual server F5 Resource in standard Kubernetes or OpenShift.

  1. Add the health monitor(s) to the backend section of the virtual server F5 resource ConfigMap.

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    kind: ConfigMap
    apiVersion: v1
    metadata:
      # name of the resource to create on the BIG-IP
      name: http.vs
      # The namespace to create the object in.
      # The k8s-bigip-ctlr watches all namespaces by default (as of v1.1).
      # If the k8s-bigip-ctlr is watching a specific namespace(s),
      # this setting must match the namespace of the Service you want to proxy
      # -AND- the namespace(s) the k8s-bigip-ctlr watches.
      namespace: default
      labels: 
        # tells the k8s-bigip-ctlr to watch this ConfigMap
        f5type: virtual-server
    data:
      # NOTE: schema v0.1.4 is required as of k8s-bigip-ctlr v1.3.0
      schema: "f5schemadb://bigip-virtual-server_v0.1.4.json"
      data: |
        {
          "virtualServer": {
            "backend": {
              "servicePort": 3000,
              "serviceName": "myService",
              "healthMonitors": [{
                "interval": 30,
                "protocol": "http",
                "send": "GET /\r\n",
                "timeout": 120
              }]
            },
            "frontend": {
              "virtualAddress": {
                "port": 80,
                "bindAddr": "173.16.2.2"
              },
              "partition": "kubernetes",
              "balance": "least-connections-node",
              "mode": "http"
            }
          }
        }
    
  2. Update the Kubernetes/OpenShift API server. Be sure to provide the namespace the Service runs in (if not default).

    kubectl
    kubectl replace -f <myConfigMap.yaml> [--namespace <service-namespace>]
    
    openshift cli
    oc replace -f <myConfigMap.yaml> [--namespace <service-namespace>]
    
  3. Use the BIG-IP management console to verify the Service’s virtual server has an attached health monitor.

    admin@(bigip)(cfg-sync Standalone)(Active)(/kubernetes)(tmos)$ show ltm virtual <virtual-name>
    

Delete BIG-IP virtual servers

  1. Delete the ConfigMap(s) from the Kubernetes/OpenShift API server.

    The Controller then deletes the corresponding BIG-IP virtual server(s) and its associated objects (pools, pool members, and health monitors).

    kubectl
    kubectl delete configmap http.vs
    configmap "http.vs" deleted
    
    openshift cli
    oc delete configmap http.vs
    configmap "http.vs" deleted
    
  2. Verify the BIG-IP LTM objects associated with the Service no longer exist.

    admin@(bigip)(cfg-sync Standalone)(Active)(/kubernetes)(tmos)$ show ltm virtual frontend_173.16.2.2_80
    

Virtual servers for down or replaced Services

  • If you need to take a Service down temporarily and want to keep the associated BIG-IP objects, leave the F5 Resource ConfigMap in place. The BIG-IP Controller will continue to manage the associated BIG-IP LTM objects when the Service comes back up.
  • If you deploy a new Service with the same name as one you took down, the BIG-IP Controller associates the existing BIG-IP LTM objects with the new Service.
  • If you take down a Service and want to remove the corresponding BIG-IP LTM objects, delete the F5 Resource ConfigMap.

Assign IP addresses to BIG-IP virtual servers using IPAM

You can use an IPAM system to assign IP addresses to BIG-IP virtual servers managed by the BIG-IP Controller. To do so, take the steps below:

  1. Create an unattached pool for the Service on the BIG-IP system.

  2. Use your IPAM system to add the IP address to the ConfigMap.

    Tip

    F5 recommends using an Annotation to add the IP address allocated by the IPAM system to the F5 Resource ConfigMap for the unattached pool.

    The annotation should follow the format

    virtual-server.f5.com/ip=<ipaddress>.

    This tells the BIG-IP Controller for Kubernetes to create a BIG-IP virtual server, assign the designated IP address to it, and attach the pool to the virtual server.

Pools without virtual servers

The BIG-IP Controller for Kubernetes can create and manage BIG-IP Local Traffic Manager (LTM) pools that aren’t attached to a front-end BIG-IP virtual server (also referred to as “unattached pools”). The BIG-IP Controller for Kubernetes applies the following naming convention when creating pool members for unattached pools:

<namespace>_<configmap-name>.

For example, default_http.pool_only.

Important

Before creating unattached pools, make sure the BIG-IP system has another wat to route traffic to the Service(s), such as an iRule or a local traffic policy. After creating an unattached pool for a Service, use the BIG-IP config utility to add the pool members to the iRule or traffic policy. This ensures proper handling of client connections to your back-end applications.

Create an unattached pool

  1. Create an F5 resource ConfigMap, but leave out the bindAddr field.

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    kind: ConfigMap
    apiVersion: v1
    metadata:
      # name of the resource to create on the BIG-IP
      name: http.pool_only
      labels:
        f5type: virtual-server
    data:
      # NOTE: k8s-bigip-ctlr v1.0.0 requires schema v0.1.2
      schema: "f5schemadb://bigip-virtual-server_v0.1.3.json"
      data: |
        {
          "virtualServer": {
            "backend": {
              "servicePort": 3000,
              "serviceName": "myService",
              "healthMonitors": [{
                "interval": 30,
                "protocol": "http",
                "send": "GET",
                "timeout": 86400
              }]
            },
            "frontend": {
              "virtualAddress": {
                "port": 80
              },
              "partition": "kubernetes",
              "balance": "least-connections-node",
              "mode": "http"
            }
          }
        }
    

    f5-resource-pool-only-example.configmap.yaml

  2. Upload the ConfigMap to the Kubernetes/OpenShift API server.

    kubectl
    kubectl create -f f5-resource-pool-only-example.configmap.yaml [--namespace=<service-namespace>]
    configmap "http.pool_only" created
    
    openshift cli
    oc create -f f5-resource-pool-only-example.configmap.yaml [--namespace=<service-namespace>]
    configmap "http.pool_only" created
    

Important

Don’t forget to attach the pool to the iRule or traffic policy on the BIG-IP system that knows how to route traffic for the Service.

Attach a pool to an existing virtual server

  1. Add the desired bindAddr to the F5 virtual server resource definition.

    Tip

    You can configure your IPAM system to do this automatically. For example:

    kubectl annotate configmap http.pool_only virtual-server.f5.com/ip=1.2.3.4

  2. Verify the changes using kubectl get or oc get.

    kubectl get configmap http.pool_only -o yaml \\
    oc get configmap http.pool_only -o yaml
    
  3. Go to Local Traffic ‣ Virtual Servers in the BIG-IP configuration utility to verify the pool attached to the virtual server. (Be sure to look in the correct BIG-IP partition.)

Delete an “unattached” pool

  1. Remove the ConfigMap from the Kubernetes/OpenShift API server.

    kubectl delete configmap http.pool_only
    configmap "http.pool_only" deleted
    
  2. Go to Local Traffic ‣ Pools in the BIG-IP configuration utility to verify deletion of the pool.

Detach a pool from a virtual server

If you want to delete a front-end BIG-IP virtual server, but keep its associated pool(s)/pool member(s):

  1. Remove the bindAddr field from the virtual server F5 resource ConfigMap.

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    kubectl edit configmap http.vs [--namespace <service-namespace>] \\
    oc edit configmap http.vs [--namespace <service-namespace>]
    ----
    # Please edit the object below.
    # ...
    #
    apiVersion: v1
    data:
      data: |
        {
          "virtualServer": {
            "backend": {
              ...
              }]
            },
            "frontend": {
              "virtualAddress": {
                "port": 80,
                \\ REMOVE THE LINE BELOW
                "bindAddr": "1.2.3.4"
              },
              "partition": "kubernetes",
              "balance": "round-robin",
              "mode": "http"
            }
          }
        }
      schema: f5schemadb://bigip-virtual-server_v0.1.4.json
    kind: ConfigMap
    metadata:
      creationTimestamp: 2017-02-14T17:24:34Z
      labels:
        f5type: virtual-server
      name: http.vs
      namespace: default
    
  2. Verify the changes using kubectl get or oc get.

    kubectl get configmap http.vs -o yaml \\
    oc get configmap http.vs -o yaml
    
  3. Go to Local Traffic ‣ Virtual Servers in the BIG-IP configuration utility to verify the virtual server no longer exists.