F5 BIG-IP per application Red Hat OpenShift cluster migrations

Overview

OpenShift migrations are typically done when it is desired to minimise disruption time when performing cluster upgrades. Disruptions can especially occur when performing big changes in the cluster such as changing the CNI from OpenShiftSDN to OVNKubernetes.

OpenShift cluster migrations are well covered for applications by using RedHat's Migration Toolkit for Containers (MTC). The F5 BIG-IP has the role of network redirector indicated in the Network considerations chapter.

The F5 BIG-IP can perform per L7 route migration without service disruption, hence allowing migration or roll-back on a per-application basis, eliminating disruption and de-risking the maintenance window.

How it works

As mentioned above, the traffic redirection will be done on a per L7 route basis, this is true regardless of how these L7 routes are implemented: ingress controller, API manager, service mesh, or a combination of these.

This L7 awareness is achieved by using F5 BIG-IP's Controller Ingress Services (CIS) controller for Kubernetes/OpenShift and its multi-cluster functionality which can expose in a single VIP L7 routes of services hosted in multiple Kubernetes/OpenShift clusters. This is shown in the next picture.

For a migration operation it will be used a blue/green strategy independent for each L7 route where blue will refer to the application in the older cluster and green will refer to the application in the newer cluster. For each L7 route, it will be specified a weight for each blue or green backend (like in an A/B strategy). This is shown in the next picture.

In this example, the migration scenario uses OpenShift´s default ingress controller (HA proxy) as an in-cluster ingress controller where the Route CR is used to indicate the L7 routes. For each L7 route defined in the HA-proxy tier, it will be defined as an L7 route in the F5 BIG-IP tier. This 1:1 mapping allows to have the per-application granularity. The VirtualServer CR is used for the F5 BIG-IP. If desired, it is also possible to use Route resources for the F5 BIG-IP.

Next, it is shown the manifests for a given L7 route required for the F5 BIG-IP, in this case, https://www.migration.com/shop (alias route-b)

apiVersion: "cis.f5.com/v1"
kind: VirtualServer
metadata:
  name: route-b
  namespace: openshift-ingress
  labels:
    f5cr: "true"
spec:
  host: www.migration.com
  virtualServerAddress: "10.1.10.106"
  hostGroup: migration.com
  tlsProfileName: reencrypt-tls
  profileMultiplex: "/Common/oneconnect-32"
  pools:
  - path: /shop
    service: router-default-route-b-ocp1
    servicePort: 443
    weight: 100
    alternateBackends:
    - service: router-default-route-b-ocp2
      weight: 0
    monitor:
      type: https
      name: /Common/www.migration.com-shop
      reference: bigip
---
apiVersion: v1
kind: Service
metadata:
  annotations:
  name: router-default-route-b-ocp1
  namespace: openshift-ingress
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: http
  - name: https
    port: 443
    protocol: TCP
    targetPort: https
  selector:
    ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
  type: NodePort
---
apiVersion: v1
kind: Service
metadata:
  annotations:
  name: router-default-route-b-ocp2
  namespace: openshift-ingress
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: http
  - name: https
    port: 443
    protocol: TCP
    targetPort: https
  selector:
    ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
  type: NodePort

The CIS multi-cluster feature will search for the specified services in both clusters. It is up to DevOps to ensure that blue services are only present in the cluster designated as blue (in this case router-default-route-b-ocp1) and green services are only present in the cluster designated as green (in this case router-default-route-b-ocp2). 

It is important to remark that the Route manifests for HA-proxy (or any other ingress solution used) doesn't require any modification. That is, this migration mechanism is transparent to the application developers.

Demo

You can see this feature in action in the next video

The manifests used in the demo can be found in the following GitHub repository:

https://github.com/f5devcentral/f5-bd-cis-demo/tree/main/crds/demo-mc-twotier-haproxy-noshards

Next steps

Try it today! CIS is open-source software and is included in your support entitlement. If you want to learn more about CIS and CIS multi-cluster features the following blog articles are suggested.

• F5 BIG-IP deployment with OpenShift - platform and networking options
• F5 BIG-IP deployment with OpenShift - publishing application options
• F5 BIG-IP deployment with OpenShift - multi-cluster architectures