arrow_back

Traffic Management with Anthos Service Mesh

Join Sign in

Traffic Management with Anthos Service Mesh

1 hour 30 minutes 1 Credit

GSP656

Google Cloud self-paced labs logo

Overview

With Anthos Service Mesh, you can manage service discovery, traffic routing, and load balancing for your service mesh without having to update code in your services. Anthos Service Mesh simplifies configuration of service-level properties like timeouts and retries, and makes it straightforward to set up tasks like staged rollouts with percentage-based traffic splits.

Anthos Service Mesh’s traffic management model relies on the following two components:

  • Pilot: the core traffic management controller component.
  • Envoy proxies: which enforce configurations and policies set through Pilot.

The Pilot architecture

These components enable Istio traffic management features including:

  • Service discovery

  • Load balancing

  • Traffic routing and control

Objectives

In this lab, you learn how to perform the following tasks:

  • Review Traffic Management use cases

  • Configure and use Istio Gateways

  • Apply default destination rules, for all available versions

  • Apply virtual services to route by default to only one version

  • Route to a specific version of a service based on user identity

  • Shift traffic gradually from one version of a microservice to another

  • Use the Anthos Service Mesh dashboard to view routing to multiple versions

Setup and requirements

Before you click the Start Lab button

Read these instructions. Labs are timed and you cannot pause them. The timer, which starts when you click Start Lab, shows how long Google Cloud resources will be made available to you.

This hands-on lab lets you do the lab activities yourself in a real cloud environment, not in a simulation or demo environment. It does so by giving you new, temporary credentials that you use to sign in and access Google Cloud for the duration of the lab.

To complete this lab, you need:

  • Access to a standard internet browser (Chrome browser recommended).
Note: Use an Incognito or private browser window to run this lab. This prevents any conflicts between your personal account and the Student account, which may cause extra charges incurred to your personal account.
  • Time to complete the lab---remember, once you start, you cannot pause a lab.
Note: If you already have your own personal Google Cloud account or project, do not use it for this lab to avoid extra charges to your account.

How to start your lab and sign in to the Google Cloud Console

  1. Click the Start Lab button. If you need to pay for the lab, a pop-up opens for you to select your payment method. On the left is the Lab Details panel with the following:

    • The Open Google Console button
    • Time remaining
    • The temporary credentials that you must use for this lab
    • Other information, if needed, to step through this lab
  2. Click Open Google Console. The lab spins up resources, and then opens another tab that shows the Sign in page.

    Tip: Arrange the tabs in separate windows, side-by-side.

    Note: If you see the Choose an account dialog, click Use Another Account.
  3. If necessary, copy the Username from the Lab Details panel and paste it into the Sign in dialog. Click Next.

  4. Copy the Password from the Lab Details panel and paste it into the Welcome dialog. Click Next.

    Important: You must use the credentials from the left panel. Do not use your Google Cloud Skills Boost credentials. Note: Using your own Google Cloud account for this lab may incur extra charges.
  5. Click through the subsequent pages:

    • Accept the terms and conditions.
    • Do not add recovery options or two-factor authentication (because this is a temporary account).
    • Do not sign up for free trials.

After a few moments, the Cloud Console opens in this tab.

Note: You can view the menu with a list of Google Cloud Products and Services by clicking the Navigation menu at the top-left. Navigation menu icon

Activate Cloud Shell

Cloud Shell is a virtual machine that is loaded with development tools. It offers a persistent 5GB home directory and runs on the Google Cloud. Cloud Shell provides command-line access to your Google Cloud resources.

  1. Click Activate Cloud Shell Activate Cloud Shell icon at the top of the Google Cloud console.

When you are connected, you are already authenticated, and the project is set to your PROJECT_ID. The output contains a line that declares the PROJECT_ID for this session:

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud is the command-line tool for Google Cloud. It comes pre-installed on Cloud Shell and supports tab-completion.

  1. (Optional) You can list the active account name with this command:

gcloud auth list
  1. Click Authorize.

  2. Your output should now look like this:

