►
From YouTube: Lightning Talk: Clearing the confusion about eBPF and service mesh - Yuval Kohavi, Solo.io
Description
Lightning Talk: Clearing the confusion about eBPF and service mesh - Yuval Kohavi, Solo.io
eBPF is an exciting technology that allows developers to extend the capabilities of the Linux Kernel without modifying the Kernel itself. Getting access to powerful Kernel capabilities can be extremely powerful, especially in networking, but what is the responsibility of this layer when it comes to service mesh? In this talk we discuss the importance of separation of layers, where eBPF fits for service mesh (and where it doesn't), and how to best optimize the service mesh architecture and experience for the real problems users have: security, observability, flexible policy enforcement, and overall traffic management.
A
Why
are
we
looking
at
ebpf
and
service
mesh
well,
service
mesh
does
l7
processing,
it
has
a
cost.
We
want
to
see
if
we
can
use
it
if
we
have
to
alleviate
that
cost
right.
Now,
let's
talk
a
little
bit
about.
Can
we
actually
do
that?
Can
we
use
ebpf
and
service
mesh
together
and
gain
some
benefits?
The
answer
is
definitely
a,
maybe,
and
in
the
next
few
slides
I'm
going
to
talk
a
little
bit
about
use
cases.
Can
I
explore
how
ebpf
can
help
the
goals
that
we
initially
discussed
now?
A
A
Ebpf
runs
when
a
certain
subsystem
in
the
kernel
and
there's
a
bunch
of
such
subsystems,
invoke
it
explicitly
and
for
it
to
work
safely.
We
need
to
know
when
it's
terminate
right.
In
other
words,
ebbf
programs
are
not
touring
complete
and
that's
a
very
important
aspect.
I
otherwise
every
ebpf
kernel
every
bff
program
could
halt,
bring
the
kernel
to
a
halt
right.
We
have
a
blog
post
if
you,
if
you
want
to
get
more
details
kind
of
covering
some
of
this,
so
feel
free
to
go
there
and
check
it
out
all
right.
A
A
As
for
l7
there's
some
problems,
that's
why
we
still
need
envoy
and
let's
go
straight
into
the
point.
So
let's
talk
a
little
bit
about
security
as
far
as
l4
policy
right
ebpf,
you
can
send
programs
to
be
processed
very
early
in
the
network
stack
and
you
can
definitely
add
benefits
there
right
block
by
ip
and
if
you
are
in
kubernetes
by
pod
labels
using
network
policy
create
logs,
create
events.
Ddos
mitigation
are
all
great
use.
A
Cases
for
ebpf,
though,
do
take
into
account
that
if
you
use
some
of
those
features
because
ebpf
executes
so
early,
some
of
the
existing
monitoring
tools
wouldn't
see
those
packets
right,
because
ebpf
kind
of
can
take
care
of
them
before
they
make
it
to
the
rest
of
the
network
stack
now
as
far
as
l7
policy,
it's
a
bit
harder
right.
So
usually,
when
we
talk
about
l7
policy,
we
need
some
way
to
derive
the
client's
identity
right.
We
have
some
policy
rules
that
we
run
that
identity
again.
A
So,
for
example,
we
can
talk
about
spiffy,
mtls
identity,
or
we
can
talk
about
jot
identity
that
are
in
a
request,
header
right,
so
think
about
something
like
a
jot
where
we
need
to
parse
the
jot
and
verify
it
against
a
public
key.
Those
are
not
very
ebpf
native
operations,
they're
kind
of
needed,
more
turing,
complete
machinery.
A
If
you
have
a
list
of
policy
rules
right
so,
for
example,
user
x
can
do
a
post
request
on
resource.
You
know
path,
foo,
that's
also
running
through
a
list
of
rules.
That's
dynamics,
it's
not
something!
That's
very
evpf
native,
something
like
external
auth,
where
you
have
to
pause.
Your
request,
send
it
to
an
external
service,
get
a
response
and
then
continue
the
request
again,
not
something
very
native.
It
requires
a
complex
state
maintenance
that
currently
is
is
very
hard
to
do.
A
I'm
not
saying
impossible
right,
never
say
never,
but
it's
not
it's
not
the
native
natural
fit.
When
we
talk
about
ebpf,
let's
see,
I
want
to
say
anything
else
here,
yeah.
So
basically,
all
these
l7
security
policy
are
not
a
natural
fit
to
the
execution
model
we
just
discussed.
So
these
are
better
done
in
a
sidecar
right
and
again,
this
is
2022.
in
2024.
My
answer
might
be
different,
but
we
work
with
what
we
have
today.
A
Let's
talk
a
little
bit
about
the
data
path
and
load
balance
and
load.
Balancing
now
ebbf
can
definitely
help
right.
Things
like
xdp
think
about
things
like
the
sock
map.
The
sidecar
acceleration
that
thomas
mentioned
earlier
can
definitely
help
bring
some
performance
benefits
to
the
mesh
reduced
latency
increased
throughput.
We
also
measured
it
and
steven
improvements,
but
once
we
talk
about
l7
load,
balancing
that
can
also
get
a
bit
complex,
think
about
an
http
route
table
right.
A
A
All
this
stuff
is
not
exactly
the
best
fit
for
abpf
again
because
of
this
complexity
and
the
state
management
think
about
complex
load.
Balancing
algorithms
list
requests
where
you
need
to
track
each
upstream
to
see
how
many
active
requests
it
has
and
make
a
routing
decision
based
on
that
right.
So
you
have
kind
of
you
need
to
maintain
a
data
structure
and
with
ebpf
data
structure
because
of
the
runtime
model.
The
kernel
needs
to
be
aware
of
them,
so
you
need
to
have
your
data
structure
supported
by
the
current
kernel
right.
A
A
Different
headers
are
compressed
and
managed
in
the
context
of
the
same
tcp
connection
right,
so
you
have
very
complex
state
management
that
is
separate
for
the
downstream
and
the
upstream,
so
you
can
just
copy
bytes
from
the
downstream
to
the
upstream
you
at
the
minimum
have
to
edit
some
of
the
the
metadata.
You
know,
http
frame
fields.
A
All
right
moving
on
metrics
of
an
observability
here
ebpf
is
actually
a
great
fit
for
service
mesh,
because
the
bpf
is
on
the
kernel
level.
It
can
observe
all
your
workloads,
whether
they're
in
the
mesh,
whether
they're
not
in
the
mesh,
doesn't
matter.
You
get
a
good
amount
of
l4
observability
metrics
as
for
l7,
it's
harder,
but
conceivable
because
you
don't
need
to
manage
any
state.
You
just
kind
of
need
to
read
the
bytes
on
the
wire
as
they
arrive
and
parse
them.
A
I've
seen
some
examples
on
the
internet,
so
it's
definitely
possible
a
bit
harder
than
you
know.
Regular
l4
right.
Let's
talk
a
little
bit
about
resiliency
and
again
with
with
l7
resiliency
things
like
think
about
how
complicated
a
retry
is.
You
know
when
the
proxy
does
it.
It
has
to
schedule,
request,
get
a
response,
see
that
the
responses
of
500
schedule
an
exponential
back
off
and
then
tie
the
request
again
as
synchronically
all
the
while
holding
back
the
original
request,
while
continuing
learning
others
request
streams
from
the
same
connection
upstream
right.
A
All
this
complex
state
management
is
very
hard
to
do
with
abpf.
Today,
things
like
passive
health
checks
right
if
you
get
a
500,
take
your
host
out
of
load,
balancing
things
like
circuit
breakers.
If
a
certain
host
has
a
number
high
number
of
requests,
that's
something
that
hard
to
do
with
ibrf.
Today,
again,
a
lot
of
state
managers,
I'm
not
saying
it's
impossible!
It's
just
a
lot
harder
than
doing
it
in
user
mode,
yeah,
all
right.
A
So,
to
summarize,
l4
and
mbpf
is
a
very
natural
fit
today,
l7
again,
if
it's
possible
and
again
I
never
say
never
right,
it's
not
easy
right,
especially
with
http
2.
That
has
complex
state
management
and
even
more
so
with
http
3,
where
everything
is
encrypted
encrypted
and
you
don't
really
have
a
choice
about
it.
A
Additionally,
when
you
think
about
l7
latency
the
bottleneck,
what
bpf
is
good
is
saving
context,
switches,
saving
buffer
copies
from
kernel
to
user
mode.
That's
not
really
our
problem
with
l7
our
problem.
Our
main
bottleneck
with
l7
is
cpu
right
when
you
think
about
request
manipulation,
adding
headers,
removing
headers
decoding,
http
and
coding,
http
2
stream
management.