solo.io Gloo Mesh - Service Mesh - Deep Dive, 31 Aug 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Multi-Cluster Service Mesh Traffic Management

Description

Service Mesh Hub (SMH) is a control plane for multi-cluster service mesh environments. This video shows how SMH handles application traffic across multiple clusters of service mesh.

Questions? https://slack.solo.io
Learn more https://www.solo.io/products/service-mesh-hub/

DM us on slack to request a workshop or demo.

A

Hi everyone, that's our second video on this series. When we talk about uh multi-cluster service mesh, I'm doing general director of field engineering at solo.io like we started discuss last time.

A

There are multiple challenges when you want to deploy service mesh across multiple clusters, we already covered this need for federated trust and identity, and this time we'll cover uh this, how you all communication between clusters, how you can have micro services running on one cluster, talking to microservices running on the other cluster, and we will cover other challenges in the next topics like how you can manage access control globally.

A

This historical strategy, but everything here is complex, so we'll do one by one.

A

So on this multi-cluster uh we will focus on istio first, and we discussed last time that the shared control plane is not what is generally used and people tend to use more the replicated control plane because you don't need a flat network, and here we already discussed about this unique identity.

A

But now, let's discuss about how we can have one pod from one side talking to a pod on the other side, using the esteo ingress gateway.

A

To make that happen, you need to create a mini object like you will see like you need to create manually a service entry on the first cluster for each service on the second cluster. You want to be able to reach and we'll use the famous book info demo to highlight that, and we will just want the product page on the first cluster, to be able to send traffic to both v1 and v2, of the reviews, micro service on first sight and v3, and on the second site to make it happen.

A

You need to create a lot of things like we will go through more details, but you need a virtual service where you define where you send the traffic and then you need like a destination rule, then you need to create service entry to let your knows how to reach the service on the second cluster and also on the second cluster.

A

You need to create like multiple objects, so that everything is rooted correctly and we will show you that in the details uh when we go through the demo, so the service meshup we talked about it last time we introduced it. So it's aimed not to support any sto, but multiple service mesh technologies, app mesh is just around the corner coming very soon and others after and the service mesh up makes your life easier.

A

When you have multiple service mesh clusters, uh doing like the discovery of these multiple services, so it creates the service entries for you automatically managing access, control and simplifying the way you can manage the multiple source traffic like we will show you in the.

A

A

So here um you know we we have like the same environment. We used last time. So three cubans cluster, uh one where you have service mesh up, deployed, scan one and then we have kind two and kind three where uh we have like uh istio running so last time we went through um deploying uh service mesh hub and registering the other clusters, and then we deployed sto clusters using uh the operator so very standard deployment.

A

Then we deployed like the booking for uh demo application on both sides, but, as you can see on the second site on kind three, we have the three version of the reviews: micro services, while on the first one we have only one.

A

We did this unification of uh identity and that's very important because we we could not do the the part we do today. If we would not have done that so now, we can simply uh create our role, uh explain the way we want the traffic to be rooted. So, as you can see, we just say we want to send like 75 percent of the request coming from the product page to the review v3 on the kind series on the second cluster and the remaining requests.

A

We want to send them to the local cluster on the v1 and v2.

A

So we are just going to execute this request and that's the only thing we will have to do. Basically, all the complexity I described before everything will be done by the service mesh, so we just apply that and we go to our environment where we can access the product page and we just need to know which ip.

A

So, let's look at the ip of the istio ingress gateway service on kind 2.,.

A

So it's here, 172, 18, 0 220., just need to go to this page and we see that we have the red star. So it's the version. Three is the red star, so the value 3 is not running in this cluster, but you see that we are able to reach that service. That is on the other cluster, and we see that most of the requests are going there. Every time we refresh like 75 percent of the time we get that one.

A

We can also look at the the one on on kind three, and uh we have the three services running there. So there is no traffic rule for it, so that should just be like a random routing. So we see here we get each of the service. There is no real.

A

You know a lot less on the v3 as we expect, so everything is working well and as you've seen, we just created one object to describe what we wanted to do and everything has been automated by the service mesh for us.

A

So if you look at these objects, so we can go through that in a little bit more details. So we have this virtual service here that describe where we want to root the request and then the corresponding destination rules and service entries. So we we can start by looking looking at this virtual service, you see the ones called reviews- and you see here that there are these subsets and we see the three of them and we just need to look now at the destination rules and find the destination rule that correspond to this host.

A

So we see the host finished by kind sweet.global, because it's correspond to workload running on another cluster. So we can just look at this destination rule that define the subsets and generally define the subset with the labels of the local service. But when you have a global role, you have this special cluster label and basically you see cluster kind, three level, so we it will be used to select the right service entry and the service entry will be corresponding also to the same host and have this label. So let's, let's find it so again.

A

Just looking at the host to find the service entry and if we look at this object, we'll we should be able to to see the level and.

A

Yeah the label and you see as well the ip of the easter egg gateway on the second side, which is kind three, and we see the the corresponding cost and and the address has been automatically selected by service mesh up because it has to be unique for each service entry.

A

Now, on the second side, the request comes, and we have this uh android filter first, so we can go to the kind three cluster and we can take a look at the android filters and there is one: that's called virtual mesh service mesh herb, that's the one that is interesting. So let's have a look at that. One.

A

And you see here the rule at the end. Basically, we replace the suffix kind suite.global by cluster.local, so that when this is done, the rest of the routing is done like if it would be a local request coming from the product page.

A

So we will have like uh the destination rule, the local destination rule that defines the subsets that we are trying to reach. So we can take a look at uh the local destination rules. This time we we will not use the global one. We use the local one, but not that the global ones are already there already created by the service mesh herb ready to use.

A

So we could configure a traffic policy from this cluster to the first one very easily as well. So now, let's just have a look at this uh review, reviews destination rule and we can see then how the subset are defined and you see they are defined with labels traditional levels. These levels correspond to uh the labels of this the the service in the pod. So here it's really like the traditional uh way of doing rooting uh in istio, so we created all these complex holes.

A

Just by doing this, creating this traffic policy that simple, like just explaining expressing what you want to do in one object, and everything is done for you by the service mesh herb. So we've been through this challenge today, we will cover the remaining ones in the next videos. We hope you enjoyed it, but before we uh wrap up a quick review of our portfolio, so we have this service mesh up. That allows you to manage multiple, a simpler way.

A

We have our api gateway, that's called glue that is also envoy based and that can also be used instead of the steel ingress gateway, but can be used when you don't have a service mesh and you just want to have to secure the edge.

A

We also invest a lot in the web assembly. We know it's the the future of envoy to be able to people to create their filters easily. We we have this web assembly a project, and we also have like the developer portal that is available for both environments, where you have service mesh or when you don't have a service mesh. If you want to simplify the way your users interact with your apis, doing right, limiting and plans, and things like that, so we hope you enjoyed it and stay tuned for the next video.