 Cool, all right, thanks, Ron. All right, and as Ron said, this is multi-cluster service mesh, and hopefully you got to come to Lynn and Ron's earlier workshops and learn about Istio and deploying Istio for production. It's not necessarily a prerequisite for what we're gonna learn here, so if you miss those, don't fret about that. If you have some experience with Istio, this will still be useful for you. Who am I? As Ron said, I am a field engineer here at solo.io. I have a pretty long and varied background. Started in telecom, moved to mostly developer work. We've done a little agile coaching, and most recently helping our customers here at solo with service mesh and our glue products. You probably already heard about solo and who we are, so I'm gonna be brief here, but just know that we've got a virtual booth, we've got an in-person booth that's starting tomorrow, so we'd love to see you either virtually or in-person. We've got some nice giveaways there. So let's talk a little bit about Istio architecture. Istio, as you know, is going to help you with your distributed architecture. As you're moving to microservices or you want to deploy your services into Kubernetes, Istio is the glue that kind of binds together all your traffic that gives you things like service discovery, MTLS, being able to do fault injection, circuit breaking, retry, all this kind of cool stuff, right? But in reality, what we're seeing is when you go to production, you're not going to just deploy to a single cluster. That's typically just a proof of concept kind of thing. And most customers that we have today are hedging their bets against multiple vendors, and so they don't want to be stuck in just one cloud. Let me make this a little bit bigger. All right, and so we want to enable our customers across multiple clouds in hybrid environments, right? Things that you'll get with BlueMesh Enterprise are one, you're going to get a long-term support with Istio. You're also obviously going to get those multi-cluster operations. So when you want to deploy Istio and have a consistent configuration across those clusters, BlueMesh is the platform that will enable that for you, along with services such as global failover routing, or traffic shifting across clusters for multi-mesh. You'll also get role-based APIs that'll help you control how your teams interact with Istio across these clusters, and you'll get extensibility through WebAssembly, as well as our advanced filtering, and be able to see what's going on across meshes through a single pane of glass with our observability. And of course, zero-trust security is kind of top of mind here. Our version of Enterprise Istio, we always do upstream first, right? So if there's some kind of fix, we will always put it in the community, but we'll have specialty builds available as well. So if you can have some kind of special requirements there, we can comply with those. And we will also support critical security patches, and our SLA is quite fast there. So what are some of the common problems that you'll see when you go into a multi-cluster mesh? And I'll try to be brief through this so we can get to the workshop, as John says, we're short on time here. So one of those is going to have to deal with, dealing with your roles. You know, typically in a production environment, you've got several teams that have different roles that need to interact with your applications and your platform. And so you'll have, you know, ones that are providing the actual services. So maybe an account team and a user team. And then a couple of other teams, maybe an SRE team and a platform team that also need to interact with these same resources on your environment. You know, some typical things that your consumer teams are going to care about, are going to deal with things like timeouts, retries, locality, where load balancing and circuit breaking. Whereas some of your other teams, and apologies, the slides are going a little bit slow here for me. Like your platform owners are going to be worried about operational concerns or restricting communication across boundaries. Being able to, you know, do things like ensure that traffic is encrypted. Making sure that, you know, you have the right resiliency settings and high availability set there. The problem comes in that Istio doesn't really mirror these abstractions. Istio's API closely resembles Envoy instead. And so there's a contention here. What GlueMesh offers is abstractions here that make sense to these teams, right? So by directly dealing with resources like traffic policy or access policy, now we can administer all those lower level APIs through translations that the GlueMesh management plane provides. The other problem that we see is obviously just multi-cluster traffic, right? Multi-cluster traffic, you can't just configure every single cluster exactly the same. There has to be intention in how these resources are defined so that, you know, if you want to deploy, for instance, canary deployment of the review service here, V3 into cluster two and not cluster one, your traffic policies need to be aware of that intention. Likewise, if there's some kind of, you know, resiliency settings for outlier detection that causes a failover, there also needs to be intentionality of understanding what is the nearest locality to send that traffic. You know, so these are some of the common problems and we need to make sure that, you know, as we're administering a multi-cluster Istio system that we have the correct semantics in place and we're ensuring that our fault domains are correct and we're unifying identity across all of these, right? Istio upstream does have a way of dealing with this. Unfortunately, it's kind of an N plus one problem or an N minus one problem of needing access to the Kubernetes API of every remote cluster that needs to be managed. And so this is kind of an untenable situation. Like, and if you look at the way that GlueMesh handles it and it's taking a little while to refresh my screen here. There we go. Okay. Looks like it went past one. You actually escape out and get to the right. Here we go. We have a pull system. So we have a GlueMesh management plane and each of the remote clusters is running an agent which pulls the configuration for the local Istio. Okay. So we can avoid that problem. I'm gonna jump ahead a little bit just to save time. What I'd like to do now is to start into the workshop and if Eric or Adam or Rom has that URL that they can share with folks in attendance and this should be the workshop that we're taking a look at. And I'll try to make this bigger. So I know that there's been an issue with being able to see all the text and I'll hang on here and wait for you to get here. You'll notice that it does say 300 minutes. I don't think we'll be able to get through every single challenge here but this should at least give you a good flavor of what GlueMesh can do for you in a multi-cluster environment. And Rob, you can just let me know when it's good to move forward. Give us two minutes. Yep. Okay, well, you're good to go. All right, great. All right, so go ahead and hit start track. We're just gonna start with the very first lab in this and you'll see there's five here. We'll try to go fairly swiftly but please slow me down if the pace is too fast. It'll just take a couple of minutes for this to load. You know, this picture here, of course, we saw the slide deck to a little bit different looking but you can see, you know, all the features that we have here. If we end up getting to the last lab, we also have a feature that's not listed here which is our GlueMesh gateway. It's loading for the users that are in the room as well. All right, great. Now I feel like this is the part where I should have prepared some jokes but you never know how long it's gonna take to actually start this environment. So let me just prep you with a little bit about what we're gonna do here in this environment. So GlueMesh being a management plane is going to be installed into some cluster. And actually I have the start button now so I'll just click in there and start talking a little bit while we wait. So the topology is gonna be that we'll have GlueMesh management plane in its own cluster and then we're gonna deal with two remote clusters where we're going to deploy the GlueMesh enterprise agents as well as Istio, okay? All right, so first thing we're gonna do is there should be a GlueMesh license key in here and we can just echo to make sure that that's all provision correctly. Hey Will, can you zoom in a couple of times? Yeah, I will do that. Is that better or more? Okay, is that good? All right, thanks. All right, so just make sure you've got a GlueMesh license key. This stuff won't work without it. This is enterprise features. All right, so as long as that is set then the next thing we're gonna do is we're going to install the command line mesh cuddle and this will provide us some convenience factor with dealing with GlueMesh. We can also install it with Helm and just keep CQL. But there's also some nice features of mesh cuddle where we can do things like check on the health of our distributed mesh. All right, and then export the path so we could get to that mesh cuddle and now we're gonna pull down the Helm chart for GlueMesh enterprise and do the installation in the management plane. And so just a couple of things about this here. We are installing version 115 and we're also rolling out our enterprise networking pods here. So once we've accomplished that installation we're gonna get the endpoint for that enterprise networking pod because we'll need that when we register our agents on the remote clusters, okay? So we'll use mesh cuddle to register our agents and here's where the convenience of mesh cuddle comes into play. You could also do this with Helm. It's just a little more work on your side because mesh cuddle is doing some work behind the scenes to create those objects that are needed on the management plane. And we'll take a look at that, those objects in just a minute as soon as these get installed. The other nice thing about using mesh cuddle here is that you can get some feedback about the progression of the registration of the remote clusters. So as you saw with cluster one after it was registered it gave us some green check marks that tells us everything was good and they were registered with the management plane. All right. So that's succeeded. So let's take a look at what objects got created within the management plane. We have two Kubernetes cluster objects here. Cluster one and cluster two and these represent our two remote clusters. We also want to install some add-ons and this will install some extra feature sets into our remote clusters. And one of those is going to be the glue mesh gateway that we'll use later on. All right. So we just, all we've done so far is created the naming spaces for those glue mesh add-ons and then labeled them so that Istio will inject sidecars into those parts. All right. Next we'll pull down the Helm repo for the enterprise agent that's going to install onto our remote clusters. And before I hit enter here you'll see a few things that are being set as booleans. One is the enterprise agent enabled and we're going to turn that on just a bit. The rate limiter enables we have a rate limiter feature as well and then external auth service. And that's another feature that we have in our glue mesh gateway. So that was installed in both of the remote clusters. Lastly, we're going to use one of those glue mesh resources that we pointed down the slides so that the Istio ingress gateway can reach the glue mesh add-ons pods. So before I hit enter on this we can take a look at this in the bigger window. You'll see this is our access policy here. We are using a source selector of the Istio ingress gateway on both cluster one and cluster two. And then we're matching that against the glue mesh add-ons namespace as our destination. And so this opens up the authorization within Istio. All right, so now we're going to deploy Istio. Is there anybody that needs me to slow down or is pace okay at this point? Silence is golden. All right, we're good. So we'll pull down Istio cuddle so that we can install Istio. And now let's deploy Istio on our first cluster. The Istio operator for cluster one can be found in our files here. So if we want to take a look at exactly how we're configuring that this is probably a good way to take a look at that. Some of the key aspects of this Istio operator install for these clusters are one, we're establishing the trust domain within the specific cluster, right? So cluster one has a trust domain and cluster one. The other that we're going to take a look at is this envoy metric service. And what we're doing here is we're using the enterprise agent so that we can send metrics back to the management plane through that configuration, okay? And if you want to take a look at the Istio ingress gateway that's also there, all right? So we've done cluster one, let's go ahead and do cluster two. And while that's processing, we can just take a look at the cluster two YAML, it looks very similar to cluster one YAML but you'll notice that it has its own trust domain here but it's part of mesh ID, mesh one. So if we go back and look here, Istio operator for cluster one is also part of mesh one. All right, so those are done. So let's just check and make sure that our pods are ready in Istio system. First we'll check cluster one, now it looks good. Now let's check cluster two. All right, everything looks good there. Now what we'd like to do for when we deploy some of our applications is point to the ingress on cluster one. So let's grab that and put it in environment variable that's gonna be our endpoint HTTP gateway cluster one here. And then we'll also at the same time grab HTTPS endpoint. Right now it's time to deploy an application. We'll use the ever popular Istio example of Book Info. Should be familiar to users of Istio. And we'll talk a little bit about how we're deploying this to each cluster in just a second. But let's just check and make sure the running takes a little bit to initialize this. So while we're waiting for those to initialize, we can just take a look at what we did up here with applying our Book Info YAML. So you'll see the version not in V3 label here and that is corresponding to our reviews service. So you'll see on cluster one, we deployed only version V1 and V2 of reviews. All right, everything's up and running. So we can move to our cluster two. On cluster two, we're not gonna use that same nomenclature for labeling. And so you'll see version three is deployed as well. All right on each cluster, we're also creating the Book Info gateway and virtual service so that it's connected to our ingress gateway on each cluster. Let's just make sure things are running. All right, cool, that one came up a lot quicker. And if you wanna kind of a picture diagram of what we did there, this is a very nice display. So here we've got both ingresses exposed externally. You can see we've got Book Info, product page reviews, ratings and details deployed to both clusters. But the cluster on the left-hand side here only has versions one and two. Everything else is wired up. All right, so let's take a look at our new application that we just deployed. We paste this in here. We should be able to port forward to that connection. And then as you go up to the top of your Book Info tab, you should see the Book Info application. So if you don't see that there or try to hit refresh or just check to make sure that you port forwarded or didn't miss any steps. All right, so let me cancel that out. I'm actually gonna have that run. Well, we'll come back to that. If we need, we'll come back to it. So at this point, we've just done standard application deployment on to our remote Istio clusters. But what we'd like to do is take advantage of the fact that we have this management plane there. It could make some decisions for us that would alleviate some of the pains that we would have of managing each cluster individually. So we're gonna talk about the virtual mesh next. All right. Okay, so one of the things to see is that right now we're not running with MTLS at all. And if we inspect reviews V1 on cluster one, we can see that basically it's running without any certificates defined. So no MTLS. And we would like to fix that. Pure authentication in the Istio system namespace will enable strict if you put it in MTLS strict mode. And so we can ensure that our mesh is running with MTLS. We do that to both clusters. Now if we take another look at that same reviews pod, we should see our certificate that's been deployed. And you can see this is basically just the self-signed generated one that comes from Istio CA. So it has our cluster one that we had specified for our trust domain coming directly from Istio. All right, just to make sure that it happened on both systems, we can take a look at reviews on cluster two and we see our trust domain there for cluster two. So we verify that Istio is doing what it's supposed to do. All right. Now, what if we wanted the management plane to take care of this forest? So let's take a look at how to do that. So this virtual mesh resource, what that does is allows us to bind together meshes across clusters. So you can see here, we've got a virtual mesh resource. We are naming our remote meshes here, Istio D Istio system cluster one and cluster two in the blue mesh namespace. And for our MTLS config, we want them to have a shared root trust, right? So for this example, we're going to have the management plane create its root of trust and allow it to generate the certificates for the remote clusters. So let's just take a look at this picture of how that works here. So what's happening on the blue mesh management cluster is we've created a shared root here and we have CA along with a CSR that gets configured and pushed down to these CERT agents that are on our remote clusters through our enterprise agent. So now Istio D can utilize that to sign certificates for the mesh. All right, so now we should be able to see this actually take effect. Let's take another look at, let's take a look at one of the secrets that we've got in Istio system here. Okay, so one of the things you can see is that labels here is labeled by a blue mesh for cluster one, all right? And there is a CA CERT along with key and the CERT chain. And if we take a look at cluster two, we should see something very similar there. Now, what we'd like to do is see, did this take effect into our actual pods of running within Istio? So if we take a look at that, we've used V1. You know, you don't see that our issuer here is that same cluster one that used to be, right? It looks a little bit different. Now we've got blue mesh as the owner and we've got the corresponding certificate change that came from our secret. This next part, all right, so we're also going to compare with what we got on the second cluster here. You can see, you know, the same thing has happened on cluster two as well. Now what we'd like to do is do a little validation on the root CERT, right? So this one's a little tricky because copy and paste buffer is a little bit small for this one. So I think what we can do is just capture what we just got and send it into temp CERT, okay? And then we're just going to edit that. And if you don't want to do this and just want to follow along with what I'm doing, that's totally fine. And you can just see for yourself what this is going to do. So using OpenSSL, we can take a look at that CERT and inspect it and see exactly what it's got going on in there. So one of the things you'll notice here is this SAN or this subject alternative name is our SPIFI ID for the service account for book info ratings. And then it's specific to cluster two there. So we know we have identity within this certificate. All right, cool. So that is the end of lab one and how is everybody? Are they caught up and keep moving right along? So hit the check button at the bottom and then it'll take you back to the timeline where we'll move to the next step. We'll be able to keep up here for all good coupes. Cool, awesome. All right, shouldn't take too long to do that. The next lab is focused on access control. All right, so the previous lab, we basically federated a little configuration to create our virtual mesh and ensure that certificates were managed by the management plane. So in this one we're gonna focus on is the Istio access control but from our higher level resources. So one thing we need to do is to modify our virtual mesh quickly to enable this and this is kind of, I think very nice. If you're familiar with the way that Istio works natively in order to set up the policy where you're operating out of zero trust, you need to ensure that each application name space has an authorization policy that will deny traffic. Here we've got, as part of the virtual mesh we've got the easy button here which is our global access policy enabled. This will handle all that trivial task for you. So now we have that enabled and what we're gonna do next is we're going to verify that this is enabled. So take this next one and actually go to terminal two and let's paste that command in. Okay, so we can forward to our book info and now if you go visit book info you should see that your access is denied. So we know our access policy is working here. So now what we need to do is create access policies that will open up the path from our ingress gateway back to our application and also all the traffic that needs to go from service to service. All right, so let's start with the ingress gateway and the ingress gateway will need to reach to the product page. So for both cluster one and cluster two we're going to enable this for product page and note that in our destination selector we're not specifying a cluster. So it means it'll apply to both clusters. All right, just with that simple fix if we go back and refresh our book info page you should see now and it might take just a second for that configuration to be pushed out. You should see that we can now get back to our book info page but some parts aren't working. We can't get to the product details. We can't get to the ratings. We can't get to the reviews. Because we haven't enabled that access yet. All right, so our next task is going to be to turn that on as well. So here what we're doing is going from the product page on cluster one and we're going to enable access to details and reviews. And just should take a couple of seconds but if we refresh again now we get to see book details and we also see book reviews. Folks that know book info pretty well know that this looks the same as when you're going to reviews V1. Right, so just to make sure you can refresh a few times and you can see rating services currently unavailable. All right, so if we wanna be able to also see reviews let's add that as well. So now from reviews we're able to get reviews but we can't get to ratings. So we'll also enable that and refresh one more time and we now see black stars. So we should be alternating if you refresh a few times between no stars and black stars because we're going to the ingress on cluster one. All right, and which has both versions one and two there. We flew through that but we're actually through with that step as well. So if we want to move on, we can move on. And while this next challenge is setting up you can see that it looks like we're going to talk about failover. What happens when reviews is unavailable on cluster we'll call it cluster West. All right, here's where we start looking at traffic policy. All right, the first thing we're gonna do actually is just look at traffic policy from the standpoint of putting it in place some of Istio's fault injection. What we'd like to do is anytime that we go to version two of reviews let's add a little delay there. So we're gonna have a fixed delay of two seconds. Anytime we visit version two reviews. And so you'll say that percentage there is 100%, right? And now this will take a few, first we have to set our port forward but this will take a few refreshes potentially of our book info so that we can see when we hit the black stars it is gonna take a little bit for us to access that. All right, so there's V1, this is probably V2. Yeah, that was V2. And you can see it took just a little bit longer for that page to refresh. So we're hitting our fault injection there. So now that we've got fault injection in place what we can do is take advantage of that to check for some kind of timeout, right? So we can set up a policy and say that, all right. Anytime we go to the reviews and it's taken longer than half a second then our traffic policy here is going to kick into effect. All right. And now if we go back and press here, this might take just a little bit to start to see an error on the page. Okay, and there we got it. So sorry, product reviews are currently unavailable for this book. I think in an earlier workshop that we did when we were checking the Envoy config we got to see that there was like default retry of two, right? And so that could delay the being able to perceive this kind of error here. Well, let's go back actually to where we started this lab before we move on to handling multi-cluster traffic. Okay, so we'll remove both those policies that we just created. And now let me take a look at this diagram again. This is just kind of a reminder of our initial setup that we've got reviews V3 over here. We'd like to be able to route some traffic over here. And so now we're going to set up a traffic policy that allows us to do that. All right, let me copy this over here and then we can talk through this before we apply it. So here we've got our traffic policy and our destination that we're going to is the reviews application on cluster one. In this case, we're going to apply a traffic shift and most of that traffic, in fact, 75% of that we're gonna divert over to cluster two reviews, okay? And then we'll keep 15% or 25% here on cluster one between both V1 and V2. So let's apply that. And you'll see just how easy and fast it is to actually divert this traffic. Now, when we go back to book info and we start to refresh, you'll start to see. And there's some of our own traffic policies probably taking effect there still. All right, so actually what we're seeing is kind of curious. We're seeing rating services currently unavailable quite a bit, right? So maybe that 75% isn't working. So what's happening? Well, what's happening is we didn't actually open up access across the clusters. So when we've got our product page that's trying to reach reviews, we didn't allow product page to actually go and talk or sorry, reviews talking to ratings. We didn't allow it to talk across clusters. So we need to turn that on. So we go back here and take a look at our new access policy. Now, what we're gonna allow is book info reviews from either cluster is going to be allowed to talk to ratings on both clusters. All right, let's apply that. And now let's refresh again and hopefully we should see better behavior. We do. All right, we've got a red stars. So we know now we are diverting traffic according to the shift that we wanted. Okay, next we're gonna talk about traffic failover. And so this is kind of a variation on this multi-cluster traffic. So let's get back to our starting state by removing the traffic policy that we just created. Okay, and now that we've done that, let's just verify that we're not seeing red stars anymore. We should just be on cluster one. There's version one. There's version two. And I don't see any more red stars. So it looks like we're good back in this steady state. All right. And so in this instance, if you see our diagram here on the right-hand side, you'll see what we're gonna do is create a condition where reviews appears to be unavailable. Before we do that, we're going to create a virtual destination that's going to be applied as a global policy across the clusters. And you'll see here with this virtual destination that we have a host name that we've called reviews.global that we'll use throughout too. And this will be routed to if we see some outlier detection here, five seconds, consecutive errors here on the reviews application. Now that we've created that virtual destination, we can use that virtual destination in our traffic policy. And you'll see here that we have our normal destination selector reviews. But now we've got a policy added where we're gonna use that virtual destination so that we can use the outlier detection to go to reviews global. Okay. To test this, what we'll do is amend our deployment on cluster one for both reviews v1 and reviews v2. And we're gonna patch it so that it just sleeps for 20 hours. All right, each of those is patched now. We'll probably need to refresh a few times here on our book info and take a look at what's going on. But what I'd also like to do is on cluster two, let's take a look at what's happening with our logs and just make sure that we're actually hitting cluster two. Okay, so let me create some space there. And we'll go back to our book info. Let me just hit it a few times. All right. And you see that cluster two reviews just your proxy logs are actually printing out the hits that we got. So we know we're failing over traffic. So now that we've done that, let's go ahead and make it available again on cluster one. And this time it's gonna take 30 seconds. So let me just set my timer here. And once this timer is over, we'll inspect the Istio proxy logs on the review app within cluster one, refresh book info and make sure that our traffic is shifted back to cluster one. All right, cool. So let's take a look at our logs here. Boy proxy is ready. Let's hit this a few times. All right, and we can see that traffic has shifted back to our reviews app here on cluster one. Okay, before we move on to the next lab, let's clean everything up by deleting our virtual destination and traffic policy. All right, we should be square. And if you're ready, go ahead and click that check button at the bottom and we'll move to the next lab. Actually doing very well on time here. All right, this lab is gonna be focused on observability and what we can do to observe our mesh cross cluster. All right, so one of the common things that you'll need to do when you're looking for errors in the system or just wanna observe requests that are coming into your system is to make sure that you have accessible access logs, right? And we have a high level abstraction called access log record that we can apply in the management plane that will allow us to capture this. So let's take a look at how that works. We'll create first our access log record here. This is gonna be specifically for our reviews app. And note that there's not a cluster designation here. So this should apply to both clusters. And we're gonna use mesh CTL so that we can observe these logs. So mesh CTL is also extensible. We have a plugin system for it. So we're going to first initialize the plugin manager for mesh CTL. You'll see an error that comes up that it doesn't know the command plugin, but once we've gone through the installation then that problem goes away. So that's all right. And then what we'd like to do is actually install the access log plugin into mesh CTL. So let's also do that. And this access log does need to be tied to the specific version here. You'll see that version 115 is the one you want because that's the version of the glue mesh management plane that we are running. All right. We're gonna just send some traffic through our Ingress Gateway on cluster one. So we can see this in action. And then take a look at the access logs that were created through mesh CTL. All right. And you'll see that each of these requests that came through created this JSON payload of access log. You can see that it has a workload ref here. What cluster it came from. You can see that as well. Any kind of TLS properties that you had in there. Subject name, so your SAN is also recorded. Things that would be critical for you if you were trying to debug a problem with maybe a slow running app or maybe some backend access wasn't behaving quite well and these metrics would be very helpful there as well. Okay. All right, let's get everything back to square one. Then the next thing what we're going to do. So let's just delete that access log. We're gonna take a look at the glue mesh enterprise UI. Okay, so run our port forward so that we can get to the management plane dashboard. And then you can click on the tab here to take a look at what the glue mesh management plane can show you. So, first off on the overview of the management plane you're gonna see your health of your remote clusters. You're also going to see that you have one or more meshes that are deployed. And if you click on the mesh tab here you can see a little more detailed information about those meshes. So you have a virtual mesh config and it's across clusters one and clusters two here. We can also inspect things like the workloads that are configured against that or policy rules that we have applied. And if we had any kind of extensibility here with Wasm filters, those you could also see here. If we click on things like a virtual mesh details and this is actually a filterable field here. So if we just wanted to look at reviews, for instance, we could take a look at that and then click in to see the exact policies that have been applied. So we've got a product page policy here and it's allowed to hit anything basically on reviews. So feel free to play around in there a little bit. I will hang out here while you explore the glue mesh dashboard before we move on to our last lab. And if you have any questions, obviously you've got Rob and Eric there in the room. Adam is online to help with any questions they have. All right, cool. So the interest of time, I'm just gonna move on here to the last lab and you either follow along with me or keep exploring that dashboard. Okay, so for our last lab, what we're gonna do is explore some of the capabilities that we provide through our glue mesh gateway. Our glue mesh gateway is basically an enhanced version of Istio's gateway, where we add a lot of the feature functionality of an API gateway. And so you can do things like rate limiting or OIDC off integration, very, very handy. All right, so first thing we wanna do to take advantage of this thing is for now what we've been doing is just using Istio's gateway to expose our product page or our Book Info app. But what we'd like to do is take advantage of the glue mesh gateway. So let's take a look at first deleting the gateway and the virtual service that we had created for the Book Info. And now we're gonna create a virtual gateway. So let's take a look at that. What it looks like before we apply it. So our Book Info virtual gateway is going to have a virtual host that's attached to it. And it's using Ingress gateway selectors here on cluster one and cluster two from the Istio Ingress gateway that we had defined earlier in our Istio operators. So pretty straightforward there. Now we haven't defined the virtual host yet. So that's the next thing that we need to do. And what the virtual host is going to do for us is it's going to match up domain matching and any kind of path matching as well. Since this is our only application we have a very simple example here of just a catch all domain and path matching. But you could have something more sophisticated in your case obviously. Lastly, we're gonna use a route table. And that route table is going to be used by our virtual host in virtual gateway. And you'll see that we've defined a few specific paths here for our route table. So we've got product page and a few other URLs as well as the API that we expose in the back end. All right, let's go ahead and do that. Now we should be able to see that this worked if we go into terminal two and port forward to our Ingress. And you can see that Bookinfo is exposed with the refresh test to make sure. No, that looks good. So our virtual gateway, remember we deleted both the gateway and the virtual service that were existing there for SDS system created this virtual gateway, virtual host and route table combination. And that took the place of what was there before. Of course, you wouldn't run this way in production. You would have a secure website, right? So let's create a certificate for our gateway. We'll just do a self-signed certificate for now. And then we'll populate a secret in both the clusters with that certificate. And now we'll modify our gateway to take advantage of that. And the nice thing you see here is that we just have to go to one location now to take advantage of that configuration. So in the management plane we're creating our virtual gateway we're configuring our TLS secret that we just created in the remote clusters. And we're also specifying now because we're using that that we're gonna use the HTTPS port. And with this simple change, you'll see that it affects the remote clusters, right? So now let's go back to our terminal two here and we'll cancel our earlier port forward. And now we're gonna port forward to port 443 or secure port. If you go back and refresh here on Book Info, you'll notice that it doesn't work, right? But here, Book Info HTTPS, it does work. So now we know we have a secure route. We won't do this here, but you could also use the gateway of the second cluster. It's configured as well. If you wanna feel free to try that I'm gonna skip that part for now. What I'd really like to see though is being able to do multi-cluster traffic, right? So you remember in one of our previous labs we had a traffic policy that allowed us to shift our traffic across the clusters. So we're gonna put that back in place very similar to the earlier traffic policy that we had. This time it has a route selector. So it's taking advantage of our route table. And now we're actually going to apply that to our route table. So you'll see down here in the bottom are matchers for reviews. We've added it to our route table so the ingress gateway can also route to it and it's going to use this destination of these. Now, because we've done this way we need to make sure our access policies are opened up so that the ingress gateway can get to that. So let's also create that access policy. You can see here we're applying to both clusters and our destination selector is now our product page and reviews. Let's generate a little traffic against this. Okay, so we wanna see here is did our traffic shift work? So if our traffic shift worked what we should see is that we get ratings back with our red stars, 75% of the time and you can see that that is the case. Most of the time we're getting red so occasionally we get black, small percentage we get nothing back for this rating. So that seems to be working which is good. Okay, let's now go back from once we came by removing that traffic policy and we'll apply the original route table. And I'm aware that we've got like three minutes left so I don't know if we need to wrap up at this point. Can you take questions? Did you say wrap up, Rom? Yep. Okay, all right, fantastic. Yeah, we'll wrap up here like both of the other workshops we run our workshops pretty regularly so please go to our solo site events and take a look at when another one might be offered if you want to review what you saw today wanna get more out of it. And yeah, we look forward to seeing you there. So thank you to the helpers in the room and Eric, thank you Adam as well for helping out online. Appreciate everything. And thanks everybody for staying on and listening. Thanks a lot.