The following example creates a route table for your sample apps so that you can route between services across clusters. You can use this setup to test most Gloo policies, such as traffic management, security, and resiliency policies.

Verify in-cluster routing

Verify that the productpage service can route to the reviews-v1 and reviews-v2 services within the same service mesh in cluster1.

  1. In a separate tab in your terminal, open the Bookinfo product page from your local host.

    1. Enable port-forwarding on the product page deployment.
        kubectl --context ${REMOTE_CONTEXT1} -n bookinfo port-forward deployment/productpage-v1 9080:9080
    2. Open your browser to http://localhost:9080/productpage?u=normal.

  2. Refresh the page a few times to see the black stars in the Book Reviews column appear and disappear. The presence of black stars represents reviews-v2 and the absence of black stars represents reviews-v1. Note that the styling of red stars from reviews-v3 is not shown because the services in cluster1 do not currently communicate with the services in cluster2.

    Figure: Bookinfo product page UI
    Figure: Bookinfo product page UI

Set up multicluster routing

Route between services across the service meshes in your workload clusters. In order for the productpage service on cluster1 to access reviews-v3 on cluster2, you create a virtual destination that represents all versions of the reviews app across both clusters. Then, you create a route table to route from productpage to the virtual destination, and divert 75% of reviews traffic to the reviews-v3 service.

Deploy east-west gateways in each workload cluster

  1. Save the revision that you used for your istiod installation in an environment variable. Typically, this is main for a Helm installation, or gloo for a Gloo Operator installation.

    • Gloo Operator:
        export REVISION=gloo
    • Helm:
        export REVISION=main

  2. Deploy an Istio east-west gateway into each workload cluster. An east-west gateway lets services in one mesh communicate with services in another.

      helm upgrade --install istio-eastwestgateway istio/gateway \
--version ${ISTIO_VERSION} \
--namespace istio-eastwest \
--create-namespace \
--kube-context ${REMOTE_CONTEXT1} \
--wait \
-f - <<EOF
revision: ${REVISION}
global:
  hub: ${REPO}
  tag: ${ISTIO_VERSION}-solo
  network: ${REMOTE_CLUSTER1}
  multiCluster:
    clusterName: ${REMOTE_CLUSTER1}
name: istio-eastwestgateway
labels:
  app: istio-eastwestgateway
  istio: eastwestgateway
  revision: ${REVISION}
  topology.istio.io/network: ${REMOTE_CLUSTER1}
service:
  type: LoadBalancer
  ports:
    # Port for health checks on path /healthz/ready.
    # For AWS ELBs, this port must be listed first.
    - port: 15021
      targetPort: 15021
      name: status-port
    # Port for multicluster mTLS passthrough; required for Gloo Mesh east/west routing
    - port: 15443
      targetPort: 15443
      # Gloo Mesh looks for this default name 'tls' on a gateway
      name: tls
    # Port required for VM onboarding
    #- port: 15012
      #targetPort: 15012
      # Required for VM onboarding discovery address
      #name: tls-istiod
EOF

helm upgrade --install istio-eastwestgateway istio/gateway \
--version ${ISTIO_VERSION} \
--namespace istio-eastwest \
--create-namespace \
--kube-context ${REMOTE_CONTEXT2} \
--wait \
-f - <<EOF
revision: ${REVISION}
global:
  hub: ${REPO}
  tag: ${ISTIO_VERSION}-solo
  network: ${REMOTE_CLUSTER2}
  multiCluster:
    clusterName: ${REMOTE_CLUSTER2}
name: istio-eastwestgateway
labels:
  app: istio-eastwestgateway
  istio: eastwestgateway
  revision: ${REVISION}
  topology.istio.io/network: ${REMOTE_CLUSTER2}
service:
  type: LoadBalancer
  ports:
    # Port for health checks on path /healthz/ready.
    # For AWS ELBs, this port must be listed first.
    - port: 15021
      targetPort: 15021
      name: status-port
    # Port for multicluster mTLS passthrough; required for Gloo Mesh east/west routing
    - port: 15443
      targetPort: 15443
      # Gloo Mesh looks for this default name 'tls' on a gateway
      name: tls
    # Port required for VM onboarding
    #- port: 15012
      #targetPort: 15012
      # Required for VM onboarding discovery address
      #name: tls-istiod
EOF

  3. Verify that the east-west gateway pods are running and the load balancer service is assigned an external address.

      kubectl get pods,svc -n istio-eastwest --context ${REMOTE_CONTEXT1}
kubectl get pods,svc -n istio-eastwest --context ${REMOTE_CONTEXT2}

    Example output:

      NAME                                         READY   STATUS    RESTARTS   AGE
pod/istio-eastwestgateway-5fc96789b4-chwrp   1/1     Running   0          55s

