You. Hello everyone, my name is Mohammed Azmil. I'm the founding engineer of imesh. Since past few years I've worked on various cloud native applications ranging from high performance backends to blockchains to full stack apps. With imesh, I help enterprise adopt Istio into their large scale production workloads. I'm very thankful to Con 42 for having me here, and today I'll be discussing on ambient mesh, which sync is the new sidecarless and faster istio for zero. Trust a bit about imesh. We formed in 2023. We offer enterprise grade istio support, and we also offer a dashboard called Imesh Dashboard, which you can use to monitor your istio workload with a mission to simplify and secure your microservices in the cloud. In today's session, we'll be having a look at understanding what is istio service mesh? What are the limitations of the existing service mesh, and we'll be understanding what istio ambient mesh is all about. What are the security and other benefit that it comes with. We'll be having a demo as well where we'll be using istio ambit mesh with mtls. We'll be applying l four and l seven authorization policies, do traffic management and do observability with open source tool that come with Istio, and a lot more. So we have quite a lot of meshes to cover, and I'm sure it's a tongue twister for you as well. So buckle up. And here we go. So in istio documentation, you can find that a service mesh is a dedicated infrastructure layer that helps you add capabilities like observability, traffic management and security without adding them to your code. So for someone who is not aware of service Imesh, it's basically a layer. It's kind of like a pluggable layer, which you add while you're deploying your workload so that you get observability, traffic management and security out of the box. Let's have a look at istio service mesh architects, the one with the sidecars. So as you can see, there are two major components to it, one being the control plane, another being the data plane. So the control plane, which is essentially istio, is responsible for injecting sidecars to all the workloads when a namespace is enabled for istio injection. So if the namespace is enabled for istio injection, all the pods are going to be deployed along with a sidecar, which is nothing but on web proxy. And this on web proxy is the central point where you do traffic management, observability and mtls, all those things that istio provides. Now, once the sidecar is deployed to a particular servit, it internally intercepts the traffic. Whatever is going to the service is now going through the onboard proxy and then to the service. This is the traditional istio servicemas architecture. Istio also provides ingress and egress gateways which are envoy proxies themselves, but later on that once we go to the demo. There are various limitations to the sidecar approach, the most pertinent one being the sidecar itself. Since each of your workload needs to be injected with the sidecar, it results in modification of the pod spec and it redirects the traffic within the pod. Also, if you have a massive workload like 4000 or 5000 pods, or even more, even the lightweight sidecar, when it is deployed on such a massive workload, causes a massive resource utilization. The traffic capture stb processing, which are very computationally expensive, are done all at the sitecar level. It manages l four routing, l seven routing, l seven observability, l four observability there's quite a lot of going on, and if you have to update the sidecar, then good luck. You have to restart the entire application. There is no midway approach that you can update half of the sidecar and leave the rest running in an older version. The service first protocol is also a massive issue with the current service. Mesh architects with the sidecar as it impacts the permissive mtls and it's very tough to work with and it doesn't even work properly for nonconformant HTTP implementations. How about we break it down? Instead of one sidecar dealing with l four and l seven and doing everything in between, we separate the concerns using two different layer, one for the l four secure overlay, another for the l seven processing layer. The MTLS tunneling, simple authorization, TCP metric logging and routing. All of them can be taken care at the l four level, whereas in the l seven layer you have rich authorization policies, metrics, logging, routing and everything that you need. The ambient mesh does exactly the same thing. It takes care of l four and l seven responsibilities differently. There are two components to it. One is the ztunnel, another is the waypoint proxy. Ztunnel, short for zero trust tunnel, helps you to securely connect and authenticate your workloads in the mesh. It is extremely lightweight as it does not do anything related to l seven processing. All it does is provide mtls and l four authorization. Waypoint proxy, however, is the one providing you with l seven capabilities and it is not mandatory to deploy waypoint proxy. You can deploy it on basis of a namespace or maybe even service account depending on your l seven use cases. So ztunnel, if it sees that there is a waypoint proxy, will pass all its traffic through it so that the l seven policies are being evaluated there, and it again goes back through the other ztunnel to the respective workload. And you can see that waypoint proxies are nothing but envoy proxies themselves. And ztunnel is a different application which is written in rust, making it very performant. Waypoint proxies are like simple kubernetes pods which are deployed in a particular namespace. So if your traffic is higher you can easily scale them up or down, which is pretty easy. Let's understand what is HTTPs connect tunnel ztunnel uses this to communicate with other ztunnel and waypoint proxies as well. It uses Hbone, the HTTP based overlay network environment, to encapsulate all the traffic that is coming through the ztunnel into a single port which is exported, as in this case that is port 15,008. You can see the Ztunnel might be listening at port 84, three and other particular ports from a particular workload, but at the end of the day it's kind of encapsulating everything in the Hbone and exported through one single port. As a result, the ztunnel doesn't has to manage a lot of connections with the other ztunnel or waypoint proxy, making it very simple as there is only one port which is exported and the entire traffic is kind of going in this kind of packet as you can see below. So this clear encapsulation provides better interoperability with load balancer infrastructure. It also works well with the existing envoycar, the istio sitecar mesh. And as a result we also have a better support for server first protocols for your MySQL and other databases where the server kind of makes the first connection. Now let's understand how secure Ztunnel actually is. For those of you who know Spiffy, the secure production identity framework for everyone, it's similar to the workload attestation process. So here you can see the sleep pod is trying to interact with the Echo server on a different node and everything is going through ztunnel and then a waypoint proxy and the communication is happening. So in between we have SvID, which is spiffy, verifiable identity to verify a particular service here. Since the spiffy says sorry, the Svid says that it's from NS NS one SA sle sleep. We know that it's coming from the sleep service and then it has to go to the echo service. And this is how the Zetaner goals from where to route the traffic. So what's happening is for generating the certificates for a particular service or particular workload. So istio is the one that acts as the root ca. You can configure it to use a different root ca, but istio in this case acts as the certificate authority. Zunnel here assumes the identity of a workload which is running on its node, and it acts as a node agent in terms of spiffy. It then sends a CSR request to the istio control plane on behalf of this particular service to get its identity back. Istio control plane then signs it and returns the X 509 certificate to the ztunnel. Here istio control plane is kind of acting like the spiffy server which signs the certificates for a particular workload, and this is how the entire certificates are being managed in the service mesh. Now let's have a look at ztunnel in action. This is not the actual demo. We'll be having a demo further in the session. This is just to see ztunnel in action. And as shown in example here we have a sleep pod which is trying to talk to an echo server in a different node. This is a local kind cluster and I'm using two nodes here which I'll simply use TCP dump and listen for port 80 and the port 1508 which is the hbone port and the same thing here as well. I'll be doing that and if I run this I get the response. And also here you can see the traffic is not encrypted. We can see the request body and the entire response zero trust adding spaces below. Now let's install istio and enable the namespaces to use the Istio ambient meshtio CtL install set profile ambient. We'll be having a look at all the configurations and all add in the session. This is just to show ztanel in action. Let's give it some time to install everything and once it is done we just need to label the namespaces with istio IO dataplane mode equal ambient so that the ambient mesh, the namespaces are kind of in the mesh. Now I'm running the same thing. We are getting the response back, but if you see here the entire traffic is encrypted. You're not seeing anything that we saw previously, and these are kind of the logs for the different ztunnels and all communicating. But every traffic here is encrypted. So yeah, this, you can see the ztanel in action and how it does mtls. It's just pretty easy. It works out of the box. Now, what could be a better time than this to discuss the benefits of ambient mesh? We trust saw Ztanel in action, and this is as easy as it can be. So the first benefit is that it can be used without modifying an existing workload. It is a non invasive method of using the service mesh. You don't have to modify pod spec or do any internal traffic rerouting in a pod. I just labeled the namespace, everything was working, and once we go to the demo, we'll be able to see it even further in action. There is zero downtime. You don't have to wait for any sidecar to be injected and running so that you can say that hey, my service mesh is up and running. It is very minimal in terms of cost because you're not deploying sidecars for every particular workload. So that makes it really cheap, both from the cost perspective and the resource utilization perspective. It is interoperable with all the sidecar based istio, even non istio workloads. So yeah, this is kind of like the best solution of istio you could ever imagine. Okay, without any delay, I'll be jumping straight to the demo, since after seeing ztanel in action, I'm sure you might be wanting the whole picture. So let's hope everything goes well. So this is my cluster setup for the demo. I'm using aks cluster with two nodes, and this is the node specification, as you can see. And I'll be using the Istio version of 118 three. So the way this demo will progress is that we'll be starting with this particular architecture, and we'll kind of keep adding bits and pieces to it. And as you can see, there is just one namespace in node one and another namespace in node two. Each namespace is going to have sleep and not sleep pods. However, the echo server in ns one is just one deployment and ns two. It has two versions, v one and v two, for us to understand traffic management as well. Now, we'll quickly go over the configuration for these deployments. So here you can see we have two files, resources ns one and resources ns two, responsible for kind of deploying various workloads in different namespaces. So I am defining the namespace here, and I'm also labeling it with Istio IO data plane mode ambient, so it is taken into the ambient mesh when you install it. So right now we won't be having any istio. So whatever you install here, it's simply going to kind of be there. And then I have service account for echo service and I'm using service account for the waypoint proxies, that's why I'm creating it. There is an echo service and then the deployment. Same thing with sleep server and not sleep. There is a service account, a service and a deployment. The only thing different in resources ns two is the namespace, and the Echo server deployment is having both v one and v two here. So now we'll quickly install the workloads. So all we have to do is apply those two files, ns one resources, ns one. Here it's creating the namespace services, deploying everything switch for some time, and we'll also deploy ns two. And done. Awesome. So let's see what we have. In NS one. We have our echo server, we have a not sleep and sleep pods, the services, the deployments, everything is up and running. Let's go to ns two. And we do have two echo server here, one for V one, another for V two. So everything up and running here as well. Let's have a look at the pods and see if they are deployed in the right nodes. The namespace two is running on this particular node, one and ns one. All the workloads would be running in the node. Now moving to step two, what we'll be doing is we'll be installing istio, and in this case I'll be installing istio with the ingress gateways as well. In the trailer you had seen just the ambient mesh istio, but here we'll be needing the istio ingress gateways. So yeah, let's just copy the command from here. Oops, this much? Yeah, I'm lazy. I'm just copy pasting commands. Oh, my bad. What did I do? Command not found. Yikes. Looks like demo gods are not with me. Let's give it some time. It's going to take some time to install istio. Core has installed. We have the istio D here, the CNIs ingress gateways, everything is going to get installed. We'll be having a look at the istio namespace as well, to see what all things it has. So once it's done for injection, okay, cool. Get ns. We'll be having an istio system namespace, which is by default. And let's see kubectl get all steer system. Okay, maybe I need to reduce the size a bit. Yeah, so here you can see we have the Steocanis that are running on different different one for each node we have the ingress gateway, we have the control brain, and we have a ztunnel which is running on both the nodes. We have the ingress gateway as well. And if we have a look at the pods, you can see one ztunnel is running in this particular node, another ztunnel is running in this node. So we have installed Istio successfully and well after that we'll also be installing the gateway APIs. We'll be needing this ahead in the demo. Since I've already installed that in my cluster, I won't be running it. You can simply use this command to install it. This is just to install the Kubernetes gateway APIs. Now since we have installed Istio, let's install Prometheus, Grafana and Kiali. All the observability tools here as well. So I don't have the ML files here, I have it in a different location. So I'll simply be going there Opensource 18.3 and then we can simply copy paste the command. However, I don't recommend copy pasting it from PDF anyways. You'll be having everything in GitHub. I'll make sure I'll add a proper readme to it as well so you can use it properly. Okay, Prometheus is installed. Let's install Yali and Grafana as well. Awesome. With this we have installed istio ambient mesh and all the related add ons to it. Now let's go ahead. Now in the next step we'll be labeling our namespace so that it is ambit Imesh enabled, which I've already done in my configuration. So if you haven't done it, or maybe you're using a different namespace which was pre created, you can simply label it like this. Now let's test it with the Kubectl exec command and see if it's working or not. Okay, and while we are here, we might also need to execute into the Z tunnels as well, so I'll be doing that. Before that, let me paste this command and format it so it works. Let's log the ztunnels cubectl log. You can see it's kind of having all the xds and all service discovery and all is going on. Okay, what was the other pod? Cool. So we have these eternal logs printed here. Now let's run this command. Nice. We are having a response back. It's coming from v two. And yeah, in this case it might come from v two. V one. We are not doing any load balancing stuff yet, so let it come from wherever it is coming. Yeah. Now we are having it from v one. And you can see it's logging all the inbound and outbound proxies. This, you can see, is basically the kind of Ip of this particular services, these ztunnel services. And we have the logs here as well, that it is having an inbound consumption. We have a residue printed here as well. So we know from where the traffic is coming. So, yeah, you can see the Z tunnel is actually working pretty fine here. And maybe if I do get SVC system. Okay, let's see what we have next. We have already enabled ambient mesh. And next we'll be having a look at the authorization policies. So we'll be doing two things here. One is that first, by default we'll block all the requests. And in the next, what we'll be doing, we'll be specifically allowing ns one sleep, ns one to talk to echo ns two. Now, let's have a look at the configurations at first. So this is the deny all l four. Basically, if you create an authorization policy here, I'm just giving the name of the authorization policy and which namespace it belongs to. So then you can see that if you don't provide any specifications to it by default, if you simply create an authorization policy, it's going to deny everything. So let's see that in action. I'm going here. Cubectl, apply f, deny all l four and just created the authorization policies. And. Yeah, let's sde if that works. Copied the command here. So here we're trying to talk from sleep ns one to echo server ns two. And we'll be getting a command terminated with exit code 56. So this is the policy is basically blocking us to do that even in the same namespace. If I just want to talk to echo server one, it's still going to block it. It won't allow anything, any, any communication. It won't allow. So now let's have a look at how to enable communications for NS two. Echo server in NS two. This is the configuration to it. Sorry, this one. So again, similar to the deny all one, we are creating an authorization policy and we are naming it as allow inbound to echo ns two. You can name it anything you want. And the namespace as well. We are giving here, and in the specification, we are simply giving the match label for the app, which is echo server ns two, and we are giving the rule. So this action could be either you can allow it, you can deny, it depends. All of these you can see in the istio documentation regarding the authorization policies. It's pretty clear there. So here you can see from, I'm just giving a source. And in opensource I have to list the principle. So here I'm listing that. Okay, you allow only the request that is coming from sleep account ns one. This is very similar to the SVid you are seeing. It's saying that in local cluster from NS one, just allow sleep service one to kind of send requests to this guy. Anything else would be blocked. So let's apply this policy. Cubectl apply f, allow communications from Echo ns two, Yaml once it is applied. Now if we go back and we try to communicate from NS one sleep to echo server in NS two, this should work and this should give us the response back and we have it. And now if I try to do the same thing with not sleep, which is in NS one, it would give an error to me. And even if I tried to do it with sleep, which is in the same namespace as that of Echo server, that is ns two, it won't work. Right. So different exit code it is giving. You can refer the documentation for this. But yeah, on the whole, the L four authorization policies are working great here. So as we can see, it is blocking the traffic and it is doing all the things. Now, next we have got allowing traffic through the ingress gateway. So this is, we have seen that we are communicating through the, you can say we are kind of exec into the sleep pod and then we were just writing curl command to communicate. Now what we'll do next is we'll allow Ingress Gateway, which is the Istio ingress gateway, to communicate with Echo NS one, the Echo server in n namespace one. For this we need to apply the Istio gateway Yaml file, which is the standard istio gateway. If I simply go there and you can see in the configuration I bills, just increase the font size a bit. You can see we are creating a gateway. Again, it's just the Kubernetes gateway type. The only selector is this istio ingress gateway. Okay. And then we are saying that for port 80, just allow from all the hosts. So this is pretty standard gateway configuration. Same thing with the virtual service, the istio virtual service that we have seen up until now with the sidecar ones as well. It's just giving a name for a particular namespace. I'm specifying that use this particular gateway, which is gateway NS one that I've made here. And all you have to do is route all the traffics to the NS one service. I need to apply this file. So if I go here and I do kubectl, apply f istiogateway yaml, it's going to apply everything. And you can also do it, you can just get the gateway right. We have applied Gateway NS one, and also the virtual service, it's associated with this particular gateway. And this is the external ip for the ingress gateway. Now let's copy and go over to Google Chrome and see. So right now you'll be seeing that the connection error is happening because remember, we applied deny all. So yeah, it still won't allow the traffic until you enable it externally. So there's another file which is simply saying similar to what we saw for the Echo NS two that allow all the inbound traffic that is coming from the Istio ingress gateway. Now, istio ingress Gateway itself has a service account, and this is just what we are referring to right now. Let me apply this file communication to echo NS one. And once the authorization policy is applied, simply go ahead and refresh it. And now you can see I'm getting everything. You can also see I'm getting the envoy headers here. So yeah, nice. We have an external gateway is to ingress gateway, and that is working well with the ambient mesh workloads. So moving ahead, we'll be having a look at the l seven authorization policies. We'll see how to generate the waypoint proxies. How do you apply waypoint proxies? So what we'll be doing is we'll be restricting the sleep ns one to echo ns two communication to only get request. We won't allow any post or delete or any such request. So let's first generate the waypoint, and before using there you can also get the authorization policies, whatever you applied using the get authorization policy command in Kubectl. In this case, in NS one, I think only two were applied, one for the inbound from the istio ingress, and another was the denial. Now let's have a look at how to generate the waypoint proxy. You can use the istio command. X stands for experimental waypoint generate nns two and s, which is not the service, but the service account, which in this case was echo server service account ns two. Let me quickly verify it. If that's the case, yeah, eco service account. Okay. Not the server. Nice. Okay, so this, as you can see, it has generated the standard Kubernetes gateway API, yaml. You can see the kind is gateway. The only difference is that you have an annotation which specifies that this is for which service account. In this case, it is for echo service account ns two. And we have the name here as well. It's just taking the same service account name and putting it as a name and namespaces. Ns two, in specification, we are specifying that the gateway class is istio waypoint and just a listener for the hbone. For the Hbone. Okay, so what I've done is actually you can directly apply it from here as well instead of generate. If you hit apply, it would still work. So what I've done is I've copied this over to a file and I've just changed the gateway name so it won't be confusing because we already have the names similar to what we had in the service account name. So let's apply this file instead. Again, it's a standard Yaml file. You can apply, it doesn't matter. Waypoint proxy, yaml enter. Nice. We have created the gateway. Okay, now let's have a look. Cubectl, get gateway. NS two. See, we have an echo service. And to gateway, the class is istio proxy. It has its own address as well, which you can see the gateway name and the istio vapor and proxy. But let's also get the pod in ns two. Now you can see there is a service, the waypoint proxy pod here as well, which is running. So as we had seen, that waypoint is just a pod. It's nothing different. It's just a pod that is running. You can scale it as and when you like. Let's just log it and see what is happening there. Pretty standard on web proxy logs here. You can see nothing fancy here. Anyways, so we have deployed that. Now let's again try to query the ns two. Echo service is ns two with service one. So right now, I haven't applied any l seven policies yet. We simply have the waypoint proxy and we are just doing the curl command now. Trust, see what happens if I run it. So previously we had already applied the l four authorization policies to deny all, and then we allowed the communication. But since I have applied the Waypoint proxy as well, I am getting an RBAC error here saying that access is denied because right now we have the Waypoint proxy, but we are again not allowing what things we need to do. So the default is basically it's getting access denied in this case. So in order for us to allow the get request, we can make another policy authorization policy. In this case it is going to be an authorization policy for l seven. As you can see, I am having a gateway name associated with it, and in this case I'm using the same gateway name which we had used in the case of waypoint proxy. So this authorization policy would be applied for that gateway. We are allowing the request and the rule is simple. Whatever was previously there from the source and the principle is basically this. And two here stands for what kind of operations are we going to do? You can again refer to the documentation for further kind of in depth guide as to what these configuration would do. And in this case we are simply using operations and saying that, okay, allow, method, get. We are not using anything else. We are allowing that from this particular cluster to echo server, just allow methods, that is get request. Let's apply this file Uctl apply f allow get request to echo ns two. Now it is created. Now if I try to do the same thing, I'm getting a successful response. Let's try it with post request. And we are getting an access denied. Cool. So this is working. This is the l seven network policies in action, as you can see. So this was a very basic example of how we would apply the l seven authorization policies. So similar to what we have seen in l four authorization policies. If you don't provide a spec selector by default, it will block everything. We have already seen that since we had not applied anything. And in this case also if you don't apply anything in operations, the two is basically specifying what all operations you want. So if I simply comment this out and I don't apply, it will allow everything that in this case we are restricting only to get, it will allow get postponed and all those things in context of this example. But since we are restricting to the set of operations as methods get only, it will only apply the get request to kind of apply the get request to pass through. Now. Next we'll be having a look at traffic management. So we'll be doing canary release here we have already seen from sleep ns one. We are able to query echo ns two with the get request. Now we want that. Okay, the 90% of traffic should be ending up at v one and the 10% at v two. So to do this we'll be applying a canary Yaml file. So as you can see, this is pretty standard. You can see whatever you would do in istio with sidecars a virtual service that is applied on a particular host. In this case, this is the host of Echo server which is in ns two. And in route destination, we are only saying that, okay, for subset V one, make 90% of the request approximately go to subset V one for this particular host. And in the other one we are saying that, okay, for 10% of the time take it to subset V two. Now the definition of these subsets are there in the destination rule that we have set here. The destination rule is again applied on ns two and it is selecting echo server service ns two. I haven't applied a full qualified domain name here because it's in the same namespace. So I'm just showing this example that yeah, it would still work without the FQDN. Okay, so in subset V one we are simply selecting echo server app ns two and the version of the app which is v one. And in V two we are simply selecting echo server app that is ns two and the version which is v two. Pretty standard. Basically if you apply this to the sidecar enabled service mesh, it would still work, nothing different. So now we are going to do kubectl apply my f canary. Yaml. Let's wait. Nice. Let's see kubectl get destination rule. In ns two we have the echo service one and also the virtual service. Awesome. Now let's test it. So what we'll be doing is so we'll run a command which will send 100 request from the sleep of NS one to the echo server of NS two. If I can, oops, I can properly format it. We should be good to go. Yeah, let's run it. It's going to take some time because it's going to fire 100 kind of requests to this particular service. And as you can see for version one, I'm just doing a grab to get whatever version it is there. In the logs, we can see that 91 of them have this echo server deployment ns two version one. And if I simply change it to version two, we'll approximately get ten requests. In this case. Okay, it's 16. That's still fine. Again, it's not going to be a perfect division of percentage. It will try to approximate it as much as it can. So we are seeing here different number, and you can see the variation is quite huge. So, okay, now let's see, what exactly was it sending here? If I simply do the standard curl command instead of any grep or anything. So let's see what we are actually picking. So we already have a hostname that was being printed and for different part it's going to be different. So this is what the grep was doing and we are simply counting the occurrences. So in this case it is again version one. Let's run it again. It's version one. Again version one. Since 90% of request is going to version one, we are most likely to get this. So as you can see, canary releases is working well. You can play around, do whatever kind of 50 50, you can do a blue green or whatever things you could do with istio. You can do the same thing with istio ambient mesh, and it's nothing short and it's pretty performant as we can see right now. So after traffic management, let's have a look at the observability and debugging capabilities of istio similar to that what we are seeing in sidecar. We'll get the same things here as well. So I'll be using. Let's go to Prometheus first. Istio dashboard Prometheus. So you can see I'm having all the istio related matrix request total. Yeah, I'm getting everything you can see from destination service gateways. This is, by the way, the ingress ones here. Also you can see the app was issue ingress. You won't see a lot whatever we have done, from the curl to the ns one, which we had tested previously before applying the deny all, because those are some of the TCP metrics. The L seven ones would come from envoy itself. So in this case, ingress gateway is envoy. So that's why we are having L seven capabilities. And the waypoint proxy itself is an envoy proxy. That's why we are having all the L seven metrics from there as well. However, all the L four metrics were there. Once you apply the ztunnel, you'll be getting all the tcp consumption opened, lost total, all those counts. Everything would be there. So the matrix, as you can see in Prometheus, it's working great. Let's have a look at Kiali as well. If I go to graph and I'm choosing last one, r maybe. Okay, I'll first. Okay, so now you can see in sleep ns one to echo service. We are already seeing the traffic flowing to version one and version two. The green ones are the previous ones which we had deployed before the service mesh was there. So this is just the general ones, whatever that has been captured. Once the service mesh is here, you can see that in the. If I go to app graph itself, you can see everything is in blue, is kind of tcp encrypted. Okay, where is this version app graph? Right. We had some of the failures as well, which is being captured here. So yeah, pretty much everything is working in the observability section. Let's have a look at Grafana as well. I'm going to the available dashboard. You can however choose to create your own dashboard. Go to the control plane dashboard and see what kind of metrics we are getting. So we have a cpu usage and we have our endpoint listener pilots. Everything, whatever we had seen in the istio sidecar version, we are getting everything here. Let's go to some other dashboard, maybe the mesh. Okay, what's there in the mesh one? Yeah, some of the information related to mesh, how many authorization policies we have applied, what interval and all those things. So yeah, we also have the service workload request and all those things, whatever was captured here. So you can also do pretty much everything what you were doing with istio related to observability here. So yeah, that pretty much sums it all. So apart from observability, we can also use istio CTL to debug our proxies. So let's have a look at that. So you can use istio CTL proxy status to get the status of all the proxies deployed. So in this case you can see especially the envoy proxies in this case, which is the waypoint and the ingress gateway, they all have the endpoint discovery service and ecds and all those things, they are synced and all the information that you can see you're getting. The ztunnel, however, is not an envoy proxy. So all of these things are ignored. You can also use istio proxy config to have a deeper understanding of the consumption of these particular envoy proxies. If you just go to the help section, you'll have a list of all the available commands that are there and you can use it to debug your proxies. So let's try something like proxy get all. So we'll be retrieving all the configuration for this specific envoy proxy. In this case we'll be using the Echo service one. And make sure that once you're giving the name of the pod, you also give the namespace after the dot. So this is how it works. So let's see what we are getting. We can see that we are getting entire overview of all the full qualified domain name services it has, what port they listened on, or what is the direction of the traffic. Also what virtual services you are using for this particular inbound. So this is a pretty handy tool for you to debug, and it also gives information about the root ca as well, as you can see here. So you can also play around with this, and istio CTL is a very powerful tool for you to debug as well. That's all for the observability and debugging. Okay, so if you have been this far, then good job. So we have successfully added ambient imesh to our cluster, and if you have any questions related to it, feel free to reach out to me on LinkedIn, or maybe even just create an issue in the GitHub repository that I'd shared. So thank you everyone. Once again, thank you to conf 42 for having me. This is MD Azmal signing off.