solo.io Product Demos, 25 Jul 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Simplify cross cluster communications on Istio with Gloo Platform

Description

No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).

A

So we have the bookinfo application deployed in both cluster one and cluster two, and right now.

A

We access the ingress gateway of cluster one and we get the product page running on cluster one.

A

And we did this by creating a virtual gateway and a route table to expose the application.

A

So what we're going to do next is update this virtual gateway so that it selects.

A

Both ingress gateways across both the clusters, so we'll select the.

A

Ingress gateway on cluster one and select the ingress gateway on cluster two.

A

And then, what we're also going to define what we call a virtual destination.? This is.

A

A way to group together, multiple services that are running across multiple clusters,.

A

And we can give it an arbitrary host name.... You know called productpage.global,, which is going to be.

A

Composed of product paid services that are running in the bookinfo front-end namespace in any.

A

Cluster because we didn't specify any cluster name here.. So when we create this virtual destination...

A

And I can go into the gloo platform ui and we can see the details of the virtual destination.

A

And you can see that it's discovered these two services...

A

Product page on cluster one and then product page on cluster two.

A

And what we'll do next is update the route table and instead of going to the cluster.

A

One directly, we're just going to route to this new virtual destination that we just created.

A

So once I apply this and I go back to my browser and if I hit the ingress gateway.

A

On cluster one,, I will get a round robin between product page on cluster one and then product page.

A

On cluster two, because I'm round robining between the two, because that's just the default behavior.

A

The other thing we can do is I can access these applications to the ingress gateway on cluster two.

A

And because I... because I created the virtual gateway to listen on both,, I.

A

Can go to ingress gateway on cluster one or cluster two and again, if I go to cluster.

A

Two I'll bounce back between product page on cluster, one and product page on cluster two.

A

So we can also see this behavior in the... in the gloo platform ui.. If we look at this graph,.

A

You can see all the various services, we can change this to show it by... by group by cluster.

A

So right now we see the different services and the different traffic. That's being..., that's flowing.

A

Between these services,, so we can see ingress gateway of cluster one sending traffic to product.

A

Page on cluster, one on the bookinfo front-end namespace on cluster one, and we can then see.

A

Product page talking to reviews, and then details and reviews talking to ratings and so on.

A

And we can now also see the second cluster.. We can see the ingress gateway on the second cluster.

A

And then talking to the product, page on... on second cluster and so on,, so we can really see.

A

The full picture of what's going on and see how traffic is flowing between all of your services.

A

So again, you know we'll pick the round robin default behavior,, but you know this might not.

A

Be what you really expected, you know, you might want to. You, want the traffic to always go to.

A

The maybe the local cluster first and then and then you can easily do that by defining.

A

An extra policy called a failover policy and then outlier detection policy.

A

Again, we can attach these policies to routes based on labels,, so we're going to apply the failover.

A

Policy to the virtual destination, using this label., we didn't put the label yet, so we'll have to.

A

Update the virtual destination, and we can say that we want to use locality to define the failover, so.

A

By default, it will try to find the local service first and if they cannot find one, then we'll try.

A

To find one in the same zone., if you can't find it there, it'll do next is region and so on.. We.

A

Can also be more explicit and say, you know,, maybe you will have one cluster in us east and one in us.

A

West and one in europe,, then you can say if us east is not responding, you want to go to us west. First.

A

Before you want to go to europe, for example., so you can be very fine grain here and you can also...

A

And we'll also define when you want to failover,, and you can do that using an outlier detection.

A

Policy,, where you can say you know, when I have two errors in an interval of five seconds,, I want to.

A

Failover for 30 seconds and then I want to try again and if it's not fixed yet then failover.

A

And so on., so let's create these policies, and then after it's done, I can just update my.

A

Virtual destination to add that missing, failover = to true label.. So now the two policies.

A

That I've just created get automatically attached to this virtual destination.

A

So now, if I go back to my browser and hit refresh over and over,, I will always get the product page.

A

On cluster one, because I because I'm going to the ingress gateway on cluster one., if I change this.

A

To the ingress gateway on cluster two,, I will always get the product page. That's running on cluster two.

A

If you look at this diagram flow,, you know this kind of represents what we're seeing right now,. If.

A

You go to ingress gateway, cluster one,. You will get to the product page on cluster one.. Everything we've.

A

Applied here we did it to the gateway,, but it also applies for east-west services,, so anybody in mesh.

A

Can call productpage.global and they'll get the same. Multi-Cluster failover behavior.

A

That we've seen in the gateway., so let's do some tests.. So imagine if we scale the product page.

A

