F5 BIG-IP per application Red Hat OpenShift cluster migrations
Perform cluster migrations, with no service disruption and avoiding all-or-nothing changes
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.