►
From YouTube: Intro: Linkerd - William Morgan, Buoyant
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Intro: Linkerd - William Morgan, Buoyant
In this session, William Morgan will provide an introduction to Linkerd, the CNCF's service mesh project. Linkerd features blazing fast performance, an ultralight footprint, a Kubernetes-native design, and open governance. You'll learn what it does, why it's useful, differences with other service meshes, and finish with a brief Q&A.
https://sched.co/Zews
A
A
So
this
is
an
introductory
talk
about
linker
d.
I
am
going
to
keep
it
up
to
date
with
the
latest
information.
So
if
you
are
familiar
with
linkerd,
hopefully
you'll
still
learn
something
in
this
and
if
you're,
not.
If
you
are
still
struggling
with
the
concept
of
what
is
a
service
mesh,
then
don't
worry
you're,
not
alone
and
I'll.
Try
my
best
to
address
those
questions
as
well
before
I
get
started
just
a
couple
things
I
wanted
to
say.
A
The
first
is
that
linker
d
is
a
community
project
and
that's
a
big
part
of
everything
that
that
we
do
so.
You
know
by
virtue
of
watching
this
talk.
You
are
just
as
much
a
part
of
the
linker
d
community
as
I
am
so
I'm
using
all
of
my
powers
invested
in
me
as
linker
d,
you
know,
maintainer
or
whatever
to
now
bless
you
with
the
ability
to
run
linker
d
yourself
to
talk
about
it,
to
understand
it
and
to
join
us.
A
We
have
a
very
active
community
on
slack
and
github
and
in
fact
these
slides
I'm
going
to
be
presenting
are
also
available
to
you
they're
on.
If
you
go
to
linker
dot
io,
you
will
see
them
on
the
community
section.
So
if
you
want
to
give
talks
about
linkedin
yourself,
all
this
material
is
available
to
you.
A
Okay.
So
let's
talk
about
language,
so
linker
d
is
a
service
mesh
and
I'll
explain
exactly
what
that
means
in
another
slide
or
two
linkery
is
an
ultralight.
Ultra
fast
security,
first
service
mesh
for
kubernetes
I'll
describe
all
of
exactly
what
that
means.
Over
the
next
couple,
slides
linkery
was
actually
the
very
first
service
mesh
project.
It
was
one
that
introduced
the
term
service
mesh
to
the
world,
which
you
know
honestly.
A
We
kind
of
regret
at
this
point,
but
that's
that's
where
we
are
and
as
such
we've
been
in
production
for
almost
four
years
at
this
point
and
a
very
healthy
community
of
folks,
just
like
yourself,
centered
in
the
slack
channel
and
and
the
github
repo
a
lot
of
contributors,
we
have
weekly
edge
releases.
If
you
want
to
try
the
latest
and
greatest
features
stable
releases,
probably
every
two
to
three
months
and
linkedin
is
committed
to
open
governance
and,
of
course,
it's
hosted
by
the
cncf.
A
A
Okay,
let's
talk
about
what
linker
d
actually
does
so
linker
d,
like
almost
every
service
mesh,
provides
a
bunch
of
features
to
you
right
and,
and
we
kind
of
put
these
into
three
basic
buckets,
there's
a
set
of
features
that
are
around
observability,
a
set
of
features
that
are
on
reliability
and
there's
a
set
of
features
that
are
around
security
and
all
of
those
features.
There's
a
couple
kind
of
identifying
characteristics
about
them.
The
first
is,
you
know
from
the
linker
d
perspective.
A
Of
course
we
try
and
provide
these
to
you
in
a
very,
very
simple
and
lightweight
package,
and
we
focus
on
operational
simplicity,
especially
so.
Our
whole
kind
of
goal
in
linkerid
is
to
reduce
the
amount
of
overhead
kind
of
mental
overhead
that
you,
as
an
operator
of
a
service
mesh,
have
to
have
now.
A
The
interesting
thing
about
these
features
right
is
that
these
are
all
things
that
we
could
accomplish
in
the
application
right
things
like
service
level,
golden
metrics
right,
so
we
link
rd,
can
monitor
your
success
rate
and
your
latency
distribution
and
your
request
volume.
You
can
draw
service
topologies
and
things
like
that,
based
on
metrics
data
right,
you
can
do
that
in
the
application
and
that's
kind
of
been.
You
know
the
standard
approach
you
can
use
in
apm
or
something
like
that,
but
the
value
that
linker
d
provides.
A
Is
it
does
this
at
the
platform
layer,
so
it
doesn't
matter
what
language
the
applications
are
written
in,
doesn't
matter
what
frameworks
they're
using
doesn't
matter.
You
know
what
the
developers
do.
What
linker
d
can
provide
is
a
consistent
and
uniform
layer
of
observability
across
all
of
your
services,
and
it
does
that
at
the
platform
layer
now
there's
limits
to
that.
Of
course,
right
like
we
have
to,
we
treat
the
services
as
black
boxes.
Basically,
so
we
don't
know
what's
going
on
inside.
We
can't
tell
you
oh
this.
A
You
know
this
loop
is
happening
200
times
a
second
or
anything
like
that,
but
we
can
give
you
the
golden
metrics
things
like
success
rate
and
latency
that
you
as
a
platform
owner
really
need
and
again
we
can
do
them
uniformly
across
the
entire
infrastructure.
Same
thing
with
the
reliability
features.
Things
like
retries
and
timeouts
right,
linker
d
is
not
a
complete
solution
to
reliability.
There's
a
lot
more.
You
have
to
do,
but
we
can
do
retries
at
the
platform
level
under
certain
conditions,
and
we
can
do
them
in
a
way.
A
That's
uniform
and
that's
well
parameterized,
and
so
on
and
security.
Of
course.
Linquity
is
definitely
not
a
full
security
solution.
There's
a
whole
lot
to
security,
but
we
can
provide
mutual
tls
in
between
pods
automatically
at
the
platform
layer
without
developers
having
to
do
anything
and
I'll
talk
a
lot
about
that,
because
there's
a
really
interesting
security
angle.
A
So,
overall
you
know
if
you
walk
away
with
nothing,
you
know
else
from
this
talk.
I
want
you
to
understand
that
the
service
mesh
provides
a
set
of
features
and
it
provides
them
at
the
platform
layer
which
means
that
you,
as
a
platform
owner
you
know
who's
operating
the
the
kubernetes
kind
of
ecosystem
of
your
developers,
you're
actually
decoupled
from
what
the
developers
do
so
the
developers
are,
you
know.
Maybe
another
way
of
saying
is
that
developers
are
then
freed.
They
don't
have
to
implement
the
tls.
A
You
get
to
do
it
at
the
platform
layer,
okay,
and
so
why
do
you
care?
I
think
I
started
touching
on
this
already
in
the
previous
slide
right.
So
you
know
all
those
fancy
features
right.
Linker
d
gives
them
to
platform
owners
right,
the
sres,
the
architects,
the
the
folks
who
are
adopting
kubernetes
right.
We
give
those
those
kind
of
critical
primitives
that
you
need
for
operating
a
large
cloud
native
application
and
we
give
them
to
you
in
a
way
that
has
no
developer
involvement.
A
I
made
these
slides
on
google
slides
and
they
looked
a
lot
better
before
I
like
exported
them
to
powerpoint.
So
you
can
imagine.
This
thing
is
like
lining
up
visually,
so
you
know
another
way
of
thinking
about
it.
Maybe
is
that
linker?
Is
it's
not
so
much
it's
a
solution
for
technical
problems.
It's
a
solution
for
socio-technical
problems.
We
want
to
decouple
the
developer
and
the
platform
side,
so
both
sides
have
ownership
and
agency
in
their
goals
for
what
they
need
to
do
for
their
job.
A
So
maybe
that's
a
little
too
philosophical
okay.
So
how
is
linkerd
design
right?
There's
a
lot
of
different
ways
of
of
building
a
service,
mesh
and
linkerity
has
a
very
particular
philosophy
for
how
we
do
this.
So
the
first
is
it
has
to
work.
It
has
to
just
work
when
it
comes
out
of
the
box,
so
as
much
as
we
can
and
there's
always
asterisks
in
these
statements.
A
Right,
there's
always
like
cases
where
we
can't
quite
do
this
magically
for
you,
but
as
much
as
we
can,
if
you
have
a
functioning
kubernetes
application
and
you
install
linker
d
applications
should
continue
functioning
right
like
we
shouldn't,
we
shouldn't
break
stuff
and
you
should
be
able
to
get
there
without
having
to
do
any
configuration.
So
we
try
and
get
you.
You
know
kind
of
basic
service
mesh
functionality
without
you
having
to
do
any
configuration.
A
A
We
want
you
to
spend
the
least
resources
on
this
computational
resources,
as
you
can,
and
then
the
next
one
is
around
simplicity.
This
is
one
that
I
think
is
really
often
underlooked
in
the
service
mesh
world.
Right
like
it's,
not
just
about
making
the
computers
do
crazy
things
there's
a
human
in
there.
You
know
possibly
someone
like
you
who
has
to
operate
this
thing,
who
has
to
understand
it?
Who
has
to
justify
it
to
your
peers?
A
Who
has
to
defend
it
when,
like
people
are
saying
something
broken?
I
think
it's.
This
service
mess
you
introduced
right,
so
we
have
to
reduce
that
operational
complexity
in
every
possible
way.
We've
just
asked
you
to
adopt
kubernetes,
which
is
like
a
huge
amount
of
apis
and
so
on,
and
you
know
we
don't,
then
want
you
to
like
double
the
amount
of
complexity
and
then.
Finally,
the
final
kind
of
real
core
goal
for
linker
d
is
to
be
security
first
right.
So
by
default,
everything
should
be
it's
not
enhancing
security.
A
A
If
you
want
some
boring
bedtime
reading,
like
almost
every
service
mesh
linker
d,
has
a
control
plane,
it
has
a
data
plane
right
and
that
that
data
plane
is
these
tiny
little
proxies
micro
micro
proxies
in
our
case
that
sit
next
to
your
application
that
intercept
the
calls
in
between
services.
So
when
a
talks
b
actually
talks
through
two
proxies
right,
it
talks
to
the
proxy
and
a
and
the
proxy
on
b,
and
because
of
that,
because
it's
handling
both
the
client
and
server
side,
linker
d
can
do
cool
stuff.
A
A
And
there
are
a
couple
variations
in
this,
but
this
is
very
similar
to
how
most
service
missions
work.
I
want
to
talk
briefly
about
the
kind
of
data
plane
side
of
things.
So
linkery
is
a
little
unique
in
the
service
mesh
world
and
that
we
do
not
use
envoy
envoy
is
a
cncf
project.
It's
a
proxy!
It's
great
used
widely
in
production,
linker
d
uses
something
that's
simply
called
linker
d2
dash
proxy.
A
As
you
can
imagine,
it's
not
a
general
purpose
proxy.
Like
envoy,
you
can't
take
it
out
and
kind
of
run
it
outside
of
lincoln.
It's
specifically
designed
for
the
service
mesh
use
case,
which
actually
is
quite
different
from,
like
the
general
purpose
use
case.
So
because
we
have
this
kind
of
dedicated
proxy,
we
can
accomplish
a
lot
of
what
we
want
to
do
with
with
linkerview.
A
A
Of
course,
we
do
have
regular
third-party
security
audits
for
the
data
plan,
especially
thanks
to
the
cncf
and
it's
built
on
this
very
modern
asynchronous
network
stack
kind
of
the
state-of-the-art
networking
and
in
the
rust
ecosystem
projects
like
tokyo
and
hyper
and
h2
and,
of
course,
like
all
of
linkedin
100,
open
source
and
100
awesome,
and
so,
if
you
are
ever
interested
in
learning
what
state
of
the
art
rust
network
programming
looks
like.
Please
come
check
out
that
repo
and
we'd
love
to
have
you
get
involved.
A
A
This
is
now
about
a
year
old,
so
there
have
been
a
couple:
different
versions
of
of
linker
d
and
sdo
since
then,
and
we're
going
to
try
and
update
this,
but
at
least
as
of
kubecon
eu
last
year,
a
huge
difference
in
performance,
I
think
largely
in
part
to
the
kind
of
micro
proxy
that
we
use
but
of
course,
still
still
more
expensive
than
not
using
a
surface
mesh
at
all.
Right,
you're
always
going
to
pay
a
cost.
So
we
want
to
minimize
that
cost.
A
We
want
to
give
you
the
features
and
maximize
the
features
and
minimize
the
cost.
I
guess
so.
If
you
search
for
kinvoke
benchmarks,
you
will
get
all
the
gory
details
there
and
then
kind
of
the
most
recent
set
of
content
or
a
set
of
features
that
we've
been
focusing
on.
Is
this
idea
of
multi-cluster
communication,
so
linker
d
actually
provides
this
kind
of
seamless,
secure
communication
in
between
pods
right.
So
I
mentioned
already.
A
I
mentioned
that
you
know
the
moment
that
you
install
linker
d
tls
is
enabled
in
between
meshed
pods,
at
least
if
they're
speaking
http,
it's
enabled
automatically,
and
you
don't
have
to
do
anything.
That's
part
of
that
right.
I
think.
If
we
go
back
to
our,
let
me
go
back
to
the
architecture
diagram
you
can
see
in
there
there's.
Actually
this
little
thing
called
the
certificate
authority,
which
is
gonna
issue
certificates.
It's
gonna,
send
those
to
the
proxy,
so
proxies
are
know
what
to
do
with
them.
A
It's
going
to
rotate
them
every
24
hours,
they're
going
to
be
tied
in
terms
of
tls
identity
to
the
kubernetes
service
account
of
the
pod
itself.
So
we
have
this
really
nice
kind
of
zero
trust
model
where
the
pods
themselves
are
enforcing
security
boundaries
and
both
ensuring
not
just
confidential,
but
also
not
just
confidentiality,
but
also
also
authenticity
of
the
communication
between
them
right
and
so
with
linkard
2.8,
which
was
out
last
month.
Let
me
go
back
to
the
diagram
here.
A
We
extend
that
same
model
to
cross
cluster
communication.
So
if
you
are
ever
in
a
world
where
you
have
to
communicate
between
kubernetes
clusters,
it's
not
as
easy
as
it
should
be,
and
so
the
multi-cluster
features
in
2.8
kind
of
met
a
couple
design
goals.
The
first
was
we
wanted
to
have
a
unified
trust
domain
across
all
the
clusters.
What
that
means
is
we
wanted
the
the
same
kind
of
security?
A
You
know
mutual
tls-based
security
primitives
to
extend
to
this
communication,
because
that
communication
was
actually
going
to
be
happening
over
the
open
internet
right
and
we
wanted
to
have
we
needed
to
have
that
so
that
you
could
have
heterogeneous
cluster.
So
it
doesn't
matter
whether
the
clusters
are
in
different
networks,
different
cloud
providers
or
on-prem
or
not.
Everything
should
just
work
but
at
the
same
time
separate
failure
domain,
so
unified
trust
domain,
separate
failure
domain,
so
one
cluster
goes
down.
A
That
doesn't
mean
that
means
that
it
doesn't
require
other
clusters
also
going
down.
I
guess
I'll
put
it
that
way
and
providing
a
uniform
model
for
doing
this
communication
in
a
way
that's
transparent
to
the
application.
So
you,
as
the
application,
can
make
a
call
if
you're
a
and
I
want
to
talk
to
b,
you
make
a
call
to
b
and
you
are
actually
not
exposed
to
whether
that
is
a
local
service
or
remote
or
a
remote
service.
A
The
way
I
like
to
think
about
this
is
it
kind
of
comes
down
to
what
you
need
in
a
service
mesh
and
if
you
look
at
the
themes
of
the
two
projects
and
all
trying
to
characterize
this
in
as
gracious
a
way
as
possible,
you
know
there's
a
lot
of
features
in
this.
You
know
and
this
you
want
to
accomplish
a
lot
of
things
and
they
want
to
accomplish
it
in
a
lot
of
different
environments.
A
Linker
d
is
kind
of
takes
a
very
different
focus,
which
is
we
actually
want
to
do
the
bare
minimum?
We
want
to
do
the
bare
minimum
that
that
we
think
is
necessary
to
build
a
secure,
reliable,
zero
trust,
ready,
kubernetes
application,
so
our
focus
is
on
being
as
small
and
as
lightweight
as
possible
and
giving
you
just
a
bare
minimum
features
and
the
bare
minimum
kind
of
complexity
that
we
can
get
away
with,
while
still
accomplishing
that
goal.
A
We
also
focus
very
heavily
on
kubernetes,
so
it
is
apparently
not
even
possible
to
really
run
liquidity
outside
of
kubernetes.
You
can
obviously
make
calls
you
know
to
non-kubernetes
resources,
like
that's
a
fact
of
life
for
almost
all
of
us.
You
know
unless
we're
in
very
new
greenfield
environments.
A
That
also
means
that
we're
much
more
with
a
much
more
focused
feature
set,
so
we're
really
trying
to
do
just
the
things
that
we,
the
bare
minimum,
to
get
away
with
accomplishing
that
goal
so,
like
I
said,
happy
to
answer
more
questions
about
that.
Both
great
projects,
okay-
and
that's-
really
kind
of
the
end
of
this
introductory
session.
A
There's
a
lot
more
material
on
linkerd.io
we've
got
a
huge
number
of
documents
of
docs
and
tutorials
and
blog
posts,
and
there's
a
like.
I
said
a
thriving
community
of
us
in
the
slack
slack.link
or
d
to
I
o.
You
can
hop
in
there
and
ask
people
that
you
know
any
time
of
day
or
night.
There's
someone
in
there.
Well,
you
know.
Probably
someone
in
there
they're
ready
to
help
you
out.
We
do
have
a
set
of
mailing
lists
where
we
do
kind
of
formal
announcements.
A
We
have
monthly
community
calls.
Actually
the
one
this
month
is
happening
well
by
the
time
you
see
this,
it
will
have
already
happened,
but
the
august
one
will
be
happening
kind
of
last
wednesday
of
august
and
formal
third-party
security
audience
audits.
So
we
have
a
really
friendly
welcoming
community.
That's
one
of
the
things
that
I'm
really
proud
of
and
that
people
always
point
out
when
they
when
they
come
and
ask
us
questions.
A
So,
please
get
involved
and,
like
I
said,
I
want
you
to
consider
yourself,
a
member
of
the
community
just
as
much
as
I
am.
This
is
a
community
project,
it's
hosted
by
the
cncf
and
it
is
a
service
mesh.
That's
for
everyone.
So
thank
you
very
much
again.
My
name
is
william
morgan
and
please
ask
me
some
questions.
A
Right
cool:
well
now
you
are
getting
the
live,
william!
You
can
tell,
because
the
live
volume
has
a
hat.
Okay,
it
looks
like
we
got
about
10
minutes
for
questions
which
is
great,
and
I
see
a
whole
bunch
of
questions
in
here.
I'm
going
to
answer
the
ones
that
pop
out
at
me
as
I
go
through
this,
but
afterwards
I'm
going
to
be
hanging
out
in
the
slack
the
cncf
slack.
A
There's
a
two
dash
kubecon
dash
maintainers
slack
room
so
feel
free
to
join
me
there
and
I'll
continue
this
conversation,
even
after
the
official
q.
A
period
is
over.
So
let
me
go
through
and
answer
a
couple
of
these
questions.
So
first
thanks
for
for
joining
me
for
this.
I
know
the
virtual
format
is
like
a
little
funny,
but
I'll
do
my
best.
Okay,
so
alec
asks
if
the
need
arises
to
change
from
one
service
mesh
to
another.
Do
you
need
to
rewrite
everything,
or
can
you
convert
or
migrate
easily?
A
I
think
it's
a
really
good
question.
The
answer
is
a
little
different
for
for
different
service
meshes,
I
think,
for
better
or
for
worse.
It's
easy
to
rip
lingerie
out,
because
kind
of
the
whole
point
of
you
know
lingerie
is
that
we
do
all
the
stuff
without
you
having
to
change
your
application.
So
you
know
certainly
from
the
code
change
perspective
you
can
pull
it
out
and,
like
you,
shouldn't,
have
to
change
anything
beyond
that.
I'm
hoping
that
you
know
once
you
do
that
you'll
realize.
A
Oh,
my
gosh,
you
know
all
the
tls
and
load
balancing
whatever's
actually
making
things
really
good
for
us.
But
I'd
say,
generally
speaking,
the
point
of
the
service
mesh
is
to
be.
You
know,
kind
of
decoupled
from
the
application.
So
hopefully
it
shouldn't
be
too
hard
to
move
from
one
to
the
other,
so
alec,
hopefully
that
answers
your
question.
A
Martin
asks
a
really
good
one.
Yes,
what
are
commonly
requested
features
that
linker
d
does
not
have
plans
to
implement
that
doesn't
have
or
doesn't
have
plans
implement.
So
that's
yeah,
that's
that's
great
I'd,
say
one
common
set
of
features
we
get
asked
for
are
things
that
belong
on
ingress,
so
linker
d
does
not
ship
with
an
ingress
layer.
We
instead
ask
you
to
like
install
one
of
the
seven
hundred
different.
You
know
great
ingress
projects,
so
things
like
I
saw
there
was
another
question
around.
A
Oh,
I
dc
connect
and
things
like
that.
Those
are
all
handled
at
ingress
and
you
know
I
don't
want
linker
d
to
do
ingress,
there's
already
so
many
good
projects
for
doing
that.
So
that's
one
common
example:
we
actually
resisted
distributed
tracing
for
a
long
time
because
I
was
like
this
doesn't
really
fit
into
the
service
mesh.
You
can't
do
distributed
tracing
in
a
way
that
you
know
involves
no
code
changes,
but
eventually
we
gave
up
and
implemented
that.
A
A
Okay,
so
let's
see
I'm
gonna
run
through
some
of
these
other
questions
here,
alejandro
asks:
how
can
someone
write
integrations
for
linker
d2
dash
proxy?
Are
you
planning
on
providing
proxy
was
on
filter
support?
That's
a
really
good
question
yeah,
so
you
know
link
rd1.x.
I
didn't
really
talk
about
this
in
the
too
much
in
this
intro
session,
but
you
know
the
original
version
of
linkedin
was
on
the
jvm.
A
A
Okay,
so
let's
take
a
look
here,
will
spiffy
be
taken
on
in
the
near
future?
This
is
a
question
from
rio.
Will
spiffy
be
taken
on
the
near
future
for
the
identity
system,
with
their
svids?
We've
been
looking
at
the
spiffy
project
so
far.
We
it
hasn't
been
compelling
enough
to
really
bite
the
bullet
and
implement
it.
The
way
we've
done
identity.
A
You
know
in
in
in
linker
d,
with
all
the
mtls
stuff
so
far
as
we
tie
it
to
service
accounts
and
we've
avoided.
I
think
a
lot
of
the
problems
that
spiffy
solves
by
not
having
a
great
mesh
expansion
story,
so
you
know
we've
kind
of
avoided
it
so
far,
but
I'd
say
generally
speaking,
it's
something
that
we
are
aware
of,
and
you
know
probably
will
be
a
topic
of
discussion.
So
thank
you
for
that
question.
Rio.
A
Yeah.
It's
a
very
interesting
question
from
vim
who
asks?
Can
linker
d
also
communicate
with
other
service
meshes?
Well,
I
mean
yeah,
it's
like
it's
all
network
calls,
so
you
could
run.
You
know
linker
d
on
one
cluster
and
istio
in
another,
and
you
know
something
else
on
a
third
and
you
know
they're
all
talking
to
each
other,
so
I
guess
at
the
at
the
basic
level.
A
Yes,
you
know
you
won't
have
the
like
mtls
stuff,
working,
probably
in
a
really
unified
way
like
you'll,
have
to
treat
this
as
like,
like
the
cross.
Cluster
communication
will
have
to
be
done
like
through
ingress
or
something
I
don't
know.
You'd
have
to
treat
these
all.
I
guess
it's
like
external.
That's
like
separate
clusters,
which
is
a
little
different
from
like
you
know,
if
you're
running
linkery
multi-cluster,
but
yes
at
its
heart,
you
can
communicate
with
other
service
meshes.
A
A
Rio
rio
asks
will
mtls
for
tcp.
Be
supported,
yes,
yes,
that's
the
headline
feature
in
the
2.9
release,
which
is
the
next
release
expected
this
year.
So
all
of
the
fancy
mtls
stuff
that
I
talked
about
so
far
is
on
by
default
for
http
traffic
grpc
traffic.
But
if
you're
doing
something
like
kafka
or
postgres
or
something
that's
not
http,
then
currently
we
can't
do
mtls
until
299
chips
and
then
we
should
have
that
all
sorted
out.
So
thank
you,
rio
for
that
question.
A
A
Sometimes
things
like
the
way
you
have
your
security
policies
and
stuff
configured
makes
it
harder
to
install
linker
d,
but
we
have
this
command
called
linker
d
check,
dash
dash
pre,
and
if
you
run
that
it
will
validate
against
the
cluster
kind
of
that
it
has
everything
that
it
needs
and
that'll
cover,
like
95
percent
of
the
cases.
So
if
you
have
a
open
shift,
v4
cluster
out
there
run
linker
d
check
pre
against
it
and
it'll
tell
you
exactly
what
will
happen
if
you
try
and
install
liquidity.
A
All
right,
so
thank
you
for
that
question.
Let's
see
what
else
we
have,
how
cumbersome
so
gordon
asks
how
cumbersome
or
not
is
it
to
debug
issues
that
may
pop
up
inside
of
liberty?
That's
a
that's
an
excellent
question,
one
of
the
first
things
that
happens
when
you
install
a
service
mesh.
You
know,
if
you
ever
do
this
in
your
own
company-
is
that
everyone
starts
blaming
you
whenever
something
goes
wrong,
like
hey
who's,
this
idiot
who
installed
the
service
mesh.
A
So
we
provide
a
bunch
of
tools
for
understanding
the
state
of
linguity
so
that
when
you
know
the
angry
mob
is
outside
your
your
gate,
you
know
asking
what's
going
on,
you
can
actually
defend
yourself,
so
you
know
the
first
thing
is:
we've
got
tools
like
linkery
check
and
and
so
on.
The
dashboard
liquidity
dashboard
itself
shows
you
exactly
what's
happening
on
the
in
the
control
plane
and
you
know
the
status
of
everything.
A
Actually,
the
control
plane
is
running
on
the
data
plane,
which
means
that
the
same
tools
we
give
you
around
metrics
observability,
mtls
and
everything
for
your
applications.
Actually,
you
can
use
those
for
the
control
plane
itself,
so
we
basically
try
and
make
it
as
easy
as
possible
to
understand
the
state
of
the
link
or
d
control
plane,
because
that's
a
big
part
of
the
operational
burden
right,
you
don't
just
install
it
and
then
you're
like
okay,
everything
works
and
things
do
break
and
you
have
to
understand
where
that
problem
is.
Is
it
somewhere
in
kubernetes?
A
A
Okay.
Let's
see,
I
think
we
probably
have
time
for
one
or
two
more
so,
let's
run
through
here,
so
lefteris
asks
looking
at
the
getting
started
guide.
Okay,
so
if
you
go
to
link
or
dot
io
click
on
getting
started,
there's
a
like
five
step
walk
through.
Do
I
need
to
manually
attach
link
or
d
to
each
application
or
just
apply
it
to
a
current
cluster
and
it
works
yeah.
So
the
way
it
works
is
it's
kind
of
a
two-step
process.
A
First,
you
install
the
control
plane
once
you
install
the
control
plane
like
nothing
is
happening.
Besides,
you
know
like
it's
sitting
there,
then
you
mesh
your
application
right
and
mesh
means.
You
add
the
data
plane
and
in
order
to
do
that,
you
can
do
that
like
one
service
at
a
time,
you
can
even
do
it
one
pod
at
a
time
if
you
want,
but
that's
what
actually
activates
the
service
mesh
for
that
application.
A
So
you
have
this
way
of
doing
things
incrementally,
so
you
know
you
said
it
manually
isn't
manually,
you
know
you
can
do
it
in
a
variety
of
ways.
We
use
annotations
and
proxy
auto
injections.
So
if
you
can
read
about
the
docs,
but
basically
you
can
do
it
in
an
incremental
way.
So
hopefully
that
makes
sense
left.
Terrace.
Okay
sounds
like
we're.
A
Basically,
out
of
time,
we
have
to
view
a
sponsor
message
at
this
point,
so
we'll
take
a
little
commercial
break,
but
once
again
I'll
be
on
the
slack
channel
at
2-coupon
maintainers.
So
please
hit
me
up
there
I'll
be
hanging
out
for
the
next
15-20
minutes
and
thank
you
for
attending
the
linker
d.
Intro
talk,
I
really
appreciate
it.