A public service is a service exposed for external access into the mesh. In Tanzu Service Mesh, you can configure public services to include integration to automate a supported global load balancer and public services without a global load balancer integration. 

To create a public service in Tanzu Service Mesh, you must describe its configuration, including the URL at which it will be accessible. This configuration is registered in its global namespace and applied to all of the clusters where this service resides.

If you want to make the service accessible at an HTTPS URL, select a previously uploaded TLS certificate in the service configuration. Clients will use this certificate to make secure, encrypted connections to the service. The domain in the certificate must match the domain specified for the public service.

In Tanzu Service Mesh you can configure public services that integrate with global load balancing (GSLB), or GSLB-enabled public services, and public services without GSLB, or non-GSLB public services. For a discussion of the concept of global load balancing, see Configure Global Load Balancing for Your Application in Tanzu Service Mesh.

If you want to publish your application for external access and load balance user requests across multiple clusters where the application is deployed using a GSLB like AWS Route 53 or NSX Advanced Load Balancer, you need to configure a GSLB-enabled public service. GSLB helps achieve high availability of your application.

If GSLB is not used or if the public service is not accessible from outside, you need to configure a non-GSLB public service.

Based on the configuration provided for the public service, Tanzu Service Mesh creates an ingress gateway definition on each Kubernetes cluster where the public service is running. This allows access to the service instance from the cluster’s ingress controller and Istio ingress gateways. 

When instances of the public service are added or removed on Kubernetes clusters that are onboarded to Tanzu Service Mesh, the global namespace detects these changes and creates any necessary ingress configuration and/or GSLB configuration to make this service accessible from outside. 

If a TLS certificate is selected for the service, the certificate will be added to the ingress controller on each cluster.

Important:
  • The URL configured to the public service restricts access to the public service that fronts the application to that URL only. Any attempts to access the application through other endpoint addresses, such as the cluster’s IP address, will be rejected.

  • If no GSLB is configured, manually add the URL for the public service into the DNS that clients will use to resolve the URL to the application. For testing, you can configure the local hosts file on your computer to resolve the URL to the public service. In a corporate environment, configure the corporate DNS to resolve the URL of the public service. For instructions on how to configure your DNS, see Creating a Non-GSLB Public Service - Developer Environment and Creating a Non-GSLB Public Service - Corporate Environment in the Example section.

  • If the GSLB that you use is not part of the supported list of providers in Tanzu Service Mesh, you must configure it manually because a GSLB is essentially a DNS service.

  • Another option to connect to the application with anything other than the public URL (like the cluster IP), is to apply a custom * wildcard gateway definition directly sto Istio on the Kubernetes cluster where the public service is running. Consider this example Istio manifest below:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: acme-gateway
spec:
  selector:
    istio: ingressgateway # use istio default controller
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: acme
spec:
  hosts:
    - "*"
  gateways:
    - acme-gateway
  http:
    - headers:
      request:
        add:
          x-allspark-request-header: gslb-cs1
      route:
        - destination:
            host: frontend.acme.com
  tcp: []
Note:
  • You can configure a public service in a global namespace before adding that service to the global namespace. When you add the service to the global namespace, Tanzu Service Mesh will read its configuration and make it public according to the settings that you specified.

  • The gateway configuration above includes a virtual service that is used to control the routing of incoming traffic. For more information about virtual services, see the Istio documentation.

The following procedure describes how to configure a public service in Tanzu Service Mesh, considering both GSLB and non-GSLB options.

Prerequisites

Before you begin configuring a public service, ensure that the following prerequisites are met: 

  • Verify that you are familiar with the concepts global namespace and public service in Tanzu Service Mesh.

  • Choose a fully qualified domain name (FQDN) for the URL at which the public service will be accessible:

    • If this service is accessible from the Internet through a GSLB, it must be a valid FQDN that is resolvable on the Internet.

    •  If no GSLB integration exists or if this public service is not accessible from the outside, you can define any FQDN that is configured in your DNS.

  • (Only for GSLB-enabled public services) If a supported GSLB integration is used, configure the integration for it in Tanzu Service Mesh. Currently, Tanzu Service Mesh supports NSX Advanced Load Balancer and AWS Route53. For more information about creating these integrations, see Create an Avi integration Account or an Amazon Web Services (AWS) integration account.

  • (Only for GSLB-enabled public services) When using a supported GSLB, create an external DNS account in Tanzu Service Mesh and select the domain provider that manages the public service's domain in the DNS account. For more information, see Manage Domains.

  • (Only for GSLB-enabled public services) Verify that you are familiar with the following GSLB concepts that are used in Tanzu Service Mesh. For more information about these concepts, see Configure Global Load Balancing for Your Application in Tanzu Service Mesh.

    • Global load balancing scheme (round robin, weighted, and active-passive)

    • Health checks

  • (Only for GSLB-enabled public services) If you want to use the weighted or active-passive global load balancing scheme for a public service, add the required labels to the service configuration on each cluster where the service is deployed. For instructions on how to add these labels, see Configure Global Load Balancing for Your Application in Tanzu Service Mesh.

  • To use an HTTPS URL for your public service, upload a Transport Layer Security (TLS) certificate for the service to Tanzu Service Mesh. For more information, see Add Certificates.

