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 Avi Load Balancer 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 as a CSAR using AKO Helm Chart. This 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, Avi Load Balancer requires Kubernetes objects such as gateways, ingress class, and custom resources in each cluster to integrate Avi Load Balancer 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 Avi Load Balancer 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 Avi Load Balancer pools with Kubernetes pods as pool members and uses the Kubernetes service’s backend port to send the traffic directly. Avi Load Balancer monitors the health of the pod and performs synchronization if changes are triggered.
CNFs can consume Avi Load Balancer 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).