Output:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`
  1. (Optional) You can list the project ID with this command:

gcloud config list project

Output:

[core] project = <project_ID>

Example output:

[core] project = qwiklabs-gcp-44776a13dea667a6 Note: For full documentation of gcloud, in Google Cloud, refer to the gcloud CLI overview guide.

Task 1. Review traffic management use cases

Different traffic management capabilities are enabled by using different configuration options.

Example: Traffic Splitting

Route traffic to multiple versions of a service.

Traffic splitting

Example: Timeouts

Set a timeout, the amount of time Istio waits for a response to a request. The timeout for HTTP requests is 15 seconds, but it can be overridden.

Timeouts

Example: Retries

A retry is an attempt to complete an operation multiple times if it fails. Adjust the maximum number of retry attempts, or the number of attempts possible within the default or overridden timeout period.

Retries

Example: Fault injection: inserting delays

Fault injection is a testing method that introduces errors into a system to ensure that it can withstand and recover from error conditions.

Fault Injection Delays

This example introduces a 5 second delay in 10% of the requests to the "v1" version of the ratings microservice.

Example: Fault injection: inserting aborts

Fault Injection Aborts

The above example returns an HTTP 400 error code for 10% of the requests to the ratings service "v1".

Example: Conditional routing: Based on source labels

Conditional Source Labels

A rule can indicate that it only applies to calls from workloads (pods) implementing the version v2 of the reviews service.

Example: Complete lab setup

Conditional End User

The above rule only applies to an incoming request if it includes a custom "end-user" header that contains the string "atharvak".

Task 2. Complete lab setup

This lab environment has already been partially configured.

  • A GKE cluster named gke was created.

  • Anthos Service Mesh has been installed.

  • The Bookinfo multi-service sample application was deployed.

Configure cluster access for kubectl

  1. In Cloud Shell, set environment variables for the zone and cluster name:

    export CLUSTER_NAME=gke export CLUSTER_ZONE={{{ project_0.default_zone }}}
  2. Configure kubectl command line access by running:

    export GCLOUD_PROJECT=$(gcloud config get-value project) gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $CLUSTER_ZONE --project $GCLOUD_PROJECT

    If prompted, click the Authorize button.

Verify cluster and Anthos Service Mesh installation

  1. Check that your cluster is up and running:

    gcloud container clusters list

    Output:

    NAME: gke LOCATION: {{{ project_0.default_zone }}} MASTER_VERSION: 1.21.10-gke.2000 ... ... STATUS: RUNNING
  2. Ensure the Kubernetes pods for the Istio control plane are deployed:

    kubectl get pods -n istio-system

    Output:

    NAME READY STATUS ... istio-ingressgateway-5c9b4874bb-4wz6m 1/1 Running istio-ingressgateway-5c9b4874bb-wssl7 1/1 Running istiod-69c7bd76f-jf2tv 1/1 Running istiod-69c7bd76f-pfkrz 1/1 Running

    Pod status should be Running or Completed.

  3. Ensure corresponding Kubernetes services for the Istio control plane are deployed:

    kubectl get service -n istio-system

    Output:

    NAME TYPE ... istio-ingressgateway LoadBalancer istiod ClusterIP istiod-asm-xxx ClusterIP
  4. Ensure corresponding Kubernetes pods for the Anthos Service Mesh control plane are deployed, so that telemetry data is displayed in the ASM Dashboard:

    kubectl get pods -n asm-system

    Output:

    NAME READY STATUS ... canonical-service-controller-manager-7684454647-4pgx7 2/2 Running

    Pod status should be Running.

Verify the Bookinfo deployment

  1. Confirm that the application has been deployed correctly:

    kubectl get pods

    Output:

    NAME READY STATUS details-v1-1520924117-48z17 2/2 Running productpage-v1-560495357-jk1lz 2/2 Running ratings-v1-734492171-rnr5l 2/2 Running reviews-v1-874083890-f0qf0 2/2 Running reviews-v2-1343845940-b34q5 2/2 Running reviews-v3-1813607990-8ch52 2/2 Running

    You may need to re-run this command until you see that all six pods are in Running status.

    Note: See how each pod has two containers? That's the application container and the Istio proxy sidecar.
  2. Review running application services:

    kubectl get services

    Output:

    NAME TYPE CLUSTER-IP EXTERNAL-IP ... details ClusterIP 10.7.248.49 <none> kubernetes ClusterIP 10.7.240.1 <none> productpage ClusterIP 10.7.248.22 <none> ratings ClusterIP 10.7.247.26 <none> reviews ClusterIP 10.7.246.22 <none>

Install a load generation tool

You will need a tool to generate traffic against your application later in the lab.

  • In Cloud Shell, install siege:

sudo apt install siege

Task 3. Understand ingress configuration using an Istio Gateway resource

In a Kubernetes environment, the Kubernetes Ingress Resource is used to specify services that should be exposed outside the cluster. In Anthos Service Mesh, a better approach, which also works in Kubernetes and other environments, is to use a Gateway resource. A Gateway allows Istio features such as monitoring and route rules to be applied to traffic entering the cluster.

The Istio Gateways diagram

The Istio Gateway overcomes Kubernetes Ingress shortcomings by separating the L4-L6 spec from L7. It only configures the L4-L6 functions (e.g. ports to expose, TLS configuration) that are uniformly implemented by all good L7 proxies. Users bind a VirtualService resource to the Gateway then use standard Istio rules to control HTTP requests and TCP traffic.

The Anthos Service Mesh installed with this lab, enables the istio-ingressgateway component. This ingress gateway uses an external TCP load balancer in Google Cloud.

Explore ingress in the istio control plane

  1. View details about istio-ingressgateway:

    kubectl describe svc istio-ingressgateway -n istio-system

    Notice the resource is a LoadBalancer.

  2. Save this external IP in your Cloud Shell environment:

    export GATEWAY_URL=$(kubectl get svc istio-ingressgateway \ -o=jsonpath='{.status.loadBalancer.ingress[0].ip}' -n istio-system) echo "The gateway address is $GATEWAY_URL"

Generate some background traffic

You will generate some background traffic against the application so that when you explore the Anthos Service Mesh dashboard, there's some interesting data to view.

  • Use siege to create traffic against your services:

    siege http://${GATEWAY_URL}/productpage

Explore using the ingress gateway with your application

As part of the lab setup, a Gateway resource, bookinfo-gateway was configured, referencing the Istio ingress gateway.

  1. In Cloud Shell, open another tab by clicking on the + icon in the Cloud Shell menu bar.

  2. Initialize the new Cloud Shell tab:

    export CLUSTER_NAME=gke export CLUSTER_ZONE={{{ project_0.default_zone }}} export GCLOUD_PROJECT=$(gcloud config get-value project) gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $CLUSTER_ZONE --project $GCLOUD_PROJECT export GATEWAY_URL=$(kubectl get svc istio-ingressgateway \ -o=jsonpath='{.status.loadBalancer.ingress[0].ip}' -n istio-system)
  3. Display the bookinfo-gateway configuration:

    kubectl describe gateway bookinfo-gateway

    Output:

    Name: bookinfo-gateway Namespace: default Labels: <none> Annotations: API Version: networking.istio.io/v1alpha3 Kind: Gateway Metadata: Creation Timestamp: 2020-06-10T14:20:03Z Generation: 1 Resource Version: 2039 Self Link: /apis/networking.istio.io/v1alpha3/namespaces/default/gateways/bookinfo-gateway UID: 7899a7a9-dcc4-4607-bf18-1984f4f3f31a Spec: Selector: Istio: ingressgateway Servers: Hosts: * Port: Name: http Number: 80 Protocol: HTTP Events: <none>

    Notice that the gateway enables HTTP traffic over port 80.

  4. Explore the VirtualService used by Bookinfo to route traffic from the gateway:

    kubectl describe virtualservices bookinfo

    Notice that the virtual service references bookinfo-gateway, and establishes a default destination of the productpage service.

    Output:

    Name: bookinfo Namespace: default Labels: <none> Annotations: API Version: networking.istio.io/v1alpha3 Kind: VirtualService Metadata: Creation Timestamp: 2020-06-10T14:20:03Z Generation: 1 Resource Version: 2041 Self Link: /apis/networking.istio.io/v1alpha3/namespaces/default/virtualservices/bookinfo UID: c792923b-3de0-41b3-82d9-87840efbe5b2 Spec: Gateways: bookinfo-gateway Hosts: * Http: Match: Uri: Exact: /productpage Uri: Prefix: /static Uri: Exact: /login Uri: Exact: /logout Uri: Prefix: /api/v1/products Route: Destination: Host: productpage Port: Number: 9080 Events: <none>
  5. Confirm that the Bookinfo application responds by sending a curl request to it from some pod, within the cluster, for example from ratings:

    kubectl exec -it \ $(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}') \ -c ratings -- curl productpage:9080/productpage \ | grep -o "<title>.*</title>"

    Output:

    <title>Simple Bookstore App</title>
  6. Check that the Bookinfo app responds to a curl request sent to it from outside the cluster, using the external IP saved earlier:

    curl -I http://${GATEWAY_URL}/productpage

    Output:

    HTTP/1.1 200 OK content-type: text/html; charset=utf-8 content-length: 4415 server: istio-envoy ...

You exposed an HTTP endpoint for the Bookinfo productpage service to external traffic. The Gateway configuration resources allow external traffic to enter the Istio service mesh and make the traffic management and policy features of Istio available for edge services.

Task 4. Use the Anthos Service Mesh dashboard to view routing to multiple versions

Note: There are a couple of items to note when it comes to viewing data in the Anthos Service Mesh dashboard.

The first is that, for most pages, it takes 1-2 minutes for the data to be available for display. That means that if you look at a page, it might not have the data you expect for 1-2 minutes. If you don't see the data you want, wait for a minute or so and then refresh the page.

The Topology page also has a big initial delay before data is shown. It can take up to 5+ minutes for the initial set of data to be available. If you see a message that there is no data, wait a bit and then refresh the page and return to the Topology view.

In the previous paragraphs, you are instructed to wait AND to refresh the page. As it turns out, not only is the data a bit delayed in arriving, but many pages won't show the available data without a page refresh. So if you expect the data to be available and you don't see it, make sure to do a refresh of the page in your browser.

View routing information in the Table View

  1. Select Navigation > Anthos > Service Mesh.

    The Anthos Service Mesh page

  2. Click on the productpage service, then select Connected Services on the left.

    The Connected Services for product page is selected

  3. Select the OUTBOUND tab and note the two services called by the productpage pods.

    The Outbound tabbed page displaying the details and reviews services

  4. Click on the reviews service icon.

    The highlighted Reviews service icon.

  5. Note the service statistics, then select the Infrastructure link on the left-hand menu.

    The Reviews Infrastructure

    You can see that there are multiple pods, running different versions of the reviews logic, that receive traffic sent to the reviews service.

  6. Click on Traffic in the left-hand menu to see another view of traffic distribution.

    The traffic reviews page

You can see that there is relatively even distribution of traffic across the three backend pods running the different versions of the application logic.

View routing information in the Topology View

  1. Click on the Anthos Service Mesh logo in the upper left corner to return to the main dashboard page.

  2. Click on the TOPOLOGY link in the upper-right corner.

    Note: If you see an error message indicating that there is no data available to graph, or you see a chart that doesn't have all the traffic you expect, wait 1-2 minutes and try again.
  3. Click on the Expand option for all the services and rearrange the mesh graph so that you can easily view:

    • The productpage service going to productpage deployment
    • The productpage deployment going to reviews service
    • The reviews service going to three version of reviews

    The Anthos Service Mesh topology

  4. Click on the reviews service node and see relative qps for each backend version.

    The Reviews topology

Examine the current traffic management configuration

  1. Use kubectl to look for virtual services:

    kubectl get virtualservices

    Output:

    NAME GATEWAYS HOSTS AGE bookinfo [bookinfo-gateway] [*] 2h

    A VirtualService is defined and a Gateway is attached to it. This was established as part of the lab setup which applied: samples/bookinfo/networking/bookinfo-gateway.yaml.

  2. Use kubectl to view details about the VirtualService:

    kubectl describe virtualservices

    Output:

    Name: bookinfo Namespace: default Labels: <none> Annotations: API Version: networking.istio.io/v1alpha3 Kind: VirtualService Metadata: Creation Timestamp: 2020-06-10T14:20:03Z Generation: 1 Resource Version: 2041 Self Link: /apis/networking.istio.io/v1alpha3/namespaces/default/virtualservices/bookinfo UID: c792923b-3de0-41b3-82d9-87840efbe5b2 Spec: Gateways: bookinfo-gateway Hosts: * Http: Match: Uri: Exact: /productpage Uri: Prefix: /static Uri: Exact: /login Uri: Exact: /logout Uri: Prefix: /api/v1/products Route: Destination: Host: productpage Port: Number: 9080 Events: <none>
  3. Use kubectl to look for destination rules:

    kubectl get destinationrules

    Output:

    No resources found in default namespace.

    Currently, no destination rules exist.

Task 5. Apply default destination rules, for all available versions

In this task, you define all the available versions, called subsets, in destination rules.

Note: For the rest of this lab, it is recommended that you review each YAML config file carefully in GitHub before applying. Look closely at the kind and spec to understand the resources being created.

Then, you can check what was defined using kubectl get afterward with the -o yaml option.
  1. Apply a config that defines 4 DestinationRule resources, 1 for each service:

    kubectl apply -f https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/destination-rule-all.yaml

    Output:

    destinationrule.networking.istio.io/productpage created destinationrule.networking.istio.io/reviews created destinationrule.networking.istio.io/ratings created destinationrule.networking.istio.io/details created
  2. Check that 4 DestinationRule resources were defined:

    kubectl get destinationrules

    Output:

    NAME HOST AGE details details 1m productpage productpage 1m ratings ratings 1m reviews reviews 1m

Click Check my progress to verify the objective. Apply default destination rules, for all available versions

  1. Review the details of the destination rules:

    kubectl get destinationrules -o yaml

    Notice that subsets are defined within the spec of a DestinationRule.

  2. Wait for 1-2 minutes, then return to the Anthos Service Mesh dashboard.

  3. Look in both the table and topology views and confirm that the traffic continues to be evenly distributed across the three backend versions. You can click SHOW TIMELINE to adjust the period of time that is being charted, making it easier to zero in on the data you are interested in.

    The Reviews traffic with rules on the Alerts timeline

Task 6. Apply virtual services to route by default to only one version

In this task, you apply virtual services for each service that routes all traffic to v1 of the service workload.

  1. Apply a config that defines 4 VirtualService resources, 1 for each service:

    kubectl apply -f https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/virtual-service-all-v1.yaml

    Output:

    virtualservice.networking.istio.io/productpage created virtualservice.networking.istio.io/reviews created virtualservice.networking.istio.io/ratings created virtualservice.networking.istio.io/details created

    Because configuration propagation is eventually consistent, wait a few seconds for the virtual services to take effect.

  2. Check that 4 routes, VirtualService resources, were defined:

    kubectl get virtualservices

    Output:

    NAME GATEWAYS HOSTS bookinfo [bookinfo-gateway] [*] details [details] productpage [productpage] ratings [ratings] reviews [reviews]

    Click Check my progress to verify the objective. Apply virtual services to route by default to only one version

  3. In Cloud Shell, get the external IP address of the ingress gateway:

    echo $GATEWAY_URL
  4. Test the new routing configuration using the Bookinfo UI.

    • Open the Bookinfo site in your browser. The URL is http://[GATEWAY_URL]/productpage, where GATEWAY_URL is the External IP address of the ingress.

    • Refresh the page a few times to issue multiple requests.

    Notice that the Book Reviews part of the page displays with no rating stars, no matter how many times you refresh. This is because you configured Istio to route all traffic for the reviews service to the version reviews:v1 and this version of the service does not access the star ratings service.

  5. Wait for 1-2 minutes, then return to the Anthos Service Mesh dashboard by selecting Navigation > Anthos > Service Mesh > reviews > Infrastructure.

  6. Select SHOW TIMELINE and focus the chart on the last 5 minutes of traffic. You should see that the traffic goes from being evenly distributed to being routed to the version 1 workload 100% of the time.

    Anthos Service Mesh dashboard displaying all traffic going to version 1

    You can also see the new traffic distribution by looking at the Traffic tab or the topology view - though these both take a couple extra minutes before the data is shown.

Task 7. Route to a specific version of a service based on user identity

In this task, you change the route configuration so that all traffic from a specific user is routed to a specific service version. In this case, all traffic from user jason will be routed to the service reviews:v2, the version that includes the star ratings feature.

Note: Istio does not have any special, built-in understanding of user identity. This example is enabled by the fact that the productpage service adds a custom end-user header to all outbound HTTP requests to the reviews service.
  1. Review the configuration found at istio. This configuration defines 1 VirtualService resource.

  2. Apply the config that defines 1 VirtualService resource:

    kubectl apply -f https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml

    Output:

    virtualservice.networking.istio.io/reviews configured
  3. Confirm the rule is created:

    kubectl get virtualservice reviews

    Output:

    NAME GATEWAYS HOSTS AGE reviews [reviews] 35m
  4. Test the new routing configuration using the Bookinfo UI.

    • Browse again to /productpage of the Bookinfo application.
    • This time, click Sign in, and use User Name of jason with no password.

    Notice the UI shows stars from the rating service.

    You can sign out, and try signing in as other users. You will no longer see stars with reviews.

    To better visualize the effect of the new traffic routing, you can create a new background load of authenticated requests to the service.

  5. Start a new siege session, generating only 20% of the traffic of the first, but with all requests being authenticated as jason:

    curl -c cookies.txt -F "username=jason" -L -X \ POST http://$GATEWAY_URL/login cookie_info=$(grep -Eo "session.*" ./cookies.txt) cookie_name=$(echo $cookie_info | cut -d' ' -f1) cookie_value=$(echo $cookie_info | cut -d' ' -f2) siege -c 5 http://$GATEWAY_URL/productpage \ --header "Cookie: $cookie_name=$cookie_value"
  6. Wait for 1-2 minutes, refresh the page showing the Infrastructure telemetry, then check in the Anthos Dashboard and you should see that roughly 85% of requests over the last few minutes have gone to version one because they are unauthenticated. About 15% have gone to version two because they are made as jason.

    Anthos Service Mesh dashboard displaying 15% authenticated for version 2

  7. In Cloud Shell, cancel the siege session by typing Ctrl+c.

  8. Clean up from this task by removing the application virtual services:

    kubectl delete -f https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/virtual-service-all-v1.yaml

    Output:

    virtualservice.networking.istio.io "productpage" deleted virtualservice.networking.istio.io "reviews" deleted virtualservice.networking.istio.io "ratings" deleted virtualservice.networking.istio.io "details" deleted
  9. You can wait for 1-2 minutes, refresh the Anthos Service Mesh dashboard, and confirm that traffic is once again evenly balanced across versions.

    Anthos Service Mesh dashboard displaying even distribution

Task 8. Shift traffic gradually from one version of a microservice to another

In this task, you gradually migrate traffic from one version of a microservice to another. For example, you might use this approach to migrate traffic from an older version to a new version.

You will send 50% of traffic to reviews:v1 and 50% to reviews:v3. Then, you will complete the migration by sending 100% of traffic to reviews:v3.

In Anthos Service Mesh, you accomplish this goal by configuring a sequence of rules that route a percentage of traffic to one service or another.

  1. In Cloud Shell, route all traffic to the v1 version of each service:

    kubectl apply -f https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/virtual-service-all-v1.yaml

    Output:

    virtualservice.networking.istio.io/productpage created virtualservice.networking.istio.io/reviews created virtualservice.networking.istio.io/ratings created virtualservice.networking.istio.io/details created
  2. Browse again to /productpage of the Bookinfo application and confirm that you do not see stars with reviews. All traffic is being routed to the v1 backend.

  3. Wait 1 minute, then refresh the Anthos Service Mesh dashboard and confirm that all traffic has been routed to the v1 backend.

    Anthos Service Mesh dashboard displaying even distribution

  4. Transfer 50% of the traffic from reviews:v1 to reviews:v3:

    kubectl apply -f \ https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/virtual-service-reviews-50-v3.yaml

    Output:

    virtualservice.networking.istio.io/reviews configured
  5. Browse again to /productpage of the Bookinfo application.

    • Refresh the /productpage
    • Notice a roughly even distribution of reviews with no stars, from v1, and reviews with red stars, from v3, that accesses the ratings service.
  6. Wait 1 minute, then refresh the page and confirm in the Anthos Service Mesh dashboard that traffic to the reviews service is split 50/50 between v1 and v3.

    Anthos Service Mesh dashboard displaying 50-50 distribution between services

  7. Transfer the remaining 50% of traffic to reviews:v3.

    Assuming you decide that the reviews:v3 service is stable, route 100% of the traffic to reviews:v3 by applying this virtual service:

    kubectl apply -f https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/virtual-service-reviews-v3.yaml

    Output:

    virtualservice.networking.istio.io/reviews configured
  8. Test the new routing configuration using the Bookinfo UI.

    • Browse again to /productpage of the Bookinfo application.

    • Refresh the /productpage; you will always see book reviews with red colored star ratings for each review.

  9. Wait 1 minute, refresh the page, then confirm in the Anthos Service Mesh dashboard that all traffic to the reviews service is sent to v3.

    Anthos Service Mesh dashboard displaying 100% sent to Version 3

  10. Clean up from this task by removing the application virtual services:

kubectl delete -f https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/virtual-service-all-v1.yaml

Output:

virtualservice.networking.istio.io "productpage" deleted virtualservice.networking.istio.io "reviews" deleted virtualservice.networking.istio.io "ratings" deleted virtualservice.networking.istio.io "details" deleted

In this task, you migrated traffic from an old version to a new version of the reviews service using Anthos Service Mesh weighted routing feature. This is very different than doing version migration using the deployment features of container orchestration platforms, which use instance scaling to manage the traffic.

With Anthos Service Mesh, you can allow the two versions of the reviews service to scale up and down independently, without affecting the traffic distribution between them.

Congratulations!

In this lab, you learned about many different ways to manage and route traffic for different purposes. You also experimented with adjusting and viewing traffic shifting for yourself, including some layer 7, application layer, routing, that looks at request headers.

Finish your quest

This self-paced lab is part of the Anthos Service Mesh quest. A quest is a series of related labs that form a learning path. Completing this quest earns you a badge to recognize your achievement. You can make your badge or badges public and link to them in your online resume or social media account. Enroll in this quest to get immediate credit. Refer to the Google Cloud Skills Boost catalog for all available quests.

Next steps / Learn more

End your lab

When you have completed your lab, click End Lab. Qwiklabs removes the resources you have used and cleans the account for you.

You will be given an opportunity to rate the lab experience. Select the applicable number of stars, type a comment, and then click Submit.

The number of stars indicates the following:

  • 5 stars = Very satisfied
  • 4 stars = Satisfied
  • 3 stars = Neutral
  • 2 stars = Dissatisfied
  • 1 star = Very dissatisfied

You can close the dialog box if you don't want to provide feedback.

For feedback, suggestions, or corrections, please use the Support tab.

Google Cloud training and certification

...helps you make the most of Google Cloud technologies. Our classes include technical skills and best practices to help you get up to speed quickly and continue your learning journey. We offer fundamental to advanced level training, with on-demand, live, and virtual options to suit your busy schedule. Certifications help you validate and prove your skill and expertise in Google Cloud technologies.

Manual Last Updated September 25, 2022

Lab Last Tested July 28, 2022

Copyright 2022 Google LLC All rights reserved. Google and the Google logo are trademarks of Google LLC. All other company and product names may be trademarks of the respective companies with which they are associated.