►
From YouTube: Contour, a High Performance Multitenant Ingress Controller for Kubernetes - Steve Sloka & Alex Xu
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Contour, a High Performance Multitenant Ingress Controller for Kubernetes - Steve Sloka & Alex Xu, VMware
Contour, a CNCF incubating project, is a high performance ingress and load balancer solution for Kubernetes. Contour offers a richer feature set than some common alternatives while maintaining a lightweight profile. At its core, Contour is providing a control plane for the Envoy edge and service proxy. This session will show you how to leverage Contour and Envoy for Kubernetes workloads in a multi-tenant environment as well as include a demo of recent Contour features. We will also focus on the project roadmap including enhanced support for Gateway API, the Contour Operator for enhanced lifecycle management, additonal configuration knobs for Envoy, feature enhancements such as ALS logging and distributed tracing support, and much more.
A
B
D
A
A
So
ingress
is
it's
part
of
the
kubernetes
api,
but
in
order
to
to
use
grass
to
leverage
congress,
you
need
an
ingress
controller,
just
a
piece
of
software
that
you'd
have
to
install
into
your
cluster
and
it
controls
how
traffic
you
know,
hits
your
cluster
from
the
outside
and
how
it
gets
routed
to
different
services
with
so
contour
works
by
packaging
and
deploying
envoy,
which
is
another
open
source
project.
It's
a
really
popular
one
and
that
functions
as
a
reverse
proxy
and
the
layer
7
little
bouncer
deployed
within
your
race
cluster.
A
So,
basically,
any
you
know
contour
is
is
a
control
plane
for
envoy
and
envoy
is
the
reverse
proxy,
which
exposes
any
http
or
https
routes
from
the
outside
to
your
upstream
services
within
the
cluster
project.
Contours
supports
tls
termination
pass-through.
We
have
various
slow
balancing
options
for
you
know
controlling
this
traffic
or
bouncing
this
traffic
between
your
different
backends.
A
As
you
scale
up
and
down,
we
can
take
the
request,
header
and
then
do
some
basic
manipulation
and
then
use
that
as
the
input
for
determining
you
know
exactly
which
back
end
to
send
the
traffic
to
we
support,
authenticated,
requests,
unauthenticated
requests,
you
can
add
ray
limiting
to
your
requests,
there's
also
sticky
sessions,
or
we
call
it
session
affinity
and
much
much
more
and
there's
lots
of
telemetry
and
tracing
capabilities
on
top
next
slide.
Please.
A
So
this
is
a
basic
overview
of
the
project,
know
since
inception
started
in
heptio
in
2017..
It
was
donated
to
cncf
at
incubation
level.
If
you
know
what
that
is.
Basically
every
project
in
cncf
goes
through
several
stages:
right.
They
go
from
sandbox
to
incubation,
to
donation,
and
this
this
stage
that
you're
at
is
basically
an
indication
of
the
maturity
level
of
the
project
from
a
community
health
perspective
right
in
terms
of
user
adoption
in
terms
of
external
contributions
and
usage
or
deployments
in
the
wild
right
production
deployments
of
contour.
A
So
we've
done
a
couple
of
these
talks
before
and
I
just
want
to
cover
you
know
what
we've
been
doing
since
the
last
talk
about
a
couple
months
ago.
So
a
couple
of
highlights
here
first
one
is
that
we're
still
doing
really
really
well
in
terms
of
supporting
gateway.
Api
api
is
an
upstream
project
from
sig
network.
A
A
A
All
right
so
I'll
go
over
briefly
what
project
contour
is
really
doing
when
you
deploy
it
into
your
kubernetes
cluster,
so
you
have
traffic
coming
from
the
external
world
right.
It
hits
your
external
load
balancer
and
then
hits
your
envoy,
and
this
external
bouncer
could
be
any
number
of
options
depending
on
how
your
kubernetes
cluster
is
deployed.
So
if
it's
deployed
on
public
cloud
or
bare
metal
or
on
some
kind
of
a
managed
service
right,
this
little
balancer
is
brought
up
differently.
A
So
if
we
look
at
you
know
this
deployment
in
in
the
context
of
public
cloud,
the
contour
is
basically
invoking
cloud
apis
to
instantiate
a
cloud
load.
Bouncer
right
and
traffic
gets
your
your
envoy
proxy,
which
is
sitting
at
the
edge
of
your
kubernetes
cluster,
and
then
traffic
gets
routed
to
different
applications
that
you
have
in
your
cluster
right.
So
we
have
a
web
application
and
then
we
have
a
blog
application
and
typically
this
routing
behavior
is
defined
using
ingress
yamls
right.
A
So
you
specify
a
path
and
how
that
maps
to
a
different
to
it
to
a
service
or
cluster.
So
you
can
use
planing
rest
channels.
You
can
also
use
the
crd
that
we
have
here
called
http
proxy.
It's
just
a
a
much
more
prescriptive
way
of
defining
the
the
routing,
behavior
and
gateway
api.
Has
another
option
called
http
route
which
we're
implementing
today.
A
So
this
is
basically
what
the
data
path
looks
like
going
to
external
load
bouncer
going
to
envoy,
and
then
it
goes
to
your
application,
and
you
can
see
that
contour
is
sitting
here.
That's
on
that
side
talking
to
envoy
almost
like
a
sidecar,
we
know
that
there's
a
kubernetes
api
server
in
your
cluster
somewhere,
and
so
what
contour
is
doing
is
basically
it's
watching
the
kubernetes
api
server.
It's
pulsing
api
server
for
changes
to
any
relevant
resources.
A
This
is
one
of
the
value
propositions
of
building
on
envoys
that
allows
itself
to
be
configured
dynamically,
and
so
you
know,
in
the
absence
of
contour.
Basically
envoy
cannot
directly
consume
kubernetes
api,
so
contour
is
acting
as
that
translation
layer
and
reflecting
these
changes
to
envoy.
So
it
can
reconfigure
itself,
and
so
this
is
basically
you
know.
Hopefully
this
gives
a
good
overview
of
what
happens
when
you
deploy
contouring
to
your
your
cluster
and
with
that
I'll
hand
it
over
to
steve.
E
E
E
E
If
you
look
into
some
of
the
the
documentation
on
the
on
the
site,
that's
linked
here,
that's
kind
of
an
important
idea
and
it
it's
represented
in
a
collection
of
resources
that
can
be
targeted
at
different
personas
in
the
in
operational
sense
and
deployment
of
applications.
So
you
may
have
your
infrastructure
provider,
your
cluster
operator
and
application
developers
that
manage
different
resources
at
different
levels
api.
E
So
we
introduced
support
for
gateway,
api
first
and
contour
version
1.13
and,
as
I
mentioned
before,
we're
currently
implementing
v1
alpha
one
of
the
api,
but
there's
big
changes
that
have
come
in
v1
alpha
two
of
the
gateway
api.
So
we
will
be
implementing
those
soon.
We
should
be
able
to
use
those
shortly
so
for
a
quick
demo
of
gateway,
api
and
contour.
Here
we
go
with
steve
steve
chris.
C
C
So
the
first
thing
we
need
to
do
is
is
tell
contour
through
its
config
map,
that
it
should
listen,
watch
for
a
gateway
class
and
a
gateway
and
tell
it
specifically
which
gateway,
class
and
gateway
to
watch
for,
and
so
the
way
that's
done
is
by
specifying
a
controller
name
here
under
the
gateway
stanza
in
the
config
map.
So
I'm
going
to
go
ahead
and
apply
this
file.
C
C
Map
now
we
need
to
restart
contour
to
pick
up
the
changes.
This
is
sort
of
alludes
to
some
of
the
changes
we've
talked
about
as
far
as
using
a
crd
for
config
and
then
making
these
things
more,
let's
see
more
dynamic,
but
for
now
we
need
to
restart
the
deployment
so
restart
contour
and
just
wait
for
it
to
be
up.
C
Okay,
so
we
got
a
new
pod
coming
up
so
I'll
move
on,
and
that
should
be
up
and
running
by
the
time
we
get
to
the
next
step.
So
the
next
thing
we
need
to
do
is
create
a
gateway
class
that
has
a
controller
string
matching
this,
this
value
that
we
put
in
the
config
file,
and
so
here
I
have
a
file,
that's
defining
a
gateway
class.
C
C
And
so
now
we
have
a
gateway
class.
I
can
list
the
gateway
classes
here
and
we
can
also
describe
it
and
so
at
the
bottom
here
you
can
see
in
the
status
that
we've
got
a
condition
added
to
the
gateway
class.
That
says
it's
valid
and
it's
been
admitted
with
the
status
of
true,
and
so
this
means
contour
has
picked
it
up
and
seen
that
it
should
process
it.
C
So
the
next
thing
we
need
to
do
then
is
define
a
gateway
for
that
gateway
class.
So
this
is
this
file
contains
a
gateway
spec.
We
can
see
that
it
uses
the
gateway
class
that
I
showed
in
the
previous
file,
and
this
is
a
just,
a
very
simple
gateway
that
has
a
single
listener,
listing
on
port
80
for
http
and
also
it
can
select
any
http
route
across
all
namespaces.
C
C
Okay,
we've
got
a
route.
So
now,
if
I
just
curl
local.projectcontour.io,
we
get
a
response
from
echo
server,
one,
which
was
that
first
service
and
regardless
of
the
path
I
put
here,
we
get
routed
to
s1.
So
we
know
we
have
two
services
in
here.
So
let's,
let's
actually
set
up
a
couple
of
rules
to
route
to
the
different
services.
C
C
C
But
if
I
take
that
header
out,
we
don't
get
routed
anywhere.
So
this
is
a
simple
way
to
add
additional
conditions
to
your
your
routing.
Now
you
might
have
an
alternate
scenario
where
you
actually
want
to
say:
I
want
any
traffic
that
has
the
s2
prefix
to
be
routed
to
s2,
but
or
I
want
any
traffic
that
has
this
header
to
be
routed
to
s2,
and
so
the
way
you
do,
that
is
to
create
a
separate
match
within
your
your
route
rule
and
this
treats
them
as
kind
of
as
logical
ores.
C
C
So
hopefully
that
gives
you
a
good
sense
of
kind
of
the
basics
of
using
gateway
api
with
contour.
There's
a
lot
more
to
dig
into
into
the
api
here,
and
certain
things
will
definitely
be
changing
with
v1
alpha
2,
but
we
plan
to
stay
on
top
of
the
changes
and
and
continue
to
build
out
our
support
year.
So
with
that
I'll
go
back
to
the
slides.
C
B
It's
still
going
to
be
pretty
much
a
release,
train
model,
whatever
is
ready
at
about
the
time.
We're
due
to
release
will
be
what
gets
cut,
but
given
that
we're
going
to
have
three
months
instead
of
one
month,
we're
hoping
that
we
should
be
able
to
do
a
bit
better
planning
and
be
able
to
tell
you
more
about,
what's
going
to
be
in
the
release
before
the
release
actually
comes
out
and
to
be
able
to
plan
a
little
bit
more
ahead
and
say
that
will
make
it
into
release
x.
B
B
This
is
your
contour
is
getting
to
be
more
mature,
we're
not
making
as
big
changes.
Every
time
we
don't
have
like
a
huge
number
of
features
left
to
hit
feature
parity
with
a
lot
of
the
other
ingress
controllers
on
the
market,
and
so
I
think,
we're
hoping
here
to
make
the
life
of
the
person
of
the
user
of
contour
easier
that
you
don't
have
to
update
every
month
to
get
the
latest
security
fixes
or
to
get
the
latest
fixes
and
patches
and
stuff
like
that.
But
it
shouldn't
be.
B
So
how
are
we
going
to
move
to
to
supporting
three
releases?
Well,
this
is
this.
Is
the
plan
the
we're
going
to
for
120,
which
is
currently
scheduled
for
october
all
these
days
here?
I've
got
very
tentative
dates.
Obviously
we
haven't
done
quarterly
releases
before
so.
This
is
the
the
rough
plan
as
of
today,
but
this
may
change,
obviously,
as
we
as
we
have
a
crack
at
this
and
find
that
things
are
easier
or
harder
than
we
intended
to
be
so
for
for
120,
which
is
scheduled
for
october.
B
The
only
release
that
will
be
supported
is
120..
That's
no
change
to
today.
Only
one
version,
however,
when
121
comes
out,
which
is
three
months
from
then,
is
sort
of
end
of
january
2022,
we
will
support
120
and
121
and
the
and
then,
as
we
go
to
122,
which
is
about
the
end
of
april,
then
it'll
be
120,
121
122
and
then
once
we
get
to
123,
which
is
july
22.
That's
when
we'll
drop
support
for
120..
So
then
we'll
support
121,
122
123.,
and
what
does
support
mean?
B
D
Well,
thanks
nick
yeah,
so
we're
looking
at
moving
to
to
contours
config
into
a
a
crd,
so
right
now
steve.
If
you
want
to
pop
down
a
couple,
clicks
yeah
right
now
we
restore
configuration
options
in
a
config
map,
so
there's
a
config
map
you
edit,
you
saw
steve,
do
that
in
the
demo,
where
you
had
to
edit
that
config
map
they
had
to
restart
contour
for
contour
to
pick
that
up.
D
That's
where
things
live
today
and
there's
also
command
flags
that
you
can
pass
so
in
the
you
know,
contour
serve
in
the
in
the
contoured
pod,
there's
different
commands.
You
can
pass
to
that
or
flags
that
overlap,
as
well
with
the
config
maps.
Right
now,
we've
got
this
sort
of
mishmash
of
where
the
config
map
overrides
the
environment
variables
which
get
overwritten
by
the
the
command
line,
flags
and
we're
sort
of
in
a
weird
spot.
So
our
goal
here
is
to
help
make
this
simpler
and
and
solve
some
problems
here.
D
So
I
think,
there's
four
different
problems
in
this
slide
and
I
should
have
put
transitions
in
here,
but
so
right
now
the
operator
that
we
have
the
contour
operator
has
to
translate
from
a
crd
into
the
config
map
so
and
the
crd
that
the
operator
is
managing
is
different
from
what
contour
manages.
So
the
goal
here
is
to
centralize
this
and
have
this
live
as
one
one
type.
So
one
configuration's,
you
know
ghost
struct.
In
a
sense,
we
didn't
have
any
way
to
surface
errors
so
other
than
logs
and
contours.
D
So
if
you
did
something
wrong,
you
can
figure
something
wrong.
Contour
would
crash
loop,
you'd
have
to
go,
tell
the
logs
and
see
what
was
wrong.
We
can
also
implement
some
simple
crd
validation.
So
if
a
field
should
be,
you
know
a
number
and
you
put
a
string
in
there,
we
can
throw
that
out
before
you
try
to
apply
that
steering
to
the
to
the
to
the
cluster
and
then
eventually
like
to
have
dynamic
resource
of
contour.
So
if
you
make
a
config
change,
it'll
just
contour
pick
that
up
and
just
restart
itself
automatically.
D
All
right
next
slide
see
cool,
so
the
implementation
kind
of
looks
like
this.
It's
like
there
was
something
on
the
left
there,
but
maybe
not
so.
The
the
the
configuration
file
has
has
been
simplified,
so
we've
taken
all
those
little
bits
and
put
them
together.
Actually
there
may
be
some
transitions
here
as
well,
so
you
can
click
click
yeah.
So
all
the
fields
now
are
camel
case.
So
we
had
a
mix
of
camelcase
and
hyphenated
values.
All
the
non-required
startup
command
flags
are
now
in
this
file.
D
So
again
you
can
have
a
simple
file,
that's
portable
across
deployments,
and
then
we've
grouped
things
together,
so
things
that
were
dealing
with
the
xds
server
they're
all
put
together
things
that
are
debug
related
things
or
health
or
metrics.
Again
they
have
a
proper
grouping
now
which,
before
we
didn't
have
as
well
there's
a
design
dock.
You
can
check
out
for
more
information
on
this
down
at
the
bottom.
D
It's
in
our
design
directory
and
the
contour
repo,
and
the
next
section
here
is
going
to
talk
about
manage
envoy,
which
is
the
next
part
of
this,
so
contour's
gonna
moving
moving
to
manage
envoy
itself.
So
envoys
is
the
critical
datapath
component
that
it
has
to
go
with
contour
contours
the
configuration
server
for
envoy.
D
So
the
goal
here
is
to
have
contour
read
this
spec
that
we
just
wrote
and
then
in
that
new
configuration
crd,
there's
a
new
managed
option
under
envoy,
and
this
will
tell
contour,
hey
I'm
going
to
manage
envoy
and
then
there's
the
details
of
how
that
envoy
demonstrated
deployment,
should
look
or
work
in
your
cluster
that'll
define
how
it's
published
to
the
outside
of
the
cluster.
What
noza
put
this
on
and
various
things?
D
This
is
obviously
a
very
simplified
window
of
this,
but
essentially
you'll
just
deploy,
contour
and
then
control
then
manage
the
envoy
fleet
for
you.
When
you
upgrade
contour
and
change
this
configuration,
then
contour
will
manage
rolling
out
that
envoy
fleet
for
you
in
the
future.
Looking
with
the
operator,
we
will
have
a
spec
that
the
operator
will
read
to
help
you
manage
contour,
so
everything
will
work
kind
of
as
it
is
today,
but
we're
looking
hoping
that
this
layered
approach
will
help.
D
B
A
B
B
Maybe
you
missed
a
little
bit
there
was
that
we
we're
not
gonna
we're
gonna,
make
sure
we.
This
is
gonna,
be
a
nice
slow
process.
Everybody's
gonna
have
plenty
of
change
plans,
chances
to
move
across
we're
not
going
to
drop
this
on
you,
and
then
you
know
you're
going
to
have
to
change
this
quickly.
There's
going
to
be
plenty
of
time
for
you
to
move
across
to
this
safely,
and
the
same
goes
for
managed
we're
going
to
bring
this
stuff
on
board.
B
Let
everybody
have
a
chance
to
try
it
out
before
before
you
know,
before
we
do
anything
about
mandating
the
gateway
api
support.
Is
you
know
a
lot
of
these
changes
asked
to
support
being
under
implement,
go
api
in
the
best
way
we
can
imagine
and
as
gateway
api
comes
on
moves
through
its
versions,
we're
gonna
try
and
get
our
best
to
keep
up
now.
You
know
I
think
alex
mentioned
earlier.
I'm
also
a
maintainer
on
the
go
api
project.
B
One
of
the
things
we're
trying
to
do
with
the
current
release
of
v1
alpha
2
is
to
make
sure
that
all
of
the
breaking
changes
that
we
need
to
make
are
in
v1
alpha
2..
So
as
the
gateway
api
moves
forward,
implementers
of
the
api
like
us,
like
contour,
won't
have
to
make
as
bigger
changes
in
order
to
support
it,
so,
hopefully,
as
gateway
api
moves
to
beta
and
then
and
then
to
ga
there's
going
to
be
minimal
changes
that
we're
going
to
need
to
make
to
our
api
processing
code.
B
That's
the
plan,
so
that's
sort
of
the
the
gateway
api
is
really
like
the
future
of
ingress.
In
kubernetes,
it's
going
to
be
the
way
to
describe
things
in
a
more
complicated
anything
more
complicated
than
sort
of
the
really
basic
ingress
use.
Cases
that
are
handled
already
by
the
base
ingress
object.
That's
going
to
be
done,
that's
going
to
be
pushed
towards
gateway
api.
B
The
best
place
and
the
gateway
api
is
sort
of
very
much
a
response
to
that
and
a
response
to
being
able
to
make
this
stuff
more
exposed
and
declarative
and
understandable,
and
so
that's
one
of
the
risks.
That's
the
reason
why
contra
is
very
involved
and
very
and
very
bullish
about
the
prospect
of
the
so
the
last
couple
of
things
we're
going
to
we're
going
to
look
at
be
looking
forward
to
is
where
you
know.
B
Qantas
has
been
around
for
quite
a
few
years
now
the
state
of
the
art
for
xds
control
planes
has
moved
on,
and
so
some
of
our
xts
code
is
getting
a
bit
long
in
the
tooth
and
there's
probably
there's
a
bunch
of
optimizations.
We
can
do
there,
so
we've
got
sort
of
a
longer
running
stream
that
has
kicked
off,
but
new,
we'll
we're
hoping
we'll
deliver
some
value
over
the
next
while
to
modernize
our
xcs
code
to
enable
some
of
the
more
advanced
ways
in
which
xds
code
works.
B
That
hopefully,
should
mean
that
contour
should
be
more
efficient,
talking
on
the
wire
to
envoy
and
vice
versa,
and,
lastly,
we're
aiming
to
push
for
cncf.
Graduation
in
2022
we've
done
a
lot
of
the
sort
of
basic
background
work
that
we've
got
to
do
for
that
and
a
lot.
But
a
lot
of
what's
required.
Is
your
community
interaction?
So
you
we're
looking
for
contributors.
We
you
know,
we
love
to
have
new
people
come
and
contribute.
We've
got
a
bunch
of
stuff
labeled
as
a
good
first
issue
and
help
wanted.
B
We
have
a
tech
docs
working
group.
So
if
you
don't,
you
know
if
you're,
not
a
coder,
but
you
want
to
contribute
to
contour.
There
are
definitely
ways
to
do
that
and
we
would
really
love
to
welcome
you
into
our
community.
You
with
that
said
as
well.
Yeah
we're
always
looking
for
more
maintainers,
and
so,
if
you
have
bandwidth
to,
you,
know
really
throw
yourself
into
contour
and
would
like
to
be
a
maintainer.
Then
talk
to
us
and
we
can
direct
you
to
places
in
which
you
can
contribute.
B
So
you
can
start
climbing
that
contribution
later.
That's
one
of
the
requirements
for
cnc
graduation
is
that
we
need
to
have
a
more
diverse
maintainer
pool
across
every
access,
and
you
know
I
for
one
would
really
like
to
see
more
more
people
be
maintainers
and
for
us
to
have
a
better
diversity.
You
know
in
thinking
in
companies
in
you
know,
in
who
people
are
so
that
we
can
build
a
better
product
that
serves
more
people
more
easily.
B
Obviously,
our
public
roadmap
that's
linked
down
the
bottom,
which
is
in
our
community
repo.
Is
the
canonical
place
to
talk
about
the
sort
of
more
lower
level
roadmap
features?
And
so
you
know
that's
the
place
to
go
to
to
find
out
sort
of
all
the
detail
on
that.
I
think,
with
that
I'll
flip
over
to
alex
for
yeah
to
finish
up
yeah
bye.
A
Thanks
nick
so
this
is,
you
know,
I
think,
thanks
for
sticking
with
us,
you've
made
it
to
the
last
slide.
This
is
the
state
of
the
world
of
the
contour
community.
So
you
know
some
telemetry.
Here
we
have
six
maintainers
but
again,
like
nick
said,
we
would
love
for
more
people
to
join
us
and
you
don't
have
to
join
as
a
maintainer
right.
There
are
other
ways
to
contribute.
A
A
So
you
know
we
have
these
community
meetings
so
feel
free
to
drop
by,
and
you
can
ask
any
questions
or
just
you
know,
watch
you
know,
watch
us
discuss
releases
and
discuss
prs
talk
about
the
road
map,
things
like
that
all
the
community
meetings
are
recorded,
so
you
can
watch
these
on
youtube.
I
think
we've
also
explored
we've
been
exploring
an
idea
of
making
the
maintainer
meetings
public
as
well,
probably
through
a
zoom
webinar
of
some
kind.
A
Also
anyone
can
come
and
attend
and
follow
us,
but
it
allows
us
to
stick
to
our
agenda
so
yeah.
I
want
to
thank
everyone
who
has
attended
in
the
past,
giving
us
really
great
feedback
and
all
the
things
that
you've
been
hearing
us
discussed
just
now,
like
the
managed
envoy,
the
gateway
api
support
that
we're
doing
all
these
things
are
still
in
flight.
So
definitely
appreciate
anyone
comment
and
share
your
perspective.