Home
Contribute Contact Us Browse all meetings
Home Contribute Contact Us Browse all meetings
Cloud Native Computing Foundation / ServiceMeshCon EU 2022 / 19 May 2022
Cloud Native Computing Foundation / ServiceMeshCon EU 2022 / 19 May 2022
Previous Meeting
Next Meeting
⏯
Add meeting Rate page Subscribe
youtube image
►
From YouTube: Cilium Service Mesh - Thomas Graf, Isovalent

Description

eBPF is a powerful Linux kernel technology that is used in several CNCF projects to provide faster networking, new security applications, and deeper observability. In this talk, we explore how eBPF, using the Cilium project, allows you to build a service mesh entirely without sidecars while still relying on proven Envoy proxy technology. We will look at how moving service mesh functionality into the kernel using eBPF leads to massive performance gains and simplification of the overall model while remaining compatible with existing control planes. Service mesh will become invisible at the kernel level similar to how namespaces, the foundation of containers, are invisible today. The sidecar-free model unlocks a simpler architecture, performance gains, scalability advantages, and even more transparency to applications. Together, we will look at the new architecture, compare performance numbers, and run through a demo.

A

All right welcome back everyone. It's me again. I will be slightly less fun than last time. I'm sure my apologies to anyone who arrived late and doesn't know what I'm talking about. Apparently, there were some av issues, I'm not sure whether it was recorded that suits me just fine. We were here to break the ice, especially for the people in the room, but this afternoon I'm here to talk about something which is more important and more relevant to everyone which is ebpf.

A

It is the panacea which will solve all our woes or it is something which just makes life a bit easier and only is for vendors to think about and isn't relevant if you're an end user. It could be one of those things. There's an angel on this shoulder, there's a demon on that shoulder first up, I would like to invite the angel to give a talk. Thomas graff is the cto and co-founder of isovalent, who are the creators and sponsors of the psyllium project, of which he is a creator and maintainer.

A

He is also chair of the governing board of the ebpf foundation. He's going to give us the four argument on the case of ebpf over the course of the next 10 minutes, we will hear the against after that. So please join me in welcoming thomas.

B

Thank you greg hello, everybody. My name is thomas, um maybe adding to the intro. My background is a kernel developer.

B

What the heck is a kernel developer, doing at the service mesh conference, what we have been creating psyllium, which is a clown native cncf project, providing networking security and observability and we're doing this with ebpf, we're being run by lots and lots of different users. I've listed a couple of them here, including major cloud providers, gk eks, digitalocean, alibaba,.

B

Large sas companies and so on, and what we have been hearing loud and clear from our users is: can you bring this magical ebpf technology to service mesh? Can you make it a bit simpler? Could you potentially get rid of sidecars? We love service mesh, but could you simplify the data path piece? So maybe we can- and this talk is exactly about this. So what is ebpf- and I will keep this very quick- I have 10 minutes.

B

I don't want to bore you with kernel level, technology, lower level details, but in a nutshell, ebpf makes the linux kernel programmable. The easiest one sentence description to describe it is what javascript is to the browser. Ebpf is to the linux kernel, so we can load. Ebpf programs in this picture we're seeing example that we run an evpf program when a system call is being performed, but we can perform this for a variety of other events, network, packets, sockets events, security events and so on.

B

Our entire security systems being built with evpf, for example, google's project zero team is working on lsm bpf to secure linux. Further.

B

We've also released tetragon a couple of days ago, which provides the runtime side of observability, um and enforcement. Evpf is definitely not something that is only used by vendors. Ebpf is powering giant data centers, including, for example, facebook, slash, meta data centers in terms of dds protection load balancing.

B

If you have an android phone you're using ebpf every single day, all of the accounting of traffic management is done with ebpf ebpf is everywhere, but usually you cannot see it and our goal is that with service smashing ebpf, you don't have to see it either. We want to optimize the data path.

B

Something that's very very important. Psyllium does not require you to choose side, car or not sidecar. In fact, we have an istio integrations that existed even before istio 1.0 several years ago, which allows you to run psyllium and istio separately, and the layer 7 policy that selim supports will be enforced in the sto side. Cars in this model we're also able to accelerate and secure istio. What is new is option, one where we're looking to implement a data path that is entirely built with ebpf and envoy.

B

