►
From YouTube: Overview And State Of Linkerd - Alex Leong, Buoyant
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. 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 - Alex Leong, Buoyant
Speakers: Alex Leong
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 recent adoption of the Gateway API and the many new features that move unlocks.
A
Hi
everyone,
this
is
overview
and
state
of
liberty,
so
welcome
so
I'm
going
to
start
with,
show
hands.
Sorry
to
do
this,
but
who
here
has
heard
the
word
service
mesh
before
should
be
everyone
because
I
just
said
it
who
who
could
explain
what
a
service
mesh
is
about?
Half
the
people,
maybe
who
has
used
a
service
mesh
before
more
people,
somehow.
A
Who's
using
a
service
mesh
in
production,
that's
still
a
good
number.
What
about
who's
using
Linker
D
in
production?
Still
still
pretty
good
I
have
to
ask
this
to
stroke.
My
ego
yeah.
So
speaking
of
my
ego,
my
name
is
Alex.
I
am
a
Lincoln
maintainer
I've
been
working
on
Linker
D
since
the
beginning
of
Liberty
I'm,
very
proud
to
be
part
of
the
project.
A
Liquidy
is
a
very
cool
project.
It's
used
by
a
lot
of
different
organizations
all
over
the
world
and
has
been
for
a
long
time.
It's
we
have
a
very
vibrant,
open
source
community.
So
if
you
ever
pop
into
the
Lincoln
slack
or
go
onto
GitHub,
you'll
see
lots
of
issues,
lots
of
pull
requests,
lots
of
activity,
people
helping
each
other
in
slack.
It's
it's
really.
It's
really
nice
we're
a
cncf
project.
We
are
a
graduated
project
and
we're
very
proud
to
be
there.
A
So
what
does
Linker
D2
so
link
ready
is
a
service
mesh
for
for
those
who
were
said,
they
were
not
able
to
explain
what
a
service
mesh
is
a
service
mesh
or
in
our
case
or
as
we
use
the
term,
means
that
there
is
a
sidecar
proxy
in
every
pod
or
in
every
pod.
That's
part
of
the
service
mesh
and
all
Network
traffic
for
that
pod.
A
A
A
What
is
coming
up
soon
on
the
roadmap,
but
I
want
to
get
through
all
of
that
kind
of
as
quickly
as
I
can
to
leave
a
lot
of
time,
if
possible,
for
questions,
because
I
really
want
this
to
be
a
little
more
interactive
and
to
hear
what
you
all
want
to
know
about
linkready
and
hopefully
answer
that.
So
if
we
get
to
the
end
and
there's
no
questions,
that
will
be
very
awkward
for
me.
A
Okay,
so
so,
what's
the
kind
of
the
philosophy
behind
Lincoln
Liberty
has
gone
through
a
couple
of
iterations?
There
was
a
previous
version
of
LinkedIn
called
link
ready,
one
which
was
written
on
the
jvm,
and
we
learned
a
lot
of
things
from
that.
It
was
very,
very
powerful,
very,
very
configurable,
and
while
that
was
really
awesome,
it
was
also
very
hard
to
use
and
a
lot
of
people.
You
know
who
are
trying
to
use
it
kind
of
had
the
experience
of
like
well,
you
know
what
we're
trying
to
do,
why?
A
Why
doesn't
it
just
work?
Why
do
I
have
to
configure
all
of
this
stuff,
and
so
we
took
a
lot
of
those
lessons
into
into
what
we
sometimes
call
Linker
D2
or
we've
kind
of
dropped.
The
two
which
is
called
Linker
D
now
and
the
idea
is
it
should
just
work
right
out
of
the
box
for
99.9
of
use
cases.
You
should
be
able
to
just
install
it
and
it
should
do
the
right
thing
and
you
know
anything
that
needs
user
input
or
needs
user
configuration
should
kind
of
come
after
that.
A
You
shouldn't
have
that
as
an
upfront
barrier
to
getting
started.
The
other
big
philosophy
that
we
had
for
this
project
was
for
it
to
be
really
really
lightweight
and
really
really
low
resource
utilization.
So
that's
why
we
wrote
a
proxy
from
scratch,
we're
not
using
Envoy
or
any
other
kind
of
off-the-shelf
proxy
for
link
review.
We
have
a
proxy
called
the
Linker
D2
proxy,
it's
written
in
Rust,
and
it's
designed
to
be
as
lightweight
and
fast
as
possible
and
operational.
A
Simplicity
has
kind
of
been
like
one
of
the
most
important
things
from
the
beginning
is
that
this
should
not
only
be
easy
to
get
started
with
and
easy
to
install,
but
also
easy
to
operate
over
time
and
easy
to
reason
about
and
easy
to
know
what's
happening
in
your
system
without
having
to
understand
a
lot
of
kind
of
black
magic
or
or
weird.
You
know
things
that
are
happening.
A
So,
like
I
mentioned,
we
use
a
specially
built
micro
proxy.
It's
very
boring
to
anyone
who
operates
it,
which
is
the
goal.
It's
called
the
link
52
proxy
and
it's
it's
something.
We're
really
proud
of
it's
kind
of
one
of
the
most
invisible
parts
of
the
service
mesh,
because
as
an
operator,
you
should
never
have
to
worry
about
it.
But
it's
got
some
very,
very
cool
technology.
Under
the
hood.
A
It's
it's
written
in
rust
on
some
like
Cutting
Edge
libraries
that
we
helped
develop
like
Tokyo
and
Hyper,
nh2
and
Tower,
and
you
know
because
it's
written
in
Rust.
We
get
a
lot
of
security
benefits
from
that
as
well.
We
don't
have
to
worry
about
certain
classes
of
memory
issues,
but,
as
I
said,
it's
like
the
philosophy
is
that
the
proxy
should
be
in
implementation.
Detail,
it's
not
something
that
we
ever
think
a
operator
should
have
to
worry
about.
A
So
that
means,
for
example,
when
we're
doing
mtls
all
of
the
mcls
identities
are
bootstrapped
from
kubernetes
service
accounts,
and
so
that's
kind
of
the
Primitive
that
we
we
build
everything
on
top
of
and
in
order
to
be
secure,
you
really
need
to
reduce
the
barriers
to
security,
because
security
features
that
nobody
uses
are
not
useful,
so
mtls
is
on
by
default.
There's
nothing.
You
need
to
do
to
configure
it
because
we
know
you've
got
a
service
account.
A
This
is
what
people
like
to
ask
us
about.
All
the
time
is:
what's
the
difference
between
Linker,
D
and
istio,
and
how
do
the
two
compare?
I
don't
want
to
go
through
all
of
these
points,
especially
because
these
two
projects
are
both
changing
at
rapid
Paces.
So
you
know
anything.
That's
true
here.
One
day
might
not
be
true.
The
next,
but
I
think
like
the
biggest
difference,
is
just
in
philosophy.
A
In
that
you
know,
the
link
ready
project
is
really
really
focused
on
operability
and
simplicity
rather
than
trying
to
satisfy
every
use
case
under
the
sun
and
I.
Think
that's
what
makes
it
easier
to
use
and
what
what
makes
people
have
more
confidence
in
it
and
it's
what
means
it
can
go
to
production
faster,
there's,
also,
a
lot
of
performance
benefits,
I
think
to
using
the
Lincoln
proxy.
We've
done
some
really
interesting
benchmarks,
which
you
can
look
up
if
you're
interested.
A
Okay,
so
what's
new
in
the
project
over
the
past
yeah
year
or
so,
solitary
211
was
a
really
exciting
release.
I
forget
when
this
came
out,
but
sometime
in
the
last
year-
and
this
is
when
we
first
added
server-side
authorization.
So
you
know
we've
had
mtls
for
a
long
time
which
has
given
us
authentication.
We
know
when
one
service
calls
another.
A
We
know
who
that
is,
they
have
an
identity,
that
identity
is
bootstrapped
from
the
service
account,
and
so
we
know
you
know
we
know
who
is
calling
who,
but
for
the
first
time
in
211,
we
gave
you
the
ability
to
restrict
who
you
would
accept.
Requests
from,
so
the
service
could
say.
I
would
only
like
to
accept
requests
from
this
other
service
or
I
would
only
like
to
request,
accept
requests
from
this
other
subnet.
A
So
we
introduced
a
new
resource
type
called
server.
This
lets,
you
define,
you
know
a
specific
port
on
your
workload
and
as
soon
as
you
have
a
server,
then
you
can
start
to
Define
authorizations.
To
say
here
are
the
identities
which
are
allowed
to
access
this
server
and
that's
all
enforced
on
the
server
side.
So
it's
very
secure
and
again
because
we
have
the
sidecar
model
where
we
have
proxies
inside
the
Pod.
Each
pod
kind
of
becomes
its
own
trust
barrier
and
it
can
say
it
can
decide
for
itself.
A
There
were
a
bunch
of
other
things
in
that
release,
which
were
really
exciting.
Specifically,
a
grpc
retries
was
something
that
was
long
term
coming
a
long
time
coming,
so
we've
had
retries
and
Linker
D
for
a
long
time,
but
they've
been
very
restricted
in
type
in
terms
of
what
types
of
requests
can
be
retried
so,
specifically
anything
with
a
body.
We
were
never
able
to
retry
before
because
we
would
have
to
buffer
that
body
so
that,
if
that
request
eventually
fails,
we
would
have
that
body.
A
So
we
could
send
it
again,
so
that
buffering
was
something
we
added
in
211,
so
that
for
for
grpc
requests
in
particular,
where
there's
always
a
body
on
the
request,
we
could
retry
those
up
to
a
maximum
payload
64k,
so
we'll
buffer,
a
certain
amount-
and
this
is
another
philosophy
about
about
Linker
D-
is
that
and
something
that
we
get
kind
of
from
working
in
Rust?
Is
we
get
to
make
very
conscious
decisions
about
how
much
data
we're
buffering
in
the
proxy?
You
know
we
have
fixed
size
cues.
A
So
before
this
all
of
the
control
plane
was
written
in
go
and
the
proxy
was
written
in
Rust,
and
so
this
was
the
first
time
we
had
rust
kind
of
entering
the
control
plane
side
of
things,
and
this
I
think
is
a
very,
very
exciting
development,
because
we
got
to
kind
of
try
out
what
it
was
like
to
write
a
controller
in
Rust.
You
know,
typically,
the
zero
written
go,
there's
a
lot
of
go
ecosystem
around
kubernetes
controllers.
A
A
Okay,
so
fast
forward
to
212,
which
is
the
most
recent
release
of
linker
d.
This
kind
of
took
the
server-side
authorization
a
step
farther,
so
one
of
the
big
drawbacks
with
the
server-side
authorization
that
we
had
into
11.
Is
that
all
the
authorization
we
said
it
was
fine
grained,
but
it
was
fine
grained
per
server
which
meant
per
Port.
So
you
could
say
you
know
this
port.
Has
this
policy?
This
port
has
this
policy.
These
are
the
types
of
requests
that
it'll
accept
and
here's
who
it'll
accept
it
from.
A
But
what
we
really
found
is
that
we
needed
to
get
even
more
fine-grained
than
that
and
have
per
route
policy,
which
meant
to
take
a
look
at
the
hcp
path
or
method
and
decide.
You
know,
is
this
a
liveness
check?
If
so,
it
needs
a
different
authorization.
You
know
policy
than
if
this
is,
you
know,
scraping
the
metrics
or
if
this
is
an
application
request,
or
if
this
is
something
else.
So
people
ran
into
a
lot
of
problems
specifically
with
liveness
probes,
because
those
were
coming
from
the
kublet.
A
They
were
not
authenticated,
they
were
not
part
of
the
mesh.
So,
in
a
lot
of
cases,
we
were
rejecting
them
because
people
set
up,
you
know
their
their
servers
and
their
authorization
policies
and
those
liveness
probes
were
failing,
and
then
the
application
was
failing
because
it
was
detected
as
down.
So
this
kind
of
helped
us
clean
that
up
a
lot
and
meant
that
we
can
now
do
authorization
per
route.
We
could
say
this
route,
you
know
these.
A
These
clients
can
talk
to
this
route
and
these
clients
can
talk
to
this
route
and,
and
it
gives
us
a
lot
more
control.
So
that's
been
a
huge
step
forward.
The
other
reason
why
this
is
really
exciting
is
because,
when
we
were
developing
this
feature,
we
needed
some
way
for
people
to
specify
which
routes
you
know
were
were
allowed
and
which
routes
were
not.
A
So
we
needed
users
to
have
some
with
to
specify
what
is
a
route,
and
it
turns
out
that
similar
work
was
already
happening
at
the
same
time
in
the
Gateway
API,
where,
as
part
of
the
Gateway
API
for
Ingress,
is
you
also
need
to
Define
what
is
a
route?
And
this
is
a
really
good
opportunity,
because
we
could
use
those
types
and
we
could
kind
of
make
sure
that
we
were
developing
this
in
a
direction
that
was
compatible
with
what
kubernetes
was
doing
and
what
what
the
Gateway
API
was
doing.
A
And
so
that's
what
we
did.
We
used
the
Gateway
API
type,
the
HTTP
route,
type
from
the
Gateway
API
to
Define
HTTP
routes,
and
you
can
attach
server
policy
onto
those
in
Linker
D.
So
you
can
say,
here's
an
HTTP
route
and
you
know
when
talking
to
this
server
on
this
route.
Here's
the
authorization
policy
that
you
should
use
and
I
think
this
sets
us
up
in
a
good
direction,
because
right
now,
there's
ongoing
work
on
the
gamma
project,
which
is
a
project
to
adapt
the
Gateway
API
for
service
measures
in
general.
A
So
this
is
obviously
something
that's
of
of
quite
a
bit
of
interest
to
us
and
it
means
that
we're
kind
of
well
set
up
to
be
compatible
with
that
and
we're
very
involved
in
that
conversation.
So
the
Gateway
API
is
very
cool.
If
you
have
not
checked
it
out,
I'm
doing
a
talk
tomorrow
about
the
the
Gateway
API
and
specifically
how
Lincoln
uses
it.
So,
if
you're
interested
in
hearing
more
about
that,
I
will
be
talking
about
that
tomorrow.
But
in
the
meantime
just
know
it's
very,
very
cool.
A
What
else
oh
yeah
and
we
also
added
kind
of
automatic
support
for
health
checks,
so
that
means
that,
even
if
you
don't
manually
configure
that
you
know
these
are
the
paths
for
that
you've
defined
as
health
checks.
We
will
admit
those
automatically
because
we
know
what
they
are
because
they're
in
your
spec
they're
in
your
your
container
spec-
and
we
know
those
are
coming
from
the
couplet.
So
as
long
as
they're
coming
from
the
right
place,
we
don't
require
mtls
on
them
and
that'll
just
work.
A
So
liquidity
213
will
be
our
next
release.
I,
don't
know
exactly
when
it's
planned
to
come
out
when
it's
ready,
but
the
major
Focus
for
213
is
going
to
be
client-side
policy.
So
in
212
and
211,
the
major
Focus
was
on
server-side
policy,
specifically
admission
policy.
We
wanted
to
say
you
know
we're
going
to
let
these
things
in
or
we're
going
to
deny
them
based
on
their
identity.
A
On
213,
we
really
want
to
focus
on
client
side
policy
and
there's
a
few
things.
The
client-side
policy
is
a
very,
very
broad
topic,
there's
a
lot
of
things
in
there,
but
specifically
we
wanted
to
focus
on
header-based,
routing
and
circuit
breaking
in
particular.
These
are
two
features
that
have
been
highly
highly
requested,
and
so
you
know
it's
the
natural
time
to
kind
of
take
what
we
learned
doing
server
policy
and
and
move
that
over
to
the
client
side.
A
So
again,
we
want
to
continue
the
the
path
that
we've
gone
on
using
the
HTTP
route,
type
from
the
Gateway
API
and
potentially
other
types
from
the
Gateway
API.
To
do
this
in
a
way
that
feels
very
kubernetes
native
and
kubernetes,
very
natural
to
anybody
who's
running
in
kubernetes,
so,
for
example,
HTTP
routes
have
these
things
called
back
ends
or
back-end
refs,
which
are
very
useful
for
ingresses,
because
as
an
Ingress,
you
want
to
say
okay
for
this
route.
A
Here's
where
I'm
going
to
send
this
request
to
in
the
same
way,
it's
kind
of
also
natural
to
use
that
for
East-West
traffic.
When
saying
well,
when
I
send
a
request
that
matches
this
route
to
this
service,
you
know
actually
I
want
to
send
it
to
this
other
backend,
instead
or
I,
want
to
split
it
and
send
a
portion
of
that
traffic
to
this
back
end
instead
or
I
want
to
split
it
based
on
a
header
and
say
for
this
header
I
want
to
go
here,
and
this
header
I
want
to
go
here.
A
We've
also
had
a
lot
of
requests
for
circuit
breaking.
This
is
a
kind
of
this
is
an
interesting
one
and
a
little
bit
of
a
nebulous
one,
because
everybody
who
asks
for
Circle
breaking
means
something
different
by
it.
So
we're
never
quite
sure
exactly
what
that
means,
but
I
think
in
general.
There's
this
need
to
do
to
specify
load
balance
or
policy
and
load.
Balancer
policy
encompasses
a
lot
of
things
so
for
link
ready
right
now.
A
So,
if
you
see
some
back
ends
are
performing
very
well:
they'll
get
more
traffic
other
back
ends
which
are
performing
more
poorly
they'll,
get
less
traffic
and
that
will
kind
of
automatically
adjust
over
time
as
the
performance
of
those
back
ends
changes
over
time
and
it's
really
really
good
at
minimizing
latency.
So
that's
what
we
use
in
100
of
cases.
We
always
use
Yuma
and
it
performs
great,
but
there's
kind
of
this,
this
desire
for
some
people
to
say
well
actually
I
want
a
little
more
input
on
how
load
balancing
happens.
A
I
want
to
do
I
want
to
have
more
control
over
when
back
ends
are
in
the
pool
or
out
of
the
pool,
and
this
is
kind
of
the
what
people
call
circuit
breaking
to
say.
Well,
if
there's
been
a
bunch
of
failures
on
this
back
end,
maybe
I
want
to
kick
that
out
of
the
load
balancer
pool
for
a
while,
let
that
back
end
recover
before
I
bring
it
back
in,
and
so
there's
a
lot
of
surface
area
here
for
configuration
to
say
well
exactly.
A
How
do
you
want
load
balancing
to
behave,
and
so
client
policy
is
a
really
natural
place
for
users
to
be
able
to
specify
that
configuration
and
say?
Well,
maybe
we
need
different
policies
for
different
routes.
Maybe
this
route
is
fundamentally,
you
know,
behaves
differently
and
it
needs
a
different
load
balancer
policy
than
this
other
one.
Maybe
we
want
circuit
breaking
over
here,
but
we
don't
want
it
over
here,
because
you
know
the
nature
of
those
Services
is
different.
A
Now,
if
you
are
a
link
to
the
expert,
you
may
recognize
that
some
of
this
sounds
kind
of
familiar
from
service
profiles.
So
service
profiles
are
something
that's
in
linkurdy
today
and
it's
a
way
of
specifying
which
routes
are
retryable
and
which
routes
have
timeouts,
and
you
know
that's
got
a
lot
of
overlap
with
what
I
just
talked
about
being
able
to
specify
client
policy,
because
retries
and
timeouts
are
client
policy
and
so
kind
of,
because
there's
this
overlap.
A
We
want
to
kind
of
start
slowly
to
move
away
from
service
profiles
for
configuring,
these
things
and
start
moving
towards
something
that
feels
more
natural
in
kubernetes,
which
is
by
doing
things
with
HTTP
routes
and
with
the
Gateway
API.
So
this
isn't
going
to
be
a
hard
cut
over
we're
going
to
kind
of
slowly
start
to
deprecate
things
from
service
profiles
and
move
them
over
to
the
new,
the
new
world
of
hdb
routes
and
and
Gateway
API.
A
Just
because
that
feels
a
lot
more.
A
lot
more
kubernetes,
easy
and
so
we'll
kind
of
slowly
slowly
migrate,
that
functionality
over
kind
of
overtime-
and
you
know,
as
I
said
before,
we've
got
our
eye
on
gamma
we're
very
involved
in
those
conversations
and
to
the
extent
possible,
we
want
to
be
compatible
with
gamma.
We
want
to
have
all
that
server
side
and
client-side
functionality
be
configured
in
a
way
that
that
makes
sense
with
the
Gateway
API.
A
So
if
this
sounds
interesting,
we
would
love
for
you
to
get
involved.
All
the
development
is
open
source,
of
course,
on
GitHub,
so
you
can
kind
of
follow
along.
You
can
file
issues.
You
can
open
PRS
if
you
are
trying
to
run
Linker
D
and
you
run
into
any
problems,
you
can
always
hop
into
the
linkready
slack,
the
slack.linkerty.io
and
there's
always
people
maintainers
and
other
users
who
are
there
helping
each
other
out
and
just
being
friendly
and
nice.
A
We've
got
some
mailing
lists
that
are
that
are
from
the
cncf
that
we
announced
releases
to
and
and
make
other
announcements
too.
There
have
been
some
security
audits
that
we've
done,
which
are
very
interesting.
If
you
care
to
read
security
audits
and
yeah,
we
would
love
to
love
to
have
everyone
participate.
A
If
you
are
looking
for
a
more
kind
of
Hands-On
way
of
learning
about
Linker
D,
there
is
a
Hands-On
service
mesh
academy,
the
next
one
is
in
November,
and
that
really
gets
you
kind
of
Hands-On
and
teaches
you
right
down
to
the
nitty-gritty
the
details
about
linkridi
that
you
might
not
be
able
to
pick
up
on
your
own.
So
if
that
is
of
interest
to
you,
I
highly
recommend
that
you
check
it
out.
A
And
if
you
are
running
Linker
D
in
in
production,
and
you
need
a
little
bit
extra
help
or
you
want
to
alleviate
some
of
that
burden
of
of
running
it
buoyant
offers
a
fully
managed
linkerty.
So
it
will
take
care
of
things
like
automatic
upgrades
and
certificate,
rotation
and
alerts
and
stuff
like
that
which
just
takes
some
of
the
administrative
burden
off
of
you,
and
you
know,
makes
it
a
little
bit
easier.
A
Good
question:
yes,
the
question
was:
istio's
got
an
ambient
proxy
proxilis
mode,
this
link,
or
do
you
ever
going
to
have
something
like
that?
Probably
not
so
we're
rarely
tied
to
the
sidecar
model.
We
think
it
has
a
lot
of
advantages
in
terms
of
security
and
in
terms
of
operability
and
understandability.
The
Pod
is
a
very
natural
security
boundary,
and
so,
when
you
do
something
with
like
ambient,
where
you
take
that
that
proxy
and
you
run
it
somewhere
else
and
you
have
it
kind
of
be
multi-tenant,
you
lose
a
lot
of
those.
A
Those
benefits
and
you've
got
one
proxy
serving
multiple
different
pods.
Those
security
boundaries
get
a
little
bit
more
muddled.
You
know
you
have
keys
from
multiple
different
accounts,
potentially
coexisting
in
that
one
proxy.
So
we
don't
see
kind
of
any
major
advantages
to
that
that
that
sidecarless
model
that
kind
of
outweigh
outweigh
the
drawbacks.
So
we're
we're
we're,
probably
in
it
with
the
sidecar
for
for
at
least
the
medium
to
long
term.
A
Yeah,
that's
that's
a
great
point,
so
the
someone
just
pointed
out
that
link
already
one
had
that
architecture
and
that's
true:
Linker
D1
had
a
per
node
proxy
and
you
know
one
of
the
lessons
that
we
learned
from
that
was
that
there's
a
lot
of
drawbacks
to
that
and
it's
very
difficult
to
do
security
correctly
in
that
model
and
it's
very
difficult.
You
know
it
introduces
a
lot
of
complexity
that
you
can
drop.
If
you
go
to
this
more
isolated
model
of
proxy
per
bod.
F
E
It's
hard
to
upgrade
like
it's:
it's
like
a
one-way
upgrade
and
for
production
workloads,
it's
very
hard
to
guarantee
that,
like
we
can
revert
if
there's
a
problem,
especially
since
you
have
to
like
rotate
everything
to
get
do
you
have
recommendations
like
for
us
right
now.
The
plan
is
like
to
safely
upgrade
to
a
new
version
is
to
have
a
separate
cluster
like
a
because
a
separate
cluster.
A
Yeah
yeah,
so
the
question
is:
is
how
do
you?
How
do
you
upgrade
in
a
way
that
you
have
confidence
that
you
can
can
roll
back
and
and
I
I
hear
that
it
has
been
an
issue
in
the
past
that
rollbacks
to
a
previous
version
have
been
very,
very
difficult,
we're
trying
to
get
better
about
that
kind
of
going
forward?
But
it
is,
you
know,
historically,
a
problem.
A
My
advice
to
you
is:
if
you're
running
into
problems,
just
try
and
engage
with
the
liquidity
team,
you
know
directly,
we
can
try
and
help
you
sort
out.
You
know
the
specifics,
but
yeah
going
going
backwards.
Doing
it
downgrade
has
not
been
something
that
has
been
a
great
experience
in
the
past.
So
I
hear
that.
F
So,
obviously
that
with
the
new
server-side
policies,
you
can
enforce
security
within
Linker
D.
Is
there
a
security
reason
to
do
both
you
know?
Is
it
I
know
you're
enforcing
a
proxy,
but
is
it
you
know
a
concern
that
we
should
apply
it
on
both
sides?
You
know,
potentially,
if
we
have
pods
that
we
don't
want
anything
talking
to
do
you
need
to
do
it
twice
or
is?
It
is
one
good
enough.
F
A
I
mean
you:
could
it's
kind
of
like
a
belt
and
suspenders
type
of
approach,
they're
they're
slightly
different
things.
You
know
when
linkerty
talks
about
security
and
mtls,
what
we're
talking
about
is
workload
identity.
So
we
have
these
identities
which
are
tied
to
certificates
which
are
bootstrapped
from
from
service
account
tokens.
So
you
know
we
don't
necessarily
say
that
you
know
this
request
is
you
know
coming
from
a
certain
place,
but
rather
it
has
this
identity.
A
G
A
It's
by
default,
it's
handled
entirely
by
Liberty.
We
do
integrate
with
start
manager,
so,
for
example,
if
you
want
automatic
certificate
rotation,
cert
manager
can
do
that
and
that
works
great
in
the
default
case.
We
generate
all
of
that
all
of
those
certificates
inside
of
linker
D
and
those
are
you
know,
kind
of
bootstrapped
up
from
the
service
account
tokens,
but
that
trust
chain
is
kind
of
all.
You
know
all
there.
It's
not
connected
to
like
a
well-known
CA
or
anything
like
that.
Okay,.
A
H
Thank
you
for
the
presentation.
It
was
great,
so
I'm
a
long
time,
SEO
user,
but
also
a
fan
of
linker
D.
Personally,
so
one
of
the
things
that
I
was
looking
at
is
in
terms
of
like
day
two
operations
in
terms
of
visibility.
Seo,
for
example,
makes
it
very
easy
to
do
something
like
chiali.
Is
there
something
in
the
community
that's
equivalent
inside
the
Linker
D
Community,
or
is
there
an
opportunity?
Is
that
something
as
a
community?
We
should
like
look
at
or
in
terms
of
viewing.
A
Yeah,
so
a
lot
of
that
is
kind
of
built
into
the
lucrative
Vis
extension.
You
know
if
you
use
the
link
review
physics
extension,
you
can
get
things
like
service
maps
and
dashboards
and
and
so
on.
So
a
lot
of
the
functionality
that's
in
in
chially
is
also
kind
of
available
through
through
the
linkready
dashboard,
but
kind
of
on
top
of
that,
all
that
data
is
in
Prometheus
and
you
can
build.
You
know
any
visualization
visualization
you
want.
On
top
of
that.
I
A
I
A
That's
a
great
question
so
for
back
pressure
you
know
we
we
use
kind
of
the
HTTP
back
pressure
mechanism,
so
as
kind
of
the
proxy
handles
traffic
it
it
takes
those
bytes
in
and
sends
them
out
and
as
soon
as
it
sends
them
out
kind
of
signals.
You
know
Upstream
that
is
ready
for
more
kind
of
using
the
natural
connection.
Windows
of
http.
D
Hi
so
I'm
interested
in
Linker
D's,
so
talking
about
your
authorization
policies,
it's
on
a
pod
to
pod
kind
of
this
workload,
authorization
does
Linker.
Do
you
have
a
story
around
like
user
authorization
between
pods
or
accessing
services
or
endpoints
in
positive,
maybe
further
on
the
stack
that
a
Gateway
wouldn't
be
able
to
necessarily
block
that
traffic.
A
E
A
The
question
was:
can
you
explain
the
difference
between
East
West
and
North?
South
traffic
north
south
generally
refers
to
stuff
coming
in
from
the
outside
world,
so
coming
in
through
the
Ingress
of
the
Gateway,
and
then
East
West
is
service
to
service
within
the
cluster
for
one
service
in
a
cluster
to
another
service.
Also
in
the
cluster.