 Hi, this screencast is about getting up and running with an OpenShift service mesh. In this screencast, I'm going to show you how to install a demonstration application and then bind it to its service mesh and then control the application's behavior through the service mesh. The demonstration application is a fairly simple one. It's composed of three microservices. One is orders, and the orders microservice talks to a Kubernetes deployment named orders. And in turn, orders will make payments, and then when a payment is made, part of the response will be to get a recommendation along with the order return. The payment service uses a payments deployment, and the recommendation service uses two deployments. One is recommendations music, and the other is recommendations food. Now when the service mesh is first applied, what will happen is that the orders service, which uses the orders deployment, will get recommendations from both the food and the music deployments in a round robin fashion. However, after the service mesh is running, we're going to apply a destination rule. And the destination rule, what that will do is it will tell the recommendations service to use only a specific deployment. First we'll start out using only the recommendations food deployment, and then we're going to alter the destination rule usage to show the recommendations music data, data coming from recommendations music. So that's how it's going to happen, and you might have to refer back to these slides as you go through the video because there's going to be a lot of stuff going on, but pretty much this is what we're going to be doing. The steps, there's going to be 10 steps. It's a little bit of an involved video. We're going to install the OpenShift service mesh. Actually that's going to be happening already. We're going to have an OpenShift service mesh start installed at the start. Then we're going to create an application namespace, and then we're going to bind the application namespace to the service mesh. Now I'm going to go through the mechanics of that, but underneath it all the namespace has already been created and it's already been applied to the service mesh, but I'm going to show you the details of how that works. Then we're going to install the Kubernetes resources, and that's going to be the service for the orders and the order deployment, and then the service for the payment and the payment deployment, and then the service for the recommendations along with the recommendations food and recommendations music deployments. Then we're going to add a gateway to the OpenShift service mesh, and what a gateway does is it allows external requests to get into the service mesh. In number six, we're going to add a virtual service orders to the service mesh, and this is going to make it so that the orders is subject to the service mesh. That means that the service mesh will be in charge of the order service, and then we're going to apply a destination role to the service mesh. Then in number eight, we're going to create a new virtual service called virtual service food, which will be bound to the recommendation service, and that will return only back the recommendations from the deployment recommendations food. We're going to delete the virtual service food, and then we're going to add the virtual service music, so that only recommendation data coming back from the deployment recommendations music will be applied to the payment response. And I'm going to use Postman to show you all this stuff in action. OK, so that being said, the thing you need to understand, as I mentioned earlier, is that I did indeed install all the operators for the service mesh to the OpenShift cluster, and the way you do that is you go into the OpenShift web console and select the administrator tab, as you can see on the upper left. And then you're going to go down and you're going to select operator hub. And then from operator hub, you're going to select the operators that are shown in this diagram under installed operators. And that's OpenShift, the OpenShift elastic search operator, the Red Hat OpenShift distributed tracing platform, the Kali operator, the Red Hat OpenShift service mesh, which is indeed a service mesh. And also, if you want to use the web terminal, which we're going to use, you're going to want to install the web terminal operator, which will allow you to use a web terminal in the OpenShift web console. So that's pretty much what we're doing. The source code for this application is online, along with all the configuration files. And let me show you where that is. OK, so that's here. So if you go to Red Hat Developers Demo, you'll see a repository called Simple Service Mesh Demo. And in there, you're going to see the Kubernetes configuration files. You're going to see the service mesh configuration files. And also, you'll see the source code for the application itself. The application is installed as containers out on KIO. Now, I'm assuming that you sort of do understand a bit about Kubernetes, that you understand what a service is and what a deployment is and what a pod is and how a service finds its pod by using selector labels. You need to know that. And if not, you might want to go back and review. And then I'm not assuming a lot of knowledge about a service mesh other than understanding a service mesh is really a one-ring to rule them all approach to controlling applications in a Kubernetes, excuse me, in an OpenShift cluster. So given that, let's start. So this is indeed my OpenShift cluster. And in this case, I'm running one under Azure. You need to have a fully functional OpenShift cluster. That means that you have the ability to create namespaces and install operators. And in this case, you can see I have both operator and developer. The other thing I'm going to do is you can see here, I'm going to add a terminal window to run directly within the cluster. And this is going to automatically bind the OC command line utility to the cluster. So that being said, let's move on. So the first thing I need to do is I need to create the namespace and I'm going to use the OC command line tool to do that. And so I'll go to here and you can see I'm going to use OC create namespace demo. And I'm going to do that and it's going to get the saying I can't create it because the namespace already exists. That that's to be expected. That's not a server. When you run it from scratch on your installation, you'll say, oh, no problem. But in this case, I do have the namespace not only installed, but I also have it bound to the Kubernetes cluster. And the way I'm going to do that is I'm going to go into administrator view and I'm going to show it to you. I'm going to go to operators and I'm going to go to installed operators. And let me go down to OpenShift here and you can see here under OpenShift, there's there's a lot of a lot of stuff. OK, and you can see that I have provided APIs, in this case, ServiceMeshControlPlane, ServiceMeshMember and also Istio ServiceMesh member role. And what I'm going to do is I'm going to go and I'm going to go into the member role here. OK, and excuse me, do I have to create a member role? OK, I'm going to create the member role. I guess I forgot to do that. So to do that, I'm going to create the member role. And what I'm going to do here is I'm going to copy this and this is going to go out and create, use the member role out on the repository. And what the member role is, is once you define, you you bind the namespace to the member role, that means that the ServiceMesh can see the application. And we're going to install our application under a namespace called ServiceMeshDemo. So let's run this and see what happens. And it's thinking. OK, so let's go back here and let's see if we can go find the ServiceMesh role. Let's go to YAML. And if we go in, oh, but OK, sorry, I didn't do it happen. So I'm going to just do it right here. I'm going to say, OK, my membership here, namespace. Oh, I'm sorry, duh. No, here's the problem. I'm sorry, I do this all the time. So let me respond. You have to go into the Istio system. This is I do this all the time. Sorry. And because the namespace, the ServiceMesh is going to be running under Istio system. Sorry about that confusion. And if we go into here, you'll see that indeed, there's the ServiceMesh role, member role. So if we go to here and again, this is very important. And again, I apologize for creating the confusion, but all of the ServiceMesh is going to take place under Istio system. And when you run, install the operators, it's going to be installed under Istio system, that namespace. So if I go to ServiceMesh, member role, I go to default and I look at the YAML. What you'll see here is if I go down here, you can see that the members ServiceMesh demo has already been installed. I did that previously. Again, when you run the YAML file, you'll, this will happen for you in your instance. But this means now that the ServiceMesh is going to know everything about what's going on in that namespace and that namespace is ServiceMesh demo. So now I have the potential for configure, for binding the application to the ServiceMesh, but I have to create the application and bind it. So in order to do that, what I'm going to do is I'm going to get the, I'm going to get the source code from, I'm going to install, I'm going to clone the demonstration application from Red Hat. And it's under demo, simple ServiceMesh demo. Okay. And now I have the source code. And now what I'm going to do is I'm going to go into the working directory for the source code. And then what I'm going to do is I'm going to run in a shell script I wrote called app setup. And let's go back here and let me go into the source code and show you what I mean by that. I'm going to go KAS. And app setup, what it does is it's going to create all of the Kubernetes resources that we need in order to get the application up and running. And you'll see here that it's going to try to replace the service role. It's going to try to create the namespace. This will error out because the namespace has already exist. And then it's going to create the recommendations service and deployment, the payment service and deployment, the orders service and deployment. And then it's also going to return the route to the to the service mesh demo. But we're not going to use this route. This route will be ineffective because the service mesh will already have taken hold. I'll explain what that means. But let's go back to here and let me run the setup here. I'm going to go paste. Oh, sorry. Let's go to here. Let's see what happened here. Let me go to simple service mesh. There you go. Okay. Okay. Let me clear the screen so that we have a little more real estate to work with. And then we go to LS. Let's see if it's there. Do a little typing. Yeah. Excuse me. Then I got to see you. Show you what I know. I've got to go to K8S. Okay. Let's go to LS. Okay. And there is app setup. So we'll go SH. Okay. And you can see now it's going to run the setup script. Okay. Okay. So now let's see. Everybody should be in place here. Okay. So we're saying everybody here is created. Everybody here is created. And so let's go into developer mode here. Developer view. And you can see here. Here is this is in the Istio space. But let's take a look at service mesh demo. And you can see here's everybody. There's here's orders. Here's payments. And then here are here is the recommendations food and recommendations music deployments. And then also what we'll do is we'll go back to administrator just to make sure everybody's happy we'll go to administrator and we'll go to operators installed operators and we'll go to Istio service and we'll go down here. We'll go to service role and we'll take a look at we'll go into the default and we'll take a look at the YAML and you can see that there's the service mesh members. So everybody is set up just hunky dory. Now one last thing we're going to do what we're going to do is we're going to do OC get pods and I'm going to get the pods by the namespace service mesh. Oops. You need to learn type over the weekend demo. And what you can see here is the pods the deployments were initially configured to run only a single pod in each deployment. However, if you see that there's two containers in each pod. OK. And what that second container is that second container is a sidecar container that the service mesh injected into the pod. And it's actually an envoy container. And what that can sidecar container does is that's the means by which the service mesh talks to the deployment. So instead of Kubernetes talking directly to the orders or payments or recommendations, what happens is Kubernetes talks to the service mesh, the service mesh talks to the sidecar container and the sidecar container talks to the deployment. That's how control is exerted. So right now we have the containers deployment up and running and the the sidecars have been injected. The next thing we need to do is install the gateway and the gateway is the mechanism by which requests make their way into the service mesh. And if we go into here, you'll see here, there's a gateway and this is the gateway we're going to execute, but pretty much it's a gateway. We're going to put it take take a look at anything in service mesh demo, use a default gateway that gets shipped with the service mesh and anything coming in over port 80, send that into the service mesh. That's what that's about. So let's go to here. Let me give yourself a little more window. And then let's go grab the YAML. We'll do that and let's put that here. There's the YAML and we'll see here. And now we've created the gateway. However, the gateway that lets you into the service mesh, but there's really nothing there once the requests arrive. And in order to put it there, there, we need to create a virtual service. And in this case, we're going to create a virtual service called order. So let me go back into the sort of the configuration code here and we'll go to and this gets this is the orders. This is the YAML file and what this is saying is saying, OK, here's a deal. Anything that comes in on the root of the request, any request, what to do is port, direct them, route them, send them to the orders host. Now, in service mesh parlance, a host translates into a Kubernetes service. So in this case, what's going to happen when a request comes in at the root, what the gateway, what the excuse me, the virtual service is going to do is it's going to send it to the Kubernetes order service going up against port 8080. That's what's going to happen. So let's go back to here. Let me grab the command, the OC command. Let me clear the screen so we have a little more real estate. OK, this is the OC command that's going to execute. And now you can see the virtual service has been created. What this means is that now the request can come in, the virtual service is looking, oh, there's a root request, I'm going to accept that and push it on to the orders host, which in KAS is the order service. And if remember the order service, what it's going to do is any request coming in, it's going to submit to the payment service and also to the recommendation service. And upon return, the recommendation is going to give a recommendation text. So let's see if that works. Hopefully. So what I'm going to do is I'm going to go to postman here. And this is my postman instance. And I have a little post going on here. OK. And what I have here is let me go to body and you can see here I have a simple post and it's going to go to Barney Kelly. It's simple. Post this this is how the post supposed to go in and it's just going to send an order in with order information credit card product ABCDFJ. So let me go send it. And now you see I got a 200 a 200 return. This is successful. And what it's saying is it's giving the product and the credit card number. And then if you look, you can see a recommendation came back and that recommendation says buy more nuts. And I just happened to know that comes in the recommendation food service. So that's that's the response. And then if we go to get the get value and I send it, you'll see here, by the way, this is all of the orders that have been placed in the service. And you can see there's by some more recommendation excellent nuts. So effectively what we've done is we've put this layer of inspection on the service mesh through the virtual service called the orders and request comes in the virtual service order says oh request coming into the route. I can see this. I'm going to pass it on to do Kubernetes order service and let Kubernetes have its way with it. So that's one thing. All right, that's done. Now what I didn't show you had to do and I'm going to do that now is I'm going to show you how to get the actual URL to call of the service meshes URL so you can call make a request to make a call. Sorry, I got a little fumbled on words. And the way you do that is you use the OC command Istio system get route. And this is very particular to my installation of OpenShift on my platform, which in this case is Azure, I put that in. And then you can see this is this is indeed not this thing here, but here is this is the route I've been using. And so if I go back to postman you can see there's the route there. That's just a nice you need to have that you need to know that the service mesh will publish its own route and the way you're going to get it is to use this command here. OK. All right, that's done. Now the next thing we're going to do is apply a destination rule. And what a destination rule does is it sets up some routing rules for lack of a better term. So let's go back into the source code and look at the destination rules. Go to service mesh and we'll go to destination rule. And we'll see destination rule here says OK, I have a virtual type kind destination rule and I'm going to apply this to service mesh demo. And then what it's going to say is here's the spec. Any this rule applies to any host recommendations. Any host recommendations translates into the kuminetti's recommendation service. And then I'm going to name the rule by a resource not it's called an attribute called subsets. And in this case, the destination rule has two subsets. One is named recommendation food and recommendation music. And these names they're arbitrary. They're just fundamentally arbitrary. I just named them the same as the deployment sort of so that they made sense. And what this is saying here saying OK, whenever you see a request that gets eventually ported to the underlying recommendation service, apply the label version food, in this case, recommendation food, or if we're using the rule recommendation music, apply the the label version music. That's what the rule does. However, in order to enforce the rule, we're going to have to make a virtual service that uses the rule. And I'm going to show you how to do that in a minute. But right now what I'm going to show you is how to apply the rule. So let's go back. Sorry, what happened here? That's strange. OK, let's open up. Let's see what happened to the terminal. Oh, it's down here. Oh, there's the terminal. Sorry, I got a little lost. All right. So let's apply the destination rule. So go to here. Oh, sorry, typo. OK, forgot to put the L ready. Here we go. There's the L. OK, the L then. Sorry about that. OK, let's put that in. OK, so now we've created the destination rule and the destination rule is out there, but it doesn't do anything yet. In order to make the destination rule work, what we need to do is to create a virtual service that uses it. So let's go back into the source code to go back to service mesh. So let's take a look at virtual service food. We're going to create that. And what virtual service food says, OK, go into the namespace service mesh demo and then find the host recommendations, which translates into the Kubernetes service named recommendations. And we're going to apply a route based on a destination rule. And the destination rule says, OK, go find the service recommendations, the host recommendations, and go use the destination rule recommendations food. Now, there's a lot of conventional logic in play here. Sorry, I apologize on behalf of the service mesh. But remember, the service mesh food recommendations food was defined in the destination rule here under the subset. And this is really a subset name recommendation food. So if we go back here, we go back into it and I look at the virtual service, it's going to create a virtual service mount recommendations. And it's going to go out onto the service mesh and look for a destination rule that has a subset name recommendation food. That's what this is going to do. So let's do this. Let me go. Now let me apply. Let's create the search. Let's create the virtual service. So I'm going to create the virtual service. I'm going to leave the L on at the end so we don't get errors. OK, the virtual service has been created, OK? So what this means now is that any request to orders and then delegates down to recommendations is only going to use food. So let's test that. Now, as you might recall, I said that until a destination rule is applied, what will happen is that the order service will feed up recommendations on a round robin basis, alternating between food and music. And the first time we did it, it was food, all right? So typically we should expect if indeed the destination rule wasn't applied, we should expect filtering between food and music. So what I'm going to do is I'm going to change this. I'm going to call it Bobby. Oh, excuse me. I've got to go to the post. Let's look at the post, Bobby, here. And I'm going to change data a little so we have something easier to keep track of. I'll change it to Bobby Kelly. OK, and I'll just do a little cut and paste magic here. OK, and the food I'm going to eat, we'll let Bobby use Jerry's credit card. Why not? Life short. All right, so I'm going to send this 10 times just because I can. I'm going to go one, two, three, four, five, six, seven, eight, nine, 10. And then I'm going to go back to the get. I'm going to get all of them. And now as you can see, I have a whole boatload of orders that have been processed. And you can see all of them are returning recommendations from the foods, in this case, by some more excellent nuts. OK, this is the food recommendation, food only. OK, that's good. So effectively, what I've done is I've applied a destination. I created a destination rule that has both recommendations, food and recommendations, music filters for those. And then also I implemented it by creating a virtual service for the recommendations service. I know it's a little bit confusing, but I created the virtual service recommendation, which sort of takes over the recommendation service under Kubernetes. Now, the other thing I do need to point out and this is somewhat this is important because you need to remember about how selectors work under a deployment. So if I go back to my developer mode and I go into service mesh demo and I take a look at the recommendations food, excuse me, I want to go look at the deployment, my fault. Let's take a look here. I go to topology. Let's go to here. Let's take a look at the deployment. And if you look at the deployment, in this case, there are two labels, application recommendation and version food. And this is for the deployment for recommendations food. And then if we go back and take a look at the deployment for recommendations music, you'll see that the selector ships with two labels, applications, recommendation and version music. So food has music, excuse me, music has app recommendations, version music has their labels. Food has app recommendations, version food has their labels. So what is the relevance here? So if we were to go back here and we'll go back to the command line because it's a little easier. Let's go to the command line here. It's a little easier. And if I go to get, excuse me, OC get services, and it's in the namespace, sorry. And if we were to take a look at the recommendation service, so what I'm going to do here is I'm going to go OC describe. Okay, if we were to look at the selector for the recommendation service, you can see it only has one selector label defined and that's app recommendations. So the Kubernetes recommendation service is going out into the cluster and say, give me pods that have the label app equals recommendations. However, the destination rule is applying another label. And in the case of recommendations food, it's applying the label version food. And in the case of recommendation music, it's applying the label version music. So what's happening is the service mesh is injecting labels into the service definition of the virtual service. I know that's a lot to go on and if you're not really familiar with Kubernetes selectors, it's a little hard to grasp. But the important thing to understand is that you create the rule and the destination rule and you apply a destination rule in a virtual service. And in this case, we have a virtual service that's filtering on recommendations food. What we're going to do now is we're going to take away the recommendations food virtual service and we're going to apply the one for music. So the first thing I need to do is I need to delete the virtual service for food. Let me clear this. Okay, that's gone. There's no more virtual service or food. All that filtering's been taken off. And now what I'm going to do is I'm going to apply the virtual service for music. And before I do that, let's just go back here. Let me review and go virtual service music. And it's saying, hey, go look for pods that have not only app recommendations and that's there implicitly, but also for the injected labels that are defined in the subset. And if you might remember, the injected label is version music. I know, not going on. You might want to go back and review this video a couple of times just to keep track of things. So let's go back here and I'm going to now apply the virtual service. Notice the spelling is correct now. Hit enter. Okay, good. So now that music virtual service has been applied. So let's go back to post, man. Okay, and let's go to my post. In this case, I'm post and we'll make another one. And we'll call it Betty Kelly just because we can. Okay, and we'll go here, Betty. Do a little cut and paste magic here. Go Betty. Okay, we'll make Betty, Betty. And in this case, we're going to say, oh, this product is a music. Okay, again, this is arbitrary. There's nothing, this is nothing that you have to do. And we're going to make, we'll call this guitar strings. Whoops, just because we can. Okay, so maybe I should learn how to type over the weekend. All right, so Betty's buying some guitar strings and remember now the filter for recommendations music is in play. So I'm going to send one. Good, 200. And let me, let's see what happened here. Okay, oh, that's a music recommendation. Buy another album by the Temptations. And let me send 10. Remember the contract was no more robbing. Everything is going to be filtered according to music. So we'll go to here. We'll go to get, I'm going to send, get all of that. There's the old recommendations for food. But if we go down now, we'll see, oh, by the way, all of these orders are now filtered to use recommendations music. There you go. I just bought 10 guitar strings, guitar strings over and over again. So there you have it. That's really pretty much as it goes. So let me just bring up the, this diagram again. So we're very clear about what happened. So what happened was I created a gateway. Okay, and the gateways are reflected as this gateway URL. And I told the gateway to take any incoming requests to port 80 and forward it on to the virtual service orders. And underneath the covers, virtual service orders uses the Kubernetes orders service which in turn uses the Kubernetes orders deployment. Then what I did after I exercised general orders around Robin fashion, getting back music and food and music and food and music and food, I have created a destination rule. And in the destination rule, I created two subsets. One is called version food. The other one's called version music. Not called, the name is actually recommendations food and recommendations music, but I define the labels version food and version music. Then what I did is I applied the virtual service named virtual service food. Virtual service food is going to go out and look for the recommendation service. And then it's going to inject the labels defined in the subset recommendations food. And in this case, the label is version food. And as you might recall, only the deployment recommendations food supports that label in addition to the originating label of app colon recommendations. Then what I did is I deleted the virtual service or virtual service food, reapplied a virtual service for virtual service music. And then I executed postman to get, to send orders for some sort of a musical item. And I got back recommendations for music as defined in the virtual service music, virtual service. I've never repeated myself. All right, so there you have it. This is a lot, lot going on. It is confusing. I know it took me a while to say, oh, now I sort of get it. So what I recommend doing if you have a chance, just go back and review this video informally, take some time and spend some time in the manifest files and in the source code so you can get a sense of what's going on. Thanks for taking the time to view this video. I hope it helped you understand OpenShift service mesh a bit better than when it started. Thanks for watching.