On first cluster to simulate a failure,, so we'll run this patch command so that.... So it's.

A

Not running on cluster one,, so we're just scaling it down to zero.. So now, as you would.

A

Expect we'd want the ingress gateway to center product page on cluster two,. So let's go to the.

A

Ingress gateway on the first cluster,, but you'll see that I'm actually getting response.

A

From product page from cluster two., so that's one use case..., that's mobility.. We can decide where the.

A

Service I want to run.. If I want to move a service from one cluster to another cluster,, I can go ahead.

A

And do it. previously, without this functionality, if I moved a service from one cluster to another,,.

A

I'd have to inform the consumers the new address just to route request to,, but with.

A

Virtual destination,, I don't need to do that at all.. It's going to be automatic., it doesn't impact.

A

The consumer and the producer can decide when to move a service and where you want to..., they.

A

Want to move it to one from one kubernetes cluster, to another, to a different platform,, a.

A

Different cloud,, it really opens up,. You know, a lot of different use cases, because it's very flexible.

A

So now let's go back and fix the application so that it's so it's running again on cluster one.

A

And if I go back and refresh in a few seconds, traffic should be going back to cluster one again.

A

So, let's see something different., this time, the service is running, but it's not going.

A

To respond... it's that outlier detection, policy, right,, so we've configured it so that it.

A

Automatically failover, if it hits a certain number of errors. so again to simulate this,. We have this...

A

It's basically, we have this like patch command, so that it's not going to respond. Anymore.

A

So we wanted to still be running,, but just not respond. Anymore.

A

So, let's try this..., maybe give it a few seconds... looks like it's still running.

A

Maybe I did something wrong here,, so let me see if we did this correctly...

A

No,, I see the error message. yeah. I think we did it too quickly.. Let's go back and.

A

And do this a little bit slower., let's go back and run the the patch command again.

A

And actually wait for the deployment to come up.? Okay! Now we should be good.. So now, if I hit refresh,.

A

You can see now I'm going to cluster two, right., so even the product pages cluster one it's running.

A

In cluster one, it's not responding well, and it's doing this because I have a policy by default. I'm.

A

Retrying three times... istio retries, three times, and the failover policy will kick it out after.

A

Just two, so the first request: fails, istio, will retry two more times, that hits the three limit,.

A

And then it just gets bounce to cluster two. as a user, I'm totally not even impacted by this outage.

A

So now, let's activate...

A

Product page on cluster, one again, and after about 30 seconds,,.

A

It should go back and we should be able to hit cluster one again... there. It goes. We've hit the.

A

30 second limit, yep., so yeah very powerful.. The the key is that this architecture is superior.

A

To upstream istio's multi-cluster. in upstream istio multi-cluster,, you need to give the secrets.

A

To every control plane to be able to access the kubernetes api server of all of the other.

A

Clusters., this is not ideal and in just in terms of scalability, you can see that with.

A

Just four clusters: the number of communications that are involved,, but it's also not very secure.

A

Because if one of the clusters is compromised,, they can access the other cluster., but with gloo mesh,. We.

A

Use this agent that discovers the services and it's passing the information to the management.

A

Plane,, which is going to tell the management plane, that's going to tell the agent what objects to.

A

Create and to make the configuration to your desired setting. in our multi-cluster, cross cluster.

A

Case, gloo will create multiple istio objects for you, automatically. one of them is a service entry,.

A

So you can see the service entry for our virtual destination product.global,. It created the service.

A

Entry., it's going to first validate that the service of response is really the product page.

A

Service and not another service, and it's going to do that... and it's also going to select either.

A

The local workloads using this app product page,. So that's why we're seeing this like round robin.

A

Between the..., between the first on the cluster, one, the local service, and then the remote cluster.

A

The local service is selected here by this workload, selector, and it also selects a workload.

A

Entry that is created for you automatically for the remote cluster., so you can see that it has the.

A

Same label,. So if I look at the workload entry and look at the ip address of that, and you'll.

A

See this matches the ip address of the east-west gateway cluster two,. So if I look at cluster.

A

Two and look at the east-west gateway, you'll see that the ip address matches.

A

On cluster two,, it'll also create a gateway. Object., essentially, gloo will create all of these...

A

Istio resources... gloo will create all these istio resources for you automatically, so that compared.

A

To upstream istio, you know you, you see exactly what's going on., it creates a lot of operational.

A

Overhead for you..., it solves those challenges.. You just create rules.

A

On which service you want to create and expose them to multiple clusters, and you can see that.

A

Gloo has done the the overhead of creating all the lower level istio resources for you.