►
From YouTube: Episode 21: Istio In Action Book Highlight
Description
Istio in action is officially out now - a book we have been waiting for a long time! I have been reading the book lately and am really impressed with the depth of knowledge in this book. In this hoot livestream, Christian and Rinor will join Lin to discuss the highlights of the book along with live demos!
Get the book at 41% discount with the promo code: SOLOIO41
Go over to http://mng.bz/06Wl, and don't forget to use the promo code!
#istio #performance #istioinaction #book #mannings #livestream #hoot
Timeline to help you navigate the video easily:
00:12-3:00 Welcome + speaker intro
3:00-5:10 service mesh and Istio news
5:10 -37:23 book discussion + answer live questions
37:23-44:42 Optimize control plane performance
44:42-58:20 Live DEMO
58:20 wrap up + coupon for the book + answer more live questions!
To learn more about us, please visit https://www.solo.io
We are hiring! https://www.solo.io/company/careers/
Questions? https://slack.solo.io
Code Samples: https://github.com/solo-io/hoot
Suggest a topic to cover here: https://github.com/solo-io/hoot/issues/new?title=episode+suggestion
A
A
Should
you
add
this
book
to
your
reading
list?
Today
we
are
going
to
discuss
some
of
the
contents
of
the
book,
so
you
could
make
an
informative
decision.
Welcome
to
the
hood
live
stream,
where
we
bring
istio
envoy,
kubernetes,
ebpf
and
graphql
technologies
to
you.
So
you
can
be
very
well
prepared
at
your
job
and
be
the
best
cloud
native
developers,
operators
and
architects.
A
B
B
Klein
in
january
2017
and
from
there
you
know,
got
involved
with
istio
and
and
and
others
so
yeah.
I'm
super
excited
to
talk
about
the
book.
I'm
super
excited
to
have
finished.
Writing
the
book
and
renault
was
a
big,
huge
contributor
and
help
to
that
so
I'll.
Let
him
I'll!
Let
him
introduce
himself
here.
D
Yeah
thanks
chris
and
so
hi
everybody
and
so
welcome,
and
thanks
for
joining
I'm
a
normal
yoko.
I'm
a
field
engineer
here
at
sodium.
Previously
I
worked
as
a
platform
engineer
over
at
red
hat
and
we
were
implementing
a
lot
of
these
features
most
likely.
I
was
one
of
the
first
people
to
read
all
the
posts
from
christian
poster
about
istio
and
I
was
getting
excited
so
I
have
some
sample
applications
that
I
always
use.
I
wrote
a
blog
post.
D
It
went
sort
of
viral
when
comparing
just
istio
the
community
is
still
not
the
largest
so
yeah
and
yeah.
It
was
a
joy
to
join
christian
work
on
the
book
and
provide
some
of
my
capabilities,
which
are
just
going
way
low
into
the
details
and
then
going
back
up
to
not
overwhelm
people
with
it.
So
I
hope
that
that
can
be
seen
as
well
in
the
book.
D
A
C
A
I've
actually
published
the
steps
on
github,
so
please
follow
along
with
with
us
on
youtube
and
also
on
our
github.
So
the
steps
are
here
on.
You
know,
episode
20.,
so
that's
the
first,
that's
the
second
news.
The
third
news
I
want
to
quickly
mention
is
istio.
Khan
is
coming.
So
if
you
want
to
be
getting
a
t-shirt
from
istio
khan,
you
know
register
today,
so
you
can
be
the
first
400
participants.
A
A
So
get
registered
if
you
haven't.
The
other
news
I
want
to
share
is
support
for
istio,
wonder
11,
it's
going
to
end,
I
guess
in
three
days
on
this
friday.
So
if
you're
on
it's
your
1.11,
so
look
out
for
upgrade
or
maybe
partner,
one
of
the
vendors
like
solo
to
support
you
on
older
version
of
istio,
if
it
needs
to
last
but
not
least,
christian
sent
this
wonderful
post
to
welcome
greg
hansen
to
join
solo
for
those
of
you
in
the
israel
community.
A
A
B
It's
it's
for
those
those
people,
but
specifically
those
that
are,
you
know
on
on
their
journey
far
far
enough,
where
they
start
to
see
the
problems
that
service
mesh
solves
right,
they're,
starting
to
automate
their
deployments,
they're
starting
to
deploy
into
containers
and
kubernetes,
and
these
are
not
just
very
simple
web
apps.
These
are
you
know:
enterprise
applications,
they're
communicating
with
each
other.
B
The
enterprise
needs
to
specify
the
policies
about
how
resilience
should
behave,
how
telemetry
should
be
collected
and
security
should
be
enforced
and
make
changes
to
to
the
system
as
it
continues
to
evolve,
and
people
like
the
developers
are
absolutely
involved.
Architects
platform
owners,
devsecops
folks,
you
know
those
are
very
likely
very
interested
in
solving
this
problem
in
a
scalable
way
and
are
likely
the
ones
leading
evaluations
and
figuring
out.
What
are
what
are
the
right
ways
to
to
solve
the
problems,
so
we
we've
written
this
book
for,
for
those
folks.
D
D
A
B
B
This
is
actually
it's
it's
it's.
We
went
to
print
with
istio
1.13,
which
is
the
most
current
release,
which
is
which
is
pretty
awesome
because
usually
technology
books,
they
become
out
first
of
all,
outdated,
pretty
quickly
and
and
behind
a
few
versions,
which
will
probably
happen,
because
this
is
going
to
continue
to
release
every
quarter,
but
we
we
definitely
we
released
the
book
with
the
most
latest
version.
I
would
say
that
another
another
big
difference
is
some
of
the
other
other
istio
books.
B
They
they
do
a
good
job
talking
about
istio's
features.
You
know
at
a
you
know,
at
a
level
that
people
can,
because
when
people
were
looking
at
those
other
history
books,
it
was
mostly
like
all
right.
Well,
can
someone
give
me
a
cliff
notes,
version
of
what
is
istio
right?
We
don't
take
a
cliff
notes
approach
here.
This
is
you
know,
480
pages
of
three
and
a
half
years
or
longer
of
you
know,
knowledge
that
we've
been
cultivating
building
and
evolving,
because
the
seo
community
and
project
has
evolved
in
in
this
time
as
well
significantly.
B
But
I
believe
it's
at
a
point
where
it's
mature,
it's
stable,
it's
it's
hardened,
certainly
in
in
many
areas,
and
and
so
I
don't
expect
to
see
the
api
churn
and
stuff
that
we
saw
in
previous
versions.
So
from
that
perspective
it
should
stay
relatively
up
to
date
and
then,
like
I
said,
we
go
into
quite
some
depth
to
not
just
what
are
the
features.
But
when
is
this
useful
and
what
are
some
trade-offs
and
when
you
do
go
down
this
path?
B
D
So
when
you
use
istio
quite
often
a
lot
of
things,
look
like
magic
and
a
lot
of
books
really
leave
it
at
that.
So
we
really
go
behind
the
scenes
and
say:
okay
now,
when
you
executed
this,
this
is
what
happened
even
going
low
level
to
the
envoy
configuration
that
is
applied,
there's
an
entire
chapter
just
about
android
and
how
it
is
configured
and
what
the
control
plane
does,
how
it
configures
it.
D
So
just
going
to
this
amount
of
detail
that
now,
when
you
know
about
how
istio
works,
if
something
is
not
working,
you
can
immediately
dive
deep
into
and
find
out.
What's
the
issue
so
there's
an
entire
chapter
about
how
to
debug
the
data
plane
and
one
which
we
will
demo
today
is
how
to
improve
the
performance
of
the
control
plane.
D
Even
now,
when
I'm
working
with
the
clients-
and
there
is
one
issue
here
or
there-
I
will
open
the
book
because
it's
easier
to
go
and
find
that
section
and
just
work
with
the
client
and
improve
it
then
start
to
research.
It
again
so
yeah,
that's
one
of
the
things
that
I
think
it
makes
the
biggest
difference
with
the
other
books
out.
There.
A
Yeah,
I
I
think
I'm
totally
impressed
with
the
breasts
and
also
the
depths
of
the
book.
It
really
covers,
like
the
first
chapter,
really
covers
like
the
beginner,
which
I
think
it's
kind
of
what
my
book
is
trying
to
achieve
right.
It's
get
people
started
with
service
match,
but
this
book
is
still
in
action.
It
covers
like
intermediate
and
also
advanced
topic
right,
so
that's
made
it
really
interesting.
A
B
C
A
D
Yeah,
so
all
so,
probably
around
six
months
I
never
took
off
one
weekend
to
do
some
other
stuff.
It
was
all
going
into
the
book
just
because
I'm
not
so
effective
and
I
was
just
one
hour
or
two
hours.
I
was
not
able
to
do
the
approach
where
split
every
day,
one
hour,
so
I
just
had
to
have
like
12
hours
of
just
working
on
the
book.
That's
why
most
of
the
beacons
had
to
go
there
yeah,
and
I
think
that's
that's
it.
What
it
took
for
me
so
to
you,
kristen.
B
C
B
I
started
writing
I
believe
in
august
or
july
2018
before
is
to
write
as
istio
was
becoming
1.0
and
and
then
at
the
end
of
2018.
I
joined
solo
and
you
know
solo.
We
were
you,
know,
9
10
people
back
then,
and
basically,
starting
from
you
know
the
beginning,
we're
building
we're
building
the
company,
and
so
you
know
that
that
that
took
a
significant
amount
of
time,
and
so
there
were
breaks.
B
Definitely
you
know
pauses,
let's
say
some
long
pauses
and
but
but
you
know,
while
we
were,
you
know
working
on
on
solo,
we're
also
paying
attention
what's
happening
in
the
istio
community
and
things
were
churning
and
there
were
some
hiccups
and
so
a
lot
of
it.
It
ended
up
being
you
know
the
the
the
timing
and
how
everything
happened
it
just
it
worked
out.
It
couldn't
have
worked
out
better,
but
you
know
there
was.
There
was
definitely
some
and
you
know
halfway
through.
I
realized
I
I'm
not.
B
B
Years
ago,
yeah-
and
that
provides
so
that,
may
maybe
you
know
it
took
a
long
time-
you
know
wake
up
early
work
on
weekends.
I
mean
just
fig,
you
know,
use
something
you
figure
it
out,
but
I
think
at
the
end
of
the
day,
if
especially,
if
there's
other
folks
out
there,
that
might
be
interested
in
writing
a
book.
What
I
could
say
is
working
with
another
person
and
another
author.
B
C
B
B
Having
a
co-author
to
get
you
through,
the
you
know,
the
the
I
think
I
wrote
the
first
four
chapters
in
like
two
months
right
and
then
I
took
pause,
rewrote,
did
all
the
stuff
and
then
you
know
got
dragged
into
building
the
startup
and
so
on
and
distracted
and
everything
would.
But
if
you
have
somebody
else
working
with
you,
that
will
give
you
a
lot
of
motivation
to
to
stay
the
course
and
finish
the
job.
So
definitely
a
huge.
Thank
you
renoir
you.
C
D
Well
and
for
me,
it
was
an
absolute
pleasure
to
work
with
christian.
He
laid
so
much
trust
into
me.
I
was
not
really
expecting
that
because,
usually,
when
you
start
to-
and
you
have
your
own
like
baby,
you
really
care
about
everything.
Just
handing
off
trust-
that's
really
difficult,
but
in
my
case
it
was
like.
D
I
was
writing
a
chapter
meeting
like
through
the
first
draft,
with
christian,
reviewing
it
and
then
progressing
on
it,
taking
some
feedback
improving
it
further,
so
it
ended
up
like
being
a
really
nice
cycle,
and
then
you
get
to
a
book
which
is
450
pages
and
your
editor
sends
all
the
history
of
you
back.
You
have
to
go
through
450
pages
and
that's
such
a
downer
having
two
pencils
to.
B
A
Absolutely
yeah
all
the
memory
of
me.
You
know
going
through
my
book
and
working
with
my
editor.
Even
I
think
it's
just
on
70
80
pages
of
book
is
that
10
times
right
with
the
lens
of
your
book.
I
I
can't
imagine
so
good
job
and
renault.
I
think
you
are
the
first.
This
is
your
first
book
right,
so
huge.
D
B
A
Yeah,
that's
what
I
said
to
myself.
This
might
be
my
last
book
too
okay,
so
we
have
our
first
question
comes
up
now,
which
is
very
exciting.
So
thank
you
for
that
question.
I'm
not
sure
if
I
can
pronounce
your
name
harinda.
It
still
is
the
foundation
in
enso's
openshift
service
mesh
and
also
glue
edge.
Is
there
any
competitive
comparison
between
the
two?
These
solution
offerings.
B
Yeah
there
there
is-
and
I
can
give
you
the
quick,
the
the
too
long,
don't
didn't
read
you
know
version
so
istio
is,
like
I
said,
extremely
popular
service
mesh
we've
seen
massive
massive
deployment.
We
are
we
at
solar
working
with
with
some
of
the
largest
deployments
of
service
mesh
in
the
world
and
and
what
you'll
see
is
anthos,
which
is
kubernetes
and
cloud
platform.
B
You
can
see
openshift
with
the
kubernetes
cloud
platform
and
and
what
we
do
here
at
solo
is
actually
and
it's
actually
solo
glue
mesh.
But
what
we
do
here
at
solo
is
we
focus
on
just
the
connectivity
pieces.
We
don't
we
don't
care
what
kubernetes
you
end
up
using
and
so
from
a
feature
standpoint.
There's
there's
a
long
list
go
to
solo.I
o
go
to
the
glue
mesh.
You
know,
I'm
not
gonna.
Go
into
that
right
now,
but
they're.
B
You
know
the
the
others
like
antho
service
mesh,
for
example,
is
a
rebranded
version
of
of
istio
right
that
integrates
with
some
of
the
google
cloud
pieces.
Oh
bishop
service
mesh
is
a
forked
version
of
istio
that
builds
on
top
of
openshift
primitives,
and
you
know
it's
very
openship
centric.
It
deploys
only
to
openshift
glue
mesh
here
at
solo.
Is
we
we're
built
on
upstream
istio?
B
B
Is
a
very
important
feature,
bringing
the
glue
edge
gateway
to
istio
and
building
the
api
gateway
directly
on
top
of
istio
having
unified
dashboards
and
observability
across
your
deployment
might
be
multi-cluster
multi-cloud.
You
know
all
of
these
things
ebpf.
You
know
with
ebpf
to
the
service
mesh
graphql,
so
we
see
the
istio
as
a
as
a
piece
of
the
puzzle,
but
we
built
a
lot
of
application.
Networking
components
around
it
and
you
know
I'll
even
put
into
the
chat
here.
Lynn,
I'm
not
sure
I'll
put
it
in
here.
A
Yeah,
so
this
is
the
blog
christian
just
mentioned
we
just
shared
in
the
chat,
so
feel
free
to
read
a
lot
on
your
own.
So
thank
you
for
that
link,
christian
yeah,
all
right
thanks
for
the
question.
So
again,
if
you
guys
have
any
questions
just
send
to
us
and
let's
continue
our
book
discussion,
what
are
the
favorite
parts
of
the
book
for
for
you
guys.
A
B
B
That
one
yeah
and
that
one's
that
one's
my
favorite,
because
that
is
one
of
the
first
features
first
group
of
features
that
got
me
really
interested
in
the
service
mesh
in
envoy
proxy.
Actually
to
be
to
be
specific,
because
at
a
at
the
talk
that
I
or
where
I
met
matt
client
at,
I
think,
was
some
conference
in
san
francisco
hey.
You
know.
B
B
B
You
know
how
things
interact
on
the
network,
let's
well,
something
else
should
be
able
to
do
that
and
and
do
it
very
efficiently
and
effectively.
So
that's
that's
where
I
got
started
with
with
the
service
mesh
and
getting
into
istio
timeouts
retry
circuit
breaking
those
were
all,
and
actually
the
initial
blogs
that
I
did
around
envoy
and
istio
were
on
those
topics
and
and
in
chapter
six
we
we
talked
about
load
balancing.
D
D
The
nice
thing
about
this
chapter
is
as
well
that
it
it
gives
you
so
much
information
that
it
makes
all
the
other
chapters
to
be
way
more
detailed.
Otherwise
it
would
be
like
a
repetition
of
the
same.
So
that's
why
I
really
like
this
chapter
and
then
it's
it's.
The
the
chapters
about
troubleshooting
the
data
plane
performance
tuning
scaling
east
in
your
organization.
So
the
reason
why
I
like
these
chapters
is
that
I
wrote
that
note
the.
D
I,
like
these
chapters,
is
that
these
really
go
into
the
detail
of
like
not
really
letting
you
into
a
place
where
you
deploy
stuff,
and
you
are
not
sure
how
things
are
working
at
this
part.
You
really
need
to
you,
learn
everything
when
something
is
not
working,
how
to
debug
it,
how
to
make
it
work
across
clusters
if
the
traffic
is
not
going
successfully
to
the
other
side,
how
you
can
find
out
where
it
is
failing
and
as
a
platform
engineer
that
I
worked
as
two
years.
D
Deploying
a
service,
for
example,
like
ast,
is
quite
easy,
but
troubleshooting
it
and
helping
all
your
clients,
all
your
customers
on
the
platform.
That's
another
field,
another
area
that
is
of
major
importance
and
that's
why
this
chapter
are
just
probably
a
little
more
towards
platform,
engineering
teams
and
as
well,
architects
that
want
to
scale
the
mesh
into
multiple
clusters.
A
Yeah,
okay,
we
have
a
second
question
coming
in
now
from
rafael,
hey
guys
is
the
it's
still
in
action
going
to
be
available
on
o'reilly
platform,
and
do
you
guys?
Do
you
see
guys?
I'm
sorry,
do
you
see
envoy
being
removed
from
istio
I've
seen
some
articles
on
how
is
silva
can
work
on
its
own
proxy.
I
assume
or
something
I
guess,
it's
kind
of
cut
off
now.
Do
you
guys
know
the
answer
for
their
writing.
B
So
for
the
o'reilly
platform-
I'm
not
sure
I
know
o'reilly
obviously
has
all
of
their
books
on
the
o'reilly
platform.
I
do
believe
they
have
other
publisher
books
on
the
platform
as
well.
If
you
can
get
other
manning
books
on
the
o'reilly
platform,
like
you
know,
kubernetes
in
action
or
microservices
in
action.
If
you
can
get
those
books
on
the
o'reilly
platform,
then
I
would
imagine
that
istio
and
action
would
eventually
get
to
the
to
the
o'reilly
platform
as
well.
B
Just
just
to
I
don't
know
the
the
level
of
folks
who
are
joining
the
the
live
stream
here,
but
envoy
is
what
makes
istio
what
istio
is
today
and
so
so
envoy?
Is
the
data
plane
proxy
in
in
the
istio
service
mesh
and
has
been
from
the
very
beginning
and
and
so
now
the
question
is:
do
we
see
it
being
removed
or
is
still
working
on
its
own?
So
the
the
data
plane
of
a
service
mesh
is
a
really
interesting
area
of
of
technology
and
evolution.
B
B
A
B
That
that
also
yeah
from
solo
con-
that's
a
great
actually
that's
that's
a
good
one
for
sure.
Send
that
one
and
the
link
yep
to
the
blog,
but
the
the
more
interesting
question
is,
you
know,
envoy
being
deployed
where
is
envoy
deployed
and
how
is
it
deployed,
or
maybe
you
know
in
highly
optimized
scenarios,
maybe
removing
envoy
completely.
B
So
sidecar
is
the
model
that
is
deployed
today.
Typically,
but,
as
you
know,
istio
has
gateways
which
are
not
side.
Cars
and
there
are
you-
know,
shared
model,
shared
side,
shared
proxy
models
that
that
are
evolving
and
that
we're
leading
the
effort
on
in
our
engineering,
team
and
you'll
start
to
see
more
of
that
come
out
pretty
soon,
I
would
say,
but
yeah
there's
there's.
B
Definitely
an
evolution
coming
envoy
is
the
foundation,
though
I
would
be
I
I
don't
want
to
leave
the
impression
that
enboy
is
going
to
be
replaced
with
something
or
something
like
that.
But
there
are,
there
will
be
more
efficient
deployment
options
and
optimizations
that
we
can
make
for
the
proxy
which
which
improve
you
know,
based
on
the
various
trade-offs
you're
willing
to
make
now
there's
also
the
proxy
list
option,
which
I
would
I
would
say,
is
a
very
highly
optimized.
B
You
know
a
big
part
of
using
the
service
meshes
so
that
you
don't
have
to
embed
a
lot
of
the
stuff
into
your
application
code,
because
that
gets
difficult
with
all
the
different
languages
you
might
want
to
support
frameworks
and
so
on.
But
there's
the
the
data
plane
for
a
service
mesh
is
a
continuum
and
you're
going
to
start
to
see
a
lot
more
optimizations
that
are
available
for
it.
A
A
A
All
right
and
we
have
a
feedback
from
rafael.
That's
what
I
thought
about
the
proximus
design.
I've
seen
some
work
around
grpc
optimization
on
proxies
deployment.
That's
awesome!
Thank
you.
Okay,
with
that,
I
guess
I'd
like
to
kind
of
dive
into
chapter
11,
because
I'm
very
impressed
with
that
book.
So
when
I
read
that
book,
I
have
a
few
questions
like
I
saw
the
concept
of
a
phantom
workload
and
its
impact
was
interesting.
A
The
foregolden
principle
the
floor
golden
sinkness
of
control,
plane
that
was
interesting
and
also
the
techniques
to
improve
istio
control,
plane
performance
that
was
interesting
and
the
thoughts
on
whether
you
should
scale
out
will
scale
up
and
the
of
the
control
plane.
Also,
should
you
leverage
auto
scaling
of
the
istio
control
plan?
I
know
this
is
a
little
bit
more
advanced
topic,
but
you
know
it
shows
the
depth
of
the
book.
B
But
what
you're
gonna
see
here
now
is
an
advanced
day,
two
type
scenario.
So
this
is
this
is
def,
it's
not
for
beginners
and,
and
so
you're
gonna
see
you
know,
kind
of
the
internal
workings
of
the
control
plane
and
how
to
optimize
and
tune
for
like
what
lin
said.
You
know
the
various
the
various
scenarios
of
of
scaling
right.
So
I
don't
want
you
to
take
come
away
from.
Oh
man.
This
is
the
thing
you
have
to.
I
have
to
understand
what
to
to
be
able
to
use
it.
No,
no!
B
D
D
So
this
is
a
phenomenon
that
we
saw
quite
often
happening
when
the
the
synchronization,
the
time
until
the
data
plane
is
updated,
is
slow.
So
here
is
one
concrete
example:
here
we
have
two
services
where
one
service
with
two
instances
and
when
one
goes
down
or
is
otherwise
failing
the
health
check
cube
that
will
report
to
kubernetes
api
server
that
it
is,
it
is
failing
the
health
check
and
then
in
kubernetes
api
server.
There
are
multiple
controllers.
One
of
those
is
the
service
controller.
D
It
will
remove
this
endpoint
from
the
service
because
it's
not
ready
to
receive
traffic,
and
this
is
something
which
is
very
important
for
study.
Now.
East
ud
will
receive
this
event
and
then
it
will
generate
employee
configuration
and
update
the
data
plane
with
it.
As
we
see
the
angus
gateway,
which
is
way
over
in
the
left
side,
but
until
this
process
until
this
cycle
happens,
the
ingest
gateway
will
still
route
traffic
to
the
application,
which
is
not
healthy
and
then
requests
will
fail.
D
This
is
not
immediately
visible
to
the
end
users,
because
the
ingers
gateway,
as
well
as
the
other
service
proxies,
are
configured
to
retry.
But
if
it
continues
for
a
longer
period
of
time,
then
it
will
as
well
leak
to
the
end
users.
That's
why
having
a
performant
control
plane
is
actually
very
important.
D
So
let's
go
to
the
next
part.
What
are
the
steps
that?
So
basically
what
we
see
this
here
is
istiod,
but
within
studio
there
are
a
lot
of
steps
that
happen
so
now,
let's
zoom
in
into
study.
So
in
this
case
we
have
one
incoming
event,
which
is
coming
from
the
kubernetes
api
server
to
the
discovery.
Server,
the
event
can
be
a
user
applying
a
configuration
or
it
can
be
a
bot
being
rescheduled
being
killed
becoming
unhealthy.
D
So
all
of
these
generate
events
and
those
events
go
to
the
discovery
server,
which
is
a
component
of
stod.
The
discovery
server
is
quite
intelligent.
It
doesn't
immediately
push
the
change
to
the
workloads
that
wouldn't
be
very
performant.
What
it
does
is
it
deep
bounces
and
waits
for
more
events,
because
when
an
event
occurs,
usually
there
are
immediately
subsequent
events.
In
a
case
when
you
deploy
a
kubernetes
service
and
the
deployment
so
initially
create
a
service
is
an
event
on
itself,
the
pods
becoming
ready
or
other
events.
D
So,
instead
of
pushing
each
of
those
changes
separately,
we
the
discovery
server
debounces,
the
change
waits
a
little
further
gets
all
these
events
merges
those
into
one
single
push
requests
and
adds
those
to
the
push
queue,
and
then
it
is
some
workers
that
are
throttled
to
not
exhaust
the
cpu,
where
it
ends
up
switching
between
one
toss
to
another.
So
basically
it
is
throttled
and
tasks
are
picked
from
the
queue
one
by
one
and
then
pushed
according
to
how
much
you
throttle
them
and
push
to
the
workloads.
D
So
all
of
these
steps
have
to
occur
for
one
change
that
comes
to
the
kubernetes
api
server
to
go
up
to
the
workloads.
So
next,
let's
see
all
the
factors
that
determine
the
performance.
The
first
factor
is
the
rate
of
changes.
When
there
are
many
changes,
this
will
overwhelm
this
duty,
especially
if
these
are
continuous
and
there
is
no
space
in
which
ecod
can
generate
a
configuration
and
push
it.
There
is
a
maximum
period
that,
after
it
is
so
after
that
changes
debunks,
then
debunks.
D
If
this
maximum
period
is
reached,
then
whatever
change
we
have
is
pushed
to
the
workloads
just
to
ensure
that
the
workloads
are
not
stale
for
too
long.
So,
basically,
rate
of
changes,
that's
the
first
factor,
and
then
it's
the
amount
of
allocated
resources
to
east
u.d.
If
s2d
has
more
resources,
then
understandably,
it
will
be
faster
at
generating
alpha
and
void,
configuration
and
pushing
it
to
the
workloads,
and
then
it's
as
well
configuration
size
by
default.
D
D
You
can
improve
this
by
specifying
which
configuration
is
important
for
which
workload
and
in
such
a
way
that
the
configuration
which
is
sent
to
the
workloads
will
become
smaller.
And
finally,
it
is
the
workload
comp.
If
you
have
more
workloads,
more
work
has
to
be
done
to
push
all
the
changes
to
all
the
workloads.
D
So
next,
let's
go
into
the
the
knobs
of
improving
performance.
After
learning
all
the
factors,
we
can
very
easily
discover
what
are
the
ways
that
we
can
improve
those
if
you
have
a
lot
of
events.
The
first
thing
that
you
can
do
is
ignore
some
events.
When
you
install
history
in
a
cluster,
you
can
specify
namespaces
or
labels
on
those
namespaces
that
you
can
ignore.
D
Events
and
those
namespaces
want
picked
up
and
pushed
to
the
workloads
so
that
the
best
way
to
improve
performance
is
to
ignore
events
which
are
not
really
important,
and
then
the
other
option
is
let's
say
we
have
still
a
lot
of
events,
but
all
of
these
are
important.
The
option
we
have
is
just
specifying
the
debunks
period
and
then
batching
all
of
those
into
fewer
push
requests
and
then
just
working
on
fewer
pushes,
instead
of
doing
a
lot
of
pushes.
D
Finally,
when
we
specify
the
configuration
which
is
important
for
a
workload,
we
do
that
by
using
a
cycle
resource
which
we
will
see
in
the
demo,
when
you
specify
those
s2d
can
discern
which
configuration
is
important
for
which
workload
and
in
such
a
way,
it
can
decide
to
send
the
envoy
configuration
to
the
first
workload
not
to
the
second
and
send
it
to
the
third
as
well.
In
such
a
way,
not
sending
it
to
one
workload
is
already
improving
the
performance
and
the
final
part
is
just
scaling
out
and
scaling
up,
which
is
understandable.
D
B
D
B
I
think
the
point
is
I
mean
I
I
I
know
you
did
great,
but
istio's
control
plane
is
a
tunable.
You
know
event-driven
system
that
you
know
you'll
have
to
explore
and
understand
your
environment
to
understand
which
knobs
need
to
be
tuned,
but
you
know
understanding
the
pieces
and
how
it
works
is
extremely
important.
A
C
D
D
Next,
what
we
are
going
to
do
is
we
are
going
to
apply
a
lot
of
services,
so
in
my
site
this
will
be
really
fast,
because
I
have
already
deployed
those.
So
let's
check
this,
so
the
images
don't
really
need
to
be
pulled
and
as
such,
it
will
be
early
fast.
So
most
of
these
are
already
running
what
is
here.
D
We
have
a
lot
of
sleep
services
which
are
just
dummy
workloads
that
have
the
side
car,
meaning
that
we
need
to
push
updates
to
those
it's
just
so
that
we
have
a
little
more
work
for
s2d
and
we
have
catalog,
which
is
the
service
which
we
can
send
traffic
and
make
sure
that
after
we
create
some
configuration
to
route
traffic
to
catalog,
that
it
is
picked
up
by
study
and
push
to
the
eastern
ingress
gateway.
So
these
are
currently
what
we
have
running
in
the
cluster:
let's
create
another
namespace
which
will
later
on.
D
We
will
ignore,
so
that
will
give
us
a
use
case
to
show
some
of
the
capabilities
to
ignore
stuff.
So
now
we
are
applying
600
resources
into
the
class
and
this
example
is
taken
from
the
book
in
the
book.
There
are
explanations
about
all
the
steps,
so
with
600
resources,
where
we
have
three
of
each
so
one
gateway
one
service
and
the
vertical
service
and
200
of
those
that
makes
600
resources.
D
So
now
in
grafana
I
usually
modify
a
little
the
dashboard
because
it
it
contains
not
all
the
metrics
which
are
important.
So
I
add
some
of
those
which
I
think
are
key,
and
we
explain
in
the
book
why
these
are
key.
So
just
to
spare
a
ton
of
detail,
I
will
skip
that
and
I
will
cover
only
what's
important.
D
D
D
D
And
let's
wait
a
little
until
we
see
all
of
those,
but
we
see
that
the
bot
is
already
getting
deleted.
So
I
will
interrupt
this
now.
What
we
can
do
is
we
can
configure
the
sd
installation
to
ignore
this
namespace,
because
this
could
be
a
namespace
where
we
have
a
lot
of
pods
being
created
deleted
a
lot
of
services,
so
if
it's
just
noise
for
the
other
services,
so
basically
the
service
mesh
is
not
interested.
D
In
all
of
this
information,
we
can
configure
the
service
mesh
to
ignore
those
changes,
and
this
is
how
we
do
it.
We
can
specify
in
the
installation
the
discovery
selectors,
but
we
are
using
a
not
in
so.
Basically,
we
select
everything
that
doesn't
have
the
istio
exclude
set
to
true
all
the
name:
spaces
that
don't
have
histories
to
set
it
through.
D
D
D
D
D
This
was
when
it
was
not
optimized
and
we
can
compare
the
optimizations
later
on.
So
let's
go
to
the
next
part.
So
ignoring
events,
that's
the
first
thing.
The
other
thing
is
we
have
one
performance
test
which
generates
some
traffic
and
then
queries
all
the
metrics
to
make
sure
if
the
performance
was
improved
or
degraded.
D
So
now
executing
this
we
see
the
first
set
of
resources,
a
gateway,
a
kubernetes
service
and
the
virtual
service
are
created,
and
we
do
that
10
times
and
without
any
optimization.
This
is
happening
in
a
namespace
which
is
not
excluded,
so
this
is
a
namespace
for
which
all
the
events
will
be
created.
D
So
and
we
see
there
are
a
ton
of
pilot
push
requests
and
if
you
see
as
well
the
performance
it
is
going
up
to
what's
this,
it
is
900
milliseconds.
So
it's
almost
one
second,
so
that
that's
quite
a
lot
good
and
the
reason
why
it's
so
much
is
that
there
is
already
a
lot
of
information
that
needs
to
be
propagated.
D
D
So
now
we
can
query
the
size
and
it
is
one
comma,
seven
megabytes.
So
every
change
will
trigger
a
one
comma,
seven
megabyte
android
configuration
to
be
generated
and
to
be
pushed
to
all
the
workloads.
So
there
are
some
changes
which
are
faster.
For
example,
endpoints
are
using
the
incremental
xds
approach,
which
is
sending
only
the
delta,
so
the
server
and
the
client
are
in
communication.
D
They
see
only
what's
the
difference
from
the
previous
state
and
sent
only
that
part,
but
this
is
implemented
only
for
end
points
not
for
services,
clusters,
listeners
etc,
so
meaning
that
most
of
the
changes
besides
one
end
point
becoming
healthy
and
becoming
not
healthy
and
healthy
or
being
rescheduled,
and
so
all
the
other
changes
really
exhaust
the
control
plane
that
has
to
push
that
amount
of
configuration.
So
what
we
can
do
is
we
can
define
a
cycle
resource
that
specifies
the
egress
traffic
of
one
service.
D
So
currently,
what
we
are
doing
here
is
we
are
creating
a
site
called
resource
in
the
default
in
the
istio
system,
namespace
with
the
name
default,
and
this
applies
to
all
workloads
within
the
cluster.
In
such
a
way,
we
are
configuring,
all
the
workloads
to
route
traffic,
only
to
the
istio
system
namespace
and
to
the
prometheus
namespace.
D
Everything
else
is
not
configured,
meaning
that
all
these
extra
configuration
of
all
the
other
services,
those
are
not
being
sent
to
the
workloads.
If
a
team
needs
egress
traffic
to
more
services,
they
would
have
to
overwrite
the
site
car
configuration,
which
is
the
default
which
another
site
car,
which
is
more
specific
and
meets
their
criteria.
This
is
quite
good
as
a
default
because
it
pushes
all
the
teams
to
decide
what
is
the
biggest
traffic
for
their
services
and
it
improves
the
performance.
So,
let's
go
here.
D
Let's
apply
this
cycle
resource
now,
with
the
sitecore
resource.
Sdod,
we'll
see
that
all
of
these
services
contain
way
more
information
and
configuration
that
they
need.
For
that
reason,
it
is
going
to
generate
new
configuration
which
doesn't
have
all
the
extra
details
and
send
it
over
to
the
workloads.
So,
as
we
see,
the
performance
is
way
better.
So
now
everything
is
faster
than
99.9
milliseconds,
which
is
a
very
good
performance.
D
One
more
thing
that
we
can
check
is
that
previously,
when
we
executed
the
performance
performance
test,
we
had
640
pushes
and
it
took
it,
had
a
latency
of
zero
comma
49
seconds,
so
490
milliseconds.
So
let's
test
this
again
now
we
will
make
another
performance
test
and
we
will
see
how
the
sidecar
improve
this
so
basically
just
specifying
the
egress
of
one
workflow.
D
A
D
A
D
Yep,
thank
you
very
much,
so
I
will
try
to
make
this
quick
because
it's
almost
one
hour.
So
if
we
go
here
at
the
bottom,
what
we
will
see
as
well
is
that
the
request
size
so
basically
in
this
graph,
we
see
that
this
was
the
amount
of
data
that
was
being
sent
over
previously
by
we
didn't
have
the
sidecar
and
now
this
is
the
amount
of
data.
So
basically
this
was
the
maximum,
but
we
see
the
average
is
why
way
lower
than
that
is
zero,
comma
378
bytes.
B
B
B
If
people
are
interested
solo,
I
o
41
is:
is
the
discount
code
right?
So
the
question
is
around
migration
and
liveness
probes
and
and
readiness
probe,
and
we
do
cover
that
we
cover
in
various
there's
not
like
one
chapter.
One
section
I
would
say
it's
covered
throughout
you'll,
see
a
discussion
around
this
on.
B
A
That's
awesome.
Well,
I
hope
this
gives
you
guys
a
good
insight
of
the
value
the
book
can
bring
to
you.
So
I
want
to
take
a
minute
to
thank
christian
and
reno
for
speaking
here
at
the
live
stream
and
especially
renault
for
your
excellent
demo,
very
engaging
how
do
folks
reach
out
to
you
if
they
have
any
questions.
A
That's
awesome
and
I
hope
you
guys
find
this
episode
interesting
if
you
do
think
it's
interesting,
please
comment
and
like
and
subscribe
to
our
channel,
so
you
don't
miss
any
of
our
future
episodes.
Next
week
we
will
come
back
on
tuesday
talk
about
accelerate
service,
mesh
adoption
with
ebpf
and
murbridge.