The Anthos Sample Deployment (deployed on Google Cloud) is a click-to-deploy solution from the Google Cloud Marketplace. This solution deploys an Anthos hands-on environment with clusters, service mesh, and an application with multiple microservices. These instructions guide you through a tutorial so that you can explore and try Anthos deployed on Google Cloud.

Anthos usage for the purposes of the Anthos Sample Deployment is free for a limited time, after which you will be charged the fees for Anthos on Google Cloud listed at Google Cloud Platform SKUs. Google will provide you with advance notice before you are charged for such Anthos usage. You are responsible for other costs, such as Compute Engine, Logging, and Monitoring.

Your journey

You are the platform lead at the Online Boutique, an online retailer of trendy lifestyle products. What started as a small e-commerce website running on two servers almost ten years ago has grown into a successful national business employing thousands of staff and is now looking to expand globally.

Throughout this period, you and your team have found yourself spending more time and money on maintaining infrastructure than on creating new business value. You have decades of cumulative experience invested in your existing stack; however, you know it's not the right technology to meet the scale of global deployment that your company needs as it expands.

Your team began using Kubernetes a year ago, and since then has been running a local cluster with a small number of services. Your deployments still involve a number of manual stages, however, and this process has unfortunately resulted in occasional outages due to differences between developer and production environments.

Your development team wants the confidence to be able to deploy more frequently without worrying that their changes may cause problems elsewhere in the application.

You've adopted Anthos to modernize your application and help migrate to the cloud.

This tutorial

You will deploy the Anthos Sample Deployment environment in your project and then walk through multiple key capabilities to explore the Anthos platform.

What's deployed?

After deploying the Anthos Sample Deployment on Google Cloud, your project is provisioned with the following:

As shown in the preceding diagram, the jump server (jump vm) is configured with the following:

In this tutorial, you're introduced to some of the key features of Anthos through the following tasks:

Identify a Google Cloud project

You can create a new Google Cloud project or use an existing project as long as it meets certain requirements. We recommend creating a new project so that it is easier to clean up the deployment later.

  1. In the Google Cloud Console, click the project selector:

  1. In the dialog that opens, either select an existing project or select from the appropriate organization, and then click New Project:

  1. If this is a new project, complete the New Project form, and then click Create.

Congratulations!
This is all you need to do to get ready to deploy your Anthos Sample Deployment environment!

You can launch the Anthos Sample Deployment through the Google Cloud Marketplace.

  1. Open the Anthos Sample Deployment on Google Cloud in the Google Cloud Marketplace. You cannot navigate to this entry through the Google Cloud Marketplace in the Cloud Console.

  1. Select and confirm the Google Cloud project to use. This should be the project that you selected or created in the Getting Started section.
  2. Click LAUNCH. It can take several minutes to progress to the deployment configuration screen while the solution enables a few APIs.
  3. Now you see the deployment configuration screen.

  1. Select an existing Service Account or create a new one. If you create a new one, you can use these values to fill in the following fields:

    Service account name: Anthos Sample Service Account
    Service account ID: anthos-sample-service-account
    Service account description: For Anthos Sample Deployment
  1. Click Deploy. Deploying the trial can take up to 15 minutes, so don't be concerned if you have to wait for a while.

    While the deployment is progressing, the Cloud Console transitions to the Deployment Manager view.

    If you want, you can click the Overview folder to see the Deployment properties, or click individual deployment resources, such as services-container or prod, to review Resource properties.

  1. After the sample is deployed, you can review the full deployment. You should see a list of all enabled resources, including two GKE clusters (pre-prod and prod) and one Compute Engine instance (the jump server).

Congratulations!
Your environment is provisioned. Now you're ready to explore Anthos GKE resources.

The Google Kubernetes Engine page in the Cloud Console is your single location for observing all clusters known to your project. You can view cluster, workload, and service details.

