►
Description
In this video, Steve Sloka explains how Contour makes Kubernetes Ingress easy to use, and how to enable blue/green deployments of your public facing apps.
A
Hi,
my
name
is
Steve
sloka
and
one
of
the
maintainer
of
contour
and
today
I'm,
going
to
give
you
a
quick
overview
of
how
Bluegreen
deployments
can
work
with
contour
I
also
want
to
give
you
this
start
out
again
a
30
second
overview.
How
contour
looks
and
works
will
discuss
how
ingress
route
works.
Ingress
route
is
a
custom,
CRD
custom
resource
definition
that
we
developed.
It
will
help
us
kind
of
extend
the
functionality
of
how
ingress
works
today
in
a
kubernetes
cluster
and
we'll
look
at
two
ways
to
a
deploy
or
apply
a
Bluegreen
deployment.
A
One
way
will
be
using
delegation
with
our
ingress
route
and
the
other
way
will
be
using
shift
weight
shifting
within
the
ingress
route
as
well.
Let's
go
ahead
and
dig
in
so
contour
is
an
ingress
controller
for
kubernetes.
It
leverages
envoy,
as
the
data
plane
proxy.
So
all
data
traffic
is
going
to
route
through
envoy.
A
Inc
contour
again
is
an
ingress
controller,
so
it
does
a
watch
on
the
kubernetes
api
and
it
looks
for
all
resources
that
it
needs
to
watch
so
things
like
services,
endpoints
secrets
and
ingress
resources
when
it
sees
any
of
those
change.
It'll
go
ahead
and
build
a
new
configuration
in
memory,
and
then
it
will
stream
those
changes
down
to
envoy
over
a
gr,
PC
connection,
so
ongoing
contour
talk
through
G
RPC
contour
is
the
xdf
server
and
envoy
is
the
client,
so
envoy
is
going
to
look
to
contour
for
all
of
his
configuration
items.
A
So
when
a
request
comes
in
from
the
internet,
it's
going
to
get
routed
to
some
sort
of
load
balancer.
This
could
be
some
cloud
load
balancer.
This
could
be
some
sort
of
on-premise
system.
This
would
also
be
a
way
that
we
can
just
drive
traffic
to
envoy,
doesn't
matter
how
we
get
there.
We
have
to
just
drive
traffic
to
an
instance
of
envoy
once
the
Envoy
gets
it.
It's
gonna,
it's
an
l7,
elf
or
proxy.
So
it's
gonna.
Take
that
request
determine
where
it
should
go
and
then
route
it
to
somewhere
within
the
cluster.
A
A
So
that
there's
issues
today
where
teams
can
take
down
production
clusters
if
they
write
conflicting
records-
and
this
is
aims
to
help
solve
some
of
those
issues.
We
do
this
do
a
thing
called
delegation
and
the
next
side
will
describe
it
a
little
further.
But
delegation
is
a
way
that
we
can
pass
Authority
off
to
other
ingress
resources.
A
We
also
want
to
provide
a
sensible
home
for
common
configuration
parameters
and
do
this
without
adding
more
annotations
to
our
service,
so
things
like
service
waiting
and
load
balancing
and
other
things
give
them
a
proper
home
within
the
spec.
So
what
is
blue
green?
So
blue
green
is
a
deployment
methodology.
It's
a
way
that
you
can
basically
route
traffic
from
one
version
to
another.
So
this
an
example
container
c-calm
is
my
fully
qualified
domain
name
and
it's
going
to
receive
traffic
and
we're
gonna,
configure
it
to
send
traffic
to
the
blue
service.
A
So
within
my
cluster
I
have
a
blue
service.
That's
hailing
the
production
traffic
today.
What
do
I
do
is
go
build
my
new
version
engineer
it
you
know:
do
my
testing
do
all
the
sort
of
things
and
then
I'll
deploy
that
as
the
green
version,
so
the
new
version
once
it's
up
and
running
I?
Can
you
know,
do
my
own
snow
tests
on
that
within
the
cluster
I
can
see
how
it
looks
and
performs,
and
if
I'm
happy
with
it,
what
I'll
do
is
I'll
remove
traffic
from
blue
and
I'll?
A
Swap
it
over
to
green
and
we'll
do
this
instantaneously
I'll?
Do
it
all
at
once,
then
then,
once
this
happens,
then
basically
my
new
version
is
deployed
and
everything's
great.
If
I
find
issues,
I
can
always
reverse
that
scenario,
and
just
swap
it
back
to
blue.
You
know,
should
I
find
some
sort
of
production
issue
or
some
sort
of
problem.
I
can
always
go
back
to
the
last
working
version.
A
So
that's
the
idea
of
how
we're
gonna
apply
these
Bluegreen
deployments,
but
if
it's
of
this
are
that
you
can
support
applications
that
maybe
can't
manage
two
versions
at
the
same
time.
So
if
your
app
just
can't
handle
having
you
know,
version
1
version
2
running
concurrently,
maybe
you
have
some
sort
of
dependency
on
another
resource
like
a
database
or
something
you've
got
a
run
database
migrations.
So
it
may
not
be
possible
to
run
you
know
a
canary
type
deployment.
A
So
let's
go
ahead
and
dig
in
and
see
how
inger
sprout
can
help
solve
this
for
us,
so
ingress
route
uses.
This
thing
called
delegation
and
delegation
follows
the
model
of
Health
DNS
works,
so
DNS
says
hey
if
I
go
by
a
domain
name.
So
if
I
buy
VMware
com,
I
own
the
domain
name
and
then
I
can
give
that
authority
for
that
domain,
name
to
a
DNS
server,
and
once
that
DNS
server
has
authority,
it
can
do
whatever
it
wants
with
it.
A
It
can
dish
out
any
kind
of
you
know,
path
or
portion
of
that
of
that
Nam
of
that
domain.
If
I
want
I
could
take
a
piece
of
that
domain
and
I
can
give
authority
to
that
to
print
server
right
when
I
carve
off
that
piece
that
new
server
now
has
permissions
on
that
ones
fast
spec.
This
is
how
delegation
is
going
to
work.
So
delegation
is
gonna,
say:
hey
I
have
route
this
route
ingress
route,
which
is
VMware
comm
and
we're
gonna
carve
off
a
path.
So
in
this
case
it
is
slash
blog.
A
This
could
be
a
path.
This
could
be
a
subdomain.
However,
you
want
to
carve
it
out,
but
by
giving
this
Authority
this
now
this
ingress
route
here,
which
is
actually
a
different
namespace,
this
blog
name
space.
It
has
authority
over
slash
blog,
so
we
can
do
whatever
it
wants
with
it.
Now,
if
someone
else
comes
along,
you
know
willingly
or
unwillingly.
A
It
goes
ahead
and
creates
this
slash
blog
for
the
same
domain
name
typical
ingress
say
this
could
cause
an
issue
right
so
who
wins
because
they're
both
defining
the
same
domain
name
with
the
same
path?
Well,
if
fingers
route
this,
this
basically
can't
happen,
because
this
other
ingress
route
does
not
have
authority.
Nothing's
gonna
change,
no
one's
delegating
to
it
cool.
So
let's
go
ahead
and
take
a
look
at
how
this
looks
so
I
have
a
crew
based
cluster
running
out
here
and
I
have
container
c-calm.
So
this
is
the
route,
so
we
can
do.
A
Is
let's
go
ahead
and
take
a
look
at
all
my
ingress
routes
and
you
can
see
I
have
three
right
now.
So
let's
ignore
the
first
two.
These
are
from
I'm
monitoring
in
metrics.
But
what
I
have
here
is
my
route.
So
I
have
this
route
blog
and
you
can
see
it's
containers
to
calm
and
it's
using
a
TLS
secret,
so
we're
gonna
terminate
TLS
there
and
the
route
is
slash,
so
all
routes
are
gonna
are
gonna
hit
here.
A
So
if
I
enter,
you
know,
slash
blog
/d,
sloka,
right,
everything's
gonna
get
here
because
whoops,
because
it
has
full
permissions
to
the
whole
the
whole
path.
Alden,
it
almost
path
so
slash.
So
let's
go
ahead
and
deploy
an
application.
So
what
I
have
is
I?
Have
this
marketing
team
and
the
marketing
team
came
to
me
and
says:
hey
I
want
to
go,
deploy
my
own
app
and
what
they
have
is
they
have
a
working
name
space.
A
So
if
I
get
my
namespaces,
you
can
see
I
have
this
marketing
one,
and
this
is
where
the
marketing
team
is
going
to
deploy
their
application.
So
we'll
do
is
we
will
go
ahead
and
will
pass
delegation
off
to
the
marketing
team.
So
if
we
come
down
here,
we'll
just
pull
this
up
and
what
we'll
do
is
well
we'll
give
delegation
to
this
team,
so
we'll
say:
hey
marketing
team,
so
the
namespace
marketing
go,
create
an
aggressor
out
called
blog
and
we'll
delegate.
A
A
A
Yet
as
well,
dues
will
go
ahead
and
create
that
so
I
have
this
blog
one
here
so
now,
what
we'll
do
is
we'll
look
at
the
marketing
team,
so
here's
the
marketing
namespace
and
it's
called
blog
and
here's
our
path,
slash
blog
and
they're
gonna,
say:
hey,
listen,
send
this
to
the
blue
service
right.
So
let's
go
ahead
and
deploy
this,
so
we
will
go
ahead
and
into
control,
apply
and
will
apply
the
blog
that
an
ingress
route.
A
So
now,
if
we
go
ahead
and
get
our
ingress
routes
will
see
a
new
one
here
see
this
marketing
one,
and
this
first
route
is
slash
blog
and
it's
valid.
So
now
what
should
happen
is
if
we
come
here-
and
we
refresh
this
now
we
get
the
marketing
blog
right.
So
here's
the
blog
website.
If
I
go
back
to
my
route,
it
should
still
be
the
route.
So
there's
our
two
different
places
network
handling
this
the
route
owns,
slash
and
now
blog
owns
slash
blog
now,
because
we
delegated
slash
blog
to
this
user.
A
If
I
go
to
Steve
/local
again
like
we
did
before
marketing
team
now
owns
that
right,
because
we've
delegated
off
slash
blog
to
them,
so
they
own
everything
after
that
path.
Unless
we
do
a
further
delegation
somewhere
else
cool
all
right,
so
let's
go
ahead
and
do
our
Bluegreen
deployment.
So
we
want
to
go
and
spin
up
our
other
service.
So
in
our
our
marketing
namespace
we
have
a
green
service.
A
A
This
it
block
to
great
now,
if
we
go
ahead
and
get
our
ingress
routes
again,
we'll
see
you've
another
one
and
now
here's
two
of
in
the
marketing
space
namespace.
Now,
what
we'll
see
is
this
blog
to
is
status
is
orphaned
right.
It
says
this
ingress
route
is
not
part
of
a
delegation
chain
from
a
route.
So
what
this
means
is
that
no
one's
delegating
to
this
blog
to
which
is
actually
what
we
want
right.
A
So
if
we
look
at
our
application,
it's
still
the
marketing
blog
and
everything's
fine,
but
because
we
haven't
delegated
to
it,
it's
showing
that
it's
it's
you
know
invalid.
So
what
we're
gonna
do
is
we're
going
to
leverage
this
idea
of
this
delegation
chain
to
implement
our
Bluegreen
deployment,
so
we're
gonna
do.
Is
we're
going
to
go
ahead
and
we're
going
to
swap
the
delegation
from
blue
to
green
and
our
route
here?
A
So
we'll
go
ahead
and
say:
let's
go
from
blog
the
blog
to
and
what
we'll
do
is
well
now
delegate
to
block
two,
which
is
our
green
deployment
and
we'll
take
off
the
delegation
from
the
blue
one
and
what
that'll
do
is
it'll
instantly
send
traffic
from
blue
all
it
to
green,
so
next
request
coming
in
will
be
on
the
green
right.
So
let's
go
ahead
and
let's
see
we
can
visualize
this
a
little
better.
So
let's
do
if
I
could
do
a
while
loop,
so
we'll
hit
the
slash
blog
every
point
one
seconds.
A
This
will
help
us
just
kind
of
visualize
this
great
and
now
what
we'll
do
is
we
already
updated
our
website,
our
route
to
be
blog
to
and
we'll
apply
this?
So
if
we
go
ahead
and
cou
control
applied
a
chef
and
we'll
apply
the
ink
with
the
route
now
as
I
hit
enter
we're
gonna.
We're
gonna
shift
the
delegation
chain
from
blue
to
green,
and
you
can
see
now
here
instantly
the
green
one
is
now
getting
all
the
traffic
now.
A
If
we
watch
our
metrics,
we
watch
all
of
our
stuff
and
go
now
we're
seeing
a
you
know,
a
spike
in
errors
or
a
high
latency
coming
out
of
it.
We
can
see
something's
wrong
and
we
can
swap
back
if
we
want
to
so
again
we'll
just
change
this
delegation
chain
back
to
blue
and
we'll
just
reapply.
This
you'll
see
let's
go
back
to
green
or
blue
I'm,
sorry
cool!
A
So
that's
how
delegation
can
help
you
do
this
now,
the
only
we
can
do
this
is
we
can
do
this
with
a
with
waiting,
so
what
we
can
do
is
pass
off
so
right
now
we're
delegating
to
blue
right.
Well,
dues
will
go
down
here
to
our
blue
one
and
we'll
have
second
service.
So
one
of
the
features
of
ingress
round
is
we
can
have
multiple
up
streams.
So
here
I
can
say
this:
one
service
gets
multiple
multiples.
You
know
back
in
upstream
services.
So
if
I
go
ahead
and
apply
this,
this
one.
A
Will
apply
the
blog
and
what
happens
now
is
that
we've
said
hey
both
applications
get
traffic,
and
this
is
kind
of
how
we
implement
a
canary
deployment
and
what
you'll
see
is
I'll
get
I
should
get
just
about
half
and
half
traffic.
It's
never
gonna
be
concurrent
percent
consistent,
but
about
each
one's
getting
about
the
same
amount
of
traffic,
but
what
I
can
do
now
is
I
can
add
weights,
so
I
can
add
weight
here
and
I
can
say:
hey
blue
gets
100
percent
of
traffic
or
100
points.
A
A
Now,
if
I
want
to
go
ahead
and
do
a
Bluegreen
deployment
in
this
model,
I'll
just
swap
my
weights
out
to
give
blue
zero
and
I'll
get
of
green.
A
hundred
and
essentially
doing
the
same
thing
that
I
did
with
delegation,
but
we're
doing
it
with
waiting.
So
if
I
apply
this
now
instantly,
the
green
one
gets
all
the
traffic.