This feature allows AKO to create Avi Load Balancer Controller objects under certain VRFs. It is applicable only for the vCenter cloud. Prior to AKO 1.12.1, for vCenter cloud, AKO used to create Avi Load Balancer Controller objects in a VRF that is derived from the VIP network, mentioned in values.yaml.

Starting with AKO 1.12.1, a parameter vrfName is introduced under the ControllerSettings section of values.yaml. This provides flexibility to deploy the Controller objects under different VRFs for different Kubernetes clusters syncing to the same Controller. AKO will create static routes under this VRF if AKO is running ClusterIP mode.

Prerequisites

Following are a few prerequisites before AKO starts using this parameter:

  1. Cloud must be vCenter write access cloud or vCenter no access cloud.

  2. VRF mentioned in the vrfName parameter must exist at the Avi Load Balancer Controller.

  3. Networks mentioned under vipNetworkList and nodeNetworkList must have the same VRF as the one mentioned in the vrfName parameter.

Configuration

ControllerSettings:
  serviceEngineGroupName: Default-Group
  controllerVersion: ""
  cloudName: Default-Cloud
  controllerHost: ""
  tenantName: admin
  vrfName: ""

Users can specify a custom VRF name as a value for a parameter vrfName present under ControllerSettings. If no value is mentioned for this parameter, AKO will derive VRF from the network mentioned under vipNetworkList. 

ClusterIP Mode

NodePort/NPL Mode

vrfName Set

  1. Static routes will be published under the given VRF.

  2. All Avi Load Balancer Controller objects will be part of the same VRF.

  1. No static route population.

  2. All Avi Load Balancer Controller objects will be part of the same VRF.

vrfName unset

  1. Static routes will be published under the VRF, derived from the vipnetworklist.

  2. All Avi Load Balancer Controller objects will be part of VRF derived out of the vipnetworklist.

  1. All Avi Load Balancer Controller objects will be part of global VRF.