►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. 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.
Sidecarless Mesh Monitoring with eBPF and Grafana - Adam Sayah, Solo.io
Service Mesh technologies were invented to fill the gap created in the micro-service world, especially when it comes to security and monitoring. Usually using a side car, a service mesh will inject metrics that can be gathered and rendered using the Prometheus and Grafana stack but the growing discussion around sidecarless services meshes and eBPF invite us to ask the following question, what are the pros and cons of a sidecarless monitoring stack in comparison to a sidecar approach? in this talk we will explore this subject in detail: - We will look into eBPF and the possibilities offered by this technologies. - We will compare the eBPF based monitoring to Envoy based technologies. - And finally, we will try to answer an important question, can eBPF metrics and Envoy metrics coexist, and if so how to render meaningful dashboards using Grafana.
A
A
You
should
bring
coffee
for
everyone,
man
all
right,
all
right,
so
yeah
again,
thank
you
for
joining
this
session,
mainly
today
we're
going
to
be
talking
about
observability,
using
in
terms
of
service
mesh
capabilities
and
what
we
can't
do
better.
Okay,
there's
many
things
going
on
today
with
ubpf
there's
a
bit
of
Market
confusion
about
things
Technologies
we
should
use
for
our
service
meshes,
there's
multiple
ones
out
there.
A
So
things
like
this
talk
I'm
taking
this
example
here,
istio,
because
this
is
what
I
know,
but
I
think
this
can
fit
any
other
service
mesh
technology
right,
because
monitoring
is
something
common
for
every
single
service
mesh.
We
all
need
to
know
what's
going
on
our
our
cluster
in
between
our
services.
A
Okay,
so
a
little
bit
about
me,
my
name
is
Adam
Saya
I'm,
a
field
engineer
at
solo,
so
basically
I
just
help
prospects
and
customers
with
all
their
API
gateways,
questions
and
service
mesh
and
recently
I'm
getting
really
interested
into
the
eppf
realm.
That's
it's!
For
me,
a
real
good
domain
that
we
we
should
investigate
into
you
know
when
we
deal
with
with
application
networking
in
general.
Okay.
A
So
today
we
gonna
go
through
a
quick
reminder
about
what
actually
why
we
should
care
about
the
service
mesh
at
the
first
place
right
and
then
we're
going
to
take
a
look
at
I
mean
the
pros
and
the
cons
of
kind
of
the
actual
things
we
do
with
the
service
mesh
in
terms
of
monitoring
we're
going
to
talk
about.
How
can
we
improve
this
a
bit?
How
can
we
go
to
this
extra
mile
configuration
optimization
in
that
matter
and
I'm
gonna?
A
Do
a
quick
demo,
though
the
quick
demo
here
is
not
part
of
any
product.
It's
just
something
I
put
together
to
kind
of
get
the
idea
across
this
may
be
implemented
in
other
service
meshes
or
should
be
an
extension
of
SEO,
as
as
a
kind
of
this
Main
Service
mesh,
I,
know
and
yeah
I'm
gonna
have
a
quick
conclusion
there
and
you
know
some
questions,
I
hope
all
right.
So,
let's
start
from
like
scratch.
Why?
Actually
we
move
to
microservices?
We
moved
to
microservices
because
it's
easy
from
operational
complexity.
A
A
Remember
couple:
well,
even
just
a
couple
years
ago
we
used
to
deal
with
projects
that
has
like
months
and
months
in
terms
of
life
cycle
right
really
so
you
we,
you
wait
for
six
months
to
just
have
one
security
patch
and
then
you
have
to
do
a
massive
upgrade,
and
that
was
just
a
nightmare
week
for
I
used
to
take
my
ptos
around
that
time.
So
just
to
get
out
of
that
so
now
with
microservices
things
are
way
better.
A
Okay
way
better
in
that
matter,
and
now
every
single
team
can
just
schedule
their
own
up
upgrade
at
their
own
pace.
They
can
have
the
scaling
their
microservices
on
their
own
terms.
I
was
really
good
in
that
specific
thing.
Now
the
thing
that
we
didn't
really
care
about
when
we
used
to
have
moderate
applications.
If
you
guys
remember,
we
used
to
have
everything
within
the
same
components,
a
meaning
in
terms
of
observability
and
knowing
what's
going
on.
A
It
is
not
to
be
it
used
to
be
an
easy
thing:
okay,
I'll
plug
in
a
debugger
there
inside
see,
what's
going
on
anything
from
function,
calls
and
seeing
different
from
API
calls.
Everything
was
within
contained
within
the
same
thing,
so
no
problems
at
all
in
terms
of
monitoring.
Now
with
microservices,
it's
a
different
story.
A
We
are
moving
to
I,
don't
know,
I
have
a
thousands
of
services.
How
am
I
going
to
know
where
which
one
failed
right?
There's
no
way
out
of
the
box
to
know
which
service
failed.
My
request,
unless
I'm
adding
some
sort
of
metadata,
if
I'm
lucky
that
my
microservice
is
returning
a
result
right
and
or
I
just
have
to
go
through
every
single
I
mean
my
lock
collection
or
it's
a
mess.
So
how
to
improve
this,
and
actually
that
was
kind
of
the
main
premises
of
what
a
kind
of
a
service
mesh
is
service.
A
Mesh
is
a
tool
that
will
help
us
in
different
terms,
terms
in
in
a
in
a
microservice
architecture,
for
mainly
these
three
things:
floating
Traffic
Control
in
general,
so
obviously
resiliency,
rerouting
blue,
green
Canary
deployment
of
services
and
all
that
stuff.
That's
fine,
then
security,
security
and
Transit,
mainly
on
mtls,
between
every
single
component,
every
single
mic,
Service
just
to
be
safe.
Since
now
that
the
services
are
scattered,
I
have
a
larger
attack.
A
Surface
I
want
to
be
saved
there,
but
again
one
of
the
main
things
in
the
service
mesh
is
observability,
so
I
need
to
observe
what's
happening.
If
something
goes
wrong,
I
always
need
to
know
to
go
back
to
see
exactly
what
happened
in
you
know,
going
back
to
the
right
service
that
failed,
try
to
debug
it,
and
you
know
just
having
a
good
monitoring
stack
on
top
of
all
my
microservices.
So
that's
what
services
mesh
service
meshes
try
to
answer
now.
A
Things
are
that
we
have
multiple
Technologies
out
there
and
most
of
them
kind
of
face.
Kind
of
the
same
problem
is
that
well,
first
of
all,
first
of
all,
just
monitoring
itself
is
hard
from
different
things.
You
need
to
capture
the
right
data.
You
need
to
write
to
capture
them
the
right
spot.
You
need.
You
know
that,
just
that
specific
concept
is
kind
of
complicated,
plus
a
lot
of
service
meshes
out.
A
Today,
we
use
proxies
a
lot
in
terms
of
monitoring
now
the
problem
with
that
is
that,
if
my,
if
my
like
talking
about
sidecars
or
even
sidecar
lists,
if
my
traffic
is
not
going
through
that
proxy,
nothing
is
getting
created
right,
so
nothing
gonna
get
generated.
If
there
is
no,
if
there's
no
proxy
in
there
and
that's
not
near
real
I
realized
the
reality
of
the
world
right.
We
are
not
in
an
environment
where
we
can
just
go
and
put
sidecars
and
proxies
everywhere.
A
I,
don't
think
it's
a
good
idea
either,
who
is
going
to
let's
say
I'm
a
big
company
and
tomorrow
I
want
to
adopt
service.
Mesh
am
I,
just
gonna
go
and
just
like
day
and
night
and
replace
all
my
microservices
with
like
a
sidecar
or
injected
traffic
a
proxy
there
I,
don't
think
it's
a
good
approach.
I
think
we
should
do
it
gradually
always
start
with
like
a
safe
application
test.
If
everything
is
well,
then
start
migrating
new
applications
add
them
to
the
mesh,
maybe
not
into
mtls
security.
A
That's
basically
what
I
was
just
talking
about
now
we
need
to
go
gradually
and
also
in
terms
of
like
proxies
proxies
are
expensive
right.
We
we
can
debate
about
that
all
day.
They
are
expensive
because
they
are
actually
a
component
to
add
to
your
infrastructure.
So
if
you
add
them,
you
need
to
add
them
for
the
right
things.
You
need
to
add
them.
For
example,
L7
traffic
are
really
well
done
using
proxies,
but
maybe
for
monitoring,
maybe
there's
something
else,
and
maybe
we
should
look
into
something
different
now.
A
Even
you
know,
in
the
side
card
less
world
where
we
have
still
a
proxy
here
somewhere,
either
on
the
Node
side
or
actually
on
the
on
the
cluster
itself.
It
still
goes
in
the
same
way:
you're
still
gonna
go
from
the
application
through
the
kernel,
socket
TCP
stack
going
to
network
going
all
the
way
up
to
their
proxy
again
going
through
the
network
again
and
then
going
to
the
physical
layer
to
send
the
traffic
somewhere
else.
So
all
this
is
important.
A
I
mean
we
still
need
it,
but
what
if
we
can
optimize
this
in
term
of
metrics
I,
don't
want
the
proxy
to
generate
my
metrics
until
it
goes
all
the
way
down
through
all
this
stuff,
and
actually
here
we're
getting
a
big
premise,
saying
that
I'm
actually
successfully
calling
the
proxies.
Imagine
if
something
felt,
even
within
the
kernel
like
I,
don't
know,
like
things
happen
right
like
different
versions
of
different
things,
just
a
problem
with
with
the
infra
itself.
How
can
I
know
what's
going
on
wrong
with
my
environment?
So
how
can
we
enhance
this?
A
A
A
This
is
basically
the
idea
behind
it,
the
idea
behind
it.
Even
in
Linux,
you
have
well
kernel
space,
so
you
have
in
term
of
memory
separation.
You
have
a
kernel
space
where
you're
actually
kernel
is
running,
it's
doing
its
stuff
and
actually
Linux
or
any
you
know
we
are.
They
are
really
strict
on
what
things
can
run
there
right.
We
don't
want
to
run
anything
that
is,
can
impact
my
machine
on
the
Kernel,
because,
obviously
we
want
the
machine
to
run,
but
if
the
application
fails
well,
the
application
fails.
A
It's
the
user's
problem,
not
really
the
kernel
problem.
This
is
why
there's
a
separation
between
a
kernel
space
and
a
user
space
and
what
we
see
usually
for
a
product
from
a
proxy
perspective.
The
proxy
runs
on
the
user
space
right.
It's
doing
you
know,
obviously
it's
doing
like
traffic
shifting
monitoring
all
that
stuff.
That's
fine!
Now
the
users
pay
the
the
kernel
space.
We
don't
interact
with
it
traditionally,
okay,
in
a
service
mesh
context
and
how
it
works
in
ebpf,
we
can
create
a
program.
A
We
can
create
some
code,
this
code,
gonna,
be
verified,
making
sure
that's
not
impacting
anything
and
then
can
be
running
on
the
Kernel
side.
It's
going
to
listen
for
events,
doing
some
reporting
doing
like
listening
to
things,
and
you
know
we
can
even
like
modify
stuff,
but
mostly
in
this
monitoring
discussion,
we
can
monitor
things
in
the
kernel.
Then
there
is
a
way
to
send
data
to
the
user
space
where
we
can
report
and
generate
metrics
and
create
primitive
stack
thing,
Prometheus,
metrics
and
so
on.
A
Okay,
so
from
efficiency
here
in
terms
of
monitoring
we're
not
talking
about
user
space,
if
my
proxy
is
not
there
and
stuff
like
that,
that's
a
different
discussion.
Now
we
are
going
all
the
way
down
to
the
kernel
to
observe
what's
happening.
So
this
is
really
powerful,
meaning
that
first,
it
can
be
way
more
effective
than
a
traditional
approach.
Okay,
meaning!
A
Well,
we
don't
need
a
proxy.
We
don't
need
to
go
all
the
way
through
all
this
stuff.
We
just
we
have
the
data
there.
So
let's
just
consume
it
to
expose
it.
It
is
lightweight,
it
is
effective.
It
is
fast.
It
is
not
on
the
request
path,
like
I
mean
from
from
a
proxy
perspective,
so
there's
a
lot
of
things
that
we
can
use
from
abpf.
Now,
that's
how
it
should
look
like.
Okay,
we
still
have
our
application.
A
We
still
have
our
user
user
space
to
run
our
proxy
to
deal
with
L7
type
things.
I,
don't
know
like
retries
and
oh
even
retries
can
be
networking,
but
let's
say
you
know:
security
UI,
DC
all
this
stuff
that
we
want
to
do
sometimes
at
the
proxy
layer,
but
the
ebpf
part
can
run
within
the
kernel
and
there
we
are
collecting
data
and
we
are
sending
it.
We
are
creating
metrics,
and
from
that
perspective
now
we
can
observe
everything
going
in
the
cluster.
So
with
what
that
means,
I
don't
know.
A
What's
the
difference
now
that
we
have
eppf
running
the
kernel,
we
don't
need
any
proxy
to
report
any
metric
again,
meaning
if
I'm
introducing
a
service
mesh
I
don't
have
to
do
it
gradual,
like
my
monitoring,
will
not
be
gradual
at
the
first
time
when
I
installed
my
service
mesh,
even
if
the
traffic
is
not
captured
and
redirected
and
part
of
the
service
mesh,
it's
still
monitored
end
to
end.
This
is
really
powerful
right
now,
I
think
if
I
have
to
stress
only
one
thing
during
this
call
doing
this.
A
A
So
if
I
want
to
take
an
example
going
back
to
my
ABCD
services,
so
I
have
four
Services
running
there,
even
if
I'm
adding
my
only
the
service,
A
and
B
to
my
service
mesh,
see-
and
these
are
also
monitored,
meaning
if
I'm
making
a
call
to
a
I'm
going
to
see
a
b
c
d,
so
full
monitoring
over
my
cluster,
but
service
mesh
is
partially
on
two
services.
So
that's
really
powerful.
A
Now
again
how
it
works
with
EPF.
You
have
you're
gonna
you're
gonna
run
like
a
code
on
the
Kernel.
This
code
will
listen
to
different
things
like
network.
If,
if
some,
if
a
is
calling
b-
or
this
is
happening
reports,
it
put
it
into
a
map,
we
call
it
right.
So
we
put
it
in
the
map
on
on
the
user
space.
On
the
other
side,
we
get
this
data
and
we
do
whatever
we
want
with
it.
We
can
basically
create
Prometheus
metric
from
it,
and
actually
this
is
what
I'm
gonna
show
here.
A
I'm
gonna
use
a
pro
like
a
tool
that
we
created
internally
at
solo,
called
Bumblebee.
Bumblebee
is
basically
a
tool
that
help
us
package,
ebpf
programs
and
automatically.
You
can
have
the
same
Docker
experience
with
a
kind
of
an
ebpf
program
where
you
can
package
it
push
it
in
the
registry
and
then
run
it
into
your
cluster.
But
the
good
thing
there
EBP
bumblebee
also
automatically
create
Prometheus
metrics
from
ebf
programs,
so
you
just
have
to
deal
with
the
ebpf
side
of
it.
A
This
is
just
an
example:
I'm
not
saying
that
bumblebee
has
to
be
used,
service,
mesh
or
I'm
just
stressing
that
this
technology,
whatever
I'm
showing
right
now,
can
be
tomorrow,
captured
and
be
part
of,
let's
say:
example:
istio,
okay,
so
you're
going
to
install
istio
you're
going
to
have
everything
like
either
the
service.
You
know
the
the
sidecar
or
the
sidecar
desk
version,
but
you're
gonna
have
the
full
monitoring
over
your
stack
and
actually
gradually
adding
your
services
to
the
service
mesh.
A
Yeah
good
thing
bumblebee
is
an
open
source
solution.
Actually,
I
can
show
you
the
repo
here
we're
happy
to
have
any
contribution
going
on
too
to
the
tool
you
know
check
it
out.
It's
going
to
be
a
good
entry
point
for
actually
that's
a
good
thing
for
me,
for
example,
where
I'm
not
coming
from
kind
of
the
the
L
Ford
Network
I'm
more
into
you
know,
I
know,
proxies
I,
know
service
mesh,
but
I'm
learning
ebpf.
A
A
This
first
step
is
basically
just
installing
Bumblebee
and
I'm
gonna
create
it
here
now
this
is
being
downloaded,
then
I'm
gonna
be
doing
a
b
in
it,
which
is
creating
my
abpf
program.
I
want
it
in
C,
I
wanna,
listen
to
the
network
capabilities,
okay,
so
actually
the
service
mesh,
probably
going
to
be
using
this
file
system,
is
not
really
important.
In
that
context,
let's
say
we
want
a
network.
That's
just
type
of
like
I
was
talking
about
the
map.
A
A
Then
I'm
going
to
be
using,
let's
say
I
just
want
to
print
this
and
then
I'm
going
to
call
it
like
prop
C.
All
right
here
is
created
now,
let's,
let's
just
compile
it,
go
back
here.
I'm
gonna
go
back
to
this
ebpf
program
in
a
second
all
right,
I
want
to
show
you
first
how
an
ebpf
program
look
like
so
here
is
you
don't
have
to
get
you?
We
don't
have
to
get
into
too
much
detail.
We're
not
here
to
understand
like
abbf
code
I'm,
just
saying
like
this
code.
A
Imagine
that
being
packaged
with
your
service
mesh.
So
this
is
what
gets
created
behind
the
scenes
for
you
when
you
install
a
service
mesh
and
if
we
go
back
to
it
here,
if
I
take
a
look
at
what's
happening,
I
can
so
we
use
something.
We
can.
We
call
K
probes
that
can
I
just
listen
on
events
and
here.
If
what
I'm
doing
is
that
I'm?
Listening
to
two
events,
when
we
get
you
know
the
the
socket
and
exit
on
it
and
from
there
I'm
triggering
a
function?
A
So
that's
super
kind
of
easy
explanation
of
what
we're
doing
here.
We're
listening
to
the
network
stack
if
something
happening
we
are
getting.
This
data
Putin
is
in
a
map
and
that's
going
to
be
pushed
back
to
my
user
space.
All
right,
that's
it!
So
this
one
will
monitor
communication
between
A
and
B.
Okay.
Every
time
something
happened
between
two
IPS
they
get
captured
and
put
into
this
address
where
it's
like
service
destination
and
and
Source
doesn't
address
and
destination
address.
This
data
can
gonna
be
captured
all
right.
A
A
All
right,
so,
while
this
is
compiling
one's
going
to
be
ready,
we're
going
to
be
able
to
use
yeah
there,
you
go
now
that
we
have
this
program
compiled
now
we
should
we
should
be
able
to
use
it.
So
now,
let's
see
this
is
ready.
We
should
push
it
to
a
registry,
as
I
mentioned
earlier,
bumblebee
allows
to
create
programs
and
push
them
to
like
a
registry
to
be
reused
like
a
kind
of
same
Docker
experience
we
can
have
and
then
now
that
is
running
now
that's
bills.
A
A
So
we
have
this.
This
is
awesome
now,
let's
think
about
Primitives
metrics
in
this
case,
if
I
go
back
to
my
terminal
and
and
make
a
call
here
to
this
to
the
Bumblebee
program,
I'm
gonna
see
this
automatically
created
metrics,
for
you
know
for
the
events
happening
between
this
address
and
the
other
address,
and
you
see
the
accounts
incremented
here.
A
So
this
was
an
example
only
for
that's
an
example
here
only
for
Destination
Source
Source
address
to
destination
address,
but
a
lot
of
things
can
be
monitored
using
ebpf
way
more
than
a
traditional
proxy
okay,
because
now
we
have
access
to
the
kernel.
We
can
listen
to
when
a
lot
of
many
different
things
that
we
should
never
have
access
when
we
get.
A
You
know
when
monitor
using
a
proxy
all
right,
so
this
is
done
now,
let's
actually
build
a
grafana
dashboard
that
would
use
this
metrics,
this
ebpf
metrics
to
build
something
all
right.
It's
going
to
take
a
second
here.
There
you
go.
We
are
starting
I'm
going
to
create
a
set
of
applications,
so
take
think
about
this
set
of
application
as
your
app
that
you
want
to
introduce
to
your
service
mesh-
and
maybe
you
don't
want
to
introduce
everything.
A
A
This
is
created
here,
the
namespace
first,
and
then
we
are
installing
Prometheus
I'm,
going
to
take
a
second
to
be
ready.
After
that
we're
going
to
deploy
the
ebpf
program
we
just
created
into
our
cluster.
Think
about
that
as
we
are
installing
our
service
mesh.
So
behind
the
scene,
this
is
happening.
Okay,
foreign.
A
And
at
the
end,
we
are
going
just
to
create,
install
grafana
and
have
this
graph
exporter,
which
transformed
basically
we'll
listen
also
to
the
cube
services
and
transform
that
into
a
graph
data.
So
here
let's
deploy
Bumblebee
again.
This
is
just
an
example
of
what
you
can
do
with
evpf
and
then
we're
going
to
use
a
pod
monitor
a
pod
monitor
in
current
in
Primitives.
A
Just
help
us
go
reach
out
to
certain
parts
get
on
some
address,
some
some
some
metrics
from
them
and
put
them
in
in
Prometheus
right,
so
the
Pod
monitor
got
created.
Now
we
can
generate
some
traffic
right.
This
is
going
through
my
Gateway
I'm
feeding,
I'm
feeding
data
to
Prometheus
through
this.
So
what's
happening
right
now,
I'm
making
calls
to
my
application
I
just
deployed,
but
behind
the
scene.
I
have
the
ebpf
program
running.
So
it's
listening
to
this
data.
A
This
is
created
it's
going
to
take
a
second
here
for
grafana
to
get
to
get
ready,
let's
see
but
Dash
capital
a
all
right.
It
should
be
all
right.
Everything's
running
now,
let's
take
a
look
at
grafana
I'm
clicking
here,
just
loading
first
time
starting
admin,
admins
super
secure,
password
skip
and
then
I
can
do
something
like
now.
So
now
we
have
data.
We
have
the
ebpf
data
directly
in
grafana
in
in
Primitives,
and
now
we
can
show
like
you
can
use
it
in
grafina.
A
So
again,
just
let's
say:
create
a
new
dashboard
and
create
new
one.
Here,
doesn't
matter
oops
a
a
new
dashboard,
I'm
gonna
add
a
new
panel
here.
This
is
fake
data,
but
I
can
actually
add
here.
I
can
go
back
to
go
back
to
the
main
I'm
gonna,
add
actually
a
data
source
for
my
graph
by
my
My
Graph
data,
so
ebpf
data,
the
fppf
data
are
in
Primitives
and
I
can
use
like
I
can
I
can
monitor.
A
I
can
create
graph
with
it,
but
if
you
want
to
use
a
kind
of
a
graph
representation,
I
needed
a
kind
of
an
exporter
there
that
creates
a
structure
for
for
like
a
graph,
a
graph
service
and
for
that
I'm
going
to
be
using
this
node
graph,
API
and
then
I'm
going
to
add
this
address
for
my
source
save
and
test.
Now
we
are
good,
oh
actually,
we
don't
have
to
have
all
this
space
save
and
test
there.
A
And
then,
if
I
want
to
go
to
my
here,
I'm
going
to
just
do
a
node
graph
and
there
you
go
there.
It
is
you
see
now
we
have
I,
don't
know
if
I
can
like
put
it
smaller
here,
but
here
is
a
representation.
I,
don't
know
if
you
can
see,
but
this
is
going.
This
is
kind
of
my
microservice
representation
traffic,
going
from
my
service
product
pages,
with
UI
all
the
way
down
to
my
other
microservices,
and
if
you
can
see
I
have
this
full
monitoring
without
even
a
service
mesh.
A
At
this
point
right,
I'm,
not
installing
I,
didn't
install
istio
or
install
anything
else.
This
is
just
part
of
what
evpf
can
do
for
us
in
that
matter.
In
the
monitoring
you
know
realm
now,
let's
go
back
quickly
to
have
a
conclusion
here
on
what
we
should.
You
know
what
should
care
about
ebpf
for
monitoring
it's
great.
It
has
no
impact
on
the
request
path,
so
we're
not
adding
any
proxies.
This
is
awesome.
It's
lightweight!
It's
actually
on
the
Kernel,
it
runs
proxies,
runs
in
the
user
space
eppf.
A
They
run
on
the
Kernel
side
and
they
have
actually.
We
can
report
data
to
your
space,
but
it's
kind
of
have
a
lower
footprint
on
what's
happening
in
the
proxies.
We
need
the
proxy
to
have
metrics,
though
in
ebpf
we
don't
have.
We
don't
need
anything
we
can
just
observe
directly
from
the
kernel.
The
thing
is
with
proxy:
we
have
a
good
understanding
of
L7
out
of
the
box
with
eppf.
We
have
that
we
still
needs
kind
of
a
lot
of
lots
of
work.
I
have
my
colleague
Aiden.
A
That
did
a
great
talk
yesterday
regarding
what
we
can
do
with
L7
I.
Invite
you
guys
to
to
check
his
stock
now
things
are
that
will
ebpf
replace
proxies
in
general
and
personally
I.
Don't
believe
that
I
think
we're
still
in
kind
of
the
near
future.
This
is
going
to
be
really
complicated.
Why
we
should
not
think
about
a
service
mesh
as
a
whole
like
we
need.
A
Let's
think
about
Technologies
and
just
use
the
best
out
of
every
one.
I
have
one
minute
left
just
for
the
conclusion
here.
Eppf
is
super
powerful
and
I.
Invite
you
guys
to
take
a
look
at
all
the
features
we
can
provide
with
it.
Okay,
try
to
to
see
if
you
guys
want
help,
I
mean
eat,
bumblebees
and
open
source
products.
You
can
take
a
look
there
as
first
start
for
ebbf
programs
ABP.
A
If
not
replace
traditional
capabilities
of
sidecars
and
proxies
in
these
in
near
term,
it's
evolving
we'll
see
where
it
goes,
but
for
now
it's
not
it's
not
there
yet
proxies
and
EPF
programs
can
completely
run
together.
We
showed
that
today
we
can
have
monitoring
done
by
ebpf
L7,
all
still
done
by
our
traditional
proxies
with
that
being
said,
this
is
the
end
of
my
talk
and
thank
you
guys
for
listening
to
me.
A
Yeah
yeah,
so
no
well,
that
was
because
of
bumblebees
the
tool
that
we
use
for
for
that
matter,
things
can
be
different,
plus
actually
from
a
service
mesh
user.
Honestly,
you
should
not
care
about
this.
They
should
be
embedded
within
the
service
mesh
technology
you're
using
this
code,
I
showed
you
all
this
mechanism
that
get
deployed
to
monitor
everything
that
should
be
just
part
of.
Like
your
install,
you
install
that
it's
running
in
your
cluster.
A
C
A
So
well,
when
you
create
like
an
EPF
program,
you're,
attaching
it
to
an
event
happening
on
on
the
Kernel
now
in
terms
of
Technologies
yeah,
it
doesn't
really
matter
since,
like
there
are
actually
all
sent
to
the
user
space
using
like
a
map.
You
are
doing
your
your
kernel,
your
ebpf
program,
going
to
be
standards.
There's
no
Technologies!
There,
it's
limited!
It's
super
guard
rail
once
defined.
You
are
going
to
add
it
to
your
kernel.