A CRD has been provided to add the GSLB configuration. The name of the object is GSLBConfig
(short name is gc
) and it has the following parameters:
apiVersion: "avilb.k8s.io/v1alpha1"
kind: "GSLBConfig"
metadata:
name: "amko-gc"
namespace: "avi-system"
spec:
gslbLeader:
credentials: gslb-avi-secret
controllerVersion: 20.1.1
controllerIP: 10.10.10.10
tenant: admin
memberClusters:
- clusterContext: cluster1-admin
- clusterContext: cluster2-admin
refreshInterval: 1800
logLevel: "INFO"
useCustomGlobalFqdn: false
apiVersion
: The api version for this object has to beavilb.k8s.io/v1alpha1
.kind
: the object kind isGSLBConfig
.name
: Can be anything, but it has to be specified in the GDP object.namespace
: By default, this object must be created inavi-system
.gslbLeader.credentials
: A secret object has to be created for (helm install
does that automatically) the GSLB Leader cluster. The username and password have to be provided as part of this secret object.gslbLeader.controllerVersion
: The version of the GSLB leader cluster.gslbLeader.controllerIP
: The GSLB leader IP address or the hostname along with the port number, if any.gslbLeader.tenant
: The tenant where AMKO will be creating GslbService in AVI.memberClusters
: The kubernetes/openshift cluster contexts which are part of this GSLB cluster. See here to create contexts for multiple kubernetes clusters.refreshInterval
: This is an internal cache refresh time interval, on which syncs up with the AVI objects and checks if a sync is required.logLevel
: Define the log level that the amko pod prints. The allowed levels are:[INFO, DEBUG, WARN, ERROR]
.useCustomGlobalFqdn
: If set to true, AMKO will look for AKO HostRules to derive the GslbService name using the local to global fqdn mapping. If set to false (default case), AMKO ignores AKO HostRules and uses the default way of deriving GslbService names by just looking at the local fqdn in the ingress/route/service type LB. See Local and Global Fqdn.
-
Only one
GSLBConfig
object is allowed. -
If using
helm install
, aGSLBConfig
object is created by picking up values from thevalues.yaml
file. -
During
helm delete
, theGSLBConfig
that holds the UUID of the current instance is deleted. To maintain the correct state of AMKO when you install AMKO again conserve the amkoUUID from annotations of GSLBconfig and add it inconfigs.amkoUUID
field of values.yaml. Otherwise a cleanup of stale GSLB services, if any, is required at the controller before re-installing AMKO.annotations: amko.vmware.com/amko-uuid: b3923b8e-7bff-11ee-8972-a24a90367d8f