Overview

This lab shows you the benefits of using Anthos Service Mesh to manage a microservices-based application deployed across multiple GKE clusters. Microservices are the centric component of a modern application. Organizations, teams, and products are organized to build resilient, secure, scalable services that solve customer needs.

Every service needs four qualities: resiliency, scale, security, and ease of management. Resiliency is important because services need to adapt to infrastructure and machine or human error. Scale allows services to run across clusters, regions, and zones to fulfill customer requests in a timely fashion. Security means encrypting all traffic between services and being able to implement and enforce policies to and from every service. Ease of management involves being able to observe metrics in a service, deliver traffic to the right service, and reliably roll out new versions.

To provide resiliency, you must be able to recover from infrastructure failure such as losing a cluster where a service might be running. To do this, you can run a service in multiple clusters with the so-called distributed services. A distributed service is a set of Kubernetes services that acts as a single logical service. Distributed services are more resilient than Kubernetes services because they run on multiple Kubernetes clusters in the same namespace.

A distributed service provides multi-regional availability and remains up even if one or more GKE clusters are down, but only if the healthy clusters can serve the desired load. Running distributed services makes cluster lifecycle management easier because you can bring clusters down for maintenance or upgrades while other clusters service traffic. In order to create a distributed service, service mesh functionality provided by Anthos Service Mesh is used to link services running on multiple clusters together to act as a single logical service.

Introduction

Two GKE clusters called gke-region1 and gke-region2 have been provisioned in and . Anthos Service Mesh has been configured across these clusters to provide cross-cluster service discoverability and secure routing so that a microservice pod running on gke-region2 can seamlessly communicate with a pod on gke-region1. Additionally, the Bank of Anthos application has been deployed across these two clusters as shown in the following diagram.

Objectives

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

• Navigate Google Cloud and explore Anthos clusters from the Google Cloud Console.
• Perform east-west cross-cluster traffic routing.
• Observe distributed services, view metrics, set up SLOs, and investigate network topology.
• Use the Anthos Service Mesh Dashboards to verify security and encryption configuration.

Setup and requirements

In this task, you perform initialization steps for your lab.

For each lab, you get a new Google Cloud project and set of resources for a fixed time at no cost.

1. Sign in to Google Skills using an incognito window.

2. 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.

3. When ready, click Start lab.

4. Note your lab credentials (Username and Password). You will use them to sign in to the Google Cloud Console.

5. Click Open Google Console.

6. 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.

7. Accept the terms and skip the recovery resource page.

Google Cloud Platform Console

After you complete the initial sign-in steps, the project dashboard appears.

• Click Select a project, select your GCP Project ID, and click Open to select your project.

Activate Google Cloud Shell

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.

1. In Cloud console, on the top right toolbar, click the Open Cloud Shell button.

   

2. 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.

• You can list the active account name with this command:

gcloud auth list

Output:

Credentialed accounts: - @.com (active)

Example output:

Credentialed accounts: - google1623327_student@qwiklabs.net

• You can list the project ID with this command:

gcloud config list project

Output:

[core] project =

Example output:

[core] project = qwiklabs-gcp-44776a13dea667a6 Note: Full documentation of gcloud is available in the gcloud CLI overview guide .

Task 1. Explore the app deployed in Anthos clusters

1. On the Navigation menu, click Kubernetes Engine > Clusters, and verify that two Anthos clusters are registered.

2. In the navigation pane, click Workloads, and verify that every microservice is deployed on both GKE clusters except from the two databases, accounts-db and ledger-db, which are only running in gke-region1.

3. In the navigation pane, click Gateways, Services & Ingress, and verify that every microservice is deployed on both GKE clusters, including the two databases, accounts-db and ledger-db, which are needed for traffic routing.
   istio-ingressgateway is also in the list and should be available in both clusters.

This component provides a public IP address, creates a Cloud Load Balancer, and enables access to the application from outside the cluster.

4. To open websites, click on the IP addresses for each of the instances of istio-ingressgateway.
   This will open the sign-in page for each website.

