With Cilium Local Redirect Policy (LRP), you can force traffic to stay on the node, improving performance and reducing latency. LRP is especially useful for DNS and Kubernetes NodeLocal DNSCache. Watch the video to learn more. Introduction Hi. Today I'm going to talk about Local Redirect Policy, or LRP. is a feature supported by Cilium. It's been around for a few releases and lets us implement a policy to redirect traffic locally, essentially keeping traffic from a pod on the same node. So what's the use case here? In Kubernetes, you often have your pods accessing a Service, and that Service fronts backend pods that might be located on different nodes. In that situation traffic may or may not leave the node. There are cases where you want the traffic to stay local to minimize latency and avoid unnecessary hops. Demo setup It's quite similar to topology-aware routing. You want the traffic to stay within the node instead of leaving when it doesn't need to. The most popular use case for this feature is alongside node-local DNS cache. The principle there is that pods are going to make DNS requests, and if we run a local DNS cache on the node we can use Local Redirect Policy to force that DNS traffic to stay within the node. That's really about improving latency and influencing the traffic to stay local. Let's take a look in the demo. I've got my lab environment. I'm running Cilium 1.16.0-rc.1 on a kind cluster with three nodes, and I've activated the Local Redirect Policy feature. Policy configuration I'm going to show you a couple of examples. First I'm going to deploy my environment with a backend pod, which is going to be my server, and a client pod. Here's the backend pod. It's got a label called app=proxy, and I've pinned it to the kind-worker node. That's going to be important later. Now let's look at my client pod. That client pod is going to access the backend I just showed you. Next I'm going to create my Local Redirect Policy. First I create a Service, and what I'm going to do is force traffic bound to that Service to go to my local backend. This is a very basic Service listening on port 80. It isn't fronting any real backends yet, so let's go ahead and deploy it. Deployment It gets a ClusterIP, and if I look in the Cilium agent service list I can see that the Service has been created. There is no backend yet because nothing matches that selector, and that's fine for this example. Now let me show you the actual Local Redirect Policy. For traffic bound to my Service in the default namespace, I'm going to redirect it to the endpoint with that particular label. Let's deploy it and then check the service list again on the Cilium agent running on the kind-worker node. Here you can see we've updated the Service from ClusterIP to Local Redirect, so traffic to the Service IP will be forwarded to 10.244.1.11. If we look back at the pod, that's the IP address of our backend. It's almost like static routing or policy-based routing, where you bypass the normal table because you know there is a better path. Verification Now let's verify it. We do a curl and we can see successful connectivity from our pod on kind-worker to the Service IP on port 80, so we've redirected the traffic from the mediabot pod into our backend pod using Local Redirect Policy. That's a practical example of using Local Redirect Policy. As I said before, the most obvious use case is DNS, so let's look at that next. We're going to use Local Redirect Policy to reduce DNS latency in the cluster by combining it with node-local DNS cache. The idea is to run a DaemonSet of local DNS agents, one on each node, so we can force DNS traffic from pods to stay on the node where the client is running. Conclusion Now I've got my DaemonSet of local DNS agents, and I want to force all DNS traffic to stay local using Local Redirect Policy. Here we're essentially saying we want all traffic bound for the kube-dns Service to stay local and be sent to endpoints with a particular label, which is the label on the DaemonSet I just deployed. I've got three nodes, so I've got one node-local DNS agent running on each node. You can see it's listening on port 53, so all DNS traffic will stay local. Now we're going to verify that traffic is indeed staying local. I'm going to collect the statistics from each local DNS agent, run some DNS queries, and make sure only the agent on the same node as my client increases its stats. I'm going to my mediabot pod, which is running on kind-worker, and I run a few lookups to google.com, isovalent.com, and so on. When I look at the statistics, they've only increased on the local DNS agent, the one running on the same node. None of them are being sent to a remote DNS agent. So again, that's a way to improve DNS latency and keep queries local. It can be used for other use cases too, but this is probably the most popular one for LRP. I hope you found this useful. If you have any questions, just give me a shout, and thank you very much for watching.