Introduction Hi. In this video we’re going to look at a new feature coming in Cilium 1.14 called Envoy as a DaemonSet. We’ve been using Envoy with Cilium for quite a few years. Envoy is typically used with Cilium for capabilities that we cannot yet do directly in eBPF, especially Layer 7 processing. For example, we use Envoy when we need Cilium Ingress, Cilium Gateway API, Layer 7 visibility of HTTP traffic, or Layer 7 network policies based on things like gRPC, HTTP method, or HTTP path. Policy configuration Envoy is a great proxy and has been used in service mesh environments for years. When Cilium needs that Layer 7 capability, it traditionally deploys Envoy inside the Cilium agent. The drawback of that approach is that they share the same lifecycle. If you patch Envoy, you impact the Cilium agent. If you restart Cilium, you also impact Envoy. Envoy deployment model The idea of deploying Envoy as a separate DaemonSet is that the two components no longer share the same lifecycle. If you restart the Cilium DaemonSet, you do not affect Envoy. If you need to patch Envoy for a vulnerability, you do not affect Cilium. Another benefit is that you can apply different CPU and memory limits to Cilium and Envoy. You also get cleaner operational separation, including separate logs instead of a single mixed stream. There are several small benefits like that, and together they make the DaemonSet model a much better deployment approach. It may well become the default in the future. Configure Layer 7 policy Let’s look at a demo. First we examine a Cilium 1.12 or 1.13 environment to see how Layer 7 policy behaves there. In that setup, Cilium is deployed and running, and the only DaemonSets are kube-proxy and Cilium itself. I deploy a Layer 7 network policy. As with any network policy, labels decide which workloads it applies to, and Layer 4 settings define protocol and ports. When we need Layer 7 filtering, that is where Envoy comes in. In this case we are filtering on a specific HTTP method and path. If I look at the Cilium agent logs, I can see that once the Layer 7 policy is applied and traffic hits it, Envoy activity appears in the same log stream as the Cilium logs. That’s exactly the coupling we want to improve. Deploy Envoy daemonset Now let’s look at Cilium 1.14. I deploy Cilium 1.14 with Envoy as a DaemonSet enabled. After about a minute, the installation is ready. If I run cilium status, I can see that everything is healthy and there is now a line showing Envoy DaemonSet, which tells me Envoy has been deployed separately. If I look at the Kubernetes DaemonSets, I can now see both the Cilium DaemonSet and the Cilium Envoy DaemonSet. Because I have three nodes, I get one Cilium and one Envoy per node. That is really the essence of the feature. Envoy is now deployed independently, which gives us lifecycle separation, better operational isolation, separate logs, and separate resource controls. Hopefully this video was helpful, and thank you very much for watching.