Manage Your BIG-IP Virtual Servers

Tip

You can use the BIG-IP Controller to attach the BIG-IP virtual servers and pools to Services in Kubernetes and OpenShift environments.

You can use the BIG-IP Controller for Kubernetes and OpenShift to Attach Virtual Servers to Services using F5 resource ConfigMaps. This document provides instructions for managing the virtual server(s) associated with your Service(s).

Edit an existing virtual server

Take the steps below to apply changes to a BIG-IP virtual server associated with a Service, Ingress, or Route.

  • Make your desired changes to the resource YAML or JSON file.

  • Upload the updated file to the Kubernetes or OpenShift API server using the commands shown below.

    Kubernetes

    Tip

    When uploading resources that don’t reside in the default namespace, specify the correct namespace using the --namespace (or -n) flag.

    kubectl
    kubectl apply -f <filename.yaml> [--namespace=<resource-namespace>]
    

    OpenShift

    Tip

    When uploading resources that don’t reside in the default or current Project, specify the correct Project using the --namespace (or -n) flag.

    openshift cli
    oc apply -f <filename.yaml> [--namespace=<resource-project>]
    

Ingresses and Routes

In addition to the steps listed above, you can use the annotate command to add/change the BIG-IP Controller Annotations for an Ingress or Route resource.

For example, to change the load balancing mode to least-connections-member:

Kubernetes Ingress

kubectl annotate ingress myIngress virtual-server.f5.com/balance=least-connections-member [--namespace=**myNamespace**]

OpenShift Route

oc annotate route myRoute virtual-server.f5.com/balance=least-connections-member [--namespace=**myProject**]

Add/Edit health monitors

  1. Define/edit the desired health monitor(s).
  2. Add the health monitor(s) to the backend section of the F5 Resource ConfigMap.
  3. Update the API server.
Example F5 resource with health monitor
kind: ConfigMap
apiVersion: v1
metadata:
  name: myApp.vs
  labels:
    f5type: virtual-server
data:
  # See the f5-schema table for schema-controller compatibility
  # http://clouddocs.f5.com/containers/latest/releases_and_versioning.html#f5-schema
  schema: "f5schemadb://bigip-virtual-server_v0.1.7.json"
  data: |
    {
      "virtualServer": {
        "backend": {
          "servicePort": 80,
          "serviceName": "myService",
          "healthMonitors": [{
            "interval": 30,
            "protocol": "http",
            "send": "GET HTTP/1.1/\r\n",
            "recv": "200|OK",
            "timeout": 120
          }]
        },
        "frontend": {
          "virtualAddress": {
            "port": 8080,
            "bindAddr": "1.2.3.4"
          },
          "partition": "k8s",
          "balance": "least-connections-member",
          "mode": "http"
        }
      }
    }

f5-resource-vs-example.configmap.yaml

Delete a virtual server

When you delete any Kubernetes or OpenShift resource, the BIG-IP Controller deletes all of its associated BIG-IP objects.

For example:

When you delete the Service called “myService” from the API server

kubectl delete service myService [--namespace=**<service_namespace>**]     \ kubernetes
oc delete service *myService [--namespace=**<service_project>**]           \ openshift

the BIG-IP Controller removes the corresponding virtual server, pool(s), etc. from the BIG-IP device.

When you delete a Service, you should also delete the F5 Resource ConfigMap, Ingress, and/or Route associated with that Service. If you leave these resources in place and create a new Service with the same name, the BIG-IP Controller will create objects on the BIG-IP system for the new Service.

You can use a TMOS shell or the BIG-IP configuration utility to verify that the BIG-IP objects no longer exist.

For example:

admin@(bigip)(cfg-sync Standalone)(Active)(/Common) cd my-partition
admin@(bigip)(cfg-sync Standalone)(Active)(/my-partition) tmsh
admin@(bigip)(cfg-sync Standalone)(Active)(/my-partition)(tmos)$ show ltm virtual
admin@(bigip)(cfg-sync Standalone)(Active)(/my-partition)(tmos)$

