►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. 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 - William Morgan & Tarun Pothulapati, 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 include Linkerd's new seamless multi-cluster and TCP mutual TLS (mtls) features in the 2.8 and 2.9 releases, as well as performance benchmarks and recent changes in Linkerd's underlying micro-proxy, Linkerd2-proxy.
https://sched.co/ekIN
A
Hi
there,
my
name
is
william
morgan
and
I'm
one
of
the
creators
of
linker
d.
This
is
the
introduction
to
linker
d
and
state
of
the
project.
Talk
at
kubecon
na
2020
virtual
I'm
going
to
be
joined
by
my
fellow
lingerie
person,
tarun
potholopathy
he's
going
to
tell
you
about
the
linker
d2.8
release
the
very
fresh
linkerity
2.9
release
and
our
plans
for
2.10
and
beyond
by
the
way
tarun
started
his
lingerie
journey
as
a
google
summer
of
code
student,
and
now
he
holds
the
illustrious
title
of
linker
d
maintainer.
A
So
hopefully
he'll
tell
you
a
little
bit
about
that,
but
before
that,
I'm
going
to
give
you
an
introduction
to
linker
d
what
it
is,
what
it
isn't
and
then
I'll
hand
it
over
to
tyrone.
So
here
we
are
what
is
linker
d
linker
d?
Is
a
service
mesh?
Hopefully
that's
a
term
that
you
have
heard
before,
but
it's
okay,
if
you
haven't,
because
I'm
going
to
tell
you
what
that
means.
A
A
All
sorts
of
fancy
logos
up
here
too.
Two
logos
up
here
that
are
not
up
here.
That
probably
should
be
because
we
have
two
very
exciting
end
user
talks
at
this
very
conference.
One
is
a
keynote
by
dave,
sudia
of
go
spot
check
where
he
talks
about
how
he
uses
linker
d
and
other
cncf
projects
to
build
a
developer
platform
at
ghost
box
tech
so
definitely
go.
Watch
that
talk
and
then
another
exciting
talk
from
justin
turner
and
garrett
griffin
at
heb.
A
Talking
about
how
they
rolled
lingerie
out
to
production
in
order
to
accelerate
the
delivery
of
their
curbside
check
out
heb
as
a
grocery
store
in
response
to
the
covid19
pandemic.
So
linker
d
is
not
just
a
cool
project;
it
can
actually
help
people,
you
know
get
their
groceries
as
part
of
the
pandemic,
so
that
is
really
exciting
for
us
be
sure
to
take
out
those
check
out
those
two
talks.
A
So
let's
get
back
to
linkedin.
What
does
linkerd
do
so
as
a
service
mesh
we
bucket
these
features
into
kind
of
three
categories.
Linguity
gives
you
a
bunch
of
observability
features,
a
bunch
of
reliability,
features
and
a
bunch
of
security
features
and
there's
some
nice
screenshots
here
of
the
cool
dashboards
that
we
have
as
well
and
what's
interesting
about
the
service
mesh
in
my
mind,
is
that
it's
not
that
these
are
new
features
that
we've
never
had
before?
A
A
There
there's
still
a
component
to
reliability
and
security
and
observability
that
cannot
be
done
by
the
service
mesh,
but
rather
than
the
servicemen
the
developers
having
to
own
all
of
that,
they
can
now
get
those
features
at
the
platform
level.
So
that's
what
lingerie
provides
it
moves.
Those
features
out
of
the
hands
of
the
developers
and
down
to
the
platform
where
they
belong
and
linkerity,
of
course
focuses
on
being
very
light
and
being
very
simple.
So
why
should
you
care?
A
Well,
in
my
mind,
you
should
care,
because
what
linkrd
does
is
it
gives
you
the
platform
owners,
the
kubernetes
adapters.
The
sres
gives
you
some
primitives
around
observability
and
security
and
reliability
that
you
need.
You
need
these
things
if
you're
building
a
cloud
native
application
and
it
does
it
in
a
way
like
I
said
that
gives
you
no
developer
involvement.
So
it's
not
really
about
solving
technical
problems
so
much
as
solving
socio-technical
problems,
it's
going
to
give
you
the
control
and
ownership
over
your
own
destiny
sounds
great.
A
Okay.
Let's
talk
a
little
bit
about
linkedin's
design
philosophy.
In
short,
I
would
say
this
is
do
as
little
as
possible
right.
So
linker
d
should
just
work
out
of
the
box.
You
should
be
able
to
add
linker
d
to
a
functioning
kubernetes
application
and
the
application
should
continue
functioning.
Okay
sounds
great,
actually
pretty
hard
to
do.
It
should
consume
as
a
minimum
of
resource
costs
right
so
memory.
Cpu
consumption
should
be
as
small
as
possible.
A
The
latency
that
it
adds
to
your
application,
of
course,
should
be
as
small
as
possible,
too,
and
there's
all
sorts
of
cool
engineering
that
we
do
in
order
to
accomplish
that,
it
should
be
simple,
so
you,
as
the
operator
of
linkedin,
should
not
have
to
wrestle
with
a
thousand
configuration
options
and
a
whole
bunch
of
new
yaml
and
and
so
on.
You've
just
adopted
kubernetes,
it's
already
very
complicated.
A
You
shouldn't
have
to
adopt
a
whole
new
level
of
complication
and
lingerie
should
have
security
enabled
out
of
the
box
on
by
default,
and
that's
the
big
headline
feature
of
2.9
around
mutual
tls,
but
I'll
leave
that
for
terune.
So
if
a
control
plane,
that's
written
in
go
sits
in
a
kubernetes
namespace,
we
have
a
very
cool
data
plane
written
in
rust,
which
I'm
going
to
talk.
A
little
bit
about
called
linker
d2-proxy-
and
I
have
you
know
some
background
reading
here.
A
If
you
feel
like
hearing
about
some
of
the
history
in
the
big
kind
of
rewrite
from
linker
dv
one
to
v2
all
right,
so
just
briefly,
linkerity
architecture
like
most
service
meshes,
there
is
a
control
plane
and
there's
a
data
plane.
The
control
plane
is
a
bunch
of
components
that
sit
off
to
the
side
and
give
you
control
and
visibility
into
the
data
plane
and
the
data
plane
is
a
set
of
proxies.
Those
proxies
are
deplo
deployed
as
side
car
containers,
which
means
they
sit
in
the
same
pod
as
your
application.
A
So
that
means
those
proxies
have
got
to
be
really
really
fast
and
really
really
lightweight,
because
you
might
have
a
whole
lot
of
them.
So
we
have
invested
a
whole
lot
of
time
and
energy
into
what
we
call
our
microproxy,
which
is
a
linker
data
plane
called
linker
d2
proxy.
It's
a
critical
part
of
the
system.
Many
service
meshes
are
built
on
envoy,
we're
not
we're
built
on
this
very
dedicated
service
mesh
proxy,
which
allows
us
to
be
extremely
fast,
extremely
low
memory
and
extremely
secure.
So
by
writing
this
in
rust.
A
We
avoid
a
whole
class
of
memory,
vulnerabilities
that
are
endemic
to
c
and
c
plus
plus
we
can
be
you
know
just
as
fast
as
the
machine
will.
Let
us
be,
of
course,
we're
audited
thanks
to
cncf.
We
have
regular
third-party
security
audits,
which
we
pass
and
linker
d2
proxy
is
built
on
this
ultra
modern
asynchronous
network
stack.
So
all
of
the
really
interesting
asynchronous
network
programming
kind
of
development
is
all
happening
in
the
rust
world
today.
A
So
if
that
kind
of
thing
is
exciting
to
you,
then
please
check
out
the
repo
everything
is
open
source.
Of
course,
apache
v2
100,
audited,
100
awesome,
so
that's
linker
d2
dash
proxy
here's
a
little
snippet
from
the
security
audit.
Of
course,
the
full
audit
is
in
the
repo
itself,
a
typically
excellent
code:
readability,
careful
choice
of
implementation,
languages
yeah.
It
was
a
good
report.
A
Okay,
we
actually
have
a
newer
version
of
these
numbers.
Unfortunately,
that
newer
version
was
not
available
in
time
for
me
to
record
this.
But
if
you
search
for
kinvoke
linker
d
benchmarks,
you
should
find
a
whole
bunch
of
open
source
benchmark
frameworks
and
results.
Talking
about
how
expensive
it
is
to
run
linkery-
and
the
answer
is
well,
it's
more
expensive
than
not
having
a
service
mesh,
but
it
is
a
lot
faster
and
a
lot
smaller
than
other
service
mesh
alternatives.
A
Istio
is
the
one
we
like
to
pick
on,
because
that's
the
one
that
everyone
knows
about.
Linker
d
is
much
much
faster
and
much
much
smaller,
but
do
your
own
research
check
out
those
results
and
then
finally,
you
know
I
said
we
were
going
to
pick
on
istio
a
little
bit
and
I'm
happy
to
take
questions
I'll
be
around
during
the
q
a
period
for
this.
A
In
my
mind,
because
this
is
such
a
common
one-
I
want
to
address
it
up
front.
I
think
it
comes
down
to
what
do
you
need
in
a
service
mesh.
So
you
know
both
istio
and
linkery
provide
very,
very
similar
value,
props.
They
both
provide
these
security
and
observability
and
reliability
features,
but
there's
a
very
different
focus
between
the
two
projects.
Istio
is
extremely
feature-rich
and
works
in
many
many
different
environments
under
many
many
different
situations,
lincoln
lingerie,
is
very
focused
on
doing
the
bare
minimum.
A
So
we
are
very
focused
on
the
kubernetes
use
case
and
we're
very
focused
on
making
it
so
that,
if
you
want
the
power
of
the
service
mesh,
you
actually
don't
have
to
do
any
configuration
at
all
at
least
certainly
not
to
get
started
and
we'll
do
as
much
out
of
the
box
for
you
by
default.
Of
course,
that
doesn't
mean
we're
hiding
things
away
from
you.
We're
also
very
focused
on
visibility
and
introspection.
A
So
at
every
point
you
know
exactly
what
linkedin
is
doing
and
you
can
understand
the
state
of
the
mesh
as
well
as
how
it's
helping
your
applications.
Okay,
so
lots
more
to
be
said
on
this.
Obviously,
but
at
this
point
I
am
going
to
turn
it
over
to
my
fellow
linker
d
person,
tarun
potholopathy
who's,
going
to
tell
you
a
little
bit
about
what
has
been
cooking
in
the
linkedin
kitchen
and
what
is
coming
soon
so
take
it
away
to
ruin.
B
I
thank
you
william,
hello,
everyone.
My
name
is
sarin
and
I'm
one
of
the
maintenance
of
the
linkedin
project
in
today's
my
part
of
the
session
I'll
try
to
cover
the
current
roadmap
of
the
project
and
also
the
current
state
of
the
lingerie
project,
and
also
the
future
roadmap.
So,
first
we'll
start
with
the
2.8
release
which
which
added
support
for
multi-cluster.
B
This
means
that
you
can
have
applications
across
clusters
talking
to
each
other
in
a
secure
manner.
This
is
possible
by
adding
a
new
component
called
the
multi-cluster
gateway
that
acts
like
an
entry
point
into
your
cluster
and
all
the
all
the
communication
from
other
classes
will
flow
through.
This
has
the
following
goals,
so
it
it
expects
a
unified
trust
domain
that
is
validated
across
all
clusters
across
clusters.
B
During
during
communication,
there
is
no
single
point
of
failure,
which
means
that
even
if
a
cluster
goes
down,
it
does
not
affect
the
service,
the
multi-cluster
functionality,
but
for
your
application,
you
can
use
things
like
traffic,
split,
etc,
to
failover
onto
other
clusters,
etc.
Applications
on
other
clusters.
It
also
does
not
have
a
requirement
on
the
networking
primitive
that
the
cluster
uses,
so
the
so
you
can
have
these
this
feature
in
in
environments
like
private
environments
vpcs
or
on
the
open
internet.
B
B
B
This
has
been
one
of
the
requested
features,
so
we
also
added
support
for
arm64,
which
means
that
you
can
run
the
here
like
the
control
pin
on
the
proxies
on
arm
64
devices
like
the
raspberry
pi,
except
run
up.
You
also
added
support
for
bring
your
own
promises,
which
means
that
previously,
whenever
you
install
even
now,
whenever
you
install
linked,
you
have
you
linked,
it
gets
it
don't
promise
this,
which
is
used
to
power,
the
dashboards,
the
cla,
etc.
B
We
also
made
it
made
the
existing
linked
promoters,
more
configurable,
so
that
you
can
have
things
like
remote,
write,
etc.
Configurations
on
the
on
the
linkedin
prometheus.
We
also
added
support
for
service
topology
service.
Topologies
is
a
relatively
new
feature
in
kubernetes
that
allows
you
to
have
node
topology
available
balancing.
So,
for
example,
if
a
client
is
connecting
to
a
service,
it
should
probably
talk
to
the
the
part
on
the
same
node
or
at
least
on
the
same
availability
zone
so
that
the
latencies
are
lower
rather
than
some
other
some
other
one.
B
So
if
you
have
service
topple
this
configured
with
that
information
linked
will
take
that
information
into
account
whenever
it's
taking
a
load.
Balancing
decision
will
make
so
as
to
have
a
latency
available
so
that
to
have
a
less
latency.
So
we
also
did
a
foundational
change
on
how
we
store
state
and
retrieve
it
during
upgrades.
So
essentially
previously,
as
linker
is
being
adopted
more
widely,
it
has
been
a
problem
to
add
more
configurations,
etc,
specific
to
environments,
etc.
B
We
made
it
easy
to
add
more
configuration
options
without
having
to
change
it.
Multi
change
things
at
multiple
places
so
that
you
can
have
more
configurations
on
linkedin
2.9
release
also
has
a
ton
of
other
improvements
around
multi-cluster
multi-threading
in
the
proxy
and
support
for
endpoint
slices.
The
2.9
release
is
a
is
a
very
tightly
packed
release
and
I'll
highly
recommend
you
to
check
out
the
release.
Notes
to
understand
the
scale
of
this
release.
B
Next,
we'll
talk
about
the
2.10
and
beyond,
so
so.
First,
obviously
we'll
we
will
work
on
the
server
speaks
first
protocol,
which
means
that
for
applications
like
mysql,
etc,
where
the
server
speaks
first
rather
than
the
client
it's
hard
for
the
proxy
to
to
do
protocol
detection
and
do
do
mtls
on
top.
So
what
we're
planning
to
do
is
to
have
a
way
for
the
car
to
for
the
user,
to
configure
things
so
that
the
proxy
can
configure
that
it's
a
server
speaks
first
protocols
and
so
that
the
proxy
can
act
accordingly.
B
We'll
also
be
adding
support
for
multi-cluster
tcp,
which
means
that
not
only
http
connections
can
flow
through
the
multi-cluster
data,
but
also
all
kinds
of
tcpa
connections
that
and
it
is-
and
they
are
mtls,
obviously
with
both
of
the
above
changes
done.
What
we
can
do
is
to
man
we
can
mandate
tls
by
default
in
your
cluster,
so
what
it
means
that
thinker
expects
you
to
have
some
configuration
to
tell
you
that,
don't
to
tell
linker
that
there
is
some
conf,
some
communication,
that
you
don't
want
empty
a
list.
B
So
it
so,
it
means
that
by
default
all
your
message
applications
all
the
all.
If
you,
if
all
the
applicants
in
your
cluster
are
missed,
it
essentially
means
that
you
have
tls
by
default
everywhere,
which
is
awesome
for
security
and
auditing
purposes.
Obviously,
we'll
also
be
having
an
inc,
a
minimal
control
plane
install.
So
so
what
you're
trying
to
do
is
that,
even
though
the
linkedin
components
right
now
can
work
independently,
the
installation
package
is
a
bit
tightly
packed
to
allow
you
to
do
that.
B
So
what
we're
trying
to
do
is
that
to
have
to
break
up
these
components
into
modules
that
you
can
independently
install
and
incrementally
install
so,
for
example,
first,
you
would
start
with
the
core
control
plane
that
consists
of
the
proxy
injector,
the
destination
service,
the
identity
service,
and
then
you
can
incrementally
install
things
like
the
dashboard
on
top.
So
this
this
makes
the
installation
installation
approach
more
simpler
and
also
more
flexible,
based
on
your
environment,
etc.
B
We'll
also
be
doing
authorization
authorization,
obviously
so,
which
means
that
you
want
to
have
a
way
to
configure
policies
on
which
service
can
access
which
other
service
and
which
service
should
not
access,
which
other
services,
essentially
so
we'll,
be
adding
we'll
be
adding
a
new
new
new
new
primitive
around
those
lines
to
make
it
possible
to
configure,
allow
and
deny
rules.
Based
on
that
we'll.
We
are
also
planning
to
have
standardized
apis
and
add-on
framework.
So
so
it
is
as
so.
B
What
a
service
mesh
allows
to
be
built
on
top
using
its
apis
is
is
very
important,
so
things
like
lagger,
which
does
canary
deployments
or
the
service
mesh
interface
etc,
are
built
using
the
apis.
That
is
service
mesh,
provides
so
to
to
add
additional
functionality
like
an
agent
that
reacts
to
golden
metrics
and
emits
events,
and
things
like
that.
You
want
to
have
a
standardized
api
on
the
on
the
on
the
service
message.
B
One
of
the
yeah
we'll
obviously
have
a
lot
of
other
plans
here:
web
assembly,
plugins,
etc.
As
more
and
more
of
these
use
cases
and
feature
requests,
pop-up
will
try
to
prioritize
based
on
that
and
and
have
all
these
roadmaps
are
available
as
issues
in
the
project,
and
if
you
have,
if
you
are
interested
on
any
of
them,
you
should
definitely
check
them
out
or
raise
an
issue.
If
you
are
interested
in
a
specific
use
case,
and
we
can
figure
that
out
as
it's
a
planned
roadmap,
keep
in
mind
that
it
can
change.
B
So
next
we'll
talk
about
the
getting
involved
side
of
things
so
I'll
I'll
tell
my
story
first.
So,
like
an
year
ago,
I
was
a
cncf
intern
at
working
on
lingerie
on
various
bug,
fixes
on
the
smi
project,
etc,
and
then
I've
been
kept
contributing
on
it.
Now
now,
I'm
one
of
the
maintenance
of
the
project.
B
B
For
example,
you
can
write
blog
post
on
a
specific
problem
that
you
that
you
that
you
faced
during
the
install
and
blog
about
it,
so
that
other
users
can
can
take
note,
I'm
sure
a
lot
of
users
would
fall
into
the
same
problem.
You
know
we
have
a
very
active
slack
community,
where
not
just
the
maintainers,
but
also,
but
also
the
users,
ask
questions
and
also
answers
and
also
answer
answers
between
themselves.
B
All
our
development
actually
happens
on
github
on
using
issues
and
using
issues
and
our
discussions
feature.
We
also
send
mail,
english,
etc
about
the
project
updates,
etc.
We
also
have
monthly
community
calls
where,
where
we,
where
we
provide
an
update
on,
what's
been,
what's
been,
what's
been
cooking
in
the
project
and
also
take
user
feedback
questions,
so
if
you're
interested
we're
more
than
happy
to
help
you
get
started.
Thank
you.