LISA SHEN: Hi, my name is Lisa Shen,
and I am a product manager in Google Cloud.
In this video, we'll take a look at how
to set up Anthos Service Mesh for improved application
security and visibility.
We'll install the ASM on an Anthos GKE cluster on AWS.
The similar process also works for GKE clusters on GCP
and Anthos-attached clusters such as an EKS cluster on AWS.
Anthos provides a unified platform
for managing Kubernetes clusters across different clouds, as
well as on-prem.
These clusters can be running inside
of virtual machines and instances,
as well as on bare metal.
Anthos is a 100% software product
that extends Google Cloud Services and engineering best
practices to your environments so you
can modernize applications faster and establish
operational consistency across them.
Architecting your applications as microservices
provides many benefits.
However, your workloads can get complex and fragmented
as they scale.
Anthos Service Mesh is Google's implementation
of the powerful Istio open source project,
allowing you to manage, observe, and secure
your services without having to change your application code.
ASM unburdens your operations and the development team
by simplifying service delivery across the board,
from traffic management and mesh telemetry
to securing communications between services.
ASM is a managed platform that uses Istio APIs to provide
service health tools, complex traffic controls, and a managed
security authority.
It is fully supported by Google with an out-of-the-box
telemetry dashboard and Anthos fleet integration.
Customers adopt a service mesh for a few reasons.
With ASM, you can build secure services in your application.
Another reason is the reliability
provided by ASM, as it gives you uniform observability.
ASM increases application visibility,
and what gets measured gets improved.
An advanced application layer, networking,
and easy traffic management is another benefit
provided by ASM.
We'll explore some of these benefits in this video demo.
Now let's navigate to the GCP Console.
As you can see, I have two clusters created already
in my project.
One is an Anthos cluster on AWS, and another one
is the GKE cluster.
In this demo, we're going to take
a look at how to install the ASM on the Anthos cluster on AWS.
There are some prerequisites that you
need to be aware of before the ASM installation.
The user cluster that you install Anthos Service
Mesh needs to have at least a total of four vCPUs,
15 gigabytes of memory, and four nodes.
As you can see, our Anthos AWS cluster meets the requirements.
Let's get to the terminal.
First, let's make sure we're in the context of the Anthos
cluster on AWS.
And now let's run the kubectl get namespace command
on the AWS cluster to verify that there is no ASM installed
at this point.
We also need to make sure that the cluster admin role is
grounded on the cluster.
Let's check on that.
OK, so next, let's use the curl command
to download the latest ASM module.
Now let's make the script executable.
Now let's use the ASM CLI to install the ASM
in cluster control plane.
Note that the --enable_all flag allows the script
to enable the required Google APIs,
set identity and access management permissions,
and to make the required updates to the cluster.
The process is going to take about a minute or two.
So while we're waiting for the ASM module installation,
let's take a peek and look at the overall installation
process in the slide.
Anthos Service Mesh gives you the option
to deploy and manage gateways as part of your service mesh.
A gateway describes a load balancer operating
at the edge of the mesh, receiving
incoming or outgoing HTTP TCP connections.
Gateways are one-way proxies that provide you
with fine-grained control over traffic
entering and leaving the mesh.
We will install Istio Ingress Gateway right
after this ASM CLI install.
Anthos Service Mesh uses sidecar proxies
to enhance network security, reliability, and observability.
With ASM, these functions are abstracted away
from the application's primary container
and implemented in a common out-of-process proxy delivered
as a separate container in the same pod.
As a result, the developers can focus on the business logic.
The separation results in a lightweight and portable
application.
So following the ingress gateway installation,
we'll enable automatic sidecar proxy injection
so that Anthos Service Mesh can monitor and secure traffic.
Now let's get back to the terminal.
It seems the CLI install is done successfully.
To verify that ASM is installed correctly,
we'll use kubectl get namespace command
to verify the ASM system and Istio system are installed.
We're also going to see the pods running in the Istio system.
The next step is to install the ingress gateway,
as we have talked about in the slide earlier.
Since gateways are user workloads, and as a best
practice, they shouldn't be deployed in the control plane
namespace.
So let's create a namespace for the ingress gateway.
Now let's enable auto-injection on the gateway
by applying a revision label on the gateway namespace.
The revision label is used by the sidecar injector web hook
to associate injected proxies with a particular control plane
revision.
Next, let's go to the directory that we
have specified in the ASM CLI module installed earlier.
Some sample codes are installed in that directory
during the ASM CLI install process.
We're going to deploy the example ingress gateway
configuration file in the samples directory.
To complete setting up Anthos Service Mesh,
we need to enable automatic sidecar injection.
We label the namespaces with the default injection
labels if the default tag is set up
or a revision label that was set on istio.d.
Note that any existing pods in the default namespace
must be restarted before sidecar is to be injected.
We don't have to do that since there's no applications running
yet in our default namespace.
Now that we have ASM installed and the sidecar proxy
configured, we can go ahead and deploy our application
to the default namespace and start observing the application
behavior.
We're going to use the Bookinfo application that
comes with the ASM CLI install in this demo.
And this is the Istio website related to the sample Bookinfo
application.
The Bookinfo application is broken into four
separate microservices.
The end-to-end architecture of the application is shown here.
There are three versions of the Reviews microservice,
for example.
Version v1 doesn't call the Rating service.
Version v2 calls the Rating service
and displays each rating as 1 to 5 black stars.
And version 3 calls the Ratings service
and displays each rating as 1 to 5 red stars.
Let's take a quick look at the sample codes
that are also available in the Istio public repo.
For example, the bookinfo.yaml file sets up the four services
and deployments.
For the Review service, there is one container
designated for each version of the service in the application.
Let's also take a quick look at the Bookinfo gateway.yaml file,
which describes the configuration
for the application ingress gateway.
The gateway exposes the services to users outside the service
mesh and allows Istio features, such as monitoring and route
rules, to be applied to the traffic entering the cluster.
Now let's deploy the Bookinfo application
to our Anthos cluster on AWS via the kubectl command.
We're going to use kubectl apply command
to apply the bookinfo.yaml file.
As you can see here, the four microservices
are being created by the bookinfo.yaml,
and we can also verify the deployment
and the services are created correctly.
As you can see, the pods and services are being created.
Now that the Bookinfo services are up and running,
you need to make the application accessible from outside
of your Kubernetes cluster, for example, from a browser.
So the Istio gateway is used for this purpose.
We're going to define the ingress gateway
for the application.
And next, we're going to confirm that gateway has been created.
Next, let's get external IP address
of the ingress gateway via the kubectl get service command.
With the external IP address, we're
able to access the application from the web browser.
Now let's get to the web browser.
Here is the Bookinfo application product page site.
Let's pay special attention to the Book Reviews
section in the website.
Recall that we have three different versions of reviews
defined in the bookinfo.yaml file.
As I hit the reload button in the browser,
the three different book review services
are being called in a round-robin style.
First one is the review with no stars,
and the other two are the black stars and red stars.
Switching among the three services
is normal Kubernetes routing and balancing behavior.
Let's switch to the GCP Console.
The Anthos Service Mesh page in the Google Cloud Console
provides both summary and in-depth metrics,
charts, and graphs that enables you to observe the service
behavior, and you get all the preconfigured dashboard service
metrics and logs out of the box.
You can monitor the overall health of the services
or drill down on a specific service
to troubleshoot the issue.
Let's navigate to the topology view of the application
services.
Let's take a look at one service,
say productpage, as an example.
Let's click on the bubble, and we can see more info
related to the service.
And the SRE golden signals, such as error rates and latencies,
are shown.
We can expand it, which consists of a deployment
pod and a Kubernetes service.
The ASM parsed the graph by observing
network traffic internal to the clusters and services.
Let's go back to the table view to see the list of services.
We can select a productpage service
for a close examination.
After the service is selected, a left navigation bar appears.
The Overview page displays SLO status, key metrics,
and details about the service.
The Health page displays SLO details.
You can create service-level objectives
for individual services.
These are supported if the apps are running on the GKE clusters
and it will be supported for Anthos multicloud clusters
in the near future.
The Metrics page displays charts for key metrics
and infrastructure metrics.
You can break down the metrics in numerous ways,
such as the cluster and the pod.
Here you can also view the application logs and traces
to find out more about your services.
The Connected Service page displays
details about inbound and outbound requests.
The Diagnostic page displays error log.
And the Infrastructure page displays the key metrics
and details about each pod.
You can click the pod name to go to the Workloads page
in the Google Cloud Console.
For more information on the additional tabs
relating to the service, you can visit ASM Dashboard
technical documentation website.
You can learn more about the Anthos Service
Mesh and installation details in our website listed here.
In addition, you can check out Istio Bookinfo application
example I've used in this demo in the Istio website below.
Thank you for watching the video.