With global namespaces in Tanzu Service Mesh, you can easily connect and secure the services in your application across clusters. You can learn how to add the services in your application to a global namespace to have them automatically discovered and connected across the clusters.

Where appropriate, an example of a sample e-commerce application is used to show you how to connect services across clusters by adding them to a global namespace. The sample application is made up of 12 services and is configured to have most of the services deployed on one cluster and the catalog service deployed on the other cluster.

Prerequisites

Verify the following prerequisites:

  • You know the Kubernetes namespaces in your clusters that hold the services of your application.

  • You are in the Tanzu Service Mesh Console. For information about accessing the Tanzu Service Mesh Console, see Access the Tanzu Service Mesh Console.

Procedure

  1. In the Tanzu Service Mesh Console, create a global namespace for your application services:
    1. In the navigation panel on the left, click Add New and then click New Global Namespace.
    2. On the General Details page of the New Global Namepace wizard, enter a unique name and a domain name for the global namespace.

      The name of a global namespace and its domain name together forms a fully qualified domain name (FQDN) that uniquely identifies that global namespace and makes it possible for the services in the global namespace to communicate with each other across clusters.

      In the example, you must enter a name of sample-gns and a domain name of sample.app.com.

    3. On the Service Mapping page, to add the services in your application to the global namespace, specify their Kubernetes namespace-cluster pairs. Under Map services in Kubernetes Namespace(s), in the left drop-down menu, select the namespace on one of your clusters that holds some of the services and in the right drop-down menu, select the name of the cluster. Click Add Service Mapping to select namespace-cluster pairs for the other services deployed on the other clusters.

      The namespace-cluster pairs you specify here define service mapping rules that are used to select services for a global namespace. Click Service Preview under each service-mapping rule to see the names of the selected services from each cluster.

      The sample application has services running on two clusters. For most of the services running in one cluster, select the default namespace in the left drop-down menu and the prod-cluster1 cluster in the right drop-down menu. Then click Add Service Mapping and select the default namespace and the prod-cluster2 cluster for the catalog service on the other cluster.

    4. On the next pages of the wizard, select service and security options.

      On this page

      Select

      Public Services (Optional) page

      No Public Services

      External Services (Optional) page

      No External Services

      Security page

      Default Self-signed Certificate and Mandatory mTLS encryption

    5. Review the configuration of the global namespace and click Finish.
  2. To enable the cross-cluster communication between the services, edit the Kubernetes deployment manifest for the appropriate service on one cluster to specify the domain name of the global namespace, prefixing the domain name with the name of the service on the other cluster.
    Important:

    Make sure that you prefix the domain name with the name of the service that you want the service being edited to communicate with. See the following example.

    In the sample application, the shopping service on one cluster must communicate with the catalog service on the other cluster. To edit the deployment manifest of the shopping service, run the following kubectl command.

    kubectl --context=prod-cluster1.local edit deployment shopping

    In the deployment manifest, set the appropriate variable to catalog.sample.app.com. The catalog prefix is required for the shopping service to communicate with the catalog service.

    Important:

    If you are using your custom application instead of the sample application, make sure to add the name of the port in the latest version protocol resolver in the Kubernetes deployment manifest for your application. This is needed for the services running on one cluster to communicate with the services running on the other clusters.

    For HTTP, prefix name with "http-", for example, http-server. The following example of a deployment manifest shows name for HTTP under ports.

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: order-app-deployment
    spec:
      selector:
        matchLabels:
          app: order-service-app
      replicas: 1 # tells deployment to run N pods matching the template
      template: # create pods using pod definition in this template
        metadata:
          labels:
            app: order-service-app
    spec:
          containers:
          - env:
            - name: CATALOG_HOST
              value: catalog-service.onlinestore
            - name: CATALOG_PORT
              value: "8010"
            - name: CUSTOMER_HOST
              value: customer-management-service.onlinestore
            - name: CUSTOMER_PORT
              value: "8011"
            image: my-images/order-service
            imagePullPolicy: Always
            name: order-service-app
            ports:
            - containerPort: 8012
              name: http-server
              protocol: TCP
  3. Verify the cross-cluster communication between the services in Tanzu Service Mesh.
    1. On the navigation panel on the left, click Inventory and then Global Namespaces.
    2. On the Global Namespaces page, click the name of the global namespace that you created (sample-gns in the example).
    3. Click the GNS Topology tab.

      The service topology graph shows the connections between the services in the different clusters. The line between the services indicates that traffic flows between them. The number of requests per seconds (RPS) or other specified service metrics are shown.

What to do next

For information about how to specify metrics to show in the service topology graph and other details about using the topology graph, see View the Summary Infrastructure and Service Information.