►
From YouTube: eBPF and Kubernetes: Little Helper Minions for Scaling Microservices - Daniel Borkmann, Cilium
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
eBPF and Kubernetes: Little Helper Minions for Scaling Microservices - Daniel Borkmann, Cilium
eBPF has come a long way in the Linux kernel and is gaining more and more adoption and popularity in the context of Kubernetes in the networking, tracing and security space. In fact, it is changing the way we think about operating systems by opening the doors to fully customise the Linux kernel as a platform. Given the rapid pace of development of eBPF in the kernel, it is often times quite challenging to keep up with all the exciting advances coming from the eBPF community. This talk provides a deep dive from the perspective of one of the eBPF co-maintainers and core developers in the Linux kernel of where we came from, where we currently are, what the future brings, why eBPF has cloud native roots and how Kubernetes users can benefit from all that. We will cover the user space landscape around eBPF as well as its inner workings and interactions with the rest of the kernel.
https://sched.co/ZemQ
A
So
let's
dive
right
in
kubernetes
is
basically
eating
the
world.
Today,
more
and
more
enterprises
are
moving
over
to
containers
and
basically
kubernetes
is
regarded
as
d-cloud
os
these
days
and
underneath
all
of
that,
there's
the
linux
kernel
as
a
base
foundation
to
provide
all
the
building
blocks
for
kubernetes
itself,
but
also
for
the
containers
in
terms
of,
for
example,
c
groups,
network
name
spaces
in
some
of
the
core
critical
parts
for
those
deployments
they
are
delivered
to
a
so-called
cni
networking
plug-in.
If
we
take
the
networking
angle
as
an
example.
A
So
what
does
this
cni
plug-in
in
kubernetes?
Do?
Basically,
it
provides
general
part
connectivity,
and
that
means
when
kubernetes
is
basically
spawning
a
new
part
that
cni
plugin
is
then
creating
network
devices
moving
them
into
the
new
network,
namespaces
and
also
assigning
ip
addresses,
routing
and
so
on.
Basically,
it
manages
even
several
ip
addresses
an
ip
address
pool
and
some
of
the
cni
plug-ins
also
take
over
kubernetes
service
handling,
in
that
they
provide
load
balancing
for
services
and
as
well
as
network
policies,
given
all
that
can
be
quite
complex,
they
also
offer
monitoring
troubleshooting.
A
That
means
people
are
running
more
and
more
parts
in
the
same
node
and
the
other
one
is
decreasing,
the
part
lifespan
even
down
to
seconds
or
a
fraction
of
seconds
for
their
workloads.
There
are
some
interesting
user
survey
reports
that
also
back
up
this.
This
data
there
are
challenges
from
the
operating
system-
kernel
side,
of
course,
with
that,
because
the
linux
kernel
or
general
kernel
has
to
keep
up
with
all
the
performance
in
skylab
scalability
requirements
that
users
have
in
their
data
center,
as
well
as
the
increasing
complexity
of
kernel
subsystems.
A
One
issue
with
that
is
that
linux
kernel
is
not
allowed
to
break
user
space.
That's
of
course
a
good
thing,
but
that
also
means
that
we
have
to
keep
all
the
old
legacy
from
five
or
ten
years
ago
around
and
keep
it
functioning
so
that
we
keep
applications
working,
and
that,
of
course
makes
the
kernel
more
complex
and
it
can
affect
the
fast
path
as
well.
A
A
He
says
he
can
work
with
crazy
people,
it's
not
a
problem,
but
they
need
to
sell
their
crazy
stuff
with
non-crazy
rational
arguments
in
small
well-defined
pieces.
So
when
he's
asking
for
killer
features,
he
wants
actually
to
he
wants.
Actually
those
developers
to
log
him
into
a
safe
and
cozy
world,
where
the
stuff
that
they
are
pushing
is
useful
for
core
kernel
developers.
First,
in
other
words
like
those
crazy
features,
should
be
wrapped
as
a
torch
and
horse.
A
They
should
look
obviously
good
at
first
sight
and
that's
pretty
much
what
happened
to
ebpf
back
in
the
days
when
it
first
got
merged.
So
it's
a
crazy
new
kernel
feature,
but
in
the
long
term
for
the
linux
kernel
it
actually
reduces
the
kernel's
feature,
creeping
normality,
because
all
the
weird
corner
cases
that
users
have
and
ask
from
the
kernel
instead
of
having
them
hard
coded
in
the
kernel
and
potentially
in
the
kernel's
fast
path.
A
A
A
Those
bpf
instructions
that
have
been
generated,
and
they
are
passing
inside
the
kernel
to
a
bpf
verifier,
which
makes
sure
that,
for
example,
memory
access
is
not
happening
out
of
bounds.
It
cannot
crash
it
or
loop
forever
or
all
these
sort
of
things,
and
once
it
determined
that
the
program
is
safe,
it
will
be
just
in
time
compiled
in
order
to
generate
native
code.
A
That
can
be
run
on
the
underlying
architecture,
for
example
x86
and
in
order
to
share
state
bpf
programs
can
use
so
called
bpf
maps.
Those
are
shared
storage
that
is
accessible
from
bpf
program
site,
but
also
from
the
users
based
site
and
bpf
needs
to
be
triggered
to
an
event
and
in
case
of
networking,
which
is
the
example
here
that
event
is,
of
course,
network
packet.
A
So
network
packet
basically
triggers
the
execution
of
the
bpf
program.
The
bpf
program
can
mangle
the
packet
it
can
forward
it
and,
in
the
end,
it
returns
a
verdict.
So,
aside
from
forwarding
what
is
also
supported
is
dropping
or
pushing
it
up,
the
stack
or
and
so
on,
and
the
crucial
part
in
all
of
that
is
again
that
it
cannot
crash
the
kernel.
It
is
as
fast
as
a
kernel
module
and
it
provides
stable
api
guarantees.
So
what
does
that
mean?
A
It
basically
means
that
when
the
ppf
program
keeps
working
on
an
old
kernel
version,
it
will
also
continue
to
keep
working
on
a
new
kernel
version
without
having
to
change
the
program
itself.
It's
similar
to
user
space
like
the
contract
that
the
kernel
has
to
use
this
base,
where
we
don't
break
applications
and
kernel
updates.
This
similar
thing
is
happening
for
the
ebpf
world,
for
example,
for
the
networking
case,
how
does
the
packet
flow
look
like
in
the
traditional
case
of
kubernetes,
where
it's
using
the
cube
proxy
component
in
order
to
handle
kubernetes
services?
A
A
Then
it's
like
pushing
this
the
packet
to
the
traffic
control
ingress
hook,
and
then
all
these
orange
boxes
are
net
filter,
ap
tables
related,
so
there's
pre-routing
hooks,
then
there's
the
actual
routing
lookup
it
determines
that
the
packet
needs
to
be
forwarded
to
a
different
networking
device.
Then
there
are
just
post
routing
hooks
again
tc
egress
one,
and
then
it
can
determine
that
the
program
has
to
go
through
a
local
part.
A
So
psyllium
would
allow,
with,
together
with
the
ebbs
with
its
ebpf
data
path,
to
accomplish
that,
and
it
can
even
go
crazier
than
that
in
the
sense
that
you
could
forward
those
packets
to
remote
service
endpoints
at
the
xtp
layer.
That
xtp
box
basically
called
the
express
data
path
and
it
allows
for
running
bpf
programs
inside
the
driver,
layer
and
forwarding
it
them
directly
from
there
without
having
to
push
it
up
to
stack.
So
we
can
save
all
the
additional
overhead
and
be
super
fast.
A
So
how
did
it
look
in
the
very
early
days
of
bpf,
so
basically
we're
speaking
about
pre
2013.?
You
can
consider
it
as
the
sdn
landscape
for
linux
at
that
time.
If
you
will
so
back
in
the
days
there
was
openvswitch
project
or
called
obs
the
traffic
control,
and
also
the
net
filter
subsystem
consisting
of,
for
example,
ip
tables,
ipvs
nf
tables
was
there
back
then,
and
those
allowed
you
to
let's
say
program.
A
There
was
also
a
future
creep
and
often
also
code,
duplication
between
tc
and
net
filter,
because
both
subsystems
were
sort
of
competing
with
each
other
and
open
research.
Back
then,
was
considered
like
the
most
advanced
data
plane
in
the
networking
stack,
but
it
didn't
integrate
well
with
networking,
and
it
was
also
considered
as
sort
of
a
frankenstein
by
other
core
developers
so
yeah.
So
how
does
it
compare?
A
Those
subsystems
still
exist
today.
So
how
do
they
compare
to
ebpf?
You
can
think
of
it.
This
way
that
open
with
htc
and
net
filter,
they
allow
you
to
program
the
data
path,
but
only
if
the
data
path
knows
what
you
want
to
do
only
if
those
concrete
building
blocks
are
in
the
kernel
as
code
and
ebpf
instead
lets
you
freely
create
that
data
path
instead,
because
you
provide
everything
through
a
bpf
program.
A
So
the
extended
bpf
that
initial
first
patch
set
was
presented
by
alexis
the
wrightof
back
in
the
days
in
2013
as
a
big
patch
bomb.
It
was
like
caused
plenty
of
discussions,
but
it
was
considered
too
intrusive.
Back
then
also
nf
tables
was
sort
of
on
the
rise.
It
was
inspired
by
the
old
epf
that
tcp
them
had,
and
people
weren't
quite
happy
because
it
would
like
that
patch
said,
would
add
another
bpf
interpreter,
so
two
would
have
to
be
maintained.
It
was
sort
of
a
hurdle
and
it
eventually
got
rejected.
A
So
you
can
see
that
here
that
linux,
the
linux
crazy
rule
of
new
kernel,
features
of
light
that
I
mentioned
earlier.
You
need
to
chuck
it
up
into
small
incremental
pieces
to
give
a
safe
and
cozy
world
and
in
2014.
Basically,
we
reworked
the
whole
patch
set
and
made
it
merchable
and
it
also
got
merged
into
the
kernel.
So
that's
like
the
initial
code
on
ebpf
that
we
had
and
what
it
did.
A
It
was
basically
replacing
the
old
bpf
interpreter
entirely,
so
the
kernel
wouldn't
have
the
old
tcp
anymore,
but
instead
the
new
ebpf1
and
the
instructions
instruction
set
got
heavily
extended
and
the
tcp
dump
bpf
language
back
then
got
translated
inside
the
kernel
to
the
new
representation
and
later
also
the
verifier
and
jit
pieces
got
added
and
much
more
work.
On
top
of
that,
and
we
basically
lexi
myself
basically
became
maintainers
because
we
spent
most
of
the
time
hacking
on
working
on
epf
on
the
kernel
and
overseeing
the
development.
Since
then,
that's
where
it
happened.
A
Basically,
where
david
muller,
the
networking
kernel,
maintainer
applied,
the
patch
said
yeah
thanks
a
lot
for
that,
and
what
else
happened
in
that
year?
Actually,
it's
quite
interesting
2014.
Also
the
first
kubernetes
patch
went
public,
so
in
2015
the
development
of
ebpf
moved
into
two
directions:
networking
and
tracing
and
a
major
milestone.
That
is
still
the
base
foundation
for
all.
A
We
also
made
the
dc
lockless
so
that
it
would
be
fast
without
any
cpu
contention
and
also
add
next
to
an
existing
ingress,
also
an
egress
hook.
So
you
have
both
attachment
points
to
see
all
the
traffic
yeah.
So
there
was
plenty
of
other
work
on
top
of
that
and
back
in
2015,
the
bcc
project
first
got
announced
that
is
a
tracing
front,
end
and
used
by
many
people
today
to
get
introspection
to
the
system
and
solve
production
issues
in
2016.
A
A
A
2016-17
was
basically
the
year
where
ebpf
began,
taking
over
production
environments,
which
is
really
exciting.
Brandon
gregg
from
netflix
called
out
the
linux
bpf
superpowers
he's
been
working
on
tracing
heavily
on
creating
the
necessary
needed
tools
for
the
bcc
project,
and
he
says
it's
compared
to
the
d
trace
where
he
has
like
13
years
of
experience.
A
Ebpf
is
worth
way
more
and
exciting,
even
though,
and
just
just
in
this
short
time
span,
the
capabilities
are
staggering,
and
facebook
announced
that
they
are
were
replacing
their
at
that
time.
Existing
ipvs
load
balancing
infrastructure
over
and
they
they
migrated
away
from
that
filter
entirely
to
ebpf,
and
they
were
attaching
those
programs
to
the
xtp
hook
in
order
to
do
layer,
4,
load,
balancing
and
ddos
production
and
since
2017
every
packet
that
goes
to
facebook.com
basically
passes
through
xtp
and
ebbf.
So
it
really
is
battle.
A
Tested
cloudflare
basically
also
saw
that
potential
and
they
migrated
from
their
net
filter
components
away
to
ebpf
as
well.
Similarly,
relying
on
x
on
the
xtp
layer
for
their
load,
balancing
and
ddos
mitigation
and
in
also
went
fully
into
production
in
2018,
actually
so
yeah,
the
evpf
community
grew
and
with
that
also
the
features
in
the
kernel
and
in
order
to
handle
all
this
incoming
kernel
patches,
alexey
myself
and
david
miller,
a
networking
maintainer
we
sat
together
and
basically
decided
that
ebbf
has
to
become
its
own
kernel
subsystem.
A
So
since
then,
alexi
and
myself,
we
manage
our
own
linux
kernel,
trees
for
bpf
and
bpf.
Next,
where
all
the
features
and
fixes
land,
we
have
our
own
main
list
and
we
are
pushing
and
collecting
all
the
code
that
the
whole
community
contributes
to
bpf
and
handing
that
over
to
david
miller,
and
he
pushes
this
to
linus
torvalds,
which
who
merges
it
into
the
upstream
kernel
back
in
that
year.
We
also
worked
on
ebpf
for
ktls.
A
A
So
bpf
programs
could
be
attacked,
can
be
attached
and
they
can
introspect
the
data
and
then
enforce
policy,
and
these
days
actually
open
ssl
has
it
natively
integrated,
which
is
great,
and
in
the
same
year
there
was
more
tools,
got
added
for
allowing
to
introspect
the
kernel
about
what's
going
on
in
bpf
land,
what
programs
are
loaded?
What
maps
do
we
have
and
therefore
bpf
tool
got
added,
which
is
a
tool
that
still
gets
extended
with
all
the
features
today,
and
also
in
or
in
order
to
ease
application
development
for
users?
A
The
lib
bpf
was
added,
which
is
a
c-based
library
that
takes
over
all
the
loading
of
bpf
programs,
so
that
applications
don't
have
to
deal
with
that
because
it
can
get
quite
complicated
in
2018,
sodium
1.0
was
announced
and
that
basically
first
brought
the
ppf
revolution
to
kubernetes
networking
and
security.
It
was
added
as
a
cni
plug-in
in
order
to
integrate
into
kubernetes,
and
it
allows
for
identity-based
policies
from
layer,
3
up
to
layer,
7
and
also
cluster
ip
services
that
were
handled
through
bpf
and
translated
there
efficiently.
A
A
component
called
btf
or
bpf
type
format
was
added
into
the
kernel.
It's
basically
a
metadata
format,
similar
to
debugging
data
that
we
have
with
dwarf,
but
it's
significantly
smaller
in
size
and
for
the
first
time
the
kernel
became
self-descriptive.
What
does
it
mean
from
a
running
kernel?
You
can
actually
it
ships
its
own
data
format
and
internal
structures,
and
you
can
introspect
them,
and
that's
basically
btf
today
is
is
the
base
for
all
the
future
features
like
compile,
runs,
run
everywhere.
A
A
Af
xdp
is
another
socket
type
in
linux.
Networking
that
got
merged
in
the
same
year
and
what
it
basically
provides
is.
It
provides
zero
copy
for
network
packets
right
out
of
the
driver
layer,
and
you
can
then
push
them
into
user
space
it's
similar
to
or
it
offers
a
similar
feature
to
what
the
dbdk
toolkit,
for
example,
does
except
in
the
case
of
dbdk
those
network
drivers
have
to
be
written
and
maintained
in
user
space
and
with
af
xdp.
A
You
can
get
the
same
performance
benefits
while
reusing
kernel
drivers,
so
that
network
device
management
is
much
much
easier
and
all
that
happens
at
the
xtp
layer.
That's
why
it's
called
af
xdp
and
the
bpf
program
that
can
be
attached
to
it
allows
for
steering
this
into
the
socket.
There's.
Also,
the
bp
filter
prototype
that
we've
worked
on
it
and
this
allowed
for
translating
iptable
rules
into
ppf
to
user
mode
driver.
A
This
was
basically
the
first
prototype
where
we
can
take
an
existing
iptables
binary
and
generate
epf,
underneath
without
the
user
having
to
know
or
realize
some
of
those
components
are
used
today.
Also
for
extending
the
kernel
in
other
areas
in
2018-19,
ppf
trace,
first
got
announced
next
to
bcc
epf
trace
traces.
Basically,
those
are
basically
d2
main
tracing
front
ends
for
bpf
brandon
greg
calls
it
dtrace
2.0
for
linux
because
of
his
capabilities,
and
it
allows
it
has
a
easy
to
use
front
end.
You
don't
have
to
code
c
programs.
A
You
can
simply
use
one
liners
efficiently.
He
also
wrote
an
880
page
fake
book
on
bpf
tracing,
which
is
really
exciting.
His
first
book
on
first
major
book
on
bpf
and
he
saw
brennan
crack-
is
also
working
on
the
new
one
for
2020
on
his
second
edition
of
the
system's
performance
covering
large
parts
with
bpf
and
tracing
as
well.
A
A
And
aside
from
that,
also
that
was
based.
2019
was
basically
the
year
of
all
the
cpu
bugs,
so
bpf
also
had
to
protect
the
gain
spectra,
and
that's
actually
quite
interesting,
because
the
bpf
verifier
does
a
lot
of
work,
sometimes
even
more
work,
analyzing,
the
programs
that
compilers
do
and
it's
here
it
even
goes
into
analyzing
the
safety
of
speculative
program
paths.
A
One
of
those
users
that
can
actually
benefit
as
well
is
chilean
because
in
the
1.8
release
it
added
xtp
based
service
load,
balancing
for
kubernetes
in
order
to
efficiently
use
the
cpu
for
networking
in
a
better
way
compared
to
the
net
filter
based
approach
for
q
proxy
on
the
kernel
site.
Many
other
interesting
events
happened
here
in
that
year.
Facebook,
for
example,
added
a
bpf
based
tcp
congestion
control,
module
that
allows
for
experimentation
for
the
data
centers
to
quickly
deploy
and
add
new
features
for
the
congestion
control
in
tcp
and
also
microsoft.
A
A
There
was
actually
like
it's
actually
interesting
to
observe
this
tremendous
change
in
the
linux
kernel
and
people
are
calling
it
one
of
the
major
os
changes
in
the
last
50
years
and
brennan
craig
actually
says
it's
one
of
the
biggest
operating
system
changes
that
he
has
seen
his
career
and
is
thrilling
to
be
part
of
it.
I
can
only
agree
with
that
ebbf
in
numbers,
so
basically
the
kernel
community.
A
A
There
are
many
different
program,
types
and
maps,
but
the
interesting
part
is
on
the
linux
kernel
that
the
bpf
subsystem
has
over
3500
test
cases.
Usually
kernel
developers
are
not
that
good
in
writing,
unit
tests
or
self
tests,
but
bpf
is
one
of
the
most
tested
subsystem
these
days
and
aside
from
alexia
myself
as
kernel
maintainers
for
bpf,
they
are
also
a
team
of
six
other
core
reviewers
and
major
contributors
that
help
with
the
patch
load
that
is
coming
at
us
and
they're
from
from
the
companies,
israel
and
facebook
and
google
yeah.
A
Overall,
it's
one
of
the
fastest
growing
subsystems
in
the
linux
kernel,
so
yeah,
it's
like,
and
you
can
see
it
as
in
sort
of
an
industry
shift,
and
you
have
those
major
adapters,
facebook
running
it
for
their
layer,
four
load,
balancer
and
ddrs
production
as
well
as
tracing,
but
basically
everywhere,
netflix,
similarly,
very
heavy
user
on
the
tracing
site
for
bpf
to
google.
You
you
have
it
in
running
on
android
phone
devices,
but
also
using
it
in
their
server
fleet
for
security
and
various
other
aspects,
cloudflare
for
their
load,
balancing
ddos
mitigation.
A
There
are
also
a
lot
of
large-scale
psyllium
users
that
are
running
it
in
production
and,
if
you
look
at
the
one
of
the
former
net
filter,
maintainers
rusty
russell,
he
actually
what
he
actually
has
to
say
about
bpf.
It's
quite
interesting.
He
says,
like
you
know,
iptables
performance
used
to
be
mostly
good
enough
back
then,
but
replacing
it
has
taken
so
long
because
it
required
a
radically
different
approach
and
it's
nice
to
see
it
finally
happening
bpf.
A
So
how
can
you
bring
this
ebpf
revolution
to
kubernetes?
Well,
basically,
bpf
is
becoming
ubiquitous
these
days,
as
I
mentioned,
and
if
you're
still
relying
on
ip
tables,
and
you
have
to
fiddle
around
and
debug,
with
a
large
number
of
rules
that
are
installed
by
cube
proxy
to
handle
services.
Well,
there's
a
way
out
of
it.
You
can
basically
replace
the
q
proxy
component
as
one
example
with
ppf.
A
So,
let's
dive
right
in
at
the
socket
layer.
This
is
basically
for
handling
all
the
east
rest
traffic
among
sodium
managed
nodes.
So
it's
doing
the
service
ip
ports
to
the
back.
End
translation,
add
the
socket.
So
whenever
applications
call
connect,
send
message
receive
message
hooks,
it
will
basically
hand
translate
the
actual
request
into
the
back
end.
And
the
interesting
thing
here
is
that
for
this
no
expensive
packet
level
network
address
translation
is
required
because
at
that
syscall
time
the
packet
hasn't
even
been
created.
A
So
what?
Basically
the
bpf
program
here
is
doing.
It's
telling
the
kernel
that
the
application
is
actually
connecting
directly
to
the
back
end,
whereas
the
application
is
thinking
it's
connecting
to
the
service
ip
and
the
bpf
program
has
both
of
these
contacts
and
knows
what
to
do
with
it
and
that
allows
for
efficient
service
handling
for
the
east
west
case.
A
Then
there's
also
the
north
south
case,
where
external
traffic
from
outside
world
is
basically
coming
onto
the
node
and
that's
handled
through
ppf
programs
at
the
xtp
and
tc
layer.
What
does
it
mean?
So?
Basically,
it's
doing
the
same
service,
ap
port
to
the
back
end,
translation
on
the
network
driver
layer
and
in
case
backends,
are
on
a
remote
node,
not
on
the
local
one.
They
have
to
be
pushed
back
out
of
the
node
again.
A
So,
similarly,
as
I
showed
you
in
the
previous
packet
flow
diagram
and
what
we've
implemented
here
is
basically
a
asnet
handling
with
native
bpf
and
this
functionality
can
be,
can
basically
be
compiled
into
for
xdp
itself,
as
well
as
for
the
dc
layer
and
on
the
xdp
layer.
As
mentioned,
allows
for
high
performance
and
low
overhead
load
balancing
you
can
use
those
cpu
cycles
that
you
would
otherwise
have
to
use
to
handle
the
service
translation
in
cube
proxy.
You
can
use
those
for
user
workloads
instead,
that's
how
it
should
be.
A
So
basically,
the
main
principle
here
is
to
operate
as
close
as
possible
to
the
socket
for
the
east-west
case
and
as
close
as
possible
to
the
driver
for
the
nerf
south
case.
So
how
does
it
look
in
numbers?
We
did
a
performance
comparison
on
xdp
and
eppf
as
well
as
cube
proxy,
so
we
had
basically
two
bare
metal
nodes
and
we
pushed
from
one
node
to
another
as
many
packets
as
possible
with
the
packet
generator.
A
A
When
the
service
is
basically
on
the
kubernetes
node
remote
and
in
the
tc
layer
that
sodium
is
able
to
attach
as
well.
You
are
still
able
to
handle
around
3.5
million
packets
per
second,
whereas
the
cube
proxy
there's
still
much
more
overhead,
because
the
net
filter
layer
comes
later
in
the
stack
than
the
tc
layer
and
it
was
only
able
to
handle
around
2.3
million
packet
per
second
and
ipvs
even
has
slightly
more
overhead
for
just
a
small
number
of
servers
that
was
tested
here
than
the
iptables
one
in
terms
of
cpu
capacity.
A
A
There
was
a
lot
of
cpu
spent
to
handle
the
software
interrupt
load
here
so
yeah.
How
does
it
look
ebpf
and
kubernetes
in
the
long
future,
so
you
can
think
of
the
linux
kernel
becoming
slow
turning
slowly
into
a
ppf
powered
microkernel.
That's
actually
a
really
interesting
thought
here.
What
you
can
think
of
in
the
long
future
that
there's
just
a
tiny
core
kernel
with
the
base
functionality
that
is
needed
to
boot
it
and
to
keep
things
running,
but
all
the
other
stuff
is
around
around.
A
A
That
allows
to
reduce
the
attack
surface
because
you
have
a
tiny
core
kernel
and,
at
the
same
time,
all
this
bpf
code
that
is
defined
around
it.
The
safety
verified
to
the
verifier
and
you
can
get
rid
of
all
the
feature
creep
that
is
otherwise
still
in
the
kernel,
but
you're
not
going
to
use
it,
and
you
can
make
a
much
better
use
of
that
of
the
cpu
resource.