►
From YouTube: CNCF Webinar: What's New in Linkerd 2.9: mTLS for all TCP connections, ARM support, and more
Description
The Linkerd 2.9 release is a huge milestone for fans of zero-trust security: it extends Linkerd's zero-config mutual TLS (mTLS) support to all TCP connections. This means Linkerd can encrypt and authenticate all TCP connections in the cluster the moment it's installed, including automatic certification rotation and strong guarantees of pod identity. The 2.9 release also adds ARM support, introduces a new multi-core proxy runtime for higher throughput, adds support for Kubernetes service topologies, and lots, lots more.
Join this webinar to hear from Linkerd creator Oliver Gould directly about what this means for the CNCF's most popular service mesh project. You'll learn how:
- Linkerd performs encryption and authentication to the pod boundary, providing "encryption in transit" in a modern, zero-trust form.
- The new multi-core proxy runtime further improves performance over Linkerd's already lightning-fast latency profile
- Linkerd's new service topology support can provide significant performance improvements and cost savings for Kubernetes applications
- What the future of Linkerd holds!
A
Okay,
I
want
to
thank
everyone
for
joining
us.
Welcome
to
today's
cncf
webinar.
What's
new
in
linkard,
I'm
libby
schultz
I'll
be
moderating
today's
webinar
and
we
would
like
to
welcome
our
presenter
today.
Oliver
gould
linkard,
ceo
excuse
me
a
few
housekeeping
items
before
we
get
started
during
the
webinar
you're,
not
able
to
talk
as
an
attendee
there's
a
q,
a
box
at
the
bottom
of
your
screen.
Please
feel
free
to
add
your
questions
there,
not
the
chat,
the
q
a
and
we'll
get
as
many
in
as
we
can
at
the
end.
A
B
Thanks
lindy
so
before
I
dive
into
this,
if
you
can
figure
out
how
to
give
me
a
reaction-
and
I
just
want
to
see
if
you
can
give
me
a
thumbs
up
in
the
in
zoom
before
I
go
on,
are
you
alive
there?
Are
you
able
to
direct
yeah?
We
get
some
hands
there.
Thank
you
great
okay.
So
before
I
dive
in
how
many
of
you
are
actually
running,
kubernetes
in
production
give
me
a
hand
if
you
are
cool.
B
Okay,
great!
We
still
got
a
few
excellent.
That's
what
I
like
to
see
well,
my
hope
today
is
that
if
you
haven't
used
linkedin
before
that,
this
talk
gives
you
enough
to
get
started
and
understand
what
problems
it
solved
and
how
it
works,
and
if
you
have
used
linkedin
before
I
hope
this
will
be
an
invite
to
get
more
involved
in
the
community
and
contribute
in
one
of
many
ways.
So
with
that,
my
name
is
oliver
gould,
I'm
the
creator
of
linker
d.
B
I've
been
working
on
this
for
the
past
few
years
and
the
talk
will
basically
start
with
a
brief
overview
of
linkedin
service
meshes
and
what
they
do
I'll.
Take
you
through
a
tour
of
link,
reduce
features,
and
then
I
will
get
to
the
good
stuff
we'll
get
to
a
demo
and
then
have
some
questions
after
that
great
so
linker
d
has
been
around.
We've
been
working
on
it
since
2015.
B
I
believe,
and
it's
been
production
for
over
four
years
now.
We've
got
a
really
active
community.
Many
of
you
already
in
the
slack
that
are
already
dealing
with
us
in
github,
and
we
really
appreciate
that
and
we've
been
in
production
with
a
whole.
You
know
wealth
of
different
types
of
companies,
very
small,
very
large,
big
traffic,
small
traffic.
Everything
and
we've
been
part
of
cncf
since
early
2016,
if
I
recall
correctly,
but
we've
been
in
cncf
for
a
long
time,
and
that
means
we're
committed
to
open
governance.
B
B
First
modern
microservices
of
all,
so
this
is
of
course
with
mesos,
because
kubernetes
was
around
yet,
but
a
lot
of
the
same
problems
and
primitives
was
there
and
I
was
on
call
for
service
discovery
and
traffic
management
and
a
lot
of
the
kind
of
core
concepts
that
link
these
deals
with
and
then
in
2016
we
we
launched
linker
d
1.0,
which
was
a
jvm
based
proxy
and
it
wasn't
kubernetes
specific.
It's
super
super
generic
can
be
tied
together,
mesos
and
console
and
kubernetes
and
all
sorts
of
things.
B
But
over
time
we
learned
that
the
that
kind
of
heavyweight
flexibility
wasn't
really
a
good
suit
for
kubernetes,
and
so
we
created
a
new
version
of
linkedin
too,
which
is
really
lightweight,
meant
to
just
get
up
and
running
and
really
tied
to
kubernetes
tightly,
and
that's
really.
What
I
want
to
talk
about
today
is
that
that
new
version
of
linkery,
which
has
been
around
since
oh,
I
don't
know
2018,
is
when
it
became
32..
B
We've
been
working
on
this
since
probably
2017,
sometime
lingerie
out
of
the
box,
give
you
three
kind
of
core.
You
know
polls
of
value,
first
being
observability,
it
can
be
really
hard
to
understand.
What's
going
on
in
your
cluster
cube,
cuddle
is
great,
but
it
can
tell
you
whether
things
are
up
or
down.
They
can't
tell
you
if
things
are
slow
or
fast
or
if
they're
failing
requests,
that's
kind
of
very
decoupled
from
the
kubernetes
ecosystem,
and
we
also
have
support
for
tracing
and
I'll
get
into
more
of
that
later.
B
The
other
big
thing
we
do
is
connectivity
and
so
load
balancing
timeouts
routing
connecting
clusters,
making
sure
that
a
pod
can
talk
to
another
pod
or
another
service
is
a
big
part
of
what
he
does
and
we
do
that
securely.
We
do
that
with
mtls
by
default
for
everything,
and
we
integrate
with
projects
like
cert
manager,
which
is
just
admitted
as
a
cncf
project,
congrats
to
manager
and
I'll
get
into
more
of
these
details.
Later.
B
Let's
start,
though,
with
microservices,
I
assume,
most
of
you
are
basically
familiar
with
microservices,
but
just
to
kind
of
lay
the
groundwork.
Microservices
are
you
know
contrast
with
what
we
had
before
then
they're
kind
of
the
lamp
stack
and
that
we've
taken
what
used
to
be
a
bunch
of
library
interactions
and
this
kind
of
linking
and
put
that
over
the
network,
and
so
now
we
can
separate
business
logic
over
the
network
and
things
call
each
other
via
apis.
B
The
service
mesh
is
a
way
to
add
rich
operability.
The
things
we're
just
talking
about
as
a
side
car
to
this,
so
you
don't
have
to
embed
this
in
a
library
in
your
code.
Of
course
you
can,
but
it's
about
having
a
proxy
that's
able
to
do
take
on
a
lot
of
these
concerns
outside
of
your
application,
so
you
can
have
it
uniformly
depending
on
you
know,
regardless
of
what
application
stack
you're
using
whether
the
homogenous
or
heterogeneous
a
service
mesh
can
make
that
you
know
uniform
and
work
well.
B
This
is
all
powered
by
a
control
plane,
and
so
you
have
a
kubernetes
control
plane,
which
is
the
kubernetes
api
server
and
its
extensions
and
linkery
provides
a
set
of
control
plane
apis
that
are
interact
closely
with
the
groupenetics
apis
to
power,
the
proxies
so
in
linkerid
itself,
the
proxy
is
basically
unaware
of
anything
having
to
do
with
kubernetes.
It
only
knows
about
the
control
plane,
api.
The
control
plane
itself
is
very
tightly
coupled
to
kubernetes.
B
This
kind
of
looks
like
this
right.
We
have.
These
proxies
are
ejected
sidecar,
so
it
within
your
pod.
We
add
a
container
to
your
pod,
which
is
the
proxy
that's
done
by
a
control
plane.
Web
hook
called
the
proxy
injector.
Also
in
the
control
plane,
we
have
a
certificate
authority,
which
is
the
proxy
uses
to
establish
identities.
B
We'll
get
into
more
of
those
details
later
and
then
we've
we've
built
the
proxy
in
rust.
We've
built
most
of
the
control
plane
in
go.
We
ship
up
an
instance
of
prometheus
and
grafana.
By
default
we
have
great
helm,
charts,
we
support
smi,
we're
a
big
part
of
the.
You
know
we're
big
fans
of
the
cncf
ecosystem,
and
so
we
really
try
to
leverage
as
much
of
that
ecosystem
as
you
can
that's
not
in
our
core
competency.
B
Our
goal
is
to
do
this
without
adding
complexity,
so
kubernetes
itself
is
complex
and
that's
really
what
we
find.
No
one
should
want
to
adopt
a
service
mesh.
Most
people
need
are
having
enough
trouble
just
to
adopt
kubernetes
and
linguity
is
meant
to
just
kind
of
get
installed,
get
out
of
your
way
and
then
grow
with
you.
As
you
have
more
problems
that
you're
trying
to
solve.
We
really
don't
want
you
to
try
to
solve
all
of
the
traffic
problems
on
day,
one
that
should
be
an
incremental
path.
B
B
Part
of
our
goals,
for
simplicity,
are
that
we
don't
try
to
invent
new
abstractions
that
are
specific
to
linkedin.
We
really
embrace
kubernetes,
primitives
and
sometimes
to
a
fault
I
would
argue,
but
we
really
don't
want
you
to
have
to
introduce
new
types
of
abstractions
that
you
have
to
think
about
and
manage.
We
really
try
to
use
things
that
are
already
well
understood
and
well
supported,
and
we
try
to
do
that
securely
by
default
and
we'll
we'll
show
more
examples
of
this
later.
B
B
B
The
proxy
is
to
one
of
the
biggest
questions
we
get
is
does
linker
to
use
envoy,
and
the
answer
is
no.
I
know
we
really
have
tailored
our
proxy
to
the
service
mesh
use
case.
It's
not
a
generally
configurable
proxy
there's,
no
config
file
that
you
can
go
change,
how
the
proxy
works
or
add
plugins
to
it
today,
and
that's
one
for
simplicity,
two
for
for
minimizing
resource
overhead
and
three
for
security.
B
We
find
that
the
more
configurable
something
in
this
kind
of
critical
part
of
the
stack
is
the
harder
it
is
to
audit
the
harder
it
is
to
gain
confidence
about
being
secure.
So
we
really
try
to
minimize
the
flexibility
of
the
proxy
and
really
tailor
it
for
this
use
case.
For
these
reasons,
and
we've
had
this
audited
a
few
times
now,
we
basically
do
security
audits
once
a
year
and
things
have
been
going
really
well.
B
As
far
as
that,
we've
had
a
few
very
minor
issues,
but
nothing,
nothing
scary,
and
this
is
all
built
heavily
on
the
rust
networking
ecosystem
and
if
you
haven't
played
with
the
rust
stack
of
tokyo,
hyper
tonic
tower.
These
projects
are
really
exciting
and
we've
invested
heavily
in
them.
In
fact,
a
lot
of
the
proxy
code
has
been
forked
out
of
the
proxy
moved
upstream
into
these
projects,
and
so
we're
we're
big
fans
of
the
open
source
ecosystem
and
and
making
things
better
there.
B
So
the
single
sharpest
tool
in
our
tool
belt
is
little
load
balancer
and
so
every
proxy
implements
what's
called
a
peak
yuma
load.
Balancer
yuma
is
a
exponentially
weighted
moving
average
and
we
use
the
latency
of
individual
requests
to
inform
the
load
balancer.
So
there's
no
centralized
load,
balancer
state,
there's
no
single
load
bounce
you
go
to
every
s.
Every
pod
has
its
own
little
load,
balancer
embedded
in
that
proxy.
That's
making
its
own
latency
decisions
in
its
own
routing
decisions.
B
This
is
all
really
tightly
coupled
to
kubernetes
services.
So
we
don't
again
we
don't
add
new
primitives
there.
We
use
services
for
service
discovery,
which
means
we
benefit
from
things
like
service
topology,
and
I
think
I
saw
mate
in
the
the
list
here.
Mate
is
one
of
our
interns
this
summer
and
who
implemented
service
topology
support,
so
service
topologies
are
a
new
kubernetes
feature.
B
I
think
they've
just
been
available
since
118
or
119.,
and
it
allows
you
to
express
kind
of
node
affinity
and
things
like
that
or
you
know,
failure
zones
and
make
kubernetes
services
aware
of
that
and
now
linkerity
honors
that
stuff
as
well.
This
means
that
we
can
bypass
cube
proxy
and
again.
The
big
big
goal
here
is
that
you
can
just
add
this
proxy
to
your
application.
B
Here's
a
really
good
example.
I
don't
spend
too
much
time
on
here,
but
just
to
show
what
a
load
balancing
algorithm
can
actually
do
for
reliability.
If
we
use
something
really
naive
like
around
robin
balancer
and
we
let's
say
we're,
this
is
actually
a
test.
We
ran
where
there's
ten
instances
and
one
instance
is
slow.
It
has
a
two
second
latency.
Everything
else
is
quite
fast.
B
If
your
pager
goes
off,
and
so
I
really
do
think
that
the
the
load,
balancing
and
liquidity
is
maybe
under
touted
but
really
important
thing
that
it
does
one
of
the
the
probably
the
most
important
thing.
That
lincry
does,
though,
is
add
mutual
tls
to
all
measure
connections.
So
when
we
say
that
we
mean,
if
there's
a
proxy
on
two
pods
and
those
pops
communicate,
we'll
establish
mpls
for
that
mutual
tls
were
both
both
pods
identified,
identify
themselves
to
each
other,
and
we
have
a
secure
connection
there.
B
B
You
can
use
things
like
cert
manager
to
bootstrap
this
and
help
manage
that
ca
and
also,
if
you
already
have
tls
and
for
your
infrastructure,
linkerdy,
will
work
with
that
transparently.
We
won't
add
a
new
layer
of
tls
to
that
necessarily,
but
we
will
let
that
pass
through
as
tcp
traffic
and
up
until
two
nine,
so
linker
d,
two
eight,
for
instance,
only
supported
mtls
for
http
communication.
B
I
was
two
nine
we've
added
support
for
both
the
load,
balancer
and
mutual
tls
for
almost
all
tcp
traffic,
there's
some
classes
of
pcp
traffic
that
doesn't
apply
to
yet
but
we'll
be
fixing
that
in
210
and
that's
really
exciting.
Actually,
that's
the
big
thing
we
did
in
two
nights:
here's
my
favorite
linguity
feature
and
I
don't
think
this
is
any
in
any
other
service
mesh
you'll
have
to
check
with
them.
B
I
haven't
really
done
my
research
there,
but
this
is
something
we
specially
designed
in
delinquity
and
that
we
do
protocol
upgrades
between
proxies,
and
so
this
is
a
hand-drawn
diagram
I
did
earlier
today,
but
if
you
have
h21
communication
and
you're
doing
many
requests
at
once,
let's
say
you're
doing
a
thousand
concurrent
requests
from
a
pod
to
another
set
of
pods
that'll
be
a
thousand
tcp
connections.
One
per
you
know,
request
that's
active
and
with
hp2
multiplexing.
B
Another
feature
we
implemented,
I
think,
probably
about
a
year
ago-
now
is
traffic
splitting,
and
this
is
basically
stochastic
weighted
routing
and
a
popular
tool.
Flagger
can
be
used
to
drive.
This
basically
says
if
you
have
multiple
services
that
you
want
to
send
traffic
to.
Well,
you
can
wait
between
them
and
say
I
want
twenty
percent
traffic
here
and
eighty
percent
of
the
traffic
there
and
the
link
candy
will
on
to
that,
and
I
can
show
this
off
in
a
demo
again.
B
This
was
something
that
only
worked
with
http
traffic
until
two
nine
and
as
of
the
two
nine
release,
we
now
support
this
for
tcp
as
well.
Now
it's
at
the
connection
level.
We
can't
be
any
smarter
than
that,
but
it
is
it's
really
a
convenient
tool,
especially
for
multi-cluster
routing
this.
The
service
mesh
interface
is
a
project
that
was
initially
sponsored
by
folks
at
azure
and
we've
been
heavily
involved
in
it,
and
most
of
the
other
service
meshes
have
been
heavily
involved
in
it
and
it
provides
basically
three
core
apis.
B
Another
is
a
telemetry
api
to
smi
metrics,
which
is
really
just
a
uniform
set
of
metrics
that
will
work
with
any
service
mesh
and
then
there's
a
policy
api
as
well-
and
this
is
another
crd
that'll.
Let
you
just
express
policy
linkery,
doesn't
support
the
policy
api
yet
and
we're
working
on
revving
that
api
with
those
folks,
so
that
we
can
support
it
in
a
better
way.
That's
probably
211,
so
not
in
the
next
release,
but
the
following
in
two
seven
I
think-
and
maybe
two
eight
in
the
last
release.
B
This
is
really
cool
and
it
works
really
well
with
traffic
split,
so
the
application
doesn't
have
to
know
about
where
a
service
is
hosted.
You
just
say
I
want
to
talk
to
the
foo
service
and
if
the
proof
service
is
actually
an
east
cluster,
you
can
make
that
all
totally
transparent
to
the
app
and
you
can
even
kind
of
do
weighted
shifting
and
things
like
that.
This
is
great
because
there's
no
single
point
of
failure
here,
we're
not
going
through
any
kind
of
centralized
load,
balancer,
there's
no
special
network
requirements.
B
Cool
another
reason
that
we
focused
on
implementing
our
own
proxy
was
that
we
really
wanted
to
have
an
excellent
prometheus
experience
and
I
think
it's
gotten
better
over
the
last
year
or
so,
but
for
a
long
time
on
voice
from
atheist,
instrumentation
was
really
is
difficult.
Envoy
started
with
a
statsd
push-based
model
and
we've
taken
another
approach,
which
is
to
use
a
lot
of
the
kubernetes
metadata.
So
the
deployment
you're
talking
to
the
surface
account,
but
that's
part
of
the
the
pod
name,
all
sorts
of
labels
for
that
pod.
B
B
This
also
we've
extended
to
work
with
open
api
or
swagger
specs,
as
well
as
your
pc.
So
you
can
take
those
route,
definitions
and
import
them
into
linkedin
and
have
all
that
information
show
up
in
your
linkedin
metrics
as
well.
Again,
there's
no
configuration
necessary.
Those
swagger
and
protobuf
enhancements
do
take
some
configuration,
but
we
just
try
to
make
this
work
out
of
the
box.
You
don't
have
to
do
any
configuration
we
ship
from
prometheus
by
default
and
you
can
get
run
up
and
running
in
two
nine
you're
also
able
to
bring
your
own
prometheus.
B
B
We
get
a
lot
of
folks
asking
for
distributed
tracing
with
open
census
or
wind,
telemetry
and
linguity
can
work
in
that
world
as
well,
but
the
dirty
secret
about
distributed
tracing
is
that
you
actually
have
to
change
your
application.
Integrate
with
this
there's
no
way
that
we
can
do
this
totally
transparent
to
the
application.
So
if
you
have
tracing
set
up
in
your
ecosystem,
linguity
will
emit
spans
and
tell
you
you
know
where
you're
hitting
hops
in
linker
d
in
the
service
mesh.
B
B
Query
proxies
directly
and
say:
show
me
metadata
about
the
traffic-
that's
going
through
you,
so
this
isn't
aggregated
in
the
metrics
form
where
you
already
know
what
you're
looking
for
this
can
be
done:
kind
of
in
the
discovery
or
exploratory
mode.
That
does
mean
that
your
your
headers
and
all
sorts
of
private
information
can
be
exposed
by
this
api,
and
so
this
is
all
locked
down
with
our
back.
You
can
set
role
bindings
to
make
this
much
more
locked
down.
B
Okay,
then
there's
a
few
more
things
in
q9
that
I
haven't
even
talked
about.
Yet
one
of
the
bigger
ones
was
a
summer
of
code
project
that
added
multicharge
builds.
So
now
you
can
use
linkedin
on
your
raspberry
pi
clusters
or
your
gravitron
clusters,
if
you're
in
aws,
so
with
arm
taking
on
a
lot
more
importance
in
the
world
and
being
much
more
power
efficient.
B
As
I
mentioned,
mckay
added
service
topology
support.
This
also
means
that
we
now
support
the
new
kubernetes
endpoint
slices
api.
The
endpoint
slices
api
is
designed
to
allow
your
clusters
to
have
much
larger
services.
The
kubernetes
api
itself
could
get
very
slower
on
large
services
and
large
deployments,
and
so
we
support
those
new
apis
that
allow
those
things
to
be
more
efficient.
B
As
I
mentioned
just
a
second
ago,
we
allow
you
to
bring
your
own
prometheus
and
grafana.
So
if
you
already
have
those
things,
no
reason
to
install
a
second
copy
of
them
and
in
210
we'll
be
making
a
lot
of
these
components
very
optional,
where
they
get
installed
separately
and
then,
where
I
spend
most
of
my
time,
is
molinkini
proxy.
We
had
a
ton
of
changes
between
two
eight
and
two
nine.
We
basically
rewrote
the
entire
services
discovery
mechanism.
B
So
now,
instead
of
looking
at
post,
headers
and
headers
of
the
requests
we
defined,
we
do
all
discovery
based
on
the
ips
we're
talking
to.
So,
if
it's
an
ip,
we
know
it's
a
service
ip
and
we
can
do
load
balancing
based
on
that
or,
if
you're
talking
directly
to
a
pod,
we'll
just
forward
it
to
the
pod
without
doing
load
balancing-
and
this
means
that
we
can
work
well
with
ingresses.
B
We've
done
all
this
work,
basically
to
support
mtls
for
tcp
communication,
so
most
tcp
protocols
will
now
be
secure
and
load
balanced
and
routed
with
via
traffic
split
out
of
the
box.
The
protocols
that
doesn't
match
are
server
first
protocols,
so
things
like
my
sql
or
smtp,
where
the
where
the
server
speaks
first
to
the
proxy
or
to
the
client,
and
that's
because
we
do
protocol
detection.
There's
no
configuration
needed
to
tell
us
what
protocol
you're
speaking
for
the
most
part.
So
we
look
at
the
first
few
bytes
of
the
connection
we
say.
B
B
There's
a
we.
As
we've
been
getting
more
and
more
production
users,
we
had
some
people
doing
failure,
testing
and
realizing
that
it
could
take
linguity
a
while
to
reconnect
after
a
node
outage,
and
things
like
that-
and
this
was
actually
turns
out
because
of
coup
proxy
because
coup
proxy
itself,
which
is
the
eip
tables
based
service
discovery
and
load
balancing
scheme
which
kubernetes
ships
with
by
default,
can
actually
be
quite
slow
to
update
in
some
environments.
B
B
We
also
adopted
a
new
runtime
in
the
proxy,
so
previously
the
proxy
would
only
use
at
most
one
core.
We
only
ran
one
thread
for
the
proxy
and
this
is
great
for
most
applications
where
you
just
want
linkedin
to
be
small
and
get
out
of
the
way,
but
some
folks
want
to
push
50
000
requests
a
second
through
a
pod,
and
that's
going
to
be
really
hard
to
do
on
one
thread,
and
so
now
we
support
scaling
this
up
it.
On
there's
a
an
annotation
or
if
you
set
cpu
limits
via
a.
B
B
Big
motivators
for
us
is
to
have
the
lightest
footprint
we
can,
especially
in
the
proxy
okay.
I
finally
got
to
the
fun
time
I
have
enough
time
to
get
through
it.
I
think
so
I,
instead
of
giving
you
like
a
flashy
micro
service
demo,
where,
like
we've
done,
emoji
photo
in
the
past,
and
I
think
in
the
2
8
webinar
I
did,
we
did
multi-cluster
and
things
like
that.
I'm
actually
just
going
to
show
you
the
dev
environment
that
I
use
for
testing
a
lot
of
the
proxy
changes
and
lengthy
changes
in
general.
B
I'm
a
big
fan
of
k3d,
it's
much
like
kind
in
that
you
can
just
run
it
in
docker
on
your
host,
no
build
kubernetes
setup,
I'm
going
to
be
using
the
latest
lingerie
stable
release,
which
came
out
on
monday,
and
I'm
going
to
be
using
this
load
test
tool.
I
wrote
called
ort
might
change
its
name,
but
it's
really
just
a
a
client
which
generates
lots
of
requests.
Those
can
be
grpc
issue,
one
or
tcp,
and
we
have
a
server
that
supports
those.
B
This
is
what
we
use
for
testing
or
reproducing
bugs,
or
things
like
that,
and
so
without
further
ado.
Let's
see
if
I
can
show
you
what's
going
on
and
if
you
can't,
if,
if
this
responds
too
small,
just
shut
it
and
then
chat
and
I'll
try
to
fix
it
so
right,
instead
of
showing
you
how
to
set
up
a
k3d
cluster,
I've
already
set
that
up
and
I've
already
deployed
the
app
to
it.
B
So,
let's
install
linkerd
and
I'll
just
take
you
through
that
experience
really
quickly
so
before
we
actually
install
link,
we're
gonna
check
and
make
sure
the
cluster
is
ready.
You
know
if
I
had
to
kind
of
if
I
installed
link
it
previously
and
not
uninstalled
properly
or
if
there's
a
clock,
skew.
We
do
a
bunch
of
checks
just
to
make
sure
link
can
be
installed.
B
B
B
In
order
to
validate
the
lingerie's
coming
up
correctly,
we
can
use
the
lengthy
check
command
and
what
lengthy
check
does
is
it
again
runs
through
a
whole
bunch
of
common
problems
that
can
happen
during
an
install
and
validate
so
they
they
aren't
there
one
of
the
biggest
things
we
have
to
make
sure
all
the
pods
come
up.
So
we're
going
to
wait
for
all
the
pods
to
initialize.
This
will
take
hopefully
not
too
long
a
couple.
B
B
B
You
know
most
of
them
well
under
20
megs,
the
permeate
the
one
that's
running
with
the
prometheus,
which
talks
to
all
of
the
pods
in
the
cluster
is
a
little
bit
higher
there
running
around
20
megs,
okay,
so
I've
got
that
all
set
up,
and
now
I'm
gonna
upgrade
my
test.
So
don't
worry
too
much
about
this.
This
is
a
helm
chart.
I
use
for
configuring
different
topologies
to
test.
B
Let's
see
we're
going
to
run
at
most
three
requests
at
once:
per
load,
generator
we're
going
to
inject
linguity,
and
so
this
injector
linker
sitting
there.
What
it
really
does
is
just
add
a
single
annotation
to
the
the
pods
or
to
the
manifest
so
that
the
linguity
controller
can
know
to
inject
these
things.
So
by
default
we
won't
add,
link
created
things.
You
can
either
annotate
name
spaces
or
the
workloads
themselves
to
get
things
running,
and
so
that
will.
B
B
This
is
really
what
we
get
out
of
the
box
of
linkedin,
so
we
immediately
have
a
whole
bunch
of
metrics
about
what's
going
on
in
the
cluster,
so
we
can
take
a
high
level
look
at
the
name
spaces.
We
see
that
the
linker
do
name
space
and
the
oort
name.
Space
are
the
only
ones
injected
doing
around
2.5
000
requests
a
second
in
there,
which
makes
some
sense.
B
B
B
B
B
B
B
B
B
The
one
of
the
bigger
features
we're
working
on
for
210
is
really
focusing
on
minimizing
the
core
control
plane.
So
in
order
to
get
tls
service
discovery
and
load,
balancing
and
proxy
configuration,
which
are
the
really
what
you
need
to
run
the
surface
mesh,
we
want
to
minimize
stolen
premium
space
too.
So
only
those
core
concerns,
and
then
things
like
prometheus
and
grafana
and
tap-
are
going
to
become
an
extension
that
you
can
add
on
delinquity
with
a
single
command
again,
but
are
not
part
of
that
kind
of
core
control
plane.
B
B
Today
we
don't
do.
We
multi-cluster
only
supports
http
traffic,
and
so
the
big
thing
we're
gonna
do
for
for
that
in
for
multi-cluster
in
210
is
start
supporting
all
tcp
traffic,
including
server
first
protocols,
and
that
means
we'll
start
doing
mtls
for
those
protocols
as
well.
That
will
require
some
configuration
to
enable,
but
it's
not
it's
like
an
annotation.
It's
not
that
heavy.
B
B
B
That's
still
not
widely
supported,
called
bounded
service
accounts,
and
so
today,
every
pod
has
a
single
service
account
that
it
uses
for
everything
it's
going
to
use,
whether
it's
you
know,
modifying
kubernetes
resources
or
doing
identity,
provisioning
and
there's
a
new
beta
feature
that
allows
us
to
bound
service
account
tokens
to
different
uses.
So
what
we'd
really
like
to
do
is
have
short-lived
service
account
tokens
that
are
only
used
for
provisioning
identity,
so
they
can't
be
confused
with
other
things
that
you
might.
You
know
if
you
give
a
service
account
token
to
something
else.
B
You
can't
use
that
to
get
linkedin
identity.
Traffic
policy,
as
I
mentioned,
is
a
big
concern
that
we
have
we've
been
being
pretty
incremental
about
that.
The
goal
is
to
first
get
everything
to
be
tlsed,
get
that
to
be
multi-cluster
and
then
once
we
have
these
kind
of
core
connectivity
concerns,
we
can
start
to
think
about
policy
in
a
more
serious
way.
B
That's
a
big
part
of
what
I
think
differentiates
linkedin
from
other
service
meshes
especially
istio
is
we
haven't
started
with
all
the
features
and
tried
to
productionize
them
all
slowly,
we've
really
focused
on
being
production,
ready
and
incremental
in
our
approach
there.
So
that's
what
we're
going
to
do
for
traffic
policy
as
well.
B
There's
a
group
of
folks
outside
of
buoyant
that
are
very
eager
to
implement
pips
140-2,
for
this
basically
means
for
government.
So
if
you
want
to
use
linguity
and
government
applications
today,
our
rts
tls
implementations
are
not
validated
by
the
standard,
and
so
there's
some
folks
working
on
allowing
you
to
swap
out
the
tls
mutations
for
ones
that
are
validated.
B
You
can
of
course
talk
to
resources
that
aren't
in
the
kubernetes
clusters,
but
those
aren't
secured
and
managed
in
the
same
way,
and
so
we're
really
eager
to
allow
you
to
add
proxies
to
things
that
are
not
in
kubernetes,
so
that
we
can
support
that
use
case
as
well
and
finally,
there's
a
new
wasm
web
web
assembly,
which
is
neither
webinar
assembly,
api
called
proxy
wasm,
which
is
supported
by
envoy,
and
we
started
to
experiment
with
what
it
would
take
to
support
that
sort
of
thing
in
a
proxy.
I'm
still
a
little.
B
You
know
conservative
about
adopting,
leading
edge
technologies
like
that,
of
course,
I
think
from
a
security
point
of
view,
there
may
be
some
risks
there,
but
ultimately
this
means
that
you
might
be
able
to
write
plugins
in
any
number
of
languages.
Javascript
go
rust
and
have
them
just
dropped
from
the
proxy
and
work
without
having
to
change
proxy
code,
which
is
really
promising,
but
don't
let
that
stop
you
from
getting
involved
in
writing
proxy
code.
B
It's
important
to
call
out
that.
Not
all
contributions
to
linkedin
have
to
be
code
contributions.
We
have
a
community
anchor
program
where
we've
just
started
over
the
past
couple
months,
where
we
really
want
to
get
folks
in
the
community
who
are
getting
value
at
linkedin.
Solving
your
problems
with
it.
We
want
you
to
be
talking
about
that.
We
want
you
to
be.
B
And
finally,
it's
it's
a
community
project
right.
I've
said
this
many
times
today
and
it's
the
real
value
of
linkedin
is
that
we've
got
a
great
set
of
folks
who
are
always
adding
new
things
to
it,
who
are
helping
us
find
bugs
before
we
get
to
stable
releases,
and
so
you
know
folks
testing
edge
releases.
We
do
edge
releases
basically
every
week
and
stable
releases
about
every
two
months
or
so
this
last
one
is
a
little
bit
longer,
but
we'd
love
for
you
to
get
involved
on
github.
B
B
I
also
love
it
when
people
help
people
debug
each
other
debug
things
on
slack,
we
have
a
lot
of
new
people
coming
in
and
asking
questions,
and
it's
great
to
have
people
who've
already
been
there
to
answer
those
questions.
So
it's
not
just
a
few
of
us
all.
The
time
we've
got
mailing
lists.
We've
got
monthly
community
calls.
We
get
security
audits,
we're
we
love
the
scenes
except
ecosystem
and
what
it
affords
us.
So
with
that,
I
would
love
to
hear
what
questions
you
have
if
any.
B
B
The
next
question
is
with
the
t9
release
has
linked.
You
been
optimized
for
smaller
footprint
arm
devices
like
raspberry
pi,
it's
a
great
question.
Printing,
I
wouldn't
say
it's
been
totally
optimized.
We
haven't
spent
a
lot
of
time
in
the
arm
environment,
yet
it's
kind
of
experimental
at
this
point,
but
our
focus
in
general
has
been
really
lightweight,
and
so
you
know
we're
focusing
on
minimizing
the
control
plane.
So
you
have
a
very
lightweight
stall
footprint
there
and
also
the
proxies
themselves.
You
know
are
quite
small.
B
If
we
go
back
to
this
environment,
which
is
running
our
load
tests,
I
we
started
around
two
gigs
and
we're
still
under
three
gigs,
and
most
of
that
is
prometheus
right.
All
of
these,
the
largest
proxies
prometheus
proxy
at
28
megs.
Everything
else
is
20,
let
megs
or
lower,
which
is
really
really
lightweight,
especially
if
you
compare
to
some
of
the
other
service
meshes.
B
So
I
think
we'll
be
better
on
raspberry
pi
than
some
of
the
others
are,
but
there's
probably
more
work
to
do
there.
We'd
love
help
and
sanjay
also
asked
what's
the
plan
to
implement
authorization
rules
in
liquidity,
so
we're
targeting
something
like
the
smi
traffic
policy
apis
and
so
smi
has
a
traffic
policy
crd.
B
It
doesn't
quite
fit
our
model
of
the
world,
and
so
we
probably
probably
gonna,
submit
another
revision
and
work
with
them
to
rev
that
the
design
is
probably
kicking
off
in
december
in
earnest.
We
need
to
get
to
kubecon
and
get
some
of
the
210
work
in
flight,
but
we'll
start
designing
that
towards
the
end
of
the
year
and
once
210
goes
out,
we're
going
to
start
working
on
that
full
time
and
that'll
be
the
kind
of
big
feature
in
211..
A
B
Or
istio
we'd
love
to
hear,
what's
worked
well
for
you,
what
hasn't
worked
well,
john
said
that
I
said
that
multiplexing
computer
reduces
network
load.
I
think
this
is
reduced.
The
amount
of
ports
used
in
a
cluster
maybe
running
port
exhaustion.
It
definitely
can
reduce
the
number
of
raw
sockets
and
file
descriptors
and
epoxy
equipment
right.
So,
if
you
imagine,
because
we're
proxying
tcp
connections,
we
really
double.
B
If
you're,
if
we're
not
doing
anything
smart
here,
we
really
double
the
number
of
connections
in
a
pod
right,
because
we
have
to
terminate
the
connection
when
we
accept
it
and
we
have
to
establish
new
connections
on
the
way
out,
and
so
this
is
the
multiplexing
really
lets
us
work
around
that
cost.
It
means
one
that
we
have.
B
You
know
we
use
far
fewer
femoral
ports
on
the
outbound
side
and
on
the
inbound
side,
we,
you
know
not
really
doing
a
poor
exhaustion
on
the
inbound
side,
but
it's
a
similar
problem
there,
where
we
try
to
reduce
the
number
of
sockets
the
number
of
files
to
boost
the
proxy
use
and
as
we've
seen
in
testing,
that
can
really
have
an
impact
on
memory
consumption,
so
yeah
we're
our
goal
is
to
minimize
the
the
operating
system
resources.
We
need
to
do
these
things.
B
Does
lingerie
support
networked
policies
similar
to
calico,
or
should
one
just
use
calico
today
I
would
say
use
both.
So
I
think
you
know.
Security
and
depth
is
a
better
approach
than
just
having
one
layer,
and
so
it's
good
to
use
network
policies
where
you
really
want
to
enforce
where
traffic
can
go,
but
I
think
it's
also
important
to
use
things
like
mtls
for
for
kind
of
the
zero
trust
aspects
of
securing.
You
know,
communication
and
flight,
and
things
like
that
cms.
B
Can
we
segregate
traffic
between
namespaces,
for
example,
all
namespaces
can
talk
to
linkedin
insert
manager,
but
not
others,
ia
multi-tenant.
This
is
a
great
feature
request
and
I
think
it's
definitely
something
we're
going
to
approach
like
that's
definitely
a
use
case
for
us
to
consider
as
we
implement
traffic
policies.
This
is
you
know
an
obvious
type
of
policy.
You
may
want
to
express,
I
think
today,
the
way
to
achieve
that
would
be
through
a
layered
approach,
so
something
like
network
policy
is
layered
with
linguity
it's
on
the
roadmap.
A
B
B
Great
question
conrad:
I
believe
that
we
just
had
a
free
cncf
course.
Just
go
live
so
I
I
don't
have
dylan
candy,
but
yes,
there
is
coursework
it's
available
through
cncf.
I
believe
it's
free
and
it
should
be
focused
on
beginner
intermediate
for
sure,
a
good
question
from
jindong
about.
Is
there
a
downside
to
hp2
multiplexing,
and
so
it
can
add
latency
and
cpu
usage
in
some
cases.
So
it's
really
a
trade-off
between
the
kind
of
memory
footprint
and
the
socket
overlook
head
there
versus
some
cpu
and
a
little
bit
of
latency.
B
A
Okay,
thanks
so
much
oliver
for
a
great
discussion
and
a
great
presentation
and
q
a
that's
all
the
time
we
have
for
today.
Everyone
and
thanks
for
joining
us.
The
webinar,
recording
and
slides,
will
be
online
later
today,
and
we
are
looking
forward
to
seeing
you
at
a
future
cncf
webinar.
Everybody
have
a
great
day.