
Before you begin
- Labs create a Google Cloud project and resources for a fixed time
- Labs have a time limit and no pause feature. If you end the lab, you'll have to restart from the beginning.
- On the top left of your screen, click Start lab to begin
In this lab, you learn to install Cloud Service Mesh (CSM) on Google Kubernetes Engine. Cloud Service Mesh is a managed service based on Istio, the leading open source service mesh.
A service mesh gives you a framework for connecting, securing, and managing microservices. It provides a networking layer on top of Kubernetes with features such as advanced load balancing capabilities, service-to-service authentication, and monitoring without requiring any changes in service code.
Cloud Service Mesh has a suite of additional features and tools that help you observe and manage secure, reliable services in a unified way. In this lab you also learn how to use some of these features:
Cloud Service Mesh is the easiest and richest way to implement an Istio-based service mesh on your GKE Enterprise clusters.
In this lab, you learn how to perform the following tasks:
For each lab, you get a new Google Cloud project and set of resources for a fixed time at no cost.
Sign in to Qwiklabs using an incognito window.
Note the lab's access time (for example, 1:15:00
), and make sure you can finish within that time.
There is no pause feature. You can restart if needed, but you have to start at the beginning.
When ready, click Start lab.
Note your lab credentials (Username and Password). You will use them to sign in to the Google Cloud Console.
Click Open Google Console.
Click Use another account and copy/paste credentials for this lab into the prompts.
If you use other credentials, you'll receive errors or incur charges.
Accept the terms and skip the recovery resource page.
After you complete the initial sign-in steps, the project dashboard appears.
Google 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.
Google Cloud Shell provides command-line access to your Google Cloud resources.
In Cloud console, on the top right toolbar, click the Open Cloud Shell button.
Click Continue.
It takes a few moments to provision and connect to the environment. When you are connected, you are already authenticated, and the project is set to your PROJECT_ID. For example:
gcloud is the command-line tool for Google Cloud. It comes pre-installed on Cloud Shell and supports tab-completion.
Output:
Example output:
Output:
Example output:
A Google Kubernetes Engine (GKE) cluster named gke has already been created and registered. You will install Cloud Service Mesh onto this cluster and override the standard configuration to enable the optional tracing components.
To set environment variables for use in scripts, in Cloud Shell, run the following commands:
Set the Name environment variable.
Set the Zone and Region environment variables.
Set the Project ID environment variable.
Set the Project Number environment variable.
Set the Fleet Project ID environment variable.
Set the IDNS environment variable.
Set the output directory.
Verify the environment variables are set correctly.
Output:
Configure kubectl
to manage your GKE cluster:
Review your kubectl configuration:
Output:
Output:
The master version in your installation might be different because you are using GKE's regular release channel to install the cluster.
gke
to the Fleet in the project.Wait until the controlPlaneManagement appears changes the state from PROVISIONING to REVISION_READY. This might take several minutes.
Output:
Output:
Congratulations!
You now have a GKE cluster with Cloud Service Mesh installed. Kubernetes Metrics are being recorded to Cloud Monitoring, logs are being recorded to Cloud Logging, and distributed trace information is being sent to Cloud Trace.
Online Boutique is a cloud-native microservices demo application. Online Boutique consists of a 10-tier microservices application. The application is a web-based ecommerce app where users can browse items, add them to the cart, and purchase them.
Google uses this application to demonstrate use of technologies like Kubernetes/GKE, Istio/ASM, Google Operations Suite, gRPC and OpenCensus. This application works on any Kubernetes cluster (such as a local one) and on Google Kubernetes Engine. It’s easy to deploy with little to no configuration.
For more information about the application, refer to the github repo.
Enable Istio sidecar injection:
Output:
To enable Google to manage your data plane so that the sidecar proxies will be automatically updated for you, annotate the namespace:
Output:
Deploy the application:
To be able to access the application from outside the cluster, install the ingress Gateway:
Install the required custom resource definitions
Configure the Gateway:
Return to Kubernetes click on Workloads and then under Networking click Gateways,Services & Ingress pages, and verify that the new deployments and services have been created on the gke cluster.
Take a couple of minutes to investigate the demo application using the console and UI.
View the deployment using Cloud Shell
Output:
View the services using Cloud Shell
Output:
Open a new tab and enter the IP address for the frontend-external
service.
Click through various pages to get a sense of the application.
When you install a GKE or an Anthos cluster, you can enable cluster logs and metrics to be collected and forwarded to Cloud Logging and Cloud Monitoring. That gives you visibility about the cluster, the nodes, the pods and even the containers in that cluster. However, GKE and Anthos don't monitor the communication between microservices.
With Cloud Service Mesh, because every request goes through an Envoy proxy, microservice telemetry information can be collected and inspected. Envoy proxy extensions then send that telemetry to Google Cloud, where you can inspect it. Use Cloud Trace dashboards to investigate requests and their latencies and obtain a breakdown from all services involved in a request.
In the Google Cloud Console, on the Navigation menu, click Trace.
A trace graph displays service requests made within the demo application.
Click on a dot that displays higher up in the graph (representing a higher overall) request time.
Review the Cloud Trace documentation for more details on understanding trace information.
In this task, you deploy a new version of a service that has an issue which causes high latency. In subsequent tasks, you use the observability tools to diagnose and resolve.
In Cloud Shell, clone the repository that has the configuration files you need for this part of the lab:
Create the new destination rule on the gke cluster:
Create the new product catalog on the gke cluster:
Create a traffic split on the gke cluster:
When you are not using Cloud Service Mesh, you can define SLOs with the Service Monitoring API. When you are using Cloud Service Mesh, as with the gke cluster, you can define and monitor SLOs via the Cloud Service Mesh dashboard.
In the Google Cloud Console, on the Navigation menu, click Kubernetes Engine to open the GKE Dashboard.
Notice that there is one cluster registered in the fleet.
On the side pannel, under Features click Service Mesh to go to the Cloud Service Mesh dashboard.
A summary of service performance, including SLO information, is displayed. You will define a new SLO for the product catalog service.
In the Services list, click productcatalogservice.
In the menu pane, click Health.
Click +CreateSLO.
In the Set your SLI slideout, for metric, select Latency.
Select Request-based as the method of evaluation.
Click Continue.
Set Latency Threshold to 1000, and click Continue.
Set Period type to Calendar.
Set Period length to Calendar day.
Set Performance goal to 99.5%.
The Preview graph shows how your goal is reflected against real historical data.
Click Continue.
Review Display name: 99.5% - Latency - Calendar day.
You can adjust this as needed.
The autogenerated JSON document is also displayed. You could use the APIs instead to automate the creation of SLOs in the future.
To create the SLO, click +CreateSLO.
Click on your SLO entry in the SLO list.
This displays an expanded view. Your SLO will probably show that you are already out of error budget. If not, wait 3-5 minutes and refresh the page. Eventually, you will exhaust your error budget, because too many of the requests to this service will hit the new backend, which has high latency.
In the menu pane, click Metrics.
Scroll down to the Latency section of the Metrics view and note that the service latency increased a few minutes earlier, around the time you deployed the canary version of the service.
From the Breakdown By dropdown, select Source service.
Which pods are showing high latency and causing the overall failure to hit your SLO?
To return to the Service Mesh page, in the menu pane, click Service Mesh.
One SLO is flagged as out of error budget, and a warning indicator is displayed next to the problem service in the Services listing.
In the Google Cloud Console, on the Navigation menu, click Trace > Trace explorer.
Click on a dot that charts at around 3000ms; it should represent one of the requests to the product catalog service.
Note that all the time seems to be spent within the catalog service itself. Although calls are made to other services, they all appear to return very quickly, and something within the product catalog service is taking a long time.
In Cloud Shell, back out the destination rule canary release:
In Cloud Shell, back out the product catalog canary release:
In Cloud Shell, back out the traffic split canary release:
In the Google Cloud Console, on the Navigation menu, click Anthos > Service Mesh.
Click on productcatalogservice, and then in the menu pane, click Health.
Note the current compliance percentage.
Click Metrics.
On the latency chart, all the latency series show a dip that corresponds to when you rolled back the bad version of the workload.
Return to the Health page.
Compare the current compliance metric with the one you saw earlier. It should be higher now, reflecting the fact that you are no longer seeing high-latency requests.
On the Navigation menu, click Kuberenetes Engine > Service Mesh.
View the Topology on the right side.
A chart representing your service mesh is displayed.
If you don't see a full topology chart like this, it's possible that not all the topology data has been collected. It can take 10+ minutes for this data to be reflected in the chart. You can proceed to the next section and return later to see the chart.
Click on the frontend workload node and note the services called by that workload.
Take a couple of minutes to explore further and better understand the architecture of the application. You can rearrange nodes, drill down into workloads to see constituent deployments and pods, change time spans, etc.
Congratulations! You've used Google Cloud's operations suite tooling to evaluate, troubleshoot, and improve service performance on your GKE Enterprise cluster.
In this lab, you learned about logging, monitoring, and tracing using Google Cloud's operations suite.
When you have completed your lab, click End Lab. Google Cloud Skills Boost removes the resources you’ve 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:
You can close the dialog box if you don't want to provide feedback.
For feedback, suggestions, or corrections, please use the Support tab.
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.
This content is not currently available
We will notify you via email when it becomes available
Great!
We will contact you via email if it becomes available
One lab at a time
Confirm to end all existing labs and start this one