So I voted on you, however, I worked with her and I actually have been following you before
I worked with you as being that awesome person who did something with chickens and go, is
that correct?
You should enable your microphone by the way.
Yes, sadly I heard there are no chickens here today, that's for the tiny go people at the
last hour of the day, we have a tiny go-com, I have been told there will be no chickens
but there might be fireworks which I have to forbid because of fire regulations.
Here's another warning.
But I'm going to let you go then you have to talk about the amazingness of something called
EVBF that already has been mentioned five times a day, even without an EVBF talk.
So I've lost!
Hi everyone, can you hear me well?
Yes, good, okay.
So let's start with a quick poll, who has an Android phone here, can you raise your hand?
Yeah, most of you.
I mean, that was kind of obvious for the first time I guess.
So let me tell you that you are running EVBF every day on your phone and without
knowing it, it is there for networking and statistics about your network.
You're not observe, but you might wonder if EVBF is everywhere, yes and no, so it's running
on Android phone but it's mainly present today in tools in the cloud native environments.
I'm Dunya Shai, and today we're going to cover what is the role of EVBF in Kubernetes
and in networking using Go.
How is the word without EVBF?
So if you want to add a feature to a turbine application, you would probably have to
probably have to ask someone from the Linux kernel development to add something in it and
it can take years before this feature will reach the Linux distribution.
I say years, yes.
So with EVBF, you can dynamically update and write custom programs on your kernel.
In fact, you just have to write an EVBF program and just a few hours, maybe even a few
minutes, you are able to observe what's on your network on your kernel.
Let's have an overview of EVBF.
So you have an application running in the user space.
So I guess most of you are developers today and go developers, yes.
So you are running an application in the user space and you are doing Cisco system calls,
like opening a file or allocating memory, all these things or events on the Linux kernel.
And EVBF programs can be attached to this event.
So each time, for example, you are opening a file and EVBF program will run automatically.
But let's have a quick example of a program where you can trace when files are open.
So now you are seeing C code and you're like, what is she doing?
Why is it C code and a go code?
Yes, you will probably have to deal with C code if you want to write EVBF programs first.
So let's have a look, it's very basic.
So this C program is attaching, is being attached to one trace point in the system kernel.
And this C code is, is enter open at.
It means that each time you are opening a file on your system or with your application,
this EVBF program will run automatically.
And we are just logging file opening a very simple log using a helper, VPF, right, spring
like a print, a land or a print function in go.
And the output when this program is logged with all the traces, file opening,
and we can see here the process IDs.
So there is the cat that I'm actually launching in the trace file.
So this is where all the logs from the kernel are going.
And system did run all, because the kernel is opening file all the time to actually run.
So it's also opening file.
Let's have a quick demo.
Hopefully the demo will work better than the previous talk.
So here I have a bunch of files, but I have my C file that I just show you.
And I will show you later in this talk how you are going to attach them.
But I just want to show you what it looks like.
And I'm using pseudo here for one reason is that two launch EVPF
program and to run them, you need specific capabilities.
So that's why I'm running like that.
And on this side I'm just going to do a cat of the logs.
And can you see well?
Yeah, it seems okay.
So we are seeing all the logs from the cats here.
File opening.
So you can see that there are a bunch of file open.
It's actually going in real time.
So what you're seeing all the traces or the fine-being open in real time
with this little code.
So that's very powerful.
I mean, I find it fascinating.
I don't know what you're talking about.
And this is one of many of the capabilities of EVPF.
And I want to talk to you about my favorite one, which is ETP
for Express Data Path.
So with XDP, you can analyze and filter packets before the even
rich delinux kernel network stack.
So for example, if you have malicious packets that are
arriving on your network, they can be dropped before
it reads the kernel.
It reads actually your system.
So it saves CPU cycles.
It can save also memory and avoid some vulnerability,
vulnerability, sorry, and problems.
So very powerful in XDP.
And it takes the performance in general to an next level,
especially in distributed systems where the requirement of performance
are really high.
And that's why we're talking about Kubernetes here.
Kubernetes is at the foundation of cloud-native environments
and distributed system.
How many of you are familiar with Kubernetes and running it?
OK, and not as many as I thought, honestly.
That's interesting.
OK, so Kubernetes is built on shared infrastructure.
You have many containers running on a single host,
meaning on a one kernel.
Because EVPF programs are running at a kernel level,
they have visibility on the entire stack.
They're unlimited to one container.
So all the EVPF programs can act and modify and observe
what happening on all the posts across one host.
And there are many use cases like networking.
You can actually load balance, for example, traffic.
You can do security by dropping malicious packets
and forcing security or doing observability and tracing,
like we just sew with the file opening.
But what makes EVPF even more exciting is all the ecosystem
that exists today.
There is a forum of EVPF today.
But there is many tools like BCC for tracing or a
sealium between networking and security and pixie
for observability.
All these tools already exist and are using EVPF
under the hood to do all this amazing thing,
like tracing, profiling, monitoring, and more.
Let's have a look to a quick example using sealium.
So sealium is doing efficient networking.
Thanks to EVPF.
So in clusters, we have the posts and the most communicating.
It goes through a bunch of things in the traffic,
but especially goes through the chain of holes of IP tables
to define where a packet come from and where it should go.
And instead of doing that,
sealium is using the power of EVPF by attaching
these programs to specific hooks in the kernel
and bypassing all this chain.
So all the traffic is going to be very fast and efficient
in that way.
And it's again very interesting for very large distributed systems.
Because you're going to be able to run a lot of requests
in a few milliseconds, for example.
So you have an overview of EVPF now,
but you might wonder, how does it even work under the hood?
So let's have a quick look, very with me.
So we have first an EVPF program that is going to be compiled
into bytecode.
bytecode is what the kernel understands.
It's 0 and 1, basically.
And before you can actually attach it to system calls
to hoops and tracepoints, you would have to go to one critical step,
which is the very fire.
And the very fire acts as a gatekeeper.
It ensures that you won't crush your kernel because you're
running programs that are running on your kernel.
You could have a blue screen and just crush your system.
And you don't want that, especially on our systems.
And this very fire would check, for example,
that you'll program exterminating loops
or that you're not doing outside of the bone memory allocation,
like very basic stuff, very interesting.
When your program is approved by the very fire,
you have the just-in-time compiler actually
compiling it and doing some optimization, depending on your hardware.
And finally, you have your program that can be attached
to the system calls.
Then all the processes that you are running
would be able to send messages and receive them.
And each time there is an event and the EEPF program is attached to,
it's going to actually run automatically and dynamically.
It can be socket, TCP or EEPF network device.
OK, we are talking here to developers.
So let's talk about development.
So as I mentioned, you would have to write probably C.
I know that a bit sad.
But not too much.
You will have a C code that you compile into object into byte code,
and you can use clank for that.
There are specific compiler to do it.
You could write it into byte code if you like to,
but I mean, no one does.
It's only for the kernel.
You would probably write in C.
So this is the most traditional way to do it.
For several reasons, but mainly the ecosystem
is already built nowadays on C.
There are libraries available.
You can handle all the resources precisely.
And if you're a cool kid, you're going to go to Rust.
But so it makes the concurrency easier than C.
And there is memory safety.
Just you know, the ecosystem is still in maturation and evolving.
There are not as many other sources,
but the compiler is able to compile the EBTF program into byte code
that is understand by the sub-bite kernel.
And so you have your program.
You're writing it.
So you might wonder where I'm storing data because yeah,
I can see traces, but I want to handle that at some points.
Like if I'm doing, for example, counting packets
going through my network.
So this is where maps are coming.
So maps are at the backbone of EBTF programs.
This is where you will share all this data and store them.
There are different type of maps.
Actually, 30 of them with different types.
But I mean, probably you will use hash with basic key values,
but very powerful.
And there are the bridge between the Linux kernel and the user space.
So you would be able to write data into the map from the kernel
and read it from the user space.
Or you have something in the user space that you want
to inject to the kernel and then be able to read it from there,
you could also do.
And the code in the user space is able also to load the byte code
and the program.
I hope it makes sense for you.
Are you lost?
I can feel like, no, that's OK.
People are saying, yes, OK, cool.
So the user space in the user space
is code that you're going to run and writes.
It can be written in C, but you might not write it again.
You can use Python because it's more high level
and their libraries.
But I would recommend it for more exploration and experimentation
if you want to get your hands dirty at the beginning.
And of course, I'm not going to convince you.
But you're already good developers.
You would probably choose go for its simplicity and its performance.
There are libraries that exist also today to use it with EBPS.
I mentioned only three of them here.
There are others that you can have a look to.
But there is VBPF, go and go BBPF.
There are actually based on C go.
So as you may know, you don't want to use C go.
But a C go and you can actually load an attached program.
It's very easy to integrate with the ecosystem existing already in go.
Because you might know, but in Kubernetes environment,
all the tools around flood natives, most of them,
or built in go, like Grafana, Prometheus, and all these tools.
So that's very easy to integrate an application that you would like to deploy with that.
Let's have a look to another example, the concrete one,
where we are doing monitoring.
So we, oh sorry, first I'm going to show you some code.
Again, some C, sorry.
So we have a map.
So we talked about map, and I'm going to show you a concrete one.
So here I'm using a map type array with a key and a value
with a max entries of one.
Because what I'm going to do is to store for the number of,
for each time there is a packet going through my network,
I'm going to increment a counter.
Very basic.
So my function here is just doing map hook app elements.
So this is a helper that you can use.
And it's going to increment this packet counter,
each time there is a new packet.
And because I'm attaching it to my favorite feature,
do you remember XDP that I just mentioned?
Each time there is a new packet, this counter is going to be incremented.
OK.
So I kind of like you.
So I'm not going to use client directly.
I'm going to use bpf to go to attach my program.
It's a tool from clmvpf, and it makes the life easier
as a go developer.
So you have your c program, and you're going to generate
go objects from that.
So you can use the programs on the maps very easily in your go code
and manipulate them.
So I use here go generate because it's easier when you are
developing and maintaining some bpf code and go code.
This is the generated go objects from the comments.
So this is only a sample of them.
There are others.
But here we have a counter objects.
So inside we have a counter programs,
counter maps, and counter variables.
And inside the program, I have actually my program, my bpf program.
Here, this trip tag, it's very important because it
is the actual name of your program inside the kernel.
So it makes a link between the go code and the kernel objects.
And then we have the maps.
So there is only one, but if you have many of them,
there will appear also here.
And again, this is the name of the map inside the kernel.
And you have finally the main.
And in the main, what you're doing is loading all these objects.
By using load control objects here,
this is, again, a function that has been generated by the bpf
to go to.
Then I just define my interface network that I'm going to use here.
It's integral.
And this help function not at hxdp, which
is in the cilium edpf library that you can see in the imports.
So I'm using in the option the programs that we just generated
and the interface.
And this is the way to actually attach my program,
ebpf to my go code.
Just one thing here, the differ, it's kind of important because when you
close your program, it's going to detach your program.
So you don't have it running and be attached all the time.
OK, this is just the last part of the main function.
It's just fetching periodically every sequence, the packet count.
And we are using lookup function on the map,
on the packet count.
And then we just print it here.
Very easy.
OK, let's have a look in real time.
Again, so here I have, let me show you.
Can you see well again?
OK, so I have my c program here that I just show you with my map.
It's dp, my counter, it being incremented.
I have my main that is not currently compiling because I need to
generate the go objects.
I had it, sorry.
I had it before.
So go generate.
Now that I generated my objects, let's have a look to what it looks like.
I have actually began in a little Indian depending on your architecture.
But you can see here a bunch of things.
Don't worry, what is important is to find again the objects
that I just show you in the slides.
And in the main, now it's compiling.
We can see the load counter objects, the interface, and the attack
XPP. I'm not cheating.
I'm showing you the real things that I just show you.
OK, so now I have this, I want to build.
Let's meet.
So now I have my executable here, my binary, and I'm going to launch it using
against you do.
Yay, it's working.
So thank you.
So as you can see, you're seeing the number of packets that are going through my
network in real time.
So we built a C programming the kernel.
We wrote an application in the go code.
And we retrieved all these data from the map in the kernel.
And we are showing it in the user space.
So that's very powerful to extract all these data from the kernel
into the user space.
I hope you enjoyed this demo.
Now, I want to show you more concrete examples.
So this is very basic things and little files that I just show you.
And I want to show you in real life in a project
what the code couldn't look like.
And as a disclaimer, sorry for the eyes of a Latatisco people.
This is not the real code from Selium.
I just put some pseudocodes, so you have an idea.
If you've seen some of the talks today about EVPF and STDB,
you know already that it's more complicated than that.
That was just a disclaimer.
So Selium, it's an open-source project
that is enabling network policy enforcement,
doing services load balancing and more stuff.
But we're going to focus on network policy today.
It is using the EVPF programs to do it.
And we're going to have a look.
So first, we're going to declare a YAML file,
and not Elvis, a YAML file to declare the Selium network policy.
So what we are doing here is just saying that all the inputs
with the labels matching back-end.
So endpoint is a pod for the people that doesn't know it's a resource.
And sorry, I'm going to say it again.
So we have a pod that has labels matching back-end,
and all the traffic coming from the pods
with the labels matching front-end are allowed.
Otherwise, all the traffic coming from external,
I don't know, and you would like to contact the back-end,
cannot.
I mean, this is a very common use case.
You don't want anyone to communicate with your back-end,
and only the front-end.
So in the code, what it looks like.
So I will have something called an endpoint
with an ID, labels, and identity.
Because in Selium, all the pod's other resources
are transforming to identity.
An identity is a set of labels.
And here, I have two end points.
So two identities with the front-end and the back-end.
So this is my set of labels.
I, for the sake of this example, I put only one,
but you could have several of them.
And then you have a policy with a source identity,
and it's one, and the destination identity,
which is two, the front-end and the back-end.
And we say that is allowed.
It's true.
You could say that it's denied and safe-falls.
It depends of what you are dealing with.
Then we have in the EBPF map code,
all the policies that are stored in a map.
So we can do it from the GoCode.
So you define a map in the kernel program,
in the EBPF program, and from the GoCode,
you are injecting dynamically all these policies
that you are defining in the YAML configuration
and deploying live on your cluster.
So again, everything is dynamic in real time.
So for example, if you want to mitigate a vulnerability,
you could actually deploy a configuration
and a telemetric policy in real time.
And finally, you enforce these policies in the EBPF program
by saying, if this source identity to this destination is allowed,
in that case, I'll let the back-end paths
otherwise we drop it.
I hope I sparkled some curiosity,
and you'll learn a lot about EBPF.
Either you want to contribute to EBPF and Selium,
or just add some little EBPF in your day-to-day life.
I would recommend to go to the lab from ISOValant
to EBPF getting started.
This is where I started.
You don't have to set up an environment.
You just pop a cluster for you with all the dependencies
that you need.
So that's very cool.
And all the examples that I show you
are available on my repository.
And I would love to connect, get feedback,
have your point of view about EBPF.
There is an EBPF room.
So if your career is next year, you can go there.
And thank you so much.
applause.