Review clusters

  1. In the Cloud Console, on the Navigation menu (), click Kubernetes Engine > Clusters. Look for anthos-sample-cluster1 and anthos-sample-cluster2.

  1. Click the anthos-sample-cluster1 cluster for details, including your cluster's Master version, Endpoint, Current total size, and Master zone.

  1. Click the Nodes tab, near the top.

  1. Review the worker machines in your cluster.

  1. Click one of the node machines to review the Node details Summary.
  2. Review the Kubernetes Pods running on the node, as well as a Resource summary of the node (CPU, memory, storage).

Review workloads across all clusters

The Cloud Console has a Workloads view that shows an aggregated view of the workloads (Pods) running on all your Anthos GKE clusters.

  1. In the Cloud Console, on the Navigation menu, click Kubernetes Engine > Workloads.
  2. Observe that workloads from both clusters and multiple namespaces are shown. For example, workloads in the onlineboutique namespace are running in both anthos-sample-cluster1 and anthos-sample-cluster2 clusters.

Review Services & Ingress

  1. In the Cloud Console, on the Navigation menu, click Kubernetes Engine > Services & Ingress.
  2. Add a filter on Name: ingressgateway
  3. Review the Istio ingress gateway service for the anthos-sample-cluster1 cluster. An ingress gateway manages inbound traffic for your application service mesh. We'll see this in action when we use the telemetry features.

Inspect the application web frontend

  1. In the Service Details view for istio-ingressgateway in prod, click the external endpoint using port 80.

  1. Examine the application's web frontend.

  1. You can select products, add to your cart, and place orders to demo the application.

Congratulations!
You explored your clusters and workloads running on Anthos GKE! You also inspected your application's web frontend. Next, you will look through your application services by using Anthos Service Mesh.

Separate instances of the sample application were provisioned in anthos-sample-cluster1 and anthos-sample-cluster2 clusters during the deployment task. The application includes a loadgenerator utility that simulates a small amount of load to each cluster.

In this task, you use the telemetry features of Anthos Service Mesh to look at this application's services and traffic.

Examine the Services Table View

  1. In the Cloud Console, navigate to Anthos Service Mesh on the Cloud Console. The Anthos Service Mesh Table View is the default view.


  1. Under Namespace, select onlineboutique.


  1. View the Services table.

Each row in the table is one service. The frontend service renders your website's web UI. The cartservice service tracks a user's cart of items for purchase.

You can see metrics, such as Error rate, for each service. These metrics are collected out-of-the-box for services deployed on Anthos. You do not need to write any application code to see these statistics.

Visualize the Services Topology

  1. Click the Topology button at the top-right to switch from the Table View to the workload/service graph visualization.

  1. Notice that the Legend explains how to distinguish Workloads from Services.

  1. Now take a look at the topology graph. Anthos Service Mesh automatically observes which services are communicating with each other to show service-to-service connections details.

  1. Move your mouse to hover over and see additional details including outbound QPS from each service.
  2. To improve your view, use Zoom and drag workload nodes with your mouse.

Inspect details for a service in the Table View

  1. Click Table View to return to the table of services.
  2. Click the shippingservice service for an overview of service metrics.
  3. Review the telemetry available for the service.

  1. In the left navigation, change the view to Connected Services.

Here you can see both the inbound and outbound connections for the service.

An unlocked lock icon () indicates that some traffic has been observed on this port that is not using mutual TLS (mTLS). Different colors are used to indicate whether the traffic has a mix of plaintext and mTLS (orange) or just plaintext (red).

Congratulations!
You just used Anthos Service Mesh to observe your application services running in GKE. Next, you'll learn how to use SLOs to help monitor your services, and how to apply policy updates to keep all your clusters secured.

According to Google's Site Reliability Engineering (SRE) book:

It's impossible to manage a service correctly, let alone well, without understanding which behaviors really matter for that service and how to measure and evaluate those behaviors. To this end, we would like to define and deliver a given level of service to our users, whether they use an internal API or a public product.

