F5 Cloud-Native Functions For Modern Demands - Part 1

This is the first of a multi part series to introduce the latest addition to F5's cloud-native catalog of solutions, BIG-IP Next Cloud-Native Functions. This new product includes a lineup of features such as Edge Firewall, CGNAT, DNS, and Policy Enforcer CNF. More details are in below link:
https://www.f5.com/products/cloud-native-network-functions
 

Part 1 - F5 Cloud-Native Functions in a Nutshell

• Why Cloud-Native Matters
• CNF Overview
• Quick Deployment

Part 2 - F5 CNF Configuration Quick Look

• Cloud-native configuration methodology
• F5 CRDs Overview
• CGNAT with Security Deployment

Why Cloud-Native

The CNCF defines cloud-native technologies as the key to "empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds." For example, Kubernetes is a container orchestration platform that was built to provide automation and observability for managing modern apps at scale. 

The announcement of F5's new CNFs comes at a critical time as businesses embark on a journey to reap the benefits that come with using such modern platforms. These CNFs extend Kubernetes with functionality that is required for technologies such as 5G networks, and below is a short description of how it's done.

What F5 CNFs Look Like in a Nutshell

The control plane and data plane is split to achieve independent scaling, resiliency, and minimization of fault domains. The controller pod takes care of automatic discovery of the data plane pods as well as user-defined configuration via F5 developed custom resources. Other compiler pods take care of more advanced configuration and telemetry. Traffic flows to the data plane pod over an external interface, which is processed and then sent out of the cluster to the final destination on the Internet or an external resource. 

Quick Look at How it Works

As with many cloud-native apps, you start off with a helm chart to deploy the various pods using F5 developed templates and customer defined override values. 

F5 also develops custom resource definitions (CRDs) that are used to configure the data plane pod. Below is an example command to deploy the bundle for CRDs. These require special permissions in the cluster as CRDs are cluster-scope resources. Typically a cluster admin will deploy these. 

helm install --namespace my-cnf cnf-crd-n6lan cnf/f5-cnf-crds-n6lan

Below is an example command to deploy the pods in namespace "my-cnf" using the override values file "my-override-values.yaml" and specifying the chart location at the very end. Instructions on how to build your values.yaml file with custom parameters is outlined in the release notes: https://clouddocs.f5.com/cnfs/robin/latest/f5-cnf-1.0.3.pdf 

helm install --namespace my-cnf cnf-ingress-ctrl --values ./my-override-values.yaml cnf/f5ingress

You should get an output like below:

NAME: f5ing-demo-spk
LAST DEPLOYED: Thu Aug 23 21:14:12 2022
NAMESPACE: my-cnf
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
The F5Ingress Controller has been installed.

Then the control plane and data plane pods will be spun up in the specified namespace with a status of "Running"

# kubectl get po -n my-cnf
NAME                                   READY   STATUS             RESTARTS   AGE
f5-afm-5f7b44bfbc-p7zgj                2/2     Running            0          3m
f5-tmm-6f8d59f986-47gl2                4/4     Running            0          3m
f5ingress-f5ingress-796c595cbf-kblcw   1/1     Running.           0          3m

You have now deployed the controller pod "f5ingress", which is ready to configure the data plane pod "f5-tmm-*" with whatever custom resources you wish to deploy.

In the next article, I will provide a general overview of how to configure a data plane pod that accepts client IPv6 traffic and applies a CGNAT policy and firewall security to the traffic before sending it out to the Internet over an IPv4 path.