The document describes how to integrate Tanzu Service Mesh with Avi Global Server Load Balancing (GSLB) to ensure high availability of a customer's application deployed in multiple clusters, which may be located across multiple GSLB sites and regions.
To achieve high availability of an application, Tanzu Service Mesh uses Global Namespace, a platform-neutral abstraction that automatically provides connectivity and security for services across clusters and platforms. Within the global namespace, you map a public service; that is, you specify that a specific front-end service deployed in multiple clusters will be exposed outside.
By integrating with Avi GSLB, Tanzu Service Mesh automatically configures global load balancing for the public service and points Avi GSLB to wherever the service resides regardless of the underlying platform. This ensures high availability of the service across the clusters where it is deployed. Avi GSLB will direct traffic to the optimal service instance on one of the clusters, based on the currently configured load balancing policy. If a service instance is unreachable for some reason (for example, the cluster is down because of a power outage), Avi GSLB automatically routes traffic to a healthy instance.
To integrate with Avi GSLB, you need to install Controller clusters in your environment and provide the appropriate GSLB configuration for each of your tenants in Avi.
As part of the integration, to connect to the GSLB leader site in Avi, you create an Avi integration account in Tanzu Service Mesh.
To make the subdomains you delegated to Avi GSLB available to include in the URL of the public service, you must also create a DNS account in Tanzu Service Mesh, linking the DNS account to the integration account.
Prerequisites
Onboard the clusters where your application is deployed to Tanzu Service Mesh. For information about onboarding a cluster to Tanzu Service Mesh, see Onboard a Cluster to Tanzu Service Mesh.
When mapping services to the global namespace where you want to configure a public service for GSLB, verify that all the services reside in namespaces with the same name. This is required by the current version of Tanzu Service Mesh and will change in the future.
If Avi Kubernetes Operator (AKO) is installed on the onboarded clusters where instances of the public service will be deployed, deactivate the L4Settings.autoFQDN
configuration setting during installation. This setting is available starting with AKO version 1.3.3. If this setting is not deactivated, Tanzu Service Mesh will try to resolve the ingress gateway using the local FQDN rather than the external IP address, which will only work if the resolvers on the nodes point to Avi DNS. For information about the L4Settings.autoFQDN
setting, see the AKO documentation on GitHub.
Verify that a tenant is created in Avi for each user in your Tanzu Service Mesh organization. For information about creating tenants, see the Avi documentation.
Verify that you own the subdomains that you want to delegate to Avi GSLB and that you can delegate them to Avi GSLB.
Verify that you use Avi version 22.1.2. Tanzu Service Mesh currently does not support later versions of Avi.
Verify that there is connectivity between Tanzu Service Mesh SaaS or any onboarded clusters and the Avi Controllers.
You would need cluster labels to connect Tanzu Service Mesh SaaS and Avi controllers through a proxy.
Verify that there is connectivity between the Controllers on the different GSLB sites.
You are familiar with Avi concepts, such as Controller cluster, site, and virtual service. For more information about Avi concepts, see the Avi documentation.
Procedure
What to do next
After you have completed these steps, perform these verification steps:
A GSLB service has been automatically created in Avi, based on the public service configuration in the global namespace. To verify the configuration of the GSLB service, perform these steps:
Log in to Avi Admin Console.
Click in the upper-left corner and on the navigation pane, click Applications.
On the top bar, click GSLB Services. Notice that the App Domain Name column contains the domains delegated to Avi.
In the Name column, click the name of the GSLB service.
On the Members Status tab, notice that the Member Name column contains the endpoint of the ingress gateway of each cluster that you added to the global namespace.
Notice that green circles in the Overall Member Status column indicate that the endpoints are healthy.
Verify that Avi DNS responds to a DNS query for the public URL. You can run this command:
dig @AviDNSIP {public_URL} For example, dig @54.243.229.123 single.avi-servicemesh.biz
For information on changes to be performed when the GSLB leader is changed or elected, see GSLB Configuration Changes From a Follower Site.
For GSLB service health checks to work, you must ensure that there is connectivity from the Avi service engine (SE), which has an Avi DNS service attached to it, to the IP address of the workload cluster’s ingress gateway. If there is no connectivity, the health checks will fail, and Avi will generate an event about the health check endpoint being unreachable.
As a workaround, if the workload clusters are not in the same virtual private cloud (VPC) as the controller and the SEs, attach an Elastic IP address to the SE instances data interface by creating an Elastic IP address in AWS and attaching it to the data interface. You can see the interface ID on the Networking tab for the SE EC2 instance. After you apply this workaround, the health checks should work.
Deleting a cluster could affect the Avi proxy connections.