Cloud Native Computing Foundation KubeCon + CloudNativeCon North America 2017 (Austin), 15 Dec 2017

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Setting Sail with Istio [B] - Lachlan Evenson, Microsoft

Description

Setting Sail with Istio [B] - Lachlan Evenson, Microsoft

Even with Kubernetes, doing microservices is hard. In this session we will dive into Istio, A platform that builds on Kubernetes primitives and simplifies building and securing microservices. This session is a soup to nuts walkthrough of the Istio architecture along with diving into deploying a microservice onto Istio from a user perspective. For those interested in learning more about Istio, this session is a great introduction and will be very hands on.

About Lachlan Evenson
Lachlan Evenson is a cloud native evangelist and mercenary. Lachlan has spent the last two and a half years working with Kubernetes and enabling cloud native journeys. He is a believer in open source and is an active community member. Lachlan spends his days helping make cloud native projects run great on Azure.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.

A

So let me just before we get into this I just want to say: I wrote this session to be beginner level. So if this is your first time hearing about sto you're in the right place and even if you've used this do hopefully I can teach you something new. It's going to be dynamic, it's going to be fun, so, let's have some fun. We've got 35 minutes to jam in months of content, so let's have some fun. Keep it dynamic.

A

If you have questions feel free to raise your hand and I'll answer, as I can okay setting sail with this? Do who knows what is the only means you it's a sail on a boat, so we're in the Greek terminology, land all parts of a boat sto is another part of a boat I. Think it's a sail is that anybody disagree, no okay, great great great. So let's ponder this. The Mona Lisa I took this three days ago. Think about this service meshes are the new black, so this whole conference has been service. Meshes.

A

Did anybody know about service meshes three days ago, probably very, very little of us but I. You know I looked at this tweet and there was something quite profound in this tweet that I saw. Does anybody see it obviously from Jesse? It's fantastic? What I see is a community, that's maturing, so now we're not as worried about being in the the details of kubernetes. Now we're looking at running micro services and applications over time and all the toolkits. We need to actually do that.

A

So this is a sign of us as a community maturing and now we're looking at. We have a kubernetes. Now, what can we do with it? Kubernetes is growing up, so this is a great thing, so don't be scared of the service mass, hopefully I'll, demystify it a little bit, but I think this is a really profound statement from this cube con, and hopefully everybody leaves this room knowing just a little bit more about sto and service measures.

A

Two and a half years ago, I was a young little boy with starry eyes. Looking out the window in my office in San Francisco, my old boss is actually here up the front. I won't call him out. I was looking at the window, I'd heard about micro services, I bought the books, I'd read the blog I'd sat in 15 Adrienne Cockroft speeches about micro-services and Netflix I was a convert, I had a mission and we were going to do this. What did I do?

A

I went out and I took a look around and we landed on kubernetes. Thanks to thanks to my boss. He deleted that ship I got to call him out, give him credit we landed on kubernetes, we started moving these apps, we started getting into micro services. Things were great, things were doing really good. This was the platform we were going to get to micro services. Things were great like this picture. Right things were really going great. We got to our 10th or 11th service and it was a Sunday morning at 3 a.m.

A

we get the phone call I'm on call services 11:00 down I. Don't know why service 11 is down, I've got no visibility and what's happening, I've got no idea. What's going on, please ring the owners of service, one two: nine to figure out why services 11 is down I mean, what's going, I have no way so soon this bubble burst and I'm, not to say micro services are bad, but when we take a look at is do we may have some pain relief there, so the monolith is over there.

A

This is a comic from the the Google container, guys I, don't know. If you saw this the folks over there put out this comic, but we've taken that big monolith which we knew about, and we knew how that monster worked and we split it up into a million little different gremlins with their own agendas and they're all running in different directions.

A

Let's see how we can apply sto to this to actually try and solve some of these problems. So can anybody relate? Is this a story? Was anybody else, a starry-eyed boy or girl? Looking out the window saying, let's do micro services and convince your company to follow you yeah everybody's done. It good I'm in good company I'm, not the only one. Thank you, validation that I'm not crazy.

A

Who am I unlucky, but, more importantly, I'm speaking from the perspective that we've been through this journey and are still going through this journey. You're not alone. Most of us are solving this our own different ways, but let's take a look at some tools out there and maybe gather around these tools and start building a community around them. I look at is do now, and what tío is is something that we tried to build because we saw the need in a micro services platform, and we saw the kubernetes is its sharp edges.

A