Procedure

  1. On the Public Services page of the New Global Namespace wizard or the Edit Cluster dialog box, click Configure Public Services.

    You can configure a public service 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 on accessing the the New Global Namespace wizard, see Connect Services Across Clusters with a Global Namespace. For information on accessing the Edit Cluster dialog box, see Edit a Cluster.

  2. Provide the following information about the public service.
    • Service Name. Select the service that you want to make public. The drop-down menu displays the names of the services in the global namespace. If you want to create a public service that isn't in the global namespace yet, type the service name in this field. When the service is added to the global namespace, Tanzu Service Mesh will make it public according to the configuration. 

    • Internal Service Port. Specify the port on which the service will be accessible. If a single port is defined for the service in the service configuration, that port is selected by default. If more than one port is defined, select the port that you want to use. You can also specify a port number that is not on the list. 

    Note:

    The public service will not work until the specified port is exposed by the service.

    • Public URL(s). Specify the parts of the URL at which the service will be accessible: the protocol, subdomain, and domain. If you select https, in the drop-down menu below, select the name of the certificate that you want to use for the service. You can select from the certificates that your administrator has uploaded to Tanzu Service Mesh. The specified URL appears under This service will be available at:.

    • Global Load Balancing Scheme. If you want a GSLB-enabled public service, select the appropriate scheme (Round Robin, Weighted, or Active-Passive). You must perform additional configuration steps based on your choice. If you do not want to use GSLB, select Non GSLB.

  3. (For a GSLB-enabled public service), perform these steps based on the global load balancing scheme that you have selected.

    Global load balancing scheme

    Perform these steps

    Round Robin

    Under Health Checks & Failover, configure health checks. For more information, see step 4.

    Weighted

    1. Under Weighted GSLB, next to Service Label Weights, from the Service Label drop-down menu, select one of the predefined weigh labels.

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

    3. To define an additional weight, click Add Service Label and repeat steps 2–3.

    4. Under Health Checks & Failover, configure health checks. For more information, see step 4.

    Note:

    Rather than using predefined weight labels, you can add custom weigh labels. To add a custom weight label:

    1. Under Service Label, click Add Service Label.

    2. Type the label that you want.

    3. Click Add service label: <label name> that appears below.

    4. Under Weight, type the weight value to associate with this label.

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

    Active-Passive

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

    2. From the Group Load Balancing Scheme/Policy drop-down menu, select a group loading scheme for the active group instances.

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

    4. From the Group Load Balancing Scheme/Policy drop-down menu, select a group loading scheme for the passive group instances.

    5. Under Health Checks & Failover, configure health checks. For more information, see step 4.

    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. To add a custom label:

    1. Next to Active Group Label or Passive Group Label, type the label that you want.

    2. Click Add service label: <label name> that appears below.

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

  4. Under Health Checks & Failover, configure health checks.
    • 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.

    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.

  5. To configure another GSLB-enabled or non-GSLB public service in the global namespace, at the bottom of the Public Services page, click Add Public Service and repeat steps 2–4.
  6. Click Next.

    The Configuration Summary page, under Public Services, displays a summary of each configured public service. If you want to make changes to the configuration, click Edit.

  7. To save the public services that you have configured in the global namespace, click Finish.

Example

Creating a GSLB-Enabled Public Service Using a Supported GSLB Integration

An example of a public service with GSLB is a sample e-commerce application. Let’s assume that the application has a frontend service that needs to be made public at store.acme.com to handle user requests. 

To create this public service in Tanzu Service Mesh, you must describe its configuration, including the URL at which it will be accessible (store.acme.com). This configuration is registered in its global namespace and is applied to all of the clusters where this service resides and to the GSLB where clients connect.

Creating a Non-GSLB Public Service - Developer Environment

In a development environment where no DNS access exists, developers might need to create a public service without GSLB and configure their local host file for access.

Let’s assume that there is a test service called test-app that needs to be accessible for local development.

Perform these steps to configure a non-GSLB public service and update the local hosts file:

  1. Create the test-app public service in Tanzu Service Mesh, providing an FQDN that does not exist on the Internet, for example, test-app.local.com.

  2. After the configuration is complete, Tanzu Service Mesh will generate an ingress gateway definition for each Kubernetes cluster where the service runs.

  3. To access test-app from your computer, edit your local hosts file (usually located at /etc/hosts on Unix-based systems or C:\Windows\System32\drivers\etc\hosts on Windows) to resolve test-app.local.com to the IP of the appropriate ingress controller of your Kubernetes cluster, for example: 192.168.0.10  test-app.local.com.

Creating a Non-GSLB Public Service - Corporate Environment

In a corporate environment, where access to a DNS exists and where that DNS is not a supported GSLB, the operator must manually configure the DNS to point to the ingress where the public service exists.

Let’s assume that there is a corporate application named corp-app that needs to be made accessible within the corporate network.

  1. Create the corp-app public service in Tanzu Service Mesh, specifying an FQDN that is recognized within the corporate DNS, for example, corp-app.internal.com.

  2. After the configuration is complete, Tanzu Service Mesh will create an ingress gateway definition on each Kubernetes cluster where the service is running.

  3. Manually configure the corporate DNS to resolve corp-app.internal.com to the IP of the corresponding ingress controller of your Kubernetes cluster.

When these steps are completed, users within your corporate network can access the corp-app service at the corp-app.internal.com URL.

What to do next

For non-GSLB public services, after the configuration is done, you must manually configure your external DNS to point to the ingress where the public service exists. Depending on your environment, this could be a local host file modification or a corporate DNS configuration. This step ensures that the public service is accessible from the intended network. For instructions on how to configure your DNS, see Creating a Non-GSLB Public Service - Developer Environment and Creating a Non-GSLB Public Service - Corporate Environment in the Example section.

For information about how to monitor the health of a public service, view its details, and monitor the performance of the public service with metric charts, see Monitor a Public Service.

For information about editing the configuration of a public service, including its public URL, see Edit the Configuration of a Public Service.