►
From YouTube: Cilium’s Evolution: The Founding Story of Cilium
Description
How did Cilium get started? Thomas Graf, Co-Creator of Cilium, explores the foundation story of the Cilium open source project: how we got started, how it relates to eBPF superpowers, and what lead to all major cloud providers adopting it as the default networking and security layer for at least one of their managed Kubernetes platforms.
0:00 Cilium Introduction
1:43 What is eBPF?
4:25 Why did we create Cilium? What are all Cilium projects?
5:50 The origins of Cilium - Founding Team
6:44 Kubernetes Networking
9:18 Network Security & Encryption
11:22 Hubble - Network Observability
13:11 Cluster Mesh - Multi-Cluster Kubernetes
14:40 Google & AWS pick Cilium
16:08 Tetragon
20:00 Load-Balancing
20:48 Timescape
23:51 Service Mesh
26:54 Service Mesh - Split between proxy and eBPF?
30:08 Isovalent and Grafana Labs
30:48 The Roadmap ahead
32:50 Q&A
A
Welcome
everybody:
my
name
is
Thomas
Groff
I'm,
one
of
the
creators
of
psyllium
I'm,
also
co-founder
of
I
surveillance,
a
company
we
created
around
sodium
today
this
session
is
on
the
history
of
psyllium.
When
did
we
started?
Why
did
we
start
it
and
so
on?
So
let's
Jump
Right
In.
So,
first
of
all
what
is
psyllium,
and
most
of
you
probably
already
have
a
good
understanding
of
that.
So
I
literally
only
have
one
slide
on
this
in
case
somebody
has
never
heard
about
psyllium
psyllium
is
a
cncf
project.
It
is
at
incubation
stage.
A
A
psyllium
is
widely
deployed
today
across
many
many
different
end
users,
and
you
see
in
a
subset
of
logos
on
here
who
are
all
the
end
users
out
there
that
are
utilizing
setup,
there's
actually
a
long
list
of
selling
users
in
the
GitHub
repository
where
you
can
find
details
on
who
is
using
psyllium.
Why
they're
using
psyllium
and
what
they're
using
psyllium
4.,
initially
I,
will
get
to
the
details
of
that
cylind
was
created
by
I
surveillance
or
by
Engineers,
who
later
created
eye
surveillance.
A
We
then
donated
sodium
to
the
cloud
native
Computing
foundation,
so
CLM
is
today
owned
by
the
cncf.
We,
of
course
have
a
variety
of
contributors.
Data
are
not
from
eye
surveillance
or
the
the
set
of
contributors
and
people
working
on
psyllium
is
very
diverse.
Today,
at
the
foundation
of
psyllium
is
ebpf,
and
as
we
go
through
the
history
of
psyllium,
you
will
see
that
this
actually
played
a
major
role.
In
fact,
edpf
is
the
reason
why
we
created
ethelium,
it's
even
more
extreme.
A
We
actually
continued
working
on
ebpf
for
about
a
year
to
get
ebpf
to
the
point
where
we
could
actually
get
started
to
build
psyllium.
So
it's
actually
fair
to
say
that
we
saw
evpf.
We
saw
the
potential
we
continued,
developing
it
and
making
progress
on
it
and
then
about
a
year
later,
we're.
Finally,
at
the
point
where
we
could
use
ebpf
to
build
what
we
envisioned
in
terms
of
sodium.
So
what
is
this
ebpf
technology,
and
some
of
you
may
have
seen
a
slide
similar
to
this
right.
Ebpf?
A
If
you
want
to
boil
it
down
to
kind
of
one
sentence,
that
makes
somewhat
sense
to
most
people.
It
is
what
JavaScript
is
to
the
browser.
Ebpf
is
to
the
Linux
kernel.
Javascript
also
makes
the
browser
programmable
ebpf
makes
the
Linux
kernel
programmable
out
conceptually
the
same.
The
implementation
and
the
performance-
and
all
of
this
is
obviously
very,
very
different,
but
if
we
take
it
just
slightly
deeper
look
on
the
left,
you
have
like
a
JavaScript
program,
and
typically
you
would
do
something
like
this,
where
you
would.
A
This
is
obviously
very
simplified,
but
you
would
run
a
bunch
of
code
when
a
website
user
clicks
on
the
submit
button.
That's
obviously
one
of
the
the
first
use
cases
that
JavaScript
ever
solved
run
some
code.
When
you
submit
a
form.
This
is
very
similar
for
ebpf.
We
have
an
operating
system
and
we
have
a
process,
an
application
when
the
process
makes
the
system
call.
For
example,
in
this
case,
the
access
system
call
exact
system
call.
We
can
run
an
ebpf
program
when
that
happens,
and
the
program
looks
very
different.
A
You
see
on
the
right
side,
sudo
C
codes
or
C
code
like
ebpf
code
on
the
left
side.
Of
course,
JavaScript.
So
conceptually
quite
similar
and
they've
also
unlocked
like
a
a
similar
amount
of
innovation.
Of
course,
the
level
and
the
the
system
level
they
operate
at
is
widely
violently
different,
but
let's
get
to
psyllium.
So
why
did
we
create
psyllium?
Why
did
we
create
so
many
different
projects
around
sodium,
because
psyllium
is
not
just
one
project?
There's,
of
course
the
cni
which
I
guess
most
of
you
have
heard
about
before.
A
A
It
needs
psyllium
underneath
to
run
and
then
provides
extensive
observability
functionality
with
nice,
grafana,
dashboards,
Prometheus,
metrics
and
so
on,
and
then,
lastly,
tetragon
the
security
observability
and
runtime
enforcement
layer
that
operates
with
sodium,
but
you
can
run
it
completely
independent
of
psyllium
cni
as
well.
What
connects
all
of
these
projects
together
again
is
evpf
they're,
all
evpf
based
and
they
are
all
leverage
ebpf
to
the
most
extent.
So
we've
built
all
of
these
projects
essentially
to
exploit
the
powers
of
pdpf.
So
let's
go
back,
can
actually
look
at
the
origins
of
cerium.
A
When
did
we
start
it?
Why
did
we
start
it?
What
was
the
vision?
It
was
the
founding
Team
all
the
way
back.
This
is
actually
the
first
ever
psyllium
design
Summit
at
a
place
called
diabolezzo
in
Switzerland,
it's
high
up
in
the
mountains.
The
weather
was
not
really
great.
You
see
the
founding
team
here,
Andre
Martins,
Daniel
borkman
model
and
myself
I
took
the
pictures.
I
was
not
in
the
picture
itself.
We
essentially
did
kind
of
a
social,
a
social
Expedition,
into
the
mountains
as
a
team
as
a
team
activity.
A
Equally,
and
in
this
initial
phase,
we
focused
exclusively
on
networking
container,
networking
and
layer,
3
layer
for
load
balancing,
and
we
had
a
very
clear
vision
in
mind.
We
want
to
be
intent,
so
there's
obviously
there's
a
typo
in
the
in
the
slide
here:
intent
and
identity
based.
We
wanted
to
be
high
performance
and,
of
course,
also
scalable
and
really
focus
on
container
networking
around
this
time.
2016.
A
Essentially,
a
lot
of
the
industry
was
moving
away
or
moving
forward
from
openstack
and
virtualization,
and
containers
and
Docker
and
kubernetes
were
Rising
very
very
quickly,
and
it
became
clear
that
the
existing
solutions
would
not
scale
to
the
demands
of
containers
and
I.
See
a
question.
Does
psyllium
service
mesh
work
on
layer,
two
or
three
or
using
layer
7,
so
psyllium
will
operate
all
the
way
from
layer
2
to
layer
7..
It
mostly
operates
in
layer,
3,
layer
4..
It
can
also
operate
on
Layer
Two,
so
we
can,
for
example,
do
multicast
at
L2.
A
We
can
do
ARP
pass
through
and
things
like
this
and
we
all
can
also
operate
at
layer
seven.
So
really
we
work
across
the
entire.
What's
called
Aussie
layer
schema
foreign.
This
is
the
first
time
we
actually
talked
about
silly
I'm.
Sorry,
it
was
at
Linux
con
2016
in
Toronto
we
positioned
a
psyllium
as
a
fast
IPv6
container
networking
with
BPF
and
XDP.
In
fact,
it
was
actually
ipv
only
in
the
first
version,
so
you
didn't
even
Implement
ibv4
support
at
all.
Only
IPv6
there
was
no
concept
of
networking.
We.
A
We
were
sure
that
we
can
provide
networking
connectivity
without
requiring
our
end
users
to
even
understand
what
is
the
subnet
and
so
on,
and
we
already
had
policy
or
network
security
decoupled
from
the
ad
from
from
the
other
thing.
So
that's
the
identity
based
security
and
it
was
a
giant
flat,
L3
Network,
which
today
we
take
for
granted,
but
back
then
that
was
actually
a
relatively
new
concept
and
this
basic
architecture
that
you
see
on
here,
that's
still
how
psyllium
operates
today.
A
To
the
most
extent,
it's
a
little
bit
more
complicated
today,
but
Foundation
is
still
in
place
today,
fast
forward,
just
a
little
bit.
What
was
the
next
kind
of
problem
we
tackled
and
took
on
Well
network
security
at
layer
three
to
layer?
Seven,
so
we
don't
only
build
a
firewall
that
was
able
to
do
container
Network
policy
enforcement,
so
segmentation
or
network
firewalling.
A
We
did
that
not
only
on
the
network
level
but
inclusive
of
layer,
7
with
support
for
HTTP,
Kafka,
grpc
and
so
on,
and
we
also
built
in
encryption
using
initially
ipsec
to
transparently
encrypt
all
of
the
network
traffic,
so
that
was
essentially
our
network
security.
1.0-
and
that
was
the
initial
bigger
feature
sets
of
psyllium
that
actually
led
us
to
the
famous
dockercon
2017
talk.
This
was
the
first
really
really
big
conference.
Talk
we've
done,
dockercon
2017
in
general
was
really
really
big.
This
is
also
where
kubernetes
really
got
started.
A
So
Solomon
kubernetes
share
quite
a
bit
of
history.
There
there
was
this
Infamous
Star,
Wars,
themed
demo,
that
a
lot
of
people
have
seen
many
many
sodium
users
are
actually
refer
back
to
this
moment
to
this
Docker
contact
when
they
first
heard
about
so
this
talk
is
still
available
on
YouTube.
If
you
want
to
have
a
look,
was
essentially
showcasing
networking
container
networking
with
Docker
and
network
security
layer
3
to
layer
7
as
well
as
encryption.
A
This
is
also
when
we
actually
found
that
I
surveillance,
the
company,
so
we
started
our
surveillance
about
a
year
after
creating
psyllium,
and
you
can
see
here,
we
got
our
first
office,
see
one
of
our
our
leading
Engineers
I'm
ironing
the
kind
of
a
cubecon
back
wall
that
we
took
back
to
the
office,
and
we
also
celebrated
Andre's
birthday.
Here
we
actually
created
the
psyllium
logo
because
it
was
actually
slightly
different
before
it
was
roundish.
A
Some
of
you
have
actually
remember
the
old
silly
logo,
so
we
really
did
it
and
used
kind
of
a
more
hexagon
type
shape,
which
everybody
recognizes
as
the
psyllium
logo.
Today,
the
next
bigger
integration
stat
was
hobble
and
Hubble.
It
provided
the
network.
Observability
part.
This
is,
but
this
was
completely
new.
Like
network
observability
was
kind
of
an
was
kind
of
an
author
thought
in
general,
like
there
was
not
a
lot
of
observability
back,
then.
A
Typically,
the
only
option
you
had
was
to
go
back
and
run
TCP
dump
right
like
go
in
and
run
TCP
down
by
the
node
and
somehow
figure
out
like
what's
going
on,
and
that
was
just
horrible
for
container
networking
and
kubernetes
in
particular
at
larger
scale.
That
was
a
complete
no-go,
so
we
built
hobble
and
Hubble
can
run
in
the
kubernetes
cluster
and
it
can
see
all
the
network
all
the
network
activity
it
can
provide
so-called
flow
logs.
What
are
the
packets?
What
is
where
are
they
flowing?
What
is
being
dropped?
A
Why
are
things
being
dropped?
It
can
also
collect
metrics,
so
you
can
also
understand
how
much
traffic
is
Flowing.
How
many
DNS
requests
are
failing?
What
is
the
HTTP
request,
response,
latency
and
so
on?
And
this
really
allows
to
troubleshoot?
This
is
also
when
we
built
an
additional
feature
into
the
network
security
layer,
the
Sim
or
the
Sim
integration,
where
we
could
take
network
observability
data
and
extract
the
security
relevant
portion
and
feed
that
into
an
SIM.
What
a
security
team
can
query
it
2018
we
continued
to
grow.
This
is
I,
think,
is
that
cubecon?
A
A
Shortly
after
we
built
cluster
mesh
and
cluster
mesh
is
the
ability
to
mesh
multiple
kubernetes
clusters
together,
while
preserving
all
of
the
existing
features,
network,
security,
network,
observability
and
so
on,
and
while
also
introducing
what's
called
Global
Services,
where
you
can
do
low
balancing
across
multiple
clusters.
So
we
have
been
extending
our
reach
East
West,
so
we,
instead
of
just
being
able
to
handle
a
single
cluster,
all
of
a
sudden
we
could
handle
multiple
clusters.
A
We
actually
presented
this
back
in
2018
at
kubecon,
where
we
for
the
first
time,
demoed
a
kubernetes
cluster
running
in
Google
cloud
and
a
kubernetes
cluster
running
in
AWS
how
to
match
them
together
across
multiple
vpcs
and,
of
course,
this
culture
was
always
in
the
picture
as
well.
This
is
a
picture
from
a
fondue
which
is
a
national
dish.
A
In
Switzerland
we
did
in
an
Airbnb
in
Palo
Alto
with
the
with
the
team,
so
that
the
roots
in
the
Swiss
mountains,
it
has
always
been
preserved,
and
you
will
see
a
couple
of
pictures
later
on.
We
keep
coming
back
to
our
space
routes
and,
of
course,
fondue
or
swiss
dish
is
not
good
enough.
There's
also
a
lot
of
skiing
that
is
going
on.
A
This
is
actually
an
off-site
with
the
team
a
couple
of
years
later
on,
where
we
all
went
skiing
and
on
the
Lower
Side,
you
can
see
a
nice
picture
of
the
city
of
Zurich
where
we
had
a
nice
dinner
and
enjoy
the
view
over
beautiful
Zurich
2021
couple
of
years
fast
forward.
Things
started
to
get
really
really
really
crazy.
This
is
when
psyllium
joined
the
cncf
in
the
cloud
native
Network
category.
A
It
is
also
the
year
when
Google
picked
psyllium
as
the
new
default
networking
layer
for
both
gke
and
antos,
as
well
as
Amazon
picked
psyllium
for
eks
anywhere,
the
on-prem,
offering
of
the
managed
kubernetes
platform
that
AWS
offers
ecsa.
So
this
was
actually
a
big
year
and
we're
like
wow.
This
is
really
really
insane
like
this
things
are
going
really
great.
Everybody
started
to
use
Solium
and
there
was
a
lot
of
a
lot
of
excitement.
A
One
year
later,
things
got
even
crazier.
As
a
company,
we
were
able
to
raise
quite
a
bit
of
additional
money
because
our
product
gained
a
lot
of
traction
and
Microsoft.
As
the
last
of
the
three
big
cloud
providers
invested
into
sodium
and
made
it
to
the
the
default
for
Azure
as
well,
so
we
now
have
on
AKs
Azure
cni
powered
by
psyllium.
A
So
all
three
big
cloud
providers
have
at
least
one
managed
kubernetes,
offering
that
now
uses
psyllium
by
default,
so
Microsoft
joined
investors
such
as
Google,
Cisco,
a16c
and
so
on,
which
which
allowed
us
to
continue
development
of
sodium,
the
open
source
product
and
I
surveillance
Enterprise.
The
Enterprise
distribution
that
I
surveillance
offers
last
year
was
also
the
year
when
we
introduced
tetragon,
where
we
essentially
moved
Beyond,
just
a
networking
level
and
added
runtime
security
and
runtime
observability
in
the
form
of
tetragon.
A
So
this
allowed
us
to
not
only
see
the
network
layer
end
to
end
it
all
of
a
sudden
also
allowed
us
to
see
into
the
applications
and
into
the
system.
So
this
essentially
added
depth
to
the
security
solution
we
have
so
instead
of
choosing
Network
observability.
All
of
a
sudden.
We're
now
also
able
to
see
system
calls
file,
access,
privilege,
escalations
and,
to
a
better
extent,
even
Network
observability
that
is
not
accessible
on
the
wire.
But
where
you
actually
need
to
instrument
the
network
stack
as
well,
and
it
was
not
just
observability.
A
We
also
added
the
real-time
runtime
enforcement
layer
that
allows
to
extract
inject
policy
rules
to
Define
what
are
things
that
an
application
is
allowed
to
do
and
what
are
things
they're
not
allowed
to
do,
and,
and
in
particular
then
patragon
enforces
those
policies.
You
can
run
tetragon
completely
separate
if
you
run
it
together
with
syllium
and
Hubble,
they
all
use
data
from
each
other
and
provide
a
better
security
posture
overall.
A
So
this
is
the
tetragon
offering.
You
may
have
seen
this
in
the
announcement
last
year,
kind
of
all
the
things
that
tetragon
offers
a
lot
of
visibility
based
on
ebpf
probes
in
the
kernel,
with
a
lot
of
Integrations
in
user
space
on
how
to
actually
expose
this
visibility
to
different
apis
from
me:
Fierce
metrics,
grafana,
Sim,
of
course,
fluent
D,
elasticsearch,
open,
Telemetry
and
so
on,
and
then,
of
course,
as
well.
A
A
So,
yes,
the
question
is:
will
this
be
recorded?
Yes,
this
will
be
recorded
and
we
will
make
the
recording
available
to
everybody
afterwards.
Of
course,
couple
of
examples.
What
are
things
that
tetragon
can
provide-
and
this
is
really
just
a
small
little
subset
of
all
the
different
things
that
Tetra
can
tetragon
can
do
from
like
network
interface
metrics
to
introspecting,
like
the
tlsu's,
where
we
can
see
all
the
TLs
handshakes
and
where
are
they
going
to
what
TLS
version?
What
Cipher
version
we
can
trace
the
entire
network
level
or
kind
of
what?
A
What
network
activity
in
the
application
does?
We
can
understand
process
execution,
build
process
and
system
tree.
That's
what
you
see
in
the
lower
left
and
then,
of
course,
file
Integrity
monitoring.
We
can
see
every
file
access,
we
can
see
when
file,
content,
changes
and
so
on.
So
such
a
tetracon
can
be
a
massive
source
of
security,
relevant
observability
data
that
you
can
use
to
better
understand
your
system.
Your
applications
understand
threat
models
and
then,
of
course,
react
to
them.
As
well
of
course,
we
always
had
fun.
This
was
the
famous
snow
chain
incident.
A
Julia
pass
in
Switzerland
part
of
the
team,
decided,
let's
go
early,
we
want
to
go
skiing,
they
got
into
a
pretty
severe
snowstorms
that
I
had
to
mount
snow
chains
on
the
on
them.
On
the
mountain
pass,
and
you
see
a
typical
engineering
set
up
here
right,
two
two
Engineers
are
trying
to
figure
out
how
to
put
the
snow
chains
on
one
engineer
is
checking
YouTube
on
how
to
actually
do
it
and
the
fourth
person
is
just
taking
your
video.
A
That's
a
typical
engineering
setup
right
there,
so
we
keep
coming
back
to
an
amounts.
This
is
a
picture
of
last
year
of
the
team,
actually
very
close
by
to
that
original
picture.
You
saw
in
the
in
the
in
the
first
slide
when
we
started
the
whole
journey.
Of
course,
by
now
the
team
has
grown
quite
a
bit.
A
We
continue
kind
of
adding
pieces
to
psyllium,
so
the
next
piece
was
the
load
balancer
so
essentially
to
run
psyllium
as
a
load
balancer
in
front
of
a
kubernetes
cluster.
So
far
we
have
been
able
to
do
load.
Balancing
inside
of
the
kubernetes
cluster
or
across
clusters,
with
the
low
balancer
or
the
Standalone
local
answer
outside
all
of
a
sudden,
you
could
run
a
psyllium-based
local
answer
in
front
of
the
cluster
and
balance
traffic
across
multiple
clusters,
or
do
Canada
routing
and
so
on.
A
So
that
was
great,
so,
whatever
traffic
that
would
come,
let's
say
from
a
smartphone
or
some
iot
device
or
like
a
laptop
whatever
some
incoming
traffic
into
the
cluster,
you
could
now
use
psyllium
to
do
the
load,
balancing
and,
of
course,
gain
observability,
Network
policy
control
and
so
on,
but
we
didn't
stop
there.
We
also
added
Timescape.
So
one
big
ask
of
all
of
our
users:
was
you
have
all
of
this
great
observability
data?
A
How
do
I
store
this
over
time?
How
do
I
make
this
persistent
I
want
to
have
this
time
machine
and
go
back
and
look
what
happened
two
weeks
ago
or
three
hours
ago
and
I
want
to
be
able
to
do
that
across
all
the
different
platforms,
no
matter
where
sodium
runs,
so
we
built
Timescape
or
Hubble
Timescape.
It's
a
click
house
based
time
series
database,
where
you
can
take
all
the
observability
data
from
the
load
balancer
to
the
psyllium
cni
Hubble
tetragon,
all
the
pieces,
whatever
their
observability
data
they
produce.
A
You
can
feed
all
of
that
into
Timescape
and
you
can
feed
that
from
as
many
clusters
as
you
want,
or
even
from
the
Standalone
load
balances
that
are
not
running
in
kubernetes
at
all
feed,
all
of
that
in
Timescape
and
then
run
Hubble
UI,
the
nice
dashboards
on
top
of
that
or
directly
around
analytics
queries
on
top
of
Timescape.
So
this
gave
both
the
the
network
time
machine
where
you
can
go
back
and
see
what
happened
two
weeks
ago
from
a
network
perspective,
but
also
analytics
capabilities
from
a
runtime
run
time
perspective.
A
So
you
can
go
in
and
say
two
days
ago,
in
this
time
period.
What
files
did
this
part
access
or
did
file
content
change
or
what
was
the
network
policy
change
that
happened
at
this
time
at
this
timestamp
and
so
on.
So
you
can
store
all
of
this
very
effectively
in
a
Time
series.
Database
called
Timescape
based
on
click
house
question.
A
Why
not
use
grafana
mimir
instead
of
Timescape,
since
you
partner
with
grafana
Labs
great
question
so
first
of
all,
yes,
you
can
of
course
use
grafana
mimir
as
well,
and
that's
fully
compatible
it's
a
great
solution.
We
actually
started
building
Timescape
a
little
bit
earlier
than
we
partnered
when
we
announced
the
partnership
with
grafana
the
benefit
of
Timescape
based
on
it
actually
understands
the
observability
data
schema,
so
it
actually
understands
hobble
touch
psyllium,
cni
natively,
which
makes
it
more
efficient
from
an
analytics
perspective.
A
So
if
you
go
in
and
actually
just
want
to
have
persistent
flow
logging
I
think
something
like
rafana
mimir
is
awesome
and
great.
If
you
want
to
run
really
complex
analytics
on
security
data
or
if
you
have
a
lot
of
data-
and
you
want
short
query
times,
then
Timescape
with
click
house
can
be
a
bit
more
a
bit
more
efficient.
So
that's
the
the
main
trade-off.
There
is
having
something
that
is
general
purpose
like
maybe
or
having
something
clickhouse
based
where
we
actually
built
tetragon
specific
awareness
into
Timescape
itself.
A
That
said,
you
can,
like
top
Timescape
itself,
has
a
completely
compatible
Hubble
API.
So
you
can
actually
run
Prometheus
metrics
on
it.
You
can
run
grafana
on
Timescape,
it's
actually
even
better.
We
even
built
a
grafana
plugin
that
you
can
use
with
the
entire
grafana
ecosystem
and
it
queries
directly
from
Timescape
as
well
service
mesh
right
last
of
the
big
innovation
Cycles
at
least
so
far.
A
lot
of
our
users
said
great
I
love
the
cni
layer,
I
love
the
observability.
You
can
already
operate
at
layer,
seven.
A
Why
are
you
not
a
service
mesh
and
we
really
struggle
with
these
so-called
sidecar
proxies?
Can
you
give
us
something
that
is
better,
because
up
to
this
point,
our
answer
to
service
mesh
was
go
run
istio.
We
had
an
istio
integration
that
was
functional
and
great
many
users
running
istio
on
top
of
psyllium,
and
there
was
a
better
A
Better
Together
story.
So
what
more
could
we
want?
A
lot
of
users
said:
please
make
it
a
little
bit
simpler.
Please
remove
those
sidecars,
please
just
build
up
this
build
service
mesh
as
a
feature
into
psyllium.
A
So
that's
what
we
did,
that
you
see
why
the
kind
of
none
of
the
picture
part
changes,
because
service
mesh
is
essentially
just
a
feature
that
you
can
enable
feature
flag,
sorry
smash
enabled
and
you
get
a
full-blown
service
mesh
as
part
of
psyllium.
In
the
first
iteration
we
primarily
built
layer,
7,
load,
balancing
and
tracing,
because
we
already
had
the
layer
7
of
our
Network
policy.
You
see
this
on
the
left
in
the
network
security
bracket.
We
already
have
Network
policy
layer
3
to
layer
seven.
A
We
also
already
have
encryption
as
well,
so
the
main
piece
is
missing
in
the
first
version
were
layer
7
though
balancing
and
HTTP
tracing.
So
that's
what
we
added
in
the
first
version
that's
fully
available
today,
so
you
can
use
Ingress,
Gateway,
API
or
even
just
annotate
kubernetes
services
to
perform
layer,
7,
load
balancing
and
you
can
easily
just
enable
HTTP,
tracing
and
Export
that
as
metrics
or
open
Telemetry
as
well,
no
need
to
restart
Parts
when
service
mesh
is
enabled.
I
would
have
to
double
check
on
that.
A
I
think
it
is
possible
without
a
restore,
because
the
envoy
proxy
will
be
started
on
demand
as
needed.
It
I
think
it
will
depend
on
whether
your
psyllium
configuration
disables
Envoy.
So
if
it
is,
if
it
does
disable
and
one
way,
then
you
need
to
enable
that
and
restart
psyllium.
If
Envoy
is
configured
to
run
on
demand,
then
I
think
you
don't
need
to
restart
anything
at
this
point,
but
probably
best
to
check
in
the
psyllium
slack
whether
that's
actually
accurate
or
not
our
service
mesh
control
plane
across
clusters.
Is
there
a
separate
solution
plant?
A
Yes,
we'll
get
to
that.
So
that's
one
of
the
next
steps
in
this
service
mesh
offering
we're
essentially
right
now
piggybacking
on
kubernetes
kubernetes
itself,
so
you
can
Define
kubernetes
Ingress
resources
or
Gateway
AP
Gateway
API
resources,
but
they
are
limited
or
there's
scoped
to
one
cluster.
So
it's
on
you
to
actually
insert
them
into
all
the
different
classes.
That's
what
we
have
today.
Can
we
get
a
link
for
the
psyllium
slack
very
easy
go
to
psyllium.io.
A
There
is
a
big
slack
button
at
the
top
at
the
top
click
that
to
get
access
to
the
psyllium
Slack.
So
if
this
service
mesh,
what
is
actually
then
different
like?
Why
did
we
actually
build
it
in
the
end,
because
there
were
a
variety
of
service
meshes
already
on
the
market?
At
this
point,
the
main
difference
is
that
we,
first
of
all,
we
remove
this
sidecar
proxy,
so
the
need
to
run
one
proxy
for
each
and
every
part,
but
then
we
can
even
go
further.
A
We
can
even
run
ebpf
native,
so
no
proxy
whatsoever
for
a
lot
of
the
use
cases
and
for
those
use
cases,
essentially
the
all
of
the
the
logic
all
of
the
data
path.
Implementation
is
all
in
ebpf
in
the
current,
so
there
is
no
need
to
redirect
connections
or
to
terminate
connections
or
to
run
a
proxy
whatsoever.
Everything
on
this
slide
selling
service
mesh
can
do
everything
on
the
left.
A
So,
of
course,
anything
at
layer,
3,
layer,
4,
Canary
to
policyware,
routing,
multi-cluster
capability,
Network
policy
and
mtls,
currently
in
beta,
as
well
as
all
of
the
observability
tracing
open,
Telemetry
metrics
for
HD,
P,
TLS,
DNS,
TCP
and
UDP.
All
of
that
can
be
done
in
ebpf
Native
and
then,
if
we
go
to
the
right
side,
all
of
that
is
also
supported.
Layer,
7
load,
balancing
Ingress,
retries
layer,
7
rate
limiting
TLS
termination,
TLS
origination,
so
that
those
are
the
cases
when
psyllium
does
not
control
both
sides.
A
If
we
can,
if
we
control
both
sides,
both
endpoints,
of
course,
you
can
run
mtls.
If
we
don't
control
both
sides,
then
you
need
either
terminal
TLS
termination.
If
you
only
control
the
terminating
side
or
origination.
If
you
only
control
the
originating
side,
that's
when
we
need
a
proxy
as
well
as
Network
policy.
A
A
So
yes,
I'm,
aware
of
all
of
them,
of
course,
also
Falco
and
so
on.
The
main
difference
is
that
tetragon
is
very
extreme
in
what
it
provides
and
implements
in
the
in
the
inside
of
the
Linux
kernel.
So
typical
other
approaches
have
a
very
a
relatively
minimalistic
ebpf
based
kernel
level,
probe,
any
primarily
just
extracts,
visibility
and
then
the
actual
engine
that
will
react
based
on
that
observability
is
in
user
space,
and
this
leads
to
so-called
reactive
or
asynchronous
enforcement.
A
Tetragon
is
different.
It
actually
encodes
all
the
enforcement
logic
or
the
vast
vast
majority
of
that
in
the
kernel.
So
it
can
actually
react
in
real
time
while
threats
are
still
ongoing,
so
it
doesn't
have
to
send
the
events
to
user
space
and
react
in
hindsight.
It
can
react
right
when
it
sees
activity
in
the
kernel,
and
that
is
not
only
better
from
a
real-time
enforcement
perspective.
It
also
leads
to
more
efficient
observability,
because
we
can
aggressively
create
histograms
or
metrics
in
the
kernel
instead
of
exporting
a
lot
of
raw
data
and
then
calculate
metrics.
A
On
top
of
that,
we
can
provide
a
link
to
the
tachogon
webinar
that
we
did
a
couple
of
months
back.
That
goes
all
into
the.
It
goes
into
all
the
details
of
tetragon.
Then
somebody
already
mentioned
this
yes.
Last
year
we
also
announced
the
partnership
with
grafana,
which
is
amazing.
We
already
have
several
joint
efforts
that
have
been
appearing
so
far,
including
of
course,
the
grafana
plugin
for
psyllium
and
we're
looking
to
integrate
deeply
with
the
grafana
ecosystem.
I
think
this
is
really
a
match
made
in
heaven.
We
understand
ebpf
very,
very
deeply.
A
Looking
a
little
bit
forward.
What
are
we
actually
working
on
right
now,
and
some
of
this
is
already
has
already
come
out
in
113
that
we
released
a
couple
of
weeks
back,
and
some
of
this
is
essentially
will
be
part
of
114
coming
in
in
coming
this
summer.
We
call
this
network
security
2.0
and
it's
essentially
the
combination
of
service,
mesh
and
network
security
at
the
network
level.
A
A
That
are
that,
where
you
can
run
a
service
mesh,
it
should
really
be
applicable
to
all
the
endpoints,
so
we're
bringing
an
mtls
model
to
the
world
of
network
policy,
where
you
can
simply
Define
kubernetes
Network
policies
run
spiffy
and
do
authentication
for
what
is
allowed
by
your
network
policies
applicable
to
all
the
network
traffic.
So
no
limitation,
TCP
only
ipv4,
only
or
something
like
this
applicable
to
all
of
the
all
of
to
all
of
the
network.
Traffic
and,
of
course,
with
the
API
Gateway
we're
bringing
that
to
the
load
balancer.
A
So
you
can
essentially
run
layer,
7,
load,
balancing,
including
Gateway
API,
based
routing
on
the
external
or
on
the
Standalone
logo
balancer.
As
well
and
with
that,
we
are
looking
as
a
next
step
to
then
get
into
a
more
centralized
or
an
orchestrated
control
plane
where
we
can
do
orchestration
of
policies,
load,
balancing
and
so
on
across
multiple
clusters.
A
A
Of
course,
if
you
want
to
learn
more
about
psyllium
and
isovalent,
of
course,
psyllium.io
is
your
starting
point
for
psyllium
has
lots
of
resources
I
surveillance.com
resource,
in
particular,
for
all
the
interactive
labs,
future,
webinars
and
so
on?
And
of
course
you
can
get
in
contact
with
us
regarding
the
Enterprise
distribution,
if
that
is
of
Interest,
those
are
the
two
main
links
to
follow
up
to
find
more
information.
So,
let's
go
into
the
Q
a
I
see
a
couple
of
questions
already
does
psyllium
have
use
cases
in
web
3,
peer-to-peer
networking?
A
Of
course
you
even
in
those
I
would
say:
Advanced
Advanced
use
cases.
You
still
need
fundamental
networking.
So
yes,
of
course,
you
can
use
psyllium
directly.
It
is
in,
in
fact,
very
well
aligned
with
the
technology
stack
that
you
typically
use
for
web
3,
modern
protocols,
but
there
is
nothing
web3
specific
in
sodium,
so
there
is
no
web3
support
or
something
like
this
Celine
provides
generic
model.
A
Networking
that
you
can,
of
course,
use
to
build
web
free
or
peer-to-peer
networking
support
next
question:
how
much
of
development
do
you
expect
will
occur
to
make
Windows
a
first-class
citizen,
or
at
least
a
valid
endpoint
for
psyllium
and
to
tooling
around
good
question?
We
we
saw
the
first
demo
of
psyllium
in
at
kubecon
in
Valencia
a
year
ago
and
I
think
in
particular
Microsoft
is
very
eager
to
hear
your
feedback.
What
is
the
features
that
what
is
the
functionality
of
psyllium?
Is
it
psyllium?
Is
it
hobo?
Is
it
tactical?
A
What
would
you
like
to
see
on
windows,
so
the
the
the
the
eagerness
is
definitely
there,
in
particular
from
the
Microsoft
side.
If
you
are
interested,
feel
free
to
reach
out
to
us.
I
can
make
the
connection
to
the
Microsoft
team
to
have
a
deeper
conversation
on
how
to
extend
the
supported
set
of
functionality
on
Windows
and
then
the
next
question
are
there
plans
for
eye
surveillance
to
develop
a
proxy
for
use
cases
that
ebpf
cannot
manage?
A
A
It
integrates
really
well
with
our
psyllium,
so
really
from
that
perspective,
sodium
whenever
possible,
uses
ebpf
directly
and
then,
if
it
is
not
possible
with
vbpf
yet
then
we
go
back
and
use
the
envoy
proxy,
which
is
typically
a
little
bit
a
little
bit
slower
and
it
can
add
a
bit
more
overhead,
but
you
know
it's
a
good
fallback
option
to
have.
If
we
cannot
do
something
natively
in
ebpf
and
as
we
see
demands
for
particular
use
cases,
we
will
Implement
things
whenever
possible
in
ebpf.
A
good
example
of
this
is
initial.
A
A
This
works
quite
well
for
smaller
set
of
nodes.
So
let's
say
you
have
five
six
clusters
and
only
five
nodes
or
ten
nodes
per
cluster
Relay
can
be
quite
effective
and
you
can
query
in
real
time
literally,
you
can
query
and
you
will
see
flows
in
real
time
as
you
scale
up
and
if
you're
running
hundreds
of
notes
relay
becomes
less
optimal
and
you
want
to
go
towards
Timescape,
with
the
downside
that
there
isn't.
There
is
a
ingestion
delay
of
a
couple
of
seconds.
But,
yes,
you
can
do
one.
A
You
have
two
options
to
do
so
next
question:
can
we
configure
service
mesh
across
clusters
as
of
today,
what
will
be
the
central
plane
as
of
now?
So?
Yes,
you
can
use
service
mesh
across
clusters
right
now,
there
is
cluster
mesh
which
essentially
automates
the
connectivity
across
all
the
Clusters,
which
then
means
you
can
easily
run
service
mesh.
On
top
of
that,
it's
one
of
the
benefits
that
psyllium
already
has
a
multi-cluster
control,
plane
with
identity,
distribution
and
so
on,
and
the
service
mesh
Aztec
can
piggyback
on
that.
A
But
as
far
as
things
like
injecting
load,
balancing
rules
or
policy,
it
is
all
new
to
in
to
inject
that
into
all
of
the
Clusters.
We
have
a
variety
of
automation,
tools
that
we
provide
that
automate
the
injection
into
all
the
Clusters,
but
right
now
we're
not
automatically
propagating
any
sort
of
policies
or
load
balancing
rules
and
so
on.
If
that's
interesting
to
you
have
a
chat
with
us,
we
would
love
to
hear
what
you
want
to
see.
A
It's
definitely
area
that
we
might
be
going
into
next
next
question
elastic
recently
announced
Universal
profiling
using
ebpf.
Do
you
know
how
their
solution
compares
to
psyllium
in
general,
psyllium
and
Hubble
does
not
do
a
whole
bunch
of
profiling.
It's
a
use
case
that
we
have
been
excluding
excluding
quite
a
bit.
Ebpf
is
amazing
at
profiling,
and
you
may
have
seen
things
like
CPU,
flame
graphs
or
memory
heat
map
Graphics,
where
you
can
see
how
much
CPU
is
what
function
of
my
app
using.
A
Where
are
the
memory
allocation,
spikes
and
so
on,
and
that's
all
powered
by
ebpf
and
it's
amazing
there's
lots
of
different
ebpf
based
profiling
projects
like
this
and
elastic
announced
one
more
such
project
psyllium
does
not
psyllium
and
Hubble
do
not
do
any
sort
of
profiling
whatsoever.
There
is
a
whole
bunch
of
observability
and
Telemetry
data
that
you
can
extract,
for
example,
with
tetragon,
but
it's
usually
not
on
the
profiling
side.
It's
usually
more
on
the
Telemetry
in
terms
of
what
is
the
latency?
How
many?
How
many?
A
A
Let
me
check
the
chat
as
well.
Actually
it's
just
one
more
question
that
popped
in
by
dropping
side,
cars
and
having
a
single
proxy
at
the
node
level.
Are
we
losing
isolation
at
the
Pod
level
and
start
having
issues
such
as
noisy
neighbors
or
potential
security
issues?
It's
a
great
question:
there's
a
couple
of
different
layers
that
apply
to
this.
First
of
all,
we
strongly
believe
that
the
layer,
7
processing
to
layers
have
low
balancing
or
HTTP
tracing,
and
so
on
needs
to
be
decoupled
from
the
actual
encryption.
A
Of
course,
the
leak
is
less
because
you
only
manage
the
certificate
of
your
own
service.
If
you
use
a
share
proxy,
the
proxy
will
have
access
to
all
the
certificates
on
that
note,
but
by
separating
the
mgls
proxy
or
mgls
layer
or
the
encryption
layer
from
the
layer
7
proxy,
this
risk
is
mitigated
entirely.
That's
the
first
big
step.
So
that's
why
psyllium
service
mesh
essentially
separates
the
mtls
path
or
the
mtls
encryption
and
to
Kernel
level
encryption
from
the
layer
7
proxy.
This
already
mitigates
the
majority
of
the
security
risk.
A
What
then
remains
is
the
Noisy
Neighbor
and
the
Noisy
Neighbor
problem
exists,
regardless
of
whether
we
have
a
share
proxy
or
we
isolate.
If
we
have
a
sidecar,
yes,
you
can,
let's
say,
dedicate
one
virtual
CPU
per
sidecar,
but
that
doesn't
actually
really
solve
the
problem,
because
you
will
still
still
have
finite
resources
at
the
node
level
just
further
down.
Yes,
your
proxy
may
not
starve
others,
but
the
network
resources
available
in
the
total
CPU
resources
available
will
still
be
the
same.
A
In
fact,
that's
what
Linux
the
Linux
kernel
does
if
you
have
containers
running
all
on
the
same
note,
they
all
share
the
same
Linux
kernel
or
the
same,
the
same,
the
same
operating
system
and
that
actually
brought
a
lot
of
benefits
in
terms
of
Bin,
packing
efficiency
and
so
on,
as
well
as
fair
queuing,
and
we
want
to
bring
that
to
service
mesh
as
well.
I
know
that
was
a
technical,
long
answer.
I
hope
it
made
sense
to
you
happy
to
chat
further
on
this
specific
topic.
A
Of
course,
next
question
are
the
features
discussed,
part
of
Enterprise
version
or
the
free
version.
All
the
features
I
covered
today,
except
for
Timescape,
are
in
the
open
source
version,
both
sodium
and
tetragon.
They
have
in
an
open
source,
which
is
what
you
find
in
the
psyllium
repository
in
the
tetragon
repository
in
open
source
version,
and
they
then
have
an
Enterprise
version
from
I
surveillance.
That's
the
version
we
provide
support
on
right
now.
Timescape
is
the
only
component
where
we
do
not
have
an
open
source
version
for
it.
A
Let
me
check
the
chat
whether
we
have
any.
If
you
have
a
question
that
I
have
not
answered
it,
it
may
be
good
to
ask
it
again:
I
will
go
from
Bottoms,
Up
I,
see
turban
regarding
Network
policies.
Is
it
possible
to
define
guard
rail
network
policies
managed
by
security
team
and
developers
should
not
have
should
not
be
able
to
overall
that?
Yes,
you
can
do
this,
so
you
can
do
so-called
cluster-wide
policies
or
admin
policies,
and
they
are
subject
to
a
two
different
R
back
rules.
A
So
you
can
give
access
to
the
namespace
level
rules
to
your
app
teams,
even
only
for
particular
namespaces
and
your
app
teams
can
Define
them
and
then
you
as
a
security
team,
you
only
have
access
you're.
The
only
entity
was
access
to
the
cluster
while
or
admin
level
policies,
and
they
can
override
they
can
allow
something
that
should
never
be.
That
should
never
be
never
be
denied
and
they
can
also
deny
destination
and
sources
and
no
matter
what
the
application
team
does.
A
We
also
have
in
Hubble
UI,
what's
called
rbac,
so
the
ability
to
expose
the
visibility,
the
dashboards,
the
network
policy
editor
all
of
that
and
only
limit
access
or
limited
access
to
only
certain
namespaces
or
only
parts
of
certain
with
certain
labels.
So
you
can
even
restrict
the
observability
observability
data
to
a
subset
of
resources
in
your
cluster.
If
you
have
multi-tenant
kubernetes
clusters,
when
do
you
expect
cluster
mesh
to
be
out
of
better
I?
Think
that
should
be
out
of
better?
Let
me
check.
A
A
Will
this
video
be
posted
to
YouTube?
Yes,
the
psyllium
already
have
solutions
for
transparent
web
proxy
handling
so
to
force
egos
traffic
transparently
via
folding
proxy.
Yes,
we
can
do
this.
We
have
a
special
feature
in
psyllium
Network
policy,
where
you
can
define
a
network
policy
and
you
can
force
all
the
traffic
through
an
external
proxy,
so
not
only
the
psyllium
Envoy
proxy
but,
for
example,
also
a
cloudflare
proxy.
We
can
even
feed
TCP
traffic
over
an
HTTP
proxy
as
well.
A
You
can
talk
to
us
to
get
more
details
on
this
use
case,
so
definitely
fully
possible.
We
also
have
What's
called
the
egress
Gateway,
where
you
can
force
all
egress
traffic
of
certain
part,
Port
certain
parts
through
a
particular
node.
So
let's
say
you
want
to
run
a
transparent
proxy
squid
or
something
on
that
node.
You
can
force
all
the
egress
traffic
of
your
cluster
through
that
node
and
then
run
DPI
or
squid
proxy
or
whatever
inspection
tool.
You
want
to
run
there.
A
Let
me
see
if
any
more
questions,
what
what
are
the
features
planned
for
the
next
year?
Definitely
a
ton
of
stuff,
including,
of
course,
the
next
iteration
of
service
mesh,
a
lot
of
tetragon
functionality.
That
is
coming,
including
the
the
much
thought
after
Falco
rule
converter,
that
we
are
working
on
and
we
might
have
an
exciting
announcement
for
kubecon
to
do
a
bit
more
networking
outside
of
kubernetes
as
well.
But
I
won't
don't
want
to
spoil
all
the
details.
A
We
will
announce
that
during
cubecon
Amsterdam
in
a
couple
of
weeks,
which
is
check
q,
a
I
see
there
are
three
more
questions.
Are
there
any
use
cases
of
psyllium
which
uses
hppi
ebpf
in
Hardware?
Yes,
you
can
all
the
smartneck
providers
do
offer
ebpf
support
and
they
can
offload
some
functionality
of
psyllium
to
the
smartnic.
The
two
most
common
questions
or
two
most
common
features
that
are
offloadable
are
the
load
balancer,
the
Standalone
load
balancer
and
the
DDOS
protection.
A
The
DDOS
protection
is
the
ability
to
Define
long
lists
of
ips
or
IP
blocks
that
you
do
not
want
to
receive
traffic
from
so
you
can,
for
example,
block
entire
Regional
IP
blocks
to
protect
your
your
your
infrastructure.
So
let's
say
your
under
a
DDOS
attack
and
you
can
isolate
the
set
of
ips
where
the
DDOS
attack
is
coming
from.
A
You
can
black,
you
can
block
them
in
psyllium
and
it
can
enforce
it
can
push
down
these
rules
into
the
smart
Nic
to
essentially
drop
packets
even
more
even
more
effectively,
and
that
way
your
server
servers
will
remain
and
stay
stay
alive
as
long
as
they
have
enough
raw
Network
bandwidth
from
a
wire
from
a
wire
perspective,
then
do
you
have
a
public
roadmap
for
plant
functionality?
Yes,
we
have
a
roadmap,
you
can
go
to
cilium.io
and
click
on
documentation
or
just
go
into
the
cylind
documentation.
A
And
if
you
search
for
roadmap,
you
will
find
the
roadmap
that
kind
of
the
high
level
roadmap.
What
are
we
planning
to
stabilize
next?
What
are
the
bigger
pocket
items
that
are
coming
and,
of
course,
all
the
features
that
we're
working
on
all
the
small
little
bug
fixes
enhancement?
All
of
them
are
tracked
in
GitHub
as
issues
there's
several
hundred
of
them,
where
you
can
see
what
are
we
actually
working
on
and
kind
of
how
these
features
will
look
like
if
you
look
for
the
higher
level
roadmap,
that
is
part
of
the
psyllium
documentation.
A
Great
I
think
I,
hopefully
I
answered
all
the
questions.
If
you
have
more
questions,
feel
free
to
join,
the
psyllium
slack
feel
free
to
reach
out
to
me
on
Twitter
on
slack
wherever
you
can
find
me,
I'm
happy
to
answer
more
questions
or,
if
I
don't
know,
the
answer.
I
will
refer
you
to
the
right
person
again.
I
want
to
thank
everybody
for
attending
today.
I
hope
this
was
useful
and
I
would
love
to
see
many
of
you
as
part
of
the
psyllium
slack
in
the
next
couple
of
days.
Thanks
a
lot,
everybody.