►
Description
Ortwin and Stylianos are joining Andrew and Jonny to talk all things Service Mesh!
Want to take Red Hat Advanced Cluster Security Cloud Service for a spin? Go to: https://www.redhat.com/en/technologies/cloud-computing/openshift/advanced-cluster-security-kubernetes/cloud-service/trial
Join OpenShift Commons:
https://commons.openshift.org/join/
OpenShift Users Slack Channel: https://kubernetes.slack.com/archives...
Want to learn more?
Try Red Hat OpenShift: https://red.ht/3uVxkya
Follow us:
Andrew Sullivan https://twitter.com/practicalandrew
Jonathan Rickard https://twitter.com/jrocktx1
OpenShift https://twitter.com/openshift
Subscribe to Red Hat's YouTube channel: https://www.youtube.com/redhat/?sub_c...
About Ask an OpenShift Admin:
Do you have questions? We want to answer them! Every Wednesday at 11am ET, hosts Andrew Sullivan and Jonathan Rickard sit down to answer your questions about Red Hat OpenShift.
About OpenShift:
Red Hat OpenShift is an open source container application platform based on the Kubernetes container orchestrator for enterprise application development and deployment.
OpenShift on redhat.com https://red.ht/3rYz5ZS
OpenShift on GitHub https://github.com/openshift/
#RedHat #OpenShift #Kubernetes #ContainerPlatform
A
B
A
B
A
B
A
B
A
B
Well,
thank
you.
Everyone
for
joining
us
here
on
red
hat
live
streaming,
so
this
is
a
office.
Hours
live
stream
here
on
the
channel
and
office
hours
are
designed
for
you
all
to
ask
us
questions
about
anything
and
everything
that
happens
to
be
on
your
mind.
So
Johnny
and
I
are
both
openshift
experts.
B
We
tend
to
focus
on
the
things
that
are
below
the
application:
Level
lots
of
infrastructure
type
things,
so
we're
happy
to
do
our
best
to
answer
those
questions
for
you,
however,
if
we
can't
answer
them,
which,
let's
be
honest,
happens
on
a
regular
basis,
we
also
have
contacts.
We
have
people
that
we
can
reach
out
to
sort
of
all
across
the
product
in
engineering
and
everywhere
else,
inside
of
red
hat.
B
Orton's
pretty
well
known,
actually
dang
I
should
have
worn
my
shirt
today
or
when
the
shirt
that
you
that
you
sent
to
me
so
sorry,
so
Orwin
is
well
known,
certainly
within
Red
Hats
and
amongst
other
places
for
Bobby
Carr
and
a
few
other
things
so
very
happy
to
have
you
all
join
us
to
talk
about
red
hat
service
mesh
today,
so
Orton
stelos
I
will
ask
you
all
to
introduce
yourselves
in
in
that
order.
Please.
C
B
C
Not
that
much
no
yeah,
I'm
I'm
off
engineer
based
in
Germany
and
I'm
in
the
hybrid
platforms
business
unit,
as
well
as
you
Sally
and
I'm,
really
happy
there
to
support
the
team
and
and
the
product
openshift
in
various
ways.
And
primarily
you
know.
Building
or
creating
solution
patterns
is
one
thing
and,
in
general,
creating
technical
content
and.
C
D
B
Here's
some,
really
cool
things
that
you
can
do
you
know,
and
and
not
necessarily
something
that
has
been
done
before
has
been
implemented
by
a
customer,
but
it's
really
cool
stuff
that
you
can
do,
whereas
validated
patterns
are
sort
of
I
would
say
the
opposite,
but
there's
still
really
cool
stuff
that
you
can
do,
but
they're
they're,
always
customer
adopted
and
I.
Think
the
great
thing
about
validated
patterns
is-
and
this
is
Johnny's
day
job.
B
Everything
about
them
is
automated,
so
it
that
it
can
run
through
a
CI
system
yep
so
that
every
time
openshift
changes
or
get
Ops
changes
or
service
mesh
changes
or
whatever
it
is.
It's
run
through
that
CI
and
validated
hey.
It's
going
to
continue
to
work
just
like
Reed
said
it
did
before
the
change.
B
B
A
B
E
Hello
and
thanks
for
inviting
me
this
is
my
first
time
here
in
the
I'm.
Well
I've
been
collaborating
with
ultimate
for
the
past
year
and
a
half
around
service.
My
role
is
more
on
the
Consulting
end,
so
I'm
an
architect
in
the
app
Dev
space
and
I
have
been
in
the
update
space,
all
all
my
professional
life
as
far
as
I,
remember
so
I'm
on
the
application
side
and
nowadays,
obviously
try
to
understand
how
servicemas
are
also
all
the
other
cloud
services.
E
B
B
Well,
that's
awesome,
I'm,
I'm,
I,
remember
or
when
telling
me
about
it
being
published,
and
that's
super
super
awesome
and
I'm
very
happy
for
y'all
and
I
I
know
I
have
scrolled
through
it.
I
don't
understand
most
of
it
because
I
service
mesh
is
a
little
I'll
say
it's
a
little
beyond
my
normal
thing,
so
I
haven't
I,
don't
have
a
lot
of
hands-on
experience
with
it,
so
I'm
very
much
looking
forward
to
this
session
and
seeing
learning
more
about
it
and
I,
especially
like
the
in
production
aspects.
B
You
know,
there's
a
lot
of
things
that
you
know,
as
I
said
before,
right
the
difference
between
a
solution
pattern
and
a
validated
pattern
right,
hey
look!
This
is
really
cool.
This
is
something
that
I
can
do
like.
Well,
what
does
that
actually
mean
like
what
are
the
long-term
implications?
And
you
know
how
do
I
manage
and
maintain
these
things
so.
A
All
right
right
on
yeah,
so
the
the
very
first
one
is
just
a
reminder
to
everyone
that
openshift
4.14
is
going
to
be
releasing
soon
I'm,
not
exactly
sure
on
the
date.
I
think
it's
end
of
October
or
something
like
that.
But
you
know
everything
could
slide
and
so
just
take
a
look
at
the
I'll
post,
the
article
here
shortly,
but
take
a
look
at
the
the
link
and
make
sure
that
you
know
nothing
that
you've
got
running
is
going
to
be
affected
by
the
deprecations
and
then
the
open
shift
4.14.
A
B
Yep
I'll,
be
there
helping
answer
questions
shuttle
questions
between
what
we
do
on
the
live
stream
here
over
to
the
PMs
and
stuff
like
that.
So
please
do
come
out.
Listen
to
us
find
out
what's
happening
in
4.14,
there's
a
ton
of
improvements,
ton
of
changes
that
are
happening
there,
so
I
always
find
those
to
be
very
information
on.
B
So
we've
got
four
topics
in
there
leading
up
into
kubecon
the
first
week
of
November,
so
we
will
not
be
streaming
the
week
of
kubecon
and
then
I've
got
a
couple
other
things
that
we've
got
baking
in
the
background
the
ACM
folks
are
going
to
be
coming
on
in
late
November,
we'll
be
talking
about
4,
14
and
Dwayne.
I
see
your
your
question
there.
B
A
I
just
want
to
add
one
thing
about
the
the
what's
new
stuff,
if,
if
you're
watching
that
video
like
live
or
otherwise,
if
there's
something
that
you
see
that
you
want
us
to
talk
about
reach
out
to
Andrew
and
I
and
we'll
we'll
try
and
make
that
a
priority
priority,
whether
we
we
just
cover
it
briefly
or
we
do
like
a
quick
demo
on
it
or
we
do
a
whole
session.
Just
let
us
know
because
we
definitely
want
that
feedback.
B
B
A
B
I
think
that
was
that
was
really
all
we
had
just
a
reminder
so,
with
every
minor
release
of
openshift,
so
4.12
4.13
4.14,
the
the
dot
12.13.14
is
the
minor
release.
Remember
the
day
that
it
gas
is.
It
is
fully
supported
and
fully
available
to
customers,
but
the
upgrade
path
won't
necessarily
be
in
the
stable
channel.
So
the
upgrade
path
usually
on
release
day
is
in
the
fast
Channel.
It
is
fully
supported,
but
it
usually
takes
somewhere
between
45
and
60
days
for
it
to
be
promoted
into
stable.
So
that's
normal.
B
Sometimes
it
takes
longer
really
does
it
take
shorter
to
be
promoted
to
stable
because
they
go
through
and
they
do
a
lot
of
validation
and
a
lot
of
you
know
as
errors
and
issues
get
reported
as
more
people
adopt
it.
You
know
after
release
and
all
that,
so
just
keep
that
in
mind.
I
don't
know
Johnny
do
you
know
off
the
top
of
your
head?
Whether
or
not
there
is
any
SEC
changes
like
there
have
been
the
last
few
releases,
I.
Don't.
A
B
Yeah
I
know
I
think
it
was
four
four
twelve
had
the
SEC
V2
changes
and
stuff
like
that,
or
maybe
that
was
413.
One
of
those
had
some
significant
changes
that
I
know
have
caused
some
consternation
with
upgrades,
but
yeah.
Nothing,
nothing
major
this
time
like
that
yep,
yeah
and
414
is
an
eus
release.
So
you
know
the
typical
accelerated
update
or
upgrade
path
rather
will
be
available.
So
we
can
we'll
talk
about
all
that
in
more
details.
Once
we
get
closer
to
that
time,
all
right.
B
Well,
we've
We've
rambled,
we've
delayed
we've
put
off
long
enough.
Let's
talk
about
service
mesh,
so
you
know
or
when
Stelios
my
as
I
said
before
my
knowledge
of
service
mesh,
you
know
and
and
when
I
say
service,
mesh
I'm,
referring
to
this
sort
of
umbrella
term
of
you
know,
openshift
service
mesh
is
relatively
limited
right.
B
I
know
that
we
have
istio
in
there
I
know
we
have
Jaeger
right,
there's
some
other
components,
but
aside
from
you
know,
I
I
know
we
can
use
it
for
things
like
distributed
tracing
I
know
we
can
control
traffic
flows
and
stuff
like
that.
I,
don't
know
a
whole
lot
about
it,
so
if
you
wouldn't
mind,
can
you
give
the
the
you
know
dumb
guys
overview
and
dumb
guy
I'm
referring
to
is
me
of
you
know
service
mesh?
What
is
service
mesh?
Why
do
I
care
about
service
mesh?
D
C
Have
some
slides
some
some
I
would
say
introductory
slides,
which
should
partly
at
least
answer
the
things
you've
asked,
so
what
a
service
mesh
in
general
and
kind
of
the
the
core
capabilities
and
use
cases?
Why
should
I
use
this,
and
then
we
could?
You
know,
move
to
like
if
you
consider
introducing
service
mesh
in
your
company
and
it
tends
to
be
quite
complex
if
you
really
use
it
in
in
reality
right
and
there
is
a
bunch
to
consider.
C
So
there
are
different
aspects
you
could
or
you
should
gather
at
the
beginning
before
implementing
it,
and
we
walk
from
there
like
with
with
this
effective
use
case.
This
is
what
we've
also
done
in
this
ebook
kind
of
we
we've
said
like
we
have
this
company
and
they
they
have
some
requirements.
They
have
an
application
running
and
they're,
considering
introducing
service
mesh.
So
now,
what
does
it
mean?
What
are
the
requirements?
How
can
we
fulfill
them?
C
We
need
a
development
environment,
we
need
a
production
environment,
we
have
some
Partners,
we
want
to
integrate
rate
later
on.
So
there
are,
you
know
some
use
cases
and
they
kind
of
depend
on
each
other,
so
we'll
start
kind
of
building
from
a
Dev
environment
to
a
product
environment
and,
up
to
you
know,
day
two
operations
right.
So
this
is
kind
of
also
what
we
want
to
talk
today.
I
have
some
slides,
as
I've
mentioned,
not
113,
but
a
little
bit
less.
C
So
let
me
just
share
my
screen
and
we
could
just
start
with
what
service
match
is,
so
you
should
be
able
to
see.
My
screen
is
that
right
that
looks
good,
okay,
perfect,
so
yeah.
Actually,
the
title
is
heading
to
production
with
red
and
openshift
service
mesh.
So
this
is
more
or
less
the
main
topic
of
the
main
focus
for
today.
So
we
want
to
consider
some
of
the
aspects.
Of
course
not
all
in
in
detail.
I
mean
there
is
the
good
thing.
C
Is
you
have
this
book
and
you
can
also
do
everything
you
see
also
later
in
the
demo.
You
can
go
through
all
the
lab
sections
yourself.
We
have
it
internally
on
for
for
red
headers,
you
know
in
our
demo
platform,
but
there
is
also
kind
of
an
upstream
version
where
everyone
outside,
if
you
want
to
try
it
and-
and
you
know,
walk
through
the
things
we
show
you
today,
you
can
do
that
as
well.
So.
D
C
So
we
skipped
this,
you
already
know
who
we
are
so
basically
for
today,
as
mentioned.
So
what
is
service
managed
capabilities?
The
ebook
was
mentioned
already
and
then
the
main
thing
is
like
introducing
service
mesh
or
all
the
heading
to
production
topics.
We
have
a
live
demo
prepared
where
we
show
some
of
the
aspects
also
from
from
the
book,
and
then
we
have
some
day
two
operation
topics
like
tuning
and
troubleshooting,
and
also
interesting
kind
of
the
the
current
service
meshable
map.
D
C
C
C
All
the
things
I've
already
mentioned,
we
have
this
Travel
Agency
company
and
we
have
all
these
different
use
cases.
We
work
with
this
company
together
through
and
and
create
all
the
necessary
you
know,
service,
mesh,
artifacts
and
so
on.
I
I
won't
dig
deeper
into
this
right
now.
Let
us
start
with
for
especially
for
people
who
don't
know
really
what
service
mesh
is
basically
yeah.
You
could
probably
in.
D
C
Sentence
say
it
is
kind
of
a
programmable
Network
yeah.
So
we
have
a
bunch
of
microservices
and
we
add
some
user
space
proxies
as
sidecars
next
to
our
services
and
they
kind
of
intercept.
You
know
the
the
traffic
coming
to
services
and
going
out
of
service
and
it
do
something
with
them.
So
you
can
modify
the
traffic
on
kind
of
layers,
four
layer,
seven
and
there
is
a
control
plane
that
manages
all
these
proxies.
C
C
C
B
So
because
I
think
and
I'm
trying
to
think
this
is
me
thinking
of
the
cuff,
so
apologies
for
any
rough
analogies,
so
there's
effectively
with
service
mesh,
there's
effectively
three
layers
right.
So
there's
the
base
physical
networking
layer
that
each
one
of
the
openshift
nodes
is
connected
to,
and
then
there
is
some
sort
of
sdn
with
openshift
these
days
the
default
is
ovn
kubernetes.
That
creates
a
logical
Network
that
connects
all
of
the
different
nodes
together
right
and
this
is
where
pods
actually
do
their
communication
yeah
service
meshes
for
application.
B
Level
traffic
grades
pod
to
pod
communication
that
has
a
diff
additional
functionality
layered.
On
top
of
it,
the
sdn
is
typically
just
providing
connectivity
between
those
pods.
You
know
so
that
way
they
can.
You
know
leverage
a
service
or
a
route
or
something
like
that,
but
service
mesh
is
is
much
more
than
that.
C
C
Right,
complementary
I
would
say
yeah
yeah,
so
both
together
is
perfect
to
actually
Implement
something
like
a
100.
You
know
zero
trust
environment,
so
you
you
need
both
and
by
by
default.
For
example,
service
mesh
also
uses
acute
Network
policies
for
for
namespace
isolation
and
other
different
isolation
things,
but
it's
not
definitely
not
a
replacement.
It's
something
additional
and
you
know
it's
complementary.
Definitely.
C
Okay,
yeah
cool,
so
the
the
basic,
very
high
level
service,
mesh
architecture
and
I'm.
Looking
at
the
you
know
the
openshift
architecture
and
we
use
istio
right
so
istio
is
the
the
core
Upstream
project,
so
we
have
productized
istio
as
well
as
some
other
additional
projects,
Like
Jaeger,
kiali
and
so
on,
and
they
are
all
part
of
the
current
offering
of
our
openshift
service
mesh.
And
basically,
we
have
two
things:
there
is
istud
which
is
kind
of
the
core
control
plane
component.
C
It's
implemented
currently
in
one
in
one
process
and
it
offers
a
bunch
of
apis.
It
does
certificate
Management,
Service,
Discovery,
all
the
configuration
for
the
envoy,
so
everything
happens
from
this
control
plane.
So
all
the
configuration
they
will
be
translated
into
Envoy
configurations
and
will
be
distributed
to
the
sidecars
right
and
as
mentioned
there
is
this
your
cni
and
this
one
will
kind
of
modify
all
the
IP
tables
and
redirect
the
actual
traffic
to
the
invoice
and
there
we
can
now
do
what
we
need
to
do
modify
you
know.
C
Route
traffic
based
on
certain
conditions
do
rate
limiting
do
all
these
fancy
stuff
and
voy
gives
us
right.
So
this
is
kind
of
how
it
works.
This
is
a
standard
sidecar
model,
and
so
this
is
what
we
have
as
the
standard
environment
and,
additionally
in
openshift
service
mesh.
We
have
some
other
things,
for
example,
for
distributed
tracing,
so
the
envoy
proxies.
They
will
also
create
things
like
metrics.
They
create
things
like
new
traces
or
spans.
C
So
from
a
software
development
perspective,
if
you
want
to
have
distributed
tracing,
you
have
to
just
propagate
the
existing
headers.
You
know
as
you
as
you
work
with
them,
and
then
you
can
have
distributed
tracing
with
jaeger,
so
Jaeger
is
also
part
of
it.
Kiali
is
a
nice
visualization
for
openshift
service
rash.
We
will
see
some
of
the
parts
later
also
in
the
demo.
B
C
Yeah
in
general,
like
like
what
you
see
here
on
the
screen,
we
have
three
services
right.
There
is
service
ABC
and
when
we,
when
we
send
a
request
to
service
a-
and
this
is
called
service,
B
and
call
service,
c
and
d
and
whatever-
and
if
you
have
a
bunch
of
microservices
and
they
call
each
other
there
is,
there
is
kind
of
a
request
path
that
could
involve.
D
D
C
C
We
can
identify
that
this
request
from
service
B
to
service
C
belongs
to
the
origin
of
of
this
complete
request
so
in
in
this
chain
you
know,
and
we
can
make
this
visible
and
we
can
see
then,
okay,
this
service
did
call
this
service,
and
this
is
the
latency.
There
was
an
error
and
so
on
right,
so
we
can
trace
requests
which
are
pretty
you
know,
complex
and
and
in
a
long
weakness
chain.
C
B
So
Jaeger
is
capturing
all
of
those
events
as
they're
happening,
and
then
we
use
kiali
to
be
able
to
go
back
and
look
and
say:
okay,
my
application
transaction
whatever.
That
means
you
know
it
required,
or
it
did
all
of
these
microservices
and
I
can
follow
that
through
and
see.
Oh,
this
transaction
microservice.
You
know
Echo
took
47,
you
know
seconds
in
order
to
complete
whatever
it
was
doing
and
that's
why
there's
so
much
latency
in
the
application
and
then
you
from
there
you
can
kind
of
dig
in.
B
So
that's
why
the
distributed
tracing
thing
is
important
because
it
gives,
from
an
application
perspective
not
necessarily
from
a
developer
perspective,
but
whoever
is
managing
that
application.
It
gives
them
visibility
into
both
how
traffic
is
Flowing,
but
also
oftentimes
the
health
of
that
traffic
as
well.
E
Will
actually
store
it,
but
it's
actually
the
side
cut
that
will
capture
it
and
by
default
without
without
having
to
instrument
your
application
layer
with
anything
it
will
capture
traces
for
the
communication,
like
you
said,
between
the
microservices
that
they're
part
of
the
service
mess.
But
then
you
can
enhance
that
because
I
think
developers
already
do.
E
Instrument
the
microservices
for
traceability,
but
you
can
combine
as
well
so
it
could
be
that
the
like,
you
said
the
delay
is
between
Microsoft,
but
it
could
be
even
within
the
application
code
and
where
exactly
is
that,
so
the
developer
can
actually
further
enhance
and
utilize
the
same
components.
The
serverless
offers
to
further
enhance
that
traceability,
but
by
default
out
of
the
box
at
least
the
network
network,
traceability
and
the
latency,
not
retraceability,
all
the
errors
can
be
identified.
D
B
E
I
I'm
not
very
familiar
with
it,
I
think
it's
an
HTTP
3
thing,
so
I
believe
that
within
the
servicemens
you
have
effectively
the
same
capabilities,
but
you
need
to
be
part
of
that
mess
right.
You
need
to
be
part
of
the
same
mess
in
order
to
maintain
this
capabilities
of
exchange
of
certificates
for
until
this
purposes,
but
I'm
not
100,
familiar
with
how
a
quick
sec
would
actually
material
materialize
that
so,
yes
to
an
extent
within
the
mass
for
cross
cross
by
crossing
the
boundaries
of
the
mess.
C
Okay,
we
we
are
here,
architecture
and
the
way
you
manage
the
different
components
are
basically
we
we
have
an
operator.
This
is
also
the
standard
way
you
install
openshift
service
mesh.
So
there
is
one
service
mesh
operator,
and
then
you
also
use
the
existing.
You
know
elasticsearch
or
Jaeger
operator,
so
you
install
kind
of
four
operators
and
then
you
basically
work
with
custom
resources
so
for
installing
the
control
plane
and
configuring
the
control
plane,
you
use
currently
a
service
mesh
control
plane,
a
crd,
so
it
is
the
smcp
abbreviated.
C
This
is
as
of
now
and
then
for
configuring.
You
know
the
envoy
proxies
you
use,
also
standard,
kubernetes,
custom
resources
or
istio,
better,
say,
SEO,
custom
resources
like,
for
example,
here,
Gateway
virtual
Services
destination
rules
and
the
different
authorization
policies.
Things
like
this,
so
This
Way.
You
basically
configure
your
mesh
and
the
control
plane
yeah.
So
we
already
talked
about
this.
The
the
service
to
service
communication
with
them
with
within
the
mesh
is
through
the
Envoy
proxies.
They
form
kind
of
the.
C
You
know
the
data
plane
of
of
the
mesh,
and
then
we
have
for
external
interfacing
or
interfacing
external
Services.
We
have
Ingress
and
egress
gateways
if
you
want
to,
for
example,
if
you
have
a
web
application,
you
want
to
let
traffic
outside
of
the
mesh
in
to
to
inside
the
mesh.
You
will
use
an
Ingress
Gateway
and
combine
it
with
a
virtual
service
and
destination
Rule
and
configure
kind
of
the
Ingress
into
your
mesh,
and
you
can
do
the
same
thing
with
egress
gateways.
C
Both
things
are
more
or
less
Standalone
envoys,
so
they're,
not
sidecars
they're,
just
Standalone
envoys,
and
you
can
also
have
multiple
ingresses
and
also
you
know
in
different
namespaces.
You
can
deploy
it
alongside
with
your
applications
and
their
different.
Let's
say,
topologies
how
you
could
set
them
up.
C
E
It
is
applying
Network
policies
in
the
background,
and
so
as
a
as
an
effect
of
that
you
need
an
Ingress
or
an
egress
Gateway
in
order
to
access
what's
inside
the
message,
unless
of
course,
you
relax
the
default
policies.
So
at
least
hopefully
that's
a
bit
clearer
for
the
people
that
they
didn't
know
how
this
gets
implemented.
It
is
using
network
policies
and
it
is
using
the
Ingress
inigas
in
order
to
bypass
that
and
allow
traffic
into
them.
C
A
E
A
A
And
then
my
question
is
more
of
a
kind
of
like
implementation
like
I,
guess
not
really
implementation,
but
when
you're
thinking
of
a
big
picture,
what's
the
overhead
of
running
the
service
mesh
with
the
the
multiple
Envoy
proxies
and
stuff
like
that,
so
you
know
like?
Is
there
like
a?
Is
there
a
calculated
hit
that
you're
going
to
take
or
is
it?
Is
it
so
minimal
that
we
don't
really
care
like
do
you
have?
Do
you
have
like
some
of
those
numbers.
C
C
E
Is
going
to
talk
about
a
number
of
use
cases
so
I
when
I
read
the
word
foundation
I,
it
comes
to
mind
that
there
is
one
thing
in
place
and
we
ServiceMaster
Records.
Office
Solutions
is
a
productization
of
the
istio
project
and
effectively
there's
a
few
use
cases
that
it
still
covers,
and
one
part
is
the
networking.
Another
part
is
the
security,
the
observability.
E
So
the
main
aim
is
to
extract
product
capabilities
that
you
want
to
have
without
having
to
re-implement
them
in
every
micro
service
or
need
to
provide
it
as
part
of
every
platform
and
but
have
it
out
of
the
box
as
part
of
the
service
mess.
That
would
be
more
or
less
my
answer
to
this
question.
If
I
understood
what
Foundation
means
in
this.
C
So
just
one
thing
I've
already
mentioned
this
is
our
you
know
openshift
kind
of
cake
diagram
where
we
have
like
our
product
portfolio
in
terms
of
openshift,
and
you
see
the
service
mesh
is
part
of
the
platform
Services.
Here
it's
one
of
the
layered
products
like
serverless
or
CI,
CD
pipelines,
githubs,
and
you
can
install
it
as
mentioned
with,
with
an
operator,
no
additional
costs.
C
C
We
have
later
on
also
a
section
in
in
terms
of
personas
that
we
typically
identify,
but
in
general,
and
this
really
reflects
kind
of,
or
what
we
see
in
reality
is
that
most
of
the
time
the
people
who
actually
really
maintain
operate
and
configure
a
service
mesh
are
actually
platform,
Engineers
or,
let's
say
more
admin,
people
and
basically
people
who
you
know,
operate
application,
environments
and
and
care
about
them.
So
they
do
like
they.
They
configure
the
application
Behavior
they
enforce,
for
example,
mtls
encryption.
They
use
other
security
features
they
configure
resiliency.
C
For
you
know
for
for
the
applications,
and
especially
for
networking
related
stuff,
they
can
also
configure
traffic
management
and
a
b
testing,
usually
things
that
they
work
together
with
actual
developers,
are
more
or
less
for
resiliency
feature,
because
in
the
past
you
usually
it
was
the
the
actual
developer
who
implemented
with
resiliency
features
right
and
now
you've.
We
shifted
this
this
topic
completely
to
this
infrastructure
layer
to
to
service
mesh.
So
basically
the
way
developers
use
it.
C
C
You
know
certificates
and
encryption
and
retry
Logics
and
implementing
some
kind
of
circuit,
breaker
and
all
of
that
stuff
which
they
had
to
do
in
the
past
or
without
using
a
service
mesh.
So
they
can
really
focus
on
business
logic,
and
we
can
configure
this
one
with
the
central
interface
you
know
in
this
infrastructure
layer,
so
this
is
kind
of
what
we
also
see
in
reality.
Stelios
from
your
experience,
you're
you're,
the
one
in
the
field
you're
implementing
or
you
had
a
lot
of
customers
where
you've
implemented
service
mesh.
C
E
Yeah
so
yeah
I
agree
that
platform
Engineers
are
the
main.
The
main
part
is
that
they
use
that
the
other
side
of
a
usage
depending
on
the
environment,
and
so,
if
we're
talking
about
development
environment,
we
see
quite
often
the
application
teams
using
some
components
of
it,
especially
the
observability
stack,
but
also
depending
on
the
customer,
depending
on
what
other
tools
are
available.
We
also
do
see
the
product
owners
as
well,
because
part
of
the
observability
can
give
you
information
about
the
usage
the
healthiness.
E
So
we
also
see
these
type
of
users
in
the
the
interest
of
delivering,
obviously
a
solution
on
top
of
the
services
we
do
have
the
application
teams
involved,
but
depending
on
the
organizational
structure,
they
may
Implement
their
own
data
plane
configurations
or
they
may
rely
on
the
platform
Engineers
to
implement
them
for
them
or
or
with
them,
but
yeah
platform.
Engineers
is
the
correct
Persona
and
within
the
organization.
D
C
C
A
C
D
C
Know
yeah
generate
certificates
and
does
end-to-end
encryption
at
scale.
So,
as
mentioned,
each
worklet
has
a
unique
ID
and
it
automatically
creates
certificates,
distributes
them
to
the
envoy
proxies
and
they
are
also
rotated.
You
can
also
integrate.
This
is
GA
right
now
you
can
integrate
with
your
corporate
issuers
like
like
hashicorp
Vault,
so
cert
manager
is,
is
also
GA
in
this
context,
and
the
other
use
case
or
main
thing,
there's.
E
E
E
This
is
something
that
we
are
considering
as
a
use
case
for
the
services
from
an
implementation
from
a
delivery
perspective
from
my
side,
but
I
think
we
need
some
other
components
that
will
help
us
to
exactly
yes,
like
Scupper,
to
to
combine
with
this.
We
have
in
Labs
ourselves
as
delivery
team
employed
and
creative
proof
of
Concepts
around
this,
but
we
have
yet
to
see
that
on
the
edge.
But
it
is
a
use
case
that
we're
working
on
and
when
we
have
more,
maybe
we'll
come
back
and.
B
We'll
talk
about
so,
if
I'm,
if
I'm,
interpreting,
if
I'm
reading
between
the
lines
here
so
the
problem
is
the
expectation
is
for
a
far
Edge
device
or
endpoint
to
be
not
a
part
of
the
same
cluster.
So
typically,
the
service
mesh
would
not
extend
outside
of
the
cluster
or
incorporate
other
clusters
inside
of
it,
without
something
like
Scupper
to
act
as
that
connection
point
between
each
one
of
them
got
it
so
short-term,
probably
not
long-term.
Maybe
it.
E
A
B
B
C
It
that
was
very
important,
yeah,
okay,
cool
the
other
thing
was
monitoring
observing
one
of
the
other
capabilities.
Also,
as
mentioned,
we
we
have
the
proxies
in
place,
and
so
they
can
give
us
a
full
visibility
of
all
the
traffic
running
through
or
flowing
through
the
park
through
the
proxies.
So
we
have
metrics
where
we
can
see
like
the
request
volumes
failure
rates.
C
All
of
that
then
we
have
distributed
tracing
to
identify,
you
know
bottlenecks
and
we
have
the
additional
products
and
tooling
around
it,
which
is
bundled
currently
with
openshift
service
mesh,
and
we
will
see
this
also
later
just
this
use
case
alone.
If
you
have
an
application
with
a
bunch
of
microservices,
it
might
be
worth
to
just
use
service
mesh
for
observability
that
you
get
really
insights
and-
and
you
see
what's
happening
between.
D
C
C
You
can
do
it
without
source
code
changes,
and
this
is
the
the
real
benefit,
because
that
was
something
that
you
usually
had
to
implement
in
your
microservice
and
you
had
to
implement
different
libraries,
maintain
them
and
things
like
this
and
now
you
have
just
the
service
measure
and
you
can
configure
things
essentially
so
resiliency
one
thing
and
then
in
terms
of
releasing
Services
all
the
traffic
flow
and
traffic
management.
You
can
do
a
bunch
of
different
deployment,
topologies
or
types
like
Canary
deployments,
AP
testing.
C
You
can
mirror
traffic
also,
for
example,
from
your
production
environment.
You
can
mirror
traffic
even
in
a
different
cluster.
You
can
Federate
also
different
service
meshes
in
different
clusters
and
Export
Services
things
like
this
yeah
mirroring
traffic
testing,
your
new
services
against
live
traffic
yeah
all
these
routing
and
traffic
range
capabilities.
So
these
are
basically
the
four
main
capabilities
of
a
service
mesh,
not
only
openshift
service
mesh
in
general.
E
C
E
B
A
So
yeah,
it's
kind
of
cool
I
think
there's
a
limitation
right
now
with
routes
and
in
the
integration
with
with
Ross,
just
because
it's
so
fairly
new
but
I'm
excited
to
see
it
to
see
it
happen
and
to
see
that
you
can
actually
do
it
in
a
completely
different
platform
and
hopefully
haven't
seen.
The
search
is
pretty
awesome.
A
C
That
was
really
a
little
bit
just
yeah
introduction
and
core
capabilities,
and
now
we
start
a
little
bit
with
thinking
about
how
to
introduce
service
mesh
in
your
company.
If
you
consider
using
it,
if
you
think
these
are
great
capabilities
and
it
would
make
sense
what
should
I
what
topic
should
I
care
about,
and
here
we
can
start
with.
You
know,
discovering
navigating
the
service
mesh
needs,
so
Studios
yeah.
E
E
I
just
wanted
to
highlight
that,
because
of
the
complexity
and
because,
obviously
of
the
different
use
cases,
it
is
difficult
to
identify
easily
what
what
one
It
capture,
what
requirements
do
I
need
to
capture-
and
one
thing
obviously
to
take
him
into
consideration-
is
that
some
of
these
capabilities
that
we
talked
about
they're
already
part
of
either
the
application
component.
The
development
team
has
integrated
them
in
the
application
governance
or
they
are
part
of
the
platform.
So
we
already
have
kind
of
the
requirements
that
you
know
we
are
asking
of
servicemas.
E
We
just
need
to
understand
what
are
the
features
that
we
need
implemented
as
I
said
this
part
of
applications
and
then
look
at
maybe
this
Atlas
to
identify
more
focused
areas
of
caption
requirements.
So
in
summary
and
I'm
not
going
too
much
digital
is
the
the
deployment
model
so
how
we
deploy
the
service
mess
and
that
gets
affected
by
the
openshift
type
classes.
That
we
deploy
I'll
talk
about
in
the
next
slide,
a
little
bit
about
that
the
the
tenancy
models.
So
will
we
have
effectively?
E
E
Obviously
we
are
running
the
services
on
in
order
to
support
a
data
plane
of
microservices,
offering
a
solution
either
a
streaming
service
or
you
know
it's
a
normal
service
and
we
just
need
to
cater
for
the
performance
from
a
control
plane
in
order
to
support
the
database.
So
we
need
to
capture
what
are
these
requirements
like
I,
think
Johnny
asked
earlier
about
latency
throughput
and
the
likes
then?
E
There
may
be
true
that
we
need
to
integrate
with,
so
we
need
to
capture
comments
about,
what's
not
there
or
what's
there
and
what
we
need
to
integrate
with
and,
of
course,
security,
always
a
big
Topic
in
order
to
understand
what
are
corporate
standards
and
how
we
can
Implement
and
comply
with
them
with
service
mess,
and
also
what
are
security,
authentication
authorization
standards
that
we
need
to
assist
so
capture.
All
these
requirements
in
this
Atlas
is
for
that
purpose.
E
In
an
open
cluster
needs
to
be
part
of
the
service
mesh
will
be
isolated
from
anything
external
to
it.
So
we
need
to
understand
that,
and
also
we
need
to
equally
understand
what
other
types
of
isolation
are
in
place
without
the
servicemen.
So,
for
instance,
maybe
the
solution
is
split
over
multiple
clusters
or
there
is
a
different,
hosted.
Network
definition,
when
we
understand
that
then
we
look
at
is
the
oppensive
cluster
that
will
deploy
the
service
missing,
configure
and
maintain
it
a
dedicated
cluster.
E
Whilst
in
a
multi-domain
cluster,
we
might
consider
to
have
a
single
control
plane
or
there's
a
red
hat,
open
service
feature
of
multi-tenancy,
where
we
can
have
side
by
side
the
control
planes
for
the
different
business
units
isolating
the
client
applications
within
the
same
cluster
from
each
other.
This
is
on
the
network
level
isolating,
and
there
can
be
many
reasons
for
deciding
one
over
the
other.
There's.
No
one
solution
answer
for
everything.
E
For
instance,
we
identified
some
time
ago
that
having
a
single
control
plane,
although
it
was
easy
for
management
perspective
for
configuration
management
perspective,
it
was
causing
an
issue
when
there
was
a
very
large
set
of
microservices
ports.
I
think
we
would
say
kind
of
some
500
plus
we
found,
and
that
was
causing
an
issue
on
the
easy
of
this
service
of
the
control
plane.
Now
this
this
was
fixed
on
the
latter
version
of
the
product,
but
then
again
having
such
a
large
single
mesh
meant
that
every
configuration
like
ortwin
said
from
every
side
guard.
E
That
is
basically
your
entry
and
exit
point
from
the
mesh
you
had
to
share
with
all
the
other
micro
Services
we're
talking
about
500,
you
know
thousand
whatever
it
is
10
000
in
your
in
your
cluster
and
that
was
creating
a
very
bloated
sidecar,
sometimes
actually
require
more
memory
than
the
business
workload.
So
again,
going
back
to
having
multi-tenancy
with
multiple
control.
Planes
would
solve
this
because
you
have
a
much
more
dedicated
control
plane,
much
more
dedicated
isolation
through
that
deployment
model
for
your
microservices.
C
Also
in
order
to
add
here
Studios
also,
you
know
if
you
have
like
one
one
control
plane
and
you
have
really
a
lot
of
namespaces
or
you
know,
domains
that
that
are
managed
there.
This
creates
actually
also
a
bunch
of
API
traffic
load
on
the
cube
side
right,
so
you
have
to
take
care
and
it's
good
to
know
what
what
kind
of
structure
type
your
application
is,
and
also
to
to
then
kind
of
decide
for
the
right
service,
mesh,
topology
right.
E
Exactly
and
the
other
area
of
focus
when
bringing
something
to
bring
your
service
and
implementation
to
your
solution
into
your
clusters,
the
model
of
operation-
and
this
time
we
use
to
determine
effectively
who
is
involved
in
the
configuration
deployment
and
maintenance
of
a
service
mass,
and
you
think
that's
quite
easy.
We
mentioned
the
platform
engineering
earlier,
but
it's
not
always
as
simple
as
that,
because
maybe
they
are
the
ones
implementing
some
of
the
configurations.
E
But
since
the
service
business
is
not
deployed
for
a
pure
platform
concern
and
it
cannot
be
agnostic
of
what
you
will
Deploy
on
it.
So
we
need
to
get
advice
from
the
application
site
on
on
what
that
is,
and
the
problem
gets
exacerbated
when
you
consider
the
different
roles
that
can
be
involved.
Let's
say
the
platform
means
the
devsecops
team,
so
the
dev
teams
we
need
to
take
input
from
all
of
them.
So
the
conclusion
is
that
effectively
we
can
look
at
maybe
four
aspects
in
order
to
understand
for
that
specific
service
mess.
E
E
And
the
final
thing
I
want
to
say
about
this
is
effectively
you
come
to
the
conclusion.
You
need
to
come
to
conclusion
also:
what
are
the
personas
that
operate
the
mess?
This
is
a
list
of
the
most
common
ones
we
see
in
every
organization
and
when
we
say
personas
may
be
a
person,
a
real
person
combines
a
Persona
in
your
organization,
but
as
roles
we
usually
find
them.
You
know
available
and
and
to
work
with
or
work
on
the
service
mess
in
most
of
the
organizations.
So
I'm
not
going
to
go
through
it.
B
E
Yeah
you
can
and
the
realities
as
I
said,
there's
no
one
organizational
structure,
you
just
need
to
identify
and
understand
it,
because
the
problem
is
Eastern
by
extension.
Service
does
not
define
standard
or
default
rules
about
this,
and
so
every
project
team
needs
to
understand
and
implement
this
for
themselves.
So
hopefully
this
is
giving
people
some
food
for
thought
on
how
to
do
that,
because
it
can
create
friction.
It's
not
a
application
concern.
It's
a
platform
concern
in
fact,
Action
Service
taxes,
Network
Security
application
and
platform
concerns.
E
A
E
You
all
right
so
yeah
some
demo
time,
so
we've
got
and
we've
got
a
demo
with
we
prepare
there's
it's
basically
based
on
a
workshop,
and
the
workshop
is
also
it's
done
from
the
actual,
the
the
ebook
that
we
talked
about
and
there's
a
link
there,
and
this
link
basically
gets
you
to
a
a
GitHub
repository
under
the
writer
developer
demos
and
that
will
allow
you
to
go
through
the
workshop
as
a
single
user.
Doing
all
the
things
from
capturing
their
comments.
E
Obviously,
for
this
fictitious
use
case
to
developing
deep
sorry,
deploying
those
corporate
personal
responsibilities
and
and
permissions
in
the
open
shift,
delivering
a
development
environment,
utilizing
the
observability
stack
and
going
all
the
way
to
production
setup.
For
that
use
case
and-
and
here
there's
a
number
of
modules
that
we
say
you
go
through
so
Moto
6.
Actually
it's
a
in
the
in
the
actual
GitHub
is
three
modules.
E
You
end
up
actually
looking
at
performance
tuning
and
troubleshooting
in
production,
so
Motors
one
to
five
is
getting
you
to
go
to
production
with
different
considerations
such
as
you
know,
having
a
stable
environment
in
production.
Where,
if
things
go
down,
you
don't
lose
your
traces,
so
persistence.
Also
the
policies
are
around
the
authorization
policies
of
you
know,
which
microservice
can
we
can
talk
to
which
microservice
it
also
splits
I
think
the
next
slide
so
maybe
actually
going
ahead
of
what
we
have
in
the
slides.
E
It
actually
consists
of
splitting
like
in
a
real
situation
the
into
two
domains
so
the
same
service,
but
actually
there's
two
teams
and
that
they
are
operating
on
it,
which
is
not
uncommon.
You
know,
and
usually
when
we
started
this,
we
used
to
say
you
know,
there's
one
team
and
they're
responsible
for
the
data
plan.
There's
another
team
that
is
responsible
for
the
platform.
The
AL
is
not
like
this.
You
know
the
the
the
data
plane.
E
C
Basically,
this
is
this
effective,
Travel
Agency
company
right,
so
we
have
some
travel
portals
here,
which
is
basically
you
you
can
book
travels
right,
so
the
right
side,
the
travel
and
services
domain.
There's
the
central
travels
API
with
we
have
some
other
microservices,
where
you
can
book
flights,
hotels,
cars,
so
there's
one
team
with
different
roles:
managing
those
travel
Services
domain,
there's
one
team
also
with
different
roles
for
the
travel
shop
domain,
and
so
the
the
requirement
is
like
we.
We
have
some
requirements
here
like,
for
example,
for
example.
C
C
We
want
the
teams
to
work
in
isolation,
so
we
want
to
also
Implement
with
openshift
rbac.
You
know
the
different
roles
so
that
when,
when
a
certain
role
logs
into
kiali-
or
you
know,
openshift
only
sees
their
domain
and
is
allowed
is
not
allowed
to
apply
certain.
You
know
configuration
of
istio
and
all
of
that
and
we
have
some
sample
requirements
here
like,
for
example,
we
want
to
collect
five
percent.
C
E
A
While
you're
doing
that,
I
just
want
to
call
out
like
I
think
that
that
demo
is
awesome
right
because
you're
teaching
people
how
to
think
about
what
they're
incorporating
right,
like
you're
you're
showing
people
like
hey,
look,
if
you
want
to.
If
you
want
to
do
this,
here's
the
things
that
you
need
to
think
about,
and
here's
how
you
can
think
about
it
and
and
take
that
knowledge
in
and
then
apply
it
so
I
I
as
soon
as
I
saw.
Oh
man,
I
I,
love
that
a
lot!
That's
awesome!
A
E
E
It
should
be
clear
to
people,
but
it
tries
to
go
beyond
the
basic
stuff
and
you
know
try
to
Showcase
and
and
said
you
know
in
in
in
the
ebook
and
here
in
the
presentation
we
talk
also
about
tuning
and
troubleshooting,
which
is
you
know
very
important.
You
know
if
some
something
will
always
go
wrong,
so
you
need
to
know
how
to
to
look
into
it
when
you're
using
service
mess
so
yeah.
E
D
E
Yeah
all
right
cool,
so
this
is
kiali,
and
this
is
part
of
the
observability
stack
and
in
this
Workshop
we
have
two
chialis.
Let's
say
one
for
the
development
and
one
for
the
production
environment
and
if
I
remember
correctly,
this
is
for
the
development
environment
and
effectively
I've
logged
in
as
this
person,
Emma
and
Emma
is
the
mesh
operator.
So
as
a
mess
operator
actually
I,
it
has
the
capability
to
to
look
at
both
the
control
plane
and
the
data
planes.
E
It's
actually
got
the
visibility
of
all
the
namespaces
in
in
the
Kia
lab
actually
selected.
All
of
them
I
can
actually
deselect
them
and
then
I'll
get
nothing
here.
I
might
be
interested
only
in
the
dev
portal,
in
which
case
I
would
look
at
microservices
that
are
in
Dev
portal,
this
three
and
they
can
communicating
with
something
in
the
travel
agency.
So
I
can
maybe
minimize
the
visibility
here.
If
I
wanted
to
look
at
something
specific
but
effectively
yeah,
let's
say
Emma
wanted
to
see
absolutely
everything.
E
E
D
E
You
can,
if
you,
if
you
just
find
so
that
you
can
even
you
know,
kind
of
get
an
animation
of
you
know
the
traffic
flowing
from
microservice
to
microservice.
So
you
have
a
number
of
things
visually
to
understand
very
quickly.
Is
there
a
problem
now
you
can
also
reduce
the
time
of
how
often
this
this
and
diagram
gets
refreshed
it.
E
It's
important
to
understand
that
the
metrics
and
the
traces
that
it's
captured
by
the
sidecar
is
what's
creating
this
okay,
so
we
can
look
at
every
10
seconds,
a
refresh
of
the
latest
traces
of
the
latest
metrics
in
the
visual
manner.
But
beyond
that,
then
you
can
also
go
a
little
bit
more
and
look
at
the
Easter
configurations
now
I'm
just
going
to
take
out
the
istio
system.
This
new
system,
basically,
is
the
control
plane
at
namespace
and
the
other
three
are
the
data
plane.
E
This
is
where
our
microservices
and
their
sidecars
are
deployed,
and
you
can
see
here
also
what
configurations
you
have
applied,
so
you
can
see
in
my
service
mess.
Maybe
these
three
namespaces
are
specific
for
the
solution
of
the
travel
agency.
Maybe
my
service
has
other
namespaces
as
well,
but
if
I
wanted
to
just
look
at
these
three
namespaces
and
I
can
see
you
know
what
are
my
SD
configurations?
What
are
the
services
that
they
are
part
of
it?
Okay,
I
can
look
at
my
workloads
now
I'm
the
operator,
so
I
can
see
many
things.
E
So
if
I
go
here,
I
can
see
the
logs
and
everything
else.
However,
like
we
said
in
this
particular
situation,
we
have
two
teams,
the
agency
team
and
the
portal
team,
and
so
these
two
teams
deliver
both
configurations
and
microservices
in
them
in
the
different
name
spaces.
So
if
I
take
a
different
role,
okay,
so
if
I
log
out
and
say
if
I
remember,
correcting
all
the
rules,
we
have
Christina,
who
I
believe
is
the
portal
domain
owner?
E
And
here,
as
you
can
see,
we
can
see
the
microservices
from
the
portal,
but
we
can't
see
the
micro
services
from
the
travel
agency.
So
this
this
is
the
application
domain
owner
who
delivers
configurations
and
delete
for
the
service
message
for
this
particular
part
of
the
solution,
and
although
they
can
see
that
you
know,
my
solution
is
talking
to
something
else.
It's
important
to
know
the
internet
and
intra
Integrations
with
other
things.
I
can't
see
here
things
around
the
logs
I
can't
see
the
configurations
and
I
can't
actually
manage
them
either
right.
E
So
if
I
was
to
go
through
the
through
the
istio
config
to
modify
them,
I
can
only
modify
what's
in
my
domain
in
my
namespace,
and
this
is
applied
based
on
the
roles
and
responsibilities
we
identified
earlier
and
the
permissions
we've
applied
for
that
group
to
only
be
able
to
apply
and
and
do
things
for
those
namespaces.
So
in
that
case
I
can
you
know
I
can
go
in
and
I
can.
D
E
Okay,
so
maybe
I'm
not
actually
able
to
see
in
the
control
namespace,
but
I
can
see
in
the
portal
name
space,
because
my
team
is
responsible
for
delivering
these
computers.
So
you
you,
you
also
reduce
the
the
sensitivity
of
you
know
who
can
access
what
what
they
can
see
with
with
the
with
the
kyali?
So
that's
the
overview
now.
Let
me
actually.
E
This
because
I
don't
remember
now
the
password,
so
you
can
see
that
password,
but
it's
okay,
because
it's
only
short
term
environment,
hopefully
I
can
log
in
so,
let's
see
also
what's
on
the
control
plane,
because
this
was
about
the
data
plane.
So
in
the
control
plane,
this
is
the
production
environment.
As
we
talked
about
earlier,
we
can
have
a
number
of
different
things.
We
can
have
the
egress
gateways
and
we've
deployed
here
the
the
control
plane
with
two
Eagles
gateways
for
production.
So
that
means
you
know.
E
We
have
high
availability
if
one
disappears
and
the
same
for
the
Ingress
Gateway
we've
also
got
two
Easter
D
services.
What
does
the
Easter
this
service
do?
Is
maintaining
up-to-date
configurations
for
the
sidecar
proxies
the
ones
that
basically
intercept
the
traffic
in
and
out
of
your
microservice
in
Ms
and
also
apply
updates
to
the
and
the
certificates
used
for
mtls
so
basically
maintains
the
whole
of
the
data
plane
up
to
date
with
the
latest
configurations,
and
so
you
don't
have
to
go.
E
E
Dcd
service
will
look
at
the
configuration
applied
and
apply
them
in
the
right
and
in
the
right,
sidecar
proxy,
and
actually
one
I'm
going
to
go
back
here,
because
one
of
the
important
things
I
forgot
to
mention
is
that
you
can
see
the
envoy
configurations
here
on
the
kiali.
So
this
is
a
list
of
all
the
configurations
and
hence
why
I
was
talking
about
that.
It
can
get
very
big
ones.
E
So
you
have
many
microservices
out
of
the
mesh
that
you
can
see
effectively
the
Clusters
or
the
destinations
that
you
can
set
traffic
to
in
the
mess.
You
can
see
different
listeners
that
you
expose.
You
can
see
Roots
configurations
through
virtual
Services
applied,
and
you
can
also
look
in
very
detailed
overall
configuration.
So
this
is
basically
what
the
issue
did
Will
inject
in
each
of
the
sidecasts,
so
they
know
how
to
communicate
with
each
other.
They
know
what
are
the
limits
if
there
are
limits,
what
are
the
security
configurations?
E
And
that's
done
through
the
Easter
day
and
hence
the
more
microservices
you
have
in
the
in
the
data
plane
you
need
to
manage.
Maybe
the
overall
service
is
more
STDs
in
order
to
have
a
performance
control,
plane,
Prometheus.
Obviously
it's
for
metrics
capturing
grafana
for
visualization
some
dance
dashboards.
I
can
actually
look
at.
E
E
E
So
you
know
the
the
CPU
used
in
the
and
and
also
based
on
the
component
version
as
well.
I
can
also
look
at
the
and
more
specific
information
for
my
services
right,
so
I
can
look
at
operations
for
that
microservice
I
can
also
look.
You
know
the
client
workloads
incoming
requests
or
the
size
of
the
so
more
and
more
details
can
be
extracted
from
the
grafana
based
on
the
metrics
that
has
been
captured
and
yeah.
So
I
think
I
think
these
are
the
main
components.
E
But
without
having
to
you,
know,
implement
this
ourselves.
We
rely
on
the
other
operators
themselves.
So
this
is
the
operator,
and
this
is
the
control
plane
that
Orton
mentioned
earlier.
So
you
can,
as
you
can
see
here
in
my
cluster
I've,
got
three
different
droplets,
so
I'm
utilizing
a
multi-tenant
cluster
in
this
multicend
cluster
I
have
segregated
the
configurations
and
the
traffic
in
three
different,
distinct
areas.
So
I
have
a
user
one,
because
it's
a
multi-tenant,
the
dev
environment
and
user
one
production,
so
I've
set
up
a
Dev
environment
in
a
production
environment.
E
For
this
solution
was
the
user.
2
is
currently
only
having
a
development
environment
and
the
control
plane
output,
whether
you
have
one
Ingress
Gateway,
two
English
gateways,
whether
you
have
persistence
in
your
Jaeger
and
the
likes
is
defined
based
on
the
serviceman's
control,
plane,
CRT
and
the
operator
will
deliver
the
relevant,
the
relevant
deployments
for
the
service
mess
and
the
relevant
configurations.
E
So
that's
the
workshop.
That's
what
you
end
up
working
on
now,
the
there
are,
as
I
said,
you
know
many
areas
of
it,
so
we
go
through
also
how
you
can
change.
So
we
talk
about
mtls,
so
we
we
go
through
how
you
can
change
the
mtls
certificate
in
your
in
your
control
plane,
so
that
control
link
components
can
utilize
a
corporate
or
intermediate
corporate
certificate
and
the
same
thing
for
the
for
the
data
plan
in
order
to
produce
the
certificates
that
they
used
in
the
communication
services
and
encrypt
that
communication
end-to-end.
E
Yeah,
so
maybe
I'll
just
go
through
the
production
walk
through
a
little
bit.
So,
as
I
mentioned
earlier
in
the
production
setup,
we
have
a
Jager
installation.
This
is
a
separate
operator
managing
the
the
Jaeger
and
we
utilize
elastic
search
for
supporting
based
on
these
requirements.
That
old
twin
showed
earlier
seven
days
back
up
of
the
traces.
E
So
if
things
go
wrong
and
the
Jager
instance
disappears
we're
not
losing
our
traces,
we
basically
have
a
backup
of
it
and
we
utilize
that
Jaeger
effectively
within
the
service
mesh
control
plane
where
we
sample
well
in
this
case
I
think
we
start
with
20.
Eventually
we
La
we
reduce
that
to
five
percent
and
we
also
utilize
something
called
the
outbound
policies.
So
the
service
mess
not
only
isolates
the
traffic
for
the
incoming
requests,
but
also
you
can
isolate
for
external
requests.
D
E
What's
registered
in
the
mess
to
be
allowed
as
an
outbound
policy,
and
that
means
you
need
to
Define
effectively
a
traffic
configurations
in
the
service
mess
through
virtual
service
and
destination
rules
which
would
allow
you
to
come
out
of
the
mess
and
go
to
the
database
and
that
that
can
then
be
applied.
Based
on
the
policy,
you
know
who's
allowed
to
to
Define
this
network
configurations.
So
that's
another
thing
that
you
can
do
with
a
mess.
E
E
So
a
couple
of
final
things:
I
want
to
talk
about
the
production
environment
and
what
you
can
do
with
it,
and
this
is
part,
as
it
says,
they're
part
of
the
chapter
8
of
The
Tuning,
the
services
on
inbook.
It's
important
to
be
aware
of
what
you
can
and
should
monitor.
There's
many
things,
there's
many
metrics
that
you
can
monitor,
but
if
I
was
to
give
a
very
quick
suggestion
to
people
on
on
what
you
can
monitor
on
the
data
plane,
there's
a
couple
of
metrics
so
is
the
request.
E
Total
basically
means
you
look
at
the
the
number
of
requests
that
come
in
and
I
just
realized.
I've
copy
pasted
the
wrong
metric
for
the
latency
I'll,
find
this
and
and
and
change
it
in
the
final
presentation
and
there's
another
metric
for
the
for
the
latency.
So
these
two
metrics
gives
you
very
quickly
an
understanding.
E
If
my,
if
I
put
my
solution
in
the
service
mess,
do
I
get
the
same
number
of
requests
as
I
would
without
so
you
can
kind
of
you
know,
compare
and
contrast
and
the
same
thing
for
the
latency
do
I
get
a
very
bad
latency.
Do
I
need
to
tune
against
that?
Let's
see,
is
that
acceptable
and
for
the
control
plane
side
which
manages,
as
I
said,
the
configurations
in
datably
inside
there's
the
pilot
XDS,
which
shows
you
how
many
components
on
the
data
plane
are
connected
to
that
STD
that
manages
their
configuration.
E
Obviously,
the
as
you
increase
the
the
data
plane
side.
That
number
will
increase
and
then
the
pilot
proxy
convergence
time.
It
actually
shows
you.
How
long
does
the
HD
take
in
order
to
update
the
sidecars
on
the
data
plan
and
that
shouldn't
be
more
than
a
few
milliseconds
and
if
you
see
that
to
be
increased,
so
that's
that's
another,
like
you
know
thing
you
can
apply
on
the
Prometheus
and
you
can
create
an
alert
with
it.
If
you
see
that
actions
at
convergence
time
increasing,
then
you
might
need
to
make
some
suggestions.
E
E
So
you
know
you
probably
need
to
look
at
things
when
things
go
wrong
and
you
need
to
look
at
at
least
these
first
10
things
is
the
istio
network
configurations
exactly
valid,
and
you
can
see
that
actually
straight
away
in
kiali
right,
you
can
see
that
there's
a
configuration
that
is
wrong
here.
There's
like
an
icon
on
the
right
hand,
side
that
red
thing
that
says
something
is
wrong
and
you
can
kind
of
see.
E
Okay,
maybe
that's
something
wrong
with
my
syntax
there
and
also
does
the
network
of
us
have
an
error
or
a
warning
status
set?
Is
the
resource
the
right
name,
many
of
many
times
we've
seen
the
configurations
are
being
slightly
wrong,
which
meant
the
service
mess
did
not
well
apply
them,
but
had
no
way
to
understand
that
this
configuration
should
not
have
been
applied.
So
you
need
to
make
sure
that
these
configurations
are
correct.
The
resources
correct
the
the
labels
are
correct,
the
selectors
and
then
did
the
envoy
accept
the
configuration.
E
So
you
can
utilize
the
tool
called
istioctl
analyze
and
it
will
actually
give
you
an
understanding
of
you
know
if
there's
any
warnings
if
the
envoy
has
accepted
and
so
on
so
and
finally,
I
think
I've
got
also
here
another
one
to
kind
of
show
you
about.
You
know
whether
it's
been
accepted
or
not,
and
you
can
see
here
something
was
not
sent.
So
this
is
your
CTL
tool
actually
helps
you.
E
E
C
A
C
C
Match
roadmap
we're
currently
at
2.4
so
which
is
based
on
istio,
116
and
kiali
165,
and
what
we
have
right
now
or
a
new
feature
is
a
cluster-wide
installation
option.
So
this
is
like
what
istio
Upstream
is
kind
of
Deep
by
default,
so
the
the
default
in
openshift
is
I
think
it's
still
a
multi-tenant,
but
you
have
now
the
option
to
install
it
cluster
wide.
C
Also,
if
you,
for
example,
have
one
large
mesh
with
a
lot
of
you
know
different
namespaces,
it
will
definitely
increase
the
performance
and
reduce
you
know
the
the
all
the
amount
of
API
traffic
calls
and
things
like
this,
then,
as
mentioned
there's
the
integration
with
a
cert
manager.
Right
now
there
is
an
external
authorization
with
off
policy
policies.
C
B
C
After
we
will
go
to
openshift
service
mesh
3
and
there
will
a
lot
of
things
will
change
there.
So
we're
working
on
service
service,
mesh
3,
and
we
want
to
really
converge
service
mesh
with
community
istio.
So
we
want
to
productize
a
kind
of
Upstream
issue
and
we
do
not
bundle
it
like.
We
have
it
right
now,
based
on
the
Maestra
project.
You
know
with
with
kiali
and
and
Jaeger
and
so
on.
C
So
these
will
be
kind
of
external
or,
let's
say
modular,
products
that
you
can
use,
but
the
the
thing
is
we
want
to
be
closer
to
Upstream
istio,
so
a
lot
is
happening
and
we
want
to
really
to
bring
the
latest
features.
Enterprise
ready,
also
to
openshift
of
istio
is
one
of
the
reasons.
So
we
need
to
work
closer
and
collaborate
closer
with
the
issue
Community.
C
D
C
I,
just
I
share
a
link
in
a
second.
There
is
also
you
can
test
this
new
operator,
so
there's
a
def
preview
version
of
it
right
now
and
you
can
already
test
test
it
and
and
provide
feedback.
If
you
like
to
yeah
and
as
mentioned,
the
new
new
operators
is
not
based
on
Maestra.
So
all
the
things
you
have
right
now,
so
the
service
mesh
control,
plane
crds
member
roles.
They
will
not
be
part
of
service
mesh,
3.,
yeah
also
mention
service.
C
B
C
We
want
to
accelerate
the
support
for
things
like
istioctl,
there's
a
lot
of
requirement
from
from
our
customers
right
now,
because
this
is
the
standard
SEO
CLI
and
currently
we
don't
support
this.
So
this
is
something
we
we
have
on.
The
agenda
then
also
the
canary
upgrades,
for
example,
of
the
control
plane,
additional
topologies
like
multi-primary
and
also
ambient
mesh
in
the
future.
So
it's
still
very
early
for
ambient
mesh.
C
Basically,
it's
a
sidecar
list
version
of
the
data
plane
where
you
split
like
the
level,
seven
and
level
four
functionality,
and
there
is
more
or
less
one
node
agent
or
you
have
one
node
agent,
and
this
one
is
handling
the
the
level
four
traffic
and
per
application.
You
will
deploy
one
NY
as
a
waypoint
for
level
seven
features
so
from
the
user
perspective
ambient
mesh
it
boom,
there's
not
that
much
change,
but
it
can
improve
the
performance.
A
lot.
C
C
C
C
The
service
mesh
3
operator
will
be
in
tab
preview.
Also
interesting,
kyali,
there's
a
chiali
plugin
for
backstage,
then
in
developer
preview.
So
this
is
our
new
product,
Red
Hat,
developer,
Hub,
so
a
central
interface
for
developers
where
they
can,
you
know,
create
Services
based
on
Golden
path
templates,
it's
a
central
point
for
information
for
documentation
for
API
document
documentation
and
all
of
that,
and
you
can
also
extend
it
with
a
certain
plugins.
So
you
can
look
into
the
real
clusters.
C
So,
for
example,
you
have
you,
have
your
microservice
and
you
can
in
developer,
Hub,
look
at
it
and
also
look
in
kiali
like
how's
the
things
you
know
the
traffic
flowing
through
services,
so
this
will
be
pretty
cool
I.
Think
then,
with
openshift
3.0,
as
mentioned,
there
will
be
the
CLI
support
for
service
mesh,
other
the
upgrade
mechanisms,
ambient
mesh
as
def
preview
and
yeah
from
there.
We
move
on
also.
B
B
And
how
it
can
be
used
for
Ingress
and
all
kinds
of
other
stuff,
so
I'm
that
one
I
think
is
definitely
going
to
be
an
interesting
topic.
Yeah
Omar
I
see
your
question
here.
Are
you
like?
So?
Can
you
talk
in
the
future
in
more
detail
about
certificate
management
for
mesh
I'm,
not
sure
if
you're
requesting
like
a
topic
for
the
future,
or
if
you
mean
here
on
the
stream
but
or
when
our
stellius
I
don't
know?
If
you
have
anything
to
add
about
that.
E
Yeah
so
I
I
mentioned
earlier
that
we
do
have
something
in
the
workshop
effectively.
There
are
two
certificates.
You
can
consider
that
you
might
need,
so
you
can
management
within
the
service
mess.
You
obviously
need
for
inter-mess
communication
through
the
mtls
capability
and
I
think
I
saw
in
the
chat.
You
know
you
can
utilize
either
a
question
about
us
or
that's.
E
If
that's
where
you
deliver
your
certificates
and
said
to
me
for
the
purpose
of
the
of
the
services
mtls
communication
or
it
can
be
part
of
your
Vault
with
the
search
manager
being
I,
guess
integrated.
So
you
can
actually
manage
that
and
there's
capabilities
for
both.
It
depends
on
what
its
team
decides
to
follow.
This.
B
E
I
would
like
to
put
everything
in
there
because
they,
you
know
so
I
saw
that
we
know
somebody
said
that
we
can
make
these
sessions
a
bit
longer
for
this
type
of
topic.
Unfortunately,
it's
whatever
we
put,
it
wouldn't
be
long
enough.
So
that's
why
we've
put
the
link
there
for
the
workshop,
because
it
will
help
people
to
do
it
in
their
own
pace.
That's
the
only
way,
I
would
say
yeah.
B
Yeah
service
mesh
is
one
of
those
things
that
reinforces
my
fractal
comment
about
openshift
and
kubernetes.
Like
for
every
question,
you
answer
there's
an
unlimited
number
of
new
questions
that
get
unlocked
and
for
every
one
of
those
that
you
answer
there's
and
it
just
never.
It
never
ends
so
yeah
it.
This
has
been
a
lot
of
fun.
I,
like
I,
said
I've
learned
a
lot
and
I
really
do
appreciate
all
the
different
aspects
that
you
all
are
taking
towards
this
and
I'm.
B
Definitely
looking
forward
to
looking
more
in
depth
at
the
at
the
ebook
and
just
continuing
to
learn
more
for
the
audience.
Please
feel
free
to
ask
any
questions
that
you
have.
You
know,
get
them
in
a
chat
here.
You
can
also
reach
out
so,
if
you're
watching
later,
if
you're
not
watching
us
live
or
if
something
comes
up
after
the
stream
ends,
you're
also
welcome
to
reach
out
to
us,
so
you
can
reach
out
to
Johnny.
B
So
let's
see
where's
my
little
thing
here
so
Johnny
you
can
reach
via
email
at
or
via
Johnny
redhat.com
j-o-n-n-y,
at
Red,
hat.com
or
jrocktx1
across
all
the
various
social
platforms.
You
can
also
reach
me
via
email
at
andrew.sullivan
redhat.com
super
hard
to
remember
or
at
practical
Andrew,
on
whichever
one
of
the
social
media
platforms
you
happen
to
be
on.
B
If
you
saw
on
if
you're
watching
chat,
I,
replied
to
I,
think
our
hope,
nine
and
my
my
handle
popped
up
on
there
from
twitch,
so
yeah
you're,
welcome
to
reach
out
to
us.
Johnny
and
I
are
on
all
of
various
places,
including
LinkedIn
and
Reddit,
and
slack
so
I
generally
encourage
folks
to
go
to
the
kubernetes
slack
so
we'll
put
that
link
up
there.
So
if
you
go
to
kubernetes.slack.com,
if
you
don't
want
to
remember
that
you
know
C6
Alpha,
Delta,
6,
Juliet,
Mike,
one
seven
man
I
can't
believe
I.
B
Remember
the
phonetic
alphabet.
It's
been
a
minute.
You
know,
if
you
don't
remember
that
you
can
just
go
on
to
the
kubernetes
slack
kubernetes.slack.com
search
for
the
openshift
users
Channel
and
that's
where
you'll
find
most
of
us.
So
with
that
being
said,
thank
you.
Orwin
Stelios.
This
has
been
just
absolutely
phenomenal.
I've
learned
a
tremendous
amount
yeah,
so
I'm
definitely
looking
forward
to
having
you
all
back
and
talking
more
about
service
mesh.
So.
C
B
Yeah
yeah
it.
This
is
one
of
those
things
where,
like
I
said,
it's
hugely
I'll
say
feature
packed.
You
know,
there's
tons
of
stuff
that
can
happen
and
or
that
it's
capable
of
doing
and
I'm
just
I'm
I'm
blown
away
at
one.
You
know
throughout
this
thing,
y'all
have
reminded
us
that
you
don't
have
to
use
everything
right.
It's
okay,
to
only
use
the
parts
that
you
need
and
you
actually
need
to
take
that
into
consideration,
because
if.
D
B
C
D
B
B
A
B
Yep
yeah
from
the
ACs
team
to
talk
about
vulnerability
management
with
ACS
and
managing
that
with
images
and
all
that
other
stuff.
So
Savion,
please
join
us
if
you're
interested
in
in
all
that
we're
kicking
off
devsecops
month
next
week,
leading
up
into
kubecon
all
right
Joel.
That's
all
I
got
so
if
anything
comes
up,
if
you
think
of
anything,
don't
hesitate
to
reach
out
to
us
and
Johnny
I'll
leave
you
with
Last
Words
yeah.
A
Just
a
little
bit
quickly
say
thank
you
to
the
audience
for
sticking
with
us
for
an
hour
and
45
minutes.
That's
really
awesome
so
really
happy
to
see
that
y'all
did
that
love
all
the
questions
and
all
the
interaction
right.
We
again
Andrew
and
I
feed
off
this
stuff,
all
the
time
and
hopefully
Orton
and
Stelios
also
got
to
feed
off
some
of
that
energy,
because
we
love
answering
questions,
that's
what
we
do
it
for
and
and
guys.
Thank
you
so
much
for
doing
this.
A
I
I
really
do
appreciate
it
and
I
I
love
your
approach
on
the
lab,
like
you,
the
you're,
not
just
leading
the
horse
to
water.
At
this
point
right,
you're
leading
the
horse
to
water,
you're
kind
of
showing
them
how
to
drink
it,
you're
giving
them
different
ways
to
drink
the
water
and
how
to
do
things
with
it.
A
So
I
I
really
like
the
approach
and
it's
kind
of
a
it's
kind
of
a
different
take
on,
like
the
thought
leadership
part
right
where
you're
trying
to
enable
people
to
do
things
so
I
think
it's
it's
a
really
fantastic
way
of
of
doing
it.
So
good
job,
excellent
work
and
yeah-
hopefully,
hopefully
we'll
get
you
guys
back
on
here.