 Yeah, let's do it. Okay, so this talk is about supercharge your service mesh with EBPF. So my name is Edith Levine. I'm the founder and CEO of SolarIO. I'm Yuval Kohavi. I'm the chief architect at SolarIO. And we're going to teach you a little bit about EBPF service mesh and how they're related together. Before that, I'm just going to say that me and Yuval are both working in SolarIO. Solar is focusing on application network connectivity. And we have a lot of people. We're focusing, our stack is basically focused on Envoy and STO. And therefore, we are working very, very hard with customers and upstream. So we have a lot of DOC member. Some of them are here even today. And we're basically working to make service mesh upstream better for our customers. So that's number one. And we will start. So let's start when we're talking about EBPF. We'll start talking about the Kerner. I know this is something that you're usually not talking about in a service mesh one, but we should. So let's talk about the Linux Kerner one second. And what you can see is that based on this architecture, which honestly, it's a little bit simplified, it's pretty complex. And it's also very mature, right? So I mean, if you think about it, the work that we're doing today and the thing that we're running today in production, most likely it was upstream between 10 to 10 years ago to maybe two years ago. But honestly, that was done way on the back. Way on the back before we started DevOps. And before we started doing evolution, right? And before there were a lot of, you know, we were running everything right now as code and cloud native, but still we're running it on the same operating system that is honestly was built for application that was running 10 years ago. Very, very hard to do innovation in the Kerner. And that's where EBPF is coming into place. So what is EBPF? So EBPF basically started BPF, basically started in, you know, as the opportunity to solve that problem, which is very hard to innovate in the Kerner, and basically started in the TCP dump. And the idea was, can we create a sandbox or some extension or plugin to the Kerner one that will be injected by the user mod to the Kerner one? And basically we'll be able to run there on it when they will want. So what the advantage of it? First of all, it will give you a lot of flexibility. It's have to be safe, right? It's running on Kerner mode. We need to make sure that it's not going to take your operating system down. And it's need to be fast because, you know, we need performance there. So that is extremely important. And as I said, they started by basically putting the BPF in the TCP dumps. Honestly, if you're using TCP dump, you're probably using it every day. That's where it started. But then they said that's pretty cool and pretty unique. What if we will extend that? And that's exactly what EBPF stands for, Extended BPF. What if we will extend that? And basically we'll have this ability of that technology which is kind of like the Sandbeck box, basically being hooked to events in the Kerner. So what you can see here, you can put in user mode, you're basically writing the program, right? And what you can see is that index, you know, on the Kerner itself, when there is an event, you can hook this code that you wrote and basically execute it. And that's exactly what is the idea with EBPF. So the idea is, again, bring innovation to the operator system, bring the ability to give you customization and solve some problems way quicker than upstream. So now Joval will tell you a little bit about why it's relevant to Kubernetes. Yeah, so a quick background to Kubernetes and networking, right? So with Kubernetes, there's obviously the Kube API server. And then on each node, you have the Kublet, essentially the Kubernetes agent. It has a container-random interface. That's what runs your container, essentially Docker, container-denow, there's cryo. And on the networking side, you have what's called the CNI, the container-network interface. And that's the component that implements the Kubernetes networking layer. So Kubernetes networking is pluggable and swappable. There are various implementations for Kubernetes networking. And the CNI is the plugin interface that you need to implement to add network to Kubernetes. So the CNI responsibility is all the communication between pods, IPs, and how they communicate with each other. In addition, there's another component called Kuproxy, whose role is to make sure that pods can talk to Kubernetes services. So services has virtual IPs in the Kubernetes cluster. And these IPs, in order to map back to the pods that back them, this is managed by Kuproxy. Now, originally, Kuproxy was implemented, it was basically a user-mode proxy written and go. Obviously, that wasn't very fast. So then they update the implementation to an IP tables-based implementation. So you can imagine here, each pods have an IP. And if the front end wants to access the backend through a Kube service, the pod one, the front end pod, only access a single IP, and Kuproxy load balances it to all the backend pods, right? So in this case, it'll be two backend pods that Kuproxy needs to worry about. And while we're talking about all of this, the way IP tables work, IP table was originally created for firewalls. And you had very basic things that a firewall needs to do. It wasn't at this scale of Kubernetes with a lot of services, right? And the way IP table is implemented, it's a list of rules, and this list needs to be executed one by one. So the more services you have, the more pods you have, the less it scales, right? Because that list grows linearly and you need to go through those rules one by one to implement, essentially, reach your backend service. Now, the way EBPF solves this is instead of using IP tables, we can use EBPF here to do that mapping between a virtual service IP and backing pod IPs. And as you can see from this graph, we can do it sort of in a constant time. Whereas with IP tables and Kuproxy, it goes linearly higher the more services we have. Now, the project that brings all these EBPF advantages into Kubernetes is called Cilium. And Cilium, if you remember we discussed by the CN9, Kuproxy-Cilium is an implementation for both using EBPF. So Cilium can create for you the networking layer and also replace Kuproxy and uses EBPF to bring this scalability, the security and the networking features using EBPF to Kubernetes. So things like service identity to create network policies, things like performances we just discussed, things like encryption, multi-cluster routing. So just as an illustration, you can see here that with Cilium you can express policies using the pod labels and selectors and making it easier and scalable. And this is another example comparing the rules that would be in IP tables with Kuproxy versus what you can do with EBPF and Cilium and use pod selection. Now, as far as ANVOI is concerned, ANVOI is the key data playing component in the service mesh. ANVOI also can benefit from EBPF advantages. So for example, with EBPF we can short circuit the TCP stack between the application and the sidecar, right? So when your service sends a request, normally IP table is used to reroute the request transparently through ANVOI, but that means that it needs to go through the entire TCP stack for the app, get to the kernel and get back into ANVOI. With Cilium with EBPF we can use a feature called Sockmap to essentially take the data from one socket and put it straight in another socket, short cutting the whole TCP dump and optimizing that. In addition, ANVOI also uses EBPF in its quick implementation. If you're not aware, quick is HTTP 3. It's a new next level protocol. It's a UDP based. There's no kernel implementation yet. So ANVOI uses EBPF to teach the kernel how it should route the quick packets into the ANVOI worker threads. All right, with that, I'll bring it back to you, to talk a little bit about it, Ciel. Yes. So, you know, we're looking at Cilium, right? You just heard about how amazing it is and what we can do with this and how the performance will be better and so on. And you can go to the website and you can see that basically there's some similarity between what it's doing and what service mesh is doing, right? I mean, they're talking about networking here. They're talking about observability and they're talking about security, which is exactly what I took from the STO website. So are they competing? Are they complementary? What's going on there? And that's basically what we wanted to check and look at. And we did, so basically we did this research which is basically STO versus Cilium. And we took basically those three sections and we tried to understand whether it makes sense to use one or does it make sense to use the other and whether this makes sense to collaborate between those two. And that's exactly what we did. So for instance, if you're looking at identity, I'll let you talk about it, talk about it. So when we compare these features, Cilium versus Itzio. So with identity, the Cilium identity is on the L3L4 level. It's based on pod labels, whereas with Itzio, it's cryptographic identity. If you're familiar with SPIF, essentially mutual TLS certificates and the source of the identity is the service account associated with a pod, not the pod labels. As far as network policies, so you can create a Kubernetes network policies with Cilium, again, a L3L4 level. And in addition, Cilium have their Cilium Itzio implementation where they allow you to create L7 policies with Go-based filters. With Itzio, all the policies are implemented using Anvoy without the BPF. You can have Wasm extensions, which gives you a lot of power in expressing your custom policies. And Itzio also support things like external auth and has an Anvoy filter CRD that you can really customize what you need to get out of the Anvoy. As far as encryption, Cilium offers encryption between nodes, whereas Itzio offers MTLS between sidecars. As far as networking in load balancing, again, Cilium mainly is the L3L4 level, so you have pair connection load balancing, where Itzio on the L7 can give you pair request load balancing. As far as resiliency, if you're using the L7 Cilium with Anvoy, you have retries. Itzio exposes more of the Anvoy features, Adler detection retries, fault injection, and with Anvoy filter, you can really customize it and essentially use any Anvoy feature you want. In terms of multicluster, Cilium implements a flat network, a multicluster kind of mesh that joins multiple clusters together. With Itzio, there's various ways to do it. You can use Itzio with a flat network, but Itzio does not implement a flat network because Itzio is not on that level, on the L3 level. But what you can do with Itzio and something that we see a lot that organizations actually prefer to do is using Gress and Egress Gateway to connect clusters together. In terms of observability, Cilium offers Hubble, it sits on the Cilium agent on every node, collects metrics and Itzio, again, Anvoy. With Itzio, you can customize the metrics, Anvoy exposes it again using Wasm. Exislog, with Cilium, you have the L7 Anvoy implementation using Go filters. You can create custom Exislogs per protocol. So if you have your own custom protocol, you can create a Go filter for it and create some Exislogs for that. With Itzio, you can use the Anvoy filter CRD to add Exislogs to your sidecars. Service Graph, Cilium uses Hubble, Itzio uses Keali. They take the metrics, it traces and creates a service graph for you. Cool, thank you. So then the question is, what can we do about it? Because if you know solo, well, you know that we are not just doing a research, we usually act on that, finally. So what did we found and what will we do? So as I said, I mean, I think I will talk about it really quick, but in the nutshells, we have a product GlueMesh, GlueMesh is built for different, now five different extension. We, it's based on Itzio, we have a lot of custom filter for Envoy there and therefore we can do a lot of stuff in the Ingress, in the API Getway, as well as the Service Mesh, Itzio, and we have Devopo Portal and we have an extension with Wasm. And now we have also GraphQL as we announced in the keynote before. So again, I will go about that. But what is interesting here, what do we want to do with it, right? And I will tell you what we decided to do with this. So as you know, as we expand right now, there is layer three, it's still mainly focused on layer three and layer four. This is where it is, they're on the node, this is what they know, it's very local. SDR is more like layer four to layer seven. So what we did, we basically said, look, when someone telling us, right, in our product, in our global API, in the GlueMesh API, I do not want this container to talk to this container, we can do it in SDR, like we're doing it so far, right? Translation loop and putting a CRD. But we can also put it in Scylium and basically create these things, locks into all of those layers. So basically what we decided is, honestly, to ship Scylium with our product, make sure that if it's there, we're discovering it and we're taking advantage of in-thing there. Everything that's related to observability, we can give you way more metrics, more stuff that STO cannot give you. So both of them is amazing. What we're doing with STO today is basically managing, installing, upgrading, life cycle and so on. We do the same thing with Scylium. In terms of networking, honestly, most of the time there, it's make more sense to use layers, seven make more sense to use with STO. So read writers and all this stuff, it's actually make way more sense to use with STO. When we're talking about security and policy, we can leverage again both of them, right? And that's exactly what will happen. So basically when you ask us, I don't know, I want this observability, we will go and translate it to a CRD of STO and if you have there an interesting CRD of Scylium, collect the data, make sure that it's all forced for you, upgrade, install and so on. So that's what we're doing. Hopefully you'll like it. Check it out. And I don't think I even have an end slide. So I think we're done.