That does not require a sidecar; it still requires a proxy at times, but it's not necessarily one proxy per part. We'll talk about this one example that I'm using um where, where I can show how evpf can add value to to istio today as an example, this is one of many is with sitecore injection. On the network side, there is actually clear text between the app and the sidecar this. This is the arrow that we see going through the stack and for security teams.

B

That can be a problem, because anybody with capnet admin privileges will have accessibility on the clear text, as we announced in 2018 at envoycon, we've built sock map which allows to accelerate and secure the connectivity from the app to the sidecar, and this clear text is never hitting the wire it's there's. Never a single network packet being created and thus compliant security team is actually fine with it again and it allowed customers of us to actually run istio.

B

Even though, um even though there was previously clear text information on the loopback device, if you look at service mesh, what we want, observability security traffic management resilience.

B

These things have existed before on the networking layer, and I've listed a couple of tools here, but it's very clear that they are falling short of cloud native principles and requirements today.

B

What we need, in a nutshell, is elevate all of that to layer, seven, but at the same time we cannot forget about layer, the layer for the pure networking level. So I think what we want is a service mesh that combines the old world the networking world with the new world of service mesh, while providing observability security, traffic management and resilience service mesh origins. I think you all understand this in order to overtake to to fix these issues. The first approach was to build this type of functionality into the apps themselves.

B

This was not really feasible because you had to put it into every single application framework. So side cars were an obvious solution. Out of this, sidecars have a couple of shortcomings, very complex network injection, and you have to run a lot of side cars. This can become a problem at scale.

B

We're not claiming we're not saying that sidecars is never an option. It's definitely a great option for many many use cases. In some cases the performance, penalties and the efficiency can become a bottleneck for you and you might be looking for an alternative and for those users we want to provide a sidecar free alternative.

B

So we are essentially introducing psyllium service mesh. What is the goal of psyllium service mesh? We want to provide a side card, free data path whenever possible, so use ebpf, natively and we'll talk about when to use ebpf and when not, and if that is not possible, technically fall back to envoy.

B

We want native network and latency in terms of performance, and we want mtls support that can support any network protocol. If we use mtls or tls as the the protocol for both authentication and transport were pretty much limited to tcp, they can be done otherwise, but it's really hard. By separating them, we can support any network protocol with mtls.

B

Also we are offering and providing a crd where you can essentially inject on void configuration anywhere anywhere into your network, very important. We don't want to invent yet another control plane. We actually want you to bring whatever control plane. You have or want to use whether this is istio mtls, maybe just gateway api, maybe just kubernetes services and ingress with annotations, spiffy, even linkedin could be made work, it's a little bit harder because it doesn't use onward and then also important. We want to integrate with observability tools that exist, prometheus and so on.

B

Psyllium, hubble and tetragon already support this.

B

Essentially, what we want to achieve is something like this, which is as we look at through this evolution from built into the app side car built into the kernel and we've kind of done that before, if you think about virtual machines to containers, we've done that before and we've made the linux kernel, multi-tenant aware from that perspective, we're looking to apply the same principles and bring the same multi-tenancy controls into envoy and into the kernel how that will look like technically, I cannot explain all the details in one minute, but essentially we will integrate envoy as part of the kernel stack and run envoy listeners per thread in a separate c group off the pod, so cpu accounting will still be accounted to the c group to the to the to the cpu quarter of the of the part.

B

This allows us to have no side cars. No network injection no need to stop envoy no need to start on way on pod, on pod, startup and so on.

B

I'm going to make this my last slide because we're already almost out of time, what can we do in each pbpf natively and where do we still need a proxy there's, a lot of things that we can already do in ebpf natively traffic management, l3 l4, forwarding, low, balancing canary topology, routing multi-cluster network policy, mtls tracing open, telemetry, metrics, hdb parsing? What we cannot do are things like layer, 7, load, balancing, re-twice layer, seven rate limiting tls termination origination. For these things we still uncheck the proxy, but not two proxies. We inject one proxy.

B

In most cases, not two sidecar proxies. The benefits of this can be great um on the left. Here we see the performance difference in hdp parsing between bpf natively and a sidecar, and with that I'm out of time, so I will leave. I think, questions to the outside hall hallway track. If you are interested in ebpf, if you're interested in running a service mesh with outside cars feel free to catch me outside and happy to answer questions. Thank you.