Set up routing for sample apps

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 link

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/. You might need to click Normal user to open the app.

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.
   

   

   

Set up multicluster routing link

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.

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. 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. Note that this host value is different than the actual internal address that the reviews app can be reached by, because this host is an internal address that is used only by the gateways in your mesh.

     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: 8080
       protocol: HTTP
       targetPort:
         number: 9080
     services:
       - labels:
           app: reviews
   EOF
     

3. 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: 8080
         labels: 
           route: reviews
   EOF
     

4. In the http://localhost:9080/ page in your web browser, refresh the page a few times again. Now, the red stars for reviews-v3 are shown in the book reviews.
   

   

   

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

Next link

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