Google SRE teams use Service Level Indicators (SLIs), Service Level Objectives (SLOs), and Service Level Agreements (SLAs) to structure and guide the metrics that inform their work. Anthos Service Mesh makes it easy to define SLOs for your own services by using alerts to notify you when a service isn't meeting its specified level of service.

Review SLO and alerts indicators

The first step in this journey is gathering the SLIs and defining your SLOs. Anthos Service Mesh makes this a simple, straightforward task.

  1. Navigate to Anthos Service Mesh on the Cloud Console to return to the default Table View for Anthos Service Mesh.
  2. Under Namespace, select onlineboutique.


  1. Inspect the top part of this view, which shows current status of services along with indicators for alerts and SLOs, including the count of services without SLOs: No SLOs set.

  1. For shoppingcartservice, notice the adjacent indicator. If you hover over that indicator, you're informed that no SLO is set for the service.


  1. For shoppingcartservice, note the value in ms for 99% latency. The meaning of this value is that one out of every one hundred requests experiences a delay of this value. We reference this value later.

Create an SLO

In this step, you create an SLO against a latency SLI in one of your services.

  1. Click shoppingcartservice for the service Overview.
  2. Click Create an SLO.
  3. For SLI Type, select Latency.
  4. Set Latency Threshold to an arbitrarily low value, such as 50 ms (something significantly lower than the 99% latency value observed earlier).
  5. Set your SLO Goal > Compliance target to 90%.
  6. Set your Compliance Period > Period Type to Rolling, and Period Length to 1 Day.
  7. A panel, How your SLO would have performed, appears.

  1. Your new SLO has a suggested name populated.
  2. Click Submit. You've created an SLO, indicated in the Health panel for shoppingcartservice.

From this view, you can expand the SLO to investigate its status, edit it, or delete it, by clicking the drop-down arrow.

Recheck SLO and alerts indicators

  1. Click the back-arrow to return to the Services Table View.


  1. Add a filter on Namespace: onlineboutique
  2. Inspect the top part of this view and notice that the service count for No SLOs set has been reduced by one.

  1. You can see that SLOs out of error budget is no longer 0.

  1. For shoppingcartservice, notice that the adjacent indicator has changed. If you hover over that indicator, you're informed to investigate service reliability.

  1. To review SLO and compliance details, click the alert icon, and then open the panel by clicking the drop-down arrow (for more details).

If the service doesn't appear to be out of the error budget, go back and edit the SLO again; try decreasing the Latency Threshold to a smaller amount and wait a moment or two.

If you have time, you can click Create Alerting Policy. This prompts you to set up Monitoring alerts for your project if you haven't used it before. If you want to try setting up alerting for your new SLO, see Creating an alerting policy for an SLO.

Congratulations!
You just used Anthos Service Mesh to create an SLO and recognize service reliability issues. In the following section, you'll secure service-to-service traffic in your application.

In anticipation of global expansion, your CIO has mandated that all user data must be encrypted in transit to safeguard sensitive information to be in compliance with regional data privacy and encryption laws.

Earlier, when we inspected connected services for the shippingservice service, we noted an unlocked lock icon () indicating that some traffic had been observed on a request port that was not using mutual TLS (mTLS).

Rather than make changes at the source code level and rebuild and redeploy to address this situation, we can apply the new encryption policy through configuration.

With Anthos, you're only a few steps away from being in compliance; you just need to do the following:

  1. Adjust the policy configuration in your git repository to enforce that services use encrypted communications through mTLS.
  2. Rely on Anthos Config Management to automatically pick up the policy change from the repository and adjust the Anthos Service Mesh policy.
  3. Verify that the policy change occurred across all clusters that are configured to sync with the repository.

Open an SSH session on the jump server

Open a secure shell on anthos-sample-deployment-jump-server:

  1. In Deployment Manager, navigate to your Anthos Sample Deployment.
  2. Select your deployment.
  3. Click SSH to open a session on your jump server.
  4. This copies keys and drops you into a session on the jump server.
  5. Switch user to anthos-user:
