►
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)
Introduction to Istio Configuration - Joy Zhang, Google (Beginner Skill Level)
Istio is an open platform that allows the operator to turn workloads into "services" by intent-driven configurations without rewriting/redeploying them. Istio configuration provides the operators central controls to these diverse workloads regardless of what environments they run in, or where they run. In this talk, we introduce how Istio configuration is designed to meet the goals of an easy-to-use schema, access controlled API, and performant system components at scale. We cover the automations Istio provides to ease a wide range of operators' tasks on multi-environment deployments, such as configuration authoring, configuration resource life-cycle management, monitored and safe configuration distribution.
About Joy
Joy is a software engineer at Google and a technical lead of the Istio Config Working Group. She also contributes to Istio service broker and Istio integrations. Prior to that, she spent 10+ years in software development and research across a variety of areas: mobile clients, data analytics, and optical networks. Joy received her PhD in Electrical and Computer Engineering from University of Illinois, Urbana-Champaign. She currently lives in Kirkland, Washington with her husband and 3 kids.
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.
A
My
name
is
joy
and
I'm,
working
for
Google
I'm,
a
self
engineer
and
currently
I'm
one
of
the
tech
lead
and
is
to
configure
working
group.
So
this
talk
is
pretty
much
capture.
What
we
have
in
discussions
going
on
in
our
working
groups
and
I'm
very
excited
to
be
here
and
introduce
you
guys
about
these
two
configurations.
A
A
A
A
So
what
what
what
exactly
that
means?
So
let
me
go
to
a
little
more
detail.
What
is
you
can?
Do
you
still
allows
you
to
switch
traffic
through
your
prod
and
your
Canaries
allowed
to
switch
your
security
protocols,
em
tos
on
em
tos
or
exposing
a
external
service
endpoints
or
specify
a
API
spec
or
at
the
rate,
limiting
kotas
monitoring
metrics
many
of
those
all
without
the
dev
work.
You
can
do
all
of
this
through
configurations.
A
So
let's
go
to
be
the
deeper
in
this
architecture,
so
those
solid
lines
represent
a
possible
runtime
data
flow.
You
can
think
of
data
plan
traffic's
and
when
some
of
the
Android
proxies
will
be
configured
as
ingress
basically
allows
you
to
accepting
traffic
requests
outside
the
mesh
and
they
do
some
writings
and
security,
determinations
and
others
and
gets
the
traffic
inside
of
the
mesh.
What's
the
inside
of
the
mesh
between
the
mesh
traffic
is
they're
going
to
go
through
the
side,
cars
and
the
side
cars
can
be.
A
Conflict
also
allows
services
workloads
to
talk
to
you,
services
outside
of
the
mesh.
We
call
it
the
foreign
services,
we
have
three
main
sto
components:
that's
sits
on
the
control
plan.
We're
gonna
have
more
than
that
in
future,
but
now
we
have
three
so
pilot
is
the
main
configuration
engine?
That's
a
supplies
to
come
fix
to
sidecars.
A
Citadel
is
the
security
authority.
Basically,
it's
a
provision
certs
and
for
those
on
services
allows
them
to
connecting
security.
So
you
see.
Even
those
component
is
two
components.
We
call
system
services
the
rhombus
on
the
sidecar,
so
they
can
be
conscious
through
security
communications
and
these
two
policies
as
well
mixer
is
the
policy
engine
of
each
do
so.
The
sidecar
at
the
runtime
will
send
the
checks
and
the
reports
to
mixer
and
the
mixer
has
an
adapter
model
that
allows
you
to
be
able
to
extend
those
policy
checks
using
your
favorite
enforce
your
backhands.
A
They
do
quotas,
you
can
have
your
own
coded
servers
or
you
have
some
coded
server
running
on
the
cloud
mixer
can
can
can
help
you
to
use
that
through
adapters.
So
you
see
some
of
the
services
like
a
stack
driver
is
a
google
cloud
service
and
the
mixer
has
the
stack
driver
that
there
allows
you
to
send
your
metrics
just
under
logs
to
stack
driver
and
your
missus
and
and
your
only
even
your
own
infrastructure
backends.
A
This
describes
the
current
the
configuration
architecture
and
II
still
has
our
configuration
is
built
on
kubernetes
extensible
resource
model
called
CRD,
and
until
today
we
only
use
the
very
basics
of
the
CRTs.
It's
a
pretty
much
configuration
storage
and
components
like
a
mixer
and
pilots.
They
gets
configurations
through
the
watch
API
and
we
having
a
galley,
and
today
we
only
having
it's
a
if
it's
on
1.9
clusters.
We
have
the
validation
and
omission
web
hooks
and
we
have
some
configure
resources
of
random
validations.
A
So
basically
you
can
write
those
convicts
through
cubic
ATO
or
our
Easter
kado
wrapper
and
write
it
into
the
API
and
it
will
be
stored
in
the
API
server
and
the
CTC
D.
So
the
mixer
and
the
pilot
will
watch
the
configuration
change.
The
configuration
changes
will
first
go
through
the
validation
hooks
if
you
are
on
the
1.9
clusters,
with
those
features
on
the
mixer
and
the
pilot
again
gets
the
new
config
updates
and
the
pilots,
where
pilots
itself
also
receives
the
server.
A
Also,
does
the
service
discovery
and
dns
resolutions
and
gets
to
combine
those
and
the
canonical
service
names
that
they
found
in
the
in
the
platform
combine
the
with
the
user
intent
and
the
converting
to
come
fix
for
am
free
to
be
able
to
understand
and
the
pilot
that
talks
to
infer
a
sense
configures
through
the
data
plan
XTS
as
XDS
api,
and
that's
that's
what
the
current
design
and
the
architecture
and
this
one
give
you
overview
of
how
many
CR
this
we
have.
We
have
a
long
list
of
CIT.
That's
pretty
much.
A
You
grow
organically
through
the
instead
of
East
you,
so
we
have
more
features
and
more
components.
We're
just
having
some
more
CID
types.
So
there's
quite
a
lot
of
them
and
I
will
talk
later,
is
how
we
can
address
the
CID
scalability
issues,
what
else,
but
for
now
we're
having
some
of
this,
and
these
are
like
our
coders
and
there's
a
matrix
and
there's
each
adaptors
has
its
own
config
like
this
is
a
per
missus
and
the
routings
who
have
routing
rules
and
and
that
this
is
actually
we
have.
A
A
Looks
like
in
one
of
them:
okay,
oh
now,
I
can
move
back.
Thank
you,
you
can.
You
can
go
to
the
the
website
and
we
have
the
API
spec
or
talk
to
us
offline
and
we
can
help
you
or
attend
one
of
the
workshops.
So
we
can
help
walk
through
all
those
tasks,
so
we
have
found
a
website.
So
so
you
see
with
a
lot
of
convicts.
We
do
have
some
problems,
so
we
want
to
improve
so
first.
A
A
Also,
we
only
using
the
very
basic
features
and
kuben
and
easy
IDs
there's
zero
observability
in
terms
of
if
you
write
a
config,
that's
incorrect
once
it
gets
through
the
basic
validations.
There's
no
way.
You
know
where
it's
going
wrong,
so
we
want
to.
Maybe
we
can
do
better
on
that
and
also
some
of
the
come
fix
and
like
metrics
monitoring,
we
don't
having
a
scope
model
and
that
allows
you
to
do
sophisticated
reuse
across
mesh
services
and
and
the
echo
model
is
not
established
and
through
a
lot
of
protections
between
the
services
in
mind.
A
So
some
of
the
changes
may
affecting
all
the
services
and
that's
not
a
desired
figure
distributions
and
also
comes
along
regarding
always
getting
requests
the
front
users.
What
we
can
do,
then
the
basics
kubernetes
would
give
us.
Can
we
control
the
robots
or,
if
there's
a
better
configuration,
can
we
easily
wrote
it
back
and,
as
I
have
said,
that
the
main
components
gets
all
the
config,
not
much
shoutings,
we
has
isolation,
so
we
have
done
if
we
can
make
a
more
efficient
and
then
runtime
can
get
less
config.
A
So
when
we
scale
the
mesh
and
now
the
kubernetes
allows
you
to
put
in
come
fix
at
the
same
time,
many
convicts
resources
may
change
it
at
the
same
time
and
we
don't
have
a
good
way
to
reasoning
about.
What's
being
written
and
though,
why
something
happens,
it's
very
hard
to
backtrack,
tress,
multiple
environments,
we
don't
have
automation
to
give
us
a
way
to
configure
them
and
easily
so
over
the
past
few
months.
If
you
follow
a
little
bit
about
the
way
we
talk
in
our
working
group,
we
have
been
thinking.
A
What
can
we
do
to
make
this
better,
we're,
probably
not
gonna,
to
address
all
these
problems,
but
we
want
to
see
what
we
can
come
up.
That
has
a
good
value
and
make
it
a
lot
easier
for
astute
users
to
use,
as
I
have
said,
and
configuration
is
very
important
for
each
do
it's
the
one
of
the
very
important
user
experience
we
want
to
improve.
A
Architecture,
wise
we
see
configuration,
is
through
a
pipeline
of
various
stages.
The
operators
is
the
user
part
and
when
the
configurations
goes
through,
the
component
goes
through
stages.
In
fact,
we
see
when
user
rather
configures
through
an
input.
That's
how
you
provide
your
declarative,
intent
and
those
will
be
transformed
for
we
think
of
components
if
actually
want
some
different
representation
of
the
intent.
A
Then
the
users
that
we
can
having
a
separation
abstraction,
so
we
think
of
oh,
maybe
we
have
have
a
transformation
that
we
can
have
different
layers
of
configurations
exposed
to
different
layers
of
the
components
and
then
goes
to
sending
those
configuration
into
component.
That's
the
distribution
and
there's
a
stage
called
how
the
component
consumes
those
configs,
some
isolation
of
the
consumption,
allows
us
to
do
some
design.
Some
fancy
features
like
a
B
configurations
or
gradual
robots
in
the
future,
and
all
of
this
we
want
to
have
a
pretty
good
story
about
the
observe
ability.
A
A
A
What
is
the
service
config
consumer
configured
and
mash
config
I
will
go
to
detail
what
this
all
about
in
the
next
slide,
but
in
this
this
slide
I
want
to
say
that
we're
gonna
having
a
new
layer
of
API
as
a
surface
for
the
user
that
so
we
hope
we
can
all
user
oriented
design
so
make
it
easy
to
understand
and
the
features
and
is
it's
a
work
containing
four
per
service
experience
and
this
our
Easter
API
is
public
API
and
sometimes
so
you
can
envision
different
use.
Cases
may
find
the
come.
A
Fake
self
is
not
enough.
We
actually
will
allow
to
having
a
layer
on
top
of
config
it.
We
call
its
composable
config.
That's
some
investment
that
we
can
do
to
helps
to
create.
Some
tools
to
compose
is
to
come
fix
for
some
use
cases,
but
it
can
composable.
Config
is
not
architecture
to
each
do
so.
It's
kind
of
allows
Institute
and
this
one
of
the
scalability
or
extensibility
of
the
easter
api,
but
on
the
this
service,
config
consume
kamesh
campaign
component
config,
our
easter
architecture,.
A
So
why
we
do
that?
The
reason
we're
doing
it
is
trying
to
turn
component
centric
configuration
into
feature
centric.
That's
how
we
see
all
the
features
gonna
fit
in
those
3
AP
is
so
the
mesh
config,
the
mesh
config.
As
we
see
it
will
contain
a
small
amount
of
global
configuration
Singleton's
for
the
runtime,
like
pilot
address,
mixer
address
and
how
those
ombré
party
run
it's
kind
of
like
a
flags
and
that's
most
of
them
like
sits
in
the
config
map
as
in
today,
but
we
were
eventually
moving
to
see.
A
Are
these
the
service
consumer
config?
I
will
cost
the
service
config
the
service
configured.
The
users
can
I
gonna
write
because
the
easter
is
designed
the
for
service
operators
and
we
see
service
operators
and
the
main
users
and
that
gonna
configure
these
two
features.
So
networking
writing
encoded,
matrix
logging,
securities,
even
service
broker
configs,
and
it's
its
own
ideas
there
or
service
config.
A
It's
basically
those
come
fix
to
a
configure
producer
service,
and
that's
that's
how
you
think
the
mesh
services
show
the
run
and
that
there's
a
small
and
set
of
config,
so
we
call
service
consumer
config.
Basically,
we
try
to
provide
a
consumer
overriding
model
for
the
service
config.
We
don't
expect
there's
many
of
those,
but
the
some
of
these
are
like
a
rich
rice.
A
Now
goes
a
little
bit
about
the
composable
model,
the
composable
models,
as
I
talked
for
some
larger
meshes
as
you
see
from
the
previous
slides
and
it
each
new
config
api
is
a
per
service.
If
a
mesh
with
a
sultan
services
and
those
services,
for
example,
if
they
want
to
report
pretty
much
the
same
metrics,
you
will
expect
there's
redundant.
We
still
not
yet
resolved
that
problem,
so
the
composable
model
actually
allows
us
to
build
on
top
of
the
api.
A
Maybe
you
can
having
a
hierarchical
model,
giving
you
some
way
to
reuse
the
config
you
have,
and
this
will
also
work
on
different
use
cases,
some
cases
if
the
users
they
want
to
have
some
complicated
eco
models
on
certain
pieces
of
config
that
can
only
written
by
certain
principles
and
they
can
build
on
top
of
this.
So
in
our
configure
working
group
we
plan
to
play,
provides
one
solution.
A
A
Now
goes
to
the
architecture
of
the
main
configure
processing
engine
in
the
configured
in
the
previous
slide.
I
talked
about
the
review
configuration
system
as
a
pipeline,
so
Galle
is
gonna
grow
from
a
1
component.
That
only
does
being
a
validation,
webhook
of
mutation,
valley,
validation,
webhook,
add
ons
into
a
full-blown
configuration
service
for
East
you.
It
will,
instead
of
the
components,
has
the
kubernetes
watch
api
galley
with
the
main
component,
watching
the
configuration
changes
and
the
configuration
as
these
are
the
api,
the
mesh
config
and
service
consumer
config?
It's
the
same.
A
We
still
use
a
behind
kubernetes
api.
We
are
being
a
controller
they
used
to
watch
api's
and
the
gallery
will
do
other
transformations
consolidations.
Optimization.
That's
all
part
of
the
transformations
and
galley
will
sense.
The
component
come
fix
two
components
in
the
pilot,
Citadel
mixer
and
also
the
future,
the
the
ISTE
broker,
and
also
we
are
designing
a
new
distribution
API
and
through
galley.
That's
a
more
efficient,
that's
not
going
through
CRT
anymore.
A
A
little
more
detail
about
the
gala
deaths
and
the
design
principles,
so
Galle
is
in
cluster
solution,
so
Galle
can
fix
a
super
cluster
and
it's
provided
low,
latency,
configured
delivery
on
gallium,
a-reits
and
the
previous
graph.
It
shows
the
recent
topology
information
that
may
help
shouting
and
down
scoping
come
fix.
Basically,
we
can
send
less
config
to
the
components.
A
Little
more
and
notes
about
what
we
think:
how
to
do:
the
multi
cluster
environment,
solutions
for
the
very
basics.
It's
a
manual
process
as
I
mentioned.
Galley
is
a
in
cluster
solution,
so
every
cluster
will
have
a
galley
and
user
will
just
send
config
to
those
galleys
independently.
That's
gonna
work
and
you
can
have
layer
the
solution.
A
A
That
was
to
give
you
the
automations
we
can
do
to
to
config
multiple
clusters
so
before
I'm
taking
questions,
I
will
just
quickly
talk
about
the
way
we
are
right
now
in
the
implementation,
so
the
design
has
been
sorted
out.
The
high
level
architecture
design
has
been
sewed
up
and
we
are
in
the
next
level
of
detail,
design
of
the
service
configs,
the
galley
and
the
distribution
api's
so,
and
the
gallery
itself
is,
we
are
on
the
galley
clip
stop
zero.
A
So
basically,
we
are
introducing
galley
in
TV
stew
as
a
component,
and
so
in
the
first
step
we
just
do
a
separation
of
the
external
CRT
and
internal
CID,
and
they
are
in
fact
the
same
type.
Basically
just
the
resources,
it's
eating
external
and
internal.
You
know
separations
and
the
first
step
a
galley
just
does
a
sink
through
externals
galley,
being
the
watch
api
to
the
CRT
changes
and
kind
of
reads
the
external
CRTs
and
then
generate
the
it's
almost
exactly
the
same
internal
series
you
can
think
of
no
transformation
is
being
done.