►
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). 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.
A Guided Tour of Cilium Service Mesh - Liz Rice, Isovalent
The Cilium project is adding Service Mesh features to its existing eBPF-enabled, identity-aware Kubernetes networking capabilities. This demo-driven talk explores how this works, and shows why it’s now possible to create a service mesh without sidecars. - Demonstrate why, before eBPF, the sidecar model was necessary for accessing an application pod’s network traffic - Explore how Cilium uses eBPF programs to connect Kubernetes endpoints - Show how this makes the sidecar model unnecessary for identity-aware connectivity - Demonstrate an example Cilium Service Mesh in use - Compare the resources used (in both userspace and the kernel) for both models Along the way, this talk will clarify some container and kernel concepts so that attendees can leave with a mental model of how eBPF-enabled service mesh really works.
A
Hi
everyone,
thank
you
so
much
for
being
here
at
the
end
of
what
seems
like
a
pretty
full-on
week.
Anybody
here
feeling
a
bit
tired
me
too
yeah,
but
we'll
we
can
do
this.
We
can.
We
can
do
this,
so
my
name's
liz
rice,
I'm
the
chief
open
source
officer
at
I
surveillance
isovalent-
is
the
company
that
originally
created
psyllium
and
today
I'm
going
to
give
a
tour
of
the
psyllium
service
mesh.
A
A
A
So
when
we
I
don't
know
why
that
thing's.
Okay.
So
when
we
announced
the
psyllium
service
mesh
beta
program
and
our
artist
vadim
came
up
with
this
nice
little
bit
of
artwork
about
getting
rid
of
side
cars,
and
I
think
some
of
that
has
been
a
little
bit
controversial.
So
I
hope
I'm
going
to
explain
today
why
we're
preferring
a
model
that
doesn't
use
sidecars
and
some
of
the
advantages
that
that
gives
us
and
how
we've
been
able
to
get
there
so
psyllium.
A
A
It
implements
connectivity.
What
else
is
networking
for
them
to
connect
our
workloads
to
each
other
and
to
the
outside
world?
It
implements
security
features.
We
have
network
policy,
we
have
network
layer,
encryption
and
it
provides
load
balancing
whether
that's
as
a
cue
proxy
replacement,
so
load
balancing
between
the
different
pods
that
make
up
a
service
or
also
as
a
standalone
load.
Balancer.
A
There's
also
a
component
called
hubble,
which
gives
us
visibility
into
network
flows,
so
we
can
get
detailed
flow
logs
of
every
network
packet
and
from
that
the
hubble
ui
can
show
you
a
service
map
showing
which
services
are
communicating
with
each
other.
We
get
lots
of
metrics
that
we
can
export
to
prometheus
and
produce
grafana
dashboards,
we'll
see
a
few
of
those
in
a
moment
and
we
get
visibility
into
the
layer,
3
4
and
layer,
7
traffic,
so
layer,
7
being
the
application
level
protocols.
A
Okay,
let's
just
step
back
a
minute
and
talk
about
the
history
of
service
mesh
so
before
it
was
even
called
service
mesh
applications
that
are
potentially
written
in
different
programming
languages
needed
to
communicate
with
each
other.
They
might
be
sending
http
messages
between
themselves
or
grpc
or
whatever
protocol,
and
perhaps
they're
implementing
tls
for
security,
and
each
application
back
in
the
day
would
need
to
import
its
own
library
to
implement
those
networking
functions.
A
A
So
we
move
to
the
sidecar
model.
Now
kubernetes
allows
us
to
group
containers
into
pods,
pods
share
a
network
name
or
all
the
containers
in
a
pod
share
the
same
network
namespace,
so
that
allows
us
to
have
a
proxy
called
a
sidecar
inside
the
pod,
with
the
application
container,
providing
the
service
mesh
functionality.
A
So,
for
example,
your
application
doesn't
need
to
worry
about
setting
up
tls.
You
can
leave
that
to
the
proxy
to
take
care
of.
You
can
leave
service
discovery,
you
can
leave
retries,
you
can
leave
all
the
load
balancing
up
to
the
sidecar
proxy
and
it
makes
life
far
easier
for
the
developer.
So
this
is.
This
is
great.
This
is
much
more
efficient
from
a
development
perspective
and
also
because
containers
are
containers.
A
You
don't
have
to
have
the
same
programming
language.
Those
cycle
proxies
can
be
come
from
a
third
party
and
indeed
many
of
them
do.
A
lot
of
a
lot
of
people
are
using
envoy,
for
example,
there's
also
linker
d.
The
proxy
can
be
the
same
in
every
application
board,
regardless
of
the
language
of
that
application.
A
A
A
Now
we
all
expect
our
networking
stack
to
be
taken
care
of
by
the
kernel.
If
we
think
of
kubernetes
as
a
distributed
operating
system
service
mesh
is
really
the
equivalent
of
the
networking
stack.
Could
we
pull
that
into
the
kernel
today
and
the
answer
is
mostly
not
quite
everything
yet
but
mostly
layer.
Seven
is
the
part
that
we
don't
really
have
today.
A
A
And
yet
psyllium
already
has
visibility
into
layer,
seven,
let's
actually
I'll
skip
to
the
demo.
First,
to
show
you
what
I
mean
about
layer,
seven
visibility,
so
is
that
big
enough
to
see
at
the
back
is
that
okay,
somebody
wave
if
you
can
see
yeah,
I
see
some
thumbs
good
right.
So
what
do
I
have
in
this
name?
A
Space
far
far
away
come
on
network
there
we
go
okay,
I
have
an
x-wing
a
tie
fighter
and
a
couple
of
death
stars
and
my
let's
suppose
my
thai
fighter
wants
to
land
on
the
death
star.
Well,
first
of
all,
I'm
gonna
start
off
some
observability,
I'm
gonna
run
hubble
to
watch
traffic
in
that
far
far
away
namespace
and
if
I
exec
into
my
tie
fighter
and
actually
I'll
find
a
previous
previous
one
of
these
will
be
easier.
A
A
Let's
see
what's
available
from
the
death
star
api
yeah,
there's
all
sorts
of
things.
I
can
do
with
this
api
good
to
see
the
empire
has
adopted
cloud
native,
so
I
don't
know
if
you've
been
noticing
these
flows
going
up
in
the
top
half
of
the
screen.
But
we
have
things
like
this,
where
we've
got
visibility
into
the
http
request.
This
is
layer
7
and
we
can
see
the
url.
The
path
that's
been
requested
and
we
can
see
the
response
here.
A
A
So
this
is
going
to
match
at
layer
3
4
it's
going
to
match
endpoints.
No,
it's
going
to
match
endpoints
in
the
empire
in
the
death
star,
and
this
is
what
it
applies
to
and
it's
going
to
police
ingress
traffic
we're
only
going
to
allow
traffic
from
other
empire
organizations
no
landing
from
the
rebel
alliance.
Please,
and
we
are
only
going
to
allow
thai
fighters
and
other
empire
equipment
to
post
to
request
landing.
Everything
else
is
not
going
to
be
permitted.
A
A
A
And
that
will
create
a
psyllium
network
policy
that
should
prevent
the
exhaust
port
from
having
anything
put
into
it.
Okay,
and
we
can
see-
let's
just
scrolled
off
the
screen-
we
can
see
that
hubble
was
able
to
see
that
level
7
request
again
and
we
can
see
that
it
was
dropped.
It
was
out
of
policy
and
if
I
take
a
look
in
my
grafana
dashboards,
we
can
see
information
about
when
traffic
requests
have
been
placed.
We
can
see
things
like
latency,
we
can
see
dns
requests
and
responses,
and
so
on.
A
A
A
A
A
We
need
to
be
able
to
have
those
more
detailed
rules
that
we
anticipate
with
service
mesh,
so
to
be
able
to
load
balance
traffic
to
different
pods
within
a
service
based
on
perhaps
what
version
they
are
and
we
want
identity
based
security,
something
I
didn't
point
out,
but
you
probably
noticed
in
the
hubble
flows
is
we
can
see
the
identities
of
the
kubernetes
services
that
are
involved?
We
can
see
the
name
space.
A
A
All
those
traffic
management
functionality
that
we
associate
with
service
mesh
is
implemented
in
envoy
and
we're
going
to
have
psyllium
program.
Those
listeners
through
a
crd
that
we
call
psyllium
envoy
config
programming,
that
in
user
space
and
programming
ebpf
for
the
network
traffic
traffic
within
the
kernel.
A
A
B
A
The
exhaust
port-
let's
hope
not
because
we
don't
want
anybody,
blowing
up
the
death
star,
yeah,
that's
not
going
to
get
there.
In
fact
that
has
been
dropped
by
the
ingress.
So
we
never
even
saw
the
traffic
here
and
again
we're
going
to
see
the
the
grafana
visibility
or
grafana
dashboard's,
showing
us
things
like
the
the
latency
of
these
requests.
We
can
see
when
things
get
dropped,
why
they
get
dropped,
so
we
should
see
somewhere
some
yeah
traffic
being
dropped
because
it
was
out
of
policy
and
so
on.
A
A
Yeah
and
I
showed
you,
the
underlying
psyllium
envoy,
config-
that
programs,
the
envoy
listeners
now
those
are
pretty
low
level,
it's
a
pretty
low
level
crd
and
although,
if
you
take
a
look
at
the
service
mesh
examples
that
we've
created,
there
are
some
examples
of
traffic
management
where
you
would
manually
program
those
psyllium
envoy
configs,
but
that's
not
really
the
end
game.
The
endgame
is
more
akin
to
what
we've
done
with
kubernetes
ingress,
where,
by
defining
the
ingress,
there's
an
operator
that
automatically
creates
the
corresponding
psyllium
envoy
config.
A
A
People
who've
tried
using
service
mesh
and
have
found
either
the
performance
or
the
complexity
of
the
service
of
the
sidecar
model
problematic.
So
I
have
a
few
examples
of
of
user
comments
about
this.
It's
not
just
the
overhead.
It's
also
the
management
complexity
that
people
found
challenging
and
the
idea
of
not
having
to
manage
such
a
complex
set
of
resources.
A
A
Consumption
of
service,
mesh
they're,
looking
for
better
performance
and
they've
also
had
problems
with
the
startup
of
sidecar
containers
where
you've
got
perhaps
in
it
containers
you've
got
your
proxy.
You've
got
your
application
containers
that
all
need
to
start
within
a
pod
and
can
cause
race
conditions
or
otherwise
have
issues
in
the
order
in
which
those
containers
come
up
talked
about
reducing
resources.
A
This
is
an
example
of
how
a
network
packet
needs
to
flow
from
an
application
through
the
networking
stack
in
the
pod
to
reach
the
service
mesh
proxy
and
then
from
there.
It
needs
to
exit
the
pod
through
the
networking
stack
to
get
to
the
host
networking
stack,
which
it
then
needs
to
traverse
to
get
out
of
the
physical
machine.
A
A
We've
also
published
the
the
details
and
the
scripts
of
how
we've
made
these
performance
measurements.
We
would
love
for
other
people
to
go
out
and
replicate
them
and
tell
us
if
we've
made
mistakes,
because
it's
obviously
important
that
we
get
this
right,
but
I
think
it
does.
It
intuitively
makes
sense
that,
if
you're
not
having
to
go
through
such
a
long
network
path,
you
will
have
better
latency
and
the
throughput
is
pretty
similar
marginally
better
from
what
we
tested,
but
pretty
similar.
A
A
A
As
an
example,
what
you
saw
with
the
kubernetes
ingress
that
there
is
an
operator
that
is
taking
that
ingress
information
and
programming
in
the
underlying
cec?
So
that's
an
example.
There
will
be
more
so
there's
one
piece
of
the
puzzle:
missing
we've
seen
connectivity,
we've
talked
about
how
we
can
program
the
envoy
proxy
we've
talked
about
visibility.
A
A
The
encryption
can
happen
within
the
kernel,
but
we
need
to
get
the
certificates
injected
into
the
kernel
in
order
to
to
perform
that
encryption
and
we
need
to
validate
those
or
authenticate
those
certificates
and
authenticate
those
identities
when
we're
setting
up
a
network
connection
so
on
the
roadmap
intended
for
the
next.
So
1.13
release
will
be
this
separation
of
authentication
in
the
user
space
layer
and
using
that
to
control
network
layer.
Encryption
again
we're
pretty
agnostic
to
where
those
certificates
come
from.
It
could
be
spiffy,
it
could
be
cert
manager.
A
A
So
with
that,
I
think
you
almost
at
the
end
of
the
day.
I
think
maybe
there's
one
more
session
to
go
so
well
done
for
maintaining
stamina.
For
this
long,
very
much
appreciate
that
you
took
the
time
to
come
here
at
the
end
of
the
week
and
yeah.
I
don't
know
if
we
have
like
a
minute
for
questions
so
yeah.
If
we
have
questions,
let's
do
it.
Thank
you
very
much.
A
D
A
I
think,
ultimately,
that
that
will
be
the
future.
Yes,
and
we
already
have
some
layer
7
passing
being
done
in
ebpf.
I
I'm
going
to
say
more
experimentally
than
in
production,
but
so,
for
example,
we
do
have
a
an
http
2
parser
that
runs
in
ebpf.
So
I
do
expect
that
eventually
it
will
be
possible
to
run
the
protocol
parsing
parts
in
the
kernel,
yeah.
E
A
You
know
argument
here
I
would
say
we
have
in
the
kernel
name,
spaces
and
c
groups
that
we
use
to
isolate
network
stacks
already.
We
don't
worry
about
the
fact
that
we're
running
pods
using
a
shared
kernel
to
run
our
network
stack
up
to
layer
4
anyway,
so
now
what
we're
doing
by
running
this
in
envoy.
A
Obviously
this
is
user
space
rather
than
in
the
kernel,
but
we're
using
that
listener
concept
as
a
a
kind
of
isolation
process.
Now
I
would
say,
if
you're
you
know,
in
a
high
security,
you
know
very
worried
about
the
the
multi-tenant
situation.
Perhaps
you
don't
want
to
run
those
different
tenants
on
the
same
node,
but
I
don't
think
that
you
know
I
think
it's
going
to
be
on
a
case-by-case
basis,
whether
that's
important
I've
also
heard
people
talking
about
worrying
about
like
the
potential
for
sort
of
interference,
noisy
neighbors.
A
E
B
A
F
A
So
I
don't
think
it's
different
from
what
we
already
have
in
networking
in
the
kernel
with
psyllium,
and
we
have
some
great
tools
for
observing
that
you
know
we
hubble
gives
us
a
lot
of
visibility
into
where
there
are
various
different
hooks.
Where
we're
hooking
ebpf
programs,
we
can
use
that
to
get
visibility.
A
A
I
don't
know
how
that
maps
to
sort
of
what's
happening
in
that
envoy
space,
I'm
sure
there
will
be
learnings
and
maybe
there
will
need
to
be
more
tools,
but
I
don't
think
the
fact
that
it's
moving
to
or
that
you
might
be
moving
to
a
kernel-based
networking
layer,
people,
love
hubble
for
debugging
networking
issues,
and
we
have
some
users
who
really
run
at
massive
scale.
We
had
datadog
yesterday
talking
about
thousands
of
nodes
and
I
think
they
found
the
tools
really
useful.
So
I'm
optimistic.
B
G
Great
talk
first
and
I
have
a
question
about
debugging.
In
this
context,
I
mean,
from
my
point
of
view
having
a
sidecar
container.
It
provides
isolation
also
in
terms
of
debugging,
meaning,
if
there's
an
application,
not
working.
I
can
just
isolate
the
problem
to
that
pod
and
check
the
logs
in
the
sidecar
container.
G
A
A
G
A
A
So
it's
one
proxy
per
node
because
it
runs
in
the
psyllium
agent
and
we
have
one
proxy
per
node.
I
think
there
may
be
you
know.
When
we
talk
about
this
sort
of
security
model.
There
may
be
reasons
to
explore
doing
one
proxy
per
name
space,
for
example,
and
and
possibly
to
do
with
you
know
the
right
abstraction
for
configuration
yeah.
A
I
think
that's
a
fair
comment
and
that
might
be
a
good
reason
to
have
multiple
instances.
I
I
think
the
the
argument
that
I've
heard
normally
about
that
model
is
well.
You
might
be
running
custom,
you
know
wasn't
filters
or
whatever
in
your
envoy
and
so
they're
custom.
They
might
not
be
very
tested
or
hardened,
so
things
could
go
wrong.
A
That
could
be
a
really
good
reason
to
not
run
that
proxy
across
your
whole.
Node
perhaps
have
a
yeah
use
sidecars
for
that
for
those
particular
applications
where
you
need
those
custom
filters
that
you're
not
very
confident
in,
I
think
you
know
there
will
be
scope
for
applying
a
hybrid
of
these
different
models,
but
I
think
for
the
you
know,
sort
of
a
90
percent
use
case
where
people
don't
need
to
do
anything.
Super
custom
they're
using
kind
of
pretty
standard
filters
that
are
very
field
hardened.