[MUSIC PLAYING] MEGAN O'KEEFE: Hi, everyone. Welcome to day two of NEXT-- the afternoon, that is. My name is Megan O'Keefe. Just to make sure you're
in the right place, this is Hybrid 201-- Istio in Production
Day 2 Traffic Routing. All right, welcome. Great, so I'm here today. My name is Megan, hello. I'm here today to
talk to you all about how to manage
traffic in production with Istio in 40 minutes. Just a bit about me-- I am a developer programs
engineer at Google Cloud. My job is to work closely with
our engineering and product teams here at Google to make
sure that you, the users, have the best experience
possible with our technologies. Specifically, I work on
Kubernetes and Istio. In my previous
role, I was working as an engineer doing
multicluster Kubernetes at the edge of the network. So service mesh is
super exciting for me, and I'm so excited
to be here today. And thank you so
much to everyone joining here live and on
the livestream as well. So raise your hand if
you know what Istio is. Phew, OK. Raise your hand if you have
installed Istio and used it. Awesome, a little
bit fewer hands. Raise your hand if you're
running Istio in production. Oh my gosh, this is many
more hands than I expected. This is very exciting. I am here today to go beyond
the "hello world" of Istio. There's a lot of intro
content out there, and I'm here to show, through
demos and through concepts, how to actually do
things with Istio. So let's get right into it. I've divided up this
talk into four parts. First, I just want
to make sure we're all on the same page about
what Istio is and how it works. Because of time reasons-- I wish I could cover things
like multicluster Istio and mesh expansion with VMs. For the purposes
of this talk, we are here today to
talk about Istio running on one
Kubernetes cluster, plain old open-source Istio. The rest of the talk
will dive into demos about traffic rules inside of a
cluster, so east-west traffic. And then the latter part of the
talk will focus on ingress-- traffic in-- and egress-- traffic out. So how does Istio work? You may have heard of this
concept of a service mesh, right? There are many definitions
of service mesh. This is one. Picture all of your workloads
running on a platform, such as Kubernetes. The idea behind a service mesh
is it is a common substrate that lives on top
of your workloads-- does not modify them-- and through something
like a set of proxies, allows you, the operator, to
manage network interactions in a very consistent way. This is what a service mesh is. Istio is one implementation
of this paradigm. There are multiple open-source
service mesh tools out there. Istio is one. It was created a few years ago
by Google and in partnership with companies such
as IBM and Red Hat. It is fully open-source. But I think that this
definition sort of undersells what Istio is, really. I think what Istio actually
is is it's a platform. And you're like, oh my gosh,
no, not another platform, right? Kubernetes is a platform. But I really do think
that Istio is a platform. It lives on top of Kubernetes,
exposes a set of APIs for you to do some
very powerful things. Raise your hand if
you've heard of Knative. Yeah, so Knative is this amazing
open-source serverless platform that uses Istio,
works on top of Istio to do really cool stuff with
simple serverless functions on Kubernetes. That's super cool--
just one example of how you can build
on top of Istio. So I wanted to
say that outright. How does it work? And I'm sorry if this
is review for you. But the way Istio
works is through a set of sidecar proxies. So this is the data plane. So in this example, we have
one Kubernetes cluster, a set of pods-- those
are the gray boxes. And inside of each pod,
we have two containers. So remember in
Kubernetes that a pod can contain one or more containers. And the thing about
a pod in Kubernetes is that they share the same
Linux network interface. What this means is that
containers in the same pod can talk to each
other over local host. So this is how the
magic of Istio works. And what happens is you
use Istio to inject proxies into your workloads. And then all subsequent
traffic, inbound and outbound, goes through those proxies. And you're like, OK, so what? Like, proxies, great. Well, this is what Istio does. Istio configures these
proxies using rules that you give it to do very
customizable things with Envoy. And I want to go
back to just mention that those pink hexagons--
what exactly is that proxy? It is the Envoy proxy. So this is an open-source
layer 7 high-performance proxy written in C++. Istio is not the only service
mesh tool that uses Envoy. You can use Envoy on your own. Some of you might even have
written a control plane that configures Envoy proxies. That is the job of Istio. One key thing to note here is
that Istio installs its API on Kubernetes as CRDs. CRD stands for custom
resource definition. So what this means is
that you can interact with your Istio policies, and
your rules, and all of that using kubectl using
Kubernetes native tooling. And this becomes
relevant when you're trying to do things like
continuous deployment for Istio resources, and you want
a good way to do it. Put it all together, we have
the full Istio architecture. At the top, we have
the data plane. At the bottom, we have
the control plane. The key thing to note here
is that the Envoy voice side cars can handle multiple
different types of traffic. So remember, so this is
layer seven, so we're talking HTTP, GRPC, that layer,
the application layer, that is to say. And it's all running
in Kubernetes. Again, you can run
workloads in VMs. Istio can handle it. But unfortunately, don't
have the time today. I'm here today mostly to
talk about configuring Pilot. Issue has multiple
control plane components. So we have Galley
for config ingestion. We have Citadel for cert
management, for MTLS. And we have Mixer for telemetry. These are all crucial
components for Istio. Mainly the way that
you configure traffic is indirectly through Pilot. And Pilot pushes your
config, your traffic rules down to the Envoy proxies
in the form of filters. So you, the operator, are
never interacting directly with these proxies. You talk to Istio,
the control plane. And you might be kind of
wondering, like OK, so what? What's the actual added value of
taking on a piece of complexity such as Istio? It's not the world's most
easy thing to just deploy it. What does it get you? A whole lot for
traffic management. So one, just basic visibility
into which microservice is calling which. You might have
experienced this yourself if you're trying to decouple
a monolith into microservices introduces a whole bunch
of problems such as, all of a sudden, you
have new services, making network
calls to each other that maybe they
weren't doing before. Traffic inspection, so
taking individual requests and making decisions based
on things like HTTP headers. I'm going to demo
this in just a moment. Granular
percentage-based routing. So the thing about a Kubernetes
service, plain old service, is that you are limited
by your workload scaling. And what I mean by this is say
you have a Kubernetes service, and behind that sits
a bunch of pods, and you want to do
a Canary deployment, and you have, let's say,
one pod per deployment, the best you could do is 50-50. There would be no way in
Kubernetes plain to just say, I want 1% of traffic to go
to that new Canary version so I could roll back
really quickly if something goes wrong. So there's that. Automation-- this is, I think,
a really, really key thing. If you take away anything
from this talk, and I hope it's this. Because Istio exposes APIs that
you can add yamls to and use all of the tooling
that you would be using with plain
old Kubernetes, you can do an
essential automation that you could not do before. So I'm talking like turn on
MTLS end-to-end encryption for your entire mesh
with a single rule. That's pretty amazing, right? And finally,
decouple the network from your application code. What this means is that if
you're moving to microservices, you might have multiple
programming languages. Now you might have
a lot of services to deal with, a lot of
teams owning these services. With Istio, you no
longer have to have your developers think about
things like firewall rules or retry logic. The idea of Istio is to take
all of that network logic and to put it in the
hands of the operators so that you can manage
it in a unified way. And I know this is
maybe a mental shift from thinking about the
way we do these things, and it's incremental. And I'll mention that
at the end as well. OK, that is how Istio works
in a very small nutshell. What I'm going to do now is get
into the fun part, the demos. Traffic rules. So, how do you tell Istio to do
things with the Sidecar proxy? This is the question, right? Istio exposes a traffic API. It exposes multiple objects. Here are four. Today, we'll mainly
just be talking about. The first is a destination rule. What's a destination rule? It is a way to group a service
into subsets, which is just a long version of saying, you
can take a Kubernetes service and partition it
however you want. So in this example, I'm about
to show doing a partition based on versions. But you could have something
like here's my prod front end, and here's my build front end. You could do that. And this destination rule
backs a virtual service. And this is really
the key traffic rule, API object in Istio
that you should know. A virtual service is the
way that you list rules. So in this example
here, this yaml, I am going to do a
traffic splitting demo in which I canary-- or blue/green is really
the operative term-- of a second version of my
front-end microservice. And I'm going to direct
10% of traffic to it. This is sort of the
"Hello World" of Istio, so I apologize if you've
seen this a million times. But just to get
our feet wet here, it's going to be the
first demo I show. So what's the value of doing
this granular percentage-based routing that Istio lets you do? You can scale, and you
can release new versions and rollback quickly just
through the magic of Kubernetes Delete yaml. So that's pretty neat. Today in the demos,
I'm going to be showing I will be using
the Hipster Shop demo app. You may have seen this before in
some of the other Google demos. The only reason that we
use this demo over others is that we tried to
more simulate something you might actually be
running in production. So it's an e-commerce
application with a front end and a series of
back-end microservices. So traffic splitting, let's
get into the demo, shall we? What I will be showing,
again, 90% of traffic will be going to V1, 10% to V2. So let's head over
to our demo here. Can everyone see this OK? Do I need to zoom in more? So what-- just to
get a lay of the land here, what I'm
showing on the right is just a set of repeated
curl commands to a version end point of the front end. So I currently have one version
of my front end deployed to my Kubernetes cluster. This is just plain old
GKE with plain old Istio installed on it. And I am sending 100 requests
to the front end service. So this is that
Kubernetes DNS name, [? frontend.serviceclusterlocal. ?]
So what I'm going to show here is creating a destination
rule that breaks the front end into two pieces, V1 and V2. And then I will be splitting
the traffic as I showed there on the slides. So what we'll see
on the right here, hopefully, is I'm going to
deploy the second version. And what we're going
to see right away is that the default
Kubernetes round robin load balancing takes effect. And what this
means is just we're going to see 50-50, just random
selection between V1 and V2. And then I'll apply
the rule, and we will watch 90% of traffic go to V2. We deploy V2. If I do a kubectl get pods
here, we can see that-- you saw little 503 there-- that the second version of
our front end is running. If I run this command again,
we've got front end V2 running, and then we're going
to apply the resources. So apply the destination rule,
and apply the traffic splitting rule. And what we'll see here in
real time is that about 90% of traffic is headed to V1. And we're doing a
blue/green on V2. Again, in a real
production use case, hopefully you're using something
like a continuous deployment tool to do this, but just for
demo purposes, basic traffic splitting with Istio. Let's do something a little
bit more interesting here. So if we go back to the slides-- perfect-- let's look at
content-based routing. So I mentioned a few
minutes ago that Istio can inspect requests
and make decisions based on those requests. So what I'm going
to be showing is that you can use Istio to have
a rule that looks at the HTTP headers and routes
to a back end based on the contents of that header. Why would you want to do this? There would be potentially
a lot of reasons, like traffic prioritization. Building an A/B testing
framework on top of Istio would be an example. So what I'm going to show
is that any request that has a foo:bar1 header,
for demo purposes, will go to front end V1. And all other requests
will go to front end V2. So if we go back to
the terminal here, I'm going to reuse
the setup I already had from the blue/green demo. And here is the rule
that allows you to do that content-based routing. So again, we're looking at a
virtual service, Istio CRD, and rather than doing
just plain old splitting, we're going to do a match on
the header with an exact match foo:bar1. And we're going to
route all requests that fit that match to V1. And then we will route
all other requests to V2. Notice the kind
of the precedence that is implicit in this yaml. They say you shouldn't
build logic into yamls. This virtual service does
in which we fall through. So if we don't fit
this match condition, we fall through to V2. So here on the right,
when I apply this rule, and it's a plain curl
request with no headers, what do you think will happen? Raise your hand
if you think V1-- it will be V1, 100%. Raise your hand if
it will be 100% V2. OK, great. Just making sure you listen. So we're going to
apply this resource. In place, we're going to modify
the virtual service we already had. So 100% of requests went to V2. Why? Because we don't have
that HTTP request header. Here I am in a pod. And I can curl the front end. With that foo:bar1 header,
[? the ?] version end point. And we will see V1. And just to show I'm not faking
here, I can run this again, and again, and again,
and we will see V1. Run it without the header,
and we will see V2. So again, demo purposes,
showing as best as I can kind of the things you
can do on top of Istio. So if we go back to
the slides here-- so for all the subsequent
demos in this section, I'm actually going to
shift my focus from things like load balancing to building
resilient microservices with Istio. So in the following demo,
I will be showing something called circuit breaking. Raise your hand if you've
heard of circuit breaking. Yeah. So this is a very common best
practice for microservices and for distributed systems-- Istio did not invent this-- in which you wrap your services
in a piece of logic, or circuit breaker, such that if you have
multiple failing requests, essentially you're
applying back pressure to avoid cascading failures. And it helps. So what we're going
to show is if we have multiple concurrent requests
and more than one fail, we're going to flip
the circuit breaker, or trip the circuit
breaker rather, so that we fail right
away, and we don't actually make the full call
to our front end. And what this--
yeah, so what this helps you do is if you wrap all
of your services in this logic, you're building a
more resilient mesh. And we all want that. So what this actual
demo will show is I'm actually running a load
generator pod in my cluster. And I will be sending
multiple concurrent requests to the front end. And we're going to
watch some of them fail after we apply the rule. So I know it's kind of
a demo, but let's head back to the terminal here. So I've got multiple
clusters running. I'm actually going to go to
a new cluster for this demo. And let's see here-- all right. I want to make sure I'm showing
this rule as best as I can. So the way you configure
a circuit breaker in Istio is with a destination rule. And you're like, wait, we've
been doing virtual services this whole time. What's a destination rule? It's a little bit strange, but
basically a destination rule applies to inbound traffic. So what we're doing is
we're wrapping the front end service in a destination
rule such that-- and I want to make sure I'm
showing this as best as I can-- such that if we have more than
one concurrent connection, client connection to the front
end, and more than one of them is in pending state, we're
going to start kicking out subsequent client connections. And this is Envoy
logic, so you can go ahead and read
about the way Envoy implements outlier detection. Istio builds on that. It doesn't really
reinvent the wheel at all. The key thing to
note is that we are going to set that time out
period for three minutes. And I'm not going to show
the full three minutes. But, yeah, so that's
circuit breaker. So what I'm going
to do here is run multiple concurrent
requests into the front end. So in this example, I'm going to
do 10 concurrent requests, 100 total requests. And we're going to watch
all of these paths, hopefully, and get two 100s. So we can see here that all of
the requests to the front end passed, which is good. You want more than
10 clients to be able to talk to your web
front end at once, ideally. And we're going to apply
the destination rule, and we're going to run
that command again. And so what's happening
is Envoy knows to kick a 503 error in the case
that the circuit breaker is tripped. So what we're going to see here
in the terminal on the right is a whole bunch
of 503s hopefully. So a parsed non OK
code, 503, HTTP. So that came from Envoy. And you'll note-- so with 10
concurrent requests, only 15% of them actually went
through to the front end. Again, in production, you would
build a more robust system around testing this. This is just, again,
for demo purposes. So that's circuit breaker. I've got one last demo in
this traffic rules section. Thank you for
bearing with me here. If we go back to the slides,
the last demo in the section, I'm going to show
fault injection. So, raise your hand
if you've heard of chaos testing in production? Yeah. So the premise here is that
traditional unit integration smoke tests cannot
predict every failure case in your microservices. You would ideally like a
system or a framework that is prodding at your
mesh and trying to find weak areas so that you
can build up that resilience. So the idea here is that Istio
allows you to inject faults into one edge in your topology. And so what I mean
by that is what we're going to do in this demo
is inject a HTTP 400 bad request error in a specific
connection between checkout and product catalog. Notice we are not
touching the requests that are going from front
end to product catalog. So this is another example of
how Istio allows you to really granularly choose what
parts of traffic apply and what services. Again, yeah, controlled
disruptions into the mesh. So, let's go ahead
and demo that. If we go back to
the terminal here, switch over to a new cluster. So the way that you
do fault injection is with both a destination
rule and a virtual service. Let's see here, all right. So let me show that. The destination rule, all
it does-- so again, we're introducing a disruption between
checkout and product catalog. So what we're going to
do is define a subset for product catalog V1. And the virtual service needs
this to inject that fault. And so notice like with the
content-based routing demo, what we're doing is
this match condition. But rather than
matching on a header, we're matching on
the source workload. So we're saying, OK, only
requests from checkout should have this
400 status code. Abort those requests,
100% of them. Everything else fall
through to normal behavior. So that's what we hope to see. And the way I'm going
to demo this, again, just for example
purposes, is by going into the actual application
into the front end and trying to do a checkout. And it hopefully will fail. So let's see here, all right. So we're going to go
into our front end. Oops, that was not
what we wanted. So let's see here. Here's our external IP. So, here's the Hipster
Shop front end. And what we're going to do
is try to do a checkout. So notice how we injected the
fault into product catalog, but we can still see
the list of products. This is because, again, the
connections between front end and product catalog
are still OK. But if we tried to do a
checkout, place your order, we will see an error that says
internal, failed to prepare order, failed to get product. It's a 500, but internally
it is a 400 HTTP error. And what we're going to do
is if I delete these rules and I try to actually redo
that checkout transaction, it'll work. So again, basic
fault injection, you would usually apply
these sorts of resources in the context of a larger,
more controlled experiment. In production, I
would not advise testing the resiliency
of your applications by applying these rules to
your production cluster, maybe for obvious reasons. So with that, we end
the first section. Thanks for bearing with me. If we go back to
the slides, perfect. So that was kind of a whirlwind
tour of East-West traffic routing. And the key here is
to give you a taste of how you can build on
top of the Istio APIs to do cool things. So in the last two
sections, I'm going to cover Ingress and Egress. So traffic in first. Raise your hand if you're
running something like NGINX or a reverse proxy in
front of your services? Yeah, right. So inbound and Ingress
traffic into Kubernetes or into a data center
is maybe nothing new to anyone in this room. The thing I would like you
to take away from this slide is that Istio has a very
deliberate model in which everything is an Envoy proxy. So what is the
value out of that? It means you can configure
East-West traffic in the same way you configure
inbound and outbound, with the same yamls. And this becomes
very powerful when you're talking about things
like MTLS and traffic splitting. And yeah, so what I'm
going to show here is how exactly that's working. The way that Istio
Ingress works by default is that there is a default
Ingress gateway and Envoy proxy that is running
and is exposed internally through an external IP
on a Kubernetes cluster so that you configure it to
punch a port in that Ingress gateway to allow traffic in. And I've actually been
doing this this entire time. So I'm going to show
how that's been working. Like how am I accessing this
web front end in my browser? It's with this exact
set of resources. My client, my laptop
right here, is going through the Ingress
Gateway configured via gateway yaml, going to an
Ingress virtual service, finally landing at the
front end, back and-- the front end,
front end back end. So here's the Gateway yaml
that allows us to configure that Ingress gateway. So we have a selector
here that says, I'm talking about the default
Istio Ingress gateway. You can deploy your own. But I'm basically
punching a port, port 80 and the default Istio
Ingress gateway, and routing to any host
I configure it with. And in a lot of demos, you'll
see this host wildcard star. In production, you would be more
specific about the front end. So I'm just going
to quickly show those yamls in my terminal. I'm not going to deploy
anything new or special. Let's see here,
all right, perfect. So let me show you the
actual Ingress gateway pod that's running. So when you install Istio-- so these are all of the Istio
control plane components that are running in my cluster. And you'll notice this
Istio Ingress gateway pod, this one out of one. So this is a single
Envoy container that is running that
we will configure. And we configure it like this,
through this Gateway resource. These are the same resources
I just showed on the slides. And these are all
applied to the cluster. I can do a kubectl get gateway. Here it is. I can do a kubectl
get virtual service. I can actually
show you that one. And we're saying for
inbound hosts that have made it to the
virtual service, route to the back end
running on port 80, which is where the Kubernetes
service is running. And what I can do from there
is get the Istio Kubernetes services, get the external
IP of the Ingress gateway, and this is how we
get to the front end. So in production, you would be
mapping a well-known DNS name to this IP. And it's a stable IP that
you can use to back-- or to front, rather,
multiple services. So if I go to this IP, I should
be able to see the Hipster Shop front end. So that's a really quick
rundown of Ingress. There are ways to say-- sorry,
we can go back to the slides actually. Thank you. So there are ways to configure
that Ingress gateway to do things enforce mutual TLS. There is a wonderful
demo out there that shows securing
the Ingress gateway with Let's Encrypt or any sort
of cert issuer of your choice. And yeah, I don't have
time today to showcase that, but yeah, I can
find a way to link it. So that's Ingress traffic. Outbound traffic works
in a similar way in Istio in that you can choose
to route outbound traffic through an Envoy proxy. It should be said that
in Istio 1.1, which was released a
couple of weeks ago, the Egress gateway I believe
is now disabled by default. Not everyone wants all traffic
to go through an Envoy proxy as it's leaving the mesh. There are very
valid reasons why. But here is the basic model. So when you want
traffic-- so, I guess I should preface with this. Has anyone ever installed
Istio and all of a sudden had things like your MySQL
connections just start to fail? Yeah, right. So by default, Istio locks
down outbound traffic. This may change in the future. But right now, if you've
encountered this problem, that is why. You need a yaml. You need a service
entry that says, yes, it's OK for my
traffic to go to MySQL, and this is where it is. Think of a service entry
as a piece of inventory of a well-known
hostname that you are allowing outbound traffic to. And you add one of
these for anything that needs-- your
in-mesh services need to access outside. So this would be like an API,
like the Google GCE APIs. And when you add one of
these resources, by default, it goes directly to
that external service from the services Envoy proxy. What I want to show as my final
demo here is a way to secure-- so Egress traffic more securely. So imagine that you have
a situation in which you want to really carefully
monitor any traffic that is leaving your environment. So say you're running Istio
on-prem in a specific region, and you want to
make sure that you can enforce or at least
inspect outbound traffic. So what you can do is
input an Envoy proxy in between your in-mesh service
and your external service to do exactly that. So what I'm going
to show in this demo is I'm going to configure
the Egress gateway in Istio to look at all traffic
to this EU bank endpoint. Why would you want to do this? There's another really
good reason why, which is [? it ?] started-- I think it's an
increasing best practice to think of in-mesh
services the same way as you would
out-of-mesh services. And what I mean by this
is just because something is running in your
cluster does not mean you can
necessarily trust it. Kubernetes has service
accounts, and then we have-- our back end, we have all of
these safe systems in place. But that doesn't mean that
a malicious service can't make its way into your
cluster with, for example, a Docker image with it's
kind of an erroneous tag. So that is why I think this
demo is somewhat relevant. So what I'm going to be showing
here is that in our demo app, one of our back ends talks to a
bank API to get exchange rates. And we're going to put an Egress
gateway in between the currency service and the API to
look at outbound traffic. I'm not going to show
this in this demo, but what you could
do with this gateway is configure it, just as we
did all the way up until now, with rules, such as Enforce
MTL to the EU bank end point. So with that, I will do this
final demo back in my terminal. Oops, all right, perfect. Let's get on the right
cluster here, awesome. So let's look at
the resources that allow us to do exactly this. So right now, I just
have my plain demo app deployed, no fancy rules. No, traffic is not
going through an Egress. And what I want to show
just to prove it's working is to actually get the really
spammy logs of this Egress gateway. And actually-- yeah, sure. I apologize if this
hurts anyone's eyes. So what we're going
to hopefully see-- and I was running this a
little bit earlier, so sorry for the spoiler alert. But we're going
to watch requests go through the Egress
gateway via the logs once I enable these rules. What rules am I about to enable? These. So the way that you would
get this demo working is you would configure
the Egress gateway, which is already running because
I'm running a slightly dated version of Istio. You would configure this
Egress gateway to route traffic to the external endpoint. And then from there, you would
add additional resources. The first would be
ensure that traffic goes through this secure gateway
by specifying route rules just as we have been
throughout this demo. And sorry that they're
a little bit dense here. So it's, I know, a
lot to grep visually. And then we would define a
destination rule that, again, is forcing traffic to go
instead of from currency service directly to
the EU bank endpoint, we are using route rules
to funnel that traffic through the Egress gateway. And so what we will hopefully
see in the Egress gateway logs is we will see a
warm-up log that says, OK, I'm the Egress
gateway, and I know that I can be talking
to the EU bank API. And then we will see the
actual request go through once I try to do a
currency conversion. So let's apply the resources. We can see here in the
Egress gateway logs-- it's kind of hard to see-- but
we have this warming cluster outbound ECB, which is
the European Central Bank, complete. So the Envoy has been configured
with the rules it needs. And then if we go
into the front end, and we just try to
do a refresh here-- it's a bit slow. We may or may not have some
throttling issues with this API as we demo it repeatedly. And we try to do a
currency conversion here. What we'll hopefully see
when we go back to the logs is that a request went
through the Egress gateway. Sorry for all those
telemetry errors. But yeah, so we see all these
HP get requests to that API. So yeah, that's securing
Egress traffic again. With demos, it can
be tough to show exactly how you would bring
this into your own environments. But I hope it at least
gives you a taste. So with that, I'm going to go
back to the slides and wrap up. Thank you so much
for being with me. I know it's a lot of demos
and a lot of yaml to stare at. All right, back to the slides. Closing thoughts. I want to stress that Istio
1.1 one was released a couple of weeks ago, super exciting. It was the result of a ton of
hard work in the community, not just by Google, but by
many other organizations and individuals to help
improve Istio's performance and scalability. So 1.0 was not too long ago. And now, we're in 1.1. What this means is
that Istio is still a relatively young technology. Some things are changing. And it is out in the open. It's open source. But what I want
to, I guess, stress is that these APIs are the
building blocks from which you build other things. So Istio might have internal
control plane changes in the coming months, year. The hope is that these API
objects become the things that your organizations
build on to do cool stuff. So that's 1.1. What are some best practices for
bringing Istio into production? This is just my two cents. It would be to
start somewhat slow, pick the one feature
that you really want to bring to
your environment or try out if you have
a sandbox cluster. So this could be something
like a blue/green deployment. This could be enabling
MTLS, which I didn't even cover in this talk. And learn the CRD, like
learn the virtual service for that feature,
and it becomes easier after that to do other things. There is a somewhat
steep learning curve that I know I
encountered myself. So I would stress that. And from there,
gather the tool kit that helps you figure
out when things go wrong. So there's awesome open source
tools that do service graph. So kiali is one example. And yeah, there's a command
line tool called Istio CTL. If you've never encountered
that, it's on the docks. It can do things like
validate resources, check if MTLS is working,
look at the proxy status via the Envoy APIs. It can do a ton of cool stuff. And then from there,
work your way up. It's definitely a
journey, similar perhaps to adopting Kubernetes. I'm not trying to
say that it's easy because it's a bit of a road. And this talk did not
even, I don't think, scratched really the surface
of what Istio can do. API management is one example,
and user authentication with JWT tokens are
back, unified policies across services, which
services can access which, doing custom
telemetry forwarding to the sync of your choice-- Prometheus, Grafana,
hybrid environments, mesh expansion to VMs,
multiple Kubernetes clusters. I mean Istio is, I think, a
massive piece of technology that can do a whole bunch
of really cool stuff. And if this is
interesting for you, yeah, I would encourage you
to check out the other talks that I'll be showing on the
screen in a few moments. I wanted to give a quick
callout to Anthos, which was announced yesterday,
which is Google's hybrid multi-cloud offering. And I want to maybe
clarify that Istio plays a key role in Anthos. The way Istio plays a
key role is via the APIs. So all the resources I've been
showing throughout this talk-- virtual service, gateway,
destination rule-- all of those can be used to
configure your mesh in Anthos. The control plane in
Anthos is Google Manage. So what I showed was using
open source Istio Pilot to actually configure
the Envoy proxies. Today we announced
Traffic Director, which is the Google managed pilot is
a helpful way to think about it. But it works just
the same way as Pilot in that it uses the Envoy XES
APIs to configure the proxies. So I hope that
clarifies the things if you're kind of a bit confused
about how all the pieces fit together. I want to also say that
this is not the end. There are multiple other
Istio talks this week at NEXT. A quick callout that I'm
giving another talk tomorrow morning at 9:00 AM in the AMC
[? Metreon, ?] Debugging Istio. And it's almost entirely demos. So if this was not
enough for you, and you want a whole other
hour of this in your week, you can join us
tomorrow morning. One final callout that
we here at Google, we are conducting
some user studies for folks who are
either not using Istio or are currently
trying to use Istio. And if you would like to
join these user studies and to provide feedback in
any way, go to the form here. So we are at nine minutes. I would love to answer some
live questions in the remaining time. I do want to say that if
I'm not able to answer your question right now,
I'm happy to talk after. I will be around
outside the room. I'm not, I guess, and
all-knowing Istio guru, although I really wish I was. So with that, anyone who
wants to ask a question can just line up at those
mics right down the middle. And I will try to
answer as best as I can. Thank you. [MUSIC PLAYING]