5. Click Sign In to sign in with an existing test user.

6. Deposit funds or send a payment, which will create a new transaction on the shared database.

7. Refresh the pages and confirm that both Transaction History and Current Balance are the same across clusters.

Note: Notice that even though all services are replicated across clusters, they are both using the same database because the ledger-db is only deployed on one cluster. Anthos Service Mesh routes requests to the available pods regardless of the cluster you are ingressing from. This is called east-west routing.

Task 2. Force cross-cluster traffic routing

In this task, you delete all frontend pods in one cluster to force the traffic to be routed to the other cluster from the ingress gateway. That simulates a scenario where an application might be unavailable due to an upgrade or a spike in traffic.

1. In the Google Cloud Console, return to Kubernetes Engine > Workloads.

2. To open the dashboard, click on the frontend deployment in the gke-region2 cluster.

3. On the Actions dropdown, select Scale > Edit replicas.

4. Enter 0 replicas, and click Scale.

5. Return to the istio-ingressgateways IP addresses that you opened before.
   The application should continue to work.

Congratulations! You successfully tested your application resiliency. You removed all pods from one cluster, and the application continued to work without experiencing any downtime.

6. Return to your frontend deployment and scale it back to 1 replica.

Task 3. Observe distributed services

1. To return to the home page of the Anthos Service Mesh dashboard, on the Navigation menu, click Anthos > Service Mesh.

2. Under Topology View. A chart that represents your service mesh is displayed.

3. 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, investigate queries per second (QPS), etc.

4. Under List View. A list of distributed services in your mesh across your two clusters is displayed.

5. Click on the frontend service. This displays an overview of the inbound and outbound services it is communicating with. Also, you can see the golden signals: latency, traffic, errors, and saturation.

6. Click Metrics. This displays a default dashboard that is automatically created for each service on a mesh. It provides breakdown metrics on requests per second, error rates, latencies, and more.

7. Click Health. Here you can create Service Level Objectives (SLOs) to make sure that your metrics are always within certain parameters, so that you can monitor and alert when certain thresholds are surpassed.

8. Click Create SLO.

9. Select Latency as the metric, and click Continue.

10. Set the latency threshold to 350 ms, and click Continue.

11. Set the Period length to Calendar day, and set the Goal to 99.5%.

12. Click Continue.

13. Review the details and check the JSON object in case you might want to automate this operation in the future, and then click Create SLO.

Notice that the created SLO is already out-of-budget. You could also set up an alert so that when this happens you can investigate any possible problems. This helps you understand and tune your services to provide a better user experience.

Congratulations!You learned to view the topology of your service mesh, viewed service metrics, and set up SLOs.

Task 4. Verify service mesh security

• From the frontend service ASM Dashboard, open the Security tab. The following diagram is displayed:

Notice that all service to service communication has a green lock. That's because all the communication is encrypted over mutual TLS. Also, notice that an unknown source has an open red lock. That means that an unauthenticated agent is accessing the frontend service that is communicating over plain text. This unauthenticated agent is the browser.

Note: Anthos Service Mesh automatically enables mutual TLS (mTLS) across services, so that all communications are authenticated and encrypted.

The table at the bottom of the page also shows the HTTP operations that clients are allowed to perform on the frontend service. In this case, the ingressgateway and the loadgenerator are allowed to perform HTTP GET and HTTP Post requests, but unauthenticated actors are only able to perform HTTP GET requests.

Note: Anthos Service Mesh provides L7 networking policies that can be used in combination with Kubernetes L4 networking polices to provide in-depth security.

Congratulations!

In this lab, you explored Anthos clusters in the Google Cloud Console and learned about the benefits of using Anthos Service Mesh to create distributed services. You observed distributed services, viewed metrics, set up SLOs, investigated network topology, and verified security and encryption configuration using the Anthos Service Mesh Dashboards.

End your lab

When you have completed your lab, click End Lab. Google Skills 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:

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

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.