Downed Services

If you need to take down a Service for maintenance and don’t want to lose the Service’s objects on your BIG-IP, take down the BIG-IP Controller first. The Controller doesn’t delete any objects when it shuts down, so you can remove it without affecting the BIG-IP system configuration. When you bring the Controller back up, it will update the BIG-IP configurations to match the current state of the orchestration system.

Pools without Virtual Servers

You can use the BIG-IP Controller to create BIG-IP pools that aren’t attached to a front-end virtual server (unattached pools).

Important

The primary use case for unattached pools is to allow the use of an IPAM system to allocate IP addresses for your virtual servers.

If you create unattached pools and are not using IPAM, the BIG-IP system must have another way to route traffic to the pools (such as iRules or local traffic policies).

Create an unattached pool

  1. Create an F5 resource without the bindAddr property.

     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
    kind: ConfigMap
    apiVersion: v1
    metadata:
      # name of the resource to create on the BIG-IP
      name: http.pool_only
      labels:
        f5type: virtual-server
    data:
      # See the f5-schema table for schema-controller compatibility
      # http://clouddocs.f5.com/containers/latest/releases_and_versioning.html#f5-schema
      schema: "f5schemadb://bigip-virtual-server_v0.1.7.json"
      data: |
        {
          "virtualServer": {
            "backend": {
              "servicePort": 80,
              "serviceName": "myService",
              "healthMonitors": [{
                "interval": 30,
                "protocol": "http",
                "send": "GET HTTP/1.1/\r\n",
                "recv": "200|OK",
                "timeout": 120
              }]
            },
            "frontend": {
              "virtualAddress": {
                "port": 8080
              },
              "partition": "k8s",
              "balance": "ratio-member",
              "mode": "http"
            }
          }
        }
    

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

  2. Update the Kubernetes API server.

  3. Attach pools to a virtual server using IPAM –OR–

    Use the BIG-IP configuration utility or TMSH to add the pool members to an iRule or traffic policy with the correct routing rules for your application.

Attach pools to a virtual server using IPAM

Set up your IPAM system to annotate the F5 resource ConfigMap with the allocated IP address. Use the Annotation shown below.

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

When the BIG-IP Controller discovers the annotated resource, it:

  • creates a new BIG-IP virtual server with the designated IP address, and
  • attaches the existing pool to the virtual server.

The F5 IPAM Controller can write the virtual-server.f5.com/ip annotation for you. See the f5-ipam-ctlr docs for more information.

Note

The Controller doesn’t support attaching an unattached pool to an existing BIG-IP virtual server.

  • If you try to add the pool to an existing virtual that already has pools attached, you’ll see errors.
  • If you try to use an existing virtual server residing in the /Common partition, you’ll see conflict errors because the Controller will attempt to create a new virtual server in its managed partition.
  • If you manually create a virtual server in the managed partition, the Controller will delete it.

Detach a pool from a virtual server

When you detach a pool from a virtual server, the BIG-IP Controller will delete the virtual server but keep the pool(s)/pool member(s).

  1. Remove the bindAddr field from the virtual server F5 resource ConfigMap.
  2. Update the API server.
  3. Verify the changes using kubectl get (Kubernetes) or oc get (OpenShift).

Delete an unattached pool

The steps for deleting an unattached pool are the same as for deleting a virtual server.

Verify changes on the BIG-IP system

You can use the BIG-IP configuration utility or a TMOS shell to verify creation/modification/deletion of BIG-IP objects.

Configuration Utility

  • Go to Local Traffic ‣ Virtual Servers.
  • Select the correct partition from the Partition drop-down menu.

TMOS Management Console

admin@(bigip)(cfg-sync Standalone)(Active)(/Common) cd my-partition
admin@(bigip)(cfg-sync Standalone)(Active)(/my-partition) tmsh
admin@(bigip)(cfg-sync Standalone)(Active)(/my-partition)(tmos)$ show ltm virtual
------------------------------------------------------------------
Ltm::Virtual Server: default_myApp.vs_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: default_myApp.vs_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
...