►
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Super Charge Your Service Mesh With eBPF - Yuval Kohavi & Idit Levine, Solo.io
The Linux kernel is an ideal place to implement observation, networking, and security, and improvements in the eBPF space are making it more practical to leverage the Linux kernel for these use-cases. Given that both eBPF and service mesh essentially allows users to program policies to connect, secure, and observe; you may be wondering how service mesh and eBPF intersect? This talk will explore different approaches to supercharge your service mesh with eBPF to make service mesh more secure and efficient.
A
And
we're
going
to
teach
you
a
little
bit
about
ebpf
service
mesh
and
how
they're
related
together
before
that?
I'm
just
going
to
say
that
me
and
your
valuables
working
in
solo,
io
solo
is
focusing
on
application
network
connectivity
and
we
have
a
lot
of
people.
We
focusing
our
stack
is
basically
focused
on
envoy
and
sto
and
therefore
we
are
working
very,
very
hard
with
customers
and
upstream.
So
we
have
a
lot
of
toc
member.
A
Some
of
them
are
here
even
today,
and
and
and
and
we're
basically
working
to
make
service
mesh
upstream
better
for
our
customers.
So
that's
number
one
and
we
will
start
so.
Let's
start
when
we're
talking
about
evp,
we'll
start
talking
about
the
kernel.
I
know
this
is
something
that
you're
usually
not
talking
about
in
a
service
mesh
one,
but
we
should
so
let's
talk
about
the
linux
scanner,
one
second,
and
what
you
can
see
is
that,
based
on
this
architecture,
which
honestly
it's
a
little
bit
simplifies
it's
pretty
complex
and
it's
also
very
mature
right.
A
So
I
mean,
if
you
think
about
it,
the
work
that
we're
doing
today
and
the
thing
that
we're
running
today
in
productivity,
most
likely
was
upstream
between
10
to
10
years
ago,
to
maybe
two
years
ago.
But
honestly
that
was
done
way
on
the
back
way.
On
the
back
before
we
starting
devops
and
before
we
started
doing
evolution
right
and
before
there
were
a
lot
of
you
know,
we
were
running
everything
right
now,
it's
code
and
cloud
native,
but
still
we're
running
it
on
the
same
operating
system.
That
is
honestly
was
built
for
application.
A
A
Bpf
basically
started
in
you
know
as
the
opportunity
to
solve
that
problem,
which
is
very
hard
to
innovate
in
the
kernel
and
basically
started
in
the
tcp
dump,
and
the
idea
was:
can
we
create
a
sandbox
or
some
extension
or
plug-in
to
the
kernel,
one
that
will
be
injected
by
the
user
mod
to
the
kernel
one
and
basically
we'll
be
able
to
run
there
on
it
when
they
will
want
so
what
the
advantage
of
it?
First
of
all,
it
will
give
you
a
lot
of
flexibility.
A
It
have
to
be
safe
right,
it's
running
on
kernel
mode.
We
need
to
make
sure
that
it's
not
going
to
take
your
operating
system
down,
and
it's
need
to
be
fast
because
you
know
we
need
performance
there.
So
that
is
extremely
important
and,
as
I
said,
they
started
by
basically
putting
the
the
bpf
in
the
tcp
dumps
honestly,
if
you're
using
tcp,
dom
you're,
probably
using
it
every
day,
that's
where
it
started,
but
then
they
said
that's
pretty
cool
and
pretty
unique.
What?
A
If
we
will
extend
that
and
that
exactly
what
what
ebpf
stands
for
extended
bpf?
What
if
we
will
extend
it
and
basically
we'll
have
this
ability
of
that
technology,
which
is
kind
of
like
the
send
box,
basically
being
hook
to
event
in
the
kernel?
So
what
you
can
see
here,
you
can
put
in
user
mode,
you're,
basically
running
the
program
right
and
what
you
can
see
is
that
index.
B
Yeah
so
a
quick
background
to
kubernetes
and
networking
right
so
with
kubernetes,
there's,
obviously
the
cube
api
server
and
then
on
each
node.
You
have
the
kubelet,
essentially
the
kubernetes
agent.
It
has
a
container
random
interface.
That's
what
runs
your
container
essentially
docker,
container
d
nowadays
cryo
and
on
the
networking
side
you
have
what's
called
the
cni,
the
container
network
interface
and
that's
the
component
that
implements
the
kubernetes
networking
layer.
So
kubernetes
networking
is
pluggable
and
swappable.
B
B
In
addition,
there's
another
component
called
coup
proxy,
whose
role
is
to
make
sure
that
pods
can
talk
to
kubernetes
services.
So
services
has
virtual
ips
in
the
kubernetes
cluster
and
these
ips
in
order
to
map
back
to
the
pods
that
back
them.
This
is
managed
by
group
proxy.
Now
originally
coop
proxy
was
implemented.
It
was
basically
a
user
mode
proxy
written
and
go
obviously
that
wasn't
a
very
fast.
B
So
you
can
imagine
here:
each
pods
have
an
ip
and
if
the
front
end
wants
to
access
the
back
end
through
a
cube
service,
the
the
pod
one,
the
front
end
pod
only
acts
as
a
single
ip
and
cool
proxy
load
balances
it
to
all
the
back
end
pods
right
so
in
this
case
it'll
be
two
back
in
pods.
That
coopers
needs
to
worry
about,
and
why
are
we
talking
about
all
of
this?
B
The
the
way
iptables
work
iptable
was
originally
created
for
firewalls,
and
you
had
very
basic
things
that
a
firewall
needs
to
do.
It
wasn't
at
this
scale
of
kubernetes,
with
a
lot
of
services
right
and
the
way
iptable
is
implemented.
It's
a
list
of
rules
and
this
list
needs
to
be
executed
one
by
one.
B
So
the
more
services
you
have,
the
more
pods
you
have,
the
less
it
scales
right,
because
that
that
list
grows
linearly
and
you
need
to
go
through
those
rules.
One
by
one
to
implement
essentially
reach
your
backend
service.
Now
the
way
ebpf
solves
this
is
instead
of
using
ip
tables.
We
can
use
ebpf
here
to
do
that,
mapping
between
a
virtual
service,
ip
and
backing
pod
ips,
and,
as
you
can
see
from
this
graph,
we
can
do
it
sort
of
in
a
constant
time,
whereas
with
ip
tables
and
coup
proxy,
it
goes
linearly.
B
I
higher
the
more
services
we
have
now
the
project
that
brings
all
these
ebpf
advantages
into
kubernetes.
It's
called
psilium
and
cilium.
If
you
remember,
we
discussed
by
the
cni
and
cuproxycillium
is
an
implementation
for
both
using
ebpf,
so
serium
can
create
for
you,
the
networking
layer
and
also
replace
coup
proxy
and
uses
ebpf
to
bring
this
scalability.
The
security
and
the
networking
features
using
ebpf
to
kubernetes.
B
So
things
like
service
identity
to
create
network
policies.
Things
like
performance,
as
we
just
discussed
things
like
encryption,
multi-cluster
routing.
So
just
as
an
illustration,
you
can
see
here
that
you
know
with
sodium.
You
can
express
policies
using
the
pod
labels
and
selectors
and
making
it
easier
and
scalable.
B
Now,
as
far
as
envoy
is
concerned,
envoy
is
the
key
data
plane
component
in
the
service.
Mesh
anvi
also
can
benefit
from
ebpf
advantages.
So,
for
example,
with
ebpf
we
can
short-circuit
the
tcp
stack
between
the
application
and
the
sidecar
right.
So
when
your
service
sends
a
request,
normally
iptable
is
used
to
reroute
the
request
transparently
through
envoy,
but
that
means
that
it
needs
to
go
through
the
entire
tcp
stack
for
the
app
get
to
the
kernel
and
get
back
into
envoy.
B
A
Yes,
so
you
know
we're
looking
at
psyllium
right.
You
just
heard
about
how
amazing
it
is
and
what
we
can
do
with
this
and
how
the
performance
will
be
better
and
so
on,
and
you
can
go
to
the
website
and
you
can
see
that
basically
there's
some
similarity
between
what
it's
doing
and
what
service
mesh
is
doing
right.
I
mean
they're
talking
about
networking
here
they
are
talking
about
observability
and
they
are
talking
about
security,
which
is
exactly
what
I
took
from
the
sdo
website.
A
So
are
they
competing?
Are
they
complementary
what's
going
on
there
and
that's
basically
what
we
wanted
to
take
a
look
at
and
we
did
so.
Basically,
we
did
this
research,
which
is
basically
sto
versus
cilium,
and
we
took
basically
those
three
sections
and
we
tried
to
understand
where
it
makes
sense
to
use
one.
Where
does
it
make
sense
to
use
the
other,
and
what
does
this
make
sense
to
collaborate
between
those
two
and
that's
exactly
what
we
did
so,
for
instance,
if
you're
looking
at
identity?
B
So
when
we
compare
the
these
features,
syrian
versus
lithium,
so
with
identity,
the
serum
identity
is
on
the
l4
l3
l4
level.
It's
based
on
pod
labels,
whereas
with
izio
it's
cryptographic,
identity.
If
you're
familiar
with
spf,
essentially
mutual
tls
certificates,
that's
and
the
source
of
the
identity
is
the
service
account
associated
with
the
pod,
not
the
pod
labels
as
far
as
network
policies.
B
So
you
can
create
a
kubernetes
network
policies
with
psyllium
again
a
layer,
three
layer,
four
level
and,
in
addition,
serum
have
their
psyllium.
It's
your
implementation,
where
they
allow
you
to
create
l7
policies
with
go
base
filters
with
hcou.
All
the
policies
are
implemented
using
envoy
without
ebpf.
You
can
have
awesome
extensions,
which
gives
you
a
lot
of
power
in
expressing
your
custom
policies,
and
it
also
supports
things
like
external
auth
and
has
an
android
filter
crd
that
you
can
really
customize
what
you
need
to
get
out
of
anyway.
B
As
far
as
a
networking
in
in
load,
balancing
serium
is
again.
Sedum
mainly
is
the
l3
l4
level,
so
you
have
pair
connection
load
balancing
where
ico
on
the
l7
can
give
you
per
request
load
balancing
as
far
as
resiliency.
If
you're
using
the
l7
cylinder,
you
have
retries,
it
exposes
more
of
the
android
features,
outlier
detection,
retries
fault
injection
and
with
android
filter.
You
can
really
customize
it
and
essentially
use
any
android
feature.
B
You
want
in
terms
of
multi-cluster
serum
implements
a
flat
network,
a
multi-cluster
kind
of
mesh
that
joins
multiple
clusters
together
with
ezo
there's
various
ways
to
do
it.
You
can
use
it
with
a
flat
network,
but
it's
your
does
not
implement
a
flat
network
because
it's
not
on
that
level
on
the
l3
level,
but
what
you
can
do
with
it
seo
is
and
something
that
we
see
a
lot.
That
organization
actually
prefer
to
do
is
using
grass
and
egress
gateway
to
connect
clusters
together
in
terms
of
observability
serium
offers
hubble.
B
It
sits
on
the
serum
agent
on
every
node
collects
metrics
and
it's
your
again
envoy
and
with
itsu
you
can
customize
the
metrics
and
we
expose
it
again
using
a
wasim
excess
log
with
selum.
You
have
the
l7
envoy
implementation
using
go
filters,
you
can
create
custom
access
logs
per
protocol.
So
if
you
have
your
own
custom
protocol,
you
can
create
a
go
filter
for
it
and
create
some
extra
socks.
For
that
we
did
seo.
B
A
Cool,
thank
you
so
then
the
question
is:
what
can
we
do
about
it
because
if
you
know
solo
well,
you
know
that
we
are
not
just
doing
a
research.
We
usually
act
on
that
funding.
So
what
did
we
found
and
what
would
we
do
so?
As
I
said
I
mean
I
think
I
will
talk
about
really
quick,
but
in
the
nutshells
we
have
a
product
called
glue
match.
Gloomers
has
built
four
different
and
now
five
different
extension.
A
We
it's
based
on
sto.
We
have
a
lot
of
custom
filter
for
android
there
and
therefore
we
can
do
a
lot
of
stuff
in
the
ingress
in
the
api
gateway,
as
well
as
the
service
mesh
and
sdl,
and
we
have
developer
portal
and
we
have
an
extension
with
wasm
and
now
we
have
also
graphql,
as
we
announced
in
the
keynote
before
so
again.
I
will
go
about
that,
but
what
is
interesting
here?
What
do
we
want
to
do
with
it
right,
and
I
will
tell
you
what
we
decided
to
do
with
this.
A
So,
as
you
know,
as
we
explain
right
now,
there
is
layer.
Three
cilium
is
mainly
focused
on
layer,
3
and
l4.
This
is
where
it
is
there
on
the
node.
This
is
what
they
know.
It's
very
local
sdl
is
more
like
layer
4
to
layer
7..
So
what
we
did,
we
basically
said:
look
when
someone
telling
us
right
in
our
product
in
our
global
api
in
in
the
glue
mesh
api.
I
do
not
want
this
container
to
talk
to
this
container.
A
We
can
do
it
in
sto,
like
we're
doing
it
so
far,
right
the
translation,
loop
and
putting
a
crd,
but
we
can
also
put
it
in
cilia
and
basically
create
these
things
locks
into
all
of
those
layers.
So
basically,
what
we
decided
is
honestly
to
ship
psyllium
with
our
product,
make
sure
that
if
it's
there
we're
discovering
it
and
we're
taking
advantage
of
in
being
there,
everything
that
related
to
observability,
you
know
we
can
give
you
way
more
metrics,
more
stuff.
That
sto
cannot
give
you,
so
both
of
them
is
amazing.
A
What
we're
doing
with
sto
today
is
basically
managing
you
know
installing
upgrading
life
cycle
and
so
on.
We
do
the
same
thing
with
psyllium
in
terms
of
networking.
Honestly,
most
of
the
stuff,
there
is
make
more
sense,
because
layer
seven
make
more
sense
to
use
with
steel.
So
you
know
rewriters
and
all
this
stuff.
It's
actually
make
way
more
sense
to
use
with
the
sto.
When
we're
talking
about
security
and
policy,
we
can
leverage
again
both
of
them
right
and
that's
exactly
what
will
happen.
So.
A
Basically,
when
you
ask
us,
I
don't
know,
I
want
this
observability,
we
will
go
and
translate
it
to
a
series
of
sto
and
if
you
have
there
an
interesting,
a
crd
of
psyllium
collect
the
data,
make
sure
that
it's
all
forced
for
you
upgrade
install
and
so
on.
So
that's
what
we're
doing.
Hopefully,
you
like
it
check
it
out,
and
I
don't
think
I
even
have
an
end
slide.
So
I
think
we're
done.