People say it's the kernel of the cloud: it's the assembly language, it is it's not a platform for Microsoft, it doesn't have all the bells and whistles right. You need to build platforms on top of it. I still help customers with kubernetes today, so I see a lot of folks working with a lot of folks looking at sto and looking at solving problems. So I speak from that context and I wrote the upstream helm chart. So has anybody used the helm, chart good bad? You can say bad, it's! Okay, good! Thank you!

A

Thank you, but all this to say, micro services are hard. This I think Clayton got up on stage this morning and said we need to start building platforms for my tree services and seeing all these service messages, but building micro service is actually quite hard and it's hard because it's completely different to what we used to do. So, let's take a look at how we can start digging in one final quote: it wouldn't be complete without a quote from Kelsey, but kubernetes is a platform for building other platforms. So now we're happy with kubernetes.

A

We know how it works. We've we've fiddled with all the knobs it has to offer. But let's start looking at building platforms on top of it, it's not the kubernetes. It's not the end game. It's just the beginning of our micro service journey.

A

If we look into why micro services are hard from my perspective is most of us aren't operating in greenfield environments. This isn't day one of our startup. We have legacy applications and for better or for worse, they are there to stay they're, often making us money. You know that's paying our salaries, so we're not operating we're operating with that baggage. We have the big monster. We can either break him up or build little smaller monsters.

A

Whichever way we want to do that, but micro services I, think, is an ecosystem of people tooling and process, and in this equilibrium of those three tooling, is the easiest thing to change. People in process take a long time to change they're hard to change so tooling. People look at the answer is a tooling and hopefully some tools today that can help change your microservice journey. So these all take time and what we came to find is microservices exposed all the cracks in our architectures, so everything we had designed to do now.

A

We'd split it up and not gone back and rethought a lot of things so problems that were once hidden in memory that you didn't see inside a heap are now spread across a dependency graph of our pcs across 15 different services. So you've moved you've moved a problem which means once well understood problems change, so production uptime changes the way you need to monitor and start that sto has features for all of this.

A

So we'll take a look at those and, as I said earlier, the great thing about micro services is that they're easy to get on to you know you get on you get your first two or three up you're feeling good things are going really quick, you've done it, but things break down when you're at ten twenty. You have this Cambrian explosion of services everywhere, and you have no idea how they're communicating and where faults are contract points, SLA s and responsibilities.

A

If we talk about them developers, own services and micro, service, architectures, they're, responsible for contract points and api's, and when these things fail and they have all their own SLA s, we need to understand where the system is broken and how to fix it. Nascent tooling and bespoke. A lot of this tooling is less than months old. You know where we're working in a very highly dynamic environment. So if people are picking up new tools, trying to bolt them in so you're making this Rube Goldberg machine of tooling, so hopefully something like sto can help.

A

Give you a stable base and you know you're not yet equipped. You don't know what you don't know. So nobody can tell you what you need to do and there's no handbook or guide on micro service. You need to learn them in your own environment and what makes sense for your own business.

A

So out of all of this, it's what do we need? This is kind of the laundry list. What do we need? Observability monitoring, metrics tracing traffic management policy, security, easy each developer can do this right yep, but who does that and into as well? And what I've seen is each developer or development group is actually solving a lot of those problems independently and not bolting them together at the end. So because the expectation is that they all individually solve them, because there isn't a platform they can turn to to solve them right.

A

So I want everybody to kind of think about sto why you would use it before I give you the goods, because I think you all need to think about where it fits in your workplace in your environment.

A

It's not you know it's not the be-all and end-all for everybody, and should the platform provide an abstraction, so you've got a lightweight platform. That's now portable in kubernetes. Can we build that up the stack and make that just as portable as kubernetes it runs everywhere? Everybody gets the same experience. So.

A

Finally, what we're all here for is, do sto round of applause for sto, but you can give me that at the end, because if I, don't convince, you don't clap, so it's a micro service platform or service mesh, if you like to call it I call it a micro service platform that provides all those features, and the great thing is: if you're a developer, you need to know how none of them work you get them for free out of the box, which I'll demonstrate as an operator of the sto system.

A

You need to know how some of them hang together. It plugs into kubernetes, so kubernetes is incredibly versatile. We're talking about sto in the context of kubernetes, but sto is pluggable, so it can plug into cloud foundry. It can plug into messes. You can plug into kubernetes it it. It's completely detached, though, so that it's portable across you'll have the same experience across those different infrastructure providers, but it's not a silver bullet. It is, as Kelsey said, we can start building those next level platforms. It's looking at the problem above right.

