Configure Global Load Balancing for Your Application in Tanzu Service Mesh

When publishing your application for external access, you can configure global load balancing for it so that user requests are load balanced across multiple clusters in one or multiple zones or regions. With global load balancing, you can achieve high availability of your application.

A general practice for achieving high availability is to deploy an application in more than one cluster and position a global load balancer between them to direct north-south traffic to the frontend services deployed on these clusters.

In Tanzu Service Mesh, you can publish your application to external clients through a public service by using a global namespace and the integrations of Tanzu Service Mesh with AWS Route 53 or NSX Advanced Load Balancer (formerly AVI Networks). AWS Route 53 or NSX Advanced Load Balancer provides domain name system (DNS) and global service load balancing (GSLB) capabilities. A public service is an HTTP or HTTPS service that you expose externally from a global namespace. When configuring a public service, you specify one or more DNS fully qualified domain names (FQDNs) for the public service to designate them as the public URLs. A public URL is an URL at which the public service is exposed to external clients. You then provide a global load balancing configuration for each public URL of the public service. Tanzu Service Mesh distributes the traffic to the service instances according to the global load balancing configuration.

As part of the global load balancing configuration, you must select a global load balancing scheme for each public URL of the public service. You can choose between a round robin, weighted, or active-passive global load balancing scheme.

The round robin algorithm distributes user requests equally among the healthy service instances by forwarding requests to each instance in turn.

The weighted load balancing algorithm splits traffic to the service into percentage-based portions according to relative service weights. The traffic percentages are calculated according to the formula: a service weight divided by the sum of all of the service weights. For example, if you assign a service instance a weight of 20 and give other two instances a weight of 10, the load balancing algorithm will compute that 50% of the traffic goes to the first instance, and 25% of the traffic is sent to each of the other two instances. To define weights for the public service, you must add a weight label to the service configuration on each cluster where the service is deployed and then associate these predefined weight labels with the appropriate weight values in the UI. A percentage of the traffic will be routed to a specific public service instance based on the weight value associated with the weight label that is defined for that instance in its service configuration.

With the active-passive scheme, you can configure a failover routing policy by defining active and passive groups of service instances. Traffic is routed to the active group until at least one instance in the active group is healthy. If health checks determine that all the active instances are unhealthy, the load balancing algorithm fails over to the instances in the passive group. To configure active and passive groups, you must add an active group label or a passive group label to the service configuration on each cluster where the service is deployed and then select these predefined labels for the active and passive groups respectively in the UI. A specific public service instance is assigned to the active group or passive group based on whether the active group label or passive group label is defined in its service configuration.

You additionally define a group load balancing scheme, round robin or weighted, for the service instances within the active group and the passive group. Round robin is selected by default. For example, if you specify a group load balancing scheme of round robin for the passive group and if all the active group instances are unhealthy, the traffic will be rotated through the passive group instances according to the round robin algorithm.

You also configure health checks in the global load balancing configuration. Tanzu Service Mesh uses the specified health-check settings to periodically check whether the public service is reachable and functional. If health checks determine that a service instance is unhealthy, Tanzu Service Mesh routes traffic to other instances according to the configured global load balancing scheme. You can use the default health-check settings or define custom settings.

Prerequisites

• Access the Tanzu Service Mesh Console.

• Create an Avi integration Account or an Amazon Web Services (AWS) integration account, depending on you use NSX Advanced Load Balancer or Amazon Route 53 for domain name system (DNS) routing and global load balancing.

• Create a global namespace.

• Configure a public service in the global namespace.

Procedure

1. To add weight labels and active and passive group labels for the public service, perform these steps on each cluster where instances of the public service are deployed.
   1. Set the current context to the cluster and the namespace where the public service instances are deployed.

      kubectl config set-context {context} --cluster={cluster_name} --namespace={namespace_name}

   2. To edit the service configuration on the cluster, run this command.

      kubectl -n {namespace_name} edit {service_name} 

   3. In the service configuration, under labels, add the following labels

      Label	Description
      tsm_gslb_group	The active group or passive group label. Set the label to a meaningful value to specify whether this is the active group label or passive group label. See examples below. Important: In the service configuration of a specific public service instance, you can use tsm_gslb_group as the active group label or the passive group label, but not for both groups.
      tsm_gslb_weight	The weight label. Set the label to a meaningful value to help associate the label with the appropriate weight in the UI. See examples below.

      Note:

      Make sure that you add the label names exactly as are given in the Label column.

      For example, a public service named cart is deployed in three clusters: cluster A, cluster B, and cluster C. You want the public service instances on clusters A and B to be in the active group, and the public service instance on cluster C in the passive group.

      You add the following labels to the service configuration on each cluster.

      Cluster A

      Active group label

      tsm_gslb_group: ActiveGroup

      Weight label

      tsm_gslb_weight: primaryload

      Cluster B

      Active group label

      tsm_gslb_group: ActiveGroup

      Weight label

      tsm_gslb_weight: secondaryload

      Cluster C

      Passive group label

      tsm_gslb_group: PassiveGroup

