►
From YouTube: Workshop5 : Deploying Istio for Production
Description
Istio is the most popular service mesh deployed into production across the cloud-native ecosystem, and for good reason. It’s feature rich, open-source, and most importantly, battle proven.
The workshop series for those looking to learn more about how Istio works and how to operationalize it for their organization. We cover things like the basics of routing, observability, and security, and then expand into leveraging Istio for a devops/gitops CI/CD flow, zero-downtime upgrades of Istio control plane, plugging in with existing PKI, and running Istio on VMs and across multiple clusters.
The Deploy Istio for Production Workshop is a hands-on workshop focused on what it takes to deploy Istio into production. You will have access to your own linux virtual machine with a Kubernetes cluster and Istio to complete the exercises. This is not an entry level workshop to learn about Istio. This workshop includes a certification option. This credential, by Solo.io, certifies that recipients possess the essential skills to deploy Istio, configure it, debug it, secure it and operationalize it for their organization.
A
Thanks
everyone
for
joining
our
session
today,
I
think
it's
going
to
be
basically
still
an
issue
into
production.
That's
going
to
be
the
theme
of
today
and
just
to
give
a
quick
intro
about
myself
myself
for
cummings,
I'm
I'm
a
developer
advocate
right
now
at
at
solo,
I
o
based
out
of
bangalore
a
long
time
open
source
contributor
to
multiple,
open
source
projects
and
author
of
a
book.
Keratic
book
book
is
pretty
old.
A
B
Yeah
thanks,
hey
thanks
folks
for
joining
and
thanks
the
kcd
bangalore
organizers
team
for
letting
us
conduct
this
workshop.
I'm
really
excited
to
do
this,
so
I
relocated
to
india
around
one
and
a
half
years
ago.
So
I
was
doing
a
lot
of
these
workshops
and
sessions
on
iste
or
other
cloud
native
technologies
in
u.s.
I'm
very
excited
to
get
the
ball
rolling
in
india
too,
so
I've
been
a
leader
and
maintaining
stu
and
a
few
other
key
projects
in
the
cncf
space.
B
I've
been
working
with
this
year,
pretty
much
for
from
the
beginning,
like
four
and
a
half
years
or
so
have
bootstrapped
several
working
groups
there,
including
product
security,
was
leads
for
networking
and
policy
and
telemetry
and
now
part
of
the
technical
oversight
committee.
I
joined
rio
solo
last
year
and
I've
been
heading
the
engineering
team
from
india.
Actually
so
most
of
my
developers
are
still
in
us
and
it's
an
interesting
thing
to
manage
our
team
from
here.
You
can
see
my
contact.
B
You
can
reach
me
through
any
of
these
mediums
if
you're
on
this
to
community
you'll,
see
me
in
the
toc
meeting
a
few
several
working
group
meetings
like
kamesh.
I
have
it
in
a
book
on
istio,
it's
a
manning
one.
It's
rather
updated
so
I'll
differ
from
commission
that
front.
I
deliberately
chose
to
write
the
book
with
the
apis
and
concepts.
I
know
that
won't
change
for
a
long
time
and
there
is
a
team
that
keeps
this
updated.
B
A
A
We
got
a
discount
coupon
for
the
istio
in
action
book,
probably
I'll
share
that
at
the
end
of
the
session,
so
that
you
can,
if
you
want
to
read
eastern
action
from
christian
poster,
you'll
have
a
chance
to
that
and
also
a
link
to
the
istio
certification
from
solo.
So
we
have
some
lot
of
goodies
back
then.
So
please
do
stay
tuned
with
us
at
any
time.
Any
questions
please
do
stop
us
we'll.
A
So
so
we
know
we
know
a
lot
of
goodies
about
istio
right.
I
think
one
of
the
thing
is
that
we
know
each
year
provides
a
lot
of
lots
and
lots
of
good
stuff.
Some
of
you
are
experimenting
with
stuff,
like
you
say,
gives
your
rate
limiting
this
year
gives
you
circuit
breaking,
and
all
these
things
right,
but
one
of
the
things
what
you're
going
to
see
today
is
more
from
what
is
to
do
as
you
right.
A
What
I
mean
by
that
is
that
what
is
that
as
a
persona
as
a
security
administrator
or
as
a
project
manager
or
as
a
developer
or
as
somebody
as
an
operation
guy
within
your
organization
within
the
team
and
how
does
istio
is
going
to
help?
You
is
what
we
are
going
to
see
more
today
right,
because,
obviously
many
of
you
have
seen
lots
and
lots
of
videos
about
istio
and
what
is
your
does,
what
it
features
as
etc,
etc.
A
A
And
how
do
we
do
workspaces
multithings
lot
of
interesting
stuff
that
neeraj
is
going
to
share
to
us
so
we'll
go
to
that,
but
before
that
for
people
who
are
new
to
history,
who
are
experimenting,
it
just
a
little
history
about
what
we
got
here
right.
Obviously,
this
all
started
with
this
big
bank.
What
we
call
us
right.
So
this
is
not
the
big
bang
what
we
heard
of
in
our
physics
books.
This
is
all
the
big
bang
that
we
started
with
breaking
down
our
monolithic
applications
into
microservices
right.
A
This
all
started
a
few
years
ago,
and
still
people
are
doing
it
still.
I
don't
say
that
we
are
completely
moved
on
to
microservices,
or
so
it's
completely
on
monolithic
right,
but
in
my
opinion
I
always
say
that
all
the
different
type
of
architectures
are
still
relevant
and
still
important
in
any
organization.
I
cannot
completely
do
my
monolithic
to
microservice
or
I
cannot
completely
do
serverless.
A
So
that's
one
of
the
place
where
each
year
also
fits
in
that
we'll
see
more
about
that
once
we
talk
very
still
fits
into
these
kind
of
things
right
so
obviously,
breaking
down
into
monolithic
to
micro
services
brought
a
lot
of
benefits
to
us
right,
strong
module
boundaries,
independent
deployment
right
because
we
saw
all
these
services
were
autonomous
and
they
were
able
to
build
the
services
faster
and
then
get
to
deployment
quicker
right
and
also
it
also
gives
you
a
technology
diversity.
What
I
mean
by
that
is,
you
can
use
polyglot
development
right.
A
You
no
longer
see.
Okay,
I'm
a
document
shop
or
I'm
a
java
shop
or
I'm
a
go.
I'm
a
python
shop
kind
of
thing
right.
We
can
mix
all
the
beauties
of
all
different
languages
and
then
get
them
and
deploy
those
services
and
make
them
talk
with
each
other
and
work
with
each
other.
So
that's
that's
the
beauty
of,
and
benefits
of,
microservice
bought
in
right,
because
we
are
able
to
do
all
those
things,
but
at
the
same
time,
one
of
the
things
which,
which
is
the
developer,
we're
talking
about
the
personnel
right.
A
What
you
did
not
do
is
like
when
I
come
in
as
a
developer
or
when
I
come
in,
I
say
as
a
developer
and
say
where
why
my
service
is
failing,
because
that's
a
complexity
that
the
distributed
computing
brings
in
right
because,
as
many
say,
microservice
I'm
going
to
distribute
across
the
moment
I
say
I'm
going
to
distribute
across.
I
want
to
understand
why
my
service
is
failing
when
something
is
failing
right
as
a
developer
and
as
an
operations
guy.
A
I
come
in
and
see
okay,
why
did
my
which
nodes
file
which
cloud
node
is
not
working?
My
my
service
is
not
running
on
them,
so
this
is
another
thing
you
get
yourself
into
right.
Obviously
you,
if
you
imagine
yourself
as
one
of
these
personas
in
your
organization,
then
you
say:
okay,
bad,
it's
failing,
because
it's
super
complex
to
go
and
find
out.
That
is
failing
at
immediately
quickly
right
to
kind
of
do
a
recovery
and
last
but
not
the
least.
Our
security
guy
will
still
be
thinking
like
what's
happening.
Right
is
my
system
secured.
A
Somebody's
hacking
is
everything
is
encrypted
and
lots
of
other
stuff
that
comes
in
the
picture,
so
this
is
one
of
these
things
which
we
need
to
tackle
as
as
a
as
a
developer
or
some
operators,
or
as
a
security
guy
when
you
start
to
embrace
on
microservices
and
that's
where
the
microservices
tradeoff
also
comes
in
right.
So
because,
though,
we
have
strong
boundaries,
we
have
strong
everything
like.
We
still
have
some
more
weakness,
that's
built
into
the
system
right
because
it
has
a
lot
of
weakness.
A
For
example,
I
don't
know
where
it
is
operational
complexity
like
how
I
package
and
deploy
that's
one
thing
and
since
distributed
computing,
I
don't
know
like
network
reliability,
unreliability,
observability
and
security.
All
these
things
also
comes
into
picture.
So
how
do
I
handle
all
these
things
together
right
when
I
start
to
embrace
this
stuff?
A
So
this
is
where
things
gets
more
complex
right,
it's
more
more
than
a
technology
that
we
use
behind
the
scenes
more
than
other
things,
it's.
How
do
we
start
doing
the
other
important
pieces
of
your
software
development
right?
It's
not
just
about
the
technology
that
we
use
so
obviously
with
the
invention
of
docker,
which
is
the
kubernetes
containerization,
and
all
these
things
we
were
able
to
kind
of
to
alleviate
the
operational
complexity.
You
need
to
say,
like
we
package
application,
deploy
the
application.
Kubernetes
takes
care
of
scheduling
on
the
right
node.
A
Whenever
the
node
fails,
it
moves
a
workload
to
a
different
node.
It
takes
up
all
those
basic
operational
capabilities.
That's
that's
built
in
kubernetes
did
do
that
problem
solve
the
problem
for
us
from
the
operational
point
of
view,
so
we
still
have
the
solution
to
the
network
and
abilities
still
unsolved
right,
but
still
products
like
eco
or
service
mesh
particles,
just
generally
categorize
a
service
mesh
for
a
second.
A
They
try
to
solve
this
problem
by
kind
of
adding
rate
limit
circuit
breakers
and
all
these
stuff
to
build
in
stuff
right,
but
all
these
things
did
not
come
with
an
additional
thing.
For
example,
I
cannot
just
like
that
go
and
add
at
a
circuit,
breaker
or
weight
limiting
earlier.
If
you
go,
if
you
remind
mac
yourself
before
easter
was
born,
these
were
done
using
the
library.
A
So
obviously,
we
call
them
as
netflix
suite
of
libraries
like
the
libs,
that
we
add
to
our
java
applications
at
the
configuration
that
we
put
in,
which
is
which
is
kind
of
keeps
bloating.
Your
application
right,
because
we
need
to
add
a
lot
of
things
and
then
maybe
java
might
be
having
it
dotnet
might
not
be
having
it
or
python
might
not
be
having
it.
We
need
to
rewrite
those
libraries
there's
a
lot
of
complexities
involved
in
that
right.
So
without
those
additional
libraries
we
still
aren't
able
to
solve
the
problem
right.
A
What
is
kind
of
like
how
do
I
add
circuit
breaker?
How
do
I
add
rate,
limiting
delays,
doing
kiosk
testing
and
all
this
stuff?
So
we
went
ahead
and
then
did
that
the
next
one
was
the
solution
to
be
unreliability
right,
for
example
like
how
to
observe
things.
That
is
again
another
important
stuff
right
when
something
fails,
how
to
add
traces
and
then
find
out
what
caused
the
failure
and
all
these
things
right.
A
They
still
had
a
problem
there
so
because
the
solution
to
observability
is
that
the
client
from
service
say
call
to
service
b
to
service,
and
you
see
the
red
arrow
there,
which
says
the
service
fail.
We
still
need
to
add
some
more
set
of
libraries
into
our
thing,
what
we
call
instrumentation
into
our
applications
and
so
that
like
they
can
know
where
the
services
fail,
but
all
these
comes
with
the
additional
overhead
right
and
last,
but
not
the
least
our
security
thing.
A
So
we
don't
know
who
is
accessing
what
earlier
days
we
used
to
have
static
ips
you
need
to
have
fixed
ip
addresses
where
you
can
go
find
out
with
advent
of
cloud
native
application,
deployment,
kubernetes
and
all
these
stuff.
We
don't
know
which
we
cannot
do
that
kind
of
thing
right
now
on
security
stuff
right,
so
we
have
to
rely
on
some
encryption
kind
of
thing:
workload:
identification
we'll
talk
a
little
bit
more
about
during
the
labs
on.
A
How
do
we,
how
we
do
workload
identification
and
all
these
things
needs
to
be
part
of
that,
so
that
your
information
and
your
data
is
secured
across
right.
So
this
is
where
the
problem
was
starting
to
bloat
on
right
when
we
talked
about
adding
stuff
to
your
to
your
services,
which
means
that
I'm
not
writing
any
business
logic
the
other
day
right.
It's
not
my
business
thing
that
I'm
doing
there,
I'm
adding
I'm
adding,
say
a
service
discovery,
a
library,
a
retry
library,
a
load
balancing
library,
a
metric
library.
A
A
I
have
to
maintain
the
application
nuts,
and
so,
if
you,
if
your
organization
is
not
a
software
shop,
then
that's
going
to
be
pretty
complex
right,
because
I
know
only
about
to
write
applications
for
my
business
and
when
my
when
I
writing
libraries
like
these,
I
don't
know
like
what
these
libraries
do
right.
What
is
outdated?
How
do
I
get
it
updated?
What
the
project
goes
off
to
us
right
and
all
these
things
become
complex
and
also
this
leads
to
a
project
delivery
kind
of
thing,
because
my
project
is
not
going
on
time.
A
I'm
not
going
to
the
market
faster,
quicker
and
all
these
stuff
right,
which
makes
things
even
more
complex
right
because,
like
the
overall
purpose
of
getting
to
microservice,
is
that
I
want
to
go
faster
to
market,
make
better
deployments,
give
better
user
experience
solve
these
expectations,
etc,
etc.
And
these
were
the
problems
which
were
indirectly
done
even
before
when
we
started
with
microservices
and
adding
libraries
and
all
this
stuff,
okay,
but
what
we
are
going
to
look
at
and
obviously
you
know
the
answer.
A
Also
for
this
is
that
what
is
the
solution
to
this
problem?
How
do
I
avoid
this
right
with
the
cloud
native
application
deployment?
How
do
I
solve
this
problem?
What
does
istio
as
a
service
mesh
gives
the
name?
So
this
is
what
is:
is
the
trucks
of
today's
topic
and
what
you're
going
to
see
and
how
you're
going
to
put
that
into
production
using
a
set
of
labs
that
we're
going
to
do
so?
What
istio
basically
did
is
that
it
moved
all
the
stuff
from
an
application
into
what
is
called
as
a
sidecar.
A
It's
again
a
pattern
that
is
there
so
basically
making
slimming
down
your
service.
As
you
see
on
the
picture
that
I
right
there
on
my
on
my
screen,
so
we
have
service
and
service
b
and
then
we
haven't
attached
a
sidecar,
a
pattern
to
that
and
sidecar
takes
care
of
doing
all
the
things
right.
It
redirects
the
traffic
to
the
sidecar
and
we
offload
all
the
stuff
which
talked
about
right
now,
all
the
micro
services
properties.
A
What
I
call
as
into
these
sidecars
right
that
kind
of
solved
one
bit
problem
right,
because
the
side
card
now
will
take
care
of
implementing.
How
do
I
talk
to
prometheus
to
get
the
metrics?
How
do
I
talk
to
jager
to
send
the
tracing
and
how
do
I
add
encryption
using
mtls
and
all
these
stuff
right
so
and
all
for
authentication,
etc,
etc?
A
And
that's
all
a
measure
of
the
problem
right?
But
if
you
think
for
a
second,
is
that
everything
centralized
right?
No,
it's
not
right,
for
example
like
when
I
have
an
application,
I
might
have
an
application
which
only
needs
tracing.
It
does
not
need
metrics.
I'm
just
saying
an
example
right.
I
think
it's
a
very,
very
probably,
as
I
say,
a
bad
example
in
that
sense,
but
but
generally
saying
like.
Let's
imagine
that
I
want
a.
I
want,
an
application
that
needs
only
prometheus
or
just
jager
right
there.
A
Sorry
in
that
case,
I
also
want
to
have
an
architecture
that
helps
me
to
kind
of
separate
these
two
things,
what
we
call
as
a
data
plane
and
a
control
plane.
So
basically
the
control
plane
is
takes
care
of
all
the
things
which
talks
to
your
api
server
in
the
this
case
is
going
to
be
kubernetes,
understand,
discover
all
the
services
do
all
the
stuff
right
and
obviously,
and
then
generate
this
onboard
config
you'll
see
about
onward
config
during
the
labs,
and
then
it
pushes
to
the
on
voice.
A
Sidecar,
that's
going
to
be
there
on
your
data
plane,
which
is
attached
to
your
workload
or
an
application
right
in
that
way,
what
happens?
Even
if
my
even
the
case
for
extreme
cases
where
my
control
plane
goes
down,
my
data
plane
still
works
because
the
configuration
knows
about
to
reach
to
the
kubernetes
service,
because
it's
cached
and
it
runs
based
on
the
last
known,
good
configuration
right
and
also
like
this
also
gives
you
a
flexibility
that
I
can
kind
of
control.
A
What
I
need
to
get
in
what
I
don't
need
from
an
istio
point
of
view
right
what
features
what
plugins
I
can
enable?
I
should
I
don't
call
this
a
plugin,
but
I
should
say
what
features
I
want
right,
for
example,
what
I
need
to
scrape
in
only
metrics
or
tracing
or
authentication
or
encryption,
so
those
kind
of
things
can
just
be
pushed
only
to
the
application.
Specific
logic
I
mean
my
application
are
the
data
plane
and
the
control
plane
controls
the
overall
stuff
of
your
thing
right?
How
do
these
data
plane
gets
updated?
A
How
do
it
knows
about
other
services
and
all
these
things?
So
this
is
a.
This
is
a
great
separation
of
concerns
here,
if
you
see
architecturally,
because
you
can
scale
your
data
plane
without
scaling
a
control
plane
that
helps
you
to
do
the
scaling,
because
otherwise,
if
you
see
the
other
service
mesh
implementations
in
the
market,
they
would
have
mixed
these
two
things
together,
which
makes
it
complex
right,
because
I,
when
I
scale
my
data,
play,
I'm
obviously
scaling
my
control
plane
as
well.
A
Eventually
that
could
lead
to
a
disaster
where
my
kubernetes
cluster
might
crash.
So,
but
what
we
have
done
with
envoy
an
istio
is
that
we
separated
all
these
things
and
make
sure
that
these
control,
plane
and
data
planes
say
separate
so
that,
like
you,
can
scale
them
individually
without
affecting
each
other.
Even
in
other
case,
I
can
update
my
control
plane.
For
example,
steer
does
a
new
release
or
a
cv
fix,
or
something
like
that.
A
I
don't
need
to
kind
of
go:
wait
for
for
istio
to
come
and
complete
stuff
right
because,
like
for
example
like
I
don't
need
my
data
plane
to
be
update,
data
plane
can
still
stay
there.
I
go
update.
My
control,
plane
alone
will
go
to
a
new
version.
Obviously
my
data
plane
on
the
next
refresh
is
going
to
get
the
new
configure
configuration
and
updates
to
it,
so
that
makes
it
much
easier
for
us
to
kind
of
handle
these
updates
individually
without
affecting
each
other.
A
That's
a
typical
one
of
the
expectations
of
why
we
do
micro
services
right,
so
so
that's
something
which,
which
also
goes
to
the
next
thing.
What
we
talk
about
this
makes
our
guys
bit
more
happy
right.
A
little
bit.
I
think
one
more
slide
before
I
give
it
to
niraj
is
that
this
is
not
only
with
that
right.
For
example
like
for
the
guys
who
are
controlling
doing
the
control
plane
thing
right,
they
can
also
control
stuff
just
by
applying
stuff
to
the
api
server.
A
For
example,
I
want
to
do
a
blue
green
deployment,
or
I
want
to
do
a
character
deployment.
I
want
to
do
other
kind
of
microservices
patterns.
It
could
be
done
without
affecting
the
data
plane,
because
I
can
just
go
apply
these
yammers,
the
crd,
is
what
we
call
the
equipment
is
built
just
at
the
api
server,
and
then
everything
gets
affected
immediately
affected
immediately
right.
So
that
makes
my
security
guy
more
happy.
That
makes
my
developer
more
happy
and
also
makes
my
operation
sky
more
happy
right.
A
So
so
this
is,
this
is
just
an
overview
of
from
from
a
from
personal
perspective,
what
is
your
candidate,
what
you
bought
for
you,
etc,
etc
right,
but
there's
a
little
bit
more
right.
This
is
not
this.
What
I
was
talking
about
is
a
small
set
of
application
in
a
single
cluster
and
then
without
any
kind
of
tendency,
and
all
these
things
right,
I'm
just
going
to
give
it
to
niraj
who's,
going
to
talk
more
about
these
stuff
right,
going
taking
them
to
the
next
level
in
a
typical
enterprise
deployment,
a
huge
deployment.
B
Awesome:
hey
thanks
gummies.
This
is
a
great
overview
right.
So
commerce
rightly
explained
that
why
are
we
separating
the
data
in
the
control
plane,
control
plane,
gives
you
an
abstraction
layer
for
configuration
and
translates
that
to
envoy.
So
in
theory,
you
don't
have
to
learn
about
what
the
data
plane
configuration
is.
You
can
use
your
kubernetes
native
custom
resources.
You
can
use
the
cic
devops
processes
to
make
sure
you
configure
and
manage
your
mesh.
So
now
we
want
to
take
this
concept
further
right,
so
you
have
istio
running
in
a
single
cluster.
B
I
just
saw
in
chat
sandeep
mentioned.
You
know.
There
are
many
services
that
we
have
running
in
one
cluster.
We
want
to
isolate
our
fault
domains
and
make
sure
that
we
organize
our
clusters
around
these
service
communication
boundaries.
That's
a
reasonable
thing
to
do.
There
are
other
reasons
when
we
talk
to
our
customers
why
they
want
to
go
to
multi-cluster
setup
right.
So
if
you
dial
back
to
few
years
ago,
most
of
the
customers
most
of
the
enterprise
I
was
talking
to,
they
were
learning
kubernetes.
They
were
learning
cloud
native.
B
They
were
trying
to
get
one
cluster
up
and
running
and
half
services
running,
and
that
was
a
big
achievement
now
fast
forward
to
2022
there's
so
many
companies
that
we
talk
to
for
their
multi-cluster
is
just
a
necessity,
and
these
are
the
three
key
requirements
that
I
have
seen
that
they
always
want
to
have.
This
is
distilled
down
from
multiple
conversations.
I've
had
over
the
last
four
four
and
a
half
years
conversations
commerce
had
our
field
team
had
it
solo
right,
so
basically
they
want
to
make
sure
they
have
inter-clustered
product.
B
So
there
should
be
seamless
traffic
communication
between
applications
that
are
deployed
across
clusters
with
scale
over
support.
In
a
way
these
applications
don't
need
to
know
the
cluster
boundaries.
They
should
feel
like
they're
talking
to
a
com
application,
whether
it's
in
the
same
cluster
or
whether
it's
a
different
cluster.
All
of
that
is
abstracted
away
the
identities
that
the
applications
have
should
be
retained,
so
end-to-end
encryption
happens
and
nothing
in
between
can
break
that
encryption.
Nothing
in
between
can
inspect
that.
B
So
that's
the
kind
of
requirement
you
need
in
this
modern
cloud-native
world
second,
is
having
the
right
fault:
tolerance
in
your
system
right,
so
you
have
multiple
clusters,
just
like
cindy
mentioned
in
the
chat
right,
so
you
want
different
failure
domains.
So
you
don't
want
one
cluster
to
be
dependent
on
another
cluster.
Each
cluster
and
mesh
should
be
independent
and
they
should
be
able
to
function
if
the
others
go
away.
That's
a
big
big
requirement
or
actually
scaling
your
architecture.
B
If
you
don't
build
these
primitives
early
on
in
your
system,
once
you
have
a
very,
very
complicated
design,
it's
hard
to
add
back,
so
we
always
want
to
make
sure
you
have
a
fault,
tolerant
design
system
for
your
multi-cluster
mesh
and
the
last
one
which
is
very
important,
and
sometimes
customers
don't
realize.
Is
you
want
to
have
a
heterogeneous
network
support
right?
So
you
don't
want.
Even
if
your
current
setup
is
small,
you
don't
want
to
start
off
with
the
assumption
that
you
can
have
flat
networking.
B
You
can
have
unique
ips
for
pods
and
services
across
all
your
clusters.
Actually,
you
want
to
build
a
system
so
that
your
network
is
heterogeneous.
You,
even
if
you're
in
your
on-prem
on
the
same
cloud,
for
example,
if
you're
on
gke,
they
can
provide
you
flat
networking,
but
eventually
you
might
want
to
use
aks.
You
might
want
to
use
eks
or
have
an
on-prem
cluster
right,
so
you
will
have
heterogeneous
networks.
You
want
to
architect
your
system
so
that
you
can
have
overlapping
ip
spaces
between
different
clusters
and
the
traffic
still
works.
B
So
these
are
the
requirements
that
we
have,
and
now
we
want
to
talk
about
architectures
and
options
available
to
you
when
you
want
to
do
multi-cluster
mesh.
So
no
go
back.
Yes
thanks.
So
this
is
the
architecture
that
is
currently
supported
in
sdo
right.
So
we
have
been
working
in
history
of
a
lot
of
complicated
scenarios
for
multi-cluster
and
trying
to
understand
how
can
we
support
the
various
use
cases?
B
So
if
you
go
to
the
history
documentation,
you
will
see
various
options
of
shared
control,
plane
replicated
control
like
20
other
terminologies,
based
on
the
requirements
that
are
listed
in
the
last
slide.
This
is
the
key
architecture
that
works
for
you.
If
you
want
to
make
sure
you
have
those
requirements,
so
in
this
architecture,
you
will
have
a
steer
running
in
each
cluster.
So
this
is
the
key
thing
about
fault,
tolerance
right,
so
you
don't
want
one
istio
controlling
every
other
cluster
that
doesn't
work
the
way
this
class.
B
This
architecture
works,
is
each
istio
control.
Plane
is
given
access
to
the
kubernetes
api
server
for
every
other
cluster.
That's
why
you
see
so
many
lines
going
through
this
diagram.
So
basically,
every
cluster
is
your
control
plane
talks
to
the
kubernetes
api
server
from
other
clusters.
It
discovers
things
that
it
needs
to
discover
and
that's
how
application
traffic
can
go
from
one
cluster
to
another
seamlessly.
B
So
now
this
architecture
might
seem
simple
that
it
works
out
of
the
box,
but
there
are
some
challenges
that
happen
with
it,
and
this
is
why
I
always
want
to
talk
about
the
trade-offs
when
you
have
simplicity
plus
when
you
want
to
have
some
other
other
benefits
like
security
and
fault
targets
right.
So
first
thing,
which
is
a
major
limitation,
is
you
need
a
cross-cluster
kubernetes
api
access
from
a
security
point
of
view,
you
really
don't
want
that.
B
B
Secondly,
since
all
the
issue,
control
planes
are
talking
to
the
api
server
from
every
other
cluster
you're
kind
of
limited
in
scalability,
by
what
a
single
api
server
can
access
right.
So,
if
you
keep
on
adding,
is
your
control
planes?
You
still
are
connecting
you
have
a
you
have
like
a
mesh
of
control
planes
talking
to
the
kubernetes
api
server.
Secondly,
thirdly,
you
have
to
replicate
your
configuration
yourself
across
clusters.
B
So
in
this
architecture
you
are
responsible
for
making
sure
you
have
placed
all
the
service
entries
workloads
entries,
whatever
you
need
across
the
cluster.
Still
can't
do
that
right.
You
still
can
only
read
information
about
your
pods
and
end
points
from
the
different
clusters,
but
you
need
to
have
a
separate
process
to
make
sure
the
configuration
is
applied
uniformly
across
every
cluster
for
bootstrapping.
The
trust,
so
trust
here
means
how
services
from
one
cluster
to
another
can
talk
securely
using
mtls
certificates.
B
You
have
to
do
the
trust
manually
and
to
do
it
in
every
cluster.
So
if
you
have
thousands
of
clusters-
and
we
are
talking
to
some
enterprises
who
will
have
really
really
large
clusters
doing
this
manually
is
just
not
possible
and
then
for
getting
visibility
across
inter-cluster
traffic,
you
have
to
again
build
that
primitive
yourself
right,
so
you
can
have
prometheus
running
in
each
cluster.
But
then
how
do
you
roll
up
the
data?
B
And
how
do
you
have
visualization,
both
the
graph
and
the
metrics
and
the
tracing
that
commission
needed
to
that
can
span
across
clusters?
So
you
can
see
when
an
application
from
cluster
a
talks
to
application
to
cluster
b.
Then
that
makes
a
call
to
cluster
c.
You
can
trace
that
path.
So
you'll
have
to
build
all
of
these
yourselves.
If
you're
using
the
istio
multi-cluster
architecture
that
comes
out
of
the
box,
you
can
go
to
the
next
slide
awesome.
B
So
this
is
what
the
glue
mesh
solution
is,
and
we
architected
this
system
specifically
to
make
sure
we
provide
the
and
meet
the
three
key
requirements
are
listed
out,
but
we
also
take
away
the
limitations
that
sto
has
right
so
in
the
glue
mesh
solution.
The
way
it
works
is
we
deploy
an
agent
on
each
cluster.
B
This
cluster
view
point
for
you
right,
so
you
don't
have
to
think
about
a
service
entry
or
a
destination
rule
or
a
virtual
service
in
each
cluster.
You
can
think
about.
I
want
this
application
to
talk
to
this
application,
and
I
want
x
percentage
of
traffic
going
here
and
there
and
rest
of
the
hto
configurations
are
handled
by
us
and
the
way
we
do
that
is
glue.
Management
plane
takes
the
snapshots
provided
by
the
agent.
B
The
snapshot
includes
services
and
the
current
configuration
gateway
deployments,
combines
it
by
the
user,
provide
configuration
and
then
converts
it
to
steer
configuration
and
gives
it
out
back
to
each
agent.
This
agent
then
goes
and
applies
it
to
the
kubernetes
api
server,
which
will
get
picked
up
by
the
istio
control
plane
right.
So
it's
a
very,
very
flexible
and
powerful
architecture,
because
the
agent
has
access
to
the
kubernetes
api,
seven,
each
cluster,
the
glue
management
plane
does
not.
B
At
the
same
time,
we
have
good
separation
of
concern
here,
similar
to
what
kamish
was
saying
for
data
pin
and
control
plane
right.
So,
even
if
the
management
plane
in
the
agent
communication
goes
out,
the
the
local
setup
still
works
agent
is
still
able
to
reconcile
the
state
in
the
local
cluster
and
istio
is
still
able
to
convert
that
config
to
onward
conflict.
So
it's
it's
a
very
flexible,
powerful,
federated
architecture.
So
do
you
mind
moving
the
next
slide?
Commish.
B
Yeah,
so
these
are
just
quickly
the
benefits
of
this
blue
mesh
architecture.
Right
so,
like
I
was
saying,
there's
no
need
for
cross
cluster
kubernetes
api
server
access
right.
We
are
providing
a
very
powerful
persona
map
high
level
apis.
I'm
just
going
to
briefly
describe
one
of
those
apis
that
we
have
and
then
all
the
istio
configuration
is
just
generated
and
managed
by
us
directly.
You
don't
have
to
worry
about
it.
B
You
can
just
apply
the
solo
api
in
the
solo
configuration
through
your
git
ops,
whether
it's
argo
cd,
flux
or
whatnot,
and
then
we
even
do
the
automated
bootstrapping
for
the
trust.
So
all
the
root
certificates,
the
intermediate
certificates
can
be
generated
by
us
or
you
can
provide
it
and
we
can
integrate
with
vault
and
then
the
istio
level
certificates
used
by
study
is
just
managed
by
us.
You
don't
have
to
worry
about
them
yourself.
You
don't
have
to
make
sure
the
route
is
the
same.
You
just
started
from
one
place
provided
to
blue
mesh.
B
We
take
care
of
the
rest
and
then
what
in
our
architecture-
and
I
will
explain
that
briefly-
we
are
also
able
to
gather
all
the
telemetry
like
metrics
and
logs
at
one
place
in
our
in
our
control,
plane
or
in
the
management
plane
and
from
there.
You
can
visualize
it
through
a
very
simple
ui
right.
So
this
is
the
relay
architecture.
This
talks
about
how
the
configuration
goes
up,
how
the
resource
translation
happens
and
then
the
final
sto
configuration
for
each
cluster
comes
out
right.
B
B
You
can
have
prometheus
scrape
it
at
the
same
time,
you
can
also
tell
onwards
send
these
metrics
in
a
push
mode
to
a
metric
server
and
what
we
do
is
we
have
the
agent
configured
as
a
metric
server,
which
will
gather
these
metrics
and
send
them
to
the
management
plane
and
that's
how
the
management
plan
acts
as
a
sync,
where
all
the
metrics
are
gathered
from
across
different
clusters.
So
prometheus
now
can
just
scrape
that
and
then
you
can
have
one
dashboard
for
visualizing
everything
based
on
that
data.
B
Do
you
mind
going
to
the
next
slide
all
right?
So
this
is
the
last
thing
that
I'm
going
to
talk
about
before
kameh.
You
know
tells
you
more
about
the
sto
details
here,
which
is
a
concept
of
workspaces
that
we
have
in
our
bluemesh
2.0
product,
which
was
announced
and
launched
in
at
solo
con
this
year
right,
so
we
have
been
talking
with
customers
for
a
really
long
time
right
and
one
of
the
key
requirements
for
them,
and
I'm
sure
it
is
for
that
and
is
here,
is
to
support
native
multi-tenancy
in
service
mesh.
B
What
I
mean
by
that
is,
they
want
to
make
sure
configuration
that
is
applied
for
the
service
mesh
for
one
tenant
in
the
kubernetes
cluster
cannot
affect
another
tenant,
so
I
cannot
have
a
virtual
service.
I
create
for
my
application
team
foo
that
can
hijack
the
traffic
for
application
team
bar.
That's
just
not
acceptable
for
production
traffic,
because
istio
is
so
powerful
and
the
apis
are
very
low
level.
B
We've
tried
really
hard
in
the
community
to
make
that
possible,
but
these
low
level
primitives
are
just
impossible
to
make
sure
you
also
have
the
safeguards
for
multitenants
right.
So
that's
why
you
need
something
on
top
of
istio
to
give
you
this
benefit
of
strong
multitenancy
guarantees,
where,
if
you
have
different
application
teams,
different
business
units
running
on
the
same
cluster,
even
in
multiple
cluster
scenarios
right
when
they
communicate,
you
cannot
have
configuration
for
one
hijack
or
screw
up
the
configuration
for
another
tenant.
B
You
can
draw
your
isolation
boundaries
so
that
services
within
one
tenant
can,
by
default
only
talk
to
each
other.
You
will
have
to
explicitly
say:
hey.
I
want
to
talk
to
service
a
across
10
and
4,
and
if
you
don't
say
that
the
communication
doesn't
happen
so
in
glue
mesh,
what
we
have
done
is
we
have
created
the
idea
of
workspaces,
so
workspaces
is
basically
a
logical
boundary,
which
is
the
isolation
boundary
or
the
tendency
boundary
of
the
system.
B
So
these
are
constructed
of
namespaces
across
different
clusters,
so
it
can
be
named
spaces
from
one
two
or
n
number
of
clusters,
so
you
can
see
with
the
concept
of
workspace.
You
can
say
I
have
an
application
team
that
deploys
three
services
across
different
clusters
and
I
want
to
make
sure
these
this
application
steam
workspace
within
this.
They
can
talk
to
each
other
and
whatever
configuration
I
do
doesn't
affect
other
application
team
and
in
blue
mesh,
once
you
have
defined
the
workspace,
you
can
define
your
imports
and
exports.
B
It
works
better.
You
get
the
isolation
you
want
and
you
are
in
no
danger
of
you
know
accidental
misconfigurations,
taking
your
whole
cluster
down,
so
next
slide
yeah
just
summarizing
these
are
the
benefits
you
get
from
workspaces.
This
is
a
very,
very
powerful
concept
that
we
have
added.
We
have
talked
to
several
customers
who
are
really
happy
about
it.
So
I
just
wanted
to
tell
you
how
we
are
using
istu
as
a
base
as
a
toolbox
for
creating
some
of
the
powerful
concepts
that
enterprises
need.
B
So
you
get
strong
multiple
guarantees
for
the
cross
cluster
deployments
right.
So
there
are
no
naming
restrictions
right
in
the
istio
model
for
multi-cluster
you
have
to
have
the
same
name,
space
and
service
for
the
traffic
to
go
from
one
cluster
to
another.
For
us
it
doesn't
matter,
you
can
define
those
things
for
you.
B
The
data
plane
resource
consumption
by
default
is
very
optimized,
because
not
only
are
we
generating
the
virtual
services
destination
rules
and
bunch
of
other
configuration,
we
also
generate
the
sidecar
resources,
which
are
very
complicated
resources,
but
very
powerful.
So
sidecar
resource
allows
you
to
restrict
the
configuration
that
your
site
cars
see
and
because
you
can
restrict
the
configuration,
it
significantly
lowers
the
memory
and
cpu
footprint
of
c
or
sidecar.
So
this
is
one
of
the
complaints
that
many
people
who
evaluates
you
early
on,
say
you
have
a
large
cluster.
B
My
satchel
is
consuming
a
lot
of
memory.
This
is
how
you
reduce
it
and
we
do
it
automatically
for
you
just
because
we
know
once
you
define
our
workspace.
This
is
your
communication
boundary
right,
so
we
can
generate
it
automatically
for
you
and
then.
Lastly,
these
glue
resources
that
we
have
that
can
be
created
in
the
cluster
and
then
we
have
a
very
easy
way
of
organizing
the
data,
because
this
workspace
tells
us
what
is
your
ins
and
outs.
B
A
Yeah
thanks
thanks
nida.
I
think
that
was
a
wonderful
extension
like
we
now
showed
you
like
what
solo
is
capable
of
and
what
we
are
doing
around
istio
right,
because
at
times
like,
we
are
kind
of
making
these
things
simpler
for
you,
so
that
you
know
that
easter
is
complex
people
who
have
done
with
that.
We
know
that
there's
a
complex
thing
and,
as
lineage
was
saying
like
there's
an
easiest
chances
that
we
might
screw
up
configurations
which
could
bring
down
your
old
cluster
right.
A
So
we
are
trying
to
alleviate
a
few
of
those
problems
away
and
make
things
easier
for
you
so
that
we
take
care
of
all
those
complexities
and
underlying
istio
and
making
things
simple
for
you
right
and
now,
like
we'll
get
into
the
labs
and
before
that,
is
there
any
questions
that
we
want
to
handle?
Let's,
let's
spend
few
minutes
before
we
get
on
to
the
lab
so
that
we
can.
C
A
Going
to
copy
the
link
okay
before
I
think
I
can
keep
popping
your
questions.
I
think,
as
nina's
told
you'll
be
starting
to
answer
these
questions.
I
put
on
a
link
on
your
chat,
so
if
you
copy
the
link
and
paste
it
on
your
browser,
it's
recommended
that
you
have
a
chrome
browser
because
safari
and
firefox
I'm
not
sure
how
it
works.
So
you
just
take
a
chrome
browser
here
and
then
put
things
on
that.
I
think
I
showed
you
I'm
just
putting
the
link
on
here.
A
Just
soon
start
the
things
to
come
up,
so
you
can
copy
the
link
and
put
it
on
your
thing.
I
think
it
doesn't
need
any
registration
for
now
and
then
it
technically
takes
me
to
my.
I
think
you
will
not
be
getting
this,
but
it
just
takes
me
to
the
study
room
and
then
let's
need
to
go
to
my
exclusives
and
then
I
need
to
start.
A
So
when
you
see
this,
you
basically
see
a
screen
like
this
right
with
some
amount
of
things
and
a
start
track,
and
then
just
click
on
this
start
track,
so
that
whatever
we
are
going
to
do
right
now
is
everything
is
going
to
be
on
our
browser
right?
You
don't
need
it.
You
don't
need
to
install
anything
on
the
machine.
You
don't
need
any
cli
special
tools,
nothing
on
your
machine
is
required.
A
It's
all
you
required
is
a
good
latest,
up-to-date
chrome
browser
or
any
chromium
based
browser
for
that
matter,
and
then
that's
where
we
are
going
to
do
everything
for
part
of
the
labs
right.
It
might
take
few
minutes
for
everybody
to
get
so
what
we'll
do
is
like
the
usual
baby
do
is
that
you
put
on
these
things
and
then
you
you
can
put
on
an
emoji
or
a
chat
or
anything
on
the
other
zoom
thing
saying:
you're
good,
so
that
we
can
get
started
with
the
instructions
and
other
stuff
it
basically.
A
Involved
up
and
running,
please
do
put
your
questions
on
the
chat,
we'll
see
what's
wrong
with
that
all
right,
I
think
I
think
this
this
lab
will
be
available
for
let's
say
five
to
six
hours,
the
whole
day.
The
moment
you
start
to
click
right
and
and
it
the
maximum
time
you
can
do
is
only
up
to
10
o'clock
tonight.
That's
right!
I
was
set
up,
so
you
cannot
use
it
beyond
that
time.
A
Okay
and
I
think,
behind
the
scene
like
basically,
we
use
a.
We
use
a
platform
called
as
instruct
to
kind
of
do
all
the
labs,
so
what
it
basically
sets
up.
It's
a
cloud
instance
which
is
being
set
up,
and
then
it
installs
kind
or
kts
cluster
in
our
case
and
then
uninstalls
and
setups
few
things
that
allows
us
to
do
a
few
stuff.
So
that's
that's
what
is
being
done
behind
the
scenes
so
so,
which
means
that
the
provision,
the
cloud
instance
is
taking
a
bit
of
time.
D
A
E
Got
it
hey
in
in
a
service
mesh
one
of
the
challenges
by
the
way
I'm
ansel?
I
I
just
joined
a
little
bit
late,
so
you
guys
can
hear
me
yeah,
okay,
so
what
we
are
doing
to
overcome
the
the
data
availability
in
a
multi
cluster
environment
like
if
you
have
one
service
depending
on
data
on
one
cluster,
and
it
expect
the
same
kind
of
data
on
the
other
side
in
a
failover
scenario.
B
Yeah
yeah,
so
so
that's
a
great
question
right,
so
it
kind
of
depends
on
the
kind
of
back
and
system
and
the
databases
you're
using
right.
So
many
of
these
databases
itself
provide
some
fill
over
semantics
or
replication
across
clusters,
and
ac
is
right
for
glue
mesh.
What
we
do
is
from
the
networking
point
of
view
we
can
make
sure
you
fail
over.
A
Yeah,
just
to
just
to
add
to
that
neeraj
nearest
point
is
that
so
a
few
of
these,
the
questions
that
you
asked
is
a
little
bit
away
from
the
platform,
also
right
because,
like
in
this
case,
in
your
case
on
a
micro
service
architecture,
to
achieve
more
reliability
for
data,
and
then
all
these
you
can.
You
can
achieve
acid.
A
Okay
on
the
d,
it's
just
to
be
a
cd
on
the
data
side,
so
you
can
use
patterns
like
cqrs,
even
sourcing
and
all
these
things
to
make
sure
that
your
data
gets
replicated.
So
that's
more,
it's
more
architectural
thing
than
the
the
product
can
handle,
like
I'm
not
sure,
as
of
today,
I'm
not
sure
any
product
that
handles
the
real-time
application,
unless
until
you
put
something
like
kafka
streaming
in
between
and
then
streamline
the
data
and
then
do
the
replication
across
using
events.
So
that's
the
most
easiest
thing
for
distributed
computing.
A
A
Interest,
so
I
so
we
do
have.
We
do
have
ask
these
questions
before
from
few
of
our
customers,
but
we
just
suggested
the
same
thing
like
what
we
just
suggested
to
use
to
use
things
like
cqrs
and
even
sourcing,
and
all
these
things
right
to
make
to
make
sure
that
there's
a
real-time
replications
of
data
happening
across
your
your
clusters.
B
So
another
interesting
point
here
and
cell
is
that
most
of
the
customers
that
we
talked
to
right
so
even
in
the
old
world
of
monolith,
whether
they
were
using
big-ip
or
some
other
adc
right,
they
were
used
to
replicating
the
data
right.
They
they
knew
when
you
had
to
fail
over.
I
had
to
have
the
data
migration,
so
that
was
kind
of
like
a
solved
problem.
B
Maybe
it
has
changed
because
of
the
new
databases
and
the
new
backend
technologies
have
come
up,
but
many
of
the
time
the
data
might
the
data
redundancy
for
failover
is
solved,
but
in
microservices
they
just
don't
understand.
How
can
we
do
fine
grind
failover
right,
so
they
don't
want
to
fill
over
the
whole
cluster.
They
want
to
fill
up
a
particular
service.
E
A
A
Great
while,
while
others
comes
like,
we
just
keep
moving
because
at
the
interest
of
time
so
the
moment
the
moment
you
get
the
get
your
thing
up
and
running
like
this
is
what
you
see
on
your
screen
is
basically
a
a
chat
when
I
mean
a
window
like
this,
where
you
have
a
terminal
and
you
have
the
instructions
right
by
the
side
right.
So
this
is
what
you
will
also
be
seeing
the
moment.
Your
your
thing
is
up
and
running
for
you.
So
just
let
me
go
for
a
second
I'll.
A
A
I
think,
for
sometimes
it
takes
some
some
some
more
time
for
us
like
just
just
follow
this
up
anyways
the
recording
is
there
probably
you
can
just
follow
it
up,
and
this
this
lab
is
also
available
for
six
to
eight
hours
after
this
workshop,
so
that
you
can
go
back
and
try
it
again
as
well.
So
so
there
are
a
lot
of
choices
for
you,
so
this
is
what's
going
to
be
the
lab,
as
I
told
you
like,
you,
don't
need
any
enrollment
for
you
to
go
type
stuff
in
case.
A
If
you
see
your
lab
session
is
expired
or
connection
is
closed.
Please
do
click
on
this
refresh
link
right
up
there,
so
that,
like
you,
get
back
your
enrollment,
nothing
gets
lost
for
that
matter.
If
you
use
a
login,
luckily
I
guess,
like
your,
your
progress
will
be
saved
so
that,
like
you,
can
come
back
and
start
where
you
left
off
all
right.
A
A
There
are
some
details
which,
which
gives
you
I
will
not
be
covering
I'm
not
reading
through
every
of
them,
and
then
we
just
go
step
by
step
and
then
I'll
explain
them.
What
we
are
doing.
You
will
understand
on
why
at
a
very
basic
level,
because
that's
the
what
you
call
that's
the
heart
of
history
and
end
of
the
day
right,
you'll
see
a
very
basic
online
production
on
our
first
lab,
then
introduce
to
istio
installation
and
do
some
basic
application
deployment.
A
All
these
things
in
the
second
one
and
then
on
the
third
lab
you'll,
see
about
observability
telemetry
and
all
this
thing
and
security
after
that,
and
then
finally,
like
we'll,
also
see
about
how
to
debug
stuff
using
histocial,
very
basic
elements,
things
and
setting
up
certificates
and
also
like
the
one
which
niraj
covered
on
the
workspaces
right.
How
do
we
export
and
other
things?
We
will
not
be
using
blue
crds,
but
we
will
see
we'll
be
seeing
how
istio
does
it
underneath
right?
So
that's
what
we
do.
A
So,
let's
get
started
so
the
very
first
lab
you're
going
to
see
is
like
how
do
we
set
up
on
voice
so
the
the
very
basic
things
we
do
here,
just
copy
paste,
the
stuff
and
control
c
control
v-
does
work
command
c,
a
command
v
if
you're
a
mac
os.
So
both
of
them
works
once
you
hit
copy
here,
so
just
copy
paste
here
we're
just
deploying
the
applications.
A
We
can
just
say,
cube,
control,
gate
boards,
you
see
the
application
is
getting
created
and
wait
for
that
and
and
there
we
go
so
we
have
the
application-
let's
check
it
once
so,
I'm
just
going
to
go
ahead
and
call
it
as
obviously
it's
not
going
through
any
proxy
right
now.
That's
the
reason
why
you
see
just
the
user
agent
as
girl,
so
what
we're
going
to
do
right
now
is
going
to
deploy
an
onboard
configuration
all
right.
So
this
is
what
you
see
as
an
online
config.
A
A
So
this
is
a
json
or
ammo
whatever
you
call
as
in
the
hammer
in
this
case.
So
this
is
the
very
very
fundamental
or
a
very
basic
on
y
configuration
that
that
we
write
for
us
to
do
a
proxying
of
our
http
services
behind
the
scenes
right.
So
it
says
that
it
listens
on
this
particular
socket
on
this
port
and
it
has
an
access
clock
for
seeing
the
logs
and
we
have
a
listener.
Basically,
there's
an
http
listener.
A
It's
going
to
just
routing,
but
now
just
imagine
that
there's
an
http
thing
connection
manager
is
routing
your
request
that
you
get
from
ingress
into
your
community
services
that
are
discovered.
Okay,
that's
what
we're
going
to
do
right
now.
Okay,
leave
of
other
complications
for
now.
So,
just
imagine
that
I'm
just
going
to
do
this,
so
this
is
going
to
create
you,
the
the
parts
the
on
my
on
my
parts
here,
so
your
my
port
is
running
right
now
and
then
let's
go
and
get
the
headers
here.
A
It's
a
very
simple
thing
that
you're
going
to
do
right
now,
so
it's
the
same,
the
same
command
that
we
executed
earlier.
If
you
remember
the
same
header
commands,
but
that
earlier
one
went
directly
to
the
service
right
now
we
are
going
through
the
onboard
proxy.
You
see
the
host
is
onward
here
and
then
there
is
a.
There
is
an
x
on
y
request.
Timeout
millisecond
just
been
added,
because
we
added
that
on
our
configuration,
that's
a
default
one.
We
did
not
add
it
explicitly.
A
So
this
is
a
very,
very,
very
basic
stuff
that
we
saw
here
on
getting
on.
Why
I
think
istio.
Does
these
things
behind
the
scenes
for
you
don't
need
to
worry
about
all
these
things,
but
you
just
want
to
get
yourself
introduced
to
how
do
you
do
it
on
why,
in
case,
if
you
want
to
just
play
with
unvoice
right
the
next
one,
what
you're
trying
to
do
is
we're
going
to
go
and
change
the
configuration.
A
Let's
say
from
time:
orders
by
default
is
1515
000
milliseconds,
which
is
going
to
say
into
one
second,
just
for
updates
sake.
We're
just
going
to
update
this
on
my
configuration,
the
config
map
that
holds
the
configuration,
and
then
we
are
going
to
go
and
do
a
rollout
of
this
thing
right,
which
is
going
to
basically
restart
stuff.
We
have
to
wait
for
okay
get
bots
for
the
pot
to
come.
A
So
if
you
get
some
error
like
this,
just
wait
for
a
few
seconds,
because
the
part
might
be
rebouncing
or
restarting
right
which,
because
we
are
kicked
in
a
rollout
restart
here
now,
when
I
kind
of
go
and
do
a
delay
right,
I
should
get
a
gateway
timeout,
because
I've
induced
a
delay
like
one
second,
but
right
now,
I'm
trying
to
induce
a
five
second
delay,
which
means
that
the
the
on
my
proxy
is
throwing
back
an
error.
Saying:
okay,
that's
a
five
second
data,
that's
a
gateway
timeout
for
you
all
right!
A
So
this
is.
These
are
the
few
things
that
you
technically
use
in
your
chaos,
testing
right,
you'll,
be
doing
retry
time
modes
circuit
breakers
and
then
we'll
be
doing
things
like
okay
canceling
of
what
you
call
chaos
testing.
I'm
sorry
on
the
kiosk
testing,
like
we
test
all
these
things
before
make
sure
that
my
application
are
robust
handling
the
failures
properly
right.
So
that
is
one
of
the
things
which
we
did
right
now
and
the
another
important
stuff
which
which
makes
things
more
interesting
with
onboard.
A
Is
that
the
statistics
that
it
gives
you
right?
That's
a
very
important
stuff
when
you
want
to
gather
the
observability
or
find
out
something
in
your
system
or
redesign
a
re-architect
there's
a
lot
of
possibilities
that
you
can
do
with
it
right
so
out
of
the
box.
Without
you
doing
anything,
onward
exposes
a
lot
of
statistics.
Okay,
it's
a
huge
set
of
strategies
that
we
a
lot
of
things
that
you
saw
right
now.
There
is
even
prometheus
things
to
it,
we'll
be
seeing
that
later.
A
So
you
see
a
lot
of
statistics
here.
So
one
of
the
statistics
here
will
be
like,
let's
say,
for
our
timeout:
let's
go
and
find
out
if
they
see
anything
on
our
retry.
So
there
is
no
retry
here.
For
example,
all
our
retries,
our
counters
are
zero
because
we
are
not
applied
any
retry
as
of
to
our
cluster
right
now.
What
we
are
going
to
do
right
now
is:
we
are
just
going
to
go,
apply
a
replay
right!
A
That's
what
we
are
going
to
do
is
we're
saying
that
whenever
there
is
a
5xx
we're
going
to
try
it
three
times,
okay,
and
then
you
try
it
three
times
if
it
doesn't
work
even
three
times
it's
going
to
give
a
failure
right.
So
this
is
one
of
the
retry
things
that
you
technically
do
with
a
microservice
architecture
with
something
fails,
you
keep
retrying
it
for
a
few
minute
times
and
then
give
up
all
right.
A
A
C
A
And
then
now
you
should
see
some
retry
happening.
There
is
a
upstream
request.
We
strike
six
times,
because
there
was
three
replies
for
each
request
that
we
did.
Each
one
was
giving
you
500.
That
was
a
still
and
then
the
request
completed
is
six
and
then
the
limit
exceeded
is
two,
so
you
get
all
these
kind
of
statuses
right,
which
helps
you
to
kind
of
build
your
application
resiliency
in
a
way,
or
also
build
robustness,
an
application
or
divert
your
traffic
do
whatever
you
want
to
do
right.
So
this
is.
A
This
is
so
easy
with
onboard,
because
we
are
able
to
do
all
these
things
just
changing
on
the
fly
without
doing
any
restarts
or
redeploys
after
application.
If
you
imagine
the
slides
which
you
saw
earlier,
if
you
want
to
do
all
these
things
with
the
libraries,
then
we
have
to
do
an
update
to
the
libraries
redeploy,
the
application,
which
makes
your
total
deployment
complex
and
reduce
your
time
to
market
right.
So
all
the
things
that
we
do
with
istio
micro
service
based
architecture
is
that
you
want
to
go
faster
to
market
all
right.
A
So
that's
that's.
How
we
technically
do
the
lab.
I
think
we
also
saw
how
we
do
the
lab
and
all
these
things,
the
instructions
copy
paste
and,
finally,
to
verify
that
you
have
done
everything
correct.
So
there
is
a
check
button
which
you
can
click
on
once
you
click
check.
It
make
sure
that
you
have
completed
all
the
exercises
of
the
lab.
It
does
scripts
behind
the
scenes
and
when
you're
good,
then
it
goes
and
loads.
Your
next
module
or
next
chapter
all
right,
but
everyone
able
to
follow
this
and
do
this.
A
A
It
just
goes
off
now,
I'm
sorry
about
this
I'll
and
then
the
moment
you
check
and
if
you're
done
all
your
steps,
then
the
only
thing
what
you
get
right
now
is
to
start
your
next
challenge.
Right
challenges
in
this
case
is
all
the
labs
that
we
are
going
to
do
right.
Just
do
the
follow
the
link,
just
click
on
this,
which
is
going
to
be
about
installing
steel.
So
all
we're
going
to
do
on
this
particular
chapter
module.
Is
that
we'll
install
sto
obviously
deploy
some
some
applications?
A
As
you
see
here
on
my
screen,
download
the
hto
cli
and
set
it
on
your
path.
Install
is
still
a
few
of
these
things.
You
might
be.
You
might
have
experience,
you
might
be
knowing
it,
but
people
who
are
doing
history
for
the
first
time.
This
might
be
new
and
probably
it
will
help
them.
That's
the
reason
why
we
kept
these
as
well
and
then
we'll
be
installing
the
sdod,
the
control
plane.
A
E
A
So
we'll
install
the
control
plane.
First,
that's
the
sdod
and
then
we'll
play
with
that.
A
little
bit
go.
Do
some
queries
to
see
what
we
have,
what
the
configurations
has
and
all
these
things
and
and
then
we'll
do
one
install
these
two
on
our
demo
app.
Basically,
so
how
would
you
configure
a
demo
app
to
do
a
automatic,
sidecar
injection?
That's
what
we'll
be
seeing
after
that
and
that's
pretty
much
what
we
see
on
the
second
lab,
it's
very
basic
setup
of
istio
to
get
started
with
your
workflows.
A
That's
what
is
going
to
be
the
focus
of
this
particular
lab.
Okay.
So,
let's
get
started
the
very
first
thing.
Obviously
we
are
going
to
put
all
our
application
that
you
are
going
to
see
as
part
of
this
lab
into
a
name
space
called
as
eastern
action,
and
obviously
this
name
space
comes
from
the
eastern
action
book
right
that
I'll
share
the
discount
code.
If
you're
interested
in
buying
the
book,
you
can
use
a
code
from
solo
to
get
some
discounts
on
the
book,
that's
written
by
christian
poster
and
renault
all
right.
A
And
then
I'm
going
to
create
some
services
here,
it's
going
to
be
a
bunch
of
services
that
we
are
going
to
use
as
part
of
the
demos.
So
I'm
just
going
to
go,
create
a
thing:
let's
wait
for
some
time
for
these
services
to
get
up
and
ready.
Okay,
there
they
are.
So
we
have
a
sleep
application
where
we
go
usually
do
an
exec
into
that
and
call
this
thing:
there's
an
http
bin,
which
is
a
usual
service
that
is
used
in
most
of
the
demonstrations
of
istio.
Obviously
we
have
onboard
running.
A
I
think
we
can
also
go
to
the
east.
Your
system,
namespace,
is
to
an
action
name
space
to
see
what
we
have.
We
have
a
sleep
there
as
well,
a
recommendation
service.
There
is
a
web
api
through
which
we
access
the
recommendation
and
there
is
a
purchase
history
v1
service.
So
these
are
the
services
that
we
are
going
to
use
as
part
of
our
demo
applications
and
the
sleep
application
is
it
does
nothing,
but
it's
just
used
for
us
to
do
an
exec
and
then
call
the
service
right.
A
Instead
of
you
doing
the
port
forward
and
all
these
things
we
just
do
an
exit
into
the
sleep
pod
and
do
a
call
just
to
do
a
few
of
the
demonstrations
use
that
part
other
than
that
the
sleep
pod
is
not
used
for
anything
else.
It's
just
for
you
to
go
and
exit
into
the
system
all
right,
so
we
got
those
parts.
We
got
all
the
parts
up
and
running
just
note
here
right.
A
A
As
I
said
earlier,
sleep
is
just
a
just
a
convenient
spot
right
where
we
are
going
to
do
an
exit
and
then
kind
of
do
all
the
curl
commands
and
other
commands
to
to
to
do
something
within
the
service
mesh
right,
for
example,
calling
the
recommendation
api
or
purchase
usb
api
web
api,
okay
and
we're
going
to
have
three
different
applications,
a
recommendation
service.
Basically,
it's
just
imagine
like
what
the
recommendations
you
get
on
your
phone
for
an
amazon
or
any
kind
of
thing
right
and
there's
a
web
api.
A
It's
a
web
interface
through
which
we
access
the
recommendation
and
purchase
history
purchase.
History
is
not
the
version
v.
One
of
the
purchases
t
is
nothing
but
whatever
you
purchased,
it's
all
our
fictious
imaginary
services.
These
are
not
the
real
ones
just
going
to
relate
them
together.
To
do
an
example
right,
that's
what
we're
trying
to
do.
E
A
A
So
we
are
going
to
download
istio,
that's
a
shortcut,
download,
hto
url,
and
then
we
are
specifying
the
easter
version
1.11.5,
that's.
That
is
what
we're
using
for
this
particular
lab.
Though
we
have
the
other
releases
lined
up.
You
can
also
change
the
releases
if
you
don't
put
that
istio
version
variable
there,
the
application
is
going
to
download
the
latest
is
your
distro
for
you.
A
Okay,
in
this
case,
I'm
pinning
the
version
to
be
1.11.5
all
right
and
it
should
download
the
tar
onto
your
system
and
then
extract
it
and
do
all
the
stuff.
That's
the
usual
thing
that
it
does,
and
it
also
gives
you
what
we
need
to
do
here-
export
path
here,
that's
what
we're
going
to
do
right
now,
copy
this
command
and
then
paste
the
path
here
and
then,
when
I
say
clear,
is
your
ctl.
A
Version,
I
should
see
the
serial
version.
The
client
version
is
1.11.5
and
you
also
see
a
message
saying
no
istio
parts
running
on
the
pod
right,
because
when
I
get
name
spaces
on
my
queue
cluster,
there
is
no
istio
system
name
space
there,
because
it's
not
created
it's
not
installed.
That's
the
reason
why
you
released
your
ctl
version
says
that
the
road
running
pods
are
available
right.
The
other
convenience
command
here
is
also
like
in
case.
A
Are
going
to
do
this?
Gives
you
only
that
thing?
It
will
not
query
the
cluster
okay,
why?
I
say
this
command
is
that
sometimes
you
might
be
encountering
some
issues
with
the
hto
ctl
and
you
want
to
report
the
bugs.
This
is
a
very
first
question
that
they'll
ask
you
is
what
is
your
ctl
version
you
use,
so
you
have
to
report
that
version.
A
If
you
don't
have
a
cluster,
it
will
take
a
long
time
for
you
to
get
this
response
back,
but
just
for
a
convenience
just
to
quickly
get
that
you
can
just
use
remote
equal
to
false
okay,
this
list
again,
obviously
like
any
other
cube
cattle
or
any
other
kind
of
cuddle
commands
like
this
also
has
dash
dash
help
to
it
so
which
we
can
use
to
get
the
help
password
done.
Okay,
awesome,
so
we
got
the
version.
We
know
what
you're
done.
A
So
what
you're
going
to
do
next
is
what,
if
you
remember
that
we
saw
about
the
control
plane
on
the
data
plane?
The
very
first
thing
that
we
need
to
get
is
a
control
plane
installed.
That's
what
we
are
going
to
do
in
the
section
called
istio
installing
istio
the
first
step
going
to
create
the
version
okay
system.
Sorry
namespace
is
your
system
namespace,
and
then
you
can
also
just
do
the
easter
cattle
service
right.
This
is
nothing
but
we're
going
to
create
a
service
kubernetes
service
another
day
to
access
the
htod.
A
That's
what
we've
done
with
this
and
finally,
we
can
use
istio
cartel
install,
is
your
system
and
then
the
control
plane
thing,
and
then
we
install
that
revision
enable
okay,
a
few
things
into
this
command
right.
Let
me
talk
about
few
things.
What
you
are
right
now
using
is
that
we're
using
an
istio
cuttle
tool
to
kind
of
install.
A
What
do
you
mean
by
division
right?
If
you
don't
specify
any
revision
thing
right?
This
could
be
any
any
version
tag.
Usually
what
we
avoid
is
that
we
don't
use
any
dot.
Instead,
we
use
dashes
okay,
since
it's
11.11.5,
we
kind
of
used
like
1-11-5
right.
You
can
use
any
given
name
a
logical
name
for
you
for
you
to
understand
what
this
version
belongs
to.
A
What
does
this
revision
do?
Okay?
That
is
something
which
is
not
explained
on
this,
but
I'll
share
this
and
maybe
like
need,
as
you
can
add,
a
few
more
things.
On
top
of
that,
the
thing
what
we
do
with
revision
is
that
it
allows
you
to
run
multiple
istio
control
planes
right,
for
example,
let's
say
I
want
I'm
trying
something
on
1.10.5,
okay
and
then
I
want
a
new
release,
still
division,
1.11.5
release.
I
want
to
move
to
that
release.
A
So
technically
what
you
do
you
do
a
update
to
this
right,
so
what
we
can
do
with
the
revision
is
that
we
can
do
an
update
without
affecting
the
existing
deployments,
so
this
becomes
very
crucial
when
you
are
doing
on
a
production,
because
I
don't
want
to
affect
the
existing
services
or
anything.
I
want
to
update
it
and
then
move
all
services
using
chandray
update
to
the
new
service
and
then
decommission
the
old
one.
So
you
want
to
do
the
similar
stuff
like
how
do
you
roll
out
a
new
updates,
your
application?
A
You
want
to
do
the
same
thing
for
your
istio
installation.
Also,
you
have
to
follow
the
vision,
and
this
is
a
recommended
thing
from
solo,
not
only
with
solar,
but
st
also
recommends
that
when
you
install
istio
plea
on
production,
please
do
use
revisions,
okay,
so
that
you
know
to
which
division
your
workloads
are
being
targeted
for
all
right.
A
So
that's
the
thing.
So
we
got
the
hto
installed
right
now
we
got
the
core
installed
with
core.
Is
nothing
but
your
crds
vcod?
Is
your
control
plane
that
got
installed
on
this
and
then
let's
go
and
check
the
pause?
There
will
be
one
pod
that
will
be
running
on
it.
Is
your
system
name
space?
That's
going
to
be
a
risk
to
your
d
and,
as
you
see
right
now,
if
you
don't
use
revision,
you
will
not
see
this.
If
you
see
this
one
here,
so
you
will
see
this
one.
A
If
you
see
one
deployment,
which
is
ecod
1-11-5
right,
so
this
is
again
the
istio
control
plane
that
is
targeted
for
the
revision
that
you're
deploying
so
obviously
tomorrow,
when
you
do
1.12
or
1.13
or
1.14,
and
you
use
a
revision
name,
that's
going
to
get
suffix
along
with
your
deployment.
It's
your
control,
plane
deployment,
so
two
control
planes
can
run
parallelly
in
the
same
cluster.
All
right.
B
Yeah,
a
commission
just
briefly
here,
right
to
like
a
commission,
was
saying
we
use
revisions
to
make
sure
you
can
have
different
versions
and
use
for
upgrades
the
first
command
he
did
to
create
the
studio
service.
Do
you
mind
showing
the
definition
of
that
it
might
help
people
just
like
cube?
Ctl,
get
service
study,
initial
system
name.
B
Yeah,
so
the
reason
we
created
s2d
service
is
because
that
gives
you
a
stable
service,
irrespective
of
which
version
you
have
installed,
so
that
service
is
the
one
which
is
used
in
steel
version,
111
for
web
hooks
and
few
other.
We
have
removed
that
limitation.
Then
your
version
service
to
you
actually.
So
in
newer
versions,
you
don't
have
to
create
that
service.
A
And
that's
what
you
see
here
right
as
neeraj
was
saying
that
if
you
see
the
selectors
on
these
service,
so
the
ecod
service,
you
just
use
the
htod
as
a
selector
and
if
you
see
the
easter
egg,
there's
one
more
service
that
your
revision
deployment
creates.
That
is
the
cod
11.5
1.5,
which
is
targeting
your
revision
right.
This
co,
dot,
io
dot
attribution!
A
That's
what
it's
targeting
so
that,
as
as
niraj
was
saying,
you
don't
need
to
worry
all
your
service
keeps
running
to
the
cod
without,
even
if
you
change
your
traffic
right
and
you
can
also
target
your
service
going
for
a
specific
revision.
So
this
is
more.
How
do
you
handle
the
revisions?
It's
very
helpful.
Initially,
it
sounds
confusing,
but
when
you
start
using
it,
you
get
used
to
that.
You
don't
want
to
do
a
default
revisionless
services.
Okay,
awesome!
So
we
got.
A
We
got
the
steer,
control
plane
deployed
and
then
we
can
also
get
few
of
the
discovery
endpoints
and
what
this
basically
does
if
you're
just
going
to
go.
Query,
the
registry
that
just
just
just
a
as
you
say,
a
fun
command
kind
of
thing
like
just
to
understand
what
all
the
debug
endpoints
that
we
have
on
the
thing
right.
It
goes
if
you
see
here,
it
also
goes
our
cluster
local,
ui
and
then
web
api
and
everything
that's
it
goes
and
goes
to
the
complete
cluster,
takes
everything
inside
the
cluster
and
shows
to
you
right.
A
A
Okay,
there
is
a
savior
which
you
have
to
put
here
is
because
this
is,
we
will
be
talking
about
this,
so
this
is
going
to
be
having
some
amount
of
performance
impact
if
your
customer
is
huge
and
one
of
the
labs,
what
you
are
going
to
do
as
part
of
this
particular
labs,
is
that
one
of
the
modules
that
you're
going
to
do
is
how
do
you
avoid
going
out
everything
right
that
as
niraj
was
explaining
on
the
workspaces
where
we
are
limiting
stuff
right?
So
so?
A
What
I
was
saying
is
that
so,
when
you,
when
you
kind
of
when
you
kind
of
go
to
a
huge
cluster,
you'll,
be
having
lots
and
lots
of
services
so
discovering
all
the
services
and
keeping
track
of
all
of
them
is
going
to
definitely
it's
going
to
have
a
performance
impact.
That's
one
of
the
reasons
why
we
brought
in
workspaces
and
and
tenancies,
and
all
these
things
about
you
can
go
limit
stuff
and
we'll
also
be
seeing
how
we
still
does
it
behind
the
scenes
right.
A
A
A
So
there
is
no
labels
on
any
of
these
things.
I'm
just
going
to
show
this
because
you'll
come
back
to
that
thing
again
and
then,
if
you
also
get
parts
on
the
default
name
space,
it's
all
having
one
of
one.
There
is
no
sidecar
injected,
and
even
if
you
go
to
eco
in
action,
they
always
have
this
funny
way
of
swapping
their
tni
in
action.
A
So
none
of
these
parts
on
all
these
name
spaces
has
sidecar
injected
into
them.
So
how
do
we
do
that?
There
are
multiple
I
think
there
are.
I
should
certainly
multiply
two
ways
to
do
it.
One
is
automatic
sidecar
injection,
which
is
the
recommended
way
where
you
can
do
automatic,
sidecar
injection,
but
there
is
also
the
ctl
also
gives
you
a
command
called
a
cube,
inject.
Okay,
ctl.
I
think
it's
cube
inject.
I
guess
let
me
put
the
help
I
want
to
know
what's.
A
So
this
is
going
to
give
you
a
json,
basically
generating
your
sidecar
implementation
that
gets
injected
into
your
deployments.
Okay,
so
why
we
have
these
two
ways
right.
The
answer
is
simple
right.
When
you
want
everything
to
be
controlled
within
automatically
by
steer,
then
the
recommended
way
is
to
use
automatic,
sidecar
injection
so
that
the
mutation
happens
and
everything
gets
injected
in
some
cases.
A
B
C
B
A
Yeah,
I
think,
yeah,
I
think
you
can
just
put
the
insta.
I
mean
put
the
lab
in
section
start
again
and
you
have
to
start
it
from
from
this
from
the
scratch.
I
think
I
don't
think
so,
there's
a
way
we
can
go
back
as
of
as
of
today.
Maybe
that's
a
good
feedback,
probably
I'll.
Take
you
to
the
team
to
see
if
we
can
go
back
to
the
instruction
all
right
so.
C
A
Where
we
thought
so,
we
have
two
ways
to
do:
sidecar
injection
one
is
automatic
and
one
is
manual,
so
most
of
these
labs
will
be
following
the
automatic
sidecar
injection,
but
you
can
go
explore
this
cube
inject
command,
there's
more
documentation
available
in
the
sql
site.
It's
your
documentation
to
see
what
it
all
talks
about
right.
So,
let's
go
and
do
that.
So
what
I'm
going
to
do?
The
very
first
thing
I'll
explain
these
commands
in
a
second.
A
So
what
you're
right
now
doing
is
that
we
are
labeling
the
link
space
to
be
easter,
dot,
io,
slash,
rev
1-11-5.
I
think
this
is.
This
is
one
of
the
important
labels
that
istio
looks
for
to
go
and
do
the
injection
right
by
default.
It
uses
what
is
called
an
istio
injection
enable
that's
a
default
one
right,
but
in
our
case
we
are
going
a
revision
based
deployment.
That's
a
recommended
way
for
production,
so
there
we
are
going
and
saying
that
easter
dot,
io
slash
revision
label
should
be
available
on
the
namespaces.
A
Okay,
if
you
remember
the
command
that
we
executed
some
time
back,
let
me
go
ahead
and
see
that
here
show
labels.
Now
you
should
see
the
one
label
here,
that's
getting
added
to
the
default
namespace
revision
1-11-5,
so
that
make
sure
that
the
pods
on
this
namespace-
I
don't
think
so
they
are
not
it
now
on
this
namespace
have
been
h2o
bin
has
been
deployed
and
it
is
running
with
a
steer
side
car.
A
If
you
remember
earlier,
none
of
these
spots,
other
parts
are
not
got
injected
because
they
are
deployed
even
before
we
label
the
name
space.
They
are
still
having
one
of
one,
but
the
istio
bin
is
having
two
of
two,
which
means
that
the
sidecar
is
already
injected
into
the
http
bin
pod.
Okay,
that's
what
this
label
does.
C
B
A
A
Okay,
I
have
to
score
a
bit.
Ups.
Excuse
me
on
both
of
those
long.
I
think
you
see
the
the
proxy
v2
bar
that
got
injected
into
the
existing.
This
is
called
an
easter
proxy,
that's
your
sidecar,
and
then
there
should
be
your
service
pod
right.
Let
me
go
up.
There's
an
http
bin
port.
Okay,
this
is
the
http
bin
part.
There's
two
containers,
one
is
your
http
bin
container
and
another
one
is
your:
is
your
proxy
container
it
got
injected?
B
A
I
just
going
to
get
it
from
all
names
spaces.
You
should
see
an
sd
inject
sidecar,
we're
booking
this
uses
this
hasselblad,
that
it
can
go
mutate.
The
pod
right
by
default,
the
pods
are
not
muted,
are
immutable
in
kubernetes
right
so,
but
the
mutating
web
book
allows
you
to
do
a
muting
by
which
you
inject
an
extra
yaml.
The
yamaha
is
nothing
but
your
template
right.
I
think,
if
you
go
see
the
template
of
this
particular
mutating
web
book,
I'm
not
sure
we
get
the
template
here
right.
B
This
tells
you
the
web
hook
configuration
which
says
when
the
pod
comes
up,
what
webhook
you
should
call,
and
if
you
see
the
webhook
here,
the
webhook
service
will
be
istiod
right.
If
you
see
it's
studi
11155
is
your
system.
So
then,
when
you
go
to
that
service,
which
is
the
studio
service,
it
automatically
injects
the
template
that
kamesh
was
talking
about
and
that
template
is
in
istio
system
name
space.
So
if
you
get
the
config
map
sdo,
so
there's
a
config
map
called
sidecar
injector
and
it's
your
system
namespace.
A
That
image,
if
you
want
to
sure
yeah
and
before
I
show
that,
like
I
just
want
to
show
you,
you
will
be
wondering
like
we
injected
the
namespace
here.
If
you
remember
the
label,
the
namespace
default
is
to
io
revision
thing,
and
if
you
remember
this,
this
web
book
gets
applied
only
if
this
object
selector
matches
right.
That's
the
reason
why
we
label
the
namespace,
because
it
says
that
the
injection
happens
only
when
there
is
a
key
called
as
history
or
io
slash
revision
with
the
value.
A
What
whatever
revision
is
said
right
that
could
be
multiple
divisions.
Obviously
they
get
updated
whenever
you
do
multiple
revisions,
but
this
is
what
it
does
okay.
So
this
is
what
it
goes
and
finds
out.
That's
precise
reason
why
we
label
the
namespace
to
have
1-11-5
so
that
it
goes
and
injects
that,
and
if
you
see
what
is
getting
injected
as
nerj
was
saying,
get
cm,
iphone
n
is
your
system.
Let
me
find
out
the
name
of
the
the
sidecar
injector
yeah.
This
is
the
one
right.
A
B
It's
a
go
template
right.
So
what
we
do
is
we
read
in
this
template
and
we
do
a
substitution
based
on
your
configuration
that
you
have
given
in
sto
when
you,
when
you
installed
stu,
you
created
a
config
map
called
stu.
That
has
some
values
that
gets
overlaid
and
we
create
an
actual
pod
template
out
of
this,
and
one
of
the
questions
was
on
the
chat.
You
know:
how
do
we
inject
like
commercial?
There
are
three
things
that
have
to
happen.
B
A
Yeah,
and
also
like,
if
you
don't
use
revisions,
there
is
an
easter
dot,
io
injection
equal
to
enable
flag.
I
think,
if
you
can
check
on
the
documentation
on
the
easter
side,
there
is
a
default
flag
which
you'll
check
for
so.
If
these
labels
are
there
on
the
namespace,
it
could
be
done.
Okay,
I
think
we
can
also.
A
A
Okay,
all
right,
so
I
think
that
gives
you
flexibility
of
service
mixing
service
mesh
with
the
method
service,
mesh
kind
of
architecture,
so
that
is,
if
I,
if
I
recollect
correctly
one
of
the
customers
I
was
speaking
with
like
he
was
having
lots
of
monolithic
applications
and
he
was
having
some
kind
of
micro
services
you
want
to
make
them
monolithic
not
to
be
injected.
It
wants
to
be
accessed
because
he
was
afraid
of
breaking
something
because
he
was
not
very
sure.
A
So
we
have
to
take
that
approach
of
adding
those
labels
to
the
respective
deployment
yammers
right
so
that
only
those
things
get
done,
yeah
all
right.
So
that's
that's
pretty
much.
What
we
did
on
this
lab
install
istio
went
through.
How
do
we
make
the
deployment
side,
car
injected,
use
the
steer,
ctl
tool?
A
I'm
sorry
so
what
it
was.
What
it
was
saying
is
that
in
blue
mesh
right
we
also
have
an
ability
to
kind
of
go:
do
an
auto
restart
right
of
the
parts
when
something
gets
changed.
So
that's
also
another
advantage
that
you
get
when
you
use
glue
mesh
with
esteo.
We
take
care
of
doing
those
rollout
restarts
whenever
some
configuration
changes
or
name
space
or
labels
changes.
That's
also
an
advantage
when
you're
maintaining
your
large
clusters
with
large
lists
of
each
year
deployments
yeah.
So.
A
B
I
was
just
saying
that
in
glue
mesh,
we
have
our
api
called
powered,
debounce
director
that
helps
you
do
this,
but
I
have
seen
in
production.
Every
customer
is
different
right.
Some
of
the
customers
want
more
control
over
and
their
applications
are
a
little
bit
more
complicated,
so
they
want
to
do
it
themselves.
They
want
to
test
traffic
in
want
a
easier
way
of
rolling
over
everything.
So
you
get
the
flexibility
you
can
do.
However,
you
want.
A
A
Just
I'm
just
saying
that
that's
the
that's
the
way
it's
meant
to
be
right,
because
that's
how
we
know
how
things
are
working,
so
so,
let's
what
we'll
be
seeing
on
this
lab
is
basically
like.
We
talked
about.
We
talked
about
the
first
part
right
we
are
bringing
in
the
service
mesh.
We
got
the
application
workloads
deployed,
we
got
the
sidecar
injected,
but
we
come
to
a
very
crucial
point
of
one
of
the
things
why
we
need
to
use
service
mesh
right.
That's
that's
thing
like
in
a
distributed,
complex
complexity
of
applications
distributed.
A
Sorry,
I'm
sorry
distributed
architecture.
The
complexity
makes
you
hard
to
observe
something
where
something
is
failed
right.
It's
not
about.
We
are
not
worried
about
if
something
fails
right,
but
at
least
if
you
know
why
it
is
fail
and
you
are
able
to
recover
it
that
helps
us
to
get
back
to
track
right.
So
that's
what
we
are
going
to
do
as
part
of
this
lab.
A
We
are
going
to
see
the
multiple
components
that
we
can
integrate
with
istio
so
that
we
can
generate
the
metrics
generate
the
graphs
generate
other
things
that
is
required
by
the
operation
side
of
things
to
make
sure
where
is
which
has
gone
wrong
where
and
both
fix
them
up
all
right.
So
so
there
are
a
few
things
that
we
are
going
to
do.
I
think
I'm
leaving
the
the
text
for
you
to
read
so
we're
just
going
to
deploy
prometheus
as
everybody.
A
You
know,
prometheus
is
kind
of
at
the
standard
to
attract
scrape
metrics
from
from
any
of
the
kubernetes
deployments.
That's
the
same
thing
which
which
onwise
also
I
mean
stu,
is
also
going
to
use
eventually
onboard,
so
we'll
wait
for
the
the
pods
to
be
deployed
and
let's
go
install
the
prometheus
community
version
of
this
and
we'll
wait
for
the
deployment
to
happen.
A
Okay,
so
we'll
use
prometheus,
then
link
prometheus
with
grafana
and
then
see
all
those
metrics
of
grafana
on
our
graphana
dashboard
then
bring
those
things
into
our
kiali,
which
is
a
service
mesh
observability
for
istio.
We
can
go
watch
all
those
things
with
istio
and
we'll
see
a
few
things
like
your
security,
mtls
certificates
and
all
these
things.
So
these
are
the
things
that
we
are
going
to
do
as
part
of
this
particular
lab.
A
All
right,
don't
worry,
as
I
said
earlier,
so
this
lab
is
going
to
live
there
until
10
pm
india
time
tonight,
so
that
you
can
go.
Try
it
back
again.
If
you
have
to
start
the
track.
Just
put
the
url,
which
I
gave
you
just
hit
it
again
and
then
start
the
track
again
so
that
you
can
start
from
the
start
as
well
right
or
if
you're
saved
you're
saved
all
right.
A
You
can
just
give
your
queries
and
all
these
things
we
are
not
bothered
about
this
for
now
again,
I'm
not
a
prometheus
super
expert,
so
I
don't
know
even
prom
cure,
so
I'm
going
to
skip
this
for
now.
If
you
are
a
prometheus
expert,
then
put
some
queries
to
see
the
stuff,
but
what
we
are
going
to
do
more
is
we're
going
to
go.
Take
this
one
and
get
it
into
grifana
dashboard
all
right.
So
let's
go
kill
this
one
and
then
we'll
put
forward
prometheus
grafana.
A
A
Prom
operator,
so
prometheus
operator
is
what
the
thing
and
then
sadly
like
you'll
not
have
any
dashboards.
If,
even
if
I
go
to
home,
I
will
I'll
see
some
dashboards
the
standard
prometheus
dashboard,
but
it's
nothing
related
to
easter
because
we
are
not
enabled
any
istio
dashboards.
As
of
now
all
right.
A
That's
what
we
you're
going
to
do
next,
so
you're
just
going
to
go
ahead
and
then
add
the
dashboards
right,
as
I
said,
are
the
command
I'm
going
to
kill
this
one
I'll
do
a
forward
again,
so
we're
going
to
create
the
dashboard
just
your
dashboards
out
of
the
box.
We
have
not
installed
anything,
and
this
is
again
a
recommended
way
for
production
is
that
you
go
install
the
dashboards
later,
because
some
in
some
use
cases
you
might
need
to
customize
do
something
before
deploy
right.
A
A
Okay,
once
we
do
this,
we
also
need
to
do
another
important
thing
after
labeling
the
dashboards.
We
need
to
say
that
these
dashboards
has
to
be
picked
up
by
istio
right
by
our
grafana.
So
we
are
going
to
say
that
this
graph,
when
we
said
this
one
what's
basically
going
to
do-
is
like
all
these
config
maps
that
has
dashboards
grafana,
dashboard
definitions
right,
so
those
going
to
be
picked
up
and
shown
in
our
grafana
ui.
A
Okay,
let's
go
back
to
the
same
old
thing,
go
back
to
terminal
2
and
then
start
the
grafana
dashboard
again
and
once
you
go
to
the
grafana
ui
now
you
should
see
a
bunch
of
dashboards
right
now,
right,
let's
go
to
home,
and
then
you
should
see
some
more
dashboards
here.
Coming
up,
one
of
the
dashboards
will
be
your
istio
dashboards.
Okay,
let's
go
to
home.
A
And
then
you
can
also
see
you
can
also
favorite
eye.
Do
whatever
he
wants
to
right
and
then
one
of
the
things
what
you're
going
to
see
is
the
control
plane,
dashboard
right,
let's
go
to
the
control
plane,
dashboard
to
see
what
control
planes
and
other
things
that
we
deployed.
Sadly,
the
memory,
the
cpu
usage
of
all
these
things
with
the
control
place
right
for
now,
you'll
not
see
anything,
because
there
is
no
data
that
is
getting
pushed
here.
A
And
then
let's
go
down
and
then
that's
what
we're
going
to
do
with
the
scraping
section,
so
you're
going
to
scrape
the
data.
If
you
see
this
we're
going
to
apply
this
prometheus
this
thing
here
to
scrape
the
data
from
the
easter
name,
space
and
or
any
istio
parts
right,
which
is
having
app
label
access
to
your
pods
and
then
we're
going
to
apply
this
one
right.
So
even
after
applying
it,
it
might
take
some
time
for
us
to
get
that
thing.
So
we'll
have
to
wait
for
that.
A
So
this
is
the
first
thing
right
now.
What
you
have
done
is
that
we
have
enabled
scraping
of
metrics
from
the
istio
control
plane,
components
all
right.
So
that's
what
we
are
done
right
now.
So
let's
give
few
minutes
for
the
data
to
actually
flow
in.
Even
if
I
refresh,
I
will
not
be
getting
some
data,
so,
let's
go
while
that
happens,
we'll
also
go
and
enable
the
scraping
of
data
from
the
data
plane.
We
need
to
say,
like
your
http
bin
web
api
and
all
these
spots
right.
A
You
also
want
to
scrape
the
data
from
them
and
push
it
into
the
prometheus
so
that
we
can
show
that
in
the
grifana
dashboard.
That's
the
next,
which
you're
going
to
do
that's
using
the
prod,
monitor
we're
going
to
get
the
on
voice
stats.
What
we
call
as
and
then
we
have
something
defined
here-
how
to
scrape
the
data.
If
you
remember
that
the
envoy
has
the
stats
endpoint
right,
the
same
endpoint
can
also
give
you
the
prometheus
statistics.
A
A
So,
let's
give
some
more
time.
Let
me
go
here
the
dashboards
and
then
let
me
go
scroll
down.
There
should
be
a
another
dashboard.
Obviously
this
is
going
to
be
your
workload
dashboard
if
you're
not
wrong
right,
let's
go
back
and
service
dashboard.
Okay,
let's
go
to
go
to
the
service.
Dashboard,
obviously
not
have
anything
on
the
service
workloads.
The
data
is
still
not
skating
inside
okay.
A
So
what
you'll
do
is
like
you'll
just
go
and
send
some
data:
okay,
because
there's
no
load
here
so
obviously
you'll
not
get
anything
right
now,
I'm
just
kind
of
sending
the
request
to
that,
so
that
we
send
some
load
to
the
thing
so
that
we
can
start
getting
the
the
the
statistics
right,
the
metrics
end
of
the
day.
Sorry,
not
statistics.
G
D
A
A
Okay,
you
should
start
to
see
the
data
here,
the
virtual
memory,
how
much
memory
it
has
how
much
go
rotis
it's
running,
how
much
gpu
it's
using!
How
much
memory
is
using.
We
start
to
see
all
these
things
for
this.
The
username
password
is
right
there
on
the
instruction.
It
is
admin
and
prom
dash
operator.
A
A
C
A
It's
loading
some
service
and
then,
let's
click
on
the
service
workloads
here
and
obviously
saw
the
service
coming
here,
but
still
we
not
bought
some
request
yet
to
come
here.
Okay,
so
nothing
has
failed
as
of
now.
So
if
you
come
back
to
that
a
bit
after
some
time,
you
should
see
this
thing
right.
This
is
right
thing.
There
is
very
minimal
operations
that
we
have
done
right
now.
Okay,
that's
great!
So
in
these
things,
and
then
we
saw
these
xds
dashboards.
A
I
think
it
will
give
us
some
time
for
that,
those
things
to
get
populated
so
that,
because
once
you
have
this,
the
next
one,
what
you're
going
to
do
is
that
installing
right,
let
me
take
a
step
on
time.
It's
it's
kind
of
12.
We
just
got
one
90
minutes
more,
so
we
are
good
on
the
time.
So,
let's
go
back,
and
I
will
stop
this
one
here
and
let's
go
and
create
the
kiali
thing,
you'll
see
about
kiali
in
a
second,
it's
going
to
install
the
kiyali
operator
for
that.
C
A
A
Do
I
get
a
correlation
from
service
theater
service
c?
So
if
I
understand
okay,
if
you
understand
your
question,
sarah,
I
don't
understand
what
you
mean
by
correlation
from
service
a
to
service
with
respect
to
the
metrics
right,
if
you're
asking
about
tracing,
then
this
is
not
what
you
see
right
now,
it's
only
the
metrics.
It
just
gives
you
cpu
and
memory
of
the
respective
services.
It
will
not
give
you
the
cpu
memory
of
between
those
services.
Okay,
probably
it
can
give
you
the
failure,
codes,
http
response
codes.
A
If
you
see
the
service
dashboards,
that
is
something
which
can
give
you
the
failure
course
number
of
services
fail.
Number
of
other
things
fail.
Okay
for
the
thing
if
which
you
want
to
see
like
how
it
correlates
then
tracing
is
what
you
need
to
use
there,
so
that
you
can
find
out
from
service
here
to
service
v
is
faster
service
c
to
service
a
is
slower.
You
can
see
all
this
metrics
inside
the
tracing.
A
A
A
A
Okay,
maybe
like,
if
you
see
the
similar
error,
like
what
you
saw
on
my
screen,
just
stop
and
restart
the
port
forward,
so
that
you
get
this
key
ui
like
what
I
see
on
my
screen
right.
So
so
you
have
to
create
a
token
basically
and
then
copy
the
token
and
use
it
in
the
token
place
where
you,
where
you
have
to
paste
the
token
right
and
there's
also
a
step
below
in
case.
If
you
have
problems
with
the
token
until
now,
I
did
not
have
any
problems.
A
You
can
also
disable
the
kiali
and
wait
for
the
ports
to
restart
and
then
log
in
without
the
token.
So
I'm
not
seeing
that
you
don't
need
to
do
this
step
if
you're
able
to
log
in
okay,
just
you
can
just
skip
this
step
right
there.
Okay!
Now,
if
you
go
to
the
kiali
ui
and
then,
if
I
filter
by,
if
you
go
here,
I
have
to
go
to
the
graph.
A
A
E
A
A
A
If
I
go
to
traffic
animation,
it
will
go
and
shows
the
traffic
animation
for
this,
how
the
traffic
goes
right
now,
but
this
is
only
one
service
and
one
b1
here,
so
your
traffic
just
goes
like
that.
Okay,
and
if
you
also
will
see
more
about
this,
but
just
just
one
thing
which
you
can
observe
how
much
structure
is
great
for
this
service
this
year?
A
A
A
We
configured
prometheus,
to
scrape
the
data
from
the
control
plane
from
the
data
plane
and
then
we
kind
of
did
install
kiali.
We
can
kind
of
did
the
kiali
to
kind
of
get
the
data
logged
into
kle
and
then
send
some
sample
requests
so
that
we
saw
the
graph
of
the
services
flowing.
So
this
is
the
process
of
getting
observability
enabled
on
your
eco
cluster.
There
is
more
things
to
do.
We
can
send
this
data
to
an
external
service
like
you
are
your
data,
dogs
and
other
things.
A
A
Exactly
okay:
let's
click
check
to
make
sure
that
we
have
done
everything
correct
on
this
labs
and
then
we'll
move
to
the
next
one
right.
Even
if
you
want
to
kill
the
for
forwarding,
you
can
kill
that
or
you
can
keep
it
running.
That's
your
choice!
Obviously,
it
gets
killed
when
you
move
to
the
next
challenge.
A
Let's
start
the
next
lab,
so
this
lab
is
going
to
get
a
little
bit
interesting
right
so
far
we
have
done
all
the
calls
to
the
service
basically
doing
exec
into
one
particular
sleep
board
and
then
to
curl
to
the
services
and
all
these
things
right
in
this
chapter.
What
you're
going
to
do
is
is
about
english
gateway
right.
A
What
is
an
ingress
gateway,
so
english
gateway
is
basically
the
the
way
by
which
we
allow
the
traffic
to
come
inside
your
network
right,
that's
what
we
call
as
ingress
that
something
flowing
inside
an
egress
is
opposite
of
that
which
flows
outside
your
cluster
right.
So
so
far,
if
you
see
a
standard
kubernetes
deployment,
there
is
no
way
there
is
no
standard
way.
I
should
say
the
column
is
generically
ingress,
but
there
is.
A
There
are
multiple
ingresses
that
various
distros
or
ecos
cube
ecosystem
of
products
gives
you
right
for
the
traffic
to
flow
in
the
once.
The
service
is
created
and
I
want
to
expose
it
to
the
public.
Then
I
have
to
follow
one
kind
of
a
mechanism
of
adding
an
ingress
for
the
traffic
to
flowing.
There's
a
lot
of
ingress
products
available
in
the
market
like
contour
and
then
and
then
nginx
and
then
istio
is
one,
and
then
there
are
a
few
other
things.
A
Also,
if
you
say
glue
edge
is
one
of
our
flagship
products,
which
also
gives
you
an
api
gateway
for
the
traffic
to
flow
inside
your
cluster.
It's
like
an
api
gateway,
which
is
also
called
that.
I
can
also
call
this
an
english
gateway
right,
the
traffic
to
enter
intel
system.
So
that's
what
is
ingress
gateway
at
some
gateway
for
a
traffic
to
a
from
outside,
enter
inside
the
cluster.
So
so
far
as
you
saw,
we
just
did
all
calls
right.
If
you
have
seen
those
commands
that
we
are
executing
until
this
lab
everything.
A
It
could
be
from
inside
also,
but
is
what
you're
going
to
see
with
ingress
is
going
to
come
from
outside.
Okay,
for
that
we'll
be
doing
insta
installing
h2
english
gateway.
So
far,
you
have
not
done
that.
We're
going
to
do
that
now
and
then
what
we'll
do
is
once
we
have
the
sq
english
gateway
installed.
We
also
expose
our
apps
right.
That's
the
next
step
which
you'll
be
doing
will
be
kind
of
enabling
our
apps
to
use
this
gateway
so
that
the
traffic
from
outside
can
be
routed
to
our
applications.
A
A
If
you
want
to
do
that
and
then
you
can
just
go,
do
that
with
the
pkica
of
your
own
choice
as
well
right,
but
that
is
a
recommended
way,
we'll
see,
what's
the
recommended
wave,
what
we
recommend
for
you
to
do
when
it
deploys
you
into
production
how
to
handle
those
certificates,
that's
something
which
you
will
be
seeing
as
part
of
other
installation
right.
How
do
you
set
up
all
these
things?
I
think
that
that
is
pretty
much
okay
and
another
important
stuff
right.
A
I
think
this
is
where
things
get
even
more
interesting
in
reducing
the
gateway
conflict
right
also,
when
I
enable
conflict,
as
you
saw
in
the
very
first
lab,
all
the
service
gets
exposed
all
right,
so
we
want
to
reduce
the
traffic
scope.
I
call
this
a
scope
in
this
case,
so
that,
like
it,
it
sees
only
the
things
which
it
needs
to
see
right.
A
So
that
the
pressure
on
the
istio
control
plane
and
the
sq
respectively,
your
data
plane
is
lesser
so
that
your
performance
improves
we'll
see
about
that
as
well
as
the
last
part
of
this
lab
and
access
logging
we'll
also
see
about
how
do
we
do
access
logging
see
the
logs
when
you
get
when
something
gets
inside
your
stuff?
Okay,
so
these
are
the
main
things
that
we
are
going
to
see
as
part
of
this
lab.
Okay,
so
let's
get
started,
I'm
going
to
go
up
and
then
start
with
the
gateway
creation.
A
Okay,
so
I'm
just
going
to
create
I'm
going
to
deploy
a
j2
in
a
different
name
space
and,
as
you
observe
right
so
usually
in
production.
If
you
see
the
standard
deployments
of
steer
your
gateway
and
your
std
the
size
in
the
same
name
space,
but
for
production,
we
recommend
that
we
separate
them
into
two
different
namespace
for
maintainability
and
as
well.
If
you
see
this
one,
I'm
targeting
this
particular
gateway
to
the
revision
that
I
have
deployed,
so
we
can
also
control
in
that
way.
A
That's
the
way
how
we
do
the
istio
gantry
upgrades
with
moving
to
the
new
hdr
versions
by
doing
this
kind
of
a
revision
based
update,
that's
the
reason
why
we
pinned
the
control
plane
also
to
a
particular
version.
We
are
pinning
the
gateway
also
to
a
particular
version.
Okay,
so
that
your
traffic,
you
can
do
a
country
upgrades
on
your
on
your
existing
clusters,
all
right.
Let's
get
this
part.
A
A
Iphone
is
your
ingress,
so,
while
I
do
this,
I
just
putting
a
question
across
to
everyone
saying
like:
is
there
any
guesses
to
see
what
this
particular
part
could
be
from
whatever
labs
you
have
done?
Whatever
things
we
discuss
right
now,
there
are
clues
on
this
right.
There's
an
ingress
gateway
that
something
should
be
there
absolutely
right.
I
think
this
is
on
my
proxy
thing
so
which
is
going
to
be
getting
injected
in
a
data
plane,
but
this
is
outside
the
data
plane
right.
This
is
for
the
conflict
cluster.
A
B
B
F
A
Yeah,
so
if
you
see
this
image,
it's
still
your
site
card
image,
that's
what
you
see
on
your
on
your
english
gateway,
yaml
deployment
and
as
niraj
was
saying,
we
are
doing
on
a
router
mode,
which
is
standard,
router
mode
enrollment
variable
has
been
set
and
then
there
is
a
bunch
of
other
things.
We
will
not
worry
about
that
for
now,
but
just
imagine
that,
as
needed
was
saying,
is,
is
again
an
istio
sidecar,
it's
again
a
data
plane
without
application
workload
on
it.
That's
it
to
keep
it
pretty
simple.
A
That
was
a
that
was
a
great
explanation,
thanks
nirish
and
and
that's
what
we
do
right
now.
We
got
this
one
and
then
we've
got
the
pods
running
for
now
and
then
let's
go
and
get
the
service.
So
this
is
what
is
going
to
help
you
to
go
outside
the
cluster
right.
We
see
the
service,
the
service
has
a
load
balancer
and
an
external
ip
attached
to
it.
So
that's
how
we're
going
to
make
this
all
the
traffic
flow
through
it
into
this
right,
but
still
the
traffic
is
not
flowing
through
it.
A
We
can't
still
access
our
service,
we're
going
to
do
that
as
part
of
the
next
steps.
Okay,
so
for
the
convenience
I'm
going
to
grab
this
external
ip.
If
you
see
this
cube,
cuttle
command
is
nothing
but
to
grab
this
particular
external
ip
into
this
gateway
ip,
so
that
I
can
use
this
variable
in
my
commands
down
below
okay,
so
to
expose
our
apps
what
we
need
to
do
right.
There
are
two
things
which
we
need
to
do
for
the
exposure
apps
right.
The
very
first
thing.
A
A
So
how
do
we
connect
the
gateway
with
the
service
rights?
That's
what
we're
going
to
do
as
part
of
the
virtual
service
right.
So
let
me
get
the
same
thing
here,
sorry
about
the
the
format
that
you're
seeing
here,
but
I
want
to
explain
this
stuff
for
better
understanding.
Web
api
gateway
virtual
service.
A
We
are
saying
that
this
virtual
service,
which
gateway
it
has
to
use
right,
so
the
gateway
has
to
know
the
traffic
gets
transported.
That's
what
we're
going
to
use
a
web
api
gateway.
So
that's
the
link
that
we
are
creating
between
a
virtual
service
and
this
right
and
now
it
has
to
route.
Obviously,
the
next
step
says
that
it's
an
http
route
to
a
destination
web
api,
istio
inaction,
sbc.cluster.local
you
can
give
it
any
service.
We
are
just
going
to
give
it
here
and
port
8080.
A
Now
you
see
the
relation
that
the
gateway
and
the
virtual
service
is
using
the
gateway
to
send
this
traffic.
So
now,
whatever
traffic
that
comes
into
this
particular
gateway,
but
this
host
name
is
going
to
be
redirected
to
the
web.
Api
is
your
service
in
action.
So
that's
the
that's
how
the
link
happens
between
your
gateway
and
the
virtual
service,
all
right,
so
let's
go
and
create
that.
B
Do
you
mind
if
I
just
say
something
quick
here
we
created
two
separate
apis,
because
these
are
two
separate
concerns.
Gateway
is
involved
with
layer,
3
and
layer
4
configuration,
so
you
can
say
for
my
gateway
workload,
which
port
I
want
to
expose.
What
certificates
I
want
to
use.
Whether
do
I
want
to
use
sni
and
then
virtual
service,
like
commission,
was
sitting.
I
was
telling
is
more
about
how
do
I
route
these
domains
or
hosts,
and
where
do
they
go
right?
B
So
you
can
say
a
network
admin
or
a
security
person
is
responsible
for
gateway,
but
some
application
team
can
also
or
an
application
or
can
be
responsible
for
virtual
servers.
If
you're
used
to
you
know
the
traditional
adc
load,
balancer,
like
gateway
maps
to
the
whips
and
then
virtual
service
will
match
to
like
virtual
server
configuration
big-ip,
for
example,.
A
Let's
add
anything
that
I
need
to
on
top
of
this,
so,
in
my
opinion,
istio
ingress
gateway
is
more
for
control.
Your
resource
traffic
within
a
service
mesh,
whereas
like
the
api
gateway,
is
more
to
control
your
not
so
traffic
right
which
comes
inside
your
thing
right.
So
that's
the
that's.
The
easiest
way
to
remember
a
difference
between
api
gateway
and
other
stuff.
B
And
no
right
so
you
can
use
ingress
gateway
as
an
api
gateway,
but
the
number
of
features
you
need
an
api
gateway
is
not
all
there
is
to
ingress
right.
So
that's
why,
like
in
solo,
we
have
blue
edge,
which
is
a
fully
featured
api
gateway,
so
it
provides
you
api,
versioning,
creating
developer
portals
having
web
application
firewall
data
loss
prevention,
so
those
things
don't
exist
in
stu
ingress,
but.
A
Awesome
and
then
I'm
going
to
apply
these
ones
right
here,
so
I
just
got
the
gateway
done,
as
you
were
explained
right
now,
I'm
just
going
to
give
a
call
to
the
service
right
now
so
right
now,
I'm
not
doing
any
curl
inside
any
for
the
sleep
pods
or
anything,
I'm
just
calling
it
from
outside,
since
we
have
tied
our
gateway.
If
you
remember
to
a
particular
host
address,
I
have
to
pass
this
whole
translation.
A
If
you
have
a
dns
which
is
solve
this,
then
no
issues,
but
in
our
case
we
don't
have
all
those
things
I'm
just
going
to
pass
the
host
editor
and
that
we
get
the
request
here
right
and
that's
the
first
thing
you
are.
How
do
you
call
your
service
from
outside
to
inside
right?
So
there
are
also
a
way
by
which
we
can
check.
What
is
my
proxy
config
looks
like
on
my
proxycon
view,
looks
like
for
this
particular
deployment
right
so
now
for
the
istio
ingress
gateway
deployment.
A
Since
we
have
created
a
gateway,
it
says
that
anything
that
comes
into
http
8080,
there's
a
name.
That's
given
to
it.
It
has
a
domain
eq
in
o
matching
any
path.
We
can
also
give
path
controls
also
to
it
it's
going
to
go
to
this
virtual
service.
That's
what
you're
thinking
the
other
things
get
added
automatically
to
you,
okay,
so
this
is
what
it
does.
When
you
say,
okay,
I'm
going
to
come
into
the
proxy
configuration
and
see
which
one
you
want
to
do
right.
A
A
Obviously,
you
can
ask
her
to
ask
us
the
questions
you
can
come
down
to
our
I
mean
public
slack.
I
will
put
the
link
on
the
on
the
chat
later,
where
you
can
come
and
ask
questions
about
these
things
as
well.
Right
and
also
it
gives
you
the
routes,
and
this
is
where
the
thing
is
going
to
get
a
little
bit
thing
right.
It
gives
you
an
online
configuration
end
of
the
day.
A
The
route
on
very
specific
on
my
computer,
the
complete
one,
just
says,
which
is
a
cluster:
what
are
the
domains
it
handles?
What
is
the
url
that
it
gets
into?
It's
just
a
name.
If
you
remember
the
same
name
here
is
what
is
given
here
and
then
it's
retry.
All
these
things
are
added
automatically.
The
number
of
retries
is
two:
it
gives
you
four
other
things
right.
The
status
code
is
blah
blah
blah
and
then
it
goes
down
and
to
say
that
which
service
it
has
to
go
and
hit
it.
A
A
Okay,
that's
what
I'm
going
to
do,
I'm
going
to
go
and
apply
this
and
that's
going
to
create
you
the
https
and
then,
if
I
use
the
curl
to
go
on
call
using
the
same
gateway
ip,
but
I'm
going
to
use
the
443
port
all
right.
So
that's
what
you
get
the
same
get
the
same
response,
but
now
you
are
going
over
https,
so
enabling
https
is
as
simple
as
this
with
this
cure.
A
Right
just
go
and
create
a
certificate
and
then
add
to
it,
but
when
you
get
into
production,
this
is
not
be
the
case
right
because
you
might
not
be
having
access
to
the
particular
namespace
or
you
cannot
create
the
certificates
you're
not
allowed
to
do
it.
You
will
not
be
having
permissions,
etc,
etc.
So
what
is
the
recommended
way
to
do
that
in
production?
Is
what
we're
going
to
see
next
all
right,
so
let's
go
and
delete
the
old
certificate.
Okay,
we're
not
going
to
have
the
certificate
here.
A
A
A
Now
you
see
the
documentation
for
all
these
things
right
here,
this
one
okay,
so
you
can
just
go
see
this
github
project
on
all
these
things.
Here,
that's
an
open
source,
one!
Let
me
just
go,
read
it
at
leisure,
but
it's
a
very
interesting
project.
It
helps
a
lot
in
my
I
think
at
least
so.
What
we're
going
to
do
is
look
we're
going
to
deploy
the
search
manager
onto
our
cluster.
A
A
Wait
for
the
search
managers
to
be
up
and
running
for
us
so
that
we'll
create
the
certificate
issuer.
So
the
one
one
gotcha
in
this
case
is
that
please
don't
so
here.
We
use
a
self-signed
certificate
to
demonstrate
this
stuff.
But
technically
in
your
environments,
we
don't
recommend
you
to
create
those
cluster
issuers
like
this.
Please
use
a
proper
pk
like
let's
encrypt
or
google
certificates,
or
something
like
that
to
go
and
try
this
stuff
right.
So
we
created
a
secret
here,
that's
what
we
are
going
to
use
as
our
own
ca.
A
This
is
a
custom
ca,
so
for
the
for
the
for
the
for
the
production,
as
I
said
earlier,
please
use
a
proper
pkl
like
let's
encrypt
or
any
other
pki,
who
provides
you
the
sea
authority
from
where
I
can
get
the
certificates.
So
if
you
go
to
the
search
manager,
there's
a
lot
of
options,
it
provides
for
you
to
integrate
with
them.
So
it
makes
your
life
much
easier.
A
So
let's
go
and
do
this
one
as
well
apply
the
cluster
issuer
so
that
it
starts
issuing
the
certificates
and
then
we
are
going
to
create
a
certificate
request.
This
is
again
a
crd.
If
you
see
here
and
an
important
thing
on
this,
you
see
the
san
here,
the
dns
names.
This
is
june,
action.io
that
we
used
earlier
right,
I'm
just
going
to
create
this
certificate
request,
what
we
call
as
right
and
then
and
then
once
I
get
this
the
certificate
gets
created
for
me
all
right,
I
got
the
certificates.
A
The
very
interesting
thing
is:
let's
go
and
check
the
san
on
that.
So
let's
go
here,
find
out
what's
the
san
on
the
certificate
and
then,
if
you
see
this
one,
the
sinus
is
still
in
action
right.
You
can
give
any
sign
you
want,
but
for
our
case
it's
going
to
be
steel,
sand
right
and
then
it's
a
css
self
sign
authority.
Everything
is
going
to
be
its
own
authority
right.
A
A
And
then
we
created
this
now
we
are
able
to
call
back
right
earlier,
like
we
deleted
a
certificate,
but
right
now
we're
using
the
third
manager
to
go
and
get
the
certificates
and
call
the
stuff
up
right.
Let's
go
and
see,
I
think
you
should
have
created
a
secret,
but
I'm
just
wondering
where
it
got
created.
Obviously
it
should
be
the
ingress
namespace.
I
guess.
A
A
A
So
those
secrets
that
this,
if
you
see
here
the
eastern
action
cert,
is
a
secret
that
we
are
creating,
that
secret
has
to
reside
in
the
name
space
where
your
istio
ingress
gateway
is
running.
Otherwise,
your
tls
will
not
work.
What
I
mean
by
that
is
that
if
you
go
up
on
our
the
first
step
that
we
did
I'm
going
to
go
up
here,
if
you
see
here,
I
just
mentioned
on
my
gateway,
the
web
api
gateway.
I
said
the
tls
is
going
to
be
simple
and
the
credential
name
is
still
in
action.
Sir.
A
Okay,
if
you
remember
earlier,
we
created
this
certificate
in
the
istio
ingress
namespace,
that's
where
we
created
the
student
action
set
and
later
we
deleted
it,
because
we
want
the
search
manager
for
this.
So,
by
default,
whenever
it's
put
something
here,
it
has
to
be
residing
in
the
istio,
ingress
gateway
or
any
other
name
space
where
your
istio
ingress
gateway
is
running.
So
this
is
a
very,
very
important
point.
If
you
don't
do
that,
your
tls
certificates
will
not
work.
A
Okay,
I'm
repeating
it
again.
So
whenever
you
use
tls
with
gateways,
is
to
your
ingress
gateways,
the
tls
secrets
right,
the
istio
in
cache
insert
or
something
like
this.
A
tls
secret
has
to
reside
in
the
name
space
where
your
restio
ingress
gateway
is
running.
Okay,
in
our
case,
it
is
your
ingress
namespace.
A
A
Okay,
we'll
not
have
that
here,
because
it's
not
created
that,
even
if
you
created
here,
it's
not
going
to
work
because
this
here
there
is
no
namespace.
If
you
see
the
api
spec
for
the
gateway,
the
tls
attribute
will
not
have
a
namespace,
which
is
assumes
that
everything
resides
in
the
easter
egg
namespace.
A
So
this
is
one
thing
which
we
need
to
keep
in
mind
when
we
do
this
all
right,
so
we
did
this
one.
We
created
the
sand.
Everything
was
working,
I'm
fine
and
then
there
comes
an
important
part
right.
Reading
the
gateway
conflict
for
large
meshes
like
what
we
mean
by
this
okay.
So
let's
go
here
and
then
do
this
command.
A
I'm
going
to
get
all
the
clusters
in
this
case.
Don't
confuse
this
cluster
with
your
kubernetes
cluster.
This
is
the
cluster
in
nistio
in
in
envoy,
world.
A
cluster
is
a
group
of
upstream
posts,
in
this
case
kubernetes
services.
It's
a
group
of
community
services,
what
we
call
as
a
cluster
right
when
I
go
and
get
the
clusters
on
the
ingress
name,
space
english
gateway
is
going
to
go
to
all
the
thing
which
is
going
to
get
there
for
imagine
let's.
A
For
a
moment,
we
created
this
gateway
to
all
our
traffic
into
our
web
api,
correct!
That's
what
our
goal
was,
but
what
happened
right
now,
if
you
go
see
this
here,
it's
going
to
go
to
all
the
services
inside
your
name
space
and
they
are
going
to
be
part
of
a
class
which
is
going
to
be
a
huge
cluster
configuration
and
it
has
to
keep
track.
Also,
it's
not
just
the
json
or
yaml
that
gets
generated,
but
you
also
keep
track
of
these
things,
whether
it's
up
or
down
or
whatever.
A
A
Right
and
we
do
that
using
a
pilot
filter
gateway,
cluster
conflict,
there's
an
environment
variable
that
we
need
to
set
that
controls.
This
particular
feature
right.
So
when
you're
doing
a
lab,
just
just
watch
out
for
the
list
just
put
a
count
or
something
right.
Let's
do
that.
Also
right,
let
me
get
to
see
if
I
can
put
a
count
here,
wc
shell,
so
we
got
a
46.
This
is
just
a
rough
number
right
just
for
us
to
calculate
whether
my
configuration
is
reducing
these
things
or
not.
A
Okay,
so
I'm
just
going
to
apply
a
new
configuration
here,
so
I'm
just
going
to
update
my
existing
configuration
to
reduce
the
thing
right
for
that.
I
need
to
add
a
pilot
filter
gateway,
cluster
config
environment
variable
okay,
so
that's
going
to
be
added.
So,
let's
give
few
seconds
for
the
update
to
be
rolled
out.
A
F
B
Talk
to
so
we
have
to
select
everything
but
for
gateway.
You
explicitly
tell
us
right,
so
you
have
to
configure
a
gateway.
Then
you
configure
a
virtual
service
and
you
say
for
this
host:
send
this
traffic
to
this
backend.
So
we
because
we
explicitly
know
the
dependencies
of
a
gateway.
We
don't
have
to
send
it
everything.
So
in
this
case
we
are
going
to
only
send
it
the
clusters
that
it
actually
needs.
So
now,
when
commence
runs
the
same
command
again,
you
will
see
you
will
just
have
clusters
associated.
A
What
if
I
go
back
here
right
now,
since
only
the
web
api
and
agent?
These
are
few
things
which
required
htc's
grps.
These
are
the
essential
components
for
it
to
run.
So
we
cannot
skip
that,
but
from
a
services
point
of
view,
when
you
see
right
now,
since
only
the
web
api,
which
has
created
the
gateway
right,
that's
the
only
thing
which
is
part
of
your
configuration
right
now.
Others
have
gone
right.
If
you
see
the
earlier
command,
we
had
so
many
things
inside
this
right.
A
We
have
all
the
services
with,
even
if
they
have
a
gateway
or
not.
But
in
this
case
the
moment
I
enabled
a
pilot
filter
gateway,
one
layer,
web
api,
which
has
defined
a
gateway
right.
That's
a
monthly
component
which
is
available
as
part
of
your
eds.
Eds
stands
for
endpoint
discovery
service,
okay,
so
that's
the
one
thing
which
is,
which
is
that
is
that
is
used
here
right,
so
they're
kind
of
reducing
the
the
scope
of
the
whole
thing
which
the
ingress
can
see.
A
This
has
a
huge
impact
on
your
performance,
especially
when
you
have
a
high
throughput,
larger
tps,
then
your
ingress
gateway.
It
will
be
on
a
heavy
load,
so
please
make
sure
that
this
particular
thing
is
configured
according
to
your
use
case
or
your
environment,
so
that,
like
the
load
on
the
ingress
gateway,
is
reduced.
Okay,
it's
not
just
listed,
as
I
said
earlier,
it's
not
just
listing
your
services
right
as
a
json
or
yaml.
It's
beyond
that
right,
because
you
have
to
keep
track
of
that.
A
How
it
comes
up
goes
down
how
many
replicas
spot
cones
a
lot
of
things
goes
behind
the
scenes.
Okay,
so
this
is
very,
very
important,
just
the
other
one
which
is
part
of
this
particular
thing.
Okay,
there
comes
another
very
important
stuff,
which
is
very
very
essential,
for
us
is
doing
access
logging.
How
do
I
do
access
logging
for
my
gateway?
Okay?
A
To
do
this?
We
are
going
to
use
something
called
as
an
on
y
filter.
Okay,
so
we
can
also
directly
update
your
onboard
configuration
on
your
data
planes
using
this
particular
onboard
filter,
crd
that
it
gives
you
right.
So
what
I'm
going
to
do
right
now
is
going
to
do
a
filter
here
and
apply
the
configuration.
So
if
you
want
to
go
find
out
what
all
the
things
I
can
see
about
this,
I
can
just
give
you
this
unvoiled
link
here.
A
A
Configuration
that's
what
I
was
looking
for.
Okay.
So
if
you
see
this
one,
this
is
a
standard
configuration
for
onward
you'll
see
you
can
read
more
about
that
there.
So
that's
exactly
what
we're
going
to
do
here
right,
I'm
just
going
to
give
a
request
method,
start
time
and
time
etc,
etc.
To
this,
and
then
I'm
going
to
apply
this
proxy
configuration
so
that
my
logs
from
my
application
is
going
to
have
the
access
logs
added
to
this
okay
by
default,
it's
not
added.
F
A
Yeah
that's
more
detail
here.
I
just
put
the
link
just
to
understand
what
each
of
those
what
you
call
as
a
command
strings.
What
we
call
as
those
helps
you
to
do
this,
so
you
can
just
go,
find
read
this
for
more
understanding
of
what
each
of
those
things,
because
one
of
the
things
I
commonly
found
when
people
starting
to
use
istio
and
even
in
when
they
start
to
deploy
that
in
a
production
or
anywhere,
is
that
they're
having
hard
time
understanding
what
this
start
time?
What
is
this
rick
like
this
goes?
A
What
is
this?
It's
on
my
original
path
that
they're
finding
it
really
hard
to
understand
what
these
stands
for,
because
this
becomes
very,
very
important
when
you're
kind
of
debugging
your
application
issues.
So
even
when
you
report
issues
to
us
or
anybody
and
who's
supporting
enterprises,
jio,
I'm
not
sure
anybody
else
other
than
hto
is
doing
it
right
now,
all
the
upstream
ones.
So
I'm
solo!
A
So
when
you,
when
you
report
these
things,
you
have
to
report
the
logs
right,
you
have
to
understand
what
is
this
right,
because
even
in
your
debugging
sessions,
people
will
ask
you
about
this,
so
spend
some
time
reading
this
access
logging
and
what
these
ones
means
here
for
you,
so
that
they
can
know
what
you
need
to
put
as
part
of
your
access
bloggers.
Okay,
we
applied
this
now,
let's
go
and
call
this
one
again.
A
A
And
a
very
important
thing
when
you
check
the
access
locks
right
when
you
check
the
access
locks,
please
make
sure
that
you
put
the
istio
proxy
container
there.
Okay
by
default.
It
goes
to
your
application
container.
If
that's
the
first
one
that
is
coming
up
or
any
other
log
trailing
tools,
they
basically
go
fetch
the
logs
of
the
community
spots
from
the
application
box,
okay,
but
make
sure
the
access
logs
gets
into
your
istio
proxy.
The
sidecar
part
right.
If
you
see
here,
you
got
this
access
log
to
the
last
command
that
we
gave
here.
A
Okay,
so
it
gave
you
a
curl
blah
blah
blah
eastern
action
from
the
start
time
end
time
the
request,
outbound
the
source
destination,
the
host
name,
the
lots
of
other
things,
which
is
there?
Okay,
that's
what
you
got
here.
So
that's
exactly
what
we
want
on
the
log,
so
you
can
tweak
this
log
any
way
you
want,
based
on
the
access
logging
configuration
that
envoy
config
thing.
Is
there
and
then
kind
of
add
those
variables
inside
the
onboard
filters
that
we
created
earlier
and
then
put
them
across?
Okay.
There
is
also
other
formats
right.
A
This
is
a
string
format.
You
can
also
enable
the
json
format
also
for
the
login
okay.
You
can
also
do
a
logging
on
a
json
format
so
that
you
can
just
take
that
and
send
it
to
another
thing
like
splunk
or
any
other
kind
of
tools,
that
kind
of
process
it
and
do
all
kinds
of
processing.
Okay,
so
that's
pretty
much
what
we
see
in
this
lab
right.
We
saw
how
do
we
open
a
gateway
and
then
what
the
gateway
configuration
looks
like
and
then
how
do
we
enable
https?
A
And
how
do
we
scope
the
gateway
resources
to
improve
your
performance
and
then
finally,
we
saw
how
do
you
apply
the
logs
so
that
I
can
apply
the
logs
to
kind
of
investigate
my
issues
in
my
production?
Okay,
I
hope
there
are
too
much
on
this
right.
I
understand
there's
a
lot
of
things
we
covered
in
this
okay,
let's
let's
go
to
the
next
next
step,
to
see
what
we
have
next
right,
let's
go
check.
I
think
we
just
have
45
minutes
more.
A
I
hope
we
should
be
on
time
for
the
for
the
completion.
I
should
I
think
we
should
get
some
more
time
before
that.
I
think
we
have
three
more
laps
to
complete
all
right
now.
What
you're
going
to
do
is
like,
as
as
niraj
was
saying
in
the
initial
part
of
the
slides
right,
so
we
need
to
start
doing
adding
services
to
steer
right.
A
That
should
be
done
incrementally
right,
there's
a
lot
of
factors
that
you're
going
to
see
as
part
of
this
first
you're
going
to
get
the
things
into
the
service
mesh
the
next
one.
What
you're
going
to
see
is
like
accessing
service
from
within
the
mesh
from
outside
the
mesh?
That's
something
which
you're
going
to
see:
okay
digging
into
the
proxy
configuration
using
a
few
things
here
and
then
also
like.
We
have
one
more
thing
that
we
see
here,
I'm
just
okay
and
holding
an
application
until
the
proxy
card
becomes
ready.
A
This
is
one
of
the
things
you
might
mostly
might
not
need
it,
but
it's
good
to
know
how
to
do
that
as
well.
Okay,
those
are
the
things
that
you're
going
to
do
as
part
of
this
lab.
This
is
going
to
be
pretty
simple
lab.
It's
like:
how
do
we
onboard
services
into
service
mesh?
That's
what
we're
going
to
do
right
now.
So,
as
we
did
for
the
default
namespace,
I'm
going
to
label
the
istio
and
action
namespace
to
be
enabled
for
sitecar
injection
okay.
A
A
All
right,
so
so
all
these
parts
are
running
without
a
side.
Car
injection
right
now,
but
we
injected
this.
I
think
you
label
the
name
space
right.
Just
going
back
to
this
rei,
training,
the
old
point
right,
just
labeling,
the
name
space
will
not
restart
the
parts
okay.
So
what
you
have
to
do
is
like
we
technically
go
out
and
then
roll
out
the
box.
Okay,
we
are
going
to
deploy
a
new
one
and
then
we
will
roll
out
the
other
things.
Okay,
we're
going
to
do
a
can
report.
A
A
That's
the
reason
why
you
don't
see
them
the
side
card
getting
injected,
but
this
one
has
the
sidecar
automatically
injected,
because
the
new
port
that
we
deployed
after
labeling
the
namespace?
Okay,
that's
what
we
did
right
now
and
then
we
got
all
these
parts,
one
of
one
and
two
of
two:
let's
go
and
call
the
service,
because
we
don't
have
an
8
wait
for
this.
So
now
we
are
able
to
call
the
service
v1,
and
then
we
call
this
one
more
time.
We
should
see
its
goes
to
v2
right.
A
A
So
kindly
deployments
is
one
of
the
effective
techniques.
If
you
remember
like,
if
people
know
about
the
candy
deployments
pattern,
this
allows
you
to
kind
of
a
typical
one
of
the
most
common
patterns
used
in
micro
service
world
right,
because
we
want
to
introduce
changes,
new
features
only
to
a
set
of
users
and
get
the
feedback
on
how
it
works
and
then
roll
out
the
the
new
features
in
a
in
a
stacked
manner
right
so
that,
like
the
existing
users,
are
not
affected.
A
So
that's
one
of
the
the
very
coolest
patterns
that
is
used
in
very
common
patterns
used
in
the
microservice
world.
Right
now,
when
you
do
the
curl
call
here,
it
should
kind
of
flip
between
your
services,
right,
b1
and
v2,
v1
and
v2
kind
of
thing
on
the
purchase,
history
and
then
kind
of
do
this
right
and
then
now
I'm
going
to
restart
all
the
parts
which
means
that
all
my
existing
pods
are
now
going
to
have
these
side
cards.
This
is
one
of
the
ways
by
which
we
slowly
do
this
right.
A
If
you
see
the
example,
what
we
did
right
now,
we
created
the
the
character
service
created
the
deploy
the
camry
service
and
then
gave
the
request
only
to
set
up
users
we'll
be
going
to
gangry,
and
then
we
restarted
the
whole
set
of
balls
on
the
eastern
action
namespace
so
that
all
the
applications
now
start
to
behave
in
this
manner.
Okay,
everything
goes
look.
I
move
from
move
the
cadre
into
actual
version
right,
v1
to
v2
and
then
start
the
new
feature
and
then
roll
them
out
in
the
canon.
So
this
is
the
launcher.
A
Nitrate
kind
of
one
pattern
that
keeps
following
when
you
do
a
deployment
in
production.
So
there
are
other
patterns
as
well,
but
candies,
as
I
said,
can
be
the
one
pattern
that
is
usually
used
right.
Let's
go
and
see
the
pods
here
so
now
all
the
parts
should
have
everything
injected
here
for
you
right
so
now.
A
So
when
you
deploy
the
I'm
just
going
to
deploy
the
the
candy
deployment
here,
I'm
just
going
a
little
bit
faster
here,
just
considering
the
time
we
have
now
what
we
basically
did
here,
we
are
have
rolled
out
a
canary
tested
the
candy
and
made
sure
the
candy
works
well
and
moved
everything
to
candle
and
finally
like
just
to
clean
up
things,
to
go
back
to
the
state,
one
that
we
just
deleted
the
old
versions
of
it
right.
So,
if
you
go
back
and
see
what
pods
I
have.
A
So
this
is
one
of
the
things
we'll,
I
think
just
one
of
the
patterns,
probably
you
can
just
go,
read
more
about
candy
pattern.
What
it
actually
does,
the
the
the
thoughtworks
radar,
the
blinky
has
a
good
explanation
of
what
candy
pattern
is
right
now
digging
into
the
proxy
configuration
again.
So
this
is
very
crucial
at
every
step
that
you
do
an
iterative
approach
right,
and
this
is
very
important
for
us
to
know
how
to
actually
know
whether
my
configuration
on
my
configuration
generated
is
correct
or
not
right,
so
the
proxy
config
command.
A
Again,
we
saw
it
multiple
times
earlier.
Now,
I'm
going
to
get
this
proxy
config
command,
and
it's
going
to
give
me
all
the
the
complete
proxy
things
of
the
particular
thing
right.
It's
a
kind
of
a
dump
right
where
it
goes
and
all
these
things
I
think
you
can
also
do
iphone
or
json.
If
you
want
or
yaml
to
give
you
the
json
or
yaml
format
off
this
is
this
is
going
to
dump
you
the
on
y
configuration
right,
the
filter
change,
that
is,
that
is
required
here
and
all
these
things.
Okay.
A
So
this
is
a
huge
thing.
We
will
not
have
time
to
go
and
dig
into
this,
but
whenever
you
have
issues,
take
the
dump
of
this
proxy
configuration
and
share
it
with
us
when
you're
dealing
with
solo.
As
for
your
support
for
hto,
then
we'll
be
able
to
make
out
what's
going
wrong
or
help
you
out
with
your
fixing
your
environment,
all
right
so
and
then
another
important
thing
is
that
listeners
is
what
the
request
comes
in
right.
A
As
you
know,
the
other
one
is
the
clusters
where
the
listeners,
the
requests
go
to
right
the
end
destination
upstream,
was
what
we
call
as
anything
right.
I
think
there's
a
lot
of
upstream
most,
as
you
saw
here,
there's
prometheus
we'll
come
back
to
this
very
important
thing.
Again,
if
you
remember
it's
your
ingress
gateway,
we
reduce
the
scope,
okay
and
the
same
thing
has
to
be
done
for
your
data
planes,
also.
Otherwise,
we're
again
going
to
have
the
same
performance
bottleneck,
but
we'll
see
that
in
the
next
module.
A
So
right
now
we
have
so
many
things
here,
like
the
clusters
are
having
lots
and
lots
of
clusters
here:
okay
and
then
it
can
also
have
the
endpoints
right,
specific
endpoints
that
it
goes
to.
If
you
see
here,
it's
going
to
go
to
the
recommendation
istio
service
in
action.cluster.local,
and
then
it
goes
to
some
other
thing.
There
are
a
few
other
things
that
all
the
services
that
this
particular
cluster
is
going
to
go
for.
A
This
particular
recommendation
is
going
to
talk
to
okay
so
and
then
we
can
also
so
in
some
cases
what
it
might
needs
right
in
in
general,
in
kubernetes
world.
You
cannot
control,
you
can
control
the
the
elite
containers
and
then
your
actual
containers
comes
up
right,
but
sometimes
what
you
also
wanted
to
have
the
containers,
the
ordering
of
the
containers.
I
think
there
is
a
spec
which
is
I'm
not
sure
whether
this
approved
yet
and
kubernetes
are
not
to
control
this
actually.
A
But
if
you
want
to
control
this
behavior
say
that
your
application
has
to
come
up
only
after
your
just
your
proxy
starts.
Usually
your
proxy
starts
super
fast
okay.
To
do
that,
you
basically
annotate
your
application,
saying
that
istio.ioc
hold
the
application
until
the
proxy
starts
is
true.
So
if
you
set
this
annotation,
then
what
happens
when
you
roll
out
the
restart
of
a
web
application
or
a
service
the
workload?
Basically,
the
workload
parts
waits
until
your
application
starts.
Okay,
I
mean
the
http
proxy
starts.
Okay,
for
example.
A
I
have
applied
this
one
and
then
let's
go
and
describe
this
board
and
then
see
the
events.
If
you
see
the
events
that
the
probe,
which
starts
only
after
your
istio
unit,
is
started,
okay,
so,
instead
of
start
at
the
hdr
proxy
container-
and
then
here
is
your
container
web
api
container
get
started,
so
we
can
control
the
the
starting
of
your
web
application
the
container
until
the
proxy
starts
in
some
cases
you
might
need
it,
but
most
of
the
times
the
proxy
starts
at
blazing
fast
speed.
A
A
Okay,
we
are
on
the
mtls
stuff.
We
have
that
we
need
to
start.
So
how
do
I
roll
out?
Mtls
like
there
are
a
few
things
which
we
need
to
consider
right.
The
whole
lab
talks
about.
How
do
we
actually
do
mdls?
How
do
we
enable
mtls?
What
are
the
things
that
they
require,
and
this
is
from
a
more
from
a
technology
point
of
view.
A
How
do
we
do
that
with
ecu
right,
but
the
other
part
which
you'll
also
see
as
part
of
this
lab,
is
that
how
do
I
actually
go
enable
this
stuff
for
my
services
department?
What
I
mean
by
that
is
that
blindly,
I
cannot
go
enable
mdls
in
case.
If
my
one
of
the
services
is
not
enabled
for
mtls,
then
those
service
costs
going
to
fail.
So
how
do
I
control
that?
A
So
those
are
the
two
very
important
things
that
we
are
going
to
see
as
part,
and
how
do
I
identify
which
clients
are
not
enabled
for
mtls,
so
so
that
I
I
can
inform
them
so
that
they
can
enable
mtls
and
talk
to
me
right.
So
these
are
the
few
things
that
we
are
going
to
see
as
part
of
this
particular
lab.
A
Okay,
that's
what
we're
going
to
do
this
right
now,
so,
let's
say
I
am
allowing
in
both
the
base
strict
as
well
as
not
strict,
okay
and
then,
if
I
go,
give
a
call
here
from
within
a
mesh
okay,
if
you
go,
if
you
see
this
call,
I'm
calling
from
vista
in
action
name
space
which
is
labeled
within
the
mesh,
so
the
service
calls
from
within
the
mesh
will
always
go
in
an
mtls
fashion
by
default.
Okay,
how
do
I
identify.
D
A
I'll
identify
the
mtls
information
using
the
xfcc
header
that
we
call
as
x,
forwarded
client
search
form.
Okay,
if
you
see
this
one,
this
uses
a
protocol
called
a
spiffy.
This
is
a
very
interesting
protocol
that
you
can
go
and
read
about.
So
this
is
what
is
used
by
institute
to
kind
of
generate
your
workload:
identification.
Okay,
it's
nothing
but
certificates
that
it
generates,
so
that
the
workload
when
it
sends
the
spf
header,
along
with
it,
it
can
verify
that
it's
coming
from
an
authenticated
source,
that's
what
it
does
using
spiffy
here.
A
A
Okay
for
a
change,
let's
see
a
call
from
outside
the
mesh,
the
default
name
space,
I'm
calling
a
service
which
is
not
in
the
mesh.
If
you
remember
the
sleep
pod
on
the
k
get
pod
on
the
default
name,
space
does
not
have
sidecar
injector,
which
means
that
it
is
outside
the
mesh.
Okay,
that's
what
we
call
that's!
What
we
call
by
inside
and
outside
the
match
is
that
whether
a
data
plane
is
attached
to
your
service
or
not
your
workload,
okay,
so
let's
go
and
give
the
call
to
this
one.
A
And
now,
if
you
see
this
one,
there
is
no
spiffy
header
here
right
the
x.
Sorry,
not
if
we
adder
xfcc
header
right
x,
forwarded
client
for
it
does
not
have,
which
means
that
this
particular
guy
is
not
trustable
okay,
but
we
still
allowed
it
because
my
policy
right
now
what
we
applied
earlier
says
that
I'm
permissive
okay,
I
allowed
both
mtls
and
tls.
Okay,
now,
let's
go
and
lock
down
the
thing
right,
so
I'm
going
to
say:
okay
for
purchase
history,
I'm
going
to
lock
down
only
one
service
right
now.
Oh
sorry,.
A
So
I'm
just
going
to
say
for
purchase
history,
I'm
going
to
make
sure
that
it's
strict
right.
It
does
not
allow
things
without
mtls.
Okay,
that's
what
I'm
going
to
do
right
now,
so
make
it
stick
so
that
anybody
any
client
coming
without
mtls
enable
or
the
client
client
certificate,
so
they
are
going
to
be
rejected.
Okay,
that's
what
the
whole
idea
is,
I'm
going
to
call
from
the
service
from
outside
the
namespace.
A
Okay,
you
see
this
call
goes
through.
Okay,
you'll
be
wondering
how,
because
the
call
is
not
going
to
directly
from
the
sleep
pod
to
the
purchases
it's
going
through.
The
web
api
web
api
is
inside
the
http
reaction.
Name,
space
is
enabled
right.
So
let's
go
and
see
this
right.
So
let's
go.
Do
this
one?
Okay,
on
this
service
right,
let's
go
to
kayali.
A
A
A
On
differences
and
pick
up
the
name
space
graph,
I'm
going
to
pick
up
the
istio
in
sys
action
name,
space,
okay,
I'll
also
leave
the
https
right
and
then
and
then
display
I'm
going
to
do
the
security
one.
Okay,
I'm
going
to
enable
the
security
okay
and
then
I'm
going
to
give
a
call
right.
Now,
I'm
going
to
give
the
same
call
again.
A
Okay,
sorry,
I
have
to
enable
the
two
namespaces
here,
because
the
call
is
coming
from
default
into
eastern
action
and
now,
if
you
see
this,
the
web
api
in
action
is
going
to
be
calling
the
issue
in
action.
The
unknown
is
nothing
but
your
sleep
pod
that
is
giving
a
call
getting
inside
this.
This
is
an
unencrypted
traffic.
We
don't
have
the
lock
here
again.
This
is
also
under
cut.
It's
go
to
eastern
action
by
v1.
Now
the
moment
it
hits
the
is
to
an
action.
Namespace.
A
You
see
that
one
here
we
saw
the
spiffy
principles
coming
here
right.
That's
the
reason
why
the
call
was
going
through
successfully
because
the
call
is
not
directly
to
a
particular
strict,
enable
purchase
history
inside
your
web
action.
We
are
going
through
a
service
inside
the
service
mesh.
Okay,
that's
the
reason
why
you
see
all
these
locks
here,
because
they're
automatically
mtl
as
enabled
and
then
the
one
coming
from
outside
is
not
that's
what
you
see
there.
Okay,
I
should
have
paused
it
okay,
so
now
let's
go
and
do
this
we
did
this.
A
We
enable
the
security.
We
did
all
these
things
right
now
so
now.
The
other
important
things
right
now
come
to
me
is
that
how
do
I
identify
who
is
calling
with
mts?
Now
we
went
to
k
ali,
but
there
are
some
cases
where
you
might
not
use
cl.
You
cannot
use
clearly,
for
some
reasons.
Okay,
this
is
assume
that
case
okay.
So
how
do
I
basically
identify
who
is
coming
with
the
certificates?
I
think
with
mtls
enabled
and
who
is
not?
A
A
We
are
going
to
apply
this
one
where
we
are
going
to
say
that
include
the
statistics,
this
one.
This
is
kind
of
thing
where
we
enable
the
stats
capture
so
that
we
know
tls
found
a
tls,
not
form
okay.
So
we
are
going
to
see
this.
How
do
we
find
this
one,
for
example,
let's
go
and
give
this
one
call
here.
A
There's
a
tls
inspector
enable
the
tls
inspector
says
whether
the
tls
is
found
or
not
found,
sni
found
or
not
phone
kind
of
things
right.
This
will
allow
you
to
identify
how
many
requests
are
getting
in
which
has
the
the
thing
found
or
not.
Okay.
This
is
one
thing
to
identify
the
second
one,
but
this
does
not
give
you
the
source
right
from
which
source
the
request
is
coming,
so
that
you
can
inform
the
respective
consumers
or
the
clients
to
kind
of
go
update
them
to
the
respective
thing.
A
That's
what
we
are
going
to
do
next
to
do
that.
What
you
are
going
to
do
is
like
okay,
you
can
also
grab
the
listener.
Also.
This
also
gives
you
the
handshakes,
the
cx
total.
The
connection
total
will
just
come
up,
etcetera,
etcetera.
There
are
two
ways
to
do
this.
These
are
a
bunch
of
statistics.
I'm
sorry!
I
went
a
little
jumped
a
little
bit
ahead.
Okay,
so
we
enable
tls
inspector.
We
are
enable
the
listeners
so
that
we
know
how
many
requests
are
coming
through,
how
many
are
failing,
etc,
etc.
A
All
right
so,
let's
go
and
do
this
one.
Let's
go
and
give
a
call
to
the
student
action.
I
think
this
should
go
through,
because
this
is
https.
Let's
go
and
grab
the
listener
to
find
out
if
any
int
kappa.
No.
There
is
no
answer
captain,
because
this
has
come
from
default
namespace,
which
means
that
it
does
not
have
anything
inside
right.
So
we
can
also
check
the
tls
inspector
to
find
out
that
the
tls
information
come
no
there's
no
tls
one
because
coming
from
default,
node
tls
right.
A
We
found
out
that
using
the
kali
console
last
one.
So
this
gives
you
some
statistical
information
about
what
is
that
some
metrics
around
how
many
things
are
failing
all
right?
If
you
do
the
listener
stats,
if
you
do
the
same
thing,
the
listener
starts
also,
we
saw
just
now
that
check
was
zero
okay,
but
what?
If
a
call
from
a
mesh?
A
Okay,
I'm
calling
from
my
sleep
part
from
within
a
mesh
when
I
do
this,
my
old
command
should
return
me
one
cs
and
I
found
one
tls1,
because
it's
an
empty
as
enabled
that's
within
the
mesh
perfect.
That's
that
sounds
good
and
then
the
same
thing
should
happen
within
the
listener.
Also,
I
should
see
one
handshake
happening.
Okay,
this
is
a
tls
inspector.
When
I
go
this
one,
there
should
be
one
handshake,
curves
x2559.
A
There
is
one
thing
and
there
is
one
landshape.
So
this
gives
me
the
information
about
how
many
tls
is
coming.
How
many
dls
is
failing,
whether
good
or
not
how
all
we
need
to
track,
but
one
crucial
information
is
missing.
Here
is
the
source.
How
do
you
identify
that
for
that?
What
you'll
do
is
like
we're
using
the
authorization
policy
plus
the
access
logging
that
easter
provides
so
that
I
can
identify
how
which
are
the
clients
where
this
particular
mtls
is
failing?
Okay,
that's
what
you're
going
to
do
next?
A
Okay,
I'm
going
to
enable
audit
logging
so
that
there's
going
to
be
auditing
happening
on
my
request
path.
That's
what
I'm
doing
here.
The
fb
api
audit
authority
is
an
authorization
policy
rules
from
namespace,
not
in
history.
In
action
operation
is
equal
to
get
okay,
I'm
just
going
to
find
out,
because
obviously
eastern
action
is
a
namespace
where
obviously
mtls
will
be
there.
A
So
we
don't
need
to
check
that
okay
from
any
other
outside
the
mesh
client
calls
I'm
going
to
go
check,
which
are
the
ones
which
are
going
to
give
you
the
good
with
mdls,
which
are
not
good
with
mps.
Okay,
so
I
created
the
auth
policy
right
now,
okay
and
then
I'm
also
going
to
create
an
access
login
right,
as
you
know
earlier,
I'm
enabling
the
tls
inspector
and
the
other
things.
A
If
you
remember
right
those
two
things
I
have
enabled
here
on
this
one
connection
manager
and
then
I'm
going
to
apply
this
so
that
my
audit
logging
tells
me
about
some
information
about
what's
happening
right
now,
when
I
go
give
a
call
okay,
this
is
the
first
call
I'm
going
to
give
all
right
and
then,
when
I
see
the
logs
of
this
call,
so
I
get
an
access
lock.
The
access
lock
says
all
the
information,
but
the
the
good
thing
about
this.
A
This
is
giving
me
a
spiffy
adder,
okay,
from
where
the
origin
is
happening,
which
means
that
I
know
the
origin
is
coming
with
an
mtls
line
certificate
on
with
it.
Okay.
So
this
gives
me
an
information
about
what
is
not
right.
Let's
try
doing
the
same
thing
from
a
default:
namespace,
okay,
I'm
going
to
do
the
default
namespace
and
then,
when
I
check
the
logs
again
so
the
earlier
one
was
coming
with
swifi.
A
If
you
remember
the
next,
one
was
not
coming
with
the
speed,
so
this
gives
me
an
identification
from
which
source
it
is
coming
from,
but
it
is
not
coming
with
the
spiffy
header,
so
I
can
enable
I
can
I
mean
audit
or
track
those
applications
from
there.
Those
calls
are
coming
without
xfcc
headers
and
inform
those
respective
consumers
to
go
and
enable
them.
Okay.
This
way
I
can
incrementally
enable
mtl
stick
mtls
inside
my
cluster.
A
A
Which,
actually,
I
should
not
get
things
because
I'm
getting
a
56
error,
because
the
default
namespace
does
not
have
mtls
enabled.
So
I
cannot
give
a
call
to
a
strict
istune
action
namespace,
because
I
knocked
down
the
namespace
to
be
strictly
empty.
Any
call
that
comes
inside
the
istio
and
actual
space
should
be
mtns
enabled.
So
this
is
how
we
incrementally
enable
ntls
in
your
cluster
using
history
all
right.
So
that's
what
we
saw.
A
We
saw
how
we
enable
mtls,
the
permissive
mode,
the
stick
mode,
how
we
can
identify
your
services
are
coming
with
or
without
mtls,
etc,
etc,
and
then
gradually
do
the
incremental
application
of
your
mtls.
Okay,
all
right!
So
let's
go
to
the
the
last,
but
one
thing
where
we
kind
of
doing
some
scoping
and
all
these
things.
Obviously
niraj
was
talking
about
that
using
the
workspaces
that
we
do
with
the
blue
mesh.
We
are
going
to
see
how
it
is
done
underneath
by
easter.
A
Okay,
that's
what
you're
going
to
see
as
the
next
lab.
That's
what
we
call
by
configuration
scope
right
where
we
call
stuff
from
inside
or
outside,
etc,
etc.
Okay,
so
the
very
important
thing,
what
we
talk
about
configuration
is
something
like
exports
export
to
like.
If
you
remember
it's
the
same
principle,
pretty
much
the
same
principle
that
we
saw
when
you
do
the
scoping
of
english
gateway
right
so
that
it
doesn't
see
the
entire
universe
right.
A
It
just
sees
only
thing
which
is
required
for
it
to
keep
track
of
that's
exactly
what
you're
going
to
do
from
the
sidecar,
also
because
even
every
side
car
that
we
get
injected
right
all
the
side.
Car
resources
by
default
sees
everything
within
the
cluster.
Okay,
that's
exactly
what
niraj
was
talking
about
workspaces
right
this
same
principle.
A
We
take
it
into
workspace
and
try
to
control
the
visibility
of
what
it
can
see,
what
it
cannot
see
and
kind.
Therefore,
we
can
kind
of
get
those
what
you
call
multi-tenancy
and
all
these
things
coming
inside.
Okay,
so
you
are,
we
are
going
to
know
one
one
resource
called
a
side
car
resource,
which
we
say:
okay,
what
is
allowed,
what
we
guesses
are
allowed
from
within
and
without?
Okay,
that's
what
we
are
going
to
do
right
now,
so
we're
just
going
to
apply
this.
A
This
rule
the
sidecar
thing
on
this
particular
default
namespace,
and
now,
when
I
try
to
reach
the
deploy
sleep,
steering
action
from
this
particular
namespace,
I'm
going
to
get
a
503,
because
what
I
have
done
here
is
that
so
I
said
to
the
eagles
host
web
dot.
Api
thing
this
by
default
comes
only
from
the
istio
in
action
name
space.
It
cannot
the
other.
Other
resources
cannot
be
seen
from
outside
the
outside
the
name
space.
Only
the
services
within
the
names
case
can
see.
That's
what
we
enable
this.
A
A
A
What
we
do
right
now
is
that
we
save
to
the
same
side
car
we
update
the
same
site
current
say
view
all
the
services
within
the
same
name,
space
to
the
services
within
the
peers
can
see
all
the
services
within
that
particular
name
space.
That's
what
you're
trying
to
do
here!
Okay,
let's
go
here
and
apply
this
one
okay.
Now,
when
you
do
a
curl,
obviously
you'll
get
200
okay,
perfect,
because
I'm
able
to
do
this
everywhere.
A
Okay,
so
now,
when
you,
when
you
check
the
cluster
for
this
right,
so
let's
go
and
clear
the
screen
again
see
the
cluster.
Here
you
see
the
sleep
api
initially
in
action,
so
only
the
student
action
name
spaces
are
listed
here.
Okay,
obviously
the
bunch
of
other
sdod
thing
which
is
required.
We
cannot
remove
that
amount
right
now
when
I
roll
out
the
restart
of
the
sleep
pod
on
the
root
name
on
the
default
name,
space
k
get
pause.
That's
what
I'm
doing
here,
I'm
restarting
the
sleep
part.
A
A
C
A
E
A
A
What
cannot
be
seen
kind
of
thing
right
only
within
the
mesh
kind
of
thing,
so
that
it's
you
can
control
your
configuration
scope,
okay,
so
that
your
your
enviro
configuration
is
pretty
slimmer
within
the
data
play
and
also
the
number
of
requests
or
number
of
checks.
It
has
to
do
frequently
also
comes
down
which
greatly
improves
your
performance
when
you're
having
the
resources
too
many
resources
end
of
the
day,
all
right,
so
the
other
one
which
also
controls
is
the
export
to
configuration.
Okay.
A
This
is
for
the
producers
when
I,
when
I
mess
up
this
producer,
I
can
say:
okay,
I'm
exposing
I'm
making
my
service
only
visible
to
only
these
namespaces
that
what
the
service
providers
export
to
configuration
does.
Okay,
for
example,
I'm
going
to
send
the
traffic
through
the
gateway.
Okay,
I'm
getting
through
everything.
Okay,
everything
should
be
status,
200
port.
Now.
What
I'm
going
to
do
is
that
I'm
going
to
delete
the
gateway,
the
default
gateway
is
to
an
action,
okay
and
a
gateway
resource,
I'm
going
to
create
that
in
an
ingress,
namespace.
A
Okay,
that's
a
change!
I'm
just
moving
it
from
the
eastern
action
to
the
istio,
english,
namespace,
okay,
and
I'm
going
to
update
the
gateway
service
to
go
and
use
the
eastern
english
web
api
gateway.
That's
what
I'm
going
to
do
next,
all
right
now,
when
I,
when
I
do
the
curl,
I'm
going
to
still
going
to
get
the
200
request
right
now:
okay,
it's
not
going
to
do
anything
wrong!
A
So
now
what
I'll
be
doing
right
now,
I
say
that
this
gateway
is
going
to
expose
services
only
to
the
dot,
which
means
the
current
name
space.
That
is,
which
is
the
issue
in
action
namespace,
which
means
that
any
other
name
space
trying
to
call
this
particular
virtual
service
will
not
have
an
access
to
okay.
That's
what
we're
going
to
do
right
now.
A
A
A
A
C
A
My
still
my
route
still
says
four
zero.
Four,
because
I
have
not
bought
an
insta
ingress
yet
into
the
thing
right
exposed
into
a
particular
namespace.
I
can
give
the
namespace
also
here,
okay,
so
that
one
I'm
not
done
I'm
just.
I
will
be
doing
that
bit
later.
So,
let's
go
and
see.
How
can
I
merge
these
resources
right
so
and
then,
when
I
kind
of
do
this
export.
A
A
A
Yeah
it's
running
right
now.
Now,
when
I
give
the
call
that's
a
good
question,
I
think
I
need
to
I
need
to
check.
I
think
there
is
a
there
is
a
separate
lab
guide,
I'll
check
on
that
to
see
if
it
can
get
this,
but
usually
the
lab
instructions
are
part
of
these
workshops.
So
obviously
it's
tied
to
the
workshops
but
I'll
check
to
see
if
there
is
a
way
is
there
any
public
repository
from
that?
A
A
A
All
right,
so
I
think
this
one
I
think.
Well,
we
talked
about
export
too
right.
I
think
I
think
neeraj
covered
that
as
architecturally
during
the
slides,
but
we
did
this
in
a
different
way,
because
there's
a
lot
of
complexities
involved
in
how
do
we
rightly
export
stuff?
That's
one
of
the
reasons
why
we
bought
that
with
the
blue
mesh,
making
things
easier
for
you,
so
that
you
can
have
this
multi-tenancy
and
other
stuff
automatically
added
to
this
right.
A
A
And
obviously
you
can
find
the
book.
I
have
put
the
link
on
the
slide
I'll
share
the
slides
at
the
end
of
the
thing,
I
think,
if
otherwise,
if
you're
just
google
is
jio
in
action,
you
will
see
the
the
book
that's
returned
by
christian
poster
and
and
reynard
you
can
go
grab
this
book
from
manning
and
then
you
can
use
this
book.
A
I
think
you
can
use
the
discount
code,
I'm
not
sure
how
much
discount
you
get,
but
this
is
what
the
stone
code
I
got
from
our
people
to
do
this,
and
obviously
I
also
need
another
request
from
you
is
that
before
we
you
sign
off,
I
want
I
want
to
have
to
fill
up
the
survey.
I'm
going
to
put
the
survey
link
also
on
the
chat.
A
I'll
also
ask
because
nippings
are
to
kind
of
send
this
across
to
the
email
to
all
the
participants.
So
this
is
something
please
do
fill
the
survey
link.
Let
us
know
what
we
did
good,
what
we
did
bad,
etc,
so
that
we
can
improve
this
stuff
and
obviously
people
who
have
participated
in
this
thing.
You
can
also
have
a
certification
done.
Okay,
certification
link
is
here.
A
So
this
is
the
certification
that
you
get
a
solo,
certified
istio
professional.
I
mean
thing
kind
of
thing
that
you
get
you
get
the
certification
link
you
can
you
can
write
this
google
form
submit
it
from
the
id
with
which
you
are
registered,
so
that,
like
you,
get
your
certificates.
Also
there,
okay
I'll
pass
on
these
two
links,
also
to
true
nip
inside
to
kind
of
do
it,
send
it
to
email
as
well,
so
that
we
can.
A
You
can
get
this,
but
please
do
fill
up
the
feedback
that
will
help
us
a
lot
to
improve
the
next
thing.
What
you
can
cut
down,
what
you
can
increase,
what
you
cannot,
etc,
etc.
Okay,
I'll
continue
the
last
part.
While
we
do
this
right,
so
this
is
more
of
debugging,
so
nothing
big
here,
just
just
kind
of
relaxing
at
the
last
thing
after
the
intensive
horse,
okay,
so
istio
c
to
analyze,
will
basically
help
you
to
analyze
these
things.
We're
going
to
see
bunch
of
commands,
that's
going
to
say
what
is
not.
A
What
is
good,
what
is
bad
with
your
cluster,
etc,
etc.
Right.
This
is
a
very
crucial
one,
because
sometimes
you
might
need
to
play
around
with
this
to
find
out
more,
but
we'll
touch
upon
these
things.
Right,
for
example,
I'm
going
to
go,
delete
the
certificates
that
we
created
for
our
gateway
right
now,
when
I
go
and
do
these
two
ctl
analyze,
that's
going
to
say,
the
certificates
are
missing.
Okay,
as
you
see
here
the
example
says,
certificates
are
missing
because
I
just
now
deleted
it.
A
A
This
is
what
the
information
we
see
on.
I
think
it's
going
to
be
more
exhaustive
in
a
bigger
cluster.
Okay,
the
proxy
status
will
give
you
like
how
the
proxy
has
been
synced
with
your
pods
you'll,
see
the
list
of
parts
that
the
data
plane
exactly
the
data
plane
pods
and
whether
your
cds
cluster
discovery
services,
listener
discovery,
services,
endpoint
discovery,
services
and
drought.
Discovery
services
have
been
synced
with
your
istiot
okay.
What
does
it
mean?
A
Is
that
whenever
you
see
something
is
not
sync,
this
means
there
is
a
disconnect
or
something
going
wrong
or
anything
right.
You
can
go
find
out
right,
htod,
synchronizes
the
configuration
with
your
data
planes
in
a
timely
fashion,
as
I
told
you
on
the
very
first
start
of
the
lab
when
something
goes
wrong,
it
will
not
completely
disconnect
your
services,
so
these
services
will
still
continue
to
work
because
it'll
run
with
the
last
known
code
configuration
okay,
so
this
ctl
proxy
status
becomes
super
important
for
you
to
find
out
what
is
going
good.
A
What
is
going
bad?
Okay,
we
can
also
go
find
it
out
at
a
very
specific
deployment
level.
Also,
whether
the
cluster
does
match
listeners
does
match
everything.
Working,
fine
or
not.
Okay,
the
proxy
config
is
in
another
one,
which
actually
makes
a
very
big
impact
right
for
you
to
find
out
something
right.
It
doesn't
open
the
browser
here.
Okay,
it
goes
to
onward
dashboard,
so
this
dashboard
gives
you
lots
of
information.
Okay,
it
gives
you
the
certificates
clusters,
whatever
I'm
typing
right
now
on
stl.
I
can
see
everything
here
but
remember.
A
We
are
seeing
the
stats
one
right
if
you
click
on
this.
This
is
going
to
give
you
all
the
stats
from
the
browser.
Okay,
that's
what
that's
what
the
stats
I
mean,
the
sdo
the
android
dashboard
gives
but
be
careful
on
honor.
I
think
I'm
not
sure
I
think
niraj
you
can
correct
me.
There
was
there
was
something
that
has
to
update
us
to
come
in
the
estio
which
prevents
the
the
admin
dashboard
running
in
the
0.0.0
interface
right.
So
there's
something
doing
that
I
forgot.
A
I
forgot
that
I
think
right
now,
it's
running
there
so
because
why
it
is
important,
because
I
can
kill
the
server
from
here
right.
If
I
get
an
access
to
this
url,
I
can
go
shut
down
the
your
server.
If
you
see
here,
I
can
get
the
server.
If
I
run
time
modify
reset
counters,
I
can
quit
the
server,
which
means
that
your
data
plane
goes
off.
A
Okay,
so
be
careful
that
when
you
run
it
so
don't
run
it
on
0.0.0.0,
just
run
it
to
your
localhost
or
something
where
you
can
only
access
from
within
your
network.
Okay.
So
this
is
something
which
you
did
and
also
like.
You
can
also
enable
if
you
remember
that
we
enable
the
logging
using
onboard
filters
right.
We
can
also
do
the
logging
enabling
just
using
the
stl
command,
but
a
specific
part,
so
that
you
can
know
see.
A
If
you
see
there
are
a
lot
of
components
inside
admin,
aws
asset
back
trace,
so
many
things
that
half
of
it
you
will
not
use
off
of
it.
You'll
use
right,
so
I
can
go
and
enable
the
lock
so
that
I
can
get
the
debug
logs
to
identify
what
is
going
wrong.
Okay,
it's
more
for
debugging
purpose!
That's
what
we
do
here!
A
A
Okay,
it
gives
you
the
more
health
checks
to
see
if
the
spell
points
are
working.
I
think
we
saw
this
command
on
our
first
on
white
thing
right.
You
can
also
see
this
http
bin
thing
here
on
the
clusters
and
end
points
for
a
very
specific
part.
Okay,
you
can
also
do
this
one
to
get
the
prometheus
matrix
they're,
all
just
I'm
typing
these
commands.
These
are
all
standard
commands.
A
A
Just
put
dash
dash
help
to
go
and
find
out
what
all
the
other
things
you
can
do
just
play
with
that
and
obviously
put
the
slack
link
on
the
chat
soon
and
then
and
then,
and
then
we
can
just
play
around
with
all
these
commands.
Okay,
so
I
think
that
brings
us
to
the
end
of
the
lab,
where
I
think
we
have
done
all
the
exercises
here.
A
A
A
A
So
this
has
the
eastern
action
manning
book
as
well,
and
then
there
is
a
code
which
I
put
it
on
the
chat
so
that
you
can
use
it
code,
please
to
copy
the
code
in
case.
If
you
lose
the
chat,
you
lose
the
code
also,
and
obviously,
please
do
take
the
certificate.
If
you
want
to
get
yourself
certified
with
hto
from
solo,
so
you
can
get
the
certificate
done
from
there
as
well,
and
obviously
please
do
fill
the
survey
link.
A
A
F
B
F
F
A
What
we
should
do
yeah
go
ahead
this
one.
This
one
is
public,
workshops.solo.I
workshops.solar.io,
but
we
have
all
the
labs
here,
but
I'm
not
sure
if
the
so.
I
think
that
this
workshop,
that
solo.I
o
is
the
monthly
thing
which
I
see
which
is
open.
I
need
to
go
check
the
github
link.
If
I
I'm
going
to
check
back
the
with
the
people
right,
if
it's
open
I'll
I'll
share
again,
I'm
not
sure
it's
open.
It's
in
the
solo,
private
github,
repo
yeah.
F
F
From
from
the
opening
keynote
to
several
workshops
and
sessions,
so
do
attend
that
and
lastly,
if
any
of
you
are
looking
for
some
enterprise
usage
from
complicated
use
cases
where
open
source
is
your,
you
know
you
might
not
be
that
might
not
meet
your
needs.
Please
reach
out
to
us.
We
are
helping
and
making
service
messages
in
really
really
large
use
cases
and
also
in
smaller
use
cases
where
companies
are
just
starting
up
the
usage.