►
From YouTube: xDS Support in gRPC - Mark D. Roth
Description
xDS Support in gRPC - Mark D. Roth
The xDS APIs originated as Envoy’s control plane APIs, but they are evolving toward a Universal Data Plane API (UDPA) that can be used to configure any data plane client. gRPC is the first non-Envoy client to support obtaining its configuration via xDS. This talk will cover how gRPC fits into the xDS ecosystem. It will explain the advantages of supporting xDS in gRPC, particularly for service mesh deployments, and identify the set of xDS features that gRPC currently supports and the additional features that are on the roadmap. It will also discuss changes that were made to the xDS data model to support non-proxy clients like gRPC and various edge cases in the xDS transport protocol that were addressed along the way. The talk will also discuss how control plane operators and vendors can support gRPC xDS clients alongside Envoy.
A
Here's
what
we're
going
to
cover
today
we'll
talk
about.
Why
we're
doing
this?
What
changes
we
needed
in
the
xds
apis
to
support
non-proxy
client
like
grpc,
we'll
talk
about
some
gotchas,
we
discovered
in
the
xcs
transport
protocol
and
we'll
talk
about
what
management
server
maintainers
need
to
do
in
order
to
support
grpc
alongside
envoy
and
then
we'll
cover
our
current
status
and
roadmap.
A
A
So
here's
a
diagram
of
a
typical
service
mesh
topology
every
node
in
the
mesh,
has
an
envoy
instance
running
as
a
sidecar
right
next
to
the
application.
The
red
lines
here
are
data
plan
communication.
You
can
see
that
envoy
intercepts
all
traffic
in
and
out
of
the
application
and
manages
communication
between
the
nodes.
A
The
blue
lines
are
control,
plane,
communication,
the
envoy
instances
get
their
configs
from
the
xcs
server.
So
what's
the
problem
with
this
approach,
why
not
support
xds
and
grpc?
Well,
the
proxy's
add
overhead.
My
team
did
a
grpc
benchmark,
comparing
the
proxy
and
proxy
list
approach,
which
showed
about
a
three
times:
improvement
in
queries
per
cpu.
Second,
so
there's
a
significant
cpu
overhead
to
running
the
proxies,
there's,
also
a
significant
latency
improvement.
I
don't
have
specific
data
on
that.
Istio
does
have
some
data
that
shows
that
request.
A
Latency
is
significantly
higher
with
with
the
proxies,
although
their
benchmark
is
not
exactly
the
same
as
the
one
that
we
did
in
grpc.
It's
not
exactly
the
same
scenario,
so
it's
it's
a
little
bit
of
an
apple
storage's
comparison,
but
it's
the
best
data
that
I
have
to
share,
but
certainly
I
don't
think
anybody
would
doubt
that
there
is
additional
latency
by
by
adding
those
two
hops
for
all
the
communication.
A
These
features
to
separately,
however,
by
supporting
these
features
in
grpc
applications
that
use
grpc
can
get
these
features
for
free
without
the
cost
of
the
proxies.
And
so
that's
that's
really
the
motivation
here
now.
I
should
note
that
we
are
you
know.
The
motivation
here
is
is
not
to
try
to
put
envoy
out
of
business
right,
we're
not
trying
to
replace
envoy,
there's
still
going
to
be
a
whole
bunch
of
non-grpc
applications
that
that
will
need
envoy
and
frankly,
there
are
still
going
to
be.
A
A
So
here's
that
same
service,
mesh,
topology
diagram
as
before,
but
this
time
using
proxilis
grpc
instead
of
having
a
sidecar
proxy
on
each
node.
The
application
just
links
against
grpc
and
jpc
directly
provides
the
traffic
management
features
and
the
control
plane
integration
by
taking
in
the
configuration
from
xts.
So
there's
no
need
for
the
for
the
sidecar
proxy.
A
All
right,
let's
talk
about
what
changes
we
needed
to
make
in
the
xds
apis
to
make
this
work
now
the
xds
apis
were
developed
specifically
for
envoy,
so
they
make
the
obvious
assumption
that
the
client
is
envoy,
and
this
caused
some
challenges
for
us,
because
not
only
is
grpc
not
envoy,
but
it's
not
even
a
proxy
right.
It's
a
a
client
and
a
server.
A
You
know
xcs
configuration
resources
and
also
because
we
want
to
allow
grpc
and
envoy
to
easily
coexist
in
the
same
service
mesh,
as
I
mentioned
earlier,
so
the
more
that
we
can
use
the
existing
infrastructure
and
leverage
that
rather
than
having
to
create
new
stuff,
you
know
the
better.
So
we
really
want
to
minimize
these
changes,
but
there
are
two
places
where
android
and
grpc
are
sufficiently
different-
that
we
did
have
to
make
some
changes
and
we'll
talk
about
each
of
those
here.
A
The
first
thing
we
changed
was
the
way
that
the
jrc
client
handles
listener
resources.
Now,
as
you
probably
know,
the
main
xds
apis
are
lds.
Rds,
cds
and
eds
they're,
generally
chained
together
in
that
order
describing
the
path
that
request
takes
as
it
moves
through
envoy
and
it
all
starts
with
a
listener
resource
from
lds
which
tells
envoy
what
pork
to
listen
on
and
that
concept
simply
doesn't
apply
to
the
jrpc
client
right.
The
jvc
client
doesn't
listen
on
ports.
It
it,
you
know,
is
told
by
the
application.
A
You
know
to
send
requests
to
to
particular
virtual
hosts.
Now,
when
we're
first
looking
at
the
xds
api,
trying
to
understand
it
and
trying
to
figure
out
how
to
make
it
work
for
grpc.
Our
first
attempt
to
build
a
mental
model
was
sort
of
okay,
let's
figure
out
which
parts
of
the
api
apply
out
of
the
server
and
which
parts
apply
to
the
client
and
we'll
you
know,
use
those
in
the
appropriate
places.
We
thought
well.
Okay,
maybe
lds
and
rds
are
really
about
configuring.
A
Incoming
requests,
so
we'd
use
those
on
the
grpc
server
and
cds
and
eds
are
configuring.
Outgoing
requests,
so
we
use
those
on
the
grc
client,
so
it
turns
out.
This
doesn't
actually
work
most
of
the
configuration
that
we
actually
need.
That's
really
interesting
to
configure
things
on
the
grp's
client
is
actually
in
lds
and
rds.
This
is
things
like
you
know:
traffic
splitting
retries
timeouts,
that
sort
of
thing
things
that
we
really
do
want
to
set
on
the
client
but
they're
in
lds
and
rds.
A
A
This
includes
the
grpc
api,
which
is
basically
a
subset
of
http
functionality,
because
the
jrpc
protocol
is
actually
built
on
http
2..
The
hp
api
listener
should
be
noted
is
also
intended
to
be.
It's
not
jpc
specific.
It's
intended
to
be
used
by
envoy
mobile
in
the
future,
and
there
could
be
other
you
know,
http.
You
know,
xcs
aware
clients
that
might
use
it
in
the
future
as
well.
A
A
Now
the
configuration
of
an
http
api
listener
is
a
subset
of
the
socket
listener
configuration.
So
a
socket
listener
primarily
contains
a
list
of
l3
l4
filters
where
the
http
connection
manager
filter
is
the
last
filter
in
the
l3
l4
filter
chain,
and
then
it's
that's
where
all
the
l7
functionality
is
is
configured.
A
A
Now
the
the
second
change
other
than
introducing
an
api
listener.
The
second
change
that
we
made
for
grpc
and
xds
is
related
to
the
special
way
in
which
envoy
uses
lds
and
cds
envoy
uses
those
two
apis
differently
than
it
uses
the
other
xds
apis,
and
this
special
behavior
doesn't
really
make
sense
for
grpc,
so
the
the
general
xds
flow
for
envoy
is
when
it
starts
up.
It
immediately
sends
both
an
lds
and
a
cds
query
in
parallel.
These
basically
act
as
sort
of
dual
routes
for
on
voice
configuration
right.
A
A
Similarly,
when
it
receives
the
cds
response,
that
tells
it
what
eds
resources
it
needs
and
it
goes
and
requests
those
by
name
and
all
of
the
other
ancillary
xds
apis
work
the
same
way
as
rds
and
eds
right,
for
example,
vhds
is
chained
off
of
rds
and
again
envoy
asks
for
the
specific
resources
it
needs
by
name.
So
the
only
two
apis
that
are
really
special
here
are
lds
and
cds.
The
rest
of
them
are
all
quite
uniform,
and
lds
and
cds
are
special
in
sort
of
two
main
ways
number
one.
A
A
Is
that
envoy
automatically
makes
both
of
those
calls
at
startup.
This
kind
of
makes
sense
for
envoy,
because,
as
a
proxy,
you
know
not
something
that's
built
into
the
application
envoy
can't
have
any
way
of
knowing
a
priori.
What
ports
to
listen
on
or
what
upstream
clusters
it
may
need
to
talk
to,
and
so
it
needs
to
know
about
everything
it
might
ever
need.
So
you
know
so
so.
Making
these
queries
up
front
sort
of
makes
sense
for
envoy,
but
it
doesn't
really
make
sense
for
grpc
right.
A
Jrpc
is
built
into
the
application
and
when
the
application
creates
a
jrpc
client
channel,
it
creates
the
channel
to
a
particular
virtual
host.
So
the
application
knows
exactly
what
virtualist
it's
going
to
be
talked
to
and
going
to
be
talking
to,
and
it
knows
it's
not
going
to
need
anything
other
than
that.
So
we
don't
really
want
to
send
the
client
info
for
virtual
hosts
that
it's
never
going
to
use.
A
So
in
grpc,
the
xds
api
flow
is
a
little
bit
more
linear
when
the
application
creates
a
channel
to
a
virtual
host,
in
this
case,
server.example.com
the
that
triggers
grpc
to
go
and
make
an
lds
request
for
a
resource
of
the
same
name,
and
this
resource
will
be
an
http
api
listener
and
it
acts
as
basically
a
single
route
for
jrpc's
configuration
and
everything
else
is
chained
off
of
there.
So
the
lds
resource
tells
us
what
rds
resources
we
need.
The
rds
resource
tells
us
what
cds
resources
we
need.
A
The
cds
resources
tell
us
what
eds
resources
we
need,
so
in
effect,
jrpc
uses
lds
and
cs
exactly
the
same
way
as
the
other
xds
apis.
It
doesn't
do
the
special
stuff
that
envoy
does
right.
We
request
the
specific
resources
we
want
instead
of
making
wild
card
requests
and
we
don't
proactively
make
lds
and
cds
requests
at
startup.
The
lds
requests
happen
when
the
client
creates
a
channel
and
the
cds
requests
happen
when
we
get
an
rds
response.
A
A
A
I
don't
care,
I'm
just
sending
it
all
those
resources
right
and
if
you
do
that,
you
can
actually
get
away
with
that
and
that
should
work
pretty
much
fine
with
grpc,
but
it
turns
out
that
for
protocols
other
than
lds
and
cds,
the
xcs
api,
the
transport
protocol
is
actually
designed
such
that
the
server
really
only
has
to
send
resources
when
they've
changed.
So
if
you,
you
know,
if
the
client
is
subscribing
to
you
know
four
different
rds
resources,
and
only
one
of
them
is
change.
A
A
Now,
in
jrpc
we
try
to
make
things
easy
so
that
we
can
work
with
these
very
simple
xds
servers
by
saying
that
you
know,
even
though
we're
requesting
the
specific
resources
that
we
need
we're
going
to
ignore
any
resource
that
we
receive,
that
wasn't
one
of
the
ones
that
we
asked
for
right,
which
is
fine.
That
works
pretty
well.
A
But
there
are
a
couple
of
implications
about
this
that
you
need
to
be
aware
of
if
you're,
if
your
management
server
is
trying
to
be
more
intelligent
and
only
send
things
that
have
changed
right
so
number
one,
the
client
doesn't
doesn't
validate
the
resources
that
it's
going
to
ignore.
So
even
if
they're
invalid
jrpc
is
not
going
to
knack
them
and
number
two
jrc
is
not
going
to
cache
these
resources
right.
A
If,
if
the,
if
which
means
that,
if
a
resource
is
requested
later,
the
server
must
resend
it,
even
if
it
thinks
the
client
has
already
seen
it
right.
So
to
take
an
example
here,
let's
say
that
initially,
the
client
is
only
requesting
resource
a,
but
the
server
decides
to
send
it
resources
a
and
b
later
on.
If
the
client
requests
a
and
b,
the
server
needs
to
resend
b
instead
of
assuming
the
client
already
has
it
even
if
b
hasn't
changed
right.
So
the
client
has
to
be
aware.
A
Sorry,
the
server
has
to
be
aware
of
what
the
client
has
actually
subscribed
to
and
make
sure
that
it's
sending
it.
You
know
what
it
needs
when
it
requests
it.
This
isn't
much
of
an
issue
for
lds
and
cds,
since
they
actually
require
that
that
all
resources
are
present
in
every
response
anyway,
but
for
rds,
eds
and
all
the
other
apis,
because
the
server
can
send
only
those
resources
that
have
changed.
This
is
something
that
you
have
to
watch
out
for.
A
Unsubscription
is
also
kind
of
interesting
when
the
client
is
no
longer
interested
in
a
resource
that
can
unsubscribe
it
does
this
by
sending
a
new
request
with
the
resource
name
no
longer
present
in
the
request.
So,
for
example,
if
the
client
previously
sent
a
request
for
both
a
and
b
and
now
it
wants
to
unsubscribe
to
b
it'll
send
a
new
request.
A
That
includes
only
a
now
there's
an
edge
case
here,
which
is
sort
of
interesting,
which
is
what,
if
the
client
is
subscribed
to
only
one
resource
of
a
particular
type
and
it
wants
to
unsubscribe.
Well,
so
then
it's
going
to
send
a
request
where
the
research,
the
resource
names
list
in
the
request,
is
empty,
which
is
actually
exalted
the
same
way
that
it's
exactly
the
same
way
that
the
protocol
indicates.
These
wild
card
queries
that
envoy
uses
for
lds
and
cds.
A
So
the
answer
is
that
a
the
way
you
deal
with
this
is
that
a
request
with
no
resource
names
is
interpreted
as
a
wildcard
query.
Only
on
the
first
request
for
that
resource
type
on
a
stream.
So
the
decision
to
use
wildcard
query
can
only
be
made
at
the
beginning
of
a
stream
if
a
client
has
previously
sent
a
request
with
none
empty
resource
names
list.
A
subsequent
request
with
an
empty
list
means
unsubscribe
to
all.
It
does
not
mean
wild
card,
so
management
servers
need
to
be
careful
to
get
this
right.
A
There
are
a
lot
more
gotchas
in
the
transport
protocol
that
we
ran
into
as
we
were
trying
to
to
understand
it.
There
were
actually
quite
a
few
edge
cases
and-
and
you
know
interesting
things
that
are
that
are
sort
of
emergent
behavior
of
of
some
things
that
have
been
put
in
the
protocol,
so
I
I'm
not
gonna
cover
them
all
here.
A
I
don't
have
time
to
get
into
all
of
them,
unfortunately,
but
what
I
did
do
is,
as
we
ran
into
these,
we
worked
with
the
envoy
community
to
update
the
xds
documentation
to
explain
how
how
these
various
edge
cases
are
supposed
to
work
and
how
clients
and
servers
are
supposed
to
to
react
when
they
encounter
them.
So
for
anybody
writing
your
own
xds
server,
I
strongly
or
or
just
client
for
that
matter.
I
strongly
encourage
you
to
to
read
the
xds
spec.
A
A
Imagine
that
you
have
this
existing
configuration
for
use
with
envoy
we've
got
a
tcp
listener
resource,
that's
pointing
to
a
route
configuration
and
that
route
configuration
defines
three
virtual
hosts
and
let's
say
that
you've
got
grpc
traffic.
That's
currently
going
through
envoy
to
those
virtual
hosts,
and
now
you
want
to
switch
to
proxy
list
grpc.
How
do
you
do
it
so
to
do
that?
You
need
to
add
an
http
api
listener
for
each
of
the
virtual
hosts.
A
Now,
as
mentioned
earlier,
the
http
api
listeners
don't
have
l3
l4
filters
in
their
configuration,
it's
just
the
http
connection
manager
and
so,
but
the
configuration
in
the
http
api
listeners
can
point
to
the
existing
rds
resource,
which
can
be
shared
between
jrpc
and
enviro.
You
don't
have
to
duplicate
that
in
most
cases,
and
once
you
have
the
new
resources
set
up,
all
you
need
to
do
on
the
client
is
there's
a
bootstrap
file
that
needs
to
be
created.
A
A
Now
grpc
does
validate
and
cache
the
entire
route
configuration
right,
so
it
can't
ignore
virtual
hosts
other
than
the
one
that
that
caused
it
to
look
at
the
route
configuration
because
the
application
might
later
create
a
channel
to
another
virtual
host
that
might
refer
to
the
same
route
configuration
right
in
the
example
on
the
last
slide.
If
initially,
the
application
only
opens
a
a
channel
for
service,
one
it'll
get
the
route
configuration
that
has
all
three
virtual
hosts
in
it
and
then
later.
A
If
it
opens
the
channel
to
service
two
now
it's
got
a
new
listener
resource.
That's
pointing
to
that
same
route.
Configuration
which
is,
you
know,
already
includes
the
information
for
service
two.
So
we
have
to
cache
this
and
validate
it
up
front
so
that
we've
already
got
it
when
when
it.
Actually,
you
know
if
it's
going
to
be
used
later
now
this
it
does
take
up
a
fair
amount
of
memory
in
grpc
to
store
all
this
information.
A
So
you
know,
if
you're,
in
a
situation
where
the
route
configuration
includes
a
really
large
number
of
virtual
hosts,
but
grpc
is
only
ever
going
to
use
a
small
subset.
One
way
you
can
avoid
giving
jrpc
all
this
information
that
it
doesn't
need
is
to
just
inline
the
relevant
part
of
the
route
configuration
into
the
http
api
listeners.
That
way,
each
listener
only
grabs
the
information
for
the
one
virtual
host
that
that
it
it
cares
about,
and
everything
just
works.
A
You
might
also
run
into
a
case
due
to
a
a
bug
or
a
mismatching
behavior
or
something
where
jrpc
might
reject
a
config.
That
envoy
would
be
okay
with
right.
So
let's
say
that
you
have
a
route
configuration
that
has
one
virtual
host
that
is
used
by
grpc
and
another
virtualist,
that's
used
only
by
envoy
and
jrpc
is
you
know
for
some
reason
rejecting
the
config,
because
the
one
that's
meant
for
envoy,
even
though
grpc
will
never
use
it,
is,
is
somehow
getting
rejected.
A
If
that
happens,
that
then
moving
the
relevant
part
of
the
right
configuration
into
the
http
api
listener
is
also
a
decent
workaround.
We
hope
you
shouldn't
need
to
do
this.
I
only
know
of
one
case
today
where
it's
a
problem,
I'll
mention
it
later,
it's
something
that
we're
going
to
be
fixing.
So
if
you
run
into
this,
this
is
a
possible
workaround,
but
also,
let
us
know
because
we
want
to.
We
want
to
avoid
the
need
to
actually
do
this.
A
It's
just
something
to
keep
in
your
back
pocket
in
case
you
need
it,
and
you
do
of
course,
need
to
support
non-wildcard,
lds
and
cds
requests,
which
envoy
will
never
make
but
grpc
does.
This
will
mostly
be
a
no-op
for
cds,
because
even
if
you're
doing
a
pure
state
of
the
world
response,
where
you
always
send
all
the
resources,
you
know
that
should
work
just
fine
in
lds.
A
The
one
thing
you
need
to
be
aware
of
is
that
you
need
to
make
sure
not
to
send
the
api
listener
resources
to
envoy
when
it
makes
its
wild
card
requests,
because
it
won't
know
what
to
do
with
them
all
right
and
so
finally,
let's
talk
about
our
current
status
and
roadmap
for
those
that
may
not
know,
there
are
actually
four
variants
of
the
xcs
transport
protocol,
there's
two
different
dimensions:
aggregated
versus
non-aggregated
and
state
of
the
world
versus
incremental.
So
you
know
every
combination
of
those
yields.
A
A
We
support
xds
right
now
in
the
jrc
client,
only
not
yet
in
the
grpc
server,
although
that's
as
you'll
see
on
one
of
the
next
slides
that
is
in
the
works,
and
you
can
see
the
list
of
features
that
we
currently
support
here.
With
a
few
noted
limitations,
the
one
I
will
mention
I
want
to
call
out
is
in
route
matching
the
case
sensitive
field,
as
I
mentioned
earlier.
This
is
the
one
case
where
jpc
will
currently
reject
the
config.
A
Here
is
a
list
of
features
that
are
on
our
roadmap.
We've
already
started
implementing
timeout
and
circuit
breaking
support
and
a
bunch
of
others
shown
here
are
in
our
pipeline.
You
can
watch
our
proposal
repo
to
get
notifications
when
we
post
grfcs,
which
are
jrpc's
design
proposals
we
the
one
thing,
that's
that
we
know
is
coming
in
the
not
too
distant
future
that
we
don't
yet
have
an
answer
for,
but
we're
gonna
be
really
thinking
about
hard
is
how
do
we
support
http
filters
in
in
grpc?
A
I
would
encourage
you
to
file
bugs
in
our
repo
if
there
are
features
that
you
need
that
either
we
haven't
done
yet
or
aren't
on
our
roadmap.
I
can't
promise
that
we
will
prioritize
whatever
you
need,
but
it
will
be
very
useful
for
us
to
know
what
features
users
want
here
that
will
help
guide
our
development
and,
of
course,
if
you
want
to
contribute
to
the
implementation,
we
can
help
guide
you
in
in
doing
that
as
well.
A
Jpc
has
three
main
implementations:
we
have
native
implementations
in
both
java
and
go
and
there
is
a
c
core
implementation
which
is
used
as
the
underlying
implementation
for
all
the
languages
that
you
see
here.
I
should
note
that
in
c
sharp
there
are
actually
two
different
implementations,
there's
the
one
that
we
provide,
that
is
wrapped
around
c-core,
and
there
is
a
separate
native
c-sharp
implementation
for
net
that
is
written
by
microsoft.
That
implementation,
as
far
as
I
know,
does
not
yet
have
xds
support.
A
A
There
are
a
few
control
planes
that
work
with
proxies
grpc
google's
traffic
director
control
plane
is
the
main
one
that
we
develop
and
test
against,
and
you
can
look
at
this.
The
the
link
here
goes
to
a
blog
post
that
talks
about
google's
traffic
director
product
and
and
how
it
works,
and
what
it
supports.
A
Istio
also
has
some
basic
experimental
support
for
proxies
grpc.
They
don't
have
any
documentation
for
it
yet,
but
they
do
have
sort
of
a
test
that
shows
that
it
works.
So
I
would
encourage
people
to
sort
of
file
bugs
against
istio.
If
that's
you
know,
if
this
is
something
you
actually
want
to
use
in
production,
you
know
the
more
bugs
you
you
know.
A
So
I
want
to
leave
you
with
one
final
thought.
Until
now,
there
was
only
one
xgas
client,
which
was
envoy
now
with
grpc.
There
are
two,
but
I
think,
there's
gonna
be
more
in
the
future.
I
don't
think
this
is
the
last
one.
I've
already
heard
of
a
couple
of
cases
where
people
have
been
talking
about
building
an
xds,
aware,
http,
client
library
and,
as
I
mentioned
earlier,
there
will
likely
be
cases
where
people
will
want
xts,
aware
sql
clients.
A
So
you
know,
and
I
suspect
that
there
will
be
even
other
use
cases
in
the
future
that
we
haven't
thought
of
yet.
So
I
think
this
is
a
really
exciting
time
for
the
xcs
ecosystem.
I
think
it's
becoming
richer
and
more
varied
and
I'm
really
excited
to
see
where
it
goes.
So,
with
that
I
will
take
questions.
Thank
you.