►
From YouTube: Supercharge Your Microservices CI/CD with Service Mesh and Kubernetes - Brian Redmond, Microsoft
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Supercharge Your Microservices CI/CD with Service Mesh and Kubernetes - Brian Redmond, Microsoft
We all know by now that Service Mesh provides many benefits to containers on Kubernetes. Linkerd, Istio, and Consul are some great examples. With Service Mesh Interface (SMI), adoption is becoming much easier. Along with a lot of other features, Service Meshes are great at traffic shifting and observability which are helpful for microservice deployment and CI/CD platforms. Testing new versions in production with strategies such as Blue/Green, A/B, and canary rollouts are key in ensuring that deployments are error-free. In this session, I will dig deep into how you can integrate Service Mesh into deployment pipelines and automate these kinds of CI/CD methods. I will talk about observability using projects such as Prometheus and how it is key to validate candidate releases with real time latency statistics down to specific paths/methods. As always, I will include lots of demos!
https://sched.co/Uadd
A
Okay,
never
been
never
really
been
introduced
before
I
should
get
like
walk
up
music,
or
something
like
that.
You
can
ask
me
later
what
my
walk
up.
Music
song
would
be.
Yes,
as
we
know
we're
talking
about
micro-services
and
CI
CD
I'm
gonna
talk
a
lot
about
service
mesh,
really,
hopefully
at
the
beginning,
I'll
just
be
introducing
some
of
the
open-source
tools
that
I'm
gonna
use
in
this
demo
and
most
of
the
time
I'll,
hopefully
be
doing.
Demos
I,
like
live
demos,
so
we'll
be
doing
doing
demos
live
here.
A
Just
a
quick
note
on
Who
I
am
my
name.
Is
Brian
Redman
I
work
at
Microsoft
I've
been
at
Microsoft
for
over
19
years,
which
is
kind
of
amazing.
My
last
name
is
Redmond
I,
don't
I,
don't
live
in
Redmond
I've
visited
there
many
times,
but
that's
been
my
name
since
the
beginning,
so
I'm
a
program
manager
on
our
global
customer
success.
Team
I
work
with
our
field
to
help
enable
them
to
bring
customers
to
our
Azure
cloud
platform
and
primarily
around
open
source.
A
Solutions
like
like
kubernetes
I,
recently
moved
to
Denver
Colorado
and
by
recently,
like
five
days
ago.
So
pretty
excited
to
be
there
obviously
there's
other
big
Denver
fans
here,
but
yeah
I've
lived
in
Pittsburgh
for
most
of
my
adult
life,
so
I'm
excited
to
be
there
I
like
to
be
outside,
so
it's
a
perfect
place
to
do
that,
and
this
is
a
picture
of
my
wife
and
I
in
Hawaii
kind
of
looks
like
we've
jumped
out
of
a
plane
with
no
parachute
I.
Don't
recommend
that
so,
let's
get
started.
A
Let's
talk
about
micro
services,
so
I
saw
this
on
Twitter.
This
is
from
a
company
Mons.
Oh,
they
do
online
banking
out
of
the
UK
I
think,
and
this
is
something
they
tweeted.
They
said
they
had
1,500
micro
services
and
this
picture
kind
of
showed
the
network
rules
and
policies
between
each
of
the
micro
services,
and
it
was
a
interesting
thread.
Honestly,
people
were
had
sort
of
almost
violent
reactions
to
it
like
this
is
ridiculous.
There's
no
way
you
could
manage
that'
many
micro
services
and
others
thought
how
you
know.
A
Maybe
this
is
super
impressive
I'll,
be
honest
with
you.
I've
talked
to
folks
from
manzo
at
a
previous
coop
con,
and
perhaps
someone
is
actually
here
at
the
at
the
conference,
but
what
they
told
me
was
it
wasn't
easy
to
get
to
the
point
where
they
could
have
the
tools
and
processes
in
place.
The
organizational
change
to
manage
micro
services
at
scale,
but
really
honestly,
once
they
got
good
at
for
even
a
small
number
of
services
like
50
or
so
1500
wasn't
any
any
more
difficult.
A
It
could
be
honestly
hard
to
get
to
that
stage,
but
but
once
you
get
good
at
it,
it's
it's
not
that
much
harder
to
multiply
a
times.
A
big
number
1500
I
would
say
is
a
big
number,
but
some
companies
certainly
give
up
this
company.
They
were
called
segments,
they
posted
a
blog
again,
something
that
I
saw
on
Twitter
and
they
they
were
moving
to
micro
services
and
they
struggled
with
it
and
they
essentially
went
back
to
a
monolith.
I
love
how
they
call
it
a
superstar
I
think
that's
a
great
name.
A
Obviously,
monolith
just
sounds
negative,
so
they
went
with
superstar,
and
so
they
went
in
that
direction.
I'm
not
really
here
to
kind
of
recommend
micro
services
or
not,
and
the
journey
that
you
should
take
in
that.
It's
just
if
you
go
down
a
path
of
micro
services,
you're,
probably
going
to
need
better
procedures
and
and
things
to
do,
automation
around
that,
and
certainly
one
of
the
things
that
you'll
need
is
is
testing.
A
That
lack
that
first
time,
you
run
it
in
production,
that's
also
a
test,
and
so
the
more
that
you
can
actually
get
test
results
in
that
production,
environment
with
production
data,
the
more
successful
you'll
be,
and
certainly
I'll
talk
through
some
of
these
strategies
pretty
quickly.
I
would
imagine
this
audience
is
pretty
familiar
with
these
things.
A
blue/green
tests,
I
put
the
the
the
new
version
in
the
production
environment.
I
run
some
tests
against
it
once
I'm
comfortable
with
it.
I
just
used
some
kind
of
proxy
and
cut
over
to
the
new
version.
A
Pretty
simple
to
do
that.
The
canary
tests
is
where
we
do
the
same
thing.
We
run
version
two
in
that
production
environment,
but
we
start
to
just
funnel
some
of
the
actual
user
traffic
over
to
it
by
percent.
We
start
very
small,
maybe
five
or
ten
percent,
and
we
slowly
ramp
up
as
we
meet
the
thresholds
in
our
test,
that
we
need
until
the
point
where
we
just
cut
it
over
and
we're
using
the
new
version.
Easy
enough.
A
There's
also
strategies
like
a
be
testing
where
we
actually
mirror
all
of
the
traffic
that
we're
getting
through
our
production
system
to
our
current
version,
as
well
as
the
new
version
and
validated
against
it.
We
may
actually
store
some
of
that
in
a
separate
database
of
a
different
back-end
database,
of
course,
because
these
are
real
real
transactions,
but
we
get
a
real
picture
of
not
only
how
does
it
run
in
the
production
environment,
but
how
does
it
run
with
our
real
customer
traffic?
And
this
is
super
powerful?
A
The
hard
part,
of
course,
is
I've
got
to
have
capacity
to
run
double
the
transactions
which
could
be
costly
could
affect
the
production
traffic
not
necessarily
easy
to
do,
but
certainly
effective,
for
if
you
want
the
results.
So
what
we
end
up
with
is
in
a
micro
services
world
having
to
do
that
at
scale.
We
don't
just
have
to
have
one
service
blue/green
at
a
time,
we've
got
a
bunch
of
services,
and
if
it's
1,500
I've
got
to
do
this
in
a
pretty
efficient
way,
it
has
to
be
automated.
A
I
need
something
to
help
me
with
that,
and
that's
really
where
the
concept
of
service
mesh
comes
in
and
so
service
mesh,
of
course
solves
everything.
We
all
know
this.
We've
probably
seen
this
cartoon
I
love.
It
I
think
it's
fake
frankly,
but
pretty
pretty,
probably
pretty
realistic
right.
We've
all
been
in
those
meetings
where
people
just
say
well:
service
mash
will
solve
it
and
I'm
a
big
fan
of
service
mesh
trust
me
I'm
in
the
service
mesh
track,
so
I
must
be,
but
there's
certainly
in
many
places
where
service
mesh
doesn't
make
sense.
A
A
So
with
that
I
like
to
always
quote
William
Morgan
when
I
talk
about
service
smash,
Williams
from
from
buoyant
I
like
to
credit
them
is
the
sort
of
founders
of
service
mesh
and
he
defined
it
as
a
dedicated
infrastructure
layer
for
making
service
to
service
communication
safe,
fast
and
reliable
and
I.
Think
that's
a
pretty
fair
description
when
we
say
safe,
fast
and
reliable
we're
getting
some
of
these
kind
of
things.
We
get
some
observability
about.
A
What's
going
on
again,
1500
micro-services,
what's
the
latency
between
a
bunch
of
those
or
a
single
transaction
through
that
we
need
to
not
have
that
information
I'm
going
to
talk
a
bit
about
traffic
shaping
today
in
the
demo.
That's
how
we're
gonna
do
our
canary
deploy
and
so
I'll
probably
mostly
focus
on
those
first
couple,
but
you
can
certainly
do
a
lot
more
with
a
service
mesh
platform.
I
do
want
to
point
out
as
well
another
Corti
again
I'm,
obviously
saying
too
much
about
Boyan
I've
been
accused
of
working
at
buoyant.
A
I've,
never
been
paid
by
buoyant
I
just
happen
to
like
the
technology,
but
William
wrote
another
blog,
and
he
put
this
this
in
there
I
thought
this
was
super
interesting.
It
gives
you
the
features
that
are
critical
for
running
modern
server-side
software.
In
a
way,
that's
uniform
across
your
stack
and
it's
decoupled
from
the
application
code
because
really
doing
these
things
on
the
left
hand
of
the
slider,
you
can
do
it
any
way.
A
There's
tons
of
ways
to
accomplish
those
things,
it's
fairly
straightforward:
it's
these
factors
that
actually
make
service
mesh
interesting,
I,
don't
want
to
have
to
affect
the
code.
I
don't
want
to
build
these
into
the
code
and
the
applications
themselves.
I
don't
want
to
ask
developers
to
have
to
learn
this
across
a
diverse
set
of
programming
stacks
and
things
like
that,
and
so
that's
why
I
come
to
service
mesh,
and
you
can
obviously
pick
any
one
of
these
kinds
of
tools
when
you
want
to
do
it.
Do
something
with
service
mesh.
A
If
you've
been
here
all
week.
Obviously,
you've
had
lots
of
opportunities
to
learn
about
these
tools.
Again
I'm
a
fan
of
linker
D,
there's
again
quotes
out
on
Twitter
that
you'll
see
out
there.
Justin
Davies,
a
friend
of
mine,
that
is
out
of
the
UK
I,
think
there's
a
common
reaction.
You
set
it
up
and
you're
like
well.
Obviously
this
didn't
work
because
it
couldn't
have
just
worked.
A
The
first
try
with
like
three
three
commands:
it's
set
up
and
running
and
it's
giving
me
results
immediately,
and
so
obviously
it
must
have
been
broken
or
something
so
that
it's.
It's
super
easy
to
use
and
you
get
good
information
out
of
it
very
quickly
and
so
I'm
a
big
fan
of
it
and
that's
one
of
the
things
that
I'll
be
using
in
the
demo
here
today.
The
architecture
again
I
think
we've
been
talking
about
service
mesh
for
quite
some
time.
I'm
not
gonna,
spend
a
lot
of
time
on
it.
A
If
you're
new
to
the
topic
in
the
data
plane
and
your
actual
application
pods
and
your
cluster,
that's
where
the
sidecar
link
or
D
proxy
will
sit
and
so
you'll
see
two
containers
running
in
every
pod,
that's
meshed
and
all
of
the
traffic
goes
in
and
out
of
the
proxy,
it's
all
managed
by
that
control
plane.
So
that's
actually
where
we
configure
the
service
smash
and
we
get
information
about
our
observer
ability
and
all
that
kind
of
stuff.
So
I'm
going
to
use
another
open
source
tool
in
this
demo
called
flagger.
A
So
flagger
came
out
of
some
some
open,
an
open
source
project
that
came
out
of
some
folks
that
we'd
works
and
obviously
they're.
One
of
the
sponsors
here
at
the
event
and
really
what
this
was
about,
was
to
provide
some
kind
of
automation
to
be
able
to
deliver
a
canary
test
for
a
particular
deployment.
So
actually
do
some
of
the
traffic
shaping
rules
to
slowly
drift.
A
Some
of
the
traffic
to
the
new
version
perform
some
of
the
acceptance
testing
work
through
and
that
workflow,
according
to
your
your
configuration
until
slowly,
it's
actually
cut
over
and
running
in
the
new
version,
and
so
it's
pretty
powerful
and
what
you
can
do
there.
It's
ID
still
what's
considered
a
fairly
young
open
source
project,
but
you'll
see
how
it
works
when
we
go
through
the
demo
here.
A
The
other
thing
that
I'm
gonna,
take
advantage
of
here
is
something
called
service
smash
interface.
So
this
is
another
open
source
project.
That's
super
helpful
when
we
talk
about
something
like
like
a
like
a
tool
called
flagger
flagger.
If
it's
doing
some
of
that
traffic
shaping
and
they're
working
with
the
many
different
service
mesh
solutions
that
are
out
there,
they've
got
to
actually
build
their
system
against
all
of
those
different
different
service
mesh
platforms.
A
It
would
be
great
if
they
had
a
standardized
way
to
actually
talk
to
those
service
meshes
and
that's
really
what
service
mesh
interface
is
about.
It
gives
you
this
standardized
way
to
represent
service
mesh
configurations,
but
not
necessarily
have
to
understand
the
underlying
mesh,
and
certainly
again,
when
I'm
doing
things
like
a
canary
test,
it's
pretty
straightforward
that
I
just
want
to
route
some
of
the
traffic
over
it's
over
to
one
particular
version,
and
maybe
some
to
the
other,
and
so
I
can
just
build
in
a
standard
way
to
do
it.
A
That's
pretty
simple
and
not
necessarily
have
to
learn
all
of
the
configurations
of
that
underlying
mesh,
and
so
we're
gonna
you're
gonna
see
that
in
action
again
with
the
traffic
shaping,
it's
not
really
a
new
concept
in
kubernetes.
We
obviously
see
this
with
the
ingress
controller,
and
so
you,
you,
you,
put
ingress
objects
into
your
kubernetes
cluster
network.
Routing
the
actual
ingress
controller
under
the
covers
doesn't
really
change
that
much
about
the
ingress.
A
Obviously,
we
all
know
there's
little
nuances
in
that,
but
but
certainly
it's
the
same
idea
of
a
service
special
interface
in
these
early
stages
of
SMI.
Right
now
we
have
traffic
split
that
again
I'm
going
to
show
you.
We
have
traffic,
metrics
and
also
traffic
access
control,
doing
policy
around
service
to
service
communication.
A
A
lot
of
folks
actually
worked
on
this,
so
we've
had
a
number
of
different
companies,
including
Microsoft,
that
worked
on
building
SMI
and
again
it's
it's
an
it's
in
its
early
stages,
I
think
it
was
announced
at
the
last
cube
con,
so
certainly
a
lot
of
opportunity
to
get
involved
in
this
and
expand
upon
the
work
and
take
it
to
really
cover
I.
Think
more
scenarios
that
service
mesh
actually
works
works
in.
A
So
that's
that's
the
different
tools
that
I'll
be
using
in
the
demo.
So
of
course,
I
like
to
do
live
demos.
So
that's
my
preference,
who
knows
if
it'll
work
I
actually
went
in
and
took
a
look
at
my
cluster
right
before
the
talk
and
my
nginx
ingress
controller
had
like
thousand
12
restarts
or
something
so
those
are
those
fun
moments.
But
if
it's,
if
it's
not
live,
you
know
I'm,
not
I'm,
not
a
fan
of
doing
it.
So,
let's
jump
in
and
take
a
look
actually
I
want
to
show
you
real,
quick.
A
What
this
application
looks
like
I
use
this
this
application
a
lot
as
a
demo
application.
Essentially,
we
store
geospatial
data
in
a
database
on
the
backend.
We
display
it
on
a
map
and
we
have
a
bunch
of
Micra
services
in
the
middle
to
retrieve
that
and
pull
that
back.
It's
just
for
the
purposes
of
demos.
That's
why
we
have
a
bunch
of
extra
micro
services
here
so
that
we
can
experiment
with
things
like
we're.
A
A
This
is
how
the
application
looks
when
it's
deployed.
If
you
can't
see
this,
you
probably
need
to
move
closer
I
stood
in
the
back
and
I
could
make
out
basically
half
of
it
most
of
it
was
from
from
memory.
So
we
have
a
series
of
deployments
that
represent
each
of
those
micro-services
in
the
front
end.
Obviously
all
the
pods
that
are
with
it
a
couple
interesting
things
to
point
out.
A
One
is
I:
have
this
load
tester
deployment?
That's
not
really
doing
anything
at
the
moment,
it's
sitting
and
waiting
to
be
a
part
of
this
canary
test.
So
when
the
canary
test
kicks
off,
it's
actually
can
call
into
this
load
tester
to
generate
some
traffic,
because,
obviously,
if
we're
gonna
measure
the
canary
deploy,
we've
got
to
make
sure
that
it
actually
has
traffic.
So
we
have
something
to
measure,
and
maybe
our
users
aren't
active
on
during
and
when
this
is
actually
running.
A
So
we
need
this
to
actually
be
a
part
of
the
test
and
I'll
show
you
how
I
configure
how
that
that
actually
works.
When
it
happens,
the
other
thing
is
notice.
I
have
the
the
primary
deploy
here,
but
I
also
have
this
other
deployment
that
doesn't
have
any
pods
running,
so
that's
actually
where
the
canary
will
end
up
appearing.
The
other
thing
is
I
have
services
that
represent
each
of
these,
so
I
have
one
for
the
canary.
A
In
primary
specifically
in
case,
I
want
to
call
them
specifically
and
then
I
have
flights
API
and
that's
the
one
that's
associated
with
my
traffic
split
SMI.
So
when
I
call
flights
API
the
traffic
split
as
long
as
it's
working
with
linker
D
and
not
it
not
unmatched,
will
take
advantage
of
that
and
actually
follow
the
rules
of
this
traffic
split
and
just
real
quick.
So
you
can
see
what
this
looks
like.
A
You
can
see
down
at
the
bottom
we're
spending
a
hundred
percent
of
the
traffic
to
the
to
the
primary
and
none
to
the
canary.
This
is
what
Flagler
will
do
for
us,
as
it
kind
of
moves
that
forward
all
right.
So
what
I'm
going
to
do
is
actually
quickly
go
in
and
make
an
update
to
my
code.
I've
got
a
couple
different
workflows
that
I
want
to
show
you
and
github
actions.
So
a
part
of
our
CI
CD
here
we're
gonna,
do
a
pull,
request,
workflow
and
then
a
complete
CI,
CD
workflow.
A
A
And
we're
gonna
do
a
pull
request:
I'm
gonna!
Let
you
see
get
this
started
and
then
I'll
show
you
actually
what's
happening
in
the
background
and
I
do
want
to
make
it
against
my
fork
and
I
do
pull
requests.
I
do
already
have
a
pull
request
sitting
here
and
that's
just
for
the
purposes
of
speeding
up
the
demo,
but
the
pull
request
workflow
in
my
case.
We're
not
this,
isn't
the
test
in
production
Canary
part
of
the
test.
This
is
just
I'm
gonna.
Take
this
pull
request
and
perform
some
kind
of
acceptance,
testing
against
it.
A
In
my
case,
I'm,
actually
just
gonna
do
a
container
image
security
scan
on
it.
I
would
imagine,
there's
a
lot
of
other
things
that
you
would
do
here,
but
I
end
up
just
going
through
the
steps
here
doing
a
docker
build
I'm
using
another
open
source
tool
called
anchor
here.
Really
not
important
of
what's
actually
happening
here
is
just
that.
This
is
a
part
of
my
workflow
that
before
I
actually
me
been
doing
this
canary
test
I'm
doing
a
series
of
tests
only
against
the
pull
request
itself.
A
All
right-
and
you
can
see
results
of
this
over
here
in
actions.
The
the
current
one
should
be
running.
It
actually
isn't
funny
enough
did
I
not
complete.
My
full
request
we'll
ignore
that,
but
I
want
to
show
you
on
one
of
these
that
ran
when
I
first
actually
set
this
up.
I
had
a
failure
of
one
here,
and
so
you
can
actually
see
the
ant
course
can
fail
and
funny
enough.
A
A
It
always
wants
to
take
you
back
to
the
original
repo.
So
you
can
see.
This
is
one
that
I
did
earlier
today.
I
did
a
pull
request,
just
like
we
did
before
I
upgraded
to
version
1.3
Oh.
In
fact,
you
can
see
when
I
say
show
all
checks.
This
is
where
that
security
scan
occurred.
I've
got
some
folks
on
the
team
working
with
me,
Joey
checked
in
his
code,
so
we
can
merge
this
pull
request
so
since
that's
being
merged
into
master
I'm,
going
to
show
you
actually
what
that
workflow
looks
like.
A
So
in
this
one,
I've
got
a
series
of
messages
that
are
writing
this
info
out.
To
slack
so
we'll
see
it
slack
messages
come
up
kind
of
here
as
we
go,
but
but
basically
I'm
logging
in
I'm,
using
some
tools
in
Azure
to
actually
create
my
container
image
and
as
your
container
registry
and
then
I'll
connect
over
to
my
a
KS
cluster
I'll
set
context,
and
then
I
will
set
the
image
deployment
for
this
new
image
that
we
just
built.
A
So
this
is
kicking
off
and
running
right
now,
but
the
important
thing
is
even
though
I
set
this
new
image
tag.
It's
not
just
gonna
automatically
update
that
flights
API.
This
is
where
flagger
is
gonna
step
in
intercept
this
and
kick
off
my
canary
tests,
and
it
will
take
it
a
second
to
get
going
here.
Let's
actually
see
if
something's
actually
happening,
thankfully
it
is,
and
shortly
after
it
does,
a
check
out
will
actually
see
messages.
Kick
off.
A
Our
CI
CD
workflow
has
started
I
want
to
jump
over
here
to
this
environment,
and
you
what's
actually
gonna
happen.
So
you
can
see
down
here.
I,
have
this
canary
object
called
flights
API
down
here
at
the
bottom.
This
is
the
flagger
CRD
that
actually
drives
what
this
canary
test
will
look
like,
and
over
in
my
repo
I
have
got
that
object
for
you
to
take
a
look,
and
so
again
it
has
an
object
called
canary
I
can
specify
the
deployment
that
I
want
to
run
this
against.
A
A
A
percent
I
can
control
all
of
those
details
of
how
I
want
this
to
occur,
and
so
a
lot
of
other
steps
in
there
I
would
imagine
there
might
be
even
more
customization
folks
want
to
do
and
I
think
that's
the
kind
of
thing
that,
as
this
project
grows,
you'll
see
those
things
come
in
the
testing.
I
love
how
it
says:
optional,
not
optional,
but
but
certainly
there's
two
kinds
of
tests
that
you'd
run.
A
When
you
kick
this
thing
off
and
by
the
way,
let's
just
look
and
see,
is
it
kicked
off
yet
not
quite
the
first
one
is
the
the
pre
rollout.
Did
this
thing
actually
start?
Is
it
actually
just
working?
Is
it
running
at
all,
and
so
in
my
case
I'm
just
hitting
that
status
endpoint
and
making
sure
it
actually
returns
some
information,
but
certainly
once
I
that
it's
a
passed
that
acceptance
test.
A
This
is
where
we
use
that
load
test
or
pod
running
in
the
cluster,
and
it
goes
through
and
uses
this
hay
tool
to
generate
traffic
against
against
this
canary
to
make
sure
it's
actually
working
and
so
we'll
see
traffic
funneled
here,
making
sure
that
this
is
actually
working
as
expected
and
then
flagger
will
go
through
and
increment
and
slowly
perform
this
test.
For
us,
let's
see
where
we
are,
you
can
see
it
actually
kicked
off
the
the
test
here,
and
so
you,
it's
saying
that
it's
sending
some
of
the
traffic
over
to
the
canary.
A
So
let's
go
over
to
the
link
or
D
dashboard
and
see
what
things
what's
going
on
here.
One
thing
that's
cool:
is
we
still
see
a
hundred
at
the
primary
fun
enough?
That's
progressing
it's
getting
there.
One
thing:
that's
cool
about
linker
D!
Is
it
actually
natively
uses
the
the
traffic
split
API
is
a
part
of
service,
mesh
interface
and
so
you'll
see.
We
already
see
it
switching
out
sending
10%
of
the
traffic
to
the
canary
its
natively,
using
that
traffic
split
that
we
saw
earlier.
A
A
We
obviously
are
measuring
a
lot
of
statistics
on
how
this
is
working,
but
what
about
what
API
calls
were
actually
seeing
seeing
results
again
so
a
lot
of
times
when
we're
troubleshooting
a
problem
with
a
particular
application.
You
know
we
know
that
it's
performing
slowly,
but
where
it,
where
in
the
code
is
the
problem,
and
so
it
liquor
D
actually
helps
us
with
this.
A
If
we
actually
take
this,
this
tool
called
top
and
it's
using
all
the
data,
that's
collecting
inside
of
inside
a
link
or
DS
Prometheus
back-end,
and
you
can
see
a
bunch
of
the
results
of
the
actual
calls
that
are
coming
in
through
through
the
service
mesh
and
if
you
notice
it
actually
down,
is,
is
down
to
per
api
path.
Measurements
of
what's
actually
happening.
A
If
we
go
back
over
to
slack
we'll
eventually
see
this
thing
kind
of
finish,
it
looks
like
we're
at
the
40%
stage
the
way
I've
configured
this.
If
we
make
it
250
and
it
passes
all
the
tests,
it'll
actually
go
and
roll
out
the
new
version.
If
you
take
a
look
in
the
cluster
here
notice
that
we
have
the
two
primary
pods
that
are
running
and
then
that
other
one-
that's
that's
not
primary,
is
the
Canary
pod
that
itself
that's
actually
running
and
again.
A
This
should
pass
it's
possible
that
it
won't,
but,
but
certainly
in
my
experience
running
this,
it
usually
works.
So
that
is
how
that
part
works.
I
did
want
to
point
out.
One
thing
that
I
think
is
really
really
interesting
from
this,
because
I'm
using
a
few
different
tools,
it's
actually
hard
for
me
to
go
back
in
and
troubleshoot
this
see
icd
process
so
as
much
as
I
think.
This
is
interesting
from
a
demo
point
of
view.
A
I
have
a
slack
tool
where
I
can
go
in
and
get
monitoring
or
the
results
of
things
while
they're
happening
it's
a
bit
harder
for
me
to
actually
understand.
Okay,
this
thing
failed
I've
got
to
go
to
github
actions
over
here
to
troubleshoot
this
part
of
the
process.
I've
got
to
look
inside
a
flagger
to
actually
understand
what's
happening
in
flagger
like,
for
example,
if
I
want
to
know
what
happened
with
flag
or
I
do
a
describe.
A
So
we
see
this
result
here.
What
actually
happened?
You
can
see
it's
doing,
that
it's
doing
its
finalizing
and
updating
and
actually
accepting
this
new
version
and
rolling
it
out,
but
I'm
looking
here
for
this,
this
part
of
the
troubleshooting
and
another
tool
for
another,
so
not
necessarily
ideal,
but
the
point
being
that
we
understand
kind
of
having
that
ability
to
kind
of
go
through
each
each
step
of
the
process
to
roll
out
and
go
through.
There
makes
sense
all
right,
awesome.
B
How
about
there
that
sounds
good
hi,
Brian,
Scott
Fulton
from
CNN,
you
mentioned
how
linker
D
is
your
service
mesh
of
choice
but
but
based
on
the
the
structure
of
the
demo
you
just
presented
is:
can
any
other
service
mesh
work
in
its
place
and
if
it
does
is,
is
it
more
difficult?
Is
it
easier
in
certain
areas,
are
there
advantages
and
disadvantages
yeah.
A
It's
it's
a
great
question.
We
do
get
that
question
a
lot
like
in
the
purposes
of
that
demo,
because
I
use
service
special
interface,
which
again
I'm
a
big
fan
of
it,
would
be
very
easy
to
swap
that
out
and
that
especially
using
the
traffic
split
API,
you
could
split,
you
could
swap
out
which
service
mesh
are
using
and
the
demo
would
work
exactly
the
same
with
almost
no
changes.
A
Part
of
the
the
value
of
that
too
is
again
because
I'm
using
SMI,
the
the
flagger
project
can
more
easily
adapt
itself
to
the
different
meshes,
because
it's
just
taking
advantage
of
a
service
mesh
interface
in
that
standard
way.
Now
the
other
part
of
the
question
this
may
be
different
than
the
demo
is,
you
know
almost
like.
Why
would
I
pick
a
particular
service
masher
over
the
other
and
to
me
it
comes
down
to
just
looking
through
the
requirements
of
what
you're
trying
to
accomplish.
A
They
eventually
I
asked
they
think
they'll
all
have
the
same
feature
set,
and
so
then
it
really
just
come
down
to
maybe
performance
testing
and
understanding
what
vendor
you
want
to
work
with,
and
things
like
that
and
the
early
stages,
there's
still
some
feature
differences
between
them.
The
number
one
thing
I
would
look
at
the
very
first
thing,
I
would
evaluate
if
I
was
trying
to
pick.
One
is
from
a
performance
standpoint:
I'm
gonna,
I'm,
gonna
test
my
application
rigorously
without
a
service
mesh,
maybe
mesh
the
application
and
find
out
the
overhead
of
that
platform.
A
As
we
know,
there's
overhead
I
mean
there
has
to
be.
Is
it?
Is
it
measured
in
tiny
milliseconds
or
is
it
measured
in
something
you
know
horribly
much
bigger
and
also?
How
does
my
cluster
run
and
is
it
taking
up
a
bunch
of
cluster
resources
and
so
forth?
So
and
I
do
believe
at
this
stage,
some
of
the
different
service
messages
have
advantages
over
others
in
particular
areas,
but
again,
I
think
in
the
longer
term,
that
won't
be
this
factor.
C
A
It's
a
great
question:
yeah.
If
you
had
a
lot
of
replicas
you'd
want
it
to
test,
maybe
maybe
multiples
of
them.
I
I
would
hope
that
would
be
configurable.
My
impression
is
it
just
it
just
hits
the
service
end
point.
So
at
that
point
it's
gonna
sort
of
randomly
get
one
of
them
and
if,
if
that's
configurable
I
don't
know,
if
that's
something
you
can
say,
I
want
to
hit
that
acceptance
test
five
times
twenty
times
and
validate
all
of
them
and
that
way
you'd
hit
all
of
the
pods
I.
A
A
D
A
Great
yeah,
great
question
and,
and
it's
both
so
it's
measuring
everything,
but
the
reason
it's
using
hey
and
again
hazed
is
just
part
of
the
sample
that
they
provide.
You
can
honestly
use
anything
you
want
here,
but
but
let's
say
you
didn't
have
enough
real
traffic
coming
into
your
application.
Users
were
asleep
or
whatever
that
may
be.
This
is
one
way
to
drive
some
traffic
to
do
some
measurement
in
a
much
busier
application.
That's
typically
busy
24/7.
You
may
not
even
need
to
run
this
part.
A
A
E
Either
I'm
just
curious
about
how
I
saw
you
had
0%
and
100%
on
your
private
or
your
canary
versus
primary
respectively,
and
then
you
slowly
worked
at
up
to
10
and
then
20
and
then
I
saw
50%.
So
is
that
configurable,
and
is
it
just
based
on
the
amount
of
time
that's
passed?
Is
it
something
you
can
control
directly?
What
was
your
strategy
for
that?
It's.
A
It's
it's
right
here
in
this
canary
object
in
the
in
the
actual
flagger
canary
object.
All
of
that
is
configurable.
Now
I
I,
just
just
decided
again
somewhat
from
the
flow
of
the
demo
to
make
sure
it
was
started
at
10
and
stopped
at
50.
I.
Don't
know
that
that's
my
advice
on
the
proper
way
to
do
a
canary
test,
but
at
the
same
time
you
can
set
all
of
that
that
you
want.
You
can
see
the
intervals
controllable.
Every
30
seconds
go
up,
I
would
imagine
in
a
production
scenario.
A
You
wouldn't
just
be
fire
through
there,
every
30
seconds,
so
you
kind
of
have
to
have
a
feeling
of
how
your
application
works
and
what
you
would
do
there,
but
but
a
good
bit
of
it's
configurable
and
honestly
I
wouldn't
be
surprised
if
there's
more
configuration
options
than
what
I
have
listed
here
or
if
there
are
more
coming
as
they
kind
of
walk
through
working
towards
kind
of
a
version.
1
release
of
a
tool
like
this
yeah.
E
A
D
E
A
And
so
everything
that
I
kind
of
did
here
with
with
probably
more
than
that
is
somewhat
the
instructions
are
listed
here.
I,
wouldn't
call
this
a
instructions
you
could
just
take
and
follow,
but
you
could
probably
get
a
good
bit
of
it.
Working
to
be
honest,
if
you
just
went
to
flaggers
walk
through
here,
you
could
actually
see
how
a
lot
of
it
works
with
their
pod
info
sort
of
sample
application
and
get
everything
set
up
and
run
again.
You.
A
Smi
is
listed
there.
They
use
the
SMI
in
this
demo,
but
certainly
you
can
go
to
the
SMI
website
and
see
some
samples
of
more
than
just
just
doing,
traffic
shaping
and
so
forth.
Saying,
oh,
thank
you.
So
with
that
I'll
wrap
up
I'll
certainly
take
questions
up
here,
kinda
as
we
go,
but
I
appreciate
everybody
joining
and
yeah
only
a
couple
sessions
left
but
enjoy
what's
left
to
the
conference.
Yeah
thanks.