►
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.
Feature Work In GRPC; XDS And Not - Eric Anderson & Kevin Nilson, Google
Speakers: Eric Anderson, Kevin Nilson
gRPC provides services with high performance communication to use in many environments. Much of the recent work in gRPC has involved xDS (https://github.com/cncf/xds), a collection of control plane protocols that can configure data planes like Envoy and gRPC that is becoming popular to use in datacenter service meshes. The work is just past a turning point with the foundational features implemented in gRPC. In this session we'll discuss how all users, those that use xDS and those that don't, can benefit. We will cover newer features and how they achieve their goals using the cross-language xDS gRPC architecture.
A
B
So
I'm
Eric
Anderson-
this
is
Kevin
Nelson
and
we'll
be
talking
to
you
about
future
work
in
XDS,
I'm.
Sorry,
Feature,
work
in
grpc
XTS,
not
we'll,
go
ahead
and
get
started
with
some
just
sort
of
what's
new
in
grpc
and
stuff,
because
we
don't
have
another
talk
and
it'll
it'll
sort
of
set
some
of
the
stage
and
then
and
Kevin
will
do
that
and
then
I'll
get
you
into
the
XDS
and
not
portion.
A
So
before
I
kind
of
jump
into
things,
I
did
want
to
call
out
a
few
people
in
the
audience
and
if
you
are
a
grpc
maintainer
raise
your
hand,
so
we
got
a
bunch
of
folks
from
the
team,
and
so,
if
you
basically
have
questions
afterwards
or
want
to
Deep
dive
or
follow
up
with
them,
feel
free
to
do
that.
So
raise
your
hand
one
more
time
as
people
know
why
they're
raising
the
hand
cool,
so
those
are
our
maintainers
I
am
curious.
A
B
A
You
see
up
on
the
on
the
board
here.
One
of
the
things
that
we're
doing
is
something
we
call
the
developer
facilitation
meetings
and
it's
kind
of
a
weird
name,
but
really
what
it
means
is
we
sit
down.
We
got
a
bunch
of
questions,
we'd
love
to
hear
about.
You
know
what
you're
doing,
how
you're
using
jrpc.
B
A
Cool
thanks,
sir,
so
the
next
thing
I
wanted
to
talk
about
a
little
bit
is
basically
you
know
the
the
help
that
we
want
from
all
of
you
and
what
you
can
do
to
sort
of
be
part
of
evolving
grpc
and
making
it
successful.
And
you
know
one
of
the
things
that
we
do
within
the
team
is
for
each
of
the
individual
languages
for
grpc.
A
We
go
through
and
review
all
the
issues
and
all
the
the
pull
requests
every
single
week,
and
so
it's
one
person
per
language
and
what
we
do
is
is
we
assign
a
different
person?
We
call
it,
you
know,
like
a
rotation
and
that
person
goes
through
reads
the
issues
and
tries
to
triage
them,
get
them
assigned
to
the
right
person,
and
then
we
meet
as
a
team
where
they
go
through
these
issues.
A
These
pull
requests,
talk
about
them,
get
advice
from
others
and
really
what
I'm
highlighting
is
just
how
serious
we
take
it
and
how
much
time,
and
so
please,
if
there
is
something
you
don't
like,
if
there
is
something
you
feel,
we
should
be
doing
better.
If
you
think
there's
a
bug,
please
put
that
in
we
would
you
know
we
would
love
to
to
try
to
fix
it.
Try
to
make
things
better
as
best
we
can
yeah
quick
question.
A
Yeah,
so
let
me
repeat
the
question,
so
everybody
can
hear
it.
So
the
question
was:
how
do
we
keep
parity
among
among
the
different
languages
and,
among
you
know,
all
the
different
releases,
so
I'm
gonna
say
there's
two
types
of
issues
that
get
raised.
One
of
them
is:
there's
a
memory
leak
and
go
right,
and
that's
what
a
you
know
there's
some
other
problem
in
Java
where
it
doesn't
follow.
You
know
whatever
it
is,
and
they
a
lot
of
the
issues
tend
to
be
very
language.
Specific.
A
A
lot
of
the
work
that
we
do
is
keeping
things
modern
for
any
of
the
particular
languages
that
really
don't
have
to
do
with
the
overall
kind
of
underlying
architecture.
When
we
do
have
issues
that
are
feature
requests
and
things
like
that,
we
prioritize
them.
We
do
them
and
I
would
say
we
we
at
least
make
an
attempt
to
launch
features
together
in
every
language
or
at
least
the
languages.
A
We
call
supported
languages,
but
that's
something:
that's
nice
to
have
not
a
must-have
and
so
we'd
rather
get
the
features
out,
especially
if
we
know
someone
is
using
a
particular
language
and
they
want
it
and
need
it,
and
we
push
that
forward
like
that.
We
take
a
ton
of
pull
requests
from
outside
the
team.
So
you
know
just
as
part
of
the
triage
process
we
bring
those
in
and
you
know
and
merge
in
all
of
those
and
so
definitely
feel
encouraged.
A
If
there
is
something
you
know,
if
you
have
forked,
don't
keep
it
private
share
it
back,
because
you
know
a
whole
team
of
people
that
that's
what
we
do
and
the
last
point
you
know
we
would.
We
would
love
to
graduate
from
incubator
status
and
one
of
the
things
that's
super
super
important
to
make
that
happen,
but
also
is
something
we're
interested
in
in
general
is
having
more
maintainers
and
folks
that
aren't
Google
employees.
A
Cool
I
wanted
to
share
kind
of
at
a
glance
some
of
the
the
more
recent
achievements.
So
these
are
things
kind
of
from
the
last
year.
Last
six
months
or
so
you
know,
we've
we've
reached
66
000
stars
on
GitHub.
So
really
really
you
know.
People
are
really
happy
and
and
they're
kind
of
looking
into
the
internals
right
and
they're
trying
to
to
learn
more
about
it
and
trying
to
follow
the
releases
and
things
and
deeply
engaged.
A
A
You
know
still
very,
very
healthy
there
as
well
and
so
very
active
project,
doing
a
whole
lot
as
we
go
and
then
for
our
proxylist
server
mesh
product.
We
have
a
bunch
of
different
features.
We
launched
observability
that
I'll
talk
about
in
in
another
another
two
slides
and
we're
we're
launching
some
custom
load.
Balancer
policy
stuff.
Some
folks
in
the
room,
were
very
instrumental
in
making
the
request
for
that,
and
we
want
to
make
that
available
ability
for
custom,
metrics,
retries
Authority
and
some
outlier
detection.
A
So
these
are
some
of
the
key
features
that
launched
in
either
the
last
couple
months
are
about
to
Launch,
so
really
exciting,
stuff
good
momentum
across
the
team.
We're
super
proud
that
not
only
this
week
were
we
at
kubecon,
but
we
were
also
at
API
world,
so
one
the
microservices
best
in
microservices
infrastructure
award
there,
and
so
that
was
a
cool.
You
know
just
a
cool
little
thing
that
we're
we're
happy
and
proud
about
and
appreciate
that
that
has
happened
now.
A
I
want
to
share
some
of
the
the
numbers
just
so
you
can
see
the
scale
of
adoption
and
usage
and
it's
becoming
a
real
industry
standard
across
the
board.
You
can
see
for
mpm
having
5
million
weekly
downloads
of
our
JRP
CJs
package
for
Pi
Pi,
two
million
times
a
day.
You
know
the
downloads
and
it's
number
52
most
downloaded
package
on
bipi,
which
is
pretty
impressive
for
for
what
we
are
and
then
Java
for
Maven
12.5
million
downloads
a
month
of
grpc
context,
and
so
these
are
really
really
impressive
numbers.
A
We're
really
happy
with
it.
I
hope
everyone
will
continue
to
to
help
us
grow
those
numbers
and
use
grpc.
For
more
and
more
of
the
things
that
they're
doing-
and
this
is
another
chart-
that's
pretty
cool
is
the
star
history.
So
this
is
from
our
jrpc
core
project
and,
as
you
can
see,
just
continues
to
grow
with.
You
know,
really:
no,
no,
no
end
in
sight.
It's
it's
just
continuing
to
grow,
and
so
we're
real,
happy
and
excited
about
this,
and
you
know
want
to
make
sure
everyone
realizes.
A
You
know
this
is
where
grpc
is
it's.
It's
very
stable,
very
well
used
and
continue
to
grow,
with,
with
big
Investments
from
Google
and
from
our
external
developer.
Community
I
wanted
to
talk
a
little
bit
about
the
observability
project
that
we
launched.
So
we
launched
a
public
preview
on
Friday,
so
Friday
at
5
PM.
When
you're
not
supposed
to
go
on
software,
we
launched
it
having
it.
A
You
know
we
really
put
in
a
lot
of
effort
and
I
want
to
thank
the
team
for
that
and
and
everything
that
they
did
making
this
possible
and
got
that
out
there
and
really
what
it
is.
You
know
it's
a
it's
a
public
preview,
which
means
you
know
our
first
set
of
core
MVP
features
we
have
in
place,
and
we
really
believe
that
it's
something
you
know
the
apis
aren't
going
to
change
that
much.
A
We
think
it's
ready
for
folks
to
use,
but
at
the
same
time
it's
a
great
opportunity
to
work
with
us
as
we
you
know,
work
towards
GA
early
next
year,
and
so
we
would
love
to
work
with
any
of
you
on
this
product.
You
know
currently
we're
supporting
logs
and
stackdriver
or
Google
Cloud
logging.
We
have
a
bunch
of
analytics
dashboards
that
are
available
alerts
and
notifications
and
traceability,
and
so
you
know
one
of
the
most
powerful
and
interesting
things
here.
A
I
think
is
the
alerts
and
notifications
where
you
can
set
a
threshold
on
either
a
percentage
of
failures
or
response
time
or
whatever
it
is
and
set
yourself
up
for
an
email
or,
however,
you
want
to
be
notified
so
that
you
can
learn
about
these
things
through
a
private
email
that
came
right
away
rather
than
learning
about
them
on
Reddit.
So
that's
our
new
observability
project
and
you
know,
would
love.
B
B
Basically,
it's
a
control
plane
protocol
to
configure
a
mesh
or
a
bunch
of
different
nodes.
It's
it
came
out
of
envoy
and
it
was
how
different
control
planes
could
configure
Envoy
as
the
sidecar
or
that
sort
of
idea
or
a
reverse
proxy.
For
that
matter.
It
is
basically
just
a
watch-based
API
to
get
configuration
updates.
B
The
X
may
be
like,
what's
what's
up
with
that,
so
overall
XDS
stands
for
some
variable
Discovery
service
and
that
variable
might
either
by
a
listener
or
cluster
or
route
an
endpoint.
It's
not
too
important
to
know
all
those
unless
you
want
to
start
making
your
own
control
plane,
but
so
one
particular
XDS
would
be
listener,
Discovery,
service
or
LDS
and
we'll
throw
around
terms
like
LDS
EDS
CDs,
these
sort
of
things
all
the
time
and
then
we're
talking
about
listeners
clusters
or
whatever
would
be
related
to
that.
B
So
now
we
have
an
idea
of
what
XDS
is:
let's
sort
of
shift
to
Features
here's
a
sort
of
sampling
of
features
from
the
last
year.
It's
not
too
important
exactly
which
features
I've
selected.
It's
meant
to
be
a
sampling,
although
this
is
a
lot
of
the
higher
profile
ones,
so
we'll
just
sort
of
go
through
them
give
a
little
bit
of
description.
What
they
are,
so
we
sort
of
know
what
we're
talking
about,
but
we'll
just
sort
of
see
how
these
impact
grpc
and
how
they're
sort
of
done
so
RPC
retries.
B
You
want
to
know
exactly
which
other
services
can
contact
it,
and
so
you
can
restrict
only
let's
say:
Service
A
and
B
can
contact
service,
C,
outlier
detection,
it
monitors
rpcs
and
for
each
back
end
it
will
sort
of
say.
Oh
look.
This
back
end
looks
a
little
unhealthy.
A
lot
of
rpcs
have
failed
on
it
compared
to
other
backends
and
so
it'll
decide
that
this
back
in
maybe
an
outlier
and
decide
not
to
send
new
rpcs
to
it
least
request
lb.
B
We
just
have
this
in
Java
right
now,
but
it's
very
similar
to
the
round
robin
load
balancer
that's
round.
So,
instead
of
just
choosing
the
next
server
in
the
list
and
just
round
robin
over
and
over
this
one
looks
at
how
many
outstanding
requests
each
back-end
has
already
from
that
client
and
it
will
send
it
to
the
server
that
has
the
least
outstanding
requests:
custom,
locality,
lb.
This
is
sort
of
a
bring
your
own
load
balancer.
B
If
you
want
to
make
your
own
load
balancer
you
implement
it,
and
then
this
is
some
of
the
plumbing
to
use
it
from
XDS
and
then
custom,
back-end,
metrics
sort
of
plays
into
that
it's
a
little
different
than
the
others,
but
because
it's
it,
it
ties
heavily
into
the
custom
lb
policy,
but
it
allows
the
client
and
the
server
to
exchange
utilization.
Mainly
the
server
can
tell
the
client
here's
my
CPU
utilization
and
then
like
the
load
balancer
on
the
client
could
decide
which
back-ends
to
go
to
based
on
that
utilization.
B
B
So
we've
been
doing
XCS
for
a
little
while
now
and
we've
gotten
pretty
good
at
figuring
out.
Okay,
there's
this
particular
set
of
features
in
XDS.
How
will
that
end
up
being
done
in
grpc,
and
so
this
isn't
to
memorize
or
anything
like
that?
Let's
just
give
an
idea
that
these
are
the
sort
of
the
mappings
that
we
generally
do
so
there's
this
thing
in
in
XDS
called
a
listener
that
will
turn
tend
to
be
credentials
and
configuration
for
credentials.
That's
like
the
TLs
thing
route.
That's
going
to
be
service.
B
B
Those
last
two,
the
the
lb
policies
and
the
interceptors-
that
is
where
most
new
features
go
and
that's
good,
because
that
is
the
predominant
plug-in
architecture
where
you
can
inject
code
into
grpc,
and
so
us
doing
needing
to
do
most
features
in
those
last
two
lb
policies
and
interceptors
means
that
that
fits
in
actually
pretty
well
with
grpc.
Overall,
don't
be
memorizing
this.
This
is
a
diagram
from
a
recent
grfc.
Grc
is
our
change
proposal
process.
B
So
the
important
thing
to
note
is
there's
a
lot
of
green
here.
Every
green
box
is
an
lb
policy
and
they're
sort
of
constructed
into
a
big
tree.
The
big
tree
is
not
actually
bad.
In
my
mind
to
me,
this
diagram
shows
two
things:
one.
The
plug-in
system
is
working,
we're
able
to
put
quite
we're
able
to
inject
quite
a
bit
of
functionality
into
grpc
through
the
plug-in
mechanism,
and
so,
if
you
don't
want
some
of
this,
you
don't
you're
not
going
to
end
up
using
it.
B
B
So
XDS
only
I
was
talking.
These
are
XDS
features.
How
do
these
particular
features?
Look
like
if
you
don't
care
about
that.
Xds
thing:
why
is
it
not
going
there?
We
go
so
to
do
that.
We
need
to
talk
about
that
mapping.
So
RPC
retries
end
up
being
service
config.
We
already
had
some
retry
work
before
XDS,
and
so
XCS
is
able
to
just
configure
that
existing
functionality
that
we're
already
working
on
TLS
security,
though
it's
going
to
be
credentials,
authorization
is
going
to
be
an
interceptor.
The
next
three
are
all
load
belt.
B
Sorry,
the
next
three
are
all
load
balancers
and
that
last
one
I
mentioned
is
a
little
bit
weird,
it's
more
of
an
API,
but
it
interacts
mostly
with
the
load
balancers
and
interceptors,
except
for
those
two
toward
the
top.
Everything
else
is
actually
not
tidext.
Yes,
it's
pretty
XDS
independent
they're.
B
Whenever
we're
implementing
it,
there
will
potentially
be
some
XDS
glue
that
we
put
in
so
like
the
actual
implementation
process
for
XDS
might
have
some
code,
but
that
is
that
specific
to
XDS,
but
that's
just
Plumbing
these
things,
the
core
of
the
functionality,
is
available
outside
of
XDS,
and
you
get
to
see
some
things
like
that
in
the
grfcs
which
I
mentioned
were
our
change
proposals.
Outlier
section
says
that
it
is
usable
by
non-xds,
grpc
users
and
least
request
lbs
says
it
can
be
used
without
XDS
in
the
future
in
the
future.
B
We'll
come
back
to
that.
So
we've
got
all
these
things.
How
about
those
two
at
the
top?
What
what
about
those?
Why
were
those
sort
of
more
XDS
specific,
so
credentials
are
a
little
interesting
in
that
they
don't
have
any
configuration
sort
of
plumbing
and
grpc
themselves?
Normally
you
construct
them
with
an
API.
Then
you
pass
them
into
grpc
and
we
don't
want
a
generic
API
generally
for
credentials,
because
you
shouldn't
be
getting
that
elsewhere.
You
don't
want
to
look
up.
B
Oh,
how
should
I
connect
via
TLS
from
DNS
and
then
like
like?
What's
what's
the
point
you
that
DNS
is
not
secure,
you
might
as
well
just
be
using
be
using
plain
text,
so
these
sorts
of
things,
instead
of
having
you
tying
exactly
into
the
same
code,
flows
that
we'll
use
for
XDS.
Instead,
there
will
be
an
alternative
implementation,
separate
or
not
necessarily
alternative
implementation,
but
definitely
separate
apis
I
would
use.
Sometimes
it's
separate
implementation,
sometimes
not,
and
so
in
this
case
it'd
be
the
advanced
TLS
apis
that
we
use
service
authorization.
B
This
one's
a
little
bit
special,
though
because
the
configuration
that
XDS
provides
is
actually
really
really
expensive,
and
we
do
not
want
to
provide
that
for
for
a
very
long
time,
term,
support
and
so
for
this
API.
Whenever
we
exposed
it
to
grpc
users,
not
using
XDS,
it
is
a
much
simpler
API.
It
still
uses
the
same
engine
behind
the
scenes,
but
it
doesn't
have
absolutely
everything
some
parts
of
it.
You
just
don't
need
it's
for
rest
things,
so
that
just
aren't
very
interesting
or
reverse
proxy.
B
Just
who
knows
what
that
traffic
is
they've
got
a
lot
of
various
features.
Other
things
you
might
be
like,
oh,
that
might
be
a
little
more
interesting,
I
wish
that
was
added.
That
could
still
happen,
but
it
was
sort
of
taking
everything
overall.
Looking
at
all
the
features
that
we
were
talking
about
and
you're
like
I,
really
wish
this,
this
feature
was
not
available.
I
could
just
use
it
outside
of
XDS.
Why
is
it
not
or
something
the
the
biggest
reason
most
likely
is
that
no
one's
asked
for
it.
B
We
do
definitely
care
a
lot
about
what
people
are
asking
for,
and
so,
if
you're
interested
heck
for
a
feature
in
XDS
or
feature
outside
of
XTS-
and
you
see
there's
something
on
the
other
side
or
interested,
then
it's
mainly
probably
no
one's
asked
for
it.
If
people
are
asking
for
it,
then
a
lot
of
these
are
pretty
easy
to
expose
in
the
other
Realm.
B
If
it's
not
that,
though,
then
there's
two
normal
sort
of
cases
or
not
normal,
but
the
two
outlier
cases
would
be
it
integrates
too
tightly
into
XDS
in
some
way.
There
is
quite
a
lot
of
configuration
and
sometimes
they
will
assume
other
parts
of
the
system.
Xds
has
its
own
architecture
and
some
things
we
just
don't
have
an
analogous
Concept
in
grpc
so
clusters.
B
For
example,
we
have
those
they
work
in
the
XDS
space,
but
there's
a
bunch
of
XDS
specific
Plumbing
to
make
that
happen,
and
it's
just
not
a
concept
that
makes
sense
whenever
you're,
not
in
that
space.
There
will
be
some
different
concept
that
you
will
probably
have
to
create
for
that,
and
then,
as
I
said,
some
some
things
are
just
really
expansive
in
XTS,
it's
a
very
large
API
and
XDS
does
have
the
potential
to
change
some
over
time
as
more
people
use
it.
C
B
C
B
So
so
the
question
so
Envoy
grpc
does
have
interceptors.
Those
are
very
very
similar
to
to
the
filters
that
exist
in
Envoy
and
those
are
very,
very
heavily
used.
So
that's
the
number
one
interception
point
in
in
Jefferson
where
in
injection
Point
there
are
some
other
things
like
load,
balancing
policies
which
are
eventually
maybe
going
to
be
pluggable
and
Envoy
as
well,
but
they're
definitely
pluggable
in
grpc,
well,
mainly
in
the
in
go
in
Java
and
then
name.
A
Time,
yeah
and
we
are
basically
out
of
time
and
so
Eric
and
I
will
be
out
in
the
hall,
along
with
all
the
other
maintainers
on
grpc,
and
so,
if
you
do
have
questions
meet
us
out
in
the
hall
we'd
love
to
meet.
You
talk
to
you
and
help
answer
your
questions.
So
thanks
very
much
everyone.
Thank
you
for
coming.