YURI GRINSHTEYN: Do you run distributed workloads
on Kubernetes or GKE?
If so, you are probably having to manage
more and more services, and it's getting harder or harder
to understand what's going on if there are any issues.
This is where a service mesh can help.
A service mesh is a dedicated infrastructure layer
that you can add to your clusters.
It gives you a capabilities like observability, traffic
management, and security, without having
to modify application code.
My name is Yuri.
I'm an SRE at Google Cloud.
And today I'm going to show you how to use both the open source
version of the Istio service mesh
and Google's managed Anthos Service Mesh
to get better observability for your services running a GKE.
This is Engineering for Reliability.
[LIGHT MUSIC]
The Istio service mesh works by adding Envoy proxy sidecars
to your services running on GKE.
These proxies intercept all service-to-service traffic
in the mesh and enable the application-aware features
like security, traffic management and routing,
and observability.
This is the data plane.
The control plane dynamically programs the proxy
sidecars, updating them as the rules or the environment
change.
Your first option for using Istio in GKE
is to simply install the open source
distribution in your cluster.
This is the way to go if you prefer
to have the most control over your deployment
or if you have existing dependencies on features that
may not yet be available in Google's managed offering.
Istio includes an open source observability toolkit.
You can use Prometheus for metrics and Zipkin or Jaeger
for analyzing tracing.
You can also enable proxy access logs
and have the proxy sidecars write out logs
for every request in the mesh.
Let's have a look at how you can use this toolkit
and centralize all that telemetry to Cloud Operations.
In our example, we have an application running
in the Istio demo namespace.
We have the Istio control plane and observability components
running in the Istio system namespace.
This includes Prometheus for metrics and Kiali
for observing traffic in the mesh.
If, for example, we want to look at the request
rate for our services in the mesh,
we can use the istioctl dashboard prometheus command
and run a query like this.
If we want to visualize how traffic
flows between the different services in the mesh,
we can use Kiali.
At each node we can see how much traffic the service is seeing
and what the response time looks like.
Finally, we can enable request logging for the Envoy side car
proxies by using a telemetry API.
We can then view those logs in the terminal.
Now let's have a look at how we can get this telemetry
into Cloud Operations.
To adjust the Prometheus metrics,
we can actually use Google's Managed Prometheus binary just
by replacing this image tag.
This allows us to query Prometheus metrics
in Metrics Explorer.
Here's that same request for a query.
The proxy sidecar request logs are automatically
ingested into Cloud Logging.
And we can query those, too.
So through the combination of Google's Managed Service
for Prometheus and Cloud Logging,
we can get metric and log telemetry generated
by Istio ingested into Cloud Operations
and use it just like other telemetry
from your infrastructure and services.
If you want to maximize control over your Istio deployment
and possibly have experience with Istio already,
using the open source distribution
is the right way to go.
However, if you're new to using a service mesh
or would simply like a more managed experience,
there's the Anthos Service Mesh or ASM.
It's a tested and supported distribution of Istio,
giving you all the benefits of a service mesh
with full Google support.
If you'd like to control version upgrades
yourself or have existing integrations you depend on,
you can deploy ASM with an in-cluster control plane.
Let's have a look at such a deployment
and how it automatically sends telemetry to Cloud Operations.
Let's first have a look at our cluster.
The control plane pods are running in the Istio system
namespace, just like what we had when we installed open source
Istio.
Our application pods are also instrumented with the Istio
proxy containers.
Now let's have a look at the telemetry
that the Anthos Service Mesh collects.
The Anthos Service Mesh home page in the Cloud Console
has a list of the services that are running
in the mesh in our cluster.
We can select a service and get some basic information
about it, like request rates, error rate,
and average latency.
The topology view here shows us how the service
sends and receives traffic.
The Metrics screen allows us to see these metrics
over time, broken down by various dimensions.
Finally, we can get error logs for our service
by going to the Diagnostics screen.
We can click out to the Logs Explorer
to get more details about these error logs.
This is also where we can view the access logs
for our services.
We can get more metrics telemetry in Cloud Monitoring.
example, we can run a query like this
to get a breakdown of request rates by service.
So this is how you can use telemetry automatically
ingested from the in-cluster ASM control plane
to understand the behavior and the health of your services.
If you're just starting out with Istio
or would like to use a fully managed service,
you can use Managed ASM.
In this deployment model, the control plane
is fully managed by Google and does not run in your cluster.
It does mean that some features, like custom metric adapters,
won't work.
If you need advanced features like these,
the open source distribution may be the way to go for you.
If not, let's have a look at a managed ASM deployment
and how its telemetry is automatically
ingested into Cloud Operations.
Let's again start by looking at our cluster.
In this case, we don't actually have any Istio control plane
pods running in the Istio system namespace.
The control plane is entirely managed by Google,
and there are no control plane components
running in the cluster itself.
Our application paths, however, are still
instrumented with the Istio proxy sidecar container.
Now let's have a look at the collected telemetry.
Just like before, we can look at the services
running in our cluster.
For all of them, we can get the same basic telemetry,
including the topology view.
We can get the same metric telemetry,
and we can get the same access logs.
All of this is made available via the managed control
plane without the need to have anything
running in the cluster itself.
Thanks so much for watching today.
We learned how a service mesh improves observability
for distributed workloads run in GKE
and how you can use Cloud Operations to get telemetry
from both open source Istio and the Anthos Service Mesh
to observe your own services.
I hope this helps you to keep your applications reliable
and your users happy.
Don't forget to like and subscribe to never miss out
on more "Engineering for Reliability with Google Cloud."
See you soon.
[UPBEAT MUSIC]