►
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
Contour is an open source Kubernetes ingress controller providing the control plane for the Envoy edge and service proxy. Contour supports dynamic configuration updates and multi-team ingress delegation out of the box while maintaining a lightweight profile.
Using Contour you can quickly deploy cloud-native applications, update Envoy configurations on the fly, and safely delegate ingress configuration to protect service access on multi-team Kubernetes clusters.
In this webinar, Steve Sloka, Sr. Member of Technical Staff at VMware, will share how to use Contour and Envoy efficiently in your Kubernetes clusters.
A
They're
due
I'd
like
to
get
started,
thank
you
for
joining
us
today.
Welcome
to
today's
CN
CF,
webinar,
contour,
high
performance,
ingress
controller
for
kubernetes,
I'm,
Chris
short,
a
principal
technical
marketing
manager
at
Red,
Hat
and
a
cloud
native
ambassador
I'll
be
moderating
today's
webinar
few
hi
you
housekeeping
items
before
you
get
started
during
the
webinar
you're,
not
able
to
talk
as
an
attendee
I'm.
Sorry.
A
A
A
B
Hey
thanks
Chris,
so
good
morning,
good
evening,
good
afternoon,
everyone
yeah
again
I'm
Steve
sloka
and
today
we're
going
to
talk
about
contour
and
contour
is
an
ingress
controller
for
kubernetes.
So
quick,
look
at
the
agenda
for
today
we're
gonna
review
kind
of
what
ingress
is
so
we
can
help
level
set
your
background
just
to
be
on
the
same
playing
field.
We're
gonna
go
and
look
at
contour.
You
know
what
is
it?
How
does
it
work?
B
What
are
the
components
that
make
it
up
then
we'll
dig
into
this
CRD
that
we
wrote
called
HTTP
proxy
and
we'll
look
at
why
we
built
that
and
some
of
the
reasons
around
you
might
want
to
use
that
versus
you
looking
at
using
ingress
today
and
then
we'll
do
a
bunch
of
demos.
So
I've
got
a
whole
whole
slew
of
demos.
We
can
dig
into
and
I
think
majority
of
today's
talk
will
be
live
coding
on
a
server,
so
it
should
be
fun.
B
So
let's
dig
into
and
figure
out
what
ingress
is
right,
so
ingress
itself.
When
you
think
of
that
generically
it
means
incoming
right.
So
I
can
talk
about
ingress
traffic.
You
know
coming
into
my
network-
and
this
is
the
same
for
kubernetes,
so
ingress
and
kubernetes
LAN
is
the
ability
to
route
traffic
from
outside
the
cluster
or
from
the
inner
it
into
your
cluster
and
route
that
to
a
service,
an
ingress
uses.
B
This
l7
protocol
of
the
application
stack,
so
it's
able
to
route
requests
based
on
the
host
header
in
the
path
combination,
so
I
like
to
look
at
ingress
and
then
think
about.
Will
why
hide
it?
Why
would
I
use
something
else
right?
So
let's
look
at
alternatives,
real,
quick
and
then
we'll
see
why
ingress
may
be
a
good
fit
for
what
we're
trying
to
do
so.
B
I
could
use
the
thing
called
node
ports
and
I
put
node
points
and
load
balancers
together
because
they
kind
of
fit
hand-in-hand,
but
a
node
port
type
service
and
kubernetes
will
expose
a
random
port
on
your
cluster
and
that
30,000
range
by
default.
Whenever
I
expose
that
service
on
that
port,
if
I
hit
any
node
in
the
cluster,
then
traffic
will
route
to
my
application,
so
this
works.
The
problem
here
is
that
I've
got
a
whole
bunch
of
random
ports.
B
Now,
depending
on
how
many
applications
I
have
and
I've
got
to
manage
the
life
cycle
of
all
those
nodes
right
so,
if
I
know
goes
unhealthy
and
my
cluster
I've
got
a
connected
out
of
service
load,
balancer
kind
of
works,
hand
in
hand
if
you're
an
environment
that
has
a
you
know,
a
cloud
provider
or
something
like
that,
you
can
create
a
service
type
of
load,
balancer
and
essentially
behind
the
scenes.
You
creates
you
a
node
port
service,
but
it
also
provisions
a
load
balancer
outside
of
the
cluster,
and
this
load.
B
Balancer
will
then
send
traffic
to
your
cluster,
and
this
will
solve
the
problem
easily.
The
problem
is:
is
that
how
many
applications
are
going
to
live
in
your
cluster
right?
There's
a
quantity
of
those
applications
there's
also
a
cost,
whether
you're,
you
know
an
on-premise
environment
or
the
cloud
environment,
some
sort
of
cost
associated
with
this,
as
well
as
complexity,
so
let
alone
having
all
of
these
ports
open
up
in
your
cluster.
So
your
security
team
may
not
be
happy
with
all
these
different
entry
points.
B
Nothing.
You
could
use
our
thing
called
host
ports,
so
host
ports.
Basically,
map
a
pod
in
your
cluster
to
a
host
port
on
the
node,
and
this
again
would
be
another
solution
to
the
problem.
Is
you
can
only
have
one
per
cluster
right?
Only
one
port
can
map
port
80
or
one
can
map
port
80.
So
basically,
unless
you're
gonna
deploy
one
application
per
cluster.
B
So
this
diagram
here
is
an
overview
of
how
contour
looks,
and
you
can
also
apply
this
to
basically
any
ingress
control
or
instance.
So
again
we
have
our
traffic
coming
in
from
outside
the
cluster
and
we're
gonna
hit
some
sort
of
load
balancer
and
that
load
balancers
job
is
to
send
traffic
out
across
the
cluster
and
again
I'll
need
one
of
these
for
our
ingress.
B
Once
the
traffic
gets
to
in
our
case
envoy
for
contour
envoy
is
going
to
take
that
request,
inspect
it
and
then
route
it
to
the
right
place
within
the
cluster,
and
you
noticed
here
that
envoy
is
the
data
path
component
in
contour,
so
it's
the
one
handling
all
of
the
traffic.
All
of
the
the
network.
Routing
for
us
contour
in
this
scenario,
is
just
the
configuration
server
for
envoy.
So
contours
job
is
to
watch
the
cluster.
B
It's
gonna
look
for
services,
endpoints
ingress
objects,
these
HTTP
proxy
objects,
as
well
as
secrets,
and
when
any
of
those
things
might
change
in
the
cluster,
contour
will
rebuild
this
configuration
and
stream.
That
change
down
to
envoy
and
again
envoy
is
gonna
handle
all
of
the
traffic
and
again
they
said
this
is
an
l7
proxy
at
layer
seven.
B
There's
another
look
at
the
components
of
contour
again
we
said
that
contour
is
the
configuration
server
and
it
uses
envoy
as
the
data
plane
again
we're
deploying
this
to
kubernetes.
So
kubernetes
is
our
our
underlying
infrastructure.
We're
gonna,
deploy
this
too,
and
we
also
expose
Prometheus
metrics
an
envoy
as
well
as
contour,
and
you
can
use
Gravano
or
any
other
tool
that
can
consume
Prometheus
depending
on
your
environment,
so
feel
free
to
do
that.
But
again,
this
is
just
giving
you
the
overview
again
of
all
the
components
that
make
up
contour.
B
Let's
dig
into
some
more
highlights
of
contour
again:
contour
is
an
ingress
Controller
we're
using
envoy
as
the
data
plane
component
contour.
It
has.
Can
dynamically
update
its
configurations
without
dropping
connections,
so
whenever
those
services
or
endpoints
change
or
your
users
are
pushing
configuration
changes,
all
that
happens
in
real-time
or
near
real-time
and
those
changes
are
pushed
down
to
envoy
and
connections,
aren't
dropped
right,
there's,
no
reload,
there's
no
issue
of
receiving
that
update.
B
Contour
can
safely
support
ingress
in
multi
teen
clusters.
We
do
this
through
our
CRT
called
HTTP
proxy
and
we'll
dig
into
what
that
looks
like
and
feels
like
here
in
a
little
bit
that
multi-team
pattern
is
enabled
through
this
thing
called
delegation.
So
we
can
delegate
a
path
and
a
header
combination
down
to
namespaces
and
by
carving
off
these
different
pieces
of
the
path
we're
able
to
implement
this,
this
multi
team
or
multi-user
cluster
in
a
safe
way.
B
In
addition
to
having
a
30,
we
can
now
place
things
that
are
typically
annotations
in
ingress.
Today,
things
like
service
weights,
load
balancing
strategies.
You
know
prefix
rewrite
rules,
all
those
things
that
you've
got
to
deal
with
today,
that
maybe
don't
aren't
described
in
the
ingress
spec.
We
can
describe
them
in
a
place
within
our
C
or
D
again,
so
you
can
do
that
without
having
annotations
all
over
your
objects,
we're
able
to
support
in
multiple
up
streams
right.
B
So
if
you
ever
want
to
go
out
with
traffic
to
multiple
services
within
your
cluster,
this
is
helpful
to
do
things
like
Bluegreen
deployments
or
maybe
a
canary
deployment.
You
can
implement
this,
maybe
in
a
simpler
pattern.
By
allowing
you
have
to
have
multiple
services
to
route
traffic.
To
another
cool
thing
is
we
can
do?
Is
things
this
thing
called
TLS
or
certificate
delegation?
B
So
again,
an
ingress
today,
you've
got
to
have
your
your
secret
live
in
the
same
namespace,
where
your
ingress
object
is
right
and
if
you
have
a
secret
copied
across
multiple
namespaces
one
that
can
be
a
pain
to
manage
and
deal
with.
Getting
that
deployed
out.
So
you've
got
to
rotate
that
you've
got
updated,
multiple
places
and
and
three
your
users
have
access
to
those
private
keys
which
may
not
be
the
be
what
you
want.
B
So
with
contour
we
can
tuck
our
secrets
away
in
an
admin,
namespace
and
then
use
delegation
or
to
pass
that
the
permissions
off
to
other
teams
right,
so
basically
they
can
still
use
the
certificates
as
if
they
were
in
their
namespace,
but
they
don't
have
to
have
access
to
them.
So
it's
a
good
separation
of
concerns.
B
So
why
envoy?
Why
do
we
choose
envoy
when
we
started
bloating
contour?
Well,
its
dynamic
configuration
to
be
an
API,
so
I
mentioned.
This
is
one
of
the
first
wins
of
contour.
So
envoy
expose
is
a
GRDC
endpoint
and
it's
it's
their
XDS
protocol.
So
we
can
basically
contour
is
the
XDS
server
for
envoy
and
we're
going
to
stream
this
changes
again
down
through
that
gr
QC
connection.
B
We've
got
this
rich
connection
that
we
can
push
configuration
changes
down
to
and
again
not
have
to
reload
on
void,
for
that,
for
it
to
accept
them
on
void,
provides
first-class
support
for
HTTP
2,
as
well
as
G
RPC,
so
I'm
looking
for
the
future
and
what
our
users
are
looking
to
consume.
These
two
protocols
are
first-class
citizens,
an
envelope
and
it's
battle-tested
in
production
on
what
came
out
of
that.
B
The
engineers
that
lift
and
I
use
this
all
over
the
place-
and
this
has
become
a
well-known
component
in
lots
of
architectures
today,
I'm
gonna
kind
of
walk
through
a
situation
and
we're
gonna
look
at
basically
what
ingress
looks
like
today.
So
if
I
have
two
ingress
documents
right
here,
I've
got
one
on
the
left.
B
One
on
the
right
and
you'll
see
here:
I
have
it
one
is
for
Team
a
so
I've
got
one
team
here,
and
one
is
for
Team
B,
so
I'm
splitting
across
you
know
two
different
namespaces
here
each
team
has
created
their
own
object
and
they're
both
have
defined
the
hosts
of
project
contoured
at
I/o
and
I,
both
to
define
the
same
path,
slash
blog,
but
because
there
are
different,
namespaces
they're
able
to
set
different
services
throughout
traffic
to
so.
In
this
case,
team
a
is
writing
to
a
wordpress,
blog
and
Team.
B
B
is
routing
to
service
new.
Well,
the
question
comes
is
when
we
go
to
process
these
documents
together,
what
happens
right?
What
is
the
result
of
this
merge,
because
we
basically
have
conflicting
descriptions
of
what
this
should
look
like?
Really,
it's
undefined
right
and
this
could
be
dangerous
depending
on
how
your
controller
processes
these
it
could
be
the
last
one
in
wins,
the
first
one
in
wins.
Maybe
none
of
them
win
and
your
users
just
get
you
know
four
or
four
air.
So
this
is
one
of
the
things
we
look
to
solve
with
contour.
B
We
wanted
to
come
up
with
the
way
that
we
could
allow
users
to
still
self-manage
their
an
ingress
objects,
their
name
space,
but
not
have
to
deal
with
these
sort
of
issues
that
can
come
up,
and
this
is
a
common
scenario
where
maybe
you
have
this?
Is
your
production
application
here
and
then
you
go
and
deploy
a
new
application,
the
new
version
of
it
and
someone
just
you
know
accidentally
deploys
the
same
ingress
object
and
we've
taken
down
your
production.
So
we'll
look
here
how
to
how
we
can
solve
that
here
with
contour.
B
So
contour
can
do
that
with
this
thing
called
HTTP
proxy
and
if
you're
familiar
with
contour
in
the
past,
we
used
to
have
a
series
called
ingress
route.
Ingress
route
supported
a
path
prefix,
and
now
our
new
proxy
city
supports
path
prefixes,
as
well
as
headers
and
additional
information.
So
our
users,
over
over
the
last
year
gave
us
a
lot
of
feedback
as
to
what
we
wanted
to
do
with
that,
and
we
can
do
a
lot
more
now,
which
is
why
we
have
the
new
the
new
proxy
see
already
it's
again.
B
So
let's
look
at
how
this
delegation
can
work
so
generically
from
a
high-level
this.
This
works
is
that
at
the
end
owns
a
domain
name
right
in
my
case,
there's
project
contours
at
I/o
and
this
is
defined
and
what
we
sometimes
call
a
route
proxy
right
or
there's
this
top-level
route
item.
So
it
has
ownership
over
this
domain.
B
Another
team
comes
along
and
says:
hey
I
want
to
deploy
my
blog
site,
so
this
is
slash
blog
and
we
want
to
give
them
authority
to
do
that,
so
they'll
create
an
ingress
or
a
proxy
and
they'll
define
it
to
be
slash,
blog
and
we'll
implement
this
by
and
include
and
we'll
show
you
how
this
works
with
real
code
here.
In
a
second,
but
this
route
can
then
say:
hey
this.
Child
object
has
authority
to
manage
the
slash
blog.
B
So
in
the
case
that
someone
else
comes
along
and
they
say
you
know
what
I'm
the
dev
site,
I'm
gonna
go
in
or
create
a
path
of
slash
blog.
What
happens?
Is
this
contourable
throw
this
out
right,
because
this
proxy
here
does
not
have
authority
to
manage
that
that
path?
Slash
blog,
because
this
one
already
has
it
so
you
can
see
we
can
apply
this
to
paths
as
well
as
headers
and
other
things.
B
B
B
So
what
I
have
here
is
I
have
some
default
apps
that
I
wrote.
So
what
I
built
is
this
little
simple,
echo
server
and
what
the
server
does
is
it
spits
out
some
text
that
I've
defined-
and
this
is
just
to
help
us
understand
which
application
is
getting
the
traffic
and
then
and
it
spits
out
some
information
about
the
headers,
as
well
as
the
path
right
again
just
to
help
us
to
go
ahead
and
kind
of
see.
B
What's
going
on,
so
let's
go
ahead
and
deploy
that
so
we'll
apply
this
one
app
that'll
create
us
some
services
and
some
deployments
and
then
we'll
also
deploy
the
proxy
great.
Let's
dig
in
at
this
proxy
real,
quick
and
see
what
it
looks
like
so
you
see
here
is
I
have
my
version,
and
this
is
our
CRT.
So
this
is
project
contour,
that
io
/
v1
and
the
kind
is
HTTP
proxy.
We've
got
to
name
a
namespace,
but
here's
where
that
the
fun
stuff
happens.
So
here
we
define
this
fully
qualified
domain
name.
B
This
is
the
incoming
host
that
convoys
gonna,
look
for
in
my
case,
it's
demo
dot
project
contort
at
I/o
and
then
I'm,
defining
this
TLS
struct,
and
here
I'm,
saying
I
want
to
terminate
TLS
I'm
gonna
use
this
certificate
right.
So
if
I
go
and
look
at
I
get
my
secrets,
you'll
see,
I
have
a
corresponding
secret,
that's
called
TLS
wild
and
this
is
using,
let's
encrypt
through
the
cert
manager
from
the
jet
stack
folks.
B
So
this
went
out
and
got
me
a
wild
card
certificate
and
I'm
gonna
just
attach
that
and
use
it
now
that
we're
going
to
terminate
TLS
we'll
look
at
the
routes
on
here.
So
here
we
have
a
set
of
conditions
and
conditions
in
proxy.
Tell
you
what
conditions
need
to
be
met
for
this
route
to
match.
In
this
case,
I
have
one
is
just
slash
right,
so
this
is
again
the
generic
default
route.
So
slash
is
going
to
route
to
this
route
app
application.
B
B
So
if
I
do
a
curl
on
demo
dot
project,
contour,
dot,
IO
you'll
see
this
application
returns,
and
this
is
our
default
app
site
here
and
it's
slash
here.
You
can
see
the
headers
and
we'll
look
at
that
here
in
a
second
now
one
of
the
cool
things
that
that
you
might
have
noticed-
I
might
not
have
noticed,
is
here
I
inherently
said
HTTPS
because
we
defined
this
TLS
secret
here
in
contour.
B
Contour
is
going
to
be
secure
by
default,
so
other
times
you
might
have
might
have
had
to
annotate
your
object
to
say:
hey,
do
a
301
redirect
from
an
insecure
port
to
the
secure
port,
but
contour
will
do
that
for
you
automatically,
because
we've
seen
we
have
T
last
year.
So
here,
if
I
do
a
curl
on
the
insecure
port.
What
you'll
see
is
contour
will
reply
with
or
unavoidable
return
a
301
redirect,
and
this
is
hey
make
sure
you
go
to
the
to
the
TLS
version.
There
are
ways
around
this.
B
B
So
if
I
go
ahead
and
add
a
prefix
of
secure,
what's
gonna
happen
now
is
I
have
two
different
routes:
I
have
a
route
for
slash
which
is
going
to
send
traffic
to
route
app
and
I
have
a
route
for
slash,
secure,
which
is
going
to
the
secure
app.
So
if
we
go
ahead
and
apply
that-
and
if
we
do
a
curl
again
on
the
routes,
you'll
see
do
the
TLS
version
we
get
the
default
app,
which
is
what
we
wanted
I
do
it
on
slash,
secure
you'll,
see
now
I
get
the
secure
site
right.
B
So
that's
that's
cool.
Let's
make
this
a
little
more
interesting
right,
I
mentioned
before
that
conditions
are
all
the
requirements
to
make
this
this
route
match,
but
I
can
do
more
now
with
with
contour
than
just
prefix
and
previously.
So
what
I
can
do
is
I
can
add
a
header
to
this
and
I
can
say.
The
header
has
a
name
of
X
header
and
we'll
say
it
contains
the
value
ABC
right.
B
So
now
we're
going
to
route
on
the
existence
of
slash
secure
in
the
peep
and
the
path,
as
well
as
this
header,
on
the
request.
So,
if
I
go
ahead
and
apply,
write
and
I
do
the
same
curl
that
I
just
did
a
minute
ago.
If
we
curl
for
slash
secure
what
happens,
is
I
get
the
default
site
right
and
this?
This
is
true
because
we
we've
required
that
the
slash
secure
route
have
the
header
existing
on
the
request,
and
it's
not
there.
B
So
this
other
route
is
matching
that
condition
right,
because
it's
matching
slash,
which
is
which
is
true,
but
if
I
do
the
same
request
and
I
add
a
header
X
header
of
ABC.
What
you'll
see
is
I
get
the
request
to
the
secure
app
which
so
we've
defined
here
and
down
here
in
the
and
the
request.
If
you
see
here
the
bottom,
we
can
have
the
X
header
of
ABC
all
right.
So
again,
these
all
get
appended
together
and
those
all
have
to
match
for
the
proper
request
to
work.
B
B
Just
I
get
the
default
site
and,
if
I
hit
slash,
secure,
I
get
the
app
right
because
I'm
actually
in
Chrome,
but
if
we
switch
browsers
and
went
to
Firefox,
you
see
where
I'm
going
I
get
the
default
site
right.
I
got
the
default
one
here,
because
I'm
asking
for
only
having
Chrome
and
in
the
user-agent
headers
are
neat.
I
can
also
do
the
reverse,
so
I
can
say
not
contains
so
I
could
say:
hey
I,
don't
want
Chrome
and
I.
Don't
want
Firefox
right.
B
So
if
I
apply
that
one
now,
let
me
hop
back
to
Firefox
you'll,
see
I
get
the
default
site
because
we
don't
want
Firefox
if
I
switch
to
Chrome
you'll
see
that
in
the
default
one.
But
if
we
come
over
here
to
Safari
you'll
see
that
it
works
right
because
they
can
work.
This
is
not
matching
Chrome
or
Firefox.
It's
matching
Safari!
B
So
there's
how
conditions
can
work
and
function
in
your
app
so
looks
like
this
is
one
step
further
and
let's
look
at
delegation
so
I'm
just
going
to
take
these
off
for
now
and
we'll
have
just
the
path
now.
So
what
I
do
is
I
want
to
go,
deploy
it
another
app
right,
so
I
have
a
marketing
team
and
again
the
sooner
have
you
talked
about
in
the
slides
or
we
wanted
to
have.
The
marketing
team
have
slash
blog,
so
what
I
can
do
is
go
ahead
and
deploy
a
marketing
app.
B
If
I
do
a
good
control,
I
will
do
marketing
or
one
so
we'll
create
a
name
space
for
our
team
and
then
what
apply
some
apps
they're
gonna
have
a
couple
sample
apps
that
are
gonna,
help
us
deploy
this
thing,
all
right
cool.
So
now,
if
I
get
my
pods
in
the
name,
space
marketing
you
see,
I've
got
an
application
there,
and
I
also
should
have
proxy
or
two
proxies
right.
B
So
I
still
have
the
route
1,
which
we
deployed
just
a
second
ago
and
now
I
have
this
new
one
in
the
marketing
namespace
and
it's
called
blog
site
and
the
status
right
now
is
orphaned
right
because
we
haven't
defined
a
linkage
between
the
route
1
and
this
other
proxy.
We
haven't,
you
know
linked
them
together,
let's
go
ahead
and
do
that
so
well.
B
Do
I'll
go
ahead
and
bring
up
my
my
route
proxy,
which
is
here
and
then
this
one
is
my
child
1,
let's,
let's
put
together
so
maybe
this
will
help
to
see
them
again.
This
is
my
route
one
here
on
the
left,
and
this
is
the
child
one
here
living
in
the
marketing
namespace.
So
what
I
want
to
do
is
I'm
gonna,
go
ahead
and
add
this
thing
called
include
and
includes
in
contour
work
just
like
they
would
in
a
programming
language.
B
So
if
I
have
a
programming,
language
and
I
say
hey
I
want
to
include
a
header
file.
What
happens
is
when
that's
before
it's
compiled
that
header
file
gets
dumped
in
the
top
of
the
of
the
code
and
then
the
whole
the
whole
headers
is
processed
or
compiled.
The
same
thing
happens
here
right.
So
if
I
have
an
include
on
an
HTTP
proxy
you'll
see
that
I
can
tell
I
can
add
conditions
on
to
this
one
before
it's
processed.
B
B
So
let's
go
ahead
and
apply
our
route
proxy
right
and
then,
if
we
go
ahead
and
get
our
proxies
again,
you'll
see
that
now
they
should
both
be
valid
and
they're
valid,
because
now
we
have
a
proper
linkage
or
a
proper
delegation
from
this
route.
One
over
here
to
my
child,
which
is
in
the
marketing
namespace
and
the
result
of
what's
gonna
happen
here,
is
as
if
on
this
one,
we
define
a
set
of
conditions
like
this
right.
This
is
what
we
contour
goes
to
process
these.
B
These
conditions
will
exist
here
automatically,
but
we
won't
have
to
define
them
there
right
because
we're
passing
down
these
permissions
automatically.
Let's
go
ahead
and
test
this
out.
Let's
go
back
to
here
and
we'll
check
out
our
route
route
still
works.
Now,
if
I
hit
slash
blog,
what
I'm
expecting
to
see
is
the
blog
site.
B
Here
we
go
I've
got
that,
but
the
cool
part
is:
is
that
for
one,
this
child
proxy
doesn't
have
to
deal
with
TLS
they've
done
that
off
in
the
route
site
in
a
different
namespace
and
right
now
they
don't
have
to
deal
with
even
the
prefix,
because
that's
been
passed
off
to
them.
They
have
authority
to
manage
slash
blog
again.
If
someone
else
made
another
path,
prefix
of
slash,
blog
contour
and
throw
that
out,
because
it
doesn't
have
permissions
cool.
So
now
we
can
dig
deeper
right,
so
we
added
a
header
to
before.
So.
B
B
The
result
here
is
that
I
have
a
slash
blog
as
the
prefix
and
now
the
condition
is
I
have
to
have
a
user
agent
of
Chrome
right
because
all
of
the
conditions,
as
a
sum
are
passed
off
to
this
other
proxy,
so
we'll
go
ahead
and
apply
this
route
1
again
good.
So
now
in
kernel,
this
should
still
work,
and
it
does
she
get
the
blog
site
here.
B
But
if
we
hopped
over
to
Firefox
and
hit
this
path,
you'll
see
now
I
get
the
default
site
again,
because
our
child,
slash
blog,
requires
that
we
have
both
the
path-
slash
blog
as
well
as
the
huge
agent
user,
agent,
chrome
and
that
doesn't
match.
So
that's
why
it's
not
working.
So
you
can
see
where
this
is
kind
of
powerful.
If
you
had
to
have
a
bunch
of
things
exist
on
a
request,
you
can
define
them
up
here
and
again.
The
sum
of
that
rolls
down
I
go
so
another
demo.
We
can
do
real
quick.
B
B
So
now
again,
if
you
look
at
our
proxy,
it
should
have
three
of
them
on
the
blog
sites
valid
the
routes
valid,
but
this
new
one
here
this
info
one
is
orphaned
because
we
haven't
done
any
delegations
to
it.
Let's
go
wire
that
one
up
and
see
how
this
looks.
So,
let's
get
an
include
and
now
we're
going
to
add.
It
include
to
our
child
right
so
now
on.
This
include
Here
I
am
alright.
B
If
we
add
this
include
here,
this
acts
as
adding
additional
conditions
to
any
of
its
children
right,
so
the
root
owns
project
contour
da,
do
and
it
passes
off
/blog
to
this
proxy
here
now
this
proxy
is
gonna,
add
additional
conditions
and
pass
it
off
to
another
child
right,
so
it
has
another
child
of
its
own
and
that's
the
slash
info,
and
this
should
all
wire
up.
So
let's
go
ahead
and
save
this
child
one
here
in
marketing,
so
we'll
apply
marketing
o
to
proxy
great.
B
Now,
if
we
go
and
get
our
proxies
here,
we'll
see
they're
all
valid,
because
we've
tied
them
all
together.
But
what
happens
now
is
the
result
of
this
child
3
of
slash
info
gets
everything
appended
together.
So
the
result
should
be
slash
blog,
slash
info
as
well
as
the
user
agent
of
Chrome
right,
because
these
all
these
conditions
are
getting
applied
down
the
chain
because
of
the
includes,
let's
go
validate
that
this
works,
so
I'll
think
it
over
to
Chrome,
so
slash
blog
should
still
do
the
blog
site
if
I
hit
slash
blog
/
info.
B
B
So
what
I'll
do
is
I'll
go,
deploy
two
more
things,
so
here
I've
got
a
blue
deployment
and
the
green
deployment
and
they
basically
just
spit
out.
This
is
the
green
site,
or
this
is
the
blue
site.
That's
again
just
to
help
us
to
visualize
this
a
little
easier.
So
let's
go
ahead
and
apply
our
marketing,
then
we'll
do
for
green
as
well
as
before.
Blue.
B
All
right
cool!
So
now,
if
I
get
my
services
we'll
see
in
marketing,
we'll
see
I've
got
four,
but
now
I've
got
blue
and
green
all
right.
So
let's
go
ahead
and
update
the
slash
blog
here
and
we'll
change
this
one
to
blue
right.
So
now,
when
we
hit
slash
blog
I'd
expect
to
see
the
blue
deployment
respond,
so
we'll
go
ahead
and
apply
our
proxy
too
right.
So
we
deployed
that
child
there
and
just
to
verify
this
we'll
go
ahead
and
refresh
slash
blog.
B
You
see,
we
get
the
blue
site,
let's
go
ahead
and
look
at
doing
a
canary
deployment.
So
canary
deployment
works
where
you
have
two
services,
you've
got
your
current
version
and
your
new
version
and
what
you
want
to
do
is
slowly
move
traffic
over
to
the
new
version
or
the
green
version.
So
your
production
is
blue
and
your
new
version
is
green
and
we're
gonna
slowly
turn
the
knobs
and
and
send
traffic
from
one
version
to
the
next,
but
do
it
in
a
paste
environment.
B
This
can
be
done
easily
with
contour
now,
because
we
can
do
multiple
up
streams.
So
what
I
can
do
is
copy.
This
and
I
can
make
this
screen
right.
So
I
can
have
multiple
services
on
an
ingress
resource.
So
now
what
I
can
do
is
also
add
a
weight,
so
I
could
say:
hey
Luke,
it's
a
hundred
percent
over
a
hundred
points
and
the
green
one
gets
zero.
A
B
Let's
do
this
real,
quick
I
have
this:
let's
do
it
I
steal
a
while
loop
on
this.
Here
we
go
so
for
every
half,
a
second
we'll
curl
for
that
site
right.
This
will
help
us
see
it.
So
you
can
see
here
well
so
here's
the
thing
so
I'm
getting
a
default
site
because
my
route
is
requiring
the
user
agent
of
chrome
now
I'll
have
that
because
I'm
using
curl,
let's
go
ahead
and
change
that
real,
quick
and
take
that
requirement
out.
Actually
just
do
it
here
and
just
take
a
curl.
B
Now
we
should
get
blue
there,
we
go
okay,
so
what
I
want
to
see
now
is
that
it's
using
I
have
again
two
up
streams:
I
have
one
blue
service
than
one
green
service
right
now,
I
have
a
hundred
percent
of
the
traffic
going
to
blue
and
you
can
see
I'm
getting
the
blue
site
over
and
over.
If
I
want,
I
can
switch
this
around
I
could
say:
let's
send
eighty
here
and
ten
here,
all
right.
So
now,
if
we
apply
this
one,
what
I
should
get
is
mostly
the
blue,
but
I'll
get
some
green.
B
There,
it
is,
I,
saw
cream
in
there
cool.
So
as
we
can,
what
we
can
do
now
is
watch
our
metrics
watch.
Our
performance
see
how
this
is
performing.
If
well,
we
can
go
50-50
split.
The
traffic
mostly
I
mean
you
can
do
this
as
fast
or
slow
as
you'd
like
now
we're
getting
a
blue
and
green,
pretty
much
50/50
once
we're
happy
with
that,
will
switch
to
1090.
B
Apply
that
one
we
should
get
most
mostly
the
green
site,
now
cool,
mostly
the
green
site
every
day,
not
again,
we
should
get
a
blue
there
we
go
and
once
we're
happy
we
can
ship
it
all.
So
let
me
this
is
zero
and
make
just
one
hundred
I
will
apply
that,
and
now
we've
done
a
successful
blue
canary
deployment
from
blue
to
green
right.
So
that's
canary
a
Bluegreen
deployment
works
in
the
same
vein,
but
instead
of
shifting
traffic
slowly
we're
gonna
shift
traffic
all
at
once
right.
B
This
may
be
because
you
have
a
maybe
requirement
on
a
database
that
can't
handle
both
versions,
or
maybe
your
application.
Just
can't
live
with
having
two
versions
at
the
same
time
was
just
a
totally
reasonable
thing.
We
can
do
it
a
couple
ways
we
can
solve
with
weights
right.
So
just
like
this
right
now,
I
could
switch
back
to
blue
by
making
this
one
100
making
this
in
zero.
Now
I've,
given
blue
one
hundred
percent
giving
green
zero.
So
if
I
apply
this
we'll
see
an
instance
switch
to
blue
one
way
to
do
it.
B
I
know
we
could
do
it
here.
So
we
could
just
obviously
switch
the
service
right
now.
We're
at
blue
I
could
just
make
this
screen
right
and
if
I
apply
this
one
will
do
it
instant,
switch
from
blue
to
green
and
the
last
thing
we
could
do.
It
would
be
to
use
use
delegation
right
so
I
right
now,
I
have
include
sending
traffic
here.
I
can
create
a
whole
new
set
of
proxies
and
then
swap
those
delegation
chains,
and
that
would
be
an
easy
way
to
do
as
well.
B
B
Which
is
a
lot
so
thanks
very
much
sticking
around.
So
here's
just
gonna
give
you
a
click
after
all
that
a
quick
overview
of
the
roadmap
of
contour,
so
contour
is
gonna,
hit
1.0
here
in
early
November,
so
tomorrow
we're
gonna
ship,
an
RC
one
and
two
weeks
will
ship
at
RC
two
and
then
come
hang
out
with
us.
The
coop
con
much
of
the
team
will
be
there.
I
have
it.
I
was
speaking
at
on
VidCon
about
some
of
these
things
and
will
be
all
over
the
place.
B
So
come
come
here
with
us
and
chat
very
interested
to
see
I
mean
they'll
meet
all
of
you
and
see.
You
see
your
use
cases
and
then
here's
how
if
you
want
to
help
get
started
in
contour,
you
can
check
us
out
at
project
contoured
on
Io.
We
have
a
slot
channel
and
kubernetes.
That's
hashtag
contour!
You
can
follow
us
on
Twitter.
We
have
community
meetings
every
third
Tuesday.
B
So
if
you
want
to
hop
on
a
call
and
chat
about
anything,
that's
going
on
or
anything
that
we're
doing,
and
we
also
have
a
bunch
of
issues
labeled
with
good
first
issue
and
Help
Wanted.
So
if
you
want
to
help
contribute
happy
to
help
you
jump
in
and
help
out,
that's
all
I
have
so
many
questions.
We
can
go
run.
A
B
Yeah,
so
contour
is
meant
to
work
within
a
single
cluster,
so
contour
itself
is
just
an
ingress
controller
for
one
cluster,
so
it's
its
boundary
I.
Think
it's
going
to
be
that
one
cluster.
If
you
had
to
do
a
multi
cluster
type
thing,
there's
something
that
we
have
called
gimble
which
aims
to
solve
that.
So
the
idea
there
is,
you
can
have
multiple
clusters
that
miss
could
be
kubernetes
or
OpenStack
or
anything
else.
B
Its
goal
is
to
go
scrape
those
clusters
and
then
basically
turn
a
cluster
into
a
routing
cluster
and
use
the
power
of
contour.
Here
with
delegation,
everything
to
then
send
traffic
to
multiple
clusters,
but
nice
any
of
those
multi
cloud
multi
cluster
things
always
needs
a
conversation,
I
think
to
chat
about
how
you're
gonna
implement
that
and
have
it
look
and
work.
Yes,
but
inherently
contour
itself
out
of
the
box
is
only
a
single
cluster
solution.
B
B
B
So
contour
doesn't
reach
backwards
so
right
now
it's
assuming,
like
you
know,
I
had
my
example.
I
was
using
project
contour
at
I/o.
I
had
done
DNS
and
set
up
a
load
balancer
and
done
all
that
work
behind
the
scenes.
So
contour
doesn't
go
out
and
you
know
and
programmatically
set
up
gns
for
you.
That's
something!
That's
that's
on
you
to
get
set
up
today.
Right
got.
B
So
I'm
so
secrets,
so
you
notice
I
had
that
route.
Proxies,
namespace
and
I
just
mention
this,
but
what
you
can
do
is
you
can,
for
one
thing
you
can
do,
is
you
can
put
all
your
secrets
in
a
set
of
namespaces
and
then
I
can
tell
contour
that
this
these
root
namespaces
are
only
where
root
proxies
can
live
and
that
key
will.
Basically,
if
someone
else
creates
a
root
proxy
outside
of
one
of
those
contour
will
throw
it
out
right
so
limits
the
surface
area
of
where
those
can
live
within
there's
route
proxy
namespaces.
B
That's
where
you
can
store
all
of
your
certificates
so
based
on
that
contour,
if
you
delegate
off
paths
or
headers
to
other
namespaces.
Now
all
the
secrets
live
in
one
namespace,
but
your
users
can
consume
them
from
other
namespaces.
That's
the
one
generic
scenario,
the
other
way
you
can
do.
It
is
through
a
thing
called
TLS
certificate
delegation.
So
what
I
can
do
is
I?
B
Can
we
have
another
serie
called
a
GLS
certificate
delegation
and
what
it
does
is
you
can
say:
I
have
a
certificate
here
in
this
namespace
I'm
gonna
go
delegate
permission
to
another
namespace,
so
contour.
So
it's
just
a
it's
a
software
based
delegation
and
from
that
other
namespace,
the
team,
namespace
you're,
able
to
say
hey,
I'm
gonna
reference,
a
secret
which
doesn't
physically
exist
in
that
namespace,
but
you
can
still
use
it
because
of
the
linkage
you
set
up
with
that
delegation
chain.
So
contrib
will
make
it
all
happen
behind
the
scenes
for
you.
B
A
B
There's
an
open
issue
to
talk
about
I'm
off,
so
it's
come
up
a
lot
where
folks
want
it,
you
know:
have
it
have
contour
help
out
with
that
I'm
today
there
isn't.
There
isn't
a
story
around
having
off
where
contour
is
going
to
manage
that
for
you,
but
there
is
an
open
issue
which
I
think
join
us
get
up.
Let's
maybe
look
at
or
fine
to
go
comment
on
so
again
we're
very
feature
driven
and
feedback
driven.
So
whatever
users
are
wanting,
let
us
know
open
issues.
A
B
So
I
always
use
100,
because
these
are
for
me
to
to
grok
in
a
demo,
but
those
weights
are
all
arbitrary.
You
could
have
it
be.
You
know
one
one,
one
or
three
three,
three
all
so
we'll
just
basically
take
the
sum
of
all
the
make
that
two
total,
so
you
can
use
whatever
numbers
you'd
like
you
could
use
ten
thousand
and
ten
thousand
and
that'll
work
as
well
they're
all
just
arbitrary.
However,
you
want
to
manage
those
those
percentages
or
those
those
values.
A
A
Okay,
here
we
go
all
right.
You'll
love
this
one.
If
only
one
classic
ingress
controller
is
deployed
in
the
cluster,
we
usually
get
performance
hit.
If
some
team
is
deploying
a
lot
of
changes,
breaking
traffic
from
our
other
teams
during
reconfiguring,
for
example,
does
contour
address
this
issue
and
I
think
the
answer
is
yes,.
B
B
Yeah
so
contrast
shouldn't,
you
shouldn't
see
an
issue
with
busy
clusters
because,
because
of
how
envoy
we
talked
to
envoy
so
envoy
doesn't
have
to
restart
or
do
any
kind
of
reboot
logic.
Ollie
will
take
those
changes
as
fast
as
we
can
push
them
down
that
JIRA
PC
connection.
So
there's
there's
no
issue
there.
There
is
a
usually
there's
a
there's,
an
initial
startup
time.
B
So
as
when
you
first
turn
on
contour,
it's
got
to
go
and
scrape
the
entire
cluster
and
get
all
of
the
services
and
endpoints
and
all
those
things
depending
on
the
size
of
that
there
could
be
a
small
hit,
but
it's
never
really
noticeable.
So
yeah,
you
shouldn't
Alesi
an
issue
of
lag
in
terms
of
configuration,
changes
and
seeing
it
happen
in
real
time.
Okay,.
B
B
A
B
So
in
terms
of
SEO,
so
contour
is
not
a
service
mesh
right,
so
you
can
do
some
service
mesh
type
things
but
I
think,
depending
on
what
your
needs
are.
Sometimes
you
don't
need
to
deploy
a
full
mesh,
but
that's
a
different
conversation
in
terms
of
how
contour
compares
to
the
nginx
and
traffic
in
those
folks.
You
know,
and
your
necks
has
been
around
like
forever
and
eight
traffic's
been
around
a
lot
longer
as
well,
so
I
think
there's
more
knobs
under
the
hood
and
because
that's
contour
apart
is.
B
B
That
said,
you
know
contour
still
supports
ingress,
as
is
you
know
the
upstream
Kerberos
ingress,
so
you
can
still
use
that
I
know
it's
all
I
demoed
today
was
our
C
or
D,
but
we
still
support
normal
ingress
objects
as
well
so
release
whatever
whatever
you
feel
like
using
I,
feel
like
having
ongoing
the
backend
is
a
big
wing
again
with
those
dynamic
updates
on
what
self
is
a
big
community.
So
you
know
it's
growing
and
it
has
lots
of
patches
and
security
winces,
which
is
good
I'm.
A
B
B
Yeah,
so
all
pods,
yeah
so
envoy,
so
contour
will
use
his
envoy
will
route
to
endpoints
right.
So
we
use
the
service
in
cure
bays
just
to
go,
discover
the
end
points
but
contours
like
envoy
itself
is
doing
the
routing.
So
we
can
actually
we
didn't
demo
it,
but
you
can
change
the
routing
algorithm
if
you
like
so
right
now
it's
lead
waist
or
its
round
robin
you
can
do
it.
Lead
device
lead.
It
least
weighted
request
in
different
types
like
that
yeah,
so
it
it
is,
got
a
ten
points.
Awesome.
A
B
I
mean
we
have
users,
you
know
all
the
time
coming
in
and
saying:
hey
I'm
using
this.
This
is
cool
problems,
come
up
I'm,
trying
to
think
we
have
a
few
bugs
recently
just
cause.
We
have
this,
the
you
know
the
road
to
one
dodo.
We
switched
to
a
whole
new
series,
so
we've
got
a
couple
of
things
there,
but
oh
no
I
think
those
are
getting
ironed
out.
You
know
we
have
some
users
that
have
different
scaling
issues
that
you
know.
Some
people
have
again
it's
always
the
unique
environments
that
you
don't
plan
the.
B
So
those
things
come
up,
you
know,
or
you
should
just
want,
like
new
features
like
hey
it'd,
be
cool.
If
I
could
do
this
thing
or
I
could
have
this
feature
and
then
let's
chat
about
that
and
see
see
how
we
can
best
implement
that
so
yeah
so
I
think
it's
it's.
It's
been
going,
it's
a
growing
community
and
it's
it's
on.
It's
been
exciting
to
see
you
users,
you
know
using
it
more
and
more.
That's.
B
So
if
you
so
generous,
if
you
coming
out
with
this
one
just
to
Dave
Cheney
he's
our
tech
lead
here
on
contour,
he
wrote
a
blog
post
on
this,
which
should
help
explain
it.
But
the
short
answer
is
one
ingress
route
is
confusing
because
there's
the
kubernetes
ingress
object,
there's
a
generic
term
ingress
and
then
there's
this
thing
called
ingress
route
that
we
created.
So
it's
when
you
say
ingress,
it's
like!
B
What's
what
version
you
talking
about
the
object,
our
object,
the
generic
turn
and
then
it
aligns
more
proxy
aligns
more
with
what
we're
doing
you
know
we're
in
HTTP
l7
proxy.
It
is
confusing
with
the
l4
component
of
that,
but
at
its
heart
and
soul,
I
think
on
contours
this.
You
know
as
an
ingress
controller,
so
reach
out
to
that
and
and
to
that
blog
post,
and
that
should
help
hopefully
answer
some
questions.
If
not
come,
find
us
and
I'm
just
lack,
and
we
can,
we
can
chat
about
it.
Some
more
nice.
A
A
A
Channel,
potentially,
you
could
spark
a
discussion
for
sure.
Absolutely
so.
You're
gonna
be
a
cube.
Comm
right,
VMware
got
a
big
boost,
big
presents,
Steve
you're
gonna,
be
there.
Jonas
is
also
I'm,
assuming
gonna,
be
there
or
maybe
I.
Think
he's
in
the
other
will
awesome.
Thank
you
he's
in
the
chat,
dropping
answers
for
everybody.
So
thank
you
so
much
Jonas.