►
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
Envoy Deep Dive – Matt Klein, Lyft (Intermediate Skill Level)
Matt Klein, Envoy maintainer from Lyft, will host a general Q&A session on Envoy. Please come with hard questions! We might also have a small set of short lightning talks.
"About Matt
Matt Klein is a software engineer at Lyft and the architect of Envoy. Matt has been working on operating systems, virtualization, distributed systems, networking, and making systems easy to operate for over 15 years across a variety of companies. Some highlights include leading the development of Twitter’s C++ L7 edge proxy and working on high-performance computing and networking in Amazon’s EC2."
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! 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.
B
B
The
first
talking
is
about
a
new
service
that
we
are
testing
out
in
production.
These
are
statistics
that
submissions
were
using
to
monitor
their
service,
as
we
can
see
in
this
there's
border
between
our
hogs
and
we
were
getting
some
requests,
so
everything
seemed
fine,
but
when
we
looked
from
the
edges
artistic
generated
to
invoice
on
the
client
side,
what
actually
happened
was
that
two
hours
after
we
started
the
test,
there
was
another
broken
instance.
The
fact
is
that
we
did
quests
and
all
those
were
errors.
B
So
half
of
the
requests-
okay,
half
of
the
bhagavad
I,
don't
know
how
we
could
find
out
without.
If
we
didn't
deploy
envoy
before
in
turn
and
of
case,
we
hadn't,
although
a
typical,
I
and
I,
didn't
support
system
connections
and
it
was
making
requests
across
datacenters,
and
this
is
what
happened
with
the
Pinet
time
after
we
deployed
a
voice
from
the
service.
B
In
the
north
case,
we
had
the
service,
it
was
deployed
in
two
datacenters.
Everything
was
working,
fine
in
the
first
datacenter
in
the
second
one,
some
requests,
only
some
of
them
were
timing
out
when
we
try
to
do
the
migration
after
a
bit
of
investigation.
What
we
found
out
was
that
the
requested
of
timing,
how
to
actually
four
times
slower
or
in
this
dataset
in
the
first
one
everything
was
what
you
find
the
same
requests,
and
this
was
to
Tommy's
miss
confirmation
of
the
Santa
beast.
B
B
B
B
B
Looking
at
what
to
start
looking
and
after
we
deployed
avoider,
we
realize
that
most
of
the
services
or
experiencing
like
latency
spikes
every
minute
at
the
beginning
of
the
minute,
for
a
few
seconds
after
a
bit
of
investigation,
what
we
found
out
there
was
this
con
job
schedule
Ike
this
minute
ly
on
all
the
developer
machines,
this
product
script
before
doing
what
it
was
supposed
to
do.
It
was
a
connecting
pro
configuration
service
that
confirmation
service
bus
was
used
by
the
rest
of
the
infrastructure
and
data
slowdowns
was
coming
from
the
canoe
support.
B
This
is
how
we
pulled
out.
The
migration
will
still
be
songs.
Try
to
do
all
the
changes
by
themselves.
Well,
some
of
them
shows
that
most
of
them
chose
to
pair
with
us
and
all
the
changes
together
and
some
of
them
chose
to.
Let
us
do
all
the
changes,
and
this
was
mainly
focuses
at
work
in
maintenance
model,
that
nobody
wanted
dog
new
motto
and
the
concern
that
progress
by
our
colleagues
when
we
try
to
deploy
them
for
in
production,
was
about
the
sausages
like
isn't
going
to
eat
up
all
my
CP
or
my
movie.
B
B
B
That
I,
it
depends
I,
think
we
mean
just
best
howl
for
for
work
services
like
also
number
of
samples
of
intense
analysis,
which
we
have
just
at
sixty.
Seventy
percent
now
machine
block.
Actually,
my
taking
one
service
is
not
that
hard.
It's
a
I
think
it's
something
that
you
can
do
in
maximum
one
hour
work,
but
what
we
spend
more
time
was
also
discussed
with
the
semi
salons
and
try
to
make
them
understand
and
that's
what's
been
more,
that's
what
we
spend
more
time,
because
we
didn't
want
to
do
a
change
like
just.
B
C
Hi
I'm,
Doug
and
I'm
gonna
talk
about
building
a
service
mesh
with
envoy
at
Squarespace,
so
I
thought,
starting
with
a
little
bit
of
context,
would
be
helpful.
So
if
you
go
back
to
2013,
we
were
pretty
small,
less
than
50
engineers,
even
less
working
on
infrastructure
and
it's
a
typical
story.
We're
building
whatever
works
with
a
monolith,
and
you
know
we
grow
a
little
bit
more
and
find
out
that
you
know
we're
kind
of
dealing
with
too
much
firefighting.
The
monolith
is
kind
of
inflexible
for
our
needs.
C
2016
we
start
to
introduce
micro
services,
try
to
build
things
to
be
scalable
and
reliable.
Last
year
we
have
teams,
building
you
more
micro
services,
working
independently
full
stack.
The
big
thing
is
that
we're
introducing
self-service
infrastructure
with
kubernetes
I'm
so
a
little
bit
about
our
platform.
So
we
started
building
or
micro
services
platform
in
2014
we're
building
Java
API
servers,
running
on
virtual
machines
and
using
console
for
service
discovery,
we're
using
a
service,
client
library
based
a
lot
on
the
Netflix
open
source
software
stack.
C
So
that's
things
like
hysterics
ribbon
and
arcs
and
Eddy,
and
now
we
have
in
progress
this
migration
from
VMs
to
kubernetes,
so
a
little
bit
about
our
setup
with
console.
So
we
have
our
services
when
they
come
up,
they
announce
their
presence
in
the
console
and
then
a
service,
that's
requesting
those
has
its
client
library.
There
that's
running,
requesting
service
instances
out
of
console
and
then
performing
the
load
balances
against
the
healthy
and
available
service
instances.
C
We
have
console
setup
for
cross
data
center
replication
using
its
built-in
gossip
protocols.
So
why
did
we
want
to
pursue
a
service
mesh
I?
Think
one
of
the
big
things
was
that
we
wanted
to
take
that
functionality
that
we
had
in
our
client
library.
That's
you
know
using
the
Netflix,
open
source
stack
and
take
that
and
move
it
out
of
that
library
so
that
it's
its
own
process
in
the
sidecar,
and
that
would
give
us
some
advantages
like
being
able
to
configure
and
update
that
process
independently
of
the
application
that
it
serves.
C
We
also
were
interested
in
having
advanced
operational
control
through
API.
Is
that
work
with
that
sidecar?
We
were
looking
to
have
improved
observability
and
we
really
wanted
to
open
the
door
to
support
service
development,
multiple
languages.
Historically,
everything
in
production
was
Java,
but,
as
the
company
has
been
growing,
there's
been
a
desire
to
use
other
languages
in
production
and
its
it's
already
started
to
happen.
So
we
were
really
kind
of
behind
the
curve
and
wanted
to
support
those
other
languages.
C
So
we
chose
envoy
for
a
service
mesh.
Some
of
the
things
that
we
liked
about
it
was
that
it's
built
to
run
as
a
sidecar.
It
can
proxy
ingress
and
egress
traffic
really
like
the
dynamic
configuration
API.
So
we
could
use
that
to
provide
service
discovery,
information
and
do
things
like
change.
The
routing
table
and
circuit
breaker
configuration
on
the
on
the
fly,
and
we
thought
this
would
be
a
really
big
upgrade
and
our
capability
as
operators.
C
So
how
did
we
go
about
trying
to
incrementally
introduce
Envoy
entire
stack?
So
what
we
came
up
with
was
introducing
this
new
service
that
we're
calling
mesh
discovery
and
that's
really
going
to
be
put
in
place
to
front
console
and
then
that
uses
envoys,
XDS
API
the
version
to
API
to
provide
streaming
updates
to
envoy,
which
is
running
as
a
sidecar
in
our
kubernetes
pods.
So
our
services
that
are
coming
up
they're
still
doing
the
same
thing
they've
been
doing
before
announcing
in
the
console
and
then
mesh
discovery
is
just
pulling
that
information
out.
C
So
I
wanted
to
talk
a
little
bit
about
how
we're
using
this
XDS
protocol
with
console
so
envoy
when
it
starts
up
and
performs
cluster
discovery,
CDF's
request
that
goes
the
mesh
discovery
and
that
just
Maps
over
really
easily
to
requesting
from
consoles
catalog
to
just
get
a
list
of
the
services.
So
we
get
that
list
back
from
console
and
one
of
the
things
that
console
has
in
their
API
is
what
they
call
an
index,
and
that
represents
a
point
in
time
and
can
be
used
for
long
polling
to
see.
C
If
there's
any
updates,
so
we're
simply
taking
that
value
that
we
get
in
the
index
and
passing
that
as
the
version
info
back
to
envoy,
so
after
envoy
has
gotten
its
initial
list
of
clusters
that
stream
from
envoy
the
mesh
discovery
that
just
remains
open
and
idle
in
background
mesh
discovery
is
polling
console.
You
know
continuing
to
see
if
that
catalog
list
has
anything
newer,
so
we're
just
asking
console:
do
you
have
anything
newer
than
that
index?
1
2
3
once
console
has
some
new
data.
C
So
that's
how
it
works
for
CVS,
the
other
parts
of
of
XDS
are
pretty
similar,
so
we're
using
EDS
and
that's
the
same
exact
strategy
just
instead
asking
console
for
all
of
the
available
endpoints
for
a
service
instance
and
then
for
RDS
right
now.
We
just
have
a
very
simple
routing
table.
That's
just
matching
a
header
value
to
a
cluster
name,
so
I've
talked
about
observability
and
this
screenshot
is
an
example
of
one
of
the
things
that
we're
currently
working
on.
C
So
future
work
for
us
includes
trying
to
build
out
more
orchestration
features
into
our
new
discovery
system,
so
taking
that
mesh
discovery
component
really
building
it
up
to
be
the
control
plane
that
we
that
we
need.
So
we
want
to
harness
that
XDS
API,
so
that
we
can
push
updates
and
make
traffic
routing
changes
on
the
fly.
C
We
want
to
build
API
into
that
system,
to
abstract
away
the
common
operations
that
we
want
from
our
service
mesh,
and
we
want
to
build
a
dashboard
for
operators
so
that
they
can
see
all
of
these
metrics
and
also
be
able
to
go
in
there
and
quickly
make
changes
for
the
really
common
everyday
operations.
That's
it.
Thank
you.
C
Yeah,
so
we
get
the
host
information
from
envoy,
and
so
you
can
configure
envoy
with
what
cluster
it's
in
and
like
a
name
for
that
instance.
So
we're
receiving
the
information
but
right
now
we're
not
doing
anything
with
it,
but
I
think
it's
definitely
something
that
we'll
take
advantage
of
in
the
future.
C
So
we're
we're
using
Prometheus,
so
we're
just
gonna
scrape
everything
that
that
envoy
provides
for
us.
The
really
key
ones
are
request.
R/A,
like
response
codes,
five,
hundreds
and
Layton
sees
those
are
the
big
ones
for
us
and
I
think
you
know
in
the
future,
we'll
care
more
about
like
exactly
where
such
traffic
going
and
having
good
ways
to
drill
down
and
answer
those
questions.
C
D
D
So
we've
been
collaborating
on
for
a
while
now
a
healthy
own
Octavio
and
we
announced
gimble
last
week.
Kimball
is
a
multi
cluster,
multi-team,
ingress
load,
balancer
built
on
kubernetes
and
envoy
in
contour,
and
before
we
get
into
all
the
technical
and
architectural
decision
decisions
we've
made
I
think
it's
important
to
understand:
octopi,
oh
and
Yahoo
Japan's
infrastructure,
and
why
we
went
ahead
and
built
this
project.
E
Let
me
talk
about
active
view
and
our
background
quickly.
The
October
is
US
subsidiary
of
EF
to
Japan.
We
cooperate
with
Japan
on
core
infrastructure
from
their
center
to
private
crowd.
We
support
over
hundred
applications
running
on
85,000
physical
servers,
tender
centers
and
over
50
OpenStack
clusters.
We've
started
using
kubernetes
as
well,
and
the
number
of
kubernetes
cluster
is
growing
rapidly
in
such
environment.
Our
challenge
is
application.
Delivery.
Application
delivery
at
scale
is
key
to
our
business.
We
needed
Forrester
service
discovery
and
cannery
deployment
capability.
Just
provides
instant
rollback
and
performance.
E
D
You
so
gimble
is
meant
to
be
deployed
to
one
or
more
kubernetes
clusters
in
front
of
your
infrastructure.
So
this
is
your
load
balancer.
You
don't
necessarily
need
a
cloud
load
balancer
or
if
you're
on
Prem-
and
you
wanted
to
have
something
like
a
Google
or
Amazon
cloud
load
balancer.
You
could
deploy
this
to
your
infrastructure
and
get
similar
behavior
and
one
of
the
interesting
things.
So
there's
two
really
three
key
components
to
gimble
number:
one
is
the
service
discovery.
D
We
need
to
pull
information
from
upstream
kubernetes
and
OpenStack
clusters
and
inject
that
information
into
gimble,
so
that
developers
have
a
unified
way
to
configure
their
routing
rules
across
all
of
their
services.
That
may
be
running
in
different
clusters.
Number
two
is
the
routing
capabilities
so
hefty.
Earlier
this
year
we
built
imbel
or
sorry.
Last
year
we
built
gimble,
which
was
the
first
part
of
our
collaboration
and
gimble,
is
an
envoy
based
ingress
controller
for
kubernetes,
what
sorry
contour
and
then
the
third
part
is
the
monitoring
suite.
So
let's
dive
into
some
of
these
things.
D
So
the
first
thing
was
service
discovery
with
our
top
yo,
and
we've
noticed
this
with
a
lot
of
our
customers.
Development
teams
have
a
namespace
in
every
cluster
and
they
may
have
applications
to
ploy
it
across
multiple
clusters.
Some
of
it
might
be
kubernetes.
Some
of
it
might
be
OpenStack.
So
we
needed
a
way
to
discover
those
applications
running
in
upstream
clusters
now
with
gimble.
What
we
do
is
we
discover
those
in
communities
we
are
just
pulling.
D
They
are
grabbing
the
services
and
endpoint
objects
from
kubernetes,
as
well
as
the
ingress,
so
our
service
and
end
points
and
we're
injecting
them
into
the
gimble
cluster
for
OpenStack.
They
don't
have
service
and
end
points,
so
we're
translating
the
Nova
API,
which
gets
us
our
virtual
machine,
IPS
imports
and
the
OpenStack
L
bass,
so
their
load
balancer
as
a
service
API
is
an
OpenStack
and
we
translate
those
two
service
and
endpoint
objects
in
the
gimble
cluster.
D
D
The
next
aspect
is
the
routing
and
policy,
so
we
built
contour,
which
is
a
Illinois
based
ingress
controller
for
kerbin
Eddy's.
It's
a
drop-in
replacement
for
existing
ingress
controllers.
So
one
of
the
things
that
we
found
is
the
dynamic
API
envoy
is
much
well
better
suited
for
the
dynamic
environment
of
kubernetes,
where
we
have
lots
of
services
and
endpoints
coming
and
going
being
able
to
hot
reload.
D
The
router
configuration
on
the
fly
is
key,
however,
for
those
of
you
that
have
been
working
with
kubernetes,
you
may
have
noticed
that
the
kubernetes
ingress
api
by
default
doesn't
really
cover
all
the
needs
that
many
organizations
need
two
key
issues:
number
one:
it's
not
multi
team
compatible.
So
any
team
that
has
the
ability
to
create
an
ingress
object
in
a
criminai.
His
cluster
could
potentially
create
routes
or
new
domains
that
impact
other
teams.
That's
not
okay
in
businesses.
D
The
second
one
is
the
default
ingress.
Api
doesn't
support
any
advanced
features
like
weight,
shifting
or
load
balancing
or
sort
of
cluster
cutoff,
and
it
also
doesn't
support
multiple
services
per
out
and
we
have
one
service
per
out
and
in
some
of
the
ingress
controllers
have
gone
through
annotation.
D
They
try
to
inject
all
that
into
annotations,
but
we
wanted
to
have
this
built
natively
into
a
new
API,
so
we
have
put
together
a
design
for
a
new
ingress,
router
API
that
we're
going
to
be
using
as
contour
so
contour
will
be
able
to
speak
either
the
current
ingress
or
you
can
switch
to
this
new
ingress
route
design
we're
about
to
start
development
on
this.
So
we're
really
excited
about
that
and
would
love
to
talk
more
about
that.
But
don't
have
time
today.
D
The
last
fact
aspect
is
observability
at
the
scale
that
ectopy
o
is
running
at.
They
need
to
have
insight
into
where
the
traffic
is
going.
Where
are
the
errors
which
routes
are
having
problems,
or
is
it
localized
to
a
specific
service
across
all
clusters,
or
is
it
a
single
one?
Cluster?
That's
having
issues
so
gimble
when
we
have
an
out-of-the-box
monitoring
system
built
on
Prometheus,
core
fauna
and
alert
manager,
and
we
include
pre-built
dashboards.
D
Now
these
will
be
evolving
as
we
move
forward
with
the
project
as
we
learn
more
about
operating
this
system
at
scale,
and
that
really
gets
us
to
the
next
piece.
Where
are
we
on
our
roadmap?
So
last
week
we
launched
this
project.
The
two
key
things
was
the
OpenStack
Discoverer
and
the
kubernetes
Discoverer.
We
are
leveraging
the
current
ingress
v1
beta
API
for
managing
this,
and
we
have
some
initial
Doc's
documentation
in
dashboards.
D
Looking
forward
this
summer,
we'll
be
rolling
out
the
ingress
route,
integration
or
interest
route,
C
or
D
into
contour,
which
is
then
used
in
gimbal,
so
that
will
give
us
multi
team
and
advanced
routing
capabilities.
The
other
thing
is
octopus
can
be
going
to
production
with
this,
and
that
means
that
we
have
to
test
this
to
meet
their
performance
standards
which
are
quite
high.
D
So
will
you
will
be
Tapio
and
Hep
C
will
be
collaborating
on
performance
testing
of
gimbal,
which
means
that
we're
testing
contour,
which
means
we're
testing
envoy,
to
make
sure
that
we
can
handle
all
of
this
at
scale.
Now,
looking
forward
to
this
fall
version,
0.3
one
of
the
biggest
sort
of
drawbacks
for
some
companies
with
gimbal
is
right
now
hep
do
gimbal
requires
every
pod
or
virtual
machine.
That's
gonna
be
routed
to
needs
to
have
a
routable
IP
from
the
gimbal
cluster.
D
So
if
we're
using
an
overlay
network
in
your
career,
Nets
cluster,
this
isn't
gonna
work
for
you
yet,
but
we
know
this
is
a
deficiency
for
organisations
that
may
be
running
in
some
of
the
cloud
providers.
So
that's
an
aspect
that
we're
working
on
the
other
piece
is
being
able
to
deploy
this
without
a
harbor
load
balancer
in
front
of
it
at
launch
october.
Low
balance
is
in
place,
but
looking
forward,
there's
really
no
reason
that
we
need
to
have
those
hardware
load
balancers.
D
Great
question
so
so
the
question
is:
if
we're
doing
these
advanced
routing
capabilities
right
now,
if
you
make
a
change
your
traffic
and
disappear
instantly,
one
of
the
things
that
we've
done
with
this
ingress
route
design
and
we're
doing
more
talks
in
the
future
about
this
I
mean
definitely
happy
to
talk
afterwards.
Is
we're
tracking
ingress
and
treating
it
sort
of
like
DNS
delegation,
so
you
have
your
route
domain
or
your
route
ingress,
and
so
I
own
wapt.com
and
hefty
comm,
and
maybe
I
am
responsible
for
our
main
landing
page.
D
So
I
have
that
in
my
namespace,
I
can
delegate
that
to
I
can
delegate
/blog
to
the
marketing
team
and
inside
their
namespace.
They'll
have
another
ingress
object
that
they
manage
and
if
they
can
delegate
to
themselves,
they
can
have
a
Bluegreen
ingress,
so
they
have
their
top-level
that
manages
inside
their
namespace.
It
can
have
a
point
or
two
that
actually
serves
the
traffic
and
it
points
to
two
other
ingress
routes.
So
you
switch
one
if
your
traffic
blackhole's,
you
switch
back
one
more
question.
D
F
Thanks
Matt,
just
the
level
set
quick
show
of
hands
who
here
today
is
using
TLS
with
envoy
right
now.
Okay,
so
for
the
four
people
who
put
your
hand
up,
this
talk
is
for
you
for
everyone
else.
Shame
that
Eli
seriously
is
quite
hard.
Has
his
advancing
slides
man.
How
do
I
do
that?
Just
presenter
TLS
is
hard
and
hopefully
spark
and
help
you
make
it
easier
if
it's
something
you're
trying
to
do
so
envoy
supports
em,
TLS
out
of
the
box.
It's
a
pretty
neat
feature.
It's
used
really
for
two
reasons.
F
One
of
them
is
confidentiality,
that's
usually
what
you
think
of
when
you
hear
em,
TLS
or
TLS
encrypted
on
the
wire,
but
the
other
thing
it
gives
you
is
identity,
because
you
need
to
establish
the
identity
of
each
of
the
the
to
connecting
parties.
The
way
you
do,
that
is
with
a
symmetric,
keys,
keys
and
certificates,
and
you
know
that's
pretty
easy
to
set
up
with
envoy.
You
can
stick
them
on
disk
and
you
can
add
the
other
relevant
files
to
to
envoy
configure
envoy
so
Jason
the
identity
of
the
the
service,
which
is
important.
F
If
you
want
to
verify
who
you're
connecting
to
it's,
usually
there's
different
ways
that
the
x.509
certificate
format
allows
you
to
encode
it,
it
can
be
in
the
distinguished
name,
it
can
be
in
the
sand.
There's
different
strategies
there,
an
envoy
supports
quite
a
few
of
them.
So
it's
easy
enough
to
set
up
the
challenge.
F
First
of
all,
you
have
new
certificates,
sorry
new
services
being
added,
often
dynamically
and
certainly
frequently,
and
then
on
top
of
that
you,
you
need
to
be
able
to
rotate
these
credentials
or
you
should
be
able
to
rotate
these
credentials
recently,
frequently
so
start
the
process
of
manually,
creating
these
things
and
sticking
them
on
disk.
Quite
apart
from
potentially
exposing
exposing
holes
in
your
certificate
supply
chain,
it
also
simply
becomes
cumbersome
and
it's
something-
that's
quite
amenable
to
automation.
F
F
This
thing
is
running
on,
so
is
the
nodes
that
contains
this
kernel
running
in
a
particular
Amazon
security
group,
for
example,
another
bunch
of
talks
that
go
into
that
in
more
detail
the
identity
is
info.
Spiffy
is
encoded
in
the
the
sand
in
the
spiffy
certificate.
Again,
a
lot
more
there's
plenty
of
material
on
how
that's
set
up
and
structured
if
you're
interested.
F
The
only
challenge
here
with
getting
this
to
work
with
envoy
is
envoy
does
not
know
about
the
workload
API
and
so
usefully
there's
a
tool
that
is
also
available
on
the
spiffy
repository
called
the
spiffy
helper.
This
is
basically
just
a
simple
script
that
you
run
in
the
same
security
domain,
and
you
know
usually
that
usually
adjacent
to
envoy
it's
a
sidecar
to
the
sidecar.
If
you
will
and
basically
what
this
thing
does,
is
it
periodically
calls
into
the
workload
API
retrieves
the
certificates
via
the
API
and
sticks
them
on
disk?
F
It
can
track
the
TTL
of
these
things
and
rotate
them
as
well
and
crucially
for
Envoy,
when
you
rotate
your
certificates,
you
need
to
signal
to
envoy
that
you've
rotated
your
key
material
and
this
by
the
spiffy
helper.
Sorry
can
do
that
as
well,
and
then,
once
you
have
this
in
place,
you
now
have
programmatically
delivered
key
material.
That's
been
defined
by
a
policy
rather
than
something
that
you've
had
to
manually
generate
and
set
up.
F
The
only
thing
that
remains,
then,
is
to
is
to
start
applying
access
rules
to
this
again,
a
rich
set
of
discussion.
That
could
happen
around
that,
but
if
you
want
to
do
it
very
easily
within
an
envoy
JSON
file,
you
just
add
a
couple
of
lines
to
describe
the
the
sand
of
the
spiffy
IDs
that
you
want
to
be
able
to
connect
to
an
incoming
proxy
and
that's
it
except
to
say,
there's
a
there's.
Actually,
this
slide
is
very
misleading
for
one
it
references
the
SDS
which
is
obsolete.
F
Now
the
there's
a
lot
of
work
to
do
in
this
space,
but
one
of
the
first
things
we
want
to
do
is
is
have
a
nicer
bundling
between
the
the
XDS
v2
API
s
and
the
Speier
helper,
so
that
we
can
do
this
more
dynamically
without
having
things
flying
on
disk
in
in
unsafe
ways
and
plenty
of
links
here.
If
you,
if
you
want
to
learn
more
about
this
stuff,
and
of
course
you
can
come
and
ask
me
as
well
thanks
I.
F
So
it's
actually
configurable.
This
is
where
the
sort
of
policy
language
comes
in,
so
it
depends
on
the
environment
that
you're
running
your
workload
and
and
envoy
in
so
you
first
of
all
would
use
some
sort
of
infrastructure
describe
descriptor
typically,
so
that
might
be
an
AWS
ASG.
It
might
actually
be
something
specific
to
that
machine.
So
if
you
have
a
TPM,
for
example,
with
a
private
key
in
it,
you
can
sign
a
nonce
and
use
the
corresponding
public
key
to
identify
the
machine.
F
So
that's
one
level
and
then
within
the
machine
it
really
depends
on
if
you
have
any
middleware
and
how
you're
doing
that.
So,
if
you're
just
running
something
on
a
on
Linux
inside
that
machine,
you
might
use
a
unit
like
a
UID
or
a
GID
to
identify
it
if
you're
running
it
inside
a
if
that
machine
is
actually
a
kubernetes
node,
there's
a
plug-in
that
will
talk
to
the
couplet
and
pull
out
the
pod,
spec
metadata
and
say
well,
we're
identifying
you
you
know.
Is
this
process.
F
That's
calling
me
something
that
you've
said
you're
old
and,
if
so
like
give
me
this
pod,
spec
metadata
or
about
it.
We
actually
use
a
unit.
The
API
itself
is
a
UNIX
domain
socket.
So
what
spire
is
doing
when
workload
calls
that
API?
Is
it
interrogate
the
basically
interrogate
the
kernel
and
says?
Who
is
the
core
of
this,
and
the
kernel
will
give
it
back
a
PID
and
a
G
ID
and
a
few
other
pieces.
A
E
A
Yeah,
that's
a
that's
a
great
question:
I
I
think
what
we're
trying
to
do,
and
we've
held
pretty
strong
so
far
from
a
project
perspective
on
this
is
to
kind
of
keep
with
a
unified
API.
So
this
XDS
API,
so
instead
of
going
and
supporting
kubernetes
CR
DS
and
like
console
and
the
87
other
systems
out
there,
we've
kind
of
set
the
hard
line
in
the
sand,
which
is
that
you
know
if
this
is
the
API
the
Envoy
supports
and
the
people
want
to
use
it.
A
They
basically
have
to
write
to
this
API
and
in
the
beginning
of
the
project.
I
was
concerned
that
that
was
going
to
be
a
non-starter
and
that
people
would
complain
about.
Why?
Don't
you
support
console,
or
these
seven
things
and
as
it
turns
out,
it's
actually
become
a
a
selling
point
and
I
I
think
people,
the
api's
I've
been
really
pleased
with
how
we've
evolved
them.
I
think
people
enjoy
actually
using
them
and
I
think
that's
the
way
that
we
keep
it
from
getting
totally
out
of
control.
A
A
Is
that
envoy
will
run
everywhere,
but
that
no
one
needs
to
know
we're
on
boy
actually
runs
so
I
think
that
there's
going
to
be
a
whole
suite
of
systems,
whether
it's
contour
or
you
know,
there's
there's
10
or
12
different
projects
now,
and
you
know
lots
of
companies
that
are
using
envoy
I,
don't
I
I,
see
envoy
as
a
building
block
that
gets
used
in
larger
systems.
So
you
know
I
think
from
a
feature
creep
perspective.
A
A
Yeah
and-
and
you
know,
that's
a
constant
struggle
and
there
are
things
for
example,
that
I
would
like
to
never
do
so.
I,
don't
know
that
we'll
ever
implement
cashing
in
envoy,
because
why
would
we
not
use
varnish
like
varnish
works
great?
Why
would
we
implement
a
full
web
server
and
envoy
and
your
NEX
works
great
right,
so
I
think
that's
where
we
have
to
draw
those
lines.