sudo -u anthos-user -s

Confirm that Anthos Config Management is configured to sync with the repository

Step 1: Change directory to the provisioned anthos-sample config repository:

cd ~/anthos-sample/anthos-config-management/config-repo

Step 2: Run nomos status:

The nomos command is an optional command-line tool to interact with the Config Management Operator. The nomos status command will verify that Anthos Config Management is properly installed and configured on all our clusters.

nomos status

Output:

Connecting to clusters...
Current   Context                  Status       Last Synced Token   Sync Branch
-------   -------                  ------       -----------------   -----------
*         anthos-sample-cluster1   SYNCED       abef0b01            master   
          anthos-sample-cluster2   SYNCED       abef0b01            master

The output confirms that Anthos Config Management is configured to sync your clusters to the master branch of your config repository. The asterisk in the first column indicates that the current context is set to anthos-sample-cluster1.

Step 3: If necessary, switch the current context to anthos-sample-cluster1:

kubectl config use-context anthos-sample-cluster1 

Output:

Switched to context "anthos-sample-cluster1".

Step 4: Ensure that you're on the master branch:

git checkout master

Output:

Already on 'master'
Your branch is up-to-date with 'origin/master'.

Step 5: Verify your upstream configuration repository:

git remote -v

Output:

origin  https://source.developers.google.com/p/sample-deployment-for-anthos/r/config-repo (fetch)
origin  https://source.developers.google.com/p/sample-deployment-for-anthos/r/config-repo (push)

You are now ready to commit policy changes to your repository. When you push these commits to your upstream repository (origin), Anthos Config Management ensures that these changes are synchronized across the clusters that you have configured it to manage.

Update configuration policy to encrypt all service traffic

Step 1: Configuration for Anthos Service Mesh is specified by using YAML files. First let's look at cluster/mesh-policy.yaml, which is a mesh-level authentication policy that specifies the types of traffic that services in your mesh accept. Notice that the MeshPolicy mTLS mode is PERMISSIVE, which allows a service to take both plaintext HTTP and mutual TLS traffic.

cat cluster/mesh-policy.yaml

Output:

apiVersion: "authentication.istio.io/v1alpha1"
kind: "MeshPolicy"
metadata:
  name: "default"
spec:
  peers:
  - mtls:
      mode: PERMISSIVE

Step 2: Modify cluster/mesh-policy.yaml to allow only encrypted communication between services by removing PERMISSIVE mode:

cat <<EOF> cluster/mesh-policy.yaml
apiVersion: "authentication.istio.io/v1alpha1"
kind: "MeshPolicy"
metadata:
  name: "default"
spec:
  peers:
  - mtls: {}
EOF

Step 3: Now look at the Destination Rule in namespaces/istio-system/destination-rule.yaml. This specifies rules for sending traffic to the specified destinations, including whether the traffic is encrypted. Notice that TLSmode is DISABLE, meaning that traffic is sent in plaintext.

cat namespaces/istio-system/destination-rule.yaml

Output:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  annotations:
    meshsecurityinsights.googleapis.com/generated: "1561996419000000000"
  name: default
  namespace: istio-system
spec:
  host: '*.local'
  trafficPolicy:
    tls:
      mode: DISABLE

Step 4: Modify namespaces/istio-system/destination-rule.yaml to have Istio set a traffic policy that enables TLS for all matching hosts in the cluster by using TLSmode ISTIO_MUTUAL:

cat <<EOF> namespaces/istio-system/destination-rule.yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  annotations:
    meshsecurityinsights.googleapis.com/generated: "1561996419000000000"
  name: default
  namespace: istio-system
spec:
  host: '*.local'
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
EOF

Step 5: You are almost ready to push your configuration changes. Before you do, run nomos vet to ensure that your configuration is valid.

nomos vet

No output indicates that there were no validation errors.

Step 6: As soon as you push your changes, Anthos Config Management picks up and applies the changes quickly. Verify that the destinationrule gets updated and that the current state reflects that mTLS is disabled for the cluster.

