We're going to get back.
So next up we're going to have Daniel and Dave talking to us about orchestrating eBPF
applications in Kubernetes.
Hi, everyone.
I'm Dave.
This is my colleague Daniel.
We both work at Red Hat and we're here to talk to you about BPFman, quoted in Pheronics
as the world's worst superhero.
So what is eBPF?
Show of hands.
Let's do a show of hands.
Who knows anything about eBPF?
That's the best I've had in any room talking about eBPF.
I should have qualified that question, shouldn't I?
Very quickly then, BPF is a cool technology that allows you to do crazy stuff in the kernel.
So if you weren't a kernel developer before and didn't know how to maybe do something
crazy with networking, BPF works as a nice little programming toolkit for you to be
able to go and do scary things or sensible things with code inside the kernel.
So there are use cases in networking, security, observability.
There's a whole bunch of projects out there that allow you to do all of these things.
Essentially you load code into the kernel, runs inside a virtual machine if you like.
The code is verified not to crash the kernel when it gets loaded in there, which is a good
thing so it's a little bit safer than things like kernel modules.
And yeah, I think that's about it.
So you have your kernel space code that does the thing in the kernel.
You typically have some code that runs in New Zealand as well that does things like
reading data that you've exfiltrated from the kernel which gets stored in eBPF maps.
So you can do all sorts of cool things.
So why do we need a BPF manager?
Is it better now?
Hello?
Awesome.
Thank you.
Okay, let's recap.
So eBPF manager, what do we mean by an eBPF manager?
So these days we are getting and seeing a lot of different eBPF related projects or these
days say eBPF at some point within their documentation.
So you may see that we got Calico, we got Silium.
You can also see a lot of different monitoring projects such as Pixi, we know Kepler, you
know a lot.
So basically what is happening is at some point we need to, for the end projects to
coexist a little bit without being broken all along.
So what could happen, let's say you want to run an eBPF program, it goes as route, there
it goes, and then it runs another one, it overrides what we would as a route and so on.
And we wanted to have something that could make this a little bit more sense.
So getting back to there, I was saying that every eBPF program needs route access, so
you could either, okay you may say that okay but we got the capabilities.
So is there anyone here that is aware of CAP BPF?
Okay, not any, okay, we got one there.
Okay, thank you.
So far that's some kind of a trick because in the kernel, CAP BPF maps to CAP route,
so it's a nice naming but not that much on that.
Basically also you don't have any way currently of making sure that what you are running as
BPF, it's like it, so you can run what it is there and you're going to trust what you
have in mind.
Also getting back to networking, so this is your idea of running a CNI plugin such as
Cillium.
Those Cillium, those kernel ABPF hooks are explosive and the same happens for monitoring
for some of those.
So basically you need to get into that and see a little bit of priority.
We are going to be seeing that later about having two different ABPF programs with different
priorities and see how can we handle those with BPF man.
BPF man, getting back to there.
So originally this was named BPFD, we changed it because it's no longer a demon and we wanted
for people to somehow get used to that.
Everybody knows Portman and we want to basically people to get to know BPF man as well as we
know Portman.
Then goes to BPF man, Prudette.
So, BPF man is a nice source for that, surprise surprise.
It started in the room I worked in the Red Lab, the version of theologies.
So, we are starting to get some of the issues outside.
It's absolutely awesome.
So, as Daniel said, the BPF stuff is a privileged operation and what we really wanted to do
was to train people on privileged stuff outside containers if possible because then we don't
have to have containers that have privileges around like ages where the privileged stuff
just happened very quickly.
So, privileged stuff is down in the text.
So, you can actually just write out your intent.
I want this program to appear on all of my notes or only on notes.
I have this set of labels or whatever.
BPF man can then handle all of the orchestration for that for you.
And very recently we also started digging into how we can take some of the stuff which is in the
kernel which is really useful for hidden.
So, the BPF audit logs which are in audit D and pulling those out into open to laboratory
is log data.
You can train them off to your log storage thing and figure out if there's something going on
then maybe there's something that's happening in BPF at the same time.
We have an idea of what's up there.
And similarly with metrics as well, we're able to get metrics from the BPF system in the kernel
and bring those up into open to laboratory as metrics as well.
You can do the same graph, do whatever you like.
And I can go next because so far we spoke about BPF, we spoke about the operator part of BPF man
and so forth, but how about Fedora?
We said we're concentrating on Fedora and there was no Fedora being done over here.
So, first of all, how many, if there's any Fedora packages do we have in the room?
Okay, awesome.
You're going to be helping us.
So, we established a new BPF group like I guess from the last month of the last year,
2020-3 because basically we wanted to promote the usage of BPF
and see how could we package BPF applications within Fedora.
And we were thinking about, okay, BPF man is cool.
Let's go and get BPF man package within Fedora.
So, we identified it and started making the parts on how do we get BPF man in Fedora.
BPF man is written mainly in Rust and there's a self-contained change to add that to Fedora 40.
So, feel free to take a look if you want to.
I mean, those slides will be available.
But the thing is that currently you can go and start getting all the dependencies
that we have for BPF man in Fedora that those are really in Rust.
We are mostly using Rust to our PN, which you could say, okay, I'm getting a spec file.
I can just find no way.
We haven't been speaking at all about how do we handle that.
When you're packaging Rust programs in Fedora, you could do those in two different ways.
You could go the fast path, okay, let's bundle everything there.
Pretty much like the go way.
I'm not going to be caring at all about how the dependencies interact with all the packages in Fedora.
Or I'm going to go packaging all the dependencies and I'm going to be creating packages for all the dependencies in Fedora.
This goes with a few caveats though.
So, let's say one of the dependencies we have, as you can see here, we got a few dependencies,
meaning in Fedora, six store, Tony, we had a few packages in Fedora that were newer than what we were using.
That's super fine because we can just bump the dependencies and patch BPF man to work.
And we had also the other way around.
We had some packages that were too old in Fedora.
That means I can't just go by itself and bump them up in Fedora because I'm not a maintainer of those packages.
I need to go see who's the maintainer, speak to him so they bump that,
so those doesn't collide in Fedora at all with any of the packages we might be.
But let's just grab one quick example that we run into here in Fedora.
So, I wanted, let's say, one of those missing ones, six store.
Let's say, let's go and create a Rust six store package in Fedora.
If you start doing so, you'll see that you have like, let's say, ten more dependencies,
those ten more dependencies, grab you 23 more dependencies, and so.
So this been, let's say, a challenging issue.
You could say the dependency held a little bit, but we plan to address those for the final release,
even if we go to the bundle one in the beginning.
For those, we have been having a lot of help, mostly from the Rusty Group,
specifically Fabio Valentini, who's the Rusty Group maintainer.
He's been having a lot of help to us, but we are still missing a lot of Rust packages.
So if you have time to spur, please go and help us review all the Rust packages that we are maintaining.
Also, we also have another guy called Miquelon Sagasti.
He's also a good friend of Spain.
I mean, he does not do too much of a box-it-up job.
So thank you for that guy.
This is that. Of course, we are also open to anybody who would like to join the ABPFC Group
and who would like to join us helping on this effort, as much as maintaining
way more EBPF programs that could go in Fedora, such as Scribbr, Kepler, who's going to go next probably.
So basically, thank you for that.
Let's give them more time.
So let's see if we can go for that.
You want to come and do that?
Okay.
Okay.
So here is the DTF program.
I hope you like it.
It's totally clear, isn't it?
Yeah, I think we'll have to do that.
Any comments?
So this is a very, very simple program.
Effectively what's doing is counting packets that were received from a place.
Now, in reality, you'd want to be deploying them before it's like a load bar.
But just to say to them, oh no, this is a little bit more important.
So we can then match them to the container models with us.
So we have a base stage in our container file that exports the packages that we need to go to.
The DTF bytecode.
And then we have the user space part of the equation here, which packages up our user space application.
So remembering the fact that when I said that we're like user space is the DTF, the kernel is the base space of the DTF,
so user space is it.
Yeah, I can't make it any bigger.
I'll go with you.
Sorry.
We will share the link in the chat.
We'll charge the link afterwards, I guess.
Yeah, yeah.
There is a user space, and there is a kernel space.
The kernel space is basically a PID bytecode.
It is just one file inside of that.
And then some labels that we'll do.
We have to be using them on whether this should be like half or more.
An extension to the ASI is back on this example.
I wouldn't read any of that in the DTF stuff, but that's something we'll be figuring out as we go along.
Anything we can use our container engine of choice to go and build our things.
This is amazing, but fast, because we were working on that at a time.
What?
We use a pop-up interface.
We use whatever we can use.
We'll then go and question these resulting images of how to make a container registration,
because the other man's going to need to go and crash the machine.
So you can deploy your machine here, or you can deploy off the machine anywhere as long as you can access the internet to be called.
Programming container registry, that's a problem for us.
So, from personal experience, trying to develop a BPF program has been pretty handy
when we develop a BPF in the point of view.
So we can ask the DTFNR here, what's up? Are there any programs?
We'd be happy to say that at the moment.
We'll let you know if you'd mind to say, well, here's the one that we made earlier.
Please, you can go below this one in the department to get some things for me.
We've given it a priority of 10.
That's a meaningless variable.
Priority, we've given it a 1, and I think it's been 1 on TCC5, so it's a good one to give you.
That's what we used at the later part for sorting which programs should be running ahead of one another,
because we have some magical XTP stuff in the background here that allows you to sort of order your network programs,
which we've borrowed from a project called LiveX2P, which makes writing extra easy to use.
So BPF man's got the latest on program for us,
and now we're going to verify the list there, by listing it to this,
and then we're going to run our user specs bit.
We're not using any of the data just because the CD is just running here.
It's going to have a look into single panels telling it how many packets we've received,
how many bytes we've received, so we can see that the program is working.
And then we can go ahead and load another program.
At this time, it will be priority one, so we would go ahead and load that, but that's a little bit tricky,
so we did it to sort of eliminate it.
But in the end, yes, it's a loaded, and then you move to see the program here,
which we want to run in first and the first, and then add a program.
So there we go.
So just to talk about how we can take a BPF program in here,
how we can take it, deploy the CDF man on the client,
like we could also do, so we wanted to make sure we had time to demo that as well.
Yeah.
All right, that's it.
Yeah, so basically, I guess you like that thing here.
I just wanted to basically introduce you to this new BBA program.
Please, please, please help if you want to take a look at the rest practices.
And I guess we didn't have one slide, but we can just go for the Q&A.
Any questions, guys?
Can you see the CDF man?
Sorry?
Can you see the CDF man?
Because they have a lot of programs, examples of how you can get it from there.
Can you see that?
Yeah, I understand.
I just don't have a microphone.
Yeah, we'll go.
Let's take a look back.
Yeah.
Yeah, take it.
Right, so we, BPF man itself is written in Rust and is backed by a really awesome pure Rust library,
which I also happen to maintain called IA, which is amazing.
Hopefully there's some IA contributors here.
Yes, thank you.
All right, one, that was good.
So our entire stack is Rust.
However, the BPF program that you write, you can do in C with libbpf,
you can do in Cillium with go.
This example program that we've run is using Cillium, BPF and go, and BPF to go,
and all of that tooling.
Okay, that is a really, really good question.
So I will preface this with I am not a lawyer, obviously.
However, basically 99.9 ish percent of BPF code will be GPL.
The reason for that is all of the useful BPF helpers that you will call are GPL only.
Therefore, has to be GPL.
But that is just the BPF code that gets run in the kernel.
There is a really good document on kernel.org that explains BPF licensing,
which was written by lawyers, and effectively you can load your code into the kernel,
and anything that goes and talks to that doesn't effectively get touched by GPL,
so you're basically fine.
Can you please just have us load your program to then enter it into the copy?
Yep.
So the bit in the kernel will be GPL.
You use the space bit, can be whatever you want.
Obviously, if you're copying example code from Cillium or whoever else,
double check the license.
A lot of the Cillium examples, I think, are GPL plus BSD2, something permissive
that allows sort of reuse and copying.
So...
We're just packaging, effectively.
That's all we are.
So, no, no, no, write your program however you want,
and we'll just help with the packaging and deployment,
whether it's on multiple Linux nodes, whether it's Kubernetes, whether it's anything else.
So, the owners are still on you to write the code,
and then we'll help you package and deploy it.
So basically that depends.
Just think of some kind of a proper tooling to go and run your code in an easy way.
But whatever you run there, it depends on you.
So if you want to go load, no.
A non-GPL v2 or non-GPL whatever license you want to go, that depends on you.
So we ourselves are GPL, but we call it a Pachi,
and we call it a license, but that's a Pachi.
But the thing is that besides that, it's like if you are just running whatever application
on another program, that's a different thing.
Yeah, so I'm saying that the tooling itself, ours, it's a Pachi.
But whatever program you want to run into it, it's up to you.
So in terms of licenses and so forth, that would depend on whatever you want to do.
So if you want to run some sealant samples, that would depend on the sealant license.
But if you just want to run some proprietary thing, that's up to you.
Thanks very much.
I'm sorry.
Over there.
It's all the way there.
One way to go.
I think we call it whatever you want to do with the other parts.
We can hear it all, sorry.
Sorry, maybe, maybe, yes, come over here, no worries.
Yeah, come over here.
Yep, thank you.