A

How do we create a great developer experience in a micro, service-oriented world you with me? Yes, I need a yes, okay, so just high level features on the bulletin board. Here, traffic management, traffic management you've got ten features deep when I talk, traffic's management. This is how you're controlling your traffic flow inside sto.

A

So when we talk about that, we can do smart routing. We can do fault injection testing, so we can say please throw away ten percent. All these are PCs between services on given intervals. So we can look at how our application stack performs in bad times and start injecting that we can do ingress routing which we're all familiar with, but we can also do egress routing. So that's getting on and off the mesh. So I'll talk about that in a little detail, soon, metrics logs and traces who here is running any distributed, tracing fantastic, fantastic.

A

You get that for free, Yaga and Zipkin. So I'll show you how that works and security. So we actually can control em TLS, the developers don't even need to know. So we have that level of control to have mutual TLS under the hood on all our network, our pcs.

A

So now I'm going to change hat. That was lucky the starry-eyed little boy and that's SDO, but I want to go into now, I'm going to divide this sto for operators and sto for developers and we're going to get into the weeds a little bit here. So sto is a micro service platform that is itself a set of micro services, so these all run on the kubernetes cluster and they all have different functions. We're going to go through now.

A

So pilot the head of the ship: if I was to boil down sto and what it does, it is a distributed control plane for configuring envoy now, envoy, where's, many different hats and you've probably heard of envoy several times this week. Envoy is great like an envoy to nginx or a check proxy. It's just complete rewrite in C and it's highly condemned eclis configurable, where H a proxy and nginx. Traditionally our config file hub. You can have envoy connected to a distributed control plane and in the sto. That's actually what makes up the service mesh.

A

So what pilot is doing is the control plane for the Envoy instances, it's a system of record for the service mesh. So all the envoys are getting a single set of configuration from pilot that's distributed across there. It's abstract it form the underlying platform. So the way the system is modeled inside sto is extracted from kubernetes and we have what are called adaptive. So the kubernetes adapter knows how to read the system, a record out of Sto and model it onto that platform and when I say model it.

A

What it looks like under the hood is ingress --is and CR DS, so you're working with kubernetes native resources under the hood and that's where sto is actually storing its state, which is ending up, there's no other database other than that as its system of record. It has some very light: pluggable api's for service discovery, load, balancing and routing tables and there's a client that can actually plug in and you can change your routing, on-the-fly move canary things, black hole, things fault and Jack things, and these as I said it.

A

What we're talking about is dynamically changing the configuration of all the Envoy so talk about how envoy goes there so just to visualize this and I'm? Sorry, if it's not big for everybody in the back, I'll put the slides up. So basically you have the API over there to the left on the top. In the orange boxes, you have all the pluggable adapters, kubernetes mesos cloud foundries.

A

You have the abstract model, which is all the data and service types that sto need, and then you have the Envoy API and all your envoys are finding home to get the config right. So as the system changes it modifies, so Envoy is the distributed data plane.

A

Any questions on pilot keep moving. Okay, so envoy data plane it lives. Where does envoy live it lives as a sidecar in each pod? How does it get there? Well, there's two ways it can get there. You can use a tool to inject it which, if ever anybody knows a pod spec, you would inject a separate container, which is envoy or you can use an initializer.

A

So if anybody's used in initializer, you can have a pod, that's running inside kubernetes and you tell the kubernetes api before it accepts the request to shoot it over to that pod and that pod will actually modify the content. So it's actually putting that sidecar in on the user's behalf, so the user actually doesn't need to know that envoy is getting injected into their system. I'll demonstrate that soon it was envoy itself where's. A couple of hats. In the sto context, it serves as a sidecar for all the data coming in from all your applications.

A

It also serves as an ingress and an egress, so it's all running on voi, just with different configs right so envoy, even inside sto has many different roles.

A

Ingress and egress I think this is worth mentioning so everything's coming onto the service mesh or onto SDO via an ingress envoy is then planted. So envoy knows about all the other envoys and envoys communicate to on boys through their own mesh they've built a mesh, and your data goes down to your service inside each pod. External traffic goes out for an egress envoy, and this is important when we talk about egress as I've had use cases from customers, how do I get a stable public IP for all my traffic?

A

