In a K8S environment, external services are exposed with Ingress connected to the Load Balancer.
Avi Kubernetes Operator
The Avi Kubernetes Operator (AKO) is a Kubernetes operator that works as an Ingress Controller and performs Avi-specific functions in a Kubernetes environment with the NSX ALB Controller.
AKO is a TKG Cluster Add-On that manages the load balancer functionality for Kubernetes clusters by listening to Ingress, Service type Load Balancer, and Service v2 API objects (GatewayClass and Gateway).
The AKO can be deployed directly from TCA add on or as a CSAR using AKO Helm Chart. The first option provides a fixed version of AKO as it is connected to a TKG release, while the second option provides more flexibility to consume new AKO releases.
AKO is deployed as one or more pods in each Kubernetes cluster and it monitors the Kube API server for any Load balancer service request. AKO requires to have a unique namespace in each Kubernetes cluster.
In addition to AKO, NSX ALB requires Kubernetes objects such as gateways, ingress class, and custom resources in each cluster to integrate NSX ALB with TKG.
The Avi Infra setting (Custom Resource) must be created.
The following core parameters are included in the Avi Infra setting custom resource definition:
Avi Service Engine group: Defines the NSX ALB Service Engine group to be used for this cluster
Default fallback VIP network: Defines the fallback Virtual IP network to be used when Virtual IP is not provided by the user; IPv4, IPv6, and dual stack are available.
BGP label: Defines the BGP label associated with a specific BGP peer towards the uplink router.
AKO creates the NSX ALB pools with Kubernetes pods as pool members and uses the Kubernetes service’s backend port to send the traffic directly. NSX ALB monitors the health of the pod and performs synchronization if changes are triggered.
CNFs can consume NSX ALB as an external load balancer using Labels or Annotations:
Annotations: In this approach, the CNF uses standard Kubernetes service creation to request external load balancer service by adding annotations to the service. This approach can only be used if the load balancer has a single service (protocol/port) requirement.
Labels: In this approach, the CNF uses standard Kubernetes service creation to request external load balancer service by adding labels to the service. This approach can be used both for a single service (protocol/port) or a multi-service load balancer, where a single VIP is shared across multiple ports/protocols).
