►
From YouTube: Overview and State of Linkerd - Oliver Gould, Buoyant
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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 - Oliver Gould, Buoyant
In this talk, maintainers from the Linkerd project will present an overview of the project and an update on upcoming releases. They will 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 features from the latest Linkerd release, as well as the latest on Linkerd's Rust micro-proxy, Linkerd2-proxy.
A
A
A
That's
like
way
more
than
last
time,
honestly!
So
we're
making
progress
good.
So
my
name
is
oliver.
I
I
lead
the
linkedin
project.
I
created
linkedin
project
back
in
2015
or
so,
and
I'm
the
cto
of
a
company
called
buoyant.
We
have
a
booth
in
the
vendor
hall
that
you
can
get
a
cool,
linkery
hat
set,
etc,
and
I
want
to
give
you
today
a
pretty
short
talk.
I
think
we
know
about
30
minutes
or
so
so
really
go
through
a
quick
run
through
of
what
linguity
is.
A
A
We
started
with
a
version
of
linkerd1.x
which
was
written
in
the
jvm.
We're
not
talking
about
that
today.
We're
talking
about
linker
d2,
which
is
really
where
the
main
line
of
work
is
happening
since
about
2017,
or
so
we
have
a
whole
bunch
of
production.
Experience,
lots
of
cool
logos,
some
of
some
of
the
logos.
I
can't
even
show
you
because
they're
so
secret,
but
linkedin
is
trusted
and
used.
A
A
First
and
foremost,
it
gives
you
observability
for
those
of
you
who
are
unfamiliar
with
the
service
mesh
architecture,
we'll
talk
about
that
in
a
second,
but
because
there
are
sidecar
proxies
running
throughout
your
cluster.
We
can
monitor
http
metrics
grpc
metrics,
tcp
metrics
out
of
the
box
uniformly.
So
there's
no
need
to
instrument
your
application,
especially
if
you
have
multiple
languages
or
headers
environment.
You
don't
have
to
try
to
cobble
together
visibility
systems
on
top
of
these
things,
and
you
don't
have
to
modify
your
code
to
do
it.
A
A
This
has
to
be
something
that
you
can
add
into
your
cluster
and
basically
not
worry
about
it,
especially
when
you're
getting
started.
It
can't
be
a
bunch
of
new
primitives
to
go
learn,
unlike
some
of
the
other
service
meshes,
so
it
has
to
just
work
out
of
kubernetes.
You
can't
modify
our
application
to
do
it
just
add
linker
d
and
things
get
better
with
that.
We
don't
want
to
increase
the
cost
too
much.
A
This
has
to
be
on
by
default.
It
can't
be
something
that
you
have
to
buy
buoyance
professional
services
to
secure
your
cluster
with
linker.
He
has
to
do
this
in
its
core
open
source,
offering
talk
a
little
bit
about
the
architecture,
but
control
plane
is
primarily
implement.
Go
though
we
have
some
rust
things
showing
up
there.
It's
pretty
the
core
control
plane
is
fairly
small.
A
A
So,
instead
of
having
all
of
your
your
routing
infrastructure
logic
built
into
your
application,
you're
extracting
this
out
into
a
separate
component
that
can
be
configured
separately
from
your
application,
dynamically
at
runtime
to
modify
the
traffic
patterns.
We
do
this
by
adding
a
sidecar
process
to
your
pods.
This
is
a
wonderful
thing
about
kubernetes
that
the
prior
container
orchestrators,
like
mesos,
didn't
get
right.
It's
not
a
single
container,
you're
orchestrating
it's
several.
So
we
have
these
sidecar
proxies
containers
that
can
facilitate
communication.
A
We
also
have
an
extension
model
that
makes
it
easy
to
have
bigger
parts
of
the
control
plane
become
optional.
This
was
introduced,
I
think
in
210,
which
was
early
this
year,
and
so
we
have
a
viz
extension,
for
instance,
that
will
bundle
prometheus
grafana
the
linkery
dashboard,
a
system
we
call
tap,
which
lets
you
connect
to
proxies
while
they're
running
and
query
requests
as
they're
going.
A
A
As
I
said
before,
mtls's
mutual
tls
is
a
big
part
of
what
link
does
and
we
in
fact
build
lots
of
other
functionality
on
top
of
this
identity
right.
So
the
idea
is
that
if
you
have
two
pods
or
two
containers
or
two
processes,
communicating
each
other,
the
server
needs
to
know
who
the
client
is,
what
its
identity
is,
be
able
to
coordinate
that
and
not
just
base
it
on
some
ip.
A
We
want
this
to
be
kind
of
a
zero
trust
situation,
and
the
client
needs
to
be
able
to
validate
that
it's
actually
talking
to
the
server.
It's
thinking
that
it's
talking
to,
so
we
do
this
by
bootstrapping
off
of
service
accounts,
so
every
pod
in
the
kubernetes
cluster
generally
has
service
account
tokens
that
are
provided.
As
the
pod
starts
up.
We
use
that
to
authenticate
to
the
control
plane,
we
issue
private
keys
locally,
so
those
private
keys
never
leave
the
container's
memory
or
the
processes
or
the
pods
memory
rather
and
we
rotate
those
certificates.
A
A
A
These
are
faster
and
generally
more
performant
than
the
legacy
rsa
keys.
We
also
have
no
dependencies
on
openssl
or
boring
ssl
or
nec
infrastructure,
unsafe
c
infrastructure
in
the
tls
stack.
So
on
the
go
side,
we're
using
gocrypto,
that's
in
the
control
plane
on
the
proxy
we're
using
russell's,
rust,
rust,
tls,
it's
a
project,
that's
built
on
ring
and
that's
a
subset
of
the
boring
scissor
functionality
built
primarily
in
rust,
which
is
safe.
A
A
So
all
the
services
you
create
in
the
client
cluster
instead
of
selecting
pods
you're,
not
talking
to
pods
directly
you're
talking
to
a
gateway
address
in
the
target
cluster,
where
we
terminate
mtls,
you
can
apply
policy
on
that
and
that
does
load
balancing
in
the
cluster,
which
is
what
you
want
to
do.
You
want
to
have
load
balancing
decisions,
be
kind
of
close
to
the
application.
A
This
also
means
that
you
can
use
things
like
traffic
split
to
make
this
transparent,
so
you
can
just
talk
to
a
logical
service
and
whether
that's
in
the
local
cluster
or
another
cluster
can
be
an
operational
detail
and
it's
really
again
building
into
the
kubernetes
primitives
so
that
you
don't
have
to
go.
Do
a
bunch
of
linkery
specific
things.
This
a
lot
of
these
patterns
use
smi
today,
which
is
another
standard
in
the
space
ish
standard.
A
A
The
link
is
sidecar
proxy
is
where
I
spend
too
much
of
my
time.
Most
of
my
time.
I
I
love
it,
but
it's
a
labor
of
love
and,
unlike
the
other
surface
meshes
in
space,
we
do
not
use
envoy
there's
a
whole
bunch
of
reasons
behind
this
you're
welcome
to
go,
read
the
blog
post
on.
Why,
and
I
think
some
of
the
reasons
will
become
clear
as
we
go,
but
the
idea
here
is
that
we
want,
in
order
to
go
back
to
that
philosophy
of
having
something
that
just
works.
That's
minimal!
A
A
A
We
kind
of
started
with
that
model
of
link.
31,
honestly,
where
you
had
a
really
rich
plugin
system,
where
you
could
do
lots
of
different
things
in
the
data
path,
we
realized
that,
like
if
security
is
a
big
part
of
this
configuration's
bad
idea
like
configuration
and
that
complexity
that
comes
with
it,
is
really
the
enemy
of
having
something
that
you
can
like
reason
about
and
say,
this
is
secure.
This
works
well
on
top
of
that.
A
A
H2
was
almost
entirely
written
by
buoyant
folks
tower.
Is
a
service
abstraction
really
similar
to
twitter's
finagle,
which
I
have
tons
of
experience
with,
and
we've
really
built
this
all
up
into
the
rust
system,
which
is
now
becoming
a
more
and
more
attractive
target
for
other
things
to
be
built
here,
and
so
this
was
a
good
investment
from
us,
because
now
we
see
we
actually
collaborate
a
lot
with
folks
at
aws
to
name
a
few
other
companies
as
well
on
this
part
of
the
stack
and
it's
really
high
performance
and
not
a
lot
of
complaints.
A
A
And
again,
to
highlight
on
that
point
at
the
bottom:
we
don't
really
think
that,
like
we
have
folks
say
like
well,
how
do
I
configure
envoy
or
like,
and
the
proxy
in
linkedin
is
not
something
that
you
should
be
focused
on
as
like
a
thing
that
you
can
program
or
configure.
The
goal
for
linguity
is
not
to
configure
proxies.
The
goal
for
linguine
is
to
facilitate
communication,
and
the
proxy
is
just
an
implementation
detail,
and
so
there's
a
world
where
maybe
envoy
gets
written
in
rust
and
really
fits
our
needs.
A
This
obligatory
slide.
If
I
don't
include
this
someone's
going
to
ask
me-
and
I
have
to
say
this
all:
what's
the
difference
between
lingqrid
and
istio,
I
work
on
liquidity.
I
can't
tell
you,
but
what
folks
tell
us
is
that
in
fact
put
it
this
way?
Many
many
many
of
our
recent
liquidity,
adopters
or
folks
who
tried
to
operationalize
this
deal
first
and
then
said
whoa.
This
boat
is
too
big.
I
need
something
that
fits
my
use
case.
A
I
don't
need
half
the
things
in
here.
I
don't
need
a
team
to
like
deploy
this
and
that's
why
linkedin
is
better
for
them,
but
I
think
istio
is
great.
If
you're
trying
to
do
things
that
span
outside
of
kubernetes
and
join
all
sorts
of
different
environments
between
console
and
kubernetes
etc,
you
can
do
lots
of
great
things
with
this
deal.
I
don't
think
it's
a
bad
project.
I
just
think
lingard
is
better
and
here's.
Why.
A
A
We
ran
this,
I
think
over
the
summer
when
we
launched
when
we
released
210
and
what
we
see
here
is
yellow
is
no
service
mesh
just
running
things.
Raw
blue
is
linker
d
and
orange.
Is
this
geo,
and
here
lower,
is
generally
better,
so
on
the
left
here
we
see
latency
at
various
percentiles
on
the
right.
Here
we
see
cpu
usage
and
memory
usage.
A
So
two
weeks
ago
we
launched,
or
we
released,
linguity
2110,
stable
211,
and
this
is
delivers
a
really
highly
requested
feature,
which
is
authorization
policies,
and
so,
if
I
have
mtls-
and
I
can-
you
know-
secure
my
communications,
how
do
I
assert
they're
secure?
How
do
I
say
that
I
only
accept
connections
or
requests
from
these
specific
clients
to
this
application,
and
so
these
authorization
policies
do
that
we
have
two
new
primitives.
One
is
a
server
and
the
other
is
a
server
authorization.
A
So
there's
there
are
various
default
modes,
but
once
you
have
a
server,
it
basically
assumes
the
default
deny
policy,
and
then
you
can
add
authorizations
onto
that.
This
all
kind
of
uses,
hopefully
familiar
primitives
in
label
selectors,
so
servers,
select,
pods
and
refer
to
ports
of
those
pods
authorization
select
servers
it's
fairly
simple,
but
it's
also
powerful
in
the
same
way
that
service
label
selectors
can
be
really
powerful.
A
This
allows
me
to
do
things
like.
I
just
require
mtls,
I'm
going
to
default,
an
eye
policy
in
my
cluster
or
I
can
have
a
default
policy
in
my
cluster.
That
says,
I
require
authenticated
communication.
Anything!
That's
not!
Mtls
has
to
be
documented
by
an
authorization
I'll
give
you
a
caveat
here,
kublet,
which
does
all
your
health
and
readiness
probes
of
your
application
that
can't
be
secured.
A
A
I
also
have
this
proxy
protocol
hint
and
this
is
not
really
tied
to
authorization
at
all,
but
I
can
now
start
talk
about
other
things
on
other
properties
of
servers,
so
a
server
is
really
similar
to
a
service,
but
it's
different
for
reasons
I'm
not
going
to
get
into
unless
you
ask
me,
but
the
server
primitive
we
have
now.
This
new
crd
is
a
building
block
that
we're
going
to
use
for
more
types
of
configuration
on
the
inbound
side.
A
Okay
in
the
oven,
we're
looking
at,
we
have
this
primitive,
called
service
profiles,
which
is
what
we
use
for
both
inbound
and
outbound
routes,
timeouts
configurations,
all
sorts
of
things
there,
and
it's
really-
we've
lived
with
it
for
a
few
years
now
and
it's
not
our
favorite
part
of
the
system.
I'll
put
it
that
way,
and
so
we're
looking
for
a
replacement
there,
probably
much
more.
Like
those
primitives,
I
just
showed
you
the
server
and
server
authorization
where
we
can
allow
select
routes
onto
clients
and
things
like
that.
A
A
This
will
allow
us
to
be
transparent
on
the
server
side,
so
right
now,
connections
into
your
application,
look
like
they're
coming
from
localhost
because
they
are
they're
coming
from
the
proxy.
We
want
to
be
able
to
pass
that
through.
So
you
see
the
original
client
ips,
which
will
really
help
with
ingresses,
especially
today,
there's
a
way
around
that
there's
some
workarounds,
but
it's
a
little
annoying.
A
In
211
we
introduced
a
new
extension
called
linguity
smi,
and
the
goal
here
is
to
create
a
separate
extension,
that's
responsible
for
managing
or
installing
the
smi
crds
and
really
all
of
the
smi
functionality.
We
don't
want
to
be
part
of
the
core
link
install
as
we
introduce
our
own
primitives
here.
We
want
to
have
adapters
that
can
read
smi
primitives
and
generate
linguistic
primitives,
or
vice
versa.
A
For
instance,
smi
has
traffic
policy
crds
that
don't
really
line
up
with
ours,
they're
they're,
not
port,
aware,
for
instance,
we
think
pork
awareness
is
really
important.
Part
of
this,
for
instance,
I
might
want
to
allow
kublet,
unauthenticated
kublet
connections
on
my
health
check
probes,
but
not
my
application
port.
I
have
to
differentiate
those
by
port,
and
so
I
see
that
being
a
room
in
the
project
for
people
who
care
about
smi
to
get
involved
and
help
us
build
those
adapters
and
operators.
A
A
Looking
forward
a
little
bit
more
there's
this
new
linux
system,
I
o
system
called
iou
ring.
It
has
some
really
cool
benefits
performance,
wise
this
support's
still
pretty
new
in
tokyo.
It's
mostly
focused
on
file.
I
o
and
things
like
that,
but
as
that
gets
merged
further
into
the
networking
stack
we're
going
to
take
advantage
of
that
proxy
and
I
think
that'll
have
some
pretty
big
cpu
improvements,
especially.
A
The
folks
at
netapp
have
a
branch
of
the
proxy
that
adds
really
replaces
russell's
with
a
boring,
ssl
binding
native
tls
binding.
This
can
be
used
to
build
fips
140-2
compliance
systems.
So
if
you're
in
government
pci
compliant
areas,
you
can't
use
modern
crypto,
you
have
to
use
a
really
specific
set
of
vetted
crypto.
A
That
is
not
modern,
unfortunately,
but
we're
going
to
support
that
and
we're
doing
work
today
to
well
not
today,
we're
doing
work
last
week
and
next
week
to
support
that
and
get
the
proxy
to
be
able
to
be
compiled
in
the
mode
that
will
support
them
and
that's
a
big
thing
to
the
folks
at
netapp
there,
and
also
this.
This
roadmap
is
fungible.
So
if
you
have
feedback
here,
let
us
know
if
you
didn't
see
the
keynote.
This
morning
we
graduated.
Finally,
oh
yeah,
as
I
said,
we've
been
in
the
community
since
2016..
A
So
it's
great
to
see
it's
really
like
as
a
maintainer.
It
doesn't
make
that
much
of
a
difference.
We
have
a
slightly
bigger
logo
on
some
of
the
slides.
Now.
The
real
benefit,
I
think,
is
that
for
everyone,
who's
been
on
linkedin
deployed
it
is,
they
can
go
to
their
management
and
say
see.
This
is
a
real
thing,
I'm
not
a
weirdo,
you
might
be,
but
it's
so
separate.
We
have
a
bunch
of
ways
to
get
involved.
A
If
you
like
to
do
talks
or
meetups,
we
have
slides
and
a
program
to
help
facilitate
that
developers
hang
on
our
discord
server.
We
have
weekly
edge
releases,
probably
not
this
week,
but
almost
every
week
we
do
edge
releases.
So
if
you
have
staging
clusters
or
if
you're
looking
for
ways
to
give
feedback
before
we
go
to
prod
edge,
release
is
a
great
thing
to
test
monthly
community
meetings.
You
can
join
zoom
or
not
zoom,
something
like
zoom
and
ask
us
a
ton
of
questions.