kubectl get destinationrule default -n istio-system -o yaml

Output:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
...
spec:
  host: '*.local'
  trafficPolicy:
    tls:
      mode: DISABLE

Step 7: Now commit and push these changes to the upstream repository.

git commit -am "enable mtls"
git push origin master

Verify that updated confzziguration was applied

After pushing the updates, you can check to see if Anthos Config Management has picked up the configuration changes and applied them.

watch -n 1 kubectl get destinationrule default -n istio-system -o yaml

You may have to wait a few seconds, but at some point you should see DISABLE change to ISTIO_MUTUAL in the response.

Output:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
...
spec:
  host: '*.local'
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

You could also use watch to verify that the changes are applied to both clusters:

watch -n 1 'printf "anthos-sample-cluster1: " && kubectl get destinationrule default -n istio-system --context anthos-sample-cluster1 -o yaml | grep "mode: " && printf "anthos-sample-cluster2: " && kubectl get destinationrule default -n istio-system --context anthos-sample-cluster2 -o yaml | grep "mode: "'
 

You may have to wait a few seconds, but at some point you should see DISABLE change to ISTIO_MUTUAL in the response.

Output:

anthos-sample-cluster1: mode: ISTIO_MUTUAL
anthos-sample-cluster2: mode: ISTIO_MUTUAL

Press <Ctrl>+c to exit the watch command. You can now exit your session, or just close your terminal window.

In addition, you can see the changes reflected in the Cloud Console under Connected Services. The lock icon appears orange because we're looking by default at the last hour with a mix of mTLS and plaintext.

Great job!
You just used Anthos Config Management's git repository to update your Istio Policy configuration. The service traffic in your cluster is now encrypted end-to-end.

When you're finished experimenting with your Anthos Sample Deployment, you should clean up your resources to avoid incurring additional charges.

Option 1. Shut down your project

If you followed the recommendation to create a new project for this tutorial, this option cleans up all resources for you:

  1. In the Cloud Console, on the Navigation menu (), click Home.
  2. In Project info, click Go to project settings.
  3. Click Shut Down.
  4. Confirm by entering your Project ID.
  5. Click Shut Down one final time.

Option 2. Delete the deployment

This approach relies on allowing Deployment Manager to undo what it created. Even if the deployment had errors, you can use this approach to undo it.

  1. In the Cloud Console, on the Navigation menu, click Deployment Manager.
  2. Select your deployment, and then click Delete.
  3. Confirm by clicking Delete again.

  1. Even if the deployment had errors, you can still select and delete it.

  1. If clicking Delete doesn't work, then as a last resort you can try Delete but preserve resources. If Deployment Manager is unable to delete any resources, you need to note these resources and attempt to delete them manually later.
  2. Wait for Deployment Manager to finish the deletion.
  3. (Temporary step) On the Navigation menu, click Network services > Load balancing, and then delete the forwarding rules created by the anthos-sample-cluster1 and anthos-sample-cluster2 clusters.
  4. (Optional) Go to https://source.cloud.google.com/<project_id>. Delete the repository whose name includes config-repo if there is one.
  5. (Optional) Delete the Service Account that you created during the deployment and all of its IAM roles.

Option 3. Perform a manual cleanup

This approach relies on manually deleting the resources from the Cloud Console.

  1. In the Cloud Console, on the Navigation menu, click Kubernetes Engine.
  2. Select both clusters and click Delete, and then click Delete again to confirm.
  3. In the Cloud Console, on the Navigation menu, click Compute Engine.
  4. Select the jump server and click Delete, and then click Delete again to confirm.
  5. Follow Steps 7 and 8 of Option 2.

If you plan to redeploy after manual cleanup, verify that all requirements are met as described in Getting Started.

When you finish working on this tutorial, please complete our survey. We're interested in hearing about any issues you might have at any point in the tutorial. Thanks for using the survey to submit your feedback.

Thank you!

The Anthos Team