2. Edit the configuration of the global namespace that contains the public service.
   1. In the navigation pane on the left, click Home.
   2. On the GNS Overview tab, in the upper-right corner of the global namespace card, click the three vertical dots and then click Edit Global Namespace.
3. In the Edit Global Namespace window, go to the GSLB & Resiliency page.

   The GSLB & Resiliency page displays a separate configuration section for each public URL of each public service configured in the global namespace. The public URL appears to the right of the name of the public service.

4. In the configuration section for each public URL of the public service, from the Global Load Balancing Scheme drop-down menu, select Round Robin, Weighted, or High Availability (Active-Passive).
5. Perform these steps depending on the global load balancing scheme that you selected.

   Global load balancing scheme	Steps to perform
   Round Robin	Under Health Checks & Failover, configure health checks. For more information, see step 5.
   Weighted	Under Health Checks & Failover, configure health checks. For more information, see step 5. Next to Service Label Weights, from the Service Label drop-down menu, select one of the predefined weigh labels. Under Weight, type the weight value that you want to associate with the service label. You can add a weight value between 0 and 20. To define an additional weight, click Add Service Label and repeat steps 2–3. Note: Rather than using predefined weight labels, you can add custom weigh labels from the GSLB & Resiliency page. To add a custom weight label: Under Service Label, click Add Service Label. Type the label that you want. Click Add Rule: <label name> that appears below. Under Weight, type the weight value to associate with this label. Assign this custom weight label to the public service instances you want. For each instance, edit the service configuration on its cluster and set tsm_gslb_weight under labels to the label name.
   High Availability (Active-Passive)	Under Health Checks & Failover, configure health checks. For more information, see step 5. To specify the service label for the active group of service instances, under Active Group, in the Active Group Label drop-down menu, select the predefined active group label. From the Group Load Balancing Scheme/Policy drop-down menu, select a group loading scheme for the active group instances. To specify the service label for the passive group of service instances, under Passive Group, in the Passive Group Label drop-down menu, select the predefined passive group label. From the Group Load Balancing Scheme/Policy drop-down menu, select a group loading scheme for the passive group instances. If you selected Weighted from the Group Load Balancing Scheme drop-down menu for the active group or the passive group, next to Service Label Weights, define the service weights for the active group or passive group instances. For details, see the description of Weighted in this table. Note: Rather than using predefined active and passive group labels, you can add custom labels from the GSLB & Resiliency page. To add a custom label: Next to Active Group Label or Passive Group Label, type the label that you want. Click Add Rule: <label name> that appears below. Assign the active group label or the passive group label to the appropriate public service instances. For each instance, edit the service configuration on its cluster and set tsm_gslb_group under labels to the active group label or the passive group label.

   For our example in step 1c, the following GSLB configuration is specified for a public URL of the cart service on the GSLB & Resiliency page.
   
   
6. Under Health Checks & Failover, configure health checks for the public service.

   • To use the default health-check settings, click Default TSM Health Checks. To view the default settings, point to the information icon to the right of Default TSM Health Checks.

   • To use custom health-check settings, click Custom Health Checks. Provide values for the following settings.

   Setting	Description
   Protocol	The protocol (HTTPS or HTTP) to use for health-check requests.
   Port	The port to which Tanzu Service Mesh sends health-check requests. You can have a specific port number assigned for health checks, and that port can be different from the one that you specified for the public service in its configuration. Note: The list in Port contains the ports exposed by the service. You can enter a port that is not on the list if, for example, you plan to change the service configuration later to have it expose that port. However, the public service will not work until a specified port is exposed by the service.
   (Optional) Relative Path	The URL path to which Tanzu Service Mesh sends health-check requests. This path can be different from the public URL that you specified for the public service.
   Health Check Interval	The amount of time between health-check requests in seconds. You can select 10 seconds or 30 seconds. For example, if you select 30 seconds, Tanzu Service Mesh will send health-check requests to the service every 30 seconds.
   Healthy & Unhealthy Threshold	The number of consecutive failed health checks for the service to be considered unhealthy, or the number of consecutive successful health checks for the service to be considered healthy. For example, with the default Healthy & Unhealthy Threshold value of 3, Tanzu Service Mesh determines that the service is unhealthy after three consecutive failed health-check requests and then considers the service healthy after the subsequent three successful requests.

7. Repeat steps 4–6 for each public URL of the public service.

   The Configuration Summary page of the Edit Global Namespace window displays the global load balancing configuration that you specified for each public URL of the public service.

8. On the Configuration Summary page, click Finish.

What to do next

You can view the global load balancing configuration of the public service on the Configuration tab of the public service details page. For more information, see Monitor a Public Service.

You can edit the global load balancing configuration from the public service details page. For more information, see Edit the Configuration of a Public Service.

You can view the information about how traffic is routed to the different public URLs of the public service, including the service-level metrics like requests per second (RPS), on the GSLB Routing tab of the public service details page. For more information, see Monitor a Public Service.