Using BIG-IP Kubernetes Gateway API Controller
Preparing Kubernetes Cluster
To use BIG-IP Kubernetes Gateway API Controller("Controller" in short), we need to prepare a Kubernetes Cluster. The community versions between 1.18 and 1.24 are well tested.
We have kinds of ways to setup a Kubernetes cluster, In this article, we use Rancher(https://www.rancher.com/) to setup a 7-node K8S with Flannel Network:
$ kubectl get node
NAME STATUS ROLES AGE VERSION
k8s-lab-host-1 Ready controlplane,etcd,worker 52m v1.18.20
k8s-lab-host-2 Ready worker 25m v1.18.20
k8s-lab-host-3 Ready worker 19m v1.18.20
k8s-lab-host-4 Ready worker 23m v1.18.20
k8s-lab-host-5 Ready worker 27m v1.18.20
k8s-lab-host-6 Ready worker 26m v1.18.20
k8s-lab-host-7 Ready worker 26m v1.18.20
Deploying Gateway API CRDs
Gateway API is a set of CRDs developed by SIGNework(https://github.com/kubernetes/community/tree/master/sig-network).
Let’s use the following command to install Gateway API CRDs.
$ kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v0.6.0/standard-install.yaml --validate=false
customresourcedefinition.apiextensions.k8s.io/gatewayclasses.gateway.networking.k8s.io created
...
job.batch/gateway-api-admission created
job.batch/gateway-api-admission-patch created
By looking into the “standard-install.yaml” file of v0.6.0, we can see the definitions of resources: “GatewayClass” , “Gateway”, “HTTPRoute” and “ReferenceGrant”. We have also “experimental” as described https://gateway-api.sigs.k8s.io/concepts/versioning/#release-channels-eg-experimental-standard.
Notes that:
If you have network connection limit to gcr.io, you have to:
- Manually download the images and upload them to k8s nodes for gcr.io connecting limit :
gcr.io/k8s-staging-gateway-api/admission-server:v0.6.0
k8s.gcr.io/ingress-nginx/kube-webhook-certgen:v1.1.1
- Change the imagePullPolicy: Always to IfNotPresent in standard-install.yaml.
Use wget to download standard-install.yaml instead of kubectl apply -f <the remote yaml file>).
After the kubectl cmd, you can see the api-resources:
$ kubectl api-resources
…
gatewayclasses gc gateway.networking.k8s.io/v1beta1 false GatewayClass
gateways gtw gateway.networking.k8s.io/v1beta1 true Gateway
httproutes gateway.networking.k8s.io/v1beta1 true HTTPRoute
referencegrants refgrant gateway.networking.k8s.io/v1beta1 true ReferenceGrant
…
And the running Gateway API admission server deployment:
$ kubectl get deploy -n gateway-system
NAME READY UP-TO-DATE AVAILABLE AGE
gateway-api-admission-server 1/1 1 1 3m34s
Prepare a BIG-IP Instance
We have v14 – v17 classic BIG-IP well tested with basic LTM/NET abilities, like HTTP Gateway or Terminated HTTPS Gateway, vxlan or bgp networking.
The Controller is still evoluting, we’ll add more supports per customer needs.
In this article, we use “BIG-IP 15.1.0.5 Build 0.0.8 Point Release 5” for demonstration.
Setup BIG-IP for K8S CNI
To make BIG-IP as the Gateway for the business traffic, we need to setup BIG-IP’s networks for different CNI types. Currently, Controller supports 2 CNI types: Flannel and Calico, Cilium is on the way.
Flannel
For flannel network CNI, we need to setup the very vxlan/tunnel on BIG-IP, so that the BIG-IP can forward the traffic through the tunnel. In that situation, BIG-IP is configured as virtual node of K8S cluster.
The detail of Flannel network setup can be found here: https://gateway-api.f5se.io/deploy/#in-flannel-mode.
Calico
For calico network CNI, we configure BIG-IP as a BGP neighbor of K8S nodes.
The detail of Calico network setup can be found here: https://gateway-api.f5se.io/deploy/#in-calico-mode.
The above setup processes are step by step. Fortunately, we have encapsulate the setup process in the tool: https://github.com/f5devcentral/bigip-kubernetes-gateway/tree/master/cmd/tools/cni-utils. Users only need to provide configuration items, cni-utils would help to archive the CNI setup.
Now, we are ready to deploy and use Controller.
Deploy BIG-IP Kubernetes Gateway API Controller
Create ServiceAccount and ClusterRoleBinding
To monitor resource changes from Kubernetes cluster, we need to create a service account and bind it with proper role/access.
See https://github.com/f5devcentral/bigip-kubernetes-gateway/blob/master/deploy/1.clusterrole-and-binding.yaml for the integrated YAML file.
Deploy the Controller Pod
In https://github.com/f5devcentral/bigip-kubernetes-gateway/blob/master/deploy/3.deploy-bigip-kubernetes-gateway-controller.yaml, there are several resource types and names:
- Secrets
- bigip-login
The BIG-IP password for admin to do iControlREST requests.
We save it into a separate secret for security concern, it will be mounted as volume to bigip-kubenetes-gateway deployment.
- webhook-server-cert
The CA/cert/key PEM used for webhook configuration. Thus, the connection between k8s and webhook server is encrypted and verified.
- ValidatingWebhookConfiguration
- validating-webhook-configuration
The webhook configuration, in this configuration, we define a before-hand way to validate users’ resource request before doing real changes to api-server. The configuration includes many items, like, server ca bundle, server port and endpoints, etc.
Each resource has a separate endpoint for resource validation.
This webhook configuration is different with gateway-api-admission-server, it focuses on resource relationship validation. For example, validating the required GatewayClass existence before creating a Gateway.
The validation is configurable to enable or disable.
- ConfigMap
- bigip-kubernetes-gateway-configmap
This is the configuration for the downstream BIG-IP. Will be mounted as volume to bigip-kubernetes-gateway deployment.
- Deployment
- bigip-kubernetes-gateway
The deployment and pod where the controller process is running. The Controller is released as docker images to: https://hub.docker.com/r/f5devcentral/bigip-kubernetes-gateway.
We can find the default startup parameters and necessary input volumes in the “spec:” section. Users can adjust the parameters here for their deployments.
- Service
- bigip-kubernetes-gateway
The bigip-kubernetes-gateway Service is used to expose the Controller at:
8080: Prometheus metrics collection port
8081: health probing port
9443: webhook server port
Because the Controller is run with NodePort service type, no matter it’s in or out of Cluster, it can be accessed with the very ports.
Installation and Startup
To install and start controller, just run the command:
$ kubectl apply -f deploy/3.deploy-bigip-kubernetes-gateway-controller.yaml
Controller Parameters
The parameters we use to start controller is:
"--controller-name=f5.io/gateway-controller-name",
"--bigip-config-directory=/bigip-config",
"--bigip-credential-directory=/bigip-credential",
"--certificate-directory=/tmp/k8s-webhook-server/serving-certs"
By default, we need not to change them.
See the full list are as below command:
$ docker run f5devcentral/bigip-kubernetes-gateway:v0.2.1-20230411 /bigip-kubernetes-gateway-controller-linux --help
Verify the Startup
After starting the Controller, we can use the following command to monitor the logs:
$ kubectl logs -f deployment/bigip-kubernetes-gateway -c bigip-kubernetes-gateway-pod -n kube-system
Deploying a Gateway Instance
We have several usecases/examples in https://github.com/f5devcentral/bigip-kubernetes-gateway/tree/master/examples/.
As the start, you can read the simple Gateway case: https://github.com/f5devcentral/bigip-kubernetes-gateway/tree/master/examples/simple-gateway.
More Topics
HA
The controller is run as a standalone program in K8S, it has no HA feature.
When the program is terminated unexpectedly, K8S would pull up a new pod automatically to continue the Controller work.
After restarting, the resource update events would be sent to Controller again in batch from K8S. However, Controller can detect that the corresponding resources on BIG-IP are ready, no need to redeploy again.
For HA of BIG-IPs, one Controller can handle multiple BIG-IPs. They can be in HA active-standby peer.
Performance
Controller use BIG-IP iControl Rest and transaction feature to accomplish the resource deployment.
It’s a incremental way when the new resource deployment request comes. Controller will detect which part need to deploy and which part doesn’t, by comparing the existing resources and resource requests.
It’s faster than AS3 way, because, AS3 do more complex checks and validation. However, the way Controller is using only focuses on Gateway API related resources.
Prometheus
The Controller has been integrated with Prometheus, by accessing http://<controller>:8080/metrics and http://<controller>:8080/stats, we can see the metrics exposed to Prometheus. Currently, we have some metrics for runtime-manager work tracing(/metrics) and function performance tracing(/stats). In the future, we may add more metrics per customer needs.
Video Demos
Users can find more video demos from YouTube: https://www.youtube.com/playlist?list=PLAg2ep4I_zspyhcFj90n8vx_Lo8AUUyWT
BIG-IP Kubernetes Gateway API Controller Setup and simple gateway demonstration.
This video demonstrate the cross namespace routing implementation by BIGIP-Kubernetes-Gateway. See https://gateway-api.sigs.k8s.io/guide...
Splitting Traffics with HTTPRoute's multiple backendRefs.