 O hai o gozaimas. So, yes, my name's Liz Rice. I work at Isovalent, which is the company that originally created the Cillium Networking Project that Katie and Col Hay already mentioned this morning. Cillium is probably an incubating project, and it's based on EBPF, and I'm going to be talking about why EBPF is such a powerful platform for not just networking, but also observability and security infrastructure tooling, and why perhaps we no longer need to rely on the side car model going forward. You may have seen me before as the chair of the Technical Oversight Committee at the CNCF, and I'm also involved in an organisation called Open UK, which encourages collaboration around open source in the UK and also internationally. So, let's start with side cars. What do I mean when I'm talking about the side car model? Well, even before side cars, when we wanted to build common infrastructure tooling, things like logging and tracing and security tools that we want to run in every application, we used to have to either write or perhaps import code written in the same language as our application. When we move to containers, we no longer have to use the same language as our programming language. We can put that common code into containers and run the same container in every pod, so every pod is instrumented in the same way. That container is a side car container. We call this the side car model, and it's been widely used for logging and tracing and security tooling and service mesh. That's side cars. Now, let's explain EBPF. The acronym stands for Extended Barclay Packet Filter, but honestly you can forget that because it does so much more than packet filtering that the acronym is really meaningless now. What EBPF allows us to do is to customise the way the kernel behaves. We can make the kernel dynamically programmable. It's a bit like how JavaScript allows us to dynamically change the behaviour of a web page. Now, normally as application developers, we write our code in user space, and every time our user space applications want to do anything that touches hardware, maybe reading and writing to files or allocating memory, sending network messages, all these things require some hardware. And user space can't do this for itself. User space apps have to ask the kernel for assistance in all these activities. We don't normally think about this because programming languages give us abstractions, so we're unaware that the kernel is being invoked. Now, when we use EBPF, we can write a program that runs inside the kernel that's triggered by an event. And that event could be any function being triggered. It could be a trace point. It could be a network packet arriving at a certain point in the networking stack. Whenever the event happens, our custom EBPF program gets run, and if we attach EBPF programs to different types of events, we can use that to observe what's happening in the kernel, perhaps even react to those events for security purposes or networking tooling. In Kubernetes, our applications are still running in user space, but they're inside containers, inside pods. There's only one kernel per machine or virtual machine, so one kernel per host, and that kernel is shared across all of the processes, all of the containers that run on that host. As before, our applications, if they want to do anything interesting like sending and receiving networking messages, reading and writing to a file, the kernel is going to be involved. So, the kernel is aware and perhaps involved in everything that's happening on that host, and if we attach EBPF programs to the right events on the host, we can build tooling that is aware of all of those applications running in all of our pods. We only have to instrument the host, we don't have to instrument every single pod. So, I've talked about what EBPF is, I've talked about what sidecars are. Let's dig in a little bit to some of the advantages of EBPF over sidecars. For a sidecar container to be aware of what's happening in a pod, it has to run inside the same namespaces, the same Linux namespaces as the application, and to get it there inside the pod, we have to have some YAML code. Normally, that YAML is created automatically, perhaps by an admission controller or through CICD, but suppose something goes wrong or there's some misconfiguration. If the YAML doesn't get injected into that pod, the container won't be injected into that pod, there will be no instrumentation of that pod. Then, that pod is not visible, the tooling can't have any influence over that pod. EBPF doesn't need any app configuration changes at all, because we're loading the EBPF program into the kernel. As soon as you attach an EBPF program to an event, it's going to be triggered regardless of whether the pod was running already. You don't have to restart your pods, they're always going to be triggering those EBPF events. There's no need to reconfigure your pods, you don't even have to restart them. Also, EBPF is going to be aware of all the activity on that node, even if it's malicious activity, as well as the expected activity. So tooling can see malicious processes running on the node. The CICAR model can also be pretty wasteful of resources. Every pod has to be configured to have sufficient memory and CPU, not just for the application, but also for the sidecar container. We need to have duplicate copies of state and configuration information inside every pod, because by design pods are isolated from each other. You can only share information using shared files or network messages. In EBPF, we have a concept called EBPF maps. These are data structures that make it very efficient to share data between EBPF programs in the kernel and our user space tooling agents. Lots of tools have already been written that take advantage of EBPF and its power. Let's look at a couple of examples from the CNCF landscape. The first dimension is Pixie. This uses EBPF to collect metrics, all sorts of different metrics from all the nodes in your cluster, brings them together and presents them in various graphical ways. This is just one example of the kind of information you can get with Pixie. It's a flame graph showing CPU usage across an entire cluster. Another observability tool is the Hubble component of Cilium, which gives visibility into networking information. We can see individual packets and we can see the build-up of a service map showing how traffic is flowing between different Kubernetes services. We also get metrics information at both layer 3.4 and layer 7, the application layer. Hubble is part of the Cilium project. Cilium also uses EBPF to provide efficient networking connectivity. I mentioned that EBPF can attach programs to events in the networking stack. We can use that to bypass parts of the stack to deliver packets much more efficiently within a Kubernetes network. As well as providing connectivity, Cilium is also providing security using EBPF. It gives transparent encryption so we can encrypt traffic between nodes in the kernel. We can use EBPF to enforce network policy by dropping network packets that are out of policy. About a year ago, we added some additional capabilities to Cilium so that it can act as a service mesh, a side carless service mesh. What is a service mesh? A service mesh provides connectivity between apps at a service level. It abstracts away the underlying network and provides additional features like observability, security and traffic management. The innovation that Cilium brought to the world of service mesh is building it without side cars, which we can do because of the power of EBPF. All service meshes use a network proxy to handle and process traffic at the application layer, layer 7. Other service meshes have used the side car model for that proxy, so there is a proxy injected into every application pod. Cilium's implementation allows us to share a network proxy across multiple pods. Avoiding the side car model helps to avoid the complexity and resource usage that has often been associated with configuring the proxy in every single pod per Kelsey's quote about service mesh. Combining this with EBPF also gives us a much more efficient networking path. A shorter networking path means reduced networking latency. In the side car model, every single network packet has to traverse the networking stack multiple times to pass through that proxy. And if you have two pods communicating, both having a proxy, then the networking path gets pretty convoluted because it has to pass through a proxy at both ends. If we run the proxy outside of the pod, then we can create a much more direct networking path between two different pods, only passing through the proxy once and only passing through the proxy when it needs to because layer 7 traffic is involved. And we know from Cilium beta testers that this ability to avoid the operational complexity and the improved latency is really attractive. There are many organisations for whom side car based proxies, it's just been too high a price to pay for the functionality that they get. Cilium was the first to implement service mesh without side cars, but now Istio has also followed suite with the ambient mesh approach. There are some differences in how Cilium and Istio are approaching this, but they're both taking side cars out of the equation. They both use Envoy proxy to handle the complexity of layer 7. Side cars have always been an unfortunate implementation detail. Mesh features will move to the underlying infrastructure, that's from Matt Klein who originally wrote the Envoy proxy. With Cilium, we've moved a significant part of that service mesh functionality into the kernel itself and we delegate responsibility to the Envoy proxy in user space to handle layer 7 complex processing. This idea of running processing inside the kernel and delegating complex parts to user space has been done before. We're doing it in networking and service mesh. Similar pattern is used by Surikata security tooling, which makes security decisions in user space based on packets sent to user space by the kernel using NFQ. Or, if you plug in a hardware device in Linux, the kernel will call to a user mode helper, typically, to help with the complexities of configuring that device when the kernel module gets loaded. Now, in service mesh there might still be reasons why you do want to co-locate your proxy inside the pod. If you're running complex custom wasm filters in your Envoy proxy, you might want to isolate that proxy from other pods, so you could continue to do that using the sidecar model. I think we'll actually see service meshes offering a range of options for how the proxy is isolated, how many instances of the proxy exist. The last part of the service mesh puzzle is encryption. Mutual authentication between application workloads is a really important feature for many organisations. Let's have a look at how we're handling that in Cillium using EBPF. I already mentioned that we support transparent encryption. Traffic that flows between different nodes gets encrypted in the kernel using either IPsec or WireGuard. This has been really great for many organisations because all traffic is encrypted and it's very easy to manage. You can also use Cillium network policy to ensure that the traffic that flows between different services is permitted. When they're working on a next generation of encryption, mutual encryption, using application workload identities, you can use the identity management system of your choice, spiffy, cert manager, whatever else, to manage the identities and the certificates that represent each individual application workload. Cillium will inject those certificates into the kernel and will use kernel level encryption for encrypting the traffic. We've solved a lot of the problems in service mesh, in observability and security tooling using EBPF. Does this mean we will never see sidecars again? I'm sure we will still see some use of sidecars. First of all, EBPF programme is essentially kernel programming, so there's a pretty high barrier to writing EBPF programmes. I don't think people will immediately rewrite all their infrastructure tooling using EBPF and certainly the sidecar model will be a lot easier for many developers to experiment with. The other reason to use sidecars will be if you don't have access to the underlying node. In many managed Kubernetes environment, you'll need the cooperation of a cloud provider if you want to use EBPF-based tooling. But the power and the efficiency of EBPF means I'm sure we're going to see much more infrastructure tooling built on that platform. One of the real reasons for that will be the pull of users who demand improved performance and we see proven performance improvements because of things like reduced network latency. Because we can run so efficiently in the kernel and because we can load those EBPF programmes dynamically. I think the sidecar model still has its place. We will continue to see it used in some environments. But I believe EBPF has a huge role to play in the future of infrastructure tooling for networking, for observability and for security. If you'd like to learn more about EBPF, I'll be giving away copies of a book called What is EBPF that I wrote. We'll be doing that in the networking session this evening. So I hope you'll come and say hello and we'll get you a copy of that book. Thank you. Arigatou gozaimasu.