NSX Advanced Load Balancer provides an L4+L7 load balancing using a Kubernetes operator (AKO) that integrates with the Kubernetes API to manage the lifecycle of load balancing and ingress resources for workloads. AKO runs as a pod in Tanzu Kubernetes clusters and provides an Ingress controller and load balancing functionality. AKO remains in sync with the required Kubernetes objects and calls the NSX ALB Controller APIs to deploy the Ingresses and Services and place them on the Service Engines.
In this post, I will discuss implementing ingress control for a sample application and will see NSX ALB in action.
What is Kubernetes Ingress?
As per Kubernetes documentation:
Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the Ingress resource.
How do I implement NSX ALB as an ingress controller?
If you have deployed AKO via helm, the below parameters in the values.yaml file enables NSX ALB as ingress controller.
1 2 |
L7Settings: defaultIngController: 'true' |
If you have automated AKO deployment in the Tanzu Kubernetes cluster by creating custom AKODeploymentConfig (ADC) objects in the management cluster, then ensure you have included the following in your ADC.
1 2 3 4 |
extraConfigs: ingress: defaultIngressController: true disableIngressClass: false |
When an AKO pod is created in the Tanzu Kubernetes cluster, it adds the missing Kubernetes resource ingressclasses.networking.k8s.io in the cluster.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
# kubectl get ingressclasses.networking.k8s.io NAME CONTROLLER PARAMETERS AGE avi-lb ako.vmware.com/avi-lb <none> 50s # kubectl describe ingressclasses.networking.k8s.io avi-lb -n avi-system Name: avi-lb Labels: kapp.k14s.io/app=1647233362023078577 kapp.k14s.io/association=v1.ff37ac4e25b18b9bf3b7c71a4a580fb8 Annotations: ingressclass.kubernetes.io/is-default-class: true kapp.k14s.io/identity: v1;/networking.k8s.io/IngressClass/avi-lb;networking.k8s.io/v1 kapp.k14s.io/original: {"apiVersion":"networking.k8s.io/v1","kind":"IngressClass","metadata":{"annotations":{"ingressclass.kubernetes.io/is-default-class":"true"... kapp.k14s.io/original-diff-md5: 58e0494c51d30eb3494f7c9198986bb9 Controller: ako.vmware.com/avi-lb |
Deploy a sample web application
I am using the following yaml in my lab to deploy a sample web application to leverage ingress capabilities.
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 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 |
kind: Deployment apiVersion: apps/v1 metadata: name: http-ingress-deployment labels: app: http-ingress spec: replicas: 2 selector: matchLabels: app: http-ingress template: metadata: labels: app: http-ingress spec: containers: - name: http-ingress image: ianwijaya/hackazon ports: - name: http containerPort: 80 protocol: TCP imagePullSecrets: - name: regcred --- kind: Service apiVersion: v1 metadata: name: ingress-svc labels: svc: ingress-svc spec: ports: - name: http port: 80 targetPort: 80 selector: app: http-ingress type: LoadBalancer --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: avisvcingress labels: app: avisvcingress annotations: kubernetes.io/ingress.class: avi spec: rules: - host: ingress.vstellar.local http: paths: - pathType: Prefix path: / backend: service: name: ingress-svc port: number: 80 |
Verify that the new Ingress service is available for the web app after it has been deployed.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
# kubectl apply -f sample-ingress.yaml deployment.apps/ingress-deployment created service/avisvc-lb created ingress.networking.k8s.io/avisvcingress created # kubectl get all NAME READY STATUS RESTARTS AGE pod/http-ingress-deployment-7968f9cb68-gz975 1/1 Running 0 28s pod/http-ingress-deployment-7968f9cb68-jk2xb 1/1 Running 0 28s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/ingress-svc LoadBalancer 100.71.186.25 172.16.18.5 80:31309/TCP 24s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/http-ingress-deployment 2/2 2 2 27s NAME DESIRED CURRENT READY AGE replicaset.apps/http-ingress-deployment-7968f9cb68 2 2 2 28s |
For the Ingress configuration, a new VS is created and a VIP is assigned from the VIP pool. Please note that the NSX-ALB creates an https service port for the web app automatically. The sample app has an insecure Ingress configuration, but NSX-ALB handles the app’s SSL termination.
The application is accessible over both http and https.
That concludes this article. I’m looking forward to learning more about this topic and sharing what I learn.
I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing.
Pingback: Layer 7 Ingress in vSphere with Tanzu using NSX ALB