►
Description
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.
In this briefing, Steve Sloka and Nick Young (VMWare) both contributors and maintainers to this new CNCF Project will be giving an introduction to Contour and taking your questions live!
A
B
B
B
Yeah
so
again,
so
here's
the
quick
agenda,
we'll
just
walk
through
you
know
ingress.
What
ingress
controllers
are
our
http
proxy
crd
kind
of
thing
to
introduce
that
again,
as
sort
of
unique
to
contour
and
again
we'll
just
do
some
demos
at
the
end
so
yeah
I
work
for
vmware.
I
came
out
of
the
hefty
acquisition.
That's
where
contour
was
started,
so
I
you
know,
that's
that's
my.
A
A
A
A
B
Yep,
that's
it
yeah,
okay,
good!
So
we'll
move
on
ahead
of
that.
So
yeah
give
me
a
shout.
Let
me
let
me
know
if
folks
have
troubles
or
questions
whatever
excuse
me.
So
so
what
is
ingress
right
when
I
think
of
ingress,
I
think
of
incoming
just
generically
that
word
ingress.
So
this
is
the
problem
that
ingress
looks
to
solve
in
kubernetes.
So
the
idea
is
that
we
want
to
route
traffic
from
outside
of
the
cluster
into
your
cluster,
so
you
know
break
that
boundary
in
some
unique
ways.
B
So
so
why
do
this?
Why
implement
this
thing?
Well,
you
can
get
traffic
consolidation
right,
so
you
can
have
lots
of
different
applications.
All
drive
into
one
entry
point.
If
you
didn't
use
ingress,
you
might
use
something
like
a
service
type
load
balancer,
which
would
map
a
service
and
kubernetes
to
some
sort
of
external
load
balancer
depending
on
your
your
deployment
environment,
and
that
would
work
right.
You'd
get
you
know
some
sort
of
l4
load
bouncer
on
the
end.
B
The
problem,
then,
is
you've
got
you
know
one
of
those
load
balancers
per
application,
so
one
you've
got
to
deal
with.
You
know
a
cost
of
just
spinning
up
that
many
and
two
you've
got
to
deal
with
the
complexity
of
having
all
those
different
entry
points
into
your
cluster.
So
with
ingress,
you
can
consolidate
all
of
those
things
together
into
one
place.
B
B
Has
this
neat
idea-
and
we
can
talk
about
this
later-
this
idea
of
tls
certificate
delegation,
so
this
will
help
help
with
this
certificate
bit,
but
the
idea
is
that
you
can
have
your
certificates
live
in
one
namespace
and
reference
them
from
a
different
namespace.
This
will
actually
work
with
you
know
plain
old
ingress
as
well
and
again,
we'll
dig
in
this
a
little
bit
later
ingress
lets
you
abstract
your
configuration.
So
again,
when
you're
deploying
your
application,
you
don't
have
to
wonder
or
deal
with
all
right.
I've
deployed
this
my
application.
B
I
have
this
load
balancer
and
I
need
to
map
dns
to
it.
I
need
to
map
certificates,
you
can
just
basically
deploy
your
application
and
then
let
the
ingress
layer
kind
of
be
that
that
glue
to
wire
all
these
little
bits
together
and
then
the
other
big
win
that
you
typically
get
with
ingress.
Is
this
path-based
routing?
We
call
this
sometimes
l7
or
layer
7
of
the
stack-
and
this
is
your
application
routing.
So
it
lets
you
route.
Things
like
slash
foo
to
one
application
at
the
request.
Path
and
slash
bar
is
a
different
application.
B
So
what
is
an
ingress
controller?
Well,
this
one's
specific
to
contour,
but
this
should
fit
any
english
controller
out
there
in
the
world.
Typically,
so
again,
you
have
you
know
the
internet
out
here
you
have
traffic
hitting
some
sort
of
load
balancer
and
that
load
balancer
then
hit
some
sort
of
proxy.
So
in
contour's
case
we
leverage
envoy
envoy,
is
a
cncf
project
and
it
is
our
proxy
layer,
so
it
handles
all
of
the
heavy
lifting
in
terms
of
rotting
traffic
across
the
cluster
contour's.
B
B
If
you
haven't
seen
them
before
this
is
this
is
a
very
basic
ingress
resource.
I
throw
this
in
here
just
to
be
complete,
but
here
you
know,
we've
got
it.
The
kind
is
v1.
So
this
api
version
v1,
is
new.
In
1.19,
any
previous
version
you'll
see
the
v1
beta
1,
which
has
been
you
know
there
for
for
six
or
seven
years
now,
so
you
can
see
here
we're
going
to
route.
B
B
You
can
also
have
an
annotation
here
as
well,
we'll
get
in
that
here
in
a
little
bit,
but
to
extend
the
api.
You
typically
add
annotations
to
these
these
resources
to
help
make
them
more
descriptive
and
have
more
more
features
into
them
all
right.
So
we
talked
about
ingress.
So
what
are
some
of
the
issues?
We've
come
up
with?
Well
one
thing:
it's
a
specification,
so
this
is
a
slide
from
dave
cheney.
Shout
out
shout
out
to
dave.
B
B
I
think
it's
still
kind
of
relevant
he'll
talk
about
ingress
route,
which
is
again
something
we've
duplicated
out
of
contour,
but
all
the
learnings
should
apply
going
forward
and
one
of
the
things
that
dave
hits
on
is
that
ingress
today
is
just
a
specification
right
and
a
lot
of
how
you
specify
things
are
in
these
comments
in
in
the
code.
So
this
is
from
the
actual
code.
B
I
think
this
is
probably
a
year
or
so
old
now,
but
it
is
that
you
have
to
interpret
these
these
rules
right
and
how
these
things
are
described.
So
I
guess
what
we're
getting
to
is
that,
depending
on
how
the
ingress
controller
interprets
these
different
kind
of
ingress
resources
is
how
that
controller
behaves,
and
if
someone,
you
know,
interprets
them
differently
than
someone
else,
then
you
get.
You
know,
ambiguity
now
across
different
controllers,
so
you
can't
just
swap
in
one
controller
for
another
and
have
everything
just
work.
B
So
some
of
this,
some
of
this
stuff
gets
us
into
trouble
in
the
sense
that
you
know
we
don't
know
how
to
to
properly.
You
know,
implement
it
and
we
have
to
make
up
our
own
our
own
designs.
So
let's
talk
about
a
situation
here
now.
So,
given
that,
let's,
let's
look
at
these
two
different
ingress
resources,
the
one
left
here
is
is
an
ingress
resource
deployed
to
the
name,
space
team,
a
and
the
one.
The
right
here
is
going
to
team
b
and
you'll
see
they
both
have
the
same
host.
B
So
this
is
stevesloca.com
and
both
resources
and
they
have
the
same
path:
slash
blog
you'll
notice
that
they
go
to
different
endpoints,
so
so
the
first
ingress
resource
points
to
wordpress
blog
and
the
second
one
points
to
service
new,
and
the
question
here
is
that
you
know
I
have
two
different
ingress
objects:
they
have
the
same
name,
space,
the
same
path
and
the
same
domain,
but
they
point
to
different
places.
So
what
should
happen?
And
again
this
is
totally
legal.
Not
nothing
is
broken
here.
B
In
terms
of
you
know,
kubernetes
objects
that
you
can
apply
to
a
cluster.
This
is
this,
is
you
know
a
valid
valid
gamble?
I
guess.
But
what
should
happen
when
your
controller
reads
this
right
and
the
problem
is
that
it's
undefined,
because
you
could
think
of
that?
Maybe
the
first
one
in
wins.
You
know
the
first
resource
with
that
same
domain
should
serve
that
resource.
B
Maybe
the
last
one
should
win:
maybe
they
both
shouldn't
they
should
be
thrown
out
because
they
both
conflict
and
and
we've
seen
production
users
break
break
their
clusters.
This
way,
you
know
not
knowing
unknowingly,
not
not
doing
it
on
purpose
just
because
they
happen
to
deploy.
You
know
a
dev
version
to
a
different
name
space,
and
then
they
kind
of
conflicted
with
production
and
took
it
down.
So
it's
undefined,
it
can
be
dangerous,
and
this
is
sort
of
the
underpinnings
that
led
us
to
building
our
own
crd.
B
So
conference
started
out
building
one
called
ingress
route
and
we
since
deprecated
that
and
built
a
new
one
called
http
proxy,
and
this
is
sort
of
the
successor
of
that
so
you'll
see
some
of
these
underpinnings
from
ingress
mounted
for
familiar
and
also
in
some
of
the
service
api's
work.
So
there
are
some
learnings
in
there
as
well,
so
some
of
the
goals
we
had
for
the
crd,
they
were
to
support
multi-team
clusters.
B
So
they
wanted
to
have
a
way
that,
in
a
scenario
we
just
described,
we
can
have
lots
of
different
teams
self-manage
their
own
resources,
but
have
them
do
it
in
a
way
that
they
can't
conflict
and
can't
create
those
situations
where
we
take
down
production.
Do
we
do
this?
To
this
thing,
called
this
delegation
of
routing
so
you're
able
to
set
up?
You
know
what
team
can
access,
what
information
and
what
path
on
the
request?
B
And
then
each
each
person
can
self
self
manage
that
and
we'll
dig
into
this
here
in
a
minute.
We'll
show
some
demos
of
this
a
third
option
or
third
goal
was
we
wanted
to
have
a
sensible
home
for
common
configuration
parameters?
So
we
talked
about
those
annotations
on
those
resources.
So
one
was
service
weights.
One
was
load
balancing
strategies.
One
is
you
know,
path,
prefix
rewrites,
because
the
spec
again
is
not
well
defined.
There's
lots
of
places
where
we
need
to
add
more
information,
there's
not
a
good
place
for
it.
B
B
So
in
this
diagram
here
you
can
see
that
this
is
going
to
talk
about
the
delegation
bit
and
how
we
actually
implement
this
so
and
it's
sort
of
modeled
after
dns
in
a
way.
So
here
you
can
see.
I
have
this
this
crd
here,
this
steve,
silk
com,
http
proxy
and
what
it
has
it
has
authority
over
a
domain
name
called
stevesloca.com,
and
this
is
what
we
call
the
root
sometimes
so
the
top
level
is
what
we
call
our
root.
B
Now
I
can
go
and
create
a
child,
a
delegate
version
of
that-
and
I
can
say,
hey
this-
this
delegate
proxy
has
access
to
slash
blog.
We
can
delegate
authority
to
that.
So
now.
If
someone
else
comes
along
and
they
say
hey,
you
know
what
I'm
creating
a
dev,
a
dev
site
called
devblog
and
I'm
going
to
own
slash
blog.
What
happens?
B
Is
this
contour
throws
it
out
because
it
doesn't
have
any
authority
over
the
path
blog,
because
this
first
one
has
it
here
so
again,
this
is
a
very
simple
view,
but
this
is
how
you
can
actually
implement
this.
This
delegation
across
your
cluster,
let
this
team
here
self-manage
their
own
resource
and
let
in
in
the
event
that
someone
else
does
it
either
maliciously
or
just
unknowingly.
We
can
handle
that
situation
and
still
serve
traffic.
B
B
So
what
I'm
going
to
demo
is,
I
actually
my
cluster
is
completely
empty
right
now.
So
what
I
have
here
is
I've
got
a
kind
cluster.
I
think
it's
a
119
yeah
got
a
119,
a
one
node
119
on
my
mac
here
and
what
I've
done
is
I've
started
up
with
with
a
configuration
file
and
what
I've
done
basically-
and
I
can't
really
see
that
oops
is
I've,
mapped
port
80
to
my
local
machine,
so
one
thing
we
didn't
describe
was
how
I'm
deploying
contour.
B
B
B
Contour's
job
is
to
watch
the
cluster
for
services,
endpoints
all
those
different
resources
and
then
we'll
have
envoy
running
as
a
daemon
set
so
envoy's
here
and
then
ombre's
going
to
have
this
thing
called
a
bootstrap
configuration
and
that
configuration
is
what
we
passed
to
envoy
to
essentially
tell
it
where
contour
is
so.
Everything
that
onward
gets
configured
with
will
come
dynamically
through
those
xds
resources
and
again
that's
through
that
that
that's
your
pc
connection,
so
everything's
up
and
healthy.
B
B
B
Okay,
so
we
have
that
running.
So
we
have
contour
up
and
running,
but
we
haven't
given
any
configuration.
If
I
go
ahead
and
get
my
proxies
in
all
name,
spaces
I'll
have
to
deploy
something
first,
but
I
have
nothing
in
there.
So
let's
go
ahead
and
deploy
something.
So
here
I
have
some
demos
here
so
first,
what
to
do
is
we'll
deploy
some
apps.
B
So
I
have
to
go:
create
a
namespace
called
root
proxy,
since
we're
going
to
put
all
of
our
root
our
root
objects
and
proxies
into
that
place.
That's
gonna
be
my
starting,
my
starting
point
and
here
we're
going
to
have
a
deployment
and
what
this
deployment
runs
is
a
simple
little
echo
server
that
I
wrote
and
it
does
two
things
one
is
it
echoes
out
the
text
that
we
put
into
the
site
here,
and
this
will
help
us
understand.
You
know
which
application
is
responding
to
what
request
it
could
be
confusing.
B
Sometimes
when
you
start
doing
some
some
different
kind
of
routing.
The
second
thing
it
does
is
it
echoes
back
the
headers
and
the
requests
that
you
sent
it
so
again.
It
helps
us
with
debugging
and
visualizing
this
information,
so
we'll
deploy
a
root,
a
root,
app
and
then
a
service,
and
I
think
this
is
a
secure,
app
that
we'll
get
to
here
in
a
second
we'll.
Do
this
one
yeah?
Okay,
there's
that.
C
Yeah,
so
how
does
that
work?
Because
there
will
be
you
know
in
terms
of
networking
outside
going
into
the
ingress?
It's
up
to
you,
then
I
guess
to
to
define
your
routing
right.
If
the
assumption
is
that
every
node
in
the
infrastructure
has
its
own
ip
address,
and
so
there's
a
whole
other
layer
here,
part
of
ingress
that
contour
doesn't
deal
with
right.
B
B
C
Well,
the
reason
I'm
asking
I
guess
is
that
you
know
that
load
balancer
that
comes
from
the
platform,
the
public
cloud
or
or
whatever
it
is.
It
doesn't
know
where
the
services
are
in
the
in
the
cluster
right.
So
you
might
have
multiple
leaves
right
if
it
goes
to
one
node,
but
the
service
is
actually
running
on
another
node
that
happens
inside
kubernetes.
Networking
at
that.
C
B
Load,
balancer
is
only
going
to
point
to
ongoing
and
then
once
the
traffic
hits
on
void
onward
will
decide
where
it
should
go
inside
the
cluster
in
terms
of
what
services
so
you're
only
going
to
have
one
one
load,
balancer
per
instance
of
contour
and
then
onboard's
gonna
do
the
routing
to
the
actual
back-end
application.
Well,.
B
Yeah
right
yeah,
so
you
can
change
that.
So
if,
if
this
comes
up,
sometimes
we
haven't,
I
got
to
out
to
contour
here,
so
we
call
them
examples
right
now
and
we've
kind
of
gone
back
and
forth
in
terms
of
how
to
how
to
handle
this,
but
right
now
that
the
deployment
dock,
so
the
quick
start
comes
from
from
this
source
directory
and
basically
quickstart
just
smashes
them
together
into
one
big
yaml
file.
B
We
use
daemon
sets
because
envoy
scales
very
well
with
cpu
threads,
so
adding
multiple
instances
of
envoy
per
node
doesn't
really
give
you
more
performance.
So
that's
kind
of
why
that
helps
limit
that.
But
you
could
absolutely
you
know,
deploy
contour
as
a
deployment,
I'm
sorry
envoy
as
a
deployment
and
and
use
different,
different
ways
and
kubernetes
to
put
that
traffic
across
your
cluster.
We've
had
users,
you
know,
have
node,
selectors
or
other
again
other
ways
to
target.
B
You
know
these
specific
nodes
in
my
cluster
are
used
for
ingress
and
the
other
ones
aren't
again
to
limit
the
scope
of
where
they
go.
So
it's
kind
of
that's
why
we
kind
of
call
them
examples,
because
there's
so
many
different
ways
that
folks
might
need
to
deploy
this
you
can
you
can
modify
it
to
your
your
taste.
I
guess.
B
B
Now
the
domain
name,
I'm
going
to
use
this
local.project
contour.io.
This
is
set
up
to
use
localhost
out
in
contours
dns
out
wherever
it's
hosted.
So
now
we
can
use
that
here
on
our
local
demos,
to
help
give
us
a
good
domain
name
to
work
against
and
we'll
just
talk
about
the
read
apps,
we'll
kind
of
deploy
this.
This
is
real,
simple
and
then
this
will
get
us
up
and
running
here.
B
B
B
B
So
I
can
actually
add
this
and
it's
the
same
thing
here.
We're
gonna
add
the
condition
of
slash
secure.
So
basically,
this
one's
gonna
handle
slash,
secure
to
the
secure
app
and
then
slash
will
go
to
the
root
app.
So
if
we
go
ahead
and
apply
this
one,
what
we'll
see
now
how
to
open
up
a
browser
might
be
fun.
B
We'll
do
local.project
contour
you'll
see
here
is
I
get
the
root
app
at
local
and
if
I
do
secure,
what
I
get
is
the
secure
app
again
there's
that
echo
server
returning
back
so
yeah,
so
there's
that
that's
that's
again,
not
not
too
exciting.
This
is
what
ingress
would
do
today,
but
I
mentioned
these
conditions
right,
so
we
can
do
things.
We
can
add
different
types
of
conditions
to
here.
So,
for
instance,
I
could
add
a
new
condition
that
actually
adds
headers.
B
So
I
could
say:
hey
the
the
the
app
needs
the
match
secure,
as
well
as
the
user
agent
containing
firefox.
So
this
will
do
some
header
inflation
now.
So
if
I
go
ahead
and
apply
proxy2
when
I
come
to
chrome
what
you'll
see
is
I
get
I'm
at
secure,
but
I'm
getting
the
default
site
right
and
that's
because
to
match
this
route,
I've
got
to
match
the
prefix
of
slash,
secure,
as
well
as
the
user
agent
being
firefox
or
containing
firefox
and
in
chrome
it
doesn't
happen.
B
But
if
I
go
ahead
and
open
up
firefox,
it
wants
to
update,
go
away.
Okay,
okay,
I
got
it
so
now.
If
I
go
to
secure
in
firefox
you'll
see
I
get
the
actual
secure
site
because
you
can
see
I
have
here
in
the
user
agent.
It
contains
firefox
in
that
header,
so
you
can
do
some
some
routing
that
way
you
can
also
do
the
inverse.
B
So
if
I
come
to
firefox-
and
I
hit
this
one
I'll
get
the
default
site
because
I
do
match
firefox
or
the
header
having
firefox,
that's
not
what
we
want
and
chrome
we'll
do
the
same.
If
I
hit
secure,
I
still
get
the
default
site
but
open
up
safari,
and
we
paste
this
into
safari
here.
You'll
see
I
get
the
secure
site
because
I'm
matching
secure
and
I'm
not
chrome
and
I'm
not
firefox.
B
So
again,
these
are
silly
demos.
These
are
you
know
these.
Aren't
that
that
useful,
but
just
try
to
demonstrate
that
you
can
add
these
different
kind
of
header
routing
manipulations.
To
do
certain
things.
If
you
need
to
you
could
have
you
know
certain
browsers
route
to
certain
applications
and
have
different
browsers
brought
to
different
applications.
If
that
was
something
you
need
to
do
or
based
on
your
header
routing,
I
guess
is
what
I'm
getting
at.
So
that's
the
the
conditions
bit.
B
You
can
see
that
there
it's
a
list
because
we
can
expand
them
later
right
now.
We
just
have
prefix
path,
prefix
and
header,
but
future
we
can
have
different
things
there
if
we,
if
we
just
decided
to
let's,
go
ahead
and
deploy
our
marketing
site.
So
I'm
going
to
add
again
add
to
my
demo
here
and
we're
going
to
have
this
multi-team
thing
kind
of
come
into
play
now.
So
I
have
this
marketing
team
and
what
they
want
to
do
is
deploy
a
blog.
B
B
I
don't
have
one
yet.
I
don't
have
a
marketing
name
space
so
we'll
deploy
them
in
namespace
and
we'll
go
ahead
and
give
them
again
some
apps
to
work
with
so
we'll
give
them
this
this
blog
site
here
and
we'll
give
them
an
info
site
as
well.
Once
we
get
to
next
so
we'll
deploy
these
resources.
Real,
quick.
B
B
Okay,
so
I
have
this
this
blog
site
here
again,
it's
in
the
name,
space
marketing
and
it's
going
to
route
to
the
service.
You
know
www
blog.
So
if
I
go
ahead
and
get
my
proxies
now,
what
you'll
see
is
I've
got
some
errors
here,
so
you
can
see.
I
have
the
root
one
which
is
valid.
It's
handling
the
local.project
contour,
but
this
child
one
here
says
it's
orphaned
and
it's
often
because
it
doesn't
have
a
delegation
chain
from
a
root
proxy.
B
So
basically,
this
this
extra
resource
that
I
created
no
one's
pointing
to
it.
No
one
has
any
kind
of
delegation
chain
mapping
to
it.
So
so
contrast
all
this
and
threw
it
out
because
it
doesn't
have
any
mappings,
so
we
need
to
go
ahead
and
tie
those
things
together
to
be
able
to
give
it
this
delegation
chain,
so
it
can
handle
that
that
slash
blog
and
what
we
do
is
we
do
this
this
idea
of
this
delegation,
so
in
control
we
call
this
an
engagement.
We
call
it
delegation
now
we
call
it
includes.
B
So
what
this
includes
does
we'll
stick
it
here
and
I'll
talk
about
it.
This
includes
kind
of
works
like
software
programming
right.
So
whenever
contour
processes
a
site,
it
looks
for
these
includes
when
it
sees
it,
it
adds
it
to
the
you
know.
Sorry,
if
you
had
a
header
file
in
a
say,
c,
plus,
plus
or
something
you
have
reach
and
include
it's
going
to
go,
find
that
code.
Stick
it
at
the
top
of
the
file
and
continue
on
and
then
when
the
whole
thing
is
compiled.
B
You
have
that
that
header
file
in
that
new
file
there.
This
is
the
same
way
that
contour
does
it.
So
what
contour
does
is
it?
You
can
include
things,
so
you
can
say:
hey,
I'm
going
to
include
this,
this
other
resource
with
these
conditions
and
this
name
space
and
then
contour
will
apply
that
to
that
to
that
other
resource,
so
long
story
short.
What
we're
going
to
basically
do
is
from
the
root
here.
This
is
where
I
have
the
root.
B
B
Okay,
now,
if
we
go
and
get
our
proxies,
they
should
all
be
valid
and
they
are
now
if
we
go
ahead
and
let's
come
to
a
browser,
a
bit
easier.
If
I
hit
the
root,
so
the
root
app
still
works.
Fine,
if
I
hit
slash
blog
it'll,
be
delegated
to
them.
I
get
the
blog
site
again,
it's
running
in
the
marketing
namespace.
B
Now
I
want
to
note
with
inclusion
is
that
I've
included
the
prefix
blog,
but
over
here
in
marketing
I
didn't
define
any
kind
of
condition
and
again
before
we
said,
conditions
were
there's
a
default.
Slash-
and
that's
still
true
in
this
case.
But
what
happens
is
all
the
conditions
that
are
included
are
automatically
applied
this
resource?
So
essentially
this
ends
up
being
slash
blog
here.
So
if
I
added
something
else
here,
if
I
said
it
say
foo
and
if
I
apply
this
one.
B
Now,
what's
going
to
happen
is
if
I
hit
slash
blog
I'll,
get
the
default
site
because
I'm
only
handling
slash
blog
foo
in
the
marketing
team.
I
add
slash
foo
I'll
get
the
blog
site
here.
I
guess
through
that
idea
of
inclusion,
so
that
is
from
the
root
you.
You
include
these
these
different
bits
down
to
the
child
proxies.
One
thing
that
you
might
be
thinking
of
is
like
well
hey.
If
I'm
this,
you
know
this
site
running
off
in
this
marketing
space.
B
B
B
There
we
go
so
down
here.
We've
got
a
set
of
conditions
here,
and
you
can
see
that
right
now,
it's
just
all
valid.
Our
future
thought
is
to
have
this,
have
more
information
as
to
you
know,
what's
been
delegated
to
it,
what
what
things
are
may
be
wrong
with
it
and
all
that
sort
of
information,
so
this
makes
this
makes
it
more
rich.
So
this
will
help
drive.
B
B
B
B
No,
what
did
I
do?
Oh
yeah,
we
get
something
every
time.
Okay,
so
we
can
figure
that
I'll
just
verify
our
proxies
real,
quick
everything's
valid.
So
now
what
should
happen
is
that
we
should
match
slash
blog,
but
the
user
isn't
containing
firefox.
So
I'm
in
chrome
here.
So
if
I
hit
slash
blog,
I'm
gonna
get
the
default
site
because
I
don't
match
firefox,
but
firefox
should
work
to
slash
blog.
B
B
Okay,
so
that
that's
conditions
so
12
36.
Let's
do
something
fun.
So
a
couple
things
else
that
that
contour
does
is,
with
with
our
proxy
series
that
you
can
have
multiple
services
in
an
ingress
resource.
So
I
could
typically,
this
could
be,
like
you
know,
a
blue
and
a
green
deployment
type
demo.
If
you'd
like
you
can't
deal
with
ingress
today,
you
can
do
with
label
selectors,
but
it's
kind
of
it's
kind
of
hard
to
do
that.
B
B
B
Yeah
yeah
I'm
just
going
to
demo
adding
off
now
to
contour,
and
then
that's
what
I
have
that's
all
I
have
planned
and
then
we
can
do.
We
can
talk
and
do
whatever
yeah
show.
Whatever
else
needs
to
show
awesome
cool
so
over
here
in
I'll,
show
you
a
little
diagram,
quick
that
helps
so
external
auth.
So
how
envoy?
B
How
envoy
shows
auth
is
or
implements
external
authors
through
again
grpc.
So
what
you
do
is
you
define
an
external
service
to
implement
your
your
auth,
so
I'm
going
to
demo
today,
just
the
basic
auth,
but
again
you
could
implement
your
own
and
have
whatever
kind
of
informa
authentication
method
mechanism
you
want
to
have
so
here.
First
thing
you
do.
B
Is
we're
going
to
deploy
this
auth
service
right
and
onward,
we'll
talk
to
it
over
grpc,
once
you've
deployed
that
that
you
know,
may
talk
out
to
some
sort
of
auth
provider
in
my
demo.
It
won't
because
it's
using
local
local
cache,
but
it
could
and
then
we're
gonna
deploy
a
news
theory
called
this
extension
service
crd
and
what
the
crd
lets
us
do
is.
B
B
So
when
a
new
request
comes
into
your,
your
domain,
it'll
hit
envoy
onboard
will
reach
out
to
this
external
service
and
it'll
basically
need
to
return
to
envoy
thumbs
up
or
thumbs
down
as
to
should
this
request
go
through
or
not
envoy,
then
will
then
you
know
either
respond
back
to
the
client
with
hey.
You
know:
you're
you're
you're,
not
you
know
401
redirect
because
you're
not
you're,
not
valid
or
it'll.
B
B
Once
we
have
that
we
will
go
ahead
and
deploy
some
bits,
so
I'm
going
to
go,
create
a
service
account
and
a
cluster
role,
and
this
is
going
to
be
used
for
our
auth
service.
So
over
here
this
service
is
going
to
watch
a
secret
and
the
secret's
going
to
contain
the
the
basic
auth
users
and
passwords.
That's
what
that
is.
B
B
Project
contour
auth,
I'm
gonna,
stick
all
this
stuff
in
an
off
namespace
and
I
can't
spell
contour
there
we
go
so
now.
We'll
just
apply
it
again,
because
I
mistyped
all
that
there
we
go
so
we
have
sorry.
We
have
the
service
account
the
role
the
binding
and
then
that
issuer
all
right.
Now
we
have
that
let's
go
ahead
and
create
our
auth
service.
So
again
this
was
the
I'll
bounce
around.
This
is
this
auth
service
here
we're
going
to
implement
so
the
contour
project
actually
has
some
example.
B
There's
a
one
for
unit
testing.
We
can
implement
and
there's
this
basic
auth
one
we're
looking
to
help
expand
that
as
well,
but
you
can
also
plug
in
any
kind
of
envoy
external
auth
service,
because
at
this
point
we're
just
talking
envoy
to
the
service,
so
it
con
doesn't
never
care
about
that
endpoint.
So
you
can
plug
anything
in.
I
think
there's
one
from
istio
that
has
one
that
does
like
oidc
and
stuff
anyway.
So
we're
gonna
deploy
our
own
service
here.
B
B
Okay,
so
there's
our
off
deployment:
let's
go
create
the
certificates
that
need
for
that.
So
the
first
thing
we're
doing
is
going
to
create
this
hd
password
one
and
that's
to
secure
the
communication
between
envoy
and
this
external
auth
service.
So
we'll
create
that
and
then
this
one's
going
to
create
basically
a
tls
secret
for
our
incoming
requests.
So
our
clients
certificate
that
they're
going
to
consume
so
we'll
create
these
two
bits.
B
Okay
created
those
two
and
what
I
should
get
is
if
I
get
secrets-
and
they
say
it's
root
proxies-
that's
where
we
are.
I
now
have
this
one.
That's
four
seconds
old
this.
This
ingress
conformance
echo
and
I
should
have
one
in
the
project
contour
off
site,
which
is
also
about
16
seconds
old
now
for
hd
passwords,
that's
certain
manager,
doing
its
job,
generating
us
generating
a
self-signed
search.
B
Okay!
So
there's
that-
and
the
next
thing
is
we're
going
to
create
our
back-end
secret
database.
So
this
is
going
to
have.
I
did
this
ahead
of
time,
but
we
basically
have
three
users
user,
one
with
password,
one
and
user,
two
with
password
two
and
so
on.
I
created
all
these
passwords
and
I
basically
stuck
them
into
this
secret.
B
You
know
base64,
encoded
it
etc,
etc,
and
now
that
those
three
users
exist
in
this
database,
so
the
the
contour
auth
server
will
look
at
this
secret
to
basically
get
to
look
at
it
for
its
day-to-day
source
of
users.
So
we'll
go
ahead
and
apply
this
one
is
o3
secret
cool.
We
created
that,
and
the
last
bit
to
do
is
this
extension
service
again.
That
was
the
bit
over
here
I'll
bounce
around
the
crd
up
here
we're
going
to
create
and
it's
going
to
help
us
tie
it
all
together.
B
So
again,
we'll
put
this
in
the
name:
space
called
project,
contour
auth
we're
going
to
talk
over
h2
that'll.
Let
us
do
that
grpc
connection
and
then
we'll
we'll
pass
it
off
to
the
service
hd
password.
We
created
in
step
two
to
deploy
our
actual
service,
so
I
will
go
ahead
and
apply
our
extension
service
cool.
So
now
we
have
all
the
bits
deployed.
B
B
B
Okay,
so
now,
if
we
go
ahead
and
do
a
curl
for
local,
we
should
get
a
301
moved
so
again,
here's
another
another
kind
of
thing
contour
helps
to
do.
Is
you
reference
the
secret
from
your
your
domain
name?
So
you
probably
want
to
redirect.
Typically
you'd
have
to
add
you
know,
annotation
to
say:
hey
redirect
from
insecure
to
secure.
Contra
will
just
do
that
automatically
out
of
the
box
because
it
sees
the
secret
here.
B
If
you
want,
you
can
undo
that,
but
you've
got
to
annotate
your
routes
to
say:
hey,
I'm
annotate,
but
there's
a
permit
insecure
field.
You
can
do
permit
insecure
and
that
will
help
they'll.
Let
you
route
to
this
path
without
without
tls,
so
we'll
just
go
ahead
and
pass.
The
dash
k
to
this
you'll
see
now
we're
serving
tls,
which
is
good
for
our
start.
Manager
worked
now
we're
going
to
go
ahead
and
apply
we're
going
to
tell
it
to
to
add
our
our
office
here.
B
B
B
A
real
user
and
password
so
we'll
just
grab
this,
and
this
is
going
to
go
ahead
and
pass
us
basically
user,
one
with
password
one
which
is
valid,
and
if
I
run
this
you'll
see
that
hey
now
I
get
the
request
coming
through,
because
the
os
server
matches
you
know,
user
one
and
password
one
just
to
make
it
clear.
If
I
go
ahead
and
change
the
password
and
make
it
wrong,
they
make
it
password.
Two.
You
see
it's
a
bad
password,
so
I
get
redirected.
I
get
a
401
return
result
last
bit.
B
I'm
going
to
show
you
is
that
how
you
can
disable
auth
so
right
now,
essentially
every
route,
regardless
of
what
I
hit
requires
off,
but
maybe
I
want
to
have
my
slash.
My
root
site
not
need
auth,
but
I
want
to
have
secure,
require
auth.
So
what
we
can
do
is
we
can
come
down
into
here,
and
we
can
do
that.
So
we
can
say,
hey
the
root
app,
which
is
this
one
I
can
add
an
auth
policy
and
basically
disable
it
right
there.
B
B
B
I
think
that's
all
I
have
so
if
you
need
help
from
us
for
contour
or
the
contour
channel
and
the
kubernetes
slack
you
can
find
us
on
twitter
on.
You
know
github
issues
anywhere.
That's
that's
not
helpful
and
you
can
reach
out
to
me
as
well.
I'm
at
steve,
sloka
everywhere
on
the
internet,
so
hope
this
was
helpful.
Hope
this
gives
you
a
quick
intro
to
contour.
Again,
there's
lots
more.
We
can
talk
about,
but
I
think
we're
out
of
time.
A
B
Yeah,
so
actually
we
can.
There
are
some
folks
in
red
hat
that
are
actually
driving
that
so
daniel
and
michaia
are
the
two
folks
that
are
doing
a
lot
of
work
with
that.
So
the
goal
there
was
to
have,
you
know
another
way,
another
option
to
deploy
contour,
so
it's
I
think,
we're
gearing
towards
the
v1
alpha
one
for
december.
I
think
right
now,
it's
functional,
there's
just
a
few
more
bits.
B
A
Yeah
operate,
hub.io
is
where
we
put
all
the
generic
kubernetes
ones
and
if
there's
something
specific
that
damian
needs
to
do
to
make
it
run
on
openshift,
then
it
would
go
into
the
catalog.
But
yeah,
I'm
glad
you.
You
mentioned
that
because
I
just
looked
at
the
repo
while
you
were
talking
and
I'm
like.
Oh
another
excuse
to
pick
on
danny.
A
C
Sure,
thank
you
and
thank
you,
steve,
really
really
interesting
demo
and
I
do
appreciate
the
taking
seriously
the
authentication
and
and
tls
issues.
My
question
is,
you
know,
I'm
thinking
of
immediate
comparisons
to
to
other
products
in
this
space.
So
the
double
question-
I
guess,
but
the
first
product
I
think,
is
more
obvious
comparison
is
something
like
honk
and
kong
tries
to
solve.
Does
I
think,
solve
similar
things,
but
with
a
very
different
approach.
Instead
of
working
with
ingress,
it
has
its
own
gateway.
C
So
all
the
ingress
goes
to
kong
and
then
kong
will
it's
all
in
one
place.
You
do
everything
right
all
your
policies,
all
your
redirections
and
everything
there.
So
it's
it's
a
different
approach.
I
can
see
the
immediate
advantage
of
being.
You
know,
instead
of
having
lots
of
different
proxies
right
and
delegations
between
them.
C
You
have
a
central
place
where,
where
you
are
organized
all
your
routing
yeah,
maybe
you
can
talk
a
bit
about
that
and
or
maybe
I'm
totally
wrong
here
and
the
other
comparison
I
would
make,
which
is
less
obvious,
is
the
psyllium,
so
psyllium
obviously
operates
at
a
lower
level.
It
will
not
do
things,
or
at
least
not
easily
can
do
things
like
http.
B
B
Okay,
I
mean
that
that's
that's,
essentially
what
contour
is
going
to
do
for
you
too,
I
mean
you're
going
to
have
just
you
know.
You
have
one
service,
that's
going
to
get
all
the
traffic
and
then
you
know
I
know
I
demoed
like
having
ingress
across
the
cluster.
You
know
spread
all
through
it,
but
at
the
end
of
the
day
that
contour
is
going
to
take
all
of
that
and
and
create
one
big
giant
envoy
configuration
so
essentially
yeah.
All
traffic
is
going
to
hit.
B
You
know
one
or
more
envoys
in
your
cluster
and
then
all
that
rewrite
all
the
routing.
All
that
stuff
is
going
to
happen.
Essentially
at
that
you
know
envoy
proxy
layer,
so
I
think
we're
pretty
similar
there.
I
know
it
comes
up
folks,
you
know,
say
their
api
gateways
and
such
that
I
guess
I
don't
really
understand.
B
There's
been
an
api
api
gateway
and
an
ingress
controller
for
maybe
just
having
some
extra
rules
for
rewrites
and
authentication
and
stuff,
but
I
think
we're
still
sort
of
in
the
same
space
just
using
different
different
technologies,
maybe
under
the
hood
or
maybe
I'm
misunderstanding
as
well,
but
yeah.
I
think
we're
pretty
similar,
though
from
how
I
understand
how
khan
works.
A
B
A
B
Yeah,
I
think
I
think
kuma
might
be
like
the
their
service
mesh
kind
of
offering
yeah
and
there's
actually
an
ingress
controller
as
well
that
they
have
yeah
and
your
second
question
about
psyllium
yeah,
I
mean
there
are
some
interesting
things
that
that
you
could
do
with
you
know
if
you
control
the
the
networking
stack
underneath
you
know,
envoy
or
inside
of
you
know,
kubernetes
so
yeah
we
don't
have
much.
I
guess
don't
have
any
integration
in
the
sense
of
being
able
to
tap
into
that
routing
and
stuff.
B
C
Oh,
you
know,
maybe
a
quick
follow-up
comment.
What's
interesting
for
me
here
is
you
know
if
you
look
at
the
history
of
envoy
when
lyft
initially
designed
it,
this
is
actually
what
they
had
in
mind
and
not
istio.
They
really
were
thinking
of
envoy
as
an
english
controller
and
kind
of
envoy
took
on
a
life
on
its
own
later,
you
know
with
surface
meshes,
but
in
an
interesting
way.
This
is
going
back
to
basics,
of
what
envoy
was
being
thought
of.
B
Yeah
yeah
there's
a
lot.
You
can
do
with
this.
If
you
know,
if
you
need
a
service
mesh,
that's
a
different
kind
of
story,
but
if
you
just
need
some
sort
of
routing
that
does
sort
of
the
stuff,
I
think
that
you
can.
You
can
get
a
lot
of.
You
know
functionality.
Out
of
you,
know,
english
controller
gateway,
that
sort
of
thing
without
you
know,
buying
fully
into
into
a
into
a
mesh,
but
but
they
are
they're
different
stories.
You
know
today,
contour
is
focused
on
an
l7
ingress
proxy
we've
talked
about
l4.
A
Cool,
so
there's
there's
lots
one
of
the
things
that
I
love
about.
This
is
the
I
contour
really
hadn't
jumped
onto
my
radar
until
about
a
week
ago,
where
we
pre-recorded
a
panel
with
nick
young
and
paul
mori
and
brenda
chan
and
from
istio
linson
and
a
couple
other
folks
from
that
that
world,
and
so
it
you
know,
nick
regaled
us
with
tails,
which
was
wonderful.
But
it's
amazing
how
many
different
pieces
and
parts
there
are
to
the
service
mesh
and
the
serviceless
ecosystem.
A
B
Yeah
yeah,
we
do
yeah,
so
there's
two
different
couple
different
ways
to
get.
I
guess
and
hold
up
us
so
we
have
office
hours
every
week,
so
we
have
it
the
first
tuesday
and
so
yeah.
We
alternate
between
u.s
time
zone
and
australia,
time
zone,
so
the
first
and
third
tuesdays
they're
at
6,
30,
eastern
or
3
30,
pacific
and
then
in
america's
time
zone.
It's
1
p.m.
Eastern
and
10
a.m,
pacific
and
again
it
alternates
every
other
week.
And
then
every
couple
weeks
we
have
office
hours
as
well.
A
It
because
well
one
it's
really
easy
to
find
stuff
on
and
two
that
it's
really
very
clear
about
how
to
get
involved
having
you
know
how
to
be
go
from
being
an
end
user
to
a
or
to
being
a
community
participant,
the
whole
latter
stuff.
So
you
guys
have
done
an
awesome
job,
creating
a
space
for
people
to
collaborate
so
kudos
to
you
all
on
that,
and
I'm
really
looking
forward
to
kubecon
in
two
weeks,
mostly
because
all
of
my
talks
are
baked
now.
A
B
Yeah
no
worries
yeah
so
yeah,
so
we
actually
have
on
wednesday
at
three
o'clock.
There's
a
for
all
of
all
the
maintainers.
Here
we
have
a
talk,
just
kind
of
outlining
we
just
what
you
just
saw
in
a
way.
So
if
you
want
to
see
it
again,
we'll
do
sort
of
the
same
demos
again
and
then
there's
there
are
office
hours
throughout
the
week
and
there's
two
different
sets
of
those.
A
Yeah
and
if
you're
coming
to
the
openshift
commons
gathering
that
the
panel
that
I
was
blathering
on
about
a
couple
of
times
is
on
november
17th-
and
it's
I
think
it's
like
later
in
the
afternoon
like
around
two-
no
not
too
earlier
than
that
in
the
day,
but
I'll
post
that
as
well
with
there
and
that
that
was
actually
a
really
good
exploration
of
the
space.
It's
called
to
serve
or
to
be
served,
the
serverless,
microservices
and
servicemen,
and
it's
not
in
the
kubecon
schedule.
A
It's
in
the
it's
it's
buried,
it's
buried,
you
couldn't
find
it
it'd,
probably
take
the
whole
time
to
find
the
click
through
to
get
to
there,
but
suffice
to
say
that
there's
going
to
be
a
real
good,
deep
dive
on
service
lists
of
good
conversations
at
kubecon
about
that
and
at
the
openshift
commons
gathering
on
day,
zero.
So
there'll
be
plenty
of
content
for
you
to
binge
watch
afterwards
on
this
topic,
and
I
do
suggest
that
you
do
reach
out
to
the
community
project
contour
dot.