That's going out if I'm sitting in the public cloud behind a gnat or five different IP addresses how do I get it to come from this geographic location. This IP address with envoy egress routing. You can actually say everything from dev needs to go through that set of egress routers, which have these IP addresses, or these public identities and production another set. So you have a way that you can smartly move in a multi-tenant cluster, your traffic, mutual TLS. So in the early days, I think back when I was working with Jo.

A

We implemented something to do this. On top of our house, she caught bolt, but anybody who's tried to do this, you're not going to be proud of what you've done. This do actually makes this really simple.

A

So it's using kubernetes native primitives there's a CA, that's shipped with SDO that you can turn on or off, so you can enable this functionality, but each service, all their communication and M TLS session, will be established between those endpoints for each piece of communication and the lifecycle of all those certificates are managed by sto they're laid down as kubernetes secrets, and they have an identity per service. That's all handled without the user, needing no so under the hood.

A

There's that the CA watches for kubernetes service accounts then creates a key pair and dumps it in as a secret that gets mended in as into your pod, up into envoy and put in its config.

A

Mixer just to kind of round out the the operator piece. So mixer is the policy engine. So here's where you have all the knobs you can. You can turn so. We can take care of telemetry billing quota tracing access, control and mixer mixer mixer! Yes, do gives you what a long week some generic plugins, so you get pluggable adapters.

A

So the ones that are shipped with out of the box are things like Prometheus, but you could plug in any third-party tool and have sto fire a trigger and manipulate the shape and and how traffic is being routed across your mash. So this information I say the last piece. There is attributes so attributes because everything is going via envoy.

A

There's a massive ton of metadata about what's happening in the system and all this all these attributes get aggregated back up to mixer, and then you can do what I said any create handlers like a Prometheus handler. You create rules and config. So when I see this do that and modify the machine as it's running so modify the mesh real-time. While things are going, you can have human input or you may not have human input, and these are all Express expressed under the hood as C IDs right so again, we're not leaving the kubernetes api.

A

Okay I probably talked enough demo time demo time anybody want a demo yeah right, all right.

A

Okay, let me just get my screen back here so when I wanted to show, show you all- and let me know if you can see it's that big enough, the folks in the back, bigger, okay, all right fantastic, so it's do for operators I'm going to show you how to install this. Do so, there's no magic here, let's, let's just prove that to everybody cube kernel version I have a kubernetes 1.8 to cluster running here on on Azure and what I'm going to do actually to prove this? Nothing else.

A

Let's just show you that it's it's just vanilla here, I'm just right, just default cube system, stuff running right now, but what I'm going to do is use. How am I mentioned the helm chart there are installers upstream on the documentation. I will show you where they are I'm going to use helm. Helm just gives me a little more flexibility. So let me just show you how I would express this in helm, okay, so I'll grab this and I'll walk you through. What we're doing here.

A

Alright, so what I'm doing here is I'm doing helm install I'm telling it that I want to. Let me go to the command here. Sorry, I want to install the incubator in the incubator, repo of the upstream chart repo. I want us to install sto and I want to install 0.12, which they just released 0.3 last week, and I want to use the initializer which will go and take a look at in a minute. So what it is done, I'm doing this in two phases.

A

What it has done is installed all these CR d's that the east EO system relies on. So I mentioned them, so you can see a bunch of different types of configs here that can be expressed through CR DS, but all I'm gonna do now is just go back and until it actually to upgrade that and deploy, is, do the first pass.

A

I lay down the CR DS that it needs that a dependent in the second pass I actually go and install is do now, while that is happening, I will pop to this other window and what I should end up with is an sto system. Namespace.

A

Nothing yet so, let's watch that what I would expect to see is everything that I just spoke about. We should see a CA, we should see mixer, we should see pilot. We should see an initializer and a few other bits and pieces like Zipkin, Gras, fauna and Prometheus. So once this installs go ahead, so it takes a few minutes to install it's pulling down the source chart from the upstream repo unzipping it and then pushing the resources over to to kubernetes.

A

So, while that's happening, do I can take questions or I could move on any questions so far, I'll show you what we got just so happens that it passed.

B

A

Yes, so BYO kubernetes cluster on any provider or anywhere as long as you have a conform compliant API, you should be fine and I just installed it straight on I'm, putting it into the sto system namespace, but you can put it in any namespace. So what you can see here is I have the CA, the egress Agra fauna and ingress and initializer a mixer, a pilot, a Prometheus, a service grasp and a Zipkin, and that has just laid down the complete architecture.

A

It's very lightweight Sto, for all intents and purposes, is up and running the only other piece of information that I need is to complete this demo get service in the namespace sto system.