NAME                            TYPE           CLUSTER-IP       EXTERNAL-IP                                                              PORT(S)                           AGE
service/istio-eastwestgateway   LoadBalancer   172.20.113.232   ab56b2563813e4ee3aa7f149702061ec-340422164.us-east-1.elb.amazonaws.com   15021:31570/TCP,15443:32145/TCP   56s
NAME                                        READY   STATUS    RESTARTS   AGE
pod/istio-eastwestgateway-b8867b49f-smglk   1/1     Running   0          49s

NAME                            TYPE           CLUSTER-IP       EXTERNAL-IP                                                               PORT(S)                           AGE
service/istio-eastwestgateway   LoadBalancer   172.20.195.142   a7dab5dc1889246acadee31524d4c29f-1451085286.us-east-1.elb.amazonaws.com   15021:30788/TCP,15443:32698/TCP   49s

Enable routing across clusters

  1. Create a Gloo root trust policy to ensure that services in cluster1 securely communicate with the reviews service in cluster2. The root trust policy sets up the domain and certificates to establish a shared trust model across multiple clusters in your service mesh.

      kubectl apply --context $MGMT_CONTEXT -f - <<EOF
apiVersion: admin.gloo.solo.io/v2
kind: RootTrustPolicy
metadata:
  name: root-trust
  namespace: gloo-mesh
spec:
  config:
    mgmtServerCa:
      generated: {}
EOF

  2. Restart istiod and the sample apps that you deployed earlier to apply the updated certificates.

      kubectl rollout restart deployment istiod-${REVISION} -n istio-system --context ${REMOTE_CONTEXT1}
kubectl rollout restart deployment istiod-${REVISION} -n istio-system --context ${REMOTE_CONTEXT2}
kubectl rollout restart deployment details-v1 productpage-v1 ratings-v1 reviews-v1 reviews-v2 -n bookinfo --context ${REMOTE_CONTEXT1}
kubectl rollout restart deployment ratings-v1 reviews-v3 -n bookinfo --context ${REMOTE_CONTEXT2}
kubectl rollout restart deployment httpbin -n httpbin --context ${REMOTE_CONTEXT1}
kubectl rollout restart deployment helloworld-v1 helloworld-v2 -n helloworld --context ${REMOTE_CONTEXT1}
kubectl rollout restart deployment helloworld-v3 helloworld-v4 -n helloworld --context ${REMOTE_CONTEXT2}

  3. Create a virtual destination resource and define a unique hostname that in-mesh gateways can use to send requests to the reviews app. This virtual destination is configured to listen for incoming traffic on the internal-only, arbitrary hostname reviews.mesh.internal.com:8080.

      kubectl apply --context $MGMT_CONTEXT -n bookinfo -f- <<EOF
apiVersion: networking.gloo.solo.io/v2
kind: VirtualDestination
metadata:
  name: reviews-vd
  namespace: bookinfo
spec:
  hosts:
  # Arbitrary, internal-only hostname assigned to the endpoint
  - reviews.mesh.internal.com
  ports:
  - number: 9080
    protocol: HTTP
  services:
    - labels:
        app: reviews
EOF

  4. Create a route table that defines how east-west requests within your mesh are routed from the productpage service to the reviews-vd virtual destination. When you apply this route table, requests from productpage to /reviews now route to one of the three reviews versions across clusters. The east-west gateway in your mesh does the work of taking requests made to the reviews.bookinfo.svc.cluster.local hostname and routing them to the reviews.mesh.internal.com virtual destination hostname that you specified in the previous step.

      kubectl apply --context $MGMT_CONTEXT -n bookinfo -f- <<EOF
apiVersion: networking.gloo.solo.io/v2
kind: RouteTable
metadata:
  name: bookinfo-east-west
  namespace: bookinfo
spec:
  hosts:
    - 'reviews.bookinfo.svc.cluster.local'
  workloadSelectors:
    - selector:
        labels:
          app: productpage
  http:
    - name: reviews
      matchers:
      - uri:
          prefix: /reviews
      forwardTo:
        destinations:
          - ref:
              name: reviews-vd
            kind: VIRTUAL_DESTINATION
            port:
              number: 9080
      labels: 
        route: reviews
EOF

  5. In your terminal, open the Bookinfo product page from your local host.

    1. Enable port-forwarding on the product page deployment.
        kubectl --context ${REMOTE_CONTEXT1} -n bookinfo port-forward deployment/productpage-v1 9080:9080
    2. Open your browser to http://localhost:9080/productpage?u=normal.

  6. Refresh the page a few times again. Now, the red stars for reviews-v3 are shown in the book reviews.

    Figure: Bookinfo product page UI with red star reviews
    Figure: Bookinfo product page UI with red star reviews

    Bookinfo services in cluster1 are now successfully accessing the Bookinfo services in cluster2!

Next

Apply a fault injection policy to the reviews service to delay requests and simulate network issues or an overloaded service.