►
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.
Overview and State of Linkerd - Matei David, Buoyant, Inc.
In this talk, maintainers from the Linkerd project will present an overview of the project and an update on upcoming releases. They’ll cover what Linkerd is and how it compares to other service meshes; what the latest features and functionality are; what to expect in upcoming releases; and how you can get involved in one of the CNCF’s most talked-about projects. This talk will cover Linkerd’s recently-introduced policy, circuit breaking, and header-based routing features.
A
All
right,
I
think,
we're
ready
to
get
started
hello
and
welcome
everyone.
Thank
you
for
coming.
I
know
it's
been
kind
of
a
long
week,
so
I
really
appreciate
you
making
it
to
my
presentation.
It's
one
of
the
last
at
cubecon,
so
we're
gonna
make
sure
we
wrap
it
up
with
some
nice
service
meshing
before
we
actually
start.
Can
I
get
a
quick
show
of
hints
for
people
that
have
heard
about
linkerity
before
oh
wow,
all
right,
we're
doing
something
well
and
who
hasn't
ever
used
the
service
mesh
before?
A
Okay,
no
worries
we're
gonna
cover
everything
cool.
So,
let's
get
started,
welcome
to
overview
and
state
of
linker
d.
We
run
one
of
these
presentations
for
every
kubecon,
I'm
going
to
be
going
through.
What
a
service
mesh
is
what
linguity
is
and
where
it
sort
of
fits
into
the
cncf
landscape,
and
then
we're
going
to
talk
about
what
we've
been
doing
and
where
we're
going
next
and
now
what's
planned
for
the
roadmap.
A
So
a
little
bit
about
myself,
my
name
is
matty
david,
I'm
a
linguity
maintainer,
I'm
also
a
software
engineer
at
buoyant
the
creators
of
linkerd.
If
you
want
to
get
in
touch
with
me
after
the
presentation
you
have
all
of
my
handles
there,
I'm
on
twitter
github
and
a
couple
of
slack
workspaces,
not
just
linkedins.
A
A
Things
have
changed
a
little
bit
since
then,
but
I
basically
started
my
contributor
experience
with
with
linkerity
when
I
was
still
a
student.
It's
been
like
two
years
and
a
half
almost
free
now
that
I've
been
coding
and
pushing
features
for
linker
d,
so
I'm
super
excited
to
have
a
chance
to
talk
about
it
with
you
all.
A
Maybe
you
know,
maybe
you
don't.
There
are
a
couple
of
people
that
don't
know
anything
about
service
meshes,
but
linker
d
is
cncs.
First
graduated
service
mesh.
So
that's
a
huge
milestone
for
us.
We've
been
running
in
productions
for
more
than
five
years
now
the
slides
are
a
bit
old,
so
it's
four
plus
years
still
accurate.
A
We
have
a
bunch
of
slack
channel
members.
We
have
a
very
thriving
community
both
on
github
and
on
slack
we're
committed
to
open
governance,
and
we
have
been
adopted
in
production
by
a
bunch
of
cool
companies
ranging
from
enterprises
all
the
way
down
to
startups.
So,
no
matter
how
big
or
small
your
company
is,
how
much
traffic
you
have
linker
d
is
definitely
a
good
fit
and
we're
going
to
see
why
let's
talk
a
bit
about
service
meshes
and
what
linguidi
is
supposed
to
be
doing
so
service
meshes.
A
I
think
in
the
cncf
landscape
have
become
a
bit
of
a
buzzword
and
have
become
a
bit
complicated,
so
they
have
this
sort
of
history
that
predates
them.
I
guess,
and
that
makes
them
seem
very
confusing,
so
people
try
and
stay
away
from
them,
but
service
meshes
are
are
pretty
simple,
they're,
just
platform
level
tools
that
give
you
reliability,
observability
and
security
out
of
the
box.
So
it's
nothing
complicated
about
that.
We
basically
do
this
by
injecting
a
bunch
of
proxies
running
a
sidecar
containers,
next,
three
applications.
A
So
what
linker
does
is
it
injects
a
proxy
next
to
your
application?
It
receives
your
traffic,
it
proxies
it
over
to
its
target
and
in
the
process
it
achieves
mtls,
so
security,
it
pulls
metrics
from
that.
So
you
have
observability
and
it
provides
a
bunch
of
useful
features
such
as
retries
and
timeouts.
To
achieve
reliability,
it's
not
very
complicated.
So
that's
precisely
why,
in
the
link
rd
team,
we
like
to
preach
about
simplicity,
service
meshes
can
be
simple
if
done
right
and
that's
exactly
what
we're
trying
to
do.
A
Linkerity
just
works
and
that's
why
we
have,
as
you
can
see
on
the
slide,
the
moto
less
is
more
and
more
is
less.
We
have
this
strict
philosophy
and
we're
kind
of
very
opinionated
when
it
comes
to
it
that
when
you
have
a
platform
level
tool,
it
should
just
work.
You
shouldn't
be
concerned
with
learning
how
a
tool
works
and
you
shouldn't
have
to
operate
it
too
much
on
a
daily
basis.
What
we
want
you
to
do
is
to
install
linkrd
and
just
run
it.
A
A
So
with
linkerd.
We
wanted
to
make
sure
that
with
zero
config,
everything
is
possible
out
of
the
box
for
any
kubernetes
app
we're
also
ultra
lite.
We
wanted
to
introduce
the
bare
minimum
overhead
and
that's
very
important
when
you
have
a
platform
level
tool,
especially
one
that
proxy
traffic,
we
want
it
to
be
simple.
Like
I
previously
said,
and
we
wanted
to
make
security
a
basic
feature,
we
didn't
want
it
to
to
be
an
option.
We
wanted
to
make
it
the
default
for
the
data
plane,
link,
rd
uses
rust.
A
I'm
not
sure
many
of
you
are
familiar
with
rust.
Can
I
get
another
quick
show
of
hands
yeah
all
right,
we're
doing
well
there.
So
rust
is
a
programming
language.
That's
been
sort
of
getting
more
momentum
as
of
late,
but
its
main
value
proposition
is
that
you
get
zero
cost
abstractions
and
that's
that
is
very
performant.
A
You
can
basically
compile
it
to
native
code,
so
it's
very
portable.
You
can
run
it
on
on
any
architecture
that
you
want
and
it
makes
sure
that
it
has
a
strong
type
system
so
that
most
of
the
years
are
caught
at
compile
time
and
that's
very
important
for
us
because,
again
as
a
platform
level
tool,
we
don't
want
to
bring
down
your
prod
deployment
on
a
friday
right,
your
production
environment,
sorry
on
a
friday,
because
that
would
be
pretty
bad.
A
It
will
reflect
poorly
on
on
us
and
on
you
for
choosing
linguity
rust,
like
I
said,
compiles
to
native
code,
and
that
makes
it
ultra
light
and
ultra
fast
and
it
lets
you
avoid
an
entire
class
of
memory
vulnerabilities
through
its
borrowed
checker,
so
rust
basically
makes
sure
that
you
cannot
commit
any
bad
memory.
Faults
such
as
double
freeze
or
you
know,
messing
around
with
pointers
and,
if
you've
coded
in
c
or
c,
plus,
plus
that
probably
happened
to
you
at
some
point.
It
doesn't
even
have
to
be
something
that
you
don't
know.
A
We
are
also
built
on
a
state-of-the-art
network
stack,
so
there
are
a
couple
of
libraries
in
the
rust
ecosystem
that
have
gained
a
lot
of
traction
and
that
are
used
in
production
systems,
so
one
of
them
is
tokyo,
which
is
an
asynchronous
runtime,
and
the
linker
d,
maintainers
and
linkerity
contributors
have
contributed
extensively
to
tokyo.
One
of
the
core
maintainers
was
actually
at
buoyant.
Developing
the
linguity
proxy
we're
built
on
top
of
tower
were
bent
on
top
of
hyper
and
h2.
A
A
Our
philosophy,
when
it
comes
to
the
proxy
is
that
it
should
be
simple
to
implement
sorry
that
it
should
be
simple
to
use
and
it
should
be
an
implementation
detail.
It
should
be
sort
of
opaque
to
everything
that
you're
doing
in
your
kubernetes
environment.
You
shouldn't
have
to
be
a
proxy
expert
to
operate
linkedin
our
approach
to
security.
So
that's
another
one
of
our
core
ideologies.
First,
keep
it
simple!
Second,
keep
it
secure.
Our
approach
to
security
is
very
focused
and
follows
this
strict
philosophy.
A
We
want
to
secure
the
foundations,
so
you
know
we're
we're
using
rust
for
the
linker
d2
proxy,
so
we
don't
get
any
cvs
or
or
memory
vulnerabilities,
we're
built
on
top
of
kubernetes
actually
and
blinker
d
as
a
whole,
we're
leveraging
almost
entirely
kubernetes
primitives
and
in
this
case,
for
security,
we
use
service
accounts
for
pod
identity
and
we
want
to
remove
any
barriers
that
you
would
have
as
an
operator.
So
that's
why
we
have
mtls
is
on
by
default
and
as
of
recent
versions,
you
can't
actually
disable
mtls.
A
How
does
linguidi
compare
to
istio
and
it's
a
bit
of
a
hard
question,
because
it
really
depends
on
your
production
environment
and
it
depends
on
what
you
want
to
do.
Istio
is
built
for
feature
parity,
they
add
a
bunch
of
features.
You
can
do
a
lot
of
cool
stuff,
but
that
comes
at
a
cost.
It
comes
at
a
cost
of
complexity.
You
have
a
bunch
of
crds
to
manage.
A
You
have
a
bunch
of
things
to
learn,
and
this
is
very
hard
when
you
have
limited
time
to
learn
a
tool
and
to
adopt
a
tool.
On
the
other
hand,
link
rd
uses
the
bare
minimum
to
build
a
secure
and
reliable
kubernetes
platform.
So,
like
I
mentioned,
we
leverage
almost
entirely
kubernetes
primitives,
so,
for
example,
for
all
of
our
network
communications
we're
using
endpoints
we're
using
services,
we
don't
add
anything
new
to
the
whole
stack,
so
that
makes
us
much
easier
to
use,
but
it
also
makes
us
smaller,
lighter
and
faster.
A
That's
because
linker
d
is
built.
Purposely
the
linguity
proxy
is
built
purposely
for
linkerid
and
when
we
think
about
features,
yes,
we
do
miss
out
on
feature
parity,
but
every
feature
that
we
add
is
carefully
thought
out.
That's
something
that
we
want
to
do
for
our
adopters.
We
want
to
provide
a
stable
platform.
We
don't
want
to
introduce
any
breaking
changes.
We
don't
want
to
surprise
you.
A
We
want
you
to
know
that
the
tool
is
going
to
work
for
a
very
long
time
and
it's
going
to
have
backwards
compatibility,
and
we
do
that
by
carefully
thinking
through
the
road
map
and
thinking
through
of
what
people
need
chances
are.
If
you
have
a
problem,
we
can
definitely
fix
it,
but
if
we
can
fix
it
without
adding
more
overhead,
more
complexity
and
more
features,
we're
probably
going
to
do
that
as
well.
A
That
kind
of
covers
the
first
part
of
the
presentation.
You
know
the
introduction
to
linkedin
service
meshes.
If
you
didn't
really
understand
everything.
You'll
have
some
time
to
answer
questions
to
ask
questions
at
the
end,
but
now
I
want
to
talk
a
little
bit
about
linker
d's
years
so
far.
So
since
the
last
time
I
I
had
this
presentation
for
kubecon
eu
2021,
a
bunch
of
things
have
changed
shortly
before
last
year.
Before
kubecon.
Last
year
we
introduced
d
2.9
mtls
for
all
so
prior
to
this,
linkedin
only
did
mtls
for
layer
7
protocols.
A
We
did
an
mdls
for
http
grpc
and
that
was
kind
of
it,
but
we
wanted
to
introduce
mtls
for
tcp
out
of
the
box
with
no
configuration,
and
we
managed
to
do
that.
We've
also
added
arm
support,
we're
the
only
service
mesh.
As
far
as
I
know,
please
feel
free
to
collect
to
correct
me
that
compiles
to
arm
architecture.
So
if
you
have
a
home
lab,
if
you
have
arm
instances,
you
can
run
the
kerdi
on
it.
We
introduced
a
multi-multi-core
proxy
runtime,
so
we
can
add
more
throughput
and
concurrency.
A
What
if
we
just
remove
prometheus,
and
we
make
everything
optional
to
begin
with?
What?
If,
instead
of
adding
all
of
this
stuff
that
you
might
not
need,
you
can
just
have
a
default
control
plane,
that's
the
bare
minimum,
it
doesn't
introduce
an
overhead
and
then
you
can
start
composing
as
much
as
you
want.
So
this
idea
of
having
composed
sort
of
components
and
adding
composition
also
comes
in
the
proxy,
where
we
were
inspired
by
the
finago
library.
A
I
don't
know
if
any
of
you
had
any
experience
with
it
and
sort
of
follows
a
similar
pattern
of
building
middlewares
to
proxy
traffic.
So
this
is
what
we
did
for
linkrd
2.10.
We
split
everything
out
into
extension,
so
we
have
a
vise
extension,
which
is
the
metric
stack.
You
have
prometheus
grafana
metrics
api
and
the
linkrd
dashboard.
If
you
want
to
run
with
it,
you
can,
if
you
don't,
you
don't
have
to.
A
Extensions
can
also
come
from
third
parties,
so
we
wanted
to
give
adopters
the
chance
to
run
their
own
extensions
and
integrate
with
the
cli
and
the
check
system
that
we
have
so
right
now,
for
example,
in
my
spare
time,
I'm
writing
a
linguity
extension
to
take
care
of
job
objects
if
you've
used
the
sidecar
pattern
with
job
objects.
You'll
know
that
it's
a
bit
hard
to
deal
with,
so
I
wanted
to
solve
that
problem
for
the
community
in
my
spare
time,
and
I
can
just
do
it
in
an
extension.
A
Besides
all
of
this
extension
stuff,
of
course,
we
added
more
stuff,
such
as
opaque
ports
to
proc
to
proxy
without
protocol
detection,
and
we
extended
multi-cluster
to
old,
tcp
connection
and
lots
more,
of
course,
that
I
didn't
really
remember
to
put
on
the
slide
today.
We
we
have
linkerd
2.11,
so
we
released
linkedin
2.11,
I
think
in
autumn,
and
what
we
focused
on
was
policy
so
for
linkery
to
truly
be
a
security
conscious
service
mesh
and
to
offer
as
much
security
as
we
can.
A
We
wanted
to
make
sure
that
we
can
extend
zero
trust,
your
kubernetes
platform,
but
we
cannot
have
zero
trust
without
having
authorization
policies.
So
that's
why
in
2011
we
focused
on
server
side
policies.
We
wanted
to
have
a
fine
grain
access
control
system
that
you
can
use
in
a
composable
way
again
or
big
fans
of
composition
that
works
with
linguity,
secure
identities
and
also
that
works
at
a
network
range.
So
right
now,
with
authorization
policies,
you
can
describe
basically
a
resource
on
your
server.
A
That
will
allow
you
to
accept
traffic
from
specific
lines,
and
this
is
all
based
on
identity
or
based
on
network
ranges.
If
you
don't
want
certain
subnets
to
connect
your
server,
you
can
just
deny
them.
We
also
added
some
more
stuff.
We
added
grpc
retries.
So
this
is
more
http
requests
with
bodies.
If
you
have
an
http
post
request,
that
has
a
body
and
you
want
to
retry
it.
A
I
don't
know
if
any
of
you
have
tried
to
implement
this,
but
it
turns
out
to
be
a
pretty
complex
problem,
especially
if
you
want
to
keep
the
overhead
minimal.
What
do
you
do
a
lot
of
the
bytes?
Do
you
keep
them
in
memory?
Do
you
buffer
them?
It's
pretty
hard,
if
you
think
about
it,
especially
when
you
have
tens
of
thousands
of
connections
running,
but
we
managed
to
do
it
so
we
released
grpc
retries,
that's
what
we
call
it
and
we
also
managed
in
the
process
to
reduce
the
proxy
footprint
even
more
so.
A
The
control
plane,
for
example,
is
also
down
to
three
deployments
from
four.
I
think
before
we
also
expanded
a
bit
more
on
multi-cluster,
we
and
the
community
had
some
requests
to
extend
stateless
stateful
sets
and
multi-cluster
and
be
able
to
mirror
them,
but
this
is
kind
of
a
hard
problem
to
do
and
we
solved
it
by
the
introduction
of
multi-cluster
headless
support.
We
also
added
fuss
testing
some
cli
tab,
completions
to
make
the
quality
of
life
a
bit
better
for
contributors
and
a
few
other
goodies.
A
A
A
The
link
rd
proxy
then
talks
to
a
couple
of
components
that
from
the
control
plane
we
have
a
destination
service
and
the
destination
service
is
used
to
serve
service
discovery.
You
have
a
target,
you
have
an
ip.
What
do
we
know
about
this
ip?
Can
we
find
out
more?
So
this
is
where
we
collect
all
of
the
metadata,
where
we
do
all
of
the
current
client-side
policies
that
we
have
in
place,
such
as
retries
and
timeouts,
and
where
we
scope
the
target
out
and
build
a
load
balancer.
A
Next
we
have
the
policy
controller,
and
this
is
something
that
we've
introduced
in
lingerie
2.11
and
the
policy
controller
is
pretty
much
like
the
service
discovery
mechanism,
but
for
policy,
and
finally,
we
have
the
identity
component.
The
identity
component
is
super
crucial
for
us
because
it
allows
the
linguistic
proxies
to
acquire
a
certificate
as
soon
as
they
start
and
a
certificate
is
refreshed
every
24
hours.
A
However,
you
can
make
linker
d
as
robust
and
as
powerful
as
you
want
for
the
extensions,
so
I
would
have
added
a
few
more
extensions,
but
I
sort
of
ran
out
of
space
here,
but
I
wanted
to
exemplify
the
two
most
used
extensions.
I
think
that
we
have
the
viz
extension
introduces
a
prometheus
instance
a
grafana
instance
and
the
web
dashboard
prometheus
is
going
to
scrape
all
the
all
of
the
linguity
proxies
the
proxies
themselves
proxy
the
traffic
and
collect
all
of
the
metrics,
and
then
we
have
automatic
scrapes.
A
Well,
we
have
scrapes
that
ship
with
a
the
control
plane
and
the
viz
extension
and
prometheus
will
use
it
to
take
all
of
the
metrics
out.
We
also
have
a
tab
component
and
I'm
not
sure
if
any
of
you
have
used
app
when
you
tried
out
linker
d,
but
it's
a
really
nice
tool.
It
lets
you
basically
have
a
bunch
of
streaming
lines
from
the
proxy
that
show
you
how
their
connections
are
are
being
handled.
A
And
finally,
we
have
the
tap
injector,
which
is
kind
of
like
the
proxy
injector,
but
for
tap
it's
pretty
self-explanatory.
Next,
up
with
the
multi-cluster
extension,
we
have
only
two
components
and
that's
a
multi-cluster
gateway.
That's
used
to
proxy
traffic
across
clusters
and
we
have
the
service
mirror
that's
going
to
mirror
all
of
the
services
into
your
own
cluster
linkard's
approach
to
multi-cluster
is
actually
a
little
bit
unique.
We're
not
doing
what
most
other
projects
are
doing
out
there
and
we
wanted
to
design
it
in
a
way
more
simpler
way.
A
I
can
expand
on
that
a
little
bit
later.
If
anyone
has
any
follow-up
questions
we're
finally
getting
to
to
my
favorite
slide.
What's
next
for
linguity,
but
before
I
sort
of
get
into
it,
I
want
to
first
tell
you
about
the
linguity
release
process
that
we
have
so
linkerid
currently
has
two
types
of
releases.
A
We
have
weekly
edge
releases,
and
this
is
usually
where
most
of
our
functionality
and
the
code
that
we
push
on
a
weekly
basis
makes
its
way
into,
and
then
we
have
stable
releases
once
we
have
kind
of
completed
all
of
the
milestone
of
a
stable
release
of
a
stable
release,
yeah
and
in
weekly
edge
releases
we're
going
to
create
a
release
candidate.
That's
going
to
turn
into
the
actual,
stable
release
so
without
edge
releases.
A
What
we
really
try
is
to
have
new
features,
the
you
know,
kind
of
innovate
as
fast
as
we
can
and
get
the
community
input,
and
while
I'm
mentioning
all
of
this
is
because,
while
I
have
here
the
road
map
for
the
stable
release,
I
want
to
talk
a
little
bit
about
what
we've
been
doing
since
2.11
came
out.
So
since
2.11
came
out,
we
released
two
more
stable
versions,
2.11.1
and
2.11.2,
and
these
are
focused
on
back
porting.
Some
of
the
issues
that
we
fixed
throughout
the
year
in
edge
releases.
A
Also,
we
we
shipped
an
apache
style
logging
for
the
proxy,
so
you
can
have
nginx
like
access
logs,
which
is
very
useful
and
it
was
kind
of
requested
by
the
community
we're
also
working
on
having
a
log
streaming
endpoint
for
the
proxy.
So
I
I
don't
know
if
any
of
you
have
had
the
opportunity
to
debug
the
proxy,
but
sometimes
you
have
to
change
the
log
level.
You
have
to
get
the
logs
from
your
kubernetes
pod
and
we
wanted
to
make
that
a
little
bit
simpler.
A
So
we
exposed
an
endpoint
to
stream
all
of
the
logs.
You
can
put
them
into
an
aggregator.
You
can
look
at
them
in
real
time
and
do
whatever
you
want
and
we've
also
started
improving
the
cni
plug-in.
So
I
know
that
the
community
had
some
issues
with
the
cni
plug-in
and
we
were
super
quick
to
fix
that
and
we
already
started
working
on
it
other
than
that.
A
I
think
we've
mostly
had
a
bunch
of
fixes
and
a
bunch
of
quality
of
life
improvements
that
the
community
was
super
vocal
about
and,
very
importantly,
we
released
a
failover
controller
for
multi-cluster.
We
wanted
to
have
a
way
for
multi-cluster
communications
to
have
like
an
active,
passive
sort
of
scenario
and
have
a
way
to
fail
over
and
increase
the
reliability
that
linkedi
brings.
So
all
of
this
has
been
happening
behind
the
scenes
and
it
releases.
A
A
However,
we
wanted
to
stabilize
in
a
different
pattern,
so
we
sort
of
took
a
hint
from
the
gateway
api
community
and
we
started
doing
what's
known
as
policy
attachment,
so
policy
attachment
kind
of
allows
us
to
target
specific
objects
and
extend
the
api
as
much
as
we
want
without
introducing
new
types.
It's
super
robust,
we're
super
excited
about
it,
but
what
it'll
let
us
do
is
to
cover
grpc
and
http
verbs
and
rounds
when
it
comes
to
server
authorizations.
A
So
we're
going
to
have
a
much
more
fleshed
out
route
system.
That's
going
to
work
out
way
nicely
way
more
nicely
with
with
the
current
authorization
system
when
it
comes
to
cni.
I
briefly
sort
of
mentioned
that
we
started
doing
some
fixes
there.
We
received
some
reports
that
the
cni
plug-in
could
handle
different
chaining
chaining
scenarios
a
little
bit
better,
so
we're
working
on
providing
better
integration
and
better
tooling,
so
linker
d
can
work
better
with
other
ci
plugins.
A
Finally,
on
the
roadmap
for
2.13,
we're
super
excited
to
bring
client
policies,
so
we've
done
server
policies.
You
can
now
have
zero
trust
in
your
cluster,
but
that's
not
enough.
A
lot
of
people
want
jwt,
authentication
and
authorization.
A
lot
of
people
want
circuit.
Breaking
a
lot
of
people
want
header-based
routing
they
want
egress
control.
A
All
of
this
stuff
will
come
with
client-side
policies
once
these
are
fleshed
out.
All
of
the
other
systems
will
be
much
easier
to
implement
and
much
easier
to
extend.
Also,
we
we
heard
that
people
want
spiffy
support.
So
that's
something
that's
on
our
roadmap
when
it
comes
to
integration,
and
also
I
mentioned
at
the
start,
there
was
an
asterisk
with
linkery,
not
working
outside,
of
kubernetes
we're
planning
on
doing
mesh
expansion.
A
So
this
is
sort
of
what
the
roadmap
looks
like
we're
super
excited
to
be
working
on
all
of
this
stuff.
2.12
is
planned
for
obviously
this
year
and
2014
will
follow
shortly
after
if
you
haven't
had
a
chance
to
look
into
a
link
ready
match
at
the
conference.
I
know
this
is
already
a
bit
late
because
it's
friday,
the
conference
is
about
to
end,
but
I
wanted
you
to
be
aware
in
case
you
wanted
to
watch
some
of
the
recordings,
so
we've
done
a
couple
of
deep
dives
into
how
protocol
detection
works
in
linguity.
A
We've
also
done
a
little
lightning
talk
on
logging
and
debugging
failures
with
linkedin
telepresence,
and
also
we
had
a
couple
of
really
cool
case
studies
made
by
linkery
adopters.
So,
for
example,
if
any
of
you
have
managed
to
to
catch
the
xbox
cloud
gaming
presentation,
they
they
basically
talk
on
how
linkery
helped
them
secure
22k
pods
without
a
lot
of
effort
and
stress.
A
Now
we
also
want
to
talk
a
little
bit
about
the
community,
so
linker
d
is
is
proud
to
have
a
very
active
community.
We
have
a
very
thriving
slack
community
where
people
tend
to
help
each
other
out.
So
I
encourage
all
of
you
to
join.
Chances
are
if
you've
joined.
You've
probably
met
me
already.
So
if
that's
the
case
hi
nice
to
meet
you
again
in
person,
all
of
our
development
is
done
on
github.
A
So
if
you
have
any
questions,
if
you
have
any
concerns,
you
can
always
reach
us
on
github,
that's
also
where
we
track
our
milestones
for
releases.
So
this
is
very
important
because
a
question
that
we
often
get
about
the
project
is
oh:
when
will
2.12
be
out
and
the
short
answer
is
well
when
all
of
the
milestones
will
be
completed
and
the
best
way
to
track
this
is
by
going
on
github
and
looking
at
the
issues.
A
Finally,
we
have
third
party
security,
audits
and
benchmarks
that
have
been
done.
I
can
forward
some
links
or
you
can
google
them
they're
pretty
easy
to
come
by,
and
there
are
two
more
things
that
I
wanted
to
mention.
We
have
a
linkard
hero
program,
so
if
you're
thinking
about
contributing
this
is
super
important,
the
linker
d
hero
program
is
our
way
of
celebrating
our
our
contributors,
because
we
really
appreciate
the
work
that
you're
doing.
I
myself
started
as
a
contributor,
so
I'm
very
fond
of
the
program.
A
If
you
want
to
be
a
linguity
hero,
I
I
really
encourage
you
to
to
join
up
and
and
put
a
pr
in,
and
then
we
also
have
a
link
or
the
anchor
program.
The
linkery
anchor
program
is:
is
there
to
help
people
develop
their
their
writing
and
their
presentation
skills
by
sharing
their
linkery
journey
and
without
being
said,
I
also
wanted
to
say
that
the
linguity
team
is
looking
to
grow.
A
B
A
B
A
That
is
a
very
good
question,
so
our
personal
recommendation
is
to
always
upgrade
one
version
at
a
time.
So,
for
example,
if
you're
running
linker
d
2.8,
we
wouldn't
really
recommend
that
you
go
straight
to
2.11..
We
recommend
that
you
take
it
incremental
with
that
being
said,
we
always
have
to
guarantee
that
at
least
one
version.
We
are
not
going
to
pretty
much
implement
any
breaking
changes.
A
As
a
matter
of
fact,
I
don't
think
we've
had
any
major
breaking
changes
up
until
this
point,
maybe
once
or
twice
when
we
change
some
trd
definitions
which
again
drives
home
the
point
that
too
many
crds
and
too
much
configuration
is
bad
for
your
system,
but
yeah
when
it
comes
to
upgrading.
We
generally
recommend
that
you
upgrade
one
version
at
a
time,
because
it's
very
unlikely
that
you'll
have
any
braking
changes.
A
C
A
If
you
run
linkery
in
mode,
which
is
what
we
recommend,
people
do
in
production
systems,
they're
not
going
to
have
any
downtime
with
linkedin
at
all
you're,
also
not
going
to
have
any
down
time
with
your
services,
because
once
they
acquire
their
their
target
through
service
discovery,
the
connections
are
going
to
be
open
for
a
very
long
time.
So,
assuming
the
upgrade
process
is
is
a
success
and
in
most
cases
it
is
you're
not
going
to
experience
any
downtime.
As
long
as
you
run
in
aj
mode.
A
Yeah,
that's
that's
a
very
good
question,
so
linkery
actually
integrates
very
well
with
flux
and
argo
cd.
We
have
a
bunch
of
guides
on
how
to
do
that.
We're
we're
fans
of
get
ops
and
we
understand
that
deployment
strategies
can
be
a
bit
complicated,
especially
when
you
manage
a
big
platform
off
the
top
of
my
head.
I
don't
have
any
specific
advice
to
give,
but
we
do
have
guides
that
are
meant
to
help
help
guide
you
for
the
github's
get
up
sort
of
workflow,
but
when
it
comes
to
proxy
injection.
A
One
of
the
things
that
I
do
want
to
mention
is
that
it's
relatively
simple,
all
you
have
to
do
is
put
an
annotation
on
your
workloads,
so
if
you're
using
a
deployment
that
the
annotation
would
go
on
the
pod
template
and
that's
responsible
for
actually
telling
the
control
plane
to
inject
the
sidecar
proxy,
so
there
isn't
really
a
lot
of
configuration
that
you
have
to
do
and
there's
nothing
that
would
kind
of
set
your
set.
Your
git
ops
flow
apart,
if
that
makes
sense,
cool
thanks,
yeah,
no
problem,
good
question.
E
E
So
in
single
in
single
control,
plane
mode,
you
actually
can
upgrade
the
control
plane
without
having
a
loss
or
without
having
downtime
of
your
application
as
long
as
you're
not
launching
new
pods
during
that
process,
because
if
you
launch
a
new
pod,
the
proxy
injector
won't
be
able
to
add
the
proxy
you
it's
so
you
can
do
it
and
if
you
have
control
over
the
cluster,
it's
probably
fine
mode.
Of
course,
I
would
recommend
for
production
for,
like
a
variety
of
reasons,
once
you've
upgraded
the
control
plane.
E
The
data
plane
can
typically
remain
at
the
previous
version.
So
we'll
do
you
know
we'll
allow
one
version,
one
major
version
of
data
plane,
control,
plane,
compatibility
and
then
you
can.
You
can
decide
then
to
like
upgrade
the
data
plane
yourself
immediately
or
you
can
be
lazy
about
it
and
just
let
it
happen.
Naturally,
as
soon
as
you
start
getting
divergence
between
control,
plane
data
plane
of
more
than
one
major
version,
no
guarantees,
so
you
kind
of
have
to
keep
an
eye
on
on
the
version
mismatch.
If
you
do
that.
C
A
C
D
Thanks
very
useful,
I
heard
someone
saying
earlier
today
that
using
ebpf
or
like
as
a
service
mesh
has
the
potential
to
be
faster
than
a
sidecar
proxy.
I
don't
know
I
don't
sound
like
an
aggressive
question
or
something
like
I
was
curious
like
if
you
have
any
thoughts
on
that.
If
it's
easy
to,
I
don't
know,
support
that
as
well.
Maybe
you
disagree
or
I
don't
know.
I
just
want
to
learn.
A
It's
a
very
good
question
and
I'm
going
to
tackle
it
into
two
separate
answers.
So,
first
of
all
the
ebpf
mode
of
running
a
service
mesh
when
you
run
on
a
per
host
deployment,
sort
of
a
demon
set,
that's
what
we've
tried
with
linker
d1.
So
our
first
approach
with
linker
d1
was
to
have
a
daemon
set
that
runs
on
a
host
and
it
was
very
hard
for
us
to
scale
down.
So
that
was
one
of
the
first
points
that
I've
noticed.
A
A
So
when
we
run
as
a
sidecar
container,
we
run
next
to
the
container,
and
that
gives
us
good
isolation
between
the
processes.
When
you
run
on
the
host,
that's
not
entirely
possible.
So
that's
something
to
keep
in
mind
and
finally,
one
of
the
reasons
why
we
wanted
to
run
the
sidecar
container
and
why
we
why
we
went
with
it
for
linker
d2
is
that
it
allowed
us
to
scope,
identity
to
the
lowest
sort
of
unit
of
work
in
the
cluster
and
that's
the
pod.
A
The
the
only
way
to
really
achieve
zero
trust
in
kubernetes
is
to
tie
identity
to
the
lowest
unit
of
work,
and
I
think
that
would
be
much
more
difficult
to
do
when
you
run
per
host.
So
the
kind
of
tldr
here
is
that
we
we
tried
it
before
it
didn't
really
work
out
and
we
stuck
with
the
sidecar
container
for
good
reasons.
It
allows
us
to
scale
better.
It
allows
us
to
achieve
a
better
separation
and
it
allows
us
to
do
zero
trust.
A
But
the
kernel
modules
for
ebpf
haven't
really
been
contributed
or
developed
enough
for
us
to
use
it
as
a
backend
for
iptables
we're
going
to
look
into
it
when
when
the
time
will
come
and
when
it
will
be
present
as
a
module
in
the
kernel,
but
until
then
we're
we're
going
to
stick
with
the
ip
tables
implementation
and
when
it
comes
to
it.
Another
thing
is
that
you
know
when
you
run
in
kernel
space,
you're
sort
of
inviting
trouble.
So
that's
also
something
to
keep
in
mind.
Good
question,
though,.
E
Sorry
mate,
I
have
another
reverse
question
about
ebpf,
which
is
yeah
like
matteo,
said:
there's
kind
of
two
components:
there's
like
ebpf,
you
know
what
can
I?
What
can
I
do
at
layer?
Four
to
like
speed
up?
You
know
how
the
kernel
is
processing
stuff
and
you
kind
of
get
that
with
psyllium.
You
know
as
a
cni
layer
and
that
works
fine
for
the
most
part,
with
linker
d.
E
There's
also
the
idea
of
the
ebpf
service
mesh
and
what
happens
there
is
they
have
evpf
in
the
kernel,
but
they
also
have
a
single
envoy
proxy
per
host.
You
know
that's
a
multi-tenant
that
all
traffic
goes
through
and
that's
what
I
really
don't
like
about
that
model,
because
operationally
you're
in
you
puts
you
in
a
very
difficult
spot.
You've
got
one
point
of
failure
for
pods
on
the
node.
You've
got
one
place
where
if
something
goes
wrong,
a
random
selection
of
pods
from
your
services
start
going
around.
E
That
was
what
we
saw
with
with
linkardi
one.x.
Is
that
any
kind
of
like
operational,
you
know
task
you
had
to
do
on
a
per
node
basis,
when
the
rest
of
your
architecture
set
up
like
service
level
gets
very,
very
difficult
and
envoy
is
also.
I've
got
a
lot
of
opinions
about
envoy,
but
one
it's
not
it's
not
designed
for
this
kind
of
contested
multi-tenancy
right,
it's
just
not
it's
not
and
designing
it
designing
any
software
for
contested
multi-tenancy
is
really
really
hard.
E
It
would
be
possible
to
rewrite
envoy
to
do
that,
but
it
would
be
very
non-trivial
and
it
would
be.
You
know.
I
almost
don't
know
what
the
point
would
be,
since
we
already
have
this
very
nice
model.
You
know
involving
containers
and
isolation,
voc
groups
and
stuff
like
that,
so
you
should
try
it.
You
know.
I
welcome
you
to
try
it,
but
I
don't
think
it's
the
right
model
and
I
I
think
side
cars
are
actually
really
nice.
If
anyone
was
that
service
meshcon,
I
was
on
a
you
know.
E
I
talked
about
this
a
little
bit
at
the
panel
at
the
end,
I
think
sidecars
are
actually
a
really
really
nice
model.
If
you
can
make
the
side
cars
fast,
if
you
can
make
them
small,
you
have
really
nice
operational
semantics.
You
have
really
nice
security
semantics
and
there
are
problems
with
side,
cars
and
there's
stuff.
We
can
do
to
improve
them
in
kubernetes.
Certainly
when
you
get
into
like
pod
container
ordering
and
stuff
like
that,
it
has
an
operational
model
as
a
security
model,
they're
really
really
nice,
so
we're
gonna
stick
with
it.