►
From YouTube: Canary Releases in Kubernetes with Gloo API Gateway
Description
Canary deployments are an approach for safer application delivery and in this case, the delivery of new software to your end users without disrupting or interrupting their experience. Techniques like Blue/Green, Canary and Progressive Delivery allow you to reduce the risk by slowing down and better controlling how many end users have access to the new software as it is deployed to production.
Combined with the adoption of microservices architecture, containers and Kubernetes, our deployment practices change from upgrading in place to deploying entire new services in its place. These new applications can be made up of tens or even hundreds of loosely coupled services that are releasing new versions weekly or even daily.
When operationalizing Kubernetes environments, operators can leverage the networking layer to control the impact of new releases without creating service outages, gain early insight into any issues with the new service, and gain control over the software releases to ensure successful deployments, proper application behavior and a great end user experience.
In this webinar, we will cover:
* What is a Canary Deployment
* Considerations in designing your Canary process
* How to architect Canary Deployments with API gateways
* Ecosystem tools for automation and observability
* Demo
More Info:
Website https://www.solo.io/products/gloo/
Download presentation https://speakerdeck.com/soloio/canary-releases-in-kubernetes-with-gloo-api-gateway
Tutorial https://www.solo.io/blog/two-phased-canary-rollout-with-gloo/
Request a demo https://lp.solo.io/lp-request-a-demo-overview
Join the community https://slack.solo.io/
A
So
what's
the
goal,
our
goal
here
is
to
successfully
deliver
new
features
frequently
to
end-users.
We
want
it
to
be
as
much
of
a
continuous
delivery
process
as
we
can,
and
ideally
we
can
decentralize
that
process,
so
we
could
define
a
way
for
different
teams
to
potentially
manage
their
own
upgrades
and
glue
gives
you
those
primitives.
A
We,
you
know
we'll
look
into
the
configuration
for
this,
but
a
lot
of
customers
and
people
that
are
building
out
platforms
with
glue
have
asked
what
are
the
specific
workflow
steps
that
I
would
do
how
to
take
advantage
of
glues
features
and
towards
this
goal-
and
specifically
you
know,
when
we're
talking
about
production
environments
were
worried
about
some
challenges
related
to
how
do
we
minimize
risk
avoid
downtime
and
generally
avoid
disruption
which
includes
detecting
when
there's
a
problem?
So
how
would
we
you
know?
A
And
obviously
you
know
as
we
the
reason
we're
kind
of
utilizing
the
API
gateway
is.
We've
got
likely
a
lot
of
different
services,
potentially
in
a
fairly
heterogeneous
environment.
It's
complicated
to
start
to
work
through
and
define
these
workflows
and
there's
a
lot
of
different
independent
moving
parts.
So.
A
A
So
in
case
you're,
relatively
new
to
Glu
Glu
is
an
api
gateway,
it's
cloud
native
built
on
top
of
envoy
as
the
proxy.
So
you
know
when,
if
you're
thinking
about
your
application,
requests
are
coming
from
users
through
two
different
services.
As
the
entry
points
to
your
application
and
envoy
sits
in
the
middle,
usually
providing
things
like
authentication,
maybe
rate
limiting,
you
know,
maybe
transcoding
the
protocols
for
our
purposes
we're
also
going
to
leverage
a
few
Envoy
features
called
subset,
routing
and
weighted
destinations.
But
what
glue
is
is
a
control
plane,
so
envoy
requires
configuration.
A
What
glue
can
do
is
dynamically
watch
the
configuration
that
users
are
authoring,
we'll
see
those
examples
in
my
demo
and
as
you're
making
changes
to
the
config
it
pushes.
Those
out
translates
them
into
envoy
and
updates
envoy
dynamically,
so
you
use
glue
to
really
connect.
You
know
users
to
your
application
while
doing
it
in
a
secure
way.
It's
also
a
nice
kind
of
entry
point
when
it
comes
to
observability
as
we'll
see.
A
So
in
this
webinar
I'm
going
to
advocate
a
two
phased
approach
to
canary
releasing
we're
the
first
phase,
it's
very
targeted
kind
of
shifting
a
tiny
subset
of
the
traffic.
In
our
example,
it's
going
to
be
based
on
the
value
of
a
header
in
the
requests
that
we
could
kind
of
select
that
traffic
in
different
ways,
and
the
purpose
of
that
first
phase
is
really
initial
correctness.
Testing.
Let's
make
sure
things
look
okay,
for
maybe
me
or
for
a
specific
user.
A
Then
in
Phase
two
once
we're
satisfied
on
the
correctness,
we
will
start
to
shift
more
load
over
to
the
new
version
and
at
that
point,
you're
really
monitoring
kind
of
metrics
trying
to
figure
out
is
the
performance
is
the
performance
of
the
new
service
meeting
our
expectations?
Has
there
been
any
kind
of
progression
and
assuming
that
goes
on
that
goes
well
and
at
the
end,
we'll
eventually
decommission
the
first
version
for
this
demo
I'm
going
to
use
a
service
just
a
simple
echo
service.
A
So
I've
gone
and
installed
the
echo
application.
We
can
see
the
manifest
here.
Basically
it's
you
know,
I'm
running
it
in
a
namespace
called
echo,
it's
a
very
simple
container,
actually
borrowed
it
from
Hoshi
Corp.
All
it
does
is
echo
back
the
text
that
you
provided
in
a
program
argument
and
I've
put
a
kubernetes
service
in
front
of
it
just
called
echo.
So
this
is
the
kubernetes
endpoint
that
will
be
actually,
you
know
having
envoy
forward
requests
on
to.
A
Now,
a
to
start
I'm
not
deploying
two
versions:
I'm
just
going
to
deploy
one
in
addition
to
this
I
need
to
actually
create
a
route
in
glue,
so
we
want
to
define
first
the
route
itself.
It's
in
glue,
the
way
that
you
define
a
route.
Is
you
create
virtual
services?
So
we
we've
got
a
rabbit,
that's
defined
here
and
it's
essentially
routing
any
traffic.
You
know
this
is
a
demo,
so
I'm
just
matching
on
the
star
domain.
A
So
any
of
your
requests
hitting
Envoy
with
any
host
and
because
I've
used
the
the
path
prefix,
slash,
really
any
path
will
get
forwarded
and
routed
onto
this
upstream
called
echo.
What
the
upstream
is
is
really
the
destination
for
traffic,
so
here
we're
referencing
the
service
port,
the
service
name,
namespace
and
port
and
we'll
use
this
in
a
second
but
I
just
wanted
to
call
it
out
here
in
our
upstream
definition,
we're
leveraging
a
feature
called
subset
routing
and
so
basically
we'll
define
subsets
on
the
deployments
using
labels.
A
The
in
this
case
we're
going
to
use
a
version
label.
So
if
we
go
back
and
look
we'll
see
each,
you
know
our
actual
pods
that
get
created
our
deployment
has
this
v1
version
and
if
we
deployed
a
second
version
we
could
change,
we
could
we
could
deploy
v2
and
the
subset
definition
in
our
upstream
by
kind
of
describing.
That
version
is
a
way
to
break
up
that
that
destination
into
different
subsets.
A
We
can
start
to
utilize
that
in
our
glue
rats
as
we'll
see
shortly
but
I
just
want
to
first
show
you
kind
of
our
cluster,
so
I've
got
a
gke
cluster
running,
so
this
is
a
Google
Krug
Randy's
cluster
I've
deployed
in
advance
glue,
as
well
as
a
few
other
things
which
you
can
disregard.
I've
been
doing
some
service
mesh
testing
but
in
you
know,
deployed
glue
and
I've
also
gone
and
deployed
that
echo
service.
So
if
we
look
in
our
echo
name
space,
we
should
see
we've
the
service
running.
A
A
This
is
resolving
to
a
a
service
IP
address
in
the
form
of
a
URL,
and
if
we
look
at
the
services
in
our
glue
system
namespace,
we
can
see
that
I've
deployed
glue
with
the
Gateway
proxy
as
a
load,
balancer
service
and
that's
the
external
IP
address,
so
I'm
issuing
requests
to
the
proxy
because
of
the
routing
configuration
any
requests
to
this
IP
address,
hit
our
virtual
service
and
any
path
hit
our
specific
route
definition.
That's
why
this
request
returned
US
version,
v1.
A
A
Now
in
our
I'll
apply
this
and
we'll
see.
We
expect
at
this
point
really
no
change.
I
haven't
you
know,
we
only
have
you
one
deployed,
so
if
we,
if
we
go
back
and
curl
we're
still
getting
back
v1
so
that
didn't
really
change
the
functionality,
but
we
can
start
with
new
versions
in
the
namespace
without
worrying
that
traffic
is
going
to
be
sent
to
them.
A
So
that's
what
we're
going
to
do
next,
we're
going
to
deploy
v2,
which
is
essentially
the
same
as
our
v1
deployment.
The
main
difference
is:
we've
labeled
it
with
that
version,
so
that
we
know
that
it's
part
of
the
v2
subset
and
then
we've
also
updated
the
return.
Basically,
the
the
program
argument,
so
that
when
we
curl
this,
it
returns
version
v2.
A
Let's
make
sure
that
our
curl
requests,
you
know
we
picked
up
the
subset
definition
in
the
route,
so
we
can
continue
to
see
the
behavior
of
the
application
as
it
was
before.
We
didn't
start
accidentally
routing
traffic
to
this,
just
because
we
deployed
it,
but
now
we
can
look
at
what
would
it
take
to
define
a
route
that
does
send
traffic
to
that
subset.
A
A
What
our
new
route
is
going
to
do
is
it's
going
to
have
the
same
matcher
with
an
additional
header
that
that's
required
and
specifically
we're
going
to
look
for
the
header
stage
canary.
So
basically,
if
I
provide
that
header
in
my
requests,
it
will
get
forwarded
or
routed
based
on
this
definition,
if
that
header
isn't
present,
we'll
fall
back
onto
this
routes
and
the
routing
action
for
when
that
header
is
presence.
Is
that
we're
going
to
forward
to
the
same
upstream?
A
A
We've
updated
our
virtual
servants,
let's
curl
so
again
as
before.
We
didn't
change
the
behavior
of
the
application,
but
if
we
provide
our
header,
we
start
to
see
requests
going
to
v2.
This
is
good.
This
gives
us
a
way
to
selectively
start
sending
some
traffic
tivity
to
so
that
we
can
really
see.
What's
going
on,
and
let's
say
at
this
point:
I
instruct
you
know
maybe,
as
a
team
we're
going
to
do
a
round
of
correctness,
testing
or
QA.
You
know
we
can
leave
this,
as
is
for,
however
long.
A
We
want
until
we're
comfortable
that
this
is
behaving
as
we
expect
and
I'm
not
going
to
get
into
it
in
this
demo.
But
I
do
want
to
paint
a
picture,
there's
a
lot
of
ways
that
we
could.
We
can
populate
this
instead
of
expecting
the
user
to
provide
it.
A
good
example
of
that
is,
you
could
imagine
if
a
request
comes
in
with
a
JWT
token,
that's
invariant,
that's
a
valid
based
on
how
we
authenticate
JWT
s,
and
that
token
contains
a
claim
that
says
we
should
send
the
request
to
canary.
A
We
can
move
that
claim
into
the
header
if
it's
a
valid
token,
and
then
we
can
use
that
as
the
header
or
that
you
know
we
can
have
that.
Basically,
that
filter
provide
that
header
instead
of
the
user.
That's
just
one
example:
there's
other
ways
that
we
could
do
this,
you
know
and
and
control
kind
of
how
we're
matching
to
send
traffic
to
the
subsets
great.
A
So
that's
the
end
of
phase
one
we're
kind
of
happy
we're
able
to
kind
of
you
know
feel
confident
in
v2
of
the
service
based
on
our
initial
testing,
so
we're
ready
to
start
kind
of
shifting
into
Phase
two,
where
we
really
progressively
roll
out
or
deliver.
You
know
traffic
to
that
new
version
until
we're
all
the
way
to
100%.
A
I'm
going
to
build
off
of
the
virtual
service
that
we
had
before,
specifically
what
I
mean
is
I'm
going
to
leave
that
first
route
intact.
You
could
imagine-
and
during
this
the
second
phase,
you
still
want
the
ability
to
kind
of
selectively
send
traffic
specifically
to
v2.
So
this
might
be
a
nice
to
have
kind
of
route
to
maintain,
but
I'm
gonna
change
our
our
fallback
route,
our
kind
of
default
route.
A
So,
instead
of
just
for
some
just
routing
to
the
specific
single
destination
of
that
upstream,
I'm
now
going
to
utilize
a
feature
called
weighted
destinations,
so
basically
gu
lets.
You
define
multiple
destinations
on
a
particular
route.
You
can
define
the
weights
associated
with
it,
so
how
you
would
really
kind
of
shift.
You
know
for
all
the
requests
coming
in
that
match
on
this
route,
how
much
of
them
should
I
send
to
one
or
the
other
destination,
and
these
could
be
different
up
streams
that
could
be
different
destinations.
A
A
A
Now,
in
a
progressive
delivery
scenario,
you're
probably
going
to
take
a
much
more
coarse,
fine,
grained
approach
to
the
weights,
but
in
our
scenario
here
for
demo
purposes,
I'm
going
to
immediately
jump
to
sending
half
the
traffic
to
v2.
So
you
may
want
to
you
know,
start
with
a
percent
and
maybe
increase
it
to
5
percent
10.
A
You
know
25
you,
you
you'll,
want
to
come
up
with
some
scheme
for
actually
deciding
what
what
steps
along
the
way
you
want
to
test
that
there's
great
tooling
out
there
in
the
open
source
community
from
our
friends
over
at
weave
works,
there's
a
tool
called
flagger
which
helps
you
automate.
The
progressive
delivery
so
helps
you
automate
the
changing
of
the
weights
and
you
know
to
get
to
the
final
kind
of
desired
state
and
capturing
kind
of
metrics,
or
you
can
define
kind
of
business
metrics
that
you
care
about
to
evaluate
during
that
process.
A
So
now,
what
we're
seeing
is
we're
getting
some
requests
to
v1
some
to
v2.
Now
it
should
be
about
50/50
I'm,
seeing
it
not
quite
that
but
I'm
also
yeah.
This
is
a
good
time
to
introduce
I'm
running
a
performance
tests
in
the
background
here,
there's
actually
a
bit
of
a
risk
because
they
and
you
know
doing
a
live
demo
here.
But
what
I
wanted
to
show
is
we
can
start
to.
You
know
it
sends
a
significant
for
sending
a
significant
amount
of
load
through
the
proxy.
What
happens
and
to
do
that.
A
Ultimately,
this
is
the
reason
I've
deployed
an
enterprise
glue,
so
what
I've
done
is
I've
kind
of
set
up
a
couple
scripts
that
are
pushing
as
much
traffic
as
they
can
to
the
proxy,
and
at
this
point,
as
we
saw
50%
of
the
traffic,
is
going
to
the
new
version
v2
of
the
service.
So
in
a
scenario
where
we're
really
trying
to
evaluate
how
is
the
new
version
performing
under
load,
we
can
jump
into
the
dashboard
and
we
can
really
compare.
A
What
did
things
look
like
you
know
at
prefer:
v1
versus
v2,
you'll
notice
that
I've
got
some.
You
know
so
just
to
kind
of
interpret
how
I'm
perceiving
these
are.
Our
demo
started
or
our
kind
of
webinar
started
at
one.
During
this
time,
I
was
doing
some
testing,
so
I
was
kind
of
taking
up
and
down
glue,
taking
up
and
down
our
echo
upstream.
A
A
And
what
we
can
see
is
we're
issuing.
You
know
between
100
and
200
requests
per
second
on
average,
and
all
of
them
are
coming
back
as
two
hundredths.
That's
great!
That's
what
we
expect
the
average
request
times.
Staying
pretty
low,
actually
quite
low,
we're
talking
fractions
of
a
millisecond,
and
you
know
overall
latency
or
sorry.
This
is
yeah,
it's
overall
latency
through
the
proxy.
You
know
these
requests
are
coming
back
really
fast
and
that's
good.
That's
what
we
expect.
That's
what
we
hope
in
fact.
A
A
You
know
a
larger
time
interval.
We
can
actually
see,
as
we
added
the
load,
testing
and
started
sending
traffic
to
our
real
services.
Our
echo
services,
you
know
that's
when
we're
getting
a
realistic
assessment
of
glue
and
the
performance
is
great.
So
we're
happy
I
think
at
this
point
we're
pretty
comfortable
and
I'm
going
to
fast
forward
the
progressive
part
of
the
delivery
and
update
the
virtual
service
to
send
the
rest,
the
other
50%
of
the
traffic
to
v2
and
as
soon
as
I
apply
this.
We
should
start
to
see
you
know.
A
So
we
can
go
back
to
a
very
simple
virtual
service
definition
here,
where
we're
still
using
subset
we're
just
going
to
kind
of
keep
that
as
part
of
our
operational
workflow
over
time,
you
know
will
be
incrementing
this
version,
but
at
this
point
in
time
you
know
this
is
the
state
of
the
world.
All
of
our
traffic
is
hitting
v2.
So,
let's
go
update
the
road.
A
A
And,
let's
just
make
sure
things
are
still
okay,
as
we
can
see,
you
know,
we
haven't
really
seen
any
interruptions
in
our
experience,
the
traffic's
going
exactly
where
we
expected
it
to
and
even
under
loads.
You
know
we're
pretty
satisfied
with
the
overall
performance
of
the
proxy
and
we
didn't
really
see
any
errors
through
envoy.
You
know
from
envoys
perspective,
as
we
were
kind
of
changing
the
destination
for
these
routes.
A
You
could
see
that
everything
I
was
doing
here
was
driven
by
simple
configuration
changes
here
in
the
mo
now,
as
you
probably
know,
glue
has
a
fully
declarative
configuration.
The
entire
state
of
the
of
the
proxy
itself
can
be
constructed
from
these
blobs
of
configuration
that
we're
storing,
really
the
source
of
truth.
Here
is
this
directory
on
my
file
system
or
in
a
really
it's
stored
in
a
repo
somewhere
and
I've
been
manually,
pushing
it,
but
you
could
imagine
a
workflow
where
you're
incorporating
this
into
a
more
of
an
automated
CIA
CD
pipeline.
A
Just
by
you
know,
and
over
time
you
might
be
modifying
this
route
destination
definition,
you
don't
really
need
to
make
any
other
changes
in
order
to.
You
know
achieve
this
progressive
workflow,
that's
really
nice.
If
we
took
advantage
of
some
of
glues,
features
related
to
decentralized
configuration
where
we
actually
make
the
you
know
these
virtual
services
more
self-service
or
we
use
delegation
to
allow
people
to
kind
of
define
the
routing
actions
for
a
particular
path
in
that
world.
A
We
could
imagine
different
teams,
you
know
the
echo
team
could
own
this
object,
or
at
least
you
know
this
route
definition
altogether.
That
works
out
of
the
box
today
with
open
source
glue.
So
you
know
really.
This
should
be
a
powerful
tool
to
have
in
your
toolbox,
for
even
when,
with
open
source
glue
for
kind
of
performing.
You
know
a
canary
workflow.
That's
both
you
know
satisfactory,
for
your
production
needs
we're
not
seeing
any
outages
or
interruptions
in
service.
A
A
A
As
we
talked
about
you
know,
the
next
steps
here
would
be:
how
do
we
actually
automate
this?
Could
we
integrate
tools
like
flagger,
it's
great,
that
I
can
do
this
manually,
but
it
would
be
even
better
if
I
could
have
automation
looking
at
those
metrics
that
I
cared
about
and
we
can
with
out
of
the
box
with
flagger
and,
ultimately,
you
know,
I've
done
this
demo
entirely
in
kubernetes,
but
glue
doesn't
have
to
work.
That
way.
You
know
the
core
architecture
of
glue
is
based
on
the
idea
of
abstracting
away
the
storage.
A
You
know
how
you
store
your
config,
how
you
store
your
secrets
and
how
you
discover
service
endpoints.
So
if
we
wanted
to
run
this
in
more
of
a
hybrid
or
off
of
kubernetes
scenario,
we
could
and
that's
really
relevant
to
kind
of
our
enterprise
partners
or
enterprise
users
who
are
dealing
with
more
complex.
You
know
underlying
environments
than
what
I
was
able
to
show
here,
but
that's
about
it.
If
you
have
any
feedback,
we'd
love
to
hear
it
I'm
you
know,
can
use
as
much
of
the
rest
of
the
time
for
questions.
A
If
you
have
them
and
generally
would
encourage
you
to
try
this
out
and
I
think
this
is
a
workflow
that
could
form
the
start
of
a
real
production
of
operational,
a
way
to
manage
your
operations
and
we'd
love
to
hear
your
feedback
with
that.
Betty
I'll
pass
it
over
to
you
to
see.
If
there's
any
questions.
B
Punch
them
into
the
Q&A
window
and
I'll
read
them
off
to
Rick
here
and
ask
what
we'll
do
is
both
as
a
follow
up
to
this
session,
we'll
send
up
and
recording
the
links
of
the
blog
and
all
those
resources
there
be
great
to
get
feedback
in
the
community
slack
on.
If
you
tried
this
and
if
this
works
in
or
variations
that
you're
trying,
because
you
know
these
are
all
like
these
are
recommended
things
to
kind
of
get
you
started,
but
as
we
every
environment
is
different,
every
Apple
is
different.
B
Your
needs
are
different,
so
love
to
have
that
information
sharing
with
the
other
users
in
the
community
as
well.
So
a
couple
of
things
here,
you
know
I
think
this
is
a
good
question
and
that
does
a
gateway
proxy
work
as
an
ingress
I
think
that's
a
little
specific
on
the
name
of
the
different
objects.
Yeah.
A
So
there's
kind
of
two
ways
that
question
to
interpret
that
one
is
like
you
know,
as
in
kind
of
an
entry
point.
You
know
in
the
lowercase
ingress
sense
of
the
words
you
know:
I
am
using
glue
gateway
as
my
kind
of
entry
point
for
the
cluster
and
I.
We
I
have
the
kind
of
load,
balancer
service
and
so
Google
is
providing
me
kind
of
this
IP
address
externally
available.
A
So
in
that
sense,
yes,
it's
kind
of
ingress
service
here
in
terms
of
being
the
kind
of
cube
or
Nettie's
ingress
object
in
this
case
I'm,
not
using
that
I'm
kind
of
using
the
Gateway
mode
and
I'm
doing
that
specifically
to
take
advantage
of
some
extra
features
that
we
can
expose
around
subset,
routing
weighted
destinations
and
specifically
through
envoy.
But
there
is
a
mode
of
glue
or
you
could
use
it
as
a
controller
for
those
capital,
I
ingress
kind
of
see
our
resources
in
kubernetes
I.
Just
didn't
you
know,
I
didn't
showcase
that
here.
B
Actually,
that's
and
then
one
good
thing
is.
If
you
have
question
around,
you
know:
lowercase
I,
the
ingress
or
uppercase
I
ingress
is
a.
If
you
check
out
our
who
live
stream
series,
the
one
that
we
did
I
believe
it
was
last
week
kind
of
talked
about
like
ingress
versus
API
gateway,
like
and
kind
of
explained,
the
role
of
proxies
and
the
different
modes.
So
that'd
be
a
good
primer
because
I
think
ingress,
sometimes
as
a
word
is
used
for
both
and
it's
good
to
get
that
clarification
again.
A
Actually,
just
one
other
thought
on
that
Betty,
you
know
I
think
when
we
originally
built
glue,
the
the
v1
ingress
in
kubernetes
was
pretty
limited
in
terms
of
the
functionality
we
are
excited
about.
You
know
the
v2
version
of
this
there's
a
working
group,
that's
kind
of
defining
a
new
new
ingress
definition.
B
A
I
think
the
so
we
do
have
plans
to
add
more
support
for
TCP,
proxying
I.
Think
a
lot
of
the
things
I
was
showing
we're
really
required
kind
of
HTTP
like
l7.
So
like
matching,
you
know
the
phase,
one
where
I
was
matching
on
the
header.
You
know
B,
we
kind
of
need
to
define
ways
to
to
make
this
work
and
if
we're
just
using
glue
as
a
TCP
proxy,
we
are
planning.
We
are
planning
some
work
related
to
this
expanding
the
capabilities
of
our
our
glue
TCP
proxy.
B
A
It's
a
good
question,
so
it's
not
something
I've
really
tried.
I,
think
I
see
the
value,
so
something
I'd
be
interested
to
explore.
After
this
you
know
my
initial
thought
off
the
top
on
this
is
that
I
would
want
to
look
into
the
behavior
of
on
of
kubernetes
when
I,
like
the
health
check
for
pods,
is
kind
of
triggered.
One
thing
that
we've
seen
or
what
you
know,
one
thing
to
point
out
is:
there's
some
fallback
behavior
in
our
in
envoy.
A
So
if
you're
trying
to
route
to
a
subset
that
doesn't
exist,
I
believe
it
falls
back
to
just
the
service
selector
as
a
whole.
So
it's
kind
of
the
fallback
that
you're
describing
the
bit
of
information.
That
I
don't
know
right
now,
but
I'd
love
to
figure
it
out
is
I
can
does
that
fall
back
happen
when
the
health
check
is
triggered
and
and
how
do
we
actually
configure
that
so
great
question
I
think
it
would
be
something
that
would
be
valuable
to
kind
of
incorporate
into
this
workflow
for
exactly
the
reason
you
described.
Yes,.
A
B
A
And
what
we
see
so
I
will
preface
this
with
saying
that
I'm.
My
bias
is
that
key
ally,
I'm
kind
of
intrigued,
I,
assume
key
ally,
is
kind
of
a
great
GUI
for
kind
of
managing
your
sto
mesh.
Overall,
it's
kind
of
packaged
with
this
geo.
That's
been
my
experience,
working
with
it
specifically
with
this,
do
and
glue
and
do
work
great
together.
A
To
what
extent
can
we
bring
in
you
know,
metrics
and
other
things
from
the
Envoy
at
the
edge
that
isn't
technically
an
sto
sidecar,
but
is
you
know,
envoy
its
publishing
metrics
its?
If
there's
config
that
it
you
know,
Kelly
should
be
able
to
interpret
so
a
good
question.
I,
you
know
that's
kind
of
my
initial
thought
off
the
top
of
my
head.
B
A
Yeah,
so
what
we,
what
we
could?
You
could
imagine
now
that
we
have
this
primitive
and
you've
seen
this
workflow?
You
could
imagine
that
and
you
could
imagine
the
workflow
being
potentially
much
more
involved
or
there's.
Maybe
many
more
steps
along
the
way
in
phase
two
as
I
was
mentioning.
You
know,
maybe
one
two
three,
maybe
you'll
kind
of
do
it
with
a
Fibonacci
increasing
or
you
know
doubling.
A
So
that's
the
part
that
needs
to
be
automated,
but
to
automate
it.
You
also
need
to
incorporate
your
metrics,
and
so
that's
kind
of
the
two
things
that
you'd
utilize
a
tool
for
something
like
flagger
as
you
utilize,
a
tool
like
flagger
to
to
solve.
So
we've
got
the
underlying
primitives
that
we
can
be
editing
and
that
are
publishing
the
right
metrics.
Now,
how
do
we
kind
of
orchestrate
it
and
so
with
flagger?
A
We
could
be
kind
of
automatically
updating
it's
on
our
CRTs
and
we
could
be
querying
Prometheus
with
various
business
metrics
that
we
define
and
it
could
help
really
assess
our
service.
You
know
SLA
s
and
things
like
that.
Our
business
metrics
that
we
would
use
to
feel
confident
at
scale
with
our
new
version
of
the
service,
so
so
those
are
the
two
things
that
we'd
really
utilize.
You
know
to
try
and
integrate
with
with
flagger
the
whole
point.
A
You
know
you
I,
don't
I
didn't
want
to
kind
of
over
complicate
our
scenario
here,
there's
ways
that
we
can
kind
of
separate.
For
instance,
if
we
looked
at
you
know
this,
we
could
kind
of
pull
this
off
into
its
own
object.
If
we
wanted
to
do
that,
that
object
in
blue
is
called
an
upstream
group,
and
that
gives
us
the
kind
of
ability
to
granularly
set
weights
just
on
that
object
and
then
glue
will
be
responsible
for
kind
of
assembling.
A
All
of
that
I
believe
I
believe
our
integration
with
flagger
utilized
that
so
utilize
it
as
an
upstream
group
but
you
know,
would
would
be
eager
to
kind
of
actually
run
through
that
and
a
follow
up.
Yeah,
that's
those
are
the
two
points
that
we
would
be
integrating
to.
Ultimately,
try
not
to
make
this
workflow
you
kind
of
need
to
have
something:
that's
changing
the
weights
based
on
your
workflow
definition
and
and
ultimately,
based
on
the
kind
of
results
of
computing,
different
business,
metrics
and
so
you're
kind
of
accessing
this
and
you're
accessing
Prometheus,
I.
B
Want
to
say
we
we
have
done
a
demo
a
while
back
related
to
an
integration
with
flyers.
So
what
I'll
do
in
the
follow-up,
for
this
is
also
take
that
up.
So
you
all
can
see
the
demo
that
we
have
in
case
that
it
was
a
while
ago.
So
it
might
be.
You
know,
there's
there's
been
new
features
added
to
both
our
you
know
our
products,
our
products,
as
well
as
on
the
flagger
flyer
site,
so
I
think
it's
a
good
opportunity
for
us
to
actually
do
a
refresh
of
that
and
Rick.
A
And,
and
just
to
echo,
that
you
know
one
shout
out
to
Stefan
and
the
the
weave
works
team,
they've
done
a
bunch
of
work
recently
with
new
versions
of
flagger
I
think
they
just
released
a
1o,
among
other
things,
so
definitely
we're
overdue
for
kind
of
looking
at.
You
know
basically
kind
of
playing
around
with
that
integration
again,
and
it
would
be
a
great
follow
up
here,
like
you
know,
now
that
we
understand
the
workflow
with
boo,
how
do
we
automate
it?
A
My
my
goal
here
was
really:
we've
got
a
fairly
large
user
community
that
you
know,
people
that
are
using
glue
now
and
really
want
to
kind
of,
and
then
a
lot
of
those
users
and
a
lot
of
those
no
platform,
architects
and
engineers
and
developers
are
kind
of
looking
to
us
to
help
with
defining
these
operational
workflows.
So
as
we
define
these,
then
we
can
kind
of
then
work
to
automate
them.
B
A
And
basically,
what
what
were
what
you
would
do
is
glue
has
actually
two
abstractions
that
it
uses
to
determine
the
overall
configuration
for
Envoy,
because
envoy
is
actually
exposing
off
of
different
ports.
Listen
reports,
different
sets
of
routes,
so
glue,
is
both
taking
your
routes
and
then
also
taking
your
gateways.
Crts,
that's
kind
of
the
the
CRT
I
was
referencing,
that's
different
than
the
ingress
CRT.
It's
taking
those
two
things
and
it's
computing
the
kind
of
assembled
proxy
configuration.
So
what
we've
seen
with
you
know
what
you
can
do
to
enable
TCP
glue.
A
Is
you
don't
really
need
to
define
virtual
services?
You
can
kind
of
define
a
listen
report
and
define
the
tcp
right
on
the
gateway,
object
itself
and
glue
knows
how
to
kind
of
translate
that
into
your
and
into
like
the
Envoy.
The
proxy
config
I
was
looking
for
an
example
of
that,
but
I
would
have
to
find
it
in
the
docs,
but
but
yeah.
That's
that's
essentially
how
it
would
work.
B
B
A
Yeah,
so
this
is
kind
of
what
I
was
talking
about.
This
is
glues,
intermediate
representation,
so
we've
we
could
have
the
proxy
object.
That
adds
all
your
routes
or
we
could
have
kind
of
you're,
just
you're,
just
a
very
simple
TCP
listener
that
just
tells
you
the
destination
and
the
way
that
looking
for
the
Gateway
object,
but
oh
yeah.
The
way
that
you
would
define
that
with
glues
is
defining
an
object
like
this.
That
actually
specifies
your
TCP
hosts
essentially
and
the
and
the
bind
port
that
you
want
to
expose.
B
A
I
I'll
be
honest,
I
I,
don't
know
it
wasn't
the
I
wouldn't
be
surprised
because
I
think
Stefan
and
the
team
have
like
really
thought
through
a
bunch
of
different
kind
of
use
cases,
whether
it's
progressive
delivery
in
the
way
that
we've
gone
through
it
or
a/b
testing
or
other
kind
of
use
cases
for
these
traffic
shifts,
but
I,
couldn't
you
know,
I'm,
not
I,
I
haven't
looked
at
it
closely
enough
to
give
you
a
definitive
answer.
So
maybe
you
know
we
should
follow
up
with
with
the
weave
works.
B
Yeah
totally
and
they
are
very
active
just
online,
and
so
you
know
Stefan
is
always
on
Twitter
as
well
as
you
can
probably
also
find
them
in
the
the
CN
CF
communities
plaque
and
so
they're
always
answering
questions
in
there.
So
that's
also
+,
so
actually
and
then
with
that
Rick.
If
you
just
want
to
go
to
that
last
slide
in
the
presentation.
A
B
Very
last
slide
slide.
11
thanks
everybody
for
joining
we've
got
some
links
here,
we'll
send
out
the
slides
and
the
recording
as
well,
and
some
of
the
additional
links
that
we
mentioned
to
help
answer
some
of
the
questions
that
folks
had
on
the
call
today,
but
then
to
learn
more.
You
know:
we've
got
the
link
to
the
glue
product
page,
the
tutorial,
specifically
the
blog.
B
That
Rick
is
mentioning
that's
the
link
to
the
blog
and,
if
folks
specifically
want
to
try
this
and
you
know
or
have
a
PLC
that
you
want
help
with
there's
a
link
to
request
trial
with
that
and
then
hop
in
the
community.
There's
a
lot
of
a
lot
of
the
folks
on
this
call
today
are
folks
that
I
know
are
glue
users
today
running
in
production.
Others
might
be
just
kind
of
starting
to
explore
this
use
case.
We
have
a
lot
of
great
discussion
and
you
know
questions
and
answers
happening
in
the
community
there.
B
A
All
of
this
could
work
with
open-source
glue
and
that's
what
the
blog
post
was
really
geared
towards.
So
you
know
anyone
here
can
give
it
a
shot,
and
if
you
do
have
feedback,
please
you
know,
engage
in
slack
or
over
github
or
you
know,
send
me
an
email
whatever.
It
is,
we'd
love
to
hear
your
feedback
and
kind
of
learn
any
more
about
your
workflows.
Thank
you.
Everyone
great.