 Hello, everyone. My name is Phil Gibson. I'm a senior program manager at Microsoft working with our upstream open source projects. In this session, we're going to talk about Open Service Mesh. Open Service Mesh is a lightweight, extensible cloud native service mesh that you can utilize to quickly secure the communications of your services running in the Kubernetes environment. OSM takes the approach of providing a simple way to get the core features and functionality needed. Without overcomplicating the operational experience to secure your cloud native workloads. In the following demo, we're going to show you how you can easily enable the OSM add-on to an AKS cluster and configure it to protect existing services running in the cluster. We will first be deploying a sample bookstore application to the cluster. That will deploy out two initial services shown here as Bookbuyer and Bookstore v1 service. The Bookstore v2 service will be deployed later in the demo to showcase the traffic split functionality. The Bookbuyer service will begin communicating to the Bookstore v1 service once deployed. Next, we will enable the AKS OSM add-on to the cluster, and it will default to allow permissive traffic mode, meaning no communication enforcement rules will be deployed by default. This is to ensure that your application continues to run as is with no interruptions. We will then onboard the Bookbuyer and Bookstore namespaces for OSM to manage, which will allow the Envoy Sidecar proxies to be injected alongside your application's container in the pod. We will then verify that the Bookbuyer can still communicate to the Bookstore v1 service, and then once we verify that, we will then change the permissive mode of OSM to be equal to false. In return, we should see from the logs that the Bookbuyer will no longer be able to communicate to the Bookstore v1 service. Next, we will deploy our SMI traffic target policies, which will instruct OSM to allow traffic from the Bookbuyer service to resume communications to the Bookstore v1 service. Finally, we will deploy an SMI traffic split policy that will split and weight the amount of traffic from the Bookbuyer to both the Bookstore v1 service and Bookstore v2 service. The first thing we'll do is in Azure, we'll go ahead and create our resource group that will house our AKS cluster, and we'll create that in the East US2 region. Then next, we will deploy a brand new AKS cluster into that resource group, and that will kick off the deployment, and we'll give it a second to complete. We're completed. Then simply, we're going to just get our credentials to access the cluster for our CUBE control, and we already had this in the Qtfig file, so we'll just simply overwrite it, and then we will check our current context to ensure we're on the brand new cluster, which we are. Then next, what we'll do is we'll just list all of the AKS add-ons. Again, this is a brand new cluster, so we're not expecting anything, so this should come back as an all. Now we're on to deploying the Bookstore apps. We got three manifests or YAMLs that we're going to deploy. The first one is going to be the Bookbuyer. The second will be the Bookstore service, and the last one here is going to be the Book Warehouse service, where books are being retrieved from. Next, we'll just take a look at all of the components in our Bookstore namespace, and we're just verifying that we do have pods up and running with services here. Then what we're going to do is we're going to trail the logs of the Bookbuyer pod here. We'll go ahead and query to get it, and then what we're going to do is just tell the logs coming out of the Bookbuyer to ensure that it is talking to the Bookstore service, and here we'll stop the log in. You see that, yes, we are connecting to the Bookstore service, and we have our 200K, and you'll notice the server is in a, and so when we deploy the Envoy site, our proxy, you'll see that change to Envoy. Next thing we'll do here is we'll go ahead and enable the OSM-AKS add-on, and that's been enabled, and what we'll do is we will just query for that specific add-on to ensure that it is installed onto the cluster, which we get a true back, and so the next steps what we're going to do is do a light test just to see and ensure that the OSM add-on is correctly installed and functioning. So we're going to take a look at the pods for the OSM controller. It's up and running. We'll then take a look at the services here in the KubeSystem namespace, and you'll see that there are three. We have an OSM config validator, an OSM controller, as well as the OSM injector, all part of the OSM add-on service. And then finally here, we're going to query, there's a configuration config map, and one thing to notice here is the permissive traffic policy mode setting. We will be changing that setting, showing how the access works for the OSM service mesh. Next thing we'll do is we will need OSM to manage the namespaces, so we're going to add these namespaces to OSM to be able to manage. And then what we'll do here is we will now start the Envoy Proxy SICAR injection. So first thing we'll do is we'll take a look at the pod for Bookbuyer. You'll notice that it's a one-of-one ready state, meaning there's only one container in that pod. What we'll need to do to get the Envoy SICAR injection is to restart all of the deployments in those namespaces. So we'll kick off the Bookbuyer, we got the bookstore being restarted, and finally we will restart the Book Warehouse deployment. And since we have all of those restarted, now what we can do is we can go back and look at the Bookbuyer pod, and now you see that it has a ready state of two-of-two, meaning that that Envoy SICAR has been injected next to our application container, and we can quickly view that. Let's query to get the Bookbuyer again, and then we'll do a describe on it, and we'll look at both of the containers that make up that pod. So let's scroll up and the first container we'll see here in the manifest is our Envoy container. And if we scroll up a little higher, we'll see our Bookbuyer application. And then again, since we are in permissive mode, let's go ahead and just check to see that the Bookbuyer can still communicate to the bookstore service, which it can. And so we're seeing now the Envoy setting here, that that communication is being transverse through the Envoy SICAR proxy. And then we'll take a look at the config map configuration, and we'll go ahead and actually change the permissive traffic mode policy to FOSS. So that's gonna require a specific policy for OSM to pass that traffic, and we'll just verify that that setting was set to FOSS. And so now we're gonna need a specific rule for OSM to allow traffic in the mesh. And if we go back and we tell the logs of that Bookbuyer, part again, we will see that the communication has ceased, the Bookbuyer can no longer talk to the bookstore service. And what we'll do is we'll now enable that communication and restore it by deploying a SMI traffic access policy. And so we have our policy now deployed. And if we go back and take a look at our containers, I'm sorry, our logs from the Bookbuyer pod, we now see that we can now access the Bookbuyer. The Bookbuyer can now access the bookstore service with the SMI traffic access policy. So now we're gonna showcase the traffic split. First thing that we're gonna need to do is actually deploy that additional bookstore V2 service. So there's just an additional service out there. And that will all automatically contain the SMI traffic access policy as well. And then we will deploy our traffic split. And what you're seeing here is we're going to instruct the Bookbuyer to talk to both the bookstore and the bookstore V2 service. And we're gonna wait those two communication channels one 25% of the bookstore. And then the other is 75% to the bookstore V2 service. So we will apply that SMI traffic split policy. And now what we can do is we can tell the logs specifically looking for the identity. So this is the identity property is gonna actually show us which service that we are talking to. And what you're seeing here is the output. We should see more bookstore V2 services since we do have it weighted 75% more than the normal bookstore service. So that was a quick demo showcasing open service mesh providing some of the most common functionality needs of a service mesh. In summary, open service mesh is a robust service mesh utilizing the Envoy proxy. OSM provides a simplified operators experience for the most common set of service mesh features and functionality. And finally the AKS OSM add-on provides a convenient setup that will provide a fully supported service mesh as part of the AKS service. If you're ready to try out OSM in your environment please visit the documentation regarding the AKS OSM add-on preview. There you will see additional tutorials and scenarios. You can try out such as ingress configurations as well as some observability and tracing options. Thank you for your time viewing the session and I hope you venture out and try open service mesh in your environment.