09. Introducing Envoy - Introducing Envoy - The Data Plane

So we're working on a service mesh.

And there are lots of service mesh implementations out there.

Istio is just one of them.

And the way that Istio implements a service mesh is by using proxies.

The idea is that if a particular container is making a call to another container in our cluster, then the magic is the calls are routed or routed via these proxy components.

And you also know that they're implemented as sidecar containers in Kubernetes.

So already, we have two terms for this proxy.

If you're working on an Istio cluster, and somebody says, oh, the proxy in my pod is failing, you know that they're probably talking about the Istio proxy.

But they might also say, Oh, my sidecar is failing in my pod.

And that also usually would mean proxy.

But something that we've not looked at is where does this proxy come from, and I can tell you that Istio has not implemented this proxy.

In fact, you're going to find a lot of Istio comes from third party components that have been very cleverly assembled together to give a sort of easy to use, well, a relatively easy to use service mesh.

The proxy in Istio comes from an open source project called envoy.

Here I am on the envoy websites, it's at envoy proxy.io.

So envoy has been developed kind of completely independently to Istio.

And envoy is just a proxy for cluster based applications.

Now info isn't particularly written with Kubernetes in mind.

Kubernetes is just one environment that envoy can run in, just in case you're interested envoy came from lyf, which you might well be familiar with.

Lyft are not a well known name in the UK at the time, I'm recording this, I think they're currently a US and Canada operation.

So taxi scheduling, like Uber, basically.

So they anyway, they originally created this.

And they claim it's used by the claim it's used by absolutely everybody.

If we go down to the features here, basically, many of the features that I've been saying, we get from Istio in the service mesh are actually coming directly from envoy.

So for example, things like circuit braking a little bit like we did in the warm up demo application.

What we were doing there when we made that change to a yaml file was we were in fact, configuring envoy.

So we will making changes to the proxy and the tracing.

When we used Jaeger, and we used kiali.

Those features were actually coming as a as a result really of envoy gathering the metrics that we need.

So envoy really is a critical component of Istio a lot of the features that we have are coming directly from envoy.

So you might be wondering, Well, why don't we just use envoy.

And that's certainly a good arguments.

And there are probably some projects do use envoy without Istio.

But envoy does need a supporting environment around it.

And you do need additional tools to make it really to make it usable just think of envoy as being a very low level tool.

And it's not very easy to work with at a sort of engineering level.

In the next video, which I'm going to make an optional video, I know some of you will want to have a little bit of a play with MVP.

So we'll do a very short demo and a very simple demo on getting envoy up and running on its own, which might give you a taste for envoy.

But for 90% of this course we're going to be letting Istio manage envoy.

And believe me that really does make your life a lot lot easier.

But before we go any further, let's just update this picture now.

And a really annoying thing about these proxies is that you've basically got three words for them.

You could call it the proxy, you could call it the sidecar.

You could call it envoy.

Or you can use any combination of these three terms.

So don't be surprised if on your project your manager says, Hey, can you debug this envoy proxy? Or this envoy sidecar? Or can you debug my sidecar proxy? Or can you deal with my envoy proxies? It is really weird that we've got this very overloaded term in Istio but for our purposes, those three words mean the same thing or any combination thereof.

So one question that you might have here.

And I certainly felt this myself when I started on my Istio journey was given that these envoy proxies implement really most of the features that we're looking for from a service mesh, such as traffic management and telemetry, why don't we just use envoy? What is Istio bringing to the table? First of all? The answer is yes, she could absolutely go ahead yourself as a project and download envoy and build a service mesh for yourself.

That's perfectly possible and respectable routes to take.

But I certainly would not want to do that.

And over time, I've realised that Istio brings an awful lot to the table.

But as a sort of a quick answer, I'm going to say that the the thing about envoy is that it's very generic, it's capable of being deployed into many different types of cluster, it doesn't really have any particular connection with Kubernetes, it is just a proxy, you can download the source code from envoy, it's all in c++, and you can build it into a binary executable.