A

Ok, so I should have an ingress service here that will expose a public load balancer, so I should be able to get on and do that.

A

Ok! So let's go back to the demo here.

A

So now I've spoken about sto operators. Now that is all transparent of the folks that don't need to know that you know how the sausage is made. You know how it hangs together if you're an app developer. You may not necessarily need to know any of that. So as a developer, you don't need any of that knowledge so who here has never used this T Oh fantastic?

A

Who wants to come up on stage who wants to use this? Do I need a volunteer. Anybody come on up, come on down, give him a round of applause.

A

Can't get anybody up, they don't want what the prize is, but you're gonna be in for a surprise, all right. Okay, so I I have I'm gonna. Let you drive in a minute, but I have- and this is the one of the upstream demo, so you can go and recreate it at home book info Yammer, which deploys a set of micro services right. So there's no rabbits in this hat. What I would like you to do is take book info and put it on ISTE.

A

Oh okay, using cube cuddle so you're actually in that directory, and it should just be there so using cube cuddle. Can you please deploy something on sto that you just wrote.

B

A

I use cube, cuddle.

B

B

A

Okay, congratulations! You just supplied something to SDO I.

A

Think the magic is is now so.

A

Okay, what do we see here and without digging into all the amal that was there- is everything there were all single container pods there that we had set up, but we actually have two or two, and you see something important initializing, so I actually have the initializer running and, as I said, the request comes into the API server. It passes it to the initializer it's putting in envoy and then it's before it deploys. So we should get everything up and running. Eventually those two will come up, but just to prove what we've got here.

A

If we do a describe on that, pod I got to give it pod.

A

We should see that we have a sidecar here with Sto and it's running in proxy mode, so this is all transparent to the user. The gentleman that just came up on stage did it without any knowledge, he just used the standard tools and that has actually been applied now. What the gentleman that got up on stage here did not know is that he got a whole bunch more things as well, so as a user, what we can now do and I will pop back to my operator hat if you're using the helm chart.

A

It gives you a bunch more information here, but we can actually go and interrogate this app that he just deployed so I'm going to take the opportunity right now, just to show you the documentation and and I'm running through. Actually this demo right here, so you can go and dig in at home. Obviously they don't have time to go through it all right here, but what I'm going to do is just follow this documentation. All we did was deploy it and we did the automatic injection, not the manual.

A

So there is a tool where you can manually inject in the sidecar, so once we get this list of services, I should be able to in the misty Oh service in sto system right I now have it this public IP right, which is my ingress from public internet, to get on I'm just going to take this test. All I'm testing right now is that I can hit the this app that we just deployed and I'll grab this curl command.

A

So this is great because you'll absolutely know what to do when you want to test this out and actually trust that I wasn't messing around. So all this is doing is hitting that gateway, URL I'm, getting in 200 back. What I should be able to do here is grab that IP address and throw it into a browser, not that one. This one and I should hit.

A

Webpage was not founded, address did I grab the holidays.

A

Thank you yes got me.

A

A

There we go so we have an app that's rolled out. I am actually just kind of going through this curl in and a while loop here donate some traffic. So let's just do a while true do that space. Thank you. You can never type. When somebody watches, can you and I'll do a sleep asleep one done right, so I'm just running that in a loop to generate some some baseline traffic here now. What I would like to do is actually show you all. Those platform features that we spoke about earlier.

A

So if I do a helm, status, sta, so a helm will actually tell me a bunch of information around how sto has actually been installed on this cluster I'm, going to grab access to some exhilarate URLs tracing monitoring and logging and show you what we get out of the box with that application, and while that is going I.

A

Could probably grab grab the information here, so all I'm gonna do right here is show you, okay, yeah we're good.

A

So all I've done here is grab the dot. Vis and I'll show you what des is in a second I'm, just running a port forward through to the pod, so that I didn't expose it on the public Internet. So no, so what you see here is actually the dependency graph of the RPC is going through that application. So we see here, we've got some traffic coming in. We've got how many requests per second we're hitting this product page and then we're getting the reviews, and we have three different review applications.

A

At the moment we have a details and a ratings. So if I was to go back to the the UI, what those three different reviewers there's one with black stars- there's one without stars and there's one with red stars and because we have no route rules in at the moment, we're hitting all three of those different backends which a v12 and three of that review system and what you can actually model here is you can see those requests going to these three right so now, I have a dependency graph of my species.

A

