When publishing your application for external access, you can configure a supported global load balancing (GSLB) 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 from within its global namespace. 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 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.

If you want to publish your application for external access and have an integrated load balancer, such as AWS Route 53 or NSX Advanced Load Balancer, and want to load balance user requests across the clusters where the application is deployed, you need to add global load balancing (GSLB) configuration parameters to the configuration of the public service in its global namespace. In Tanzu Service Mesh, public services that have incoming requests load balanced according to their GSLB configuration are called GSLB-enabled public services.

Tanzu Service Mesh will distribute the traffic to the instances of a GSLB-enabled public service according to its global load balancing configuration. AWS Route 53 or NSX Advanced Load Balancer will provide domain name system (DNS) and GSLB capabilities for the service.

The GSLB configuration of a public service consists of the following elements.

  • Global load balancing scheme

As part of the GSLB 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.

  • Health checks

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.

You can create a GSLB-enabled public service and provide its GSLB and health-check parameters in the New Global Namespace wizard when you're creating a global namespace or in the Edit Cluster dialog box when you're editing the global namespace configuration. For information about creating a GSLB service, see Create a Public Service.

As noted above, if you want to use the weighted or active-passive global load balancing scheme for a public service, you must must add weight labels or active group and passive group labels to the service configuration on each cluster where the service is deployed. You must add these labels on the clusters as a prerequisite to adding the GSLB configuration for the public service.

The following procedure describes the steps that you must perform on each cluster where instances of the public service are deployed to add the weight labels or active and passive group labels for the service.

Procedure

  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 svc/{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

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 a 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.