And so that means that really in envoy, there's no reference to Kubernetes at all, there's no real references to clusters.

It means that envoy has its own massive terminology, and its own set of concepts, all of its own.

And you would have to learn all of those concepts and terminologies and configurations.

And you would have to somehow map that into your Kubernetes clusters.

Now to explain, I've just gone to the envoy website.

And we really do not need to understand the invoice documentation at all.

I'm just using this as an illustrative example.

I'm pretty much the hello world example here.

And this is showing you how to bootstrap a simple envoy proxy, and to connect your components to it.

And if I just go a little further down, I'm just pointing here at this is a minimal bootstrap config file.

And I don't know how you feel about this config file, it depends on what kinds of things you've worked on, if you're used to configuring Apache or nginx service, and you'll see a lot of commonality in here.

But I want to really point out that there is absolutely nothing Kubernetes like inside here, there's a lot of talk about listeners, filter chains, virtual hosts, route conflicts, clusters, now, okay, we have a Kubernetes cluster.

But the definition of cluster in envoy is completely different to the definition of a Kubernetes cluster, we have references to load balancing here and endpoints and socket addresses, and so on.

And really, as a Kubernetes engineer, I don't really recognise any of this.

So if I wanted to use envoy in my Kubernetes cluster, I'm going to have to do a lot of work an awful lot of work to configure envoy properly.

So that's what Istio brings to the table.

And as a sort of sales pitch for Istio Istio really does simplify envoy if you're working on a cluster like Kubernetes.

So Istio really does understand Kubernetes.

Now by that I mean, when we're configuring these proxies, we are able to use regular Kubernetes yaml.

Well, not quite regular Kubernetes yaml, it's going to be these custom resource definitions.

So they are extensions to Kubernetes.

But that's fine, they're still Kubernetes objects, we're going to use kubectl apply as normal.

And then under the hood, our Kubernetes yaml is going to be transformed into envoy configuration automatically.

So as an Istio engineer, unless things go horribly wrong, you don't need to work at the level of envoy.

So you could think of his scales being an abstraction layer over the top of envoy.

It's not quite technically correct.

But do you know what that's good enough for me, I've just come back into the text editor to look at the YAML file that we applied back in the warm up exercise.

This is the file called for application full stack dot yaml in the warm up exercise, and the bulk of this is regular Kubernetes yaml that you will recognise with deployments.

And going a little further down.

We're going to find some services regular Kubernetes services, but we did a little bit of work a very short amount of work on this entry here around to line 207 C which we can tell comes from Istio because of its API version.

And it's this object called a virtual service.

So we don't know what a virtual service is yet, they will be covered in detail on this course.

But the configuration of this just feels very similar to the sorts of things you will have been doing in regular Kubernetes.

But I can now reveal that what was happening with this virtual services, this was being converted under the hood into configuration that envoy understands.

So I hope that's answering the question of what has Istio ever done for us.

It's hidden, the low level details of envoy is one thing.

So the proxies then supplied by envoy, which becomes sidecar containers on a Kubernetes platform, are, I think, the most critical components in the whole of Istio.

And I mentioned previously that the set of proxies are collectively called the data plane in Istio, that's the distinguish the proxies from the rest of Istio, which is called the control plane.

And the control plane used to be really complicated in earlier versions of Istio.

But now, it's essentially a single pod, called the Istio demon.

And actually, this video as replaced what used to be a very long section on this course, covering the architecture of Istio.

But in modern versions of Istio once you understand the fact that there are proxies running, they happen to be implemented by envoy, it doesn't really matter, you probably not need to understand the detail of envoy for a very long time, if ever, the overall architecture of Istio is very much simpler than it used to be, which is why this short video has been able to replace a very long chapter, but I do have a video coming up which looks in a bit more detail in envoy.

I've only put this video in the course for people who really really really want details on envoy.

You don't have to study the next video you can safely skip it.

If you're not interested in looking at the internals of envoy