That's given to me, without any knowledge, I just wrote the app I get this for free. Would this be useful to anybody? I think I think it I think I like it now. The other thing I want to show is: let's take a look at some dashboards here. I'll throw this in the background again it ships with out of the box a graph on our dashboard and all the data is being grabbed by mixer and placed in the Prometheus and graph owner is querying Prometheus.

A

So here we have a nice dashboard, I hope everybody can see. I can zoom in, but we can see how many operations per second, the response rate, how many 500 so I have a serving application. Here, that's running the the responses where we're hitting what the time source the version we get all this wealth of information coming out of envoy and mixer without the user.

A

Knowing anything about this right because envoy is intercepting every piece of traffic annotating it with attributes mixes, passing it and spitting out all this information, so not only do I have some baseline visibility. Now on my application, I haven't had to go and build it myself as the application developer. So these are all things that sto is giving you out-of-the-box. You saw me install it I'm not! This is not pre-recorded. This is exactly how it works now. The final, the final thing that I wanted to show at least from the backend, is in telemetry.

A

So for those for those of you folks that haven't used the distributed tracing yet the way that it works. Is you actually annotate all of your our pcs and you have these collectors that aggregate the data and push it back up now, because envoy is in path of all that you get distributed tracing so pick your distributed tracing of choice. Here we bundle up Zipkin, but as of last week or the last release, they have Yaga as well, so BYO tracing, I bundled up Zipkin.

A

So I'm going to show you what Zipkin can do and like this again, I should be able to can't find that all right, I'll do a little bit of open-heart surgery. Here, pardon me, I got a bad label selector right.

A

So, if I hit, this I should hit the Zipkin UI.

A

So I can say find all traces that went to product page. This always reminds me of you know the dev console. Excuse me the developer console in chrome, so you can see your whole waterfall as the RPCs traverse the system, how many milliseconds microseconds each call which path had hit under each API and how long it took to to service that request. Pardon me I'll, move this over right and if anybody has actually dug in and started looking into sure there's a wealth of information here and at 3 a.m. on that fateful Sunday morning.

A

I wish I had this information. You could see if you had a cache. Miss one service was misbehaving, but you now have your whole dependency graph that was generated off that one call to product page. We can see where this data is going who's serving it and when how it's being served.

A

A

Okay, yeah. Let me just repeat the question: if people are using other tracing mechanisms, is that going to be possible to plug it in? The answer is absolutely yes, because this is exposed by a mixer and mix it has pluggable backends, so Zipkin and yeah yeah I just plugged into that system. You just have to take the metadata and represent it in whatever tracing model. You need to represent it and it should work. So the answer is absolutely yes.

A

So that app only uses HTTP I need it's anybody go to lots of water. Nobody's got a glass of water, it's okay, yeah! Thank you! Save the day. um Pardon me um my voice. It's been a long week that app actually uses HTTP, not G RPC under the hood. So all the calls between envoys get wrapped in G RPC, but the transport underneath for the application this HTTP today sto supports our pcs in G, RPC or HTTP, only not any other custom protocol, but they're working on making that pluggable.

A

So if you have your own RPC on your own protocol stack so, but that app is all HTTP between the components.

A

A

Let me just repeat the question there's, so everybody can hear it. So if we have multiple environments, some on Sto others not is there any way we can span? That? Is that correct what you asked you actually answered it. You can throw envoy in anywhere and as long as it can connect back to Pilate, it has the information of the mesh and as long as you can have point-to-point connectivity to all the other envoys, the mesh will work.

A

So you can attach it to the same control plane from your previous infrastructure and not have it on kubernetes.

A

Just just a second somebody can I take you first, the gentleman up the back and then there was another question here. Yes,.

A

A

So you are you asking I, think the question as I heard it is, if you have multiple containers inside the same pod, will they all be subject to the authority of that? Yes, so on boy, under the hood actually hijacks the routing table inside the network namespace inside the container and makes it the default router. So all the traffic going in and out outside that and all the traffic in between it grabs as well yeah yeah.

A

Finally, just just to wrap up and I can answer some questions. After this there is an sto community. There are community meetings if you're interested in learning more I've. Just given you just a same baseline here, please go. The documents are great. I also have a bunch of links on things. I use you can hit me on Twitter and I also did a full demonstration on my youtube channel of all the components up and running.

A

I only showed a subset subset given the time, but if you want to go and take a look at all the components, you can take a look at your own pace, but I want to thank you, and thanks for joining I can take questions.