►
From YouTube: Contour: Advanced Ingress with Envoy
Description
Contour is an ingress controller that configures Envoy based on Ingress and IngressRoute objects in a Kubernetes cluster. This post covers how contour supports advanced ingress functionality with its IngressRoute Custom Resource Definition (CRD). We'll explore some common ingress needs such as weighted load balancing and cover how multi-team ingress can be facilitated.
A
A
So
I
wanted
to
record
some
of
the
content
to
make
sure
those
who
maybe
weren't
attending
or
those
who
wanted
a
reference
after
the
fact
could
kind
of
come
back
to
it
and
look
it
up
so,
along
with
talking
about
contour
as
an
ingress
controller,
we'll
also
be
looking
at
the
ingress
api
and
how
we
tackle
some
of
the
more
advanced
things
that
one
might
need
to
do
with
ingress
as
their
journey
around
ingress
begins
to
unfold.
So
I'm
really
looking
forward
to
getting
into
this
with
you.
A
So,
let's
jump
right
in
so
speaking
to
contour
as
a
technology
just
to
level
set
a
bit.
Contour
is
an
ingress
controller.
Many
of
you
have
probably
run
things
like
nginx
h,
a
proxy
traffic.
All
these
ingress
controllers
have
different
benefits.
One
of
the
big
notes
about
contour
is
that
contour
runs
on
voi
as
its
proxy
technology.
A
So
as
a
controller,
it's
responsible
for
reading
the
ingress
objects
that,
if
you
use
nginx
or
H
a
proxy
you're,
probably
quite
used
to,
and
also
the
ingress
route
objects,
which
is
a
custom
resource
definition
that
has
a
more
capable
feature
set
and
a
feature
set.
That's
a
little
bit
more
tailored
to
Envoy
itself
in
certain
respects,
although
it's
still
very
generic
and
we'll
spend
a
lot
of
our
time.
A
But
then
you
can
set
the
replica
count
to
ensure
it's
always
a
certain
amount
available
and
then,
as
far
as
the
networking
model
goes,
you
might
choose
to
use
host
port
host
network,
perhaps
even
a
node
port.
There's
reasons
why
you
might
use
these
I
won't
get
into
that
in
this
particular
talk.
There's
some
around
performance
and
how
things
would
hop
across
namespace
is
how
IP
tables
might
be
traversed
based
on
which
option
you
choose,
but
nonetheless
there's
many
many
options.
At
the
end
of
the
day.
A
You
need
this
pot
running
in
your
cluster
and
with
an
ability
for
some
type
of
external
lb
or
even
DNS
record,
perhaps
being
able
to
reach
this
pod.
So
that's
the
overall
architecture
of
contourer.
Now
in
this
demo,
what
I'm
going
to
be
showing
you
is
a
cluster,
that's
running
contour.
So
if
I
look
inside
of
here
for
just
a
moment,
I
have
my
contour
pods
inside
of
a
namespace
called
contour.
So
in
this
case
I'm
just
running
one
contour
pod,
and
this
is
going
to
start
satisfying
those
different
resources.
A
Now,
like
we
talked
about
the
resources
we
need
to
satisfy
are
things
like
the
ingress
objects
and
the
ingress
route
objects.
So,
let's
start
off
by
talking
about
the
ingress
object,
since
that's
fairly
important,
so
I
actually
have
an
app
that
I'm
going
to
use
as
a
sample
here
and
I'll.
Show
you
this
app
right.
Now
we
do
get
pods
for
the
namespace
ping.
A
In
fact,
let's
put
a
watch
up
here,
real
quick,
so
we
can
sort
of
watch
this
and
I'm
gonna
actually
make
this
a
little
bit
better
and
also
include
ingress
in
this
list.
So
we're
gonna.
Look
for
both
pods,
which
is
what
Pio
stands
for
and
then
ingress,
which
is
what
ing
stands
for,
so
we're
watching
for
those
alright.
Now,
if
I
want
to
have
my
ping
pong
beasts
accessible,
I'm
going
to
use
ingress
to
define
how
to
route
to
it,
so
we're
just
gonna.
Look
at
this
for
a
moment
and
I'll
talk
a
bit.
A
What
ingress
is
so
inside
of
the
ping?
App
I
have
an
ingress
Auriemma
file.
Alright,
and
if
we
look
at
this
ingressing
animal
file
here,
we
can
see
overall
its
it's
pretty
simple
right.
It
defines
some
rules
about
if
this
host
is
being
accessed.
So
the
request
comes
in
with
this
host
header
and
it's
on
this
path,
in
this
case,
basically
any
path,
including
route,
we're
gonna
route
to
a
service
called
ping.
V1.
A
So
what
ingress
controllers
mostly
do
is
they
are
going
to
actually
route
directly
to
the
pods,
because
if
they
just
de
route
to
the
servers
in
most
configurations
with
kubernetes,
that's
going
to
go
to
the
service
and
the
service
will
always
round-robin
to
the
pods
from
there
using
IP
tables
or
perhaps
IP,
vs
and
so
on.
But
when
we
actually
use
the
service,
we
can
say:
ok,
any
pot
behind
ping
v1
I'm
going
to
route
to
those
endpoints.
A
That
way
when
we
want
to
do
more
advanced
load,
balancing
algorithms
like
fancier
things
in
round-robin,
maybe
certain
weighted
algorithms
and
things
of
that
nature.
We
have
the
ability
to
ensure
we
can
satisfy
those
algorithms
based
on
the
fact
that
we're
routing
directly
to
the
pots.
Ok,
so
just
something
to
kind
of
think
about
and
if
you're
not
really
sure
about
that
concept.
Just
yet
it's
it's
more
of
an
implementation
detail,
and
then
we
have
a
service
port,
which
is
how
we're
actually
going
to
go
into
the
the
the
port
to
to
access
this.
A
If
you
will
so
I'm
gonna
go
ahead
and
apply
this
for
just
a
moment.
So
if
we
do
an
apply
on
the
ping,
I
ping,
ok
and
then
we'll
watch
up
at
the
top
here,
the
change
that
occurs
so
I'll
go
ahead
and
apply
that
and
then
I'm
going
to
get
an
ingress
object
inside
of
here.
So
now,
theoretically,
the
ping
team
in
my
company
is
really
excited.
They
should
hypothetically,
be
able
to
route
to
their
object
now,
which
is
which
is
pretty
cool.
So
how
can
we
route
to
this
object?
A
Well,
we
go
back
to
the
slides
for
just
a
moment.
We've
just
kind
of
applied.
This
ingress
object
right
so
in
grass
again
expresses
l7
rules
for
getting
traffic
in,
and
this
is
a
example
of
what
you
just
saw
in
my
terminal.
These
are
namespace
scoped
objects.
So,
when
I
applied,
this
ingress
object
into
my
cluster
I
put
it
in
the
ping
namespace
it's
scoped
in
that
namespace
and
it
will
be
satisfied
by
an
ingress
controller.
A
So
right
now,
I'm,
obviously
running
contour,
but
theoretically
I
could
be
running
and
Gen
X
I
could
be
running
H
a
proxy
as
long
as
there's
not
super
specific
implementation,
things
that
I'm
expecting
this
should
work
across
and
then
there's
often
times
the
need
to
think
about
the
more
advanced
use
cases.
But
let's
not
talk
about
this
last
bullet
just
yet,
let's,
let's
just
look
at
the
ping
app
and
get
an
understanding
of
what
it's
doing
so
back
to
the
terminal
inside
the
terminal.
A
Here,
I
have
ping
running
and
I've
actually
set
up
a
do
loop
inside
of
here.
So
just
to
show
you
what
it's
doing,
let's
make
this
a
bit
bigger.
So
while
true
we
are
going
to
curl
this
host,
just
like
you
saw
on
the
ingress,
object,
we'll
sleep
for
0.3
seconds,
and
then
we
will
be
done.
So
let's
go
ahead
and
start
that
all
right,
so,
as
you
probably
could
have
guessed,
this
app
doesn't
do
anything
too
fancy.
It
basically
just
continues
to
respond
with
a
ping.
A
Now
my
terminals,
not
gonna,
do
a
great
job
of
it,
but
do
note
that
this
is
constantly
running
it.
Just
fills
up,
and
then
it
doesn't
seem
like
it's
running,
because
it's
printing
the
same
thing
but
we're
gonna
constantly
run
ping
over
and
over
again.
So
overall,
the
ping
team
is
super
happy.
Their
app
is
running
great,
it's
receiving
traffic
very,
very
good.
A
Now
what
about
when
we
get
into
more
advanced
use
cases
with
our
ingress
controllers,
or
maybe
we
need
some
more
advanced
configuration
of
the
ingress
a--'s
themselves,
and
this
is
where
things
get
a
little
bit
complicated.
So
the
ingress,
API
and
kubernetes
is
really
great,
really
generic.
It
handles
your
basic
l7
stuff,
but
then,
when
you
think
about
how
do
I
do
more
advanced
things
like
selecting
an
algorithm
like
I
was
telling
you
with
with
the
notion
of
routing,
to
endpoints
right.
So
what
if
I
want
to
do?
A
Now
the
models
have
been
different
because
the
alb
lives
outside
of
the
cluster,
but
a
similar
idea
needs
to
create
some
type
of
graph
based
on
the
ingress
objects
and
then
feed
that
up
to
an
Al
B.
Now,
when
we
got
into
the
more
advanced
pieces
that
we
had
to
consider,
we
found
ourselves
many
many
times
looking
at
how
to
put
these
items
in
and
we
fell
on,
like
a
lot
of
controllers,
do
putting
them
inside
of
annotations,
and
this
is
what
I
like
to
refer
to
as
annotation
hell
right.
A
It
just
genuinely
is
something
that
when
you
have
a
limited,
API
or
object,
and
you
need
to
feed
more
metadata
into
it,
you
oftentimes
find
yourself
adding
these
metadata
like
properties
and
then
trying
to
parse
and
read
them,
and
they
get
really
messy
in
and
hard
to
reason
with
at
certain
points.
So
an
example
of
where
this
type
of
thing
might
come
into
play.
These
more
advanced
use
cases
would
be
something
like
a
canary
use
case.
So
going
back
to
the
ping,
the
ping
group
in
our
company,
real
quick.
A
Let's
pretend
for
a
moment
that
ping
v1
was
a
smashing
success.
It's
been
returning
ping,
everybody
loves
it
in
the
company
and
outside
of
the
company,
but
now
they've
decided.
You
know
what
we're
gonna
introduce
ping
v2
and
we're
really
excited
about
ping.
V2
ping,
v2
s,
big
enhancement,
is
that
it's
going
to
return
Poong
instead
of
ping.
Now
they're
really
nervous
about
this,
because
this
is
a
really
important
application
and
they
don't
just
want
to
switch
all
the
traffic
over
Bluegreen
style
and
have
pong
start
being
returned.
A
They
want
to
kind
of
wait
the
traffic
across
this
now,
based
on
what
we
know
about
the
ingress
API.
There's
no
native
way
to
do
this,
without
perhaps
some
type
of
annotation
or
maybe
on
the
service
itself.
We
could
put
some
type
of
annotation,
but
nonetheless
it's
it's
a
little
bit
messy
it'd
be
nice.
If,
in
the
ingress
resource
itself
that
contour
is
going
to
read,
we
could
define
these
types
of
waited
rules
so
going
back
to
our
application
for
a
moment
here,
I
have
ping
up
and
running.
A
Ok
and
one
thing
I'm
going
to
kind
of
show
you
so
you
can
conceptualize
this
a
bit
is
there's
also
in
contour
the
ability
to
visualize
what
it's
dag
has
formed.
So
I'm,
going
to
just
run
a
quick
command
which
you
can
you
can
check
on
the
ingress,
the
our
sorry,
the
contour
Doc's
on
how
to
run
this
in
the
troubleshooting
Doc's,
how
to
run
this
dot
command.
I
also
have
it
on
my
website,
which
will
be
the
blog
post
will
be
in
the
description
below.
A
But
basically
what
this
enables
us
to
do
is
to
see
exactly
what
the
contour
graph
is
routing
with.
So
we
can
see
inside
of
here
that
we
have
a
listener.
It
goes
to
ping
octets
comm
when
it
receives
traffic,
it
always
routes
to
the
ping
ping
v1
application.
So
very
good.
We'll
use
this
as
a
troubleshooting
tool,
as
we
get
deeper
into
this
this
setup,
all
right,
so
we've
got
the
dot
created
so
backing
up
a
bit.
Let's
talk
a
little
bit
about
making
this
weighted,
so
we
can
sort
of
switch
the
traffic
over.
A
So
the
first
thing
that
I'm
gonna
do
here
is
I'm
going
to
take
what
I
applied
for
ping
and
I'm
gonna
go
ahead
and
delete
that
for
a
moment
just
so
that
it
can
cleanly
go
away
now,
you'll
notice
in
the
buffer
in
my
bottom
right,
there's
no
more
ping
requests
coming
through.
So
it's
probably
not.
Why
is
that
I've
just
deleted
it,
but
let's
say
we
have
an
outage
for
for
right
now,
going
back
to
the
slides.
A
This
gives
us
a
good
opportunity
to
talk
about
the
ingress
route
CRD
so,
rather
than
going
through
this
model
of
having
many
many
annotations
to
satisfy
this.
One
of
the
interesting
things
that
contour
created
is
a
ingress
route,
custom
resource
definition,
and
this
is
something
that
we're
hoping,
or
at
least
I,
selfishly
hope
that
the
community
as
a
whole
might
at
some
point
kind
of
converge
on
how
to
do
some
type
of
semi
canonical,
but
also
like
pluggable
specifics
CRD
for
things
like
ingress.
A
So,
as
you
can
see
on
the
right
here,
a
lot
of
what's
inside,
of
the
CR
D
doesn't
look
too
different.
It's
just
called
an
ingress
route.
However,
if
you
look
inside
the
spec,
there
are
definitely
some
differences,
so
you'll
notice
inside
a
virtual
host.
The
fully
qualified
domain
name
is
how
we
express
the
hostname.
You
also
notice,
you
have
more
specific
fields
and
I
might
have
some
spacing
issues
here,
because
it's
in
slides,
of
course,
but
you
have
a
actually
I,
don't
think
I
do
so.
A
You
have
a
strategy
where
you
can
set
the
actual
strategy
for
this
ingress
route.
In
saying,
in
this
case,
weighted
least,
requests
you'll
also
know
you
can
go
into
the
routes,
and
this
is
especially
important.
The
service
mapping
is
not
too
different,
but
notice.
We
now
have
a
weight
property
inside
of
here
so
with
weighting
you're,
probably
starting
to
see
where
this
is
going.
A
You
can
wait
to
specific
services
which
enables
us
to
do
that
more
specific
weighted
load,
balancing
that
we
wanted
to
do
for
the
ping
application
and
then
there's
many
many
more
things
inside
of
this
ingress
route
that
we
can
do
and
we'll
even
explore
in
this
video.
But
this
just
gives
you
an
idea
of
how
you
can
have
a
more
structured
schema,
validated
way
to
express
advanced
ingress
rules,
be
it's
things
like
TLS
pass-through
for
some
of
your
apps.
A
So
if
you
want
the
TLS
to
actually
terminate
on
the
pot
itself,
perhaps
some
of
these
services,
you
want
to
do
TCP
proxying.
So
you
want
to
kind
of
go
back
on
layer,
4
and
not
rely
on
the
layer
7
notion.
Perhaps
you
have
different
balancing
algorithms.
You
want
to
use
and
weighted
balancing,
as
we
talked
about
there's
even
a
feature
set.
That
is
going
to
be
pretty
critical
to
us
in
a
moment
around
resource
delegation
and
we'll
talk
a
bit
about
how
these
ingress
routes
can
be
used
to.
A
Actually,
in
a
multi
team
or
perhaps
multi-tenant
environment,
so
let's
go
back
to
our
ping
app
and
explore
this
in
a
real
example.
So
inside
of
the
ping
app
I
have
an
ingress
route
resource
which
again
does
not
look
too
dissimilar
to
our
existing
ingress,
still
going
to
qualify
ourselves
on
the
ping,
pets,
comm
and
we're
gonna
start
out
with
just
a
weight
of
a
hundred.
A
So
I
want
to
start
out
with
saying
ping
v1
you
receive
all
the
traffic
and
if
there's
a
weight
that
is
present
inside
of
this
ingress
route
and
then
some
other
service
doesn't
have
a
weight.
It's
going
to
be
assumed
that
that
weight
is
zero,
so
we
can
just
bring
ourselves
back
to
our
original
functionality.
So
let's
go
ahead
and
apply
this
particular
ingress
route.
So
we
will
do
a
cute.
Cuddle
apply
all
right
now,
inside
of
our
top
buffer.
A
Here,
I'm
gonna
update
us
one
more
time
and
I'm
gonna
make
sure
that
we're
looking
at
ingress
routes
instead
of
just
ingress.
So
let's
apply
that
here
and
now,
you'll
notice.
Our
ping
has
started
up
again
because
obviously
contour
picked
that
up
flipped
it
through
the
graph,
and
you
can
also
see
some
of
the
new
information,
the
ingress
route,
which
gives
us
a
little
bit
more
details,
not
only
the
fqdn
and
perhaps
TLS
secret
and
route.
One
of
my
favorites
is
the
status
so
something's
going
terribly
wrong.
A
We
could
oftentimes
look
at
the
status
of
that
CRD
and
figure
out
why
contour
was
unable
to
satisfy
it
all
right,
cool
and
we
might
as
well
update
the
dot
to
just
so.
We
can
kind
of
make
sure
that
everything
still
looks
good
cool.
So,
aside
from
the
border
getting
bigger,
we
pretty
much
have
the
same
thing
going
on,
but
you'll
notice.
Now
we
are
set
up
to
potentially
route
to
ping
v2.
A
So
let's
get
some
of
the
weighting
in
and
see
if
we
can
solve
for
this
hinari
use
case
that
we
were
talking
about
so
I'm
gonna
shift,
15%
of
traffic
into
ping,
v2
and
then
85%
of
traffic
into
ping
v1.
Let's
do
that
now,
alright,
so
going
back
to
here,
let's
go
ahead
and
edit.
In
fact,
you
know
if
we
just
edit
this
directly,
it
might
make
for
a
better
example.
So
I
will
do
a
cube
cuddle
edit,
and
we
will
do
this
inside
of
the
namespace
ping.
A
Great
okay,
so
it's
not
beautiful
as
far
as
colors
go,
but
that's
okay.
So
what
do
we
want
to
do
here?
Well,
we've
got
a
weight
of
a
hundred
four
ping
v1.
We
want
to
bring
ping
v1
to
a
weight
of
C
here,
a
weight
of
85
cool,
all
right
and
then
for
our
next
one.
Here
we
are
gonna,
do
a
weight
of
15
like
we
had
talked
about,
so
let's
go
ahead
and
save
that
up
all
right-
and
now
you
can
see
inside
of
here,
we've
got
some
instances
of
pong
starting
to
come
through.
A
So
now
you
know
if
we
took
a
large
sample
size
of
this,
we
should
start
to
see
that
roughly
15%
of
our
requests
are
now
routing
to
the
v2
of
the
app,
which
is
pong
really
cool.
So
we
have
a
way
to
express
these
more
advanced
use
cases
like
doing
canary
style
deployments
and
then,
of
course,
eventually,
our
team
is
going
to
be
extremely
happy
with
how
this
went.
I
think
my
editor
is
just
set
wrong.
A
So
let's
see,
if
I
export
that
maybe
you'll
be
able
to
see
it
in
color,
let's
edit
this
there,
we
go
so
you'll
edit
this
one
more
time
and
then,
if
we
come
back
in
here
after
this
great
success
of
pong,
we're
gonna
bring
this
to
10.
We're
gonna
bring
pong
up
to
90,
save
that
one
more
time
and
then,
as
you
could
have
probably
guessed,
we're
mostly
going
to
see
pong
now
with
a
couple
pings
floating
through
every
now
and
then,
as
we
saw
with
our
dag
as
well.
We
have
this
ping
docked.
A
It's
calm
that
is
routing
to
these
two
services,
so
a
pretty
cool
setup
and
pretty
easy
to
troubleshoot
and
reason.
With
with
what's
going
on
here.
Okay
now,
I
have
another
use
case
that
I
want
to
tackle
with
you
all.
We
talked
a
little
bit
about
this
notion
of
the
ingress
route.
Having
these
delegation
like
capabilities,
so
what
exactly
does
ingress
router?
Even
ingress
delegation
mean
exactly
so
backing
up
to
my
company
for
a
moment.
A
A
Okay,
so
in
fact
let
me
just
kill
this
watch
for
a
moment,
so
we're
gonna
apply
the
mountains
app
fantastic,
so
the
mountains
app
is
a
service
that
our
company
offers
that
effectively
provides
a
screenshot
or
I
guess
a
picture
of
a
mountain
so
that
you
can
take
that
mountain
landscape
and
use
it
as
the
background
of
your
computer.
So
as
you're
depressed
throughout
the
day,
you
can
look
at
what
the
outside
looks
like
and
then
perhaps
be
excited
by
nature
right.
A
A
Let's
see
here,
we'll
do
sorry
we'll
do
a
cute
cuddle
fly
and
I
have
this
other
file
in
here
daemul
good
deal,
okay,
all
right!
So
I
set
some
things
up,
we're
kind
of
backing
up
and
refreshing
here,
and
let's
pretend
that
our
company
is
really
excited
about
this
new
app
that
gives
mountain
landscapes
as
a
service.
Okay.
So
we
come
back
to
our
web
browser
here
and
we
want
to
go
to
the
mountains
website.
A
So,
if
I
take
a
look
at
my
ingress
route
for
mountains,
I'll
just
back
up
one
more
time
here
and
we
go
into
mountains,
mountains.
Let's
see
ingress
route
ins
see
what
I've
got
a
call
I
our
mountains.
Okay,
so
we
have
an
app
here.
It
routes
into
a
service
called
mountains,
fantastic,
so
assume,
I
have
that
deployed
and
set
up.
Would
you
saw
me,
do
keep
cuddle
fly
on
that
and
for
Mountain
stock
pets?
Calm
I
should
receive
a
beautiful
picture
of
a
mountain
range
great.
A
A
This
does
not
look
like
a
mountain
range.
In
fact,
if
you're
expecting
a
mountain
range,
it
would
probably
depress
you
quite
a
bit
and
no
offense
if
you're
a
big
fan
of
waiting
in
lines
or
going
to
the
DMV.
So
we
think
about
this
for
a
moment
and
we're
kind
of
like
all
right.
So
what's
going
on
here,
why
is
our
Mountain
app
clearly
serving
the
wrong
thing?
A
So
we'll
go
back
into
our
our
terminal
for
a
moment
here
and
let's
produce
that
dot
output
one
more
time,
I'm
gonna
refresh
this
and
let's
see
what
our
company
is
currently
routing.
So
looking
at
the
visualization
of
our
graph,
we've
got
our
listener
coming
in
at
80
80
and
that
routes
two
lines
and
mountains
now
what's
interesting
about
here
is
if
you
follow
the
path,
two
mountains,
both
that
in
lines
route
to
the
same
service.
A
So
apparently
we
have
some
type
of
conflict
here
and
as
the
administrator
who
has
an
idea
of
some
of
the
things
running
in
your
cluster,
you
realize
oh
yeah.
We
have
another
department
in
our
company
that,
instead
of
serving
up
mountain
landscapes,
they
serve
up
pictures
of
people
waiting
in
lines
right
and
obviously
the
audience
between
these
two
things
is
vastly
different,
but
for
some
reason
the
lines
come.
A
group
or
team
was
just
able
to
take
over
the
mountains,
fully
qualified
domain
name
and
just
route
to
that.
A
So,
let's
see
if
we
can
fix
this
real
quick,
so
we
have
a
mountains,
a
mountains,
yeah
Mille,
so
we'll
do
mountains
like
we
looked
at
so
mountains,
dot,
yeah
Mille,
so
maybe
we
just
didn't
apply
this
right.
So,
let's
see
if
we
could
apply
this
and
then
get
our
mountains
service
back,
so
we
will
go
ahead
and
do
another
watch
on
mountains.
Okay,
so
I
will
do
an
apply
here
for
mountains,
IR
Mountains,
dot,
animal
and
it
will
create,
but-
and
this
is
where
status
is
gonna-
help
us
out
a
bit.
A
It's
a
bit
wrapped
here.
If
you
look
closely,
it's
letting
us
know
in
status,
hey
this
is
invalid.
You're,
fully
qualified
domain
name
Mountains
is
used
by
multiple
ingress
routes.
Okay,
so
you
can
probably
get
an
idea,
and
you
probably
could
even
from
this
graph
what
our
issue
is
here
right.
We
have
a
system
in
place,
we're
theoretically,
someone
can
just
hop
in
and
ask
for
a
fully
qualified
domain
name
and
contour
will
respect
it
in
this
case,
lines
is
effectively
taking
over
the
fully
qualified
domain
name
that
should
be
owned
by
the
mountains
group.
A
So
what
does
this
effectively
mean?
And
why
is
this
an
important
thing
to
consider
what
a
lot
of
folks
get
into
setting
up
their
first
kubernetes
cluster
things
go
clusters.
Things
go
really
well
at
first.
You
know
they
have
an
initial
app,
but
then,
in
some
cases,
where
they're
not
just
doing
a
cluster
per
application
or
team.
In
some
cases
they
start
getting
down
the
road
of
multi
team
clusters
or
even
more
multi-tenant
type
clusters.
A
This
is
where
things
get
pretty
tricky,
because
now
you
don't
just
have
to
solve,
for
how
do
I
get
traffic
into
my
cluster,
but
you
also
have
to
solve,
for
how
do
I
ensure
a
group
that
might
be
the
lines.
Department
only
has
the
ability
to
create
certain
things
that
the
mountain's
group
shouldn't
be
able
to
create
and
same
with
reverse.
How
do
I
make
sure
the
mountains
group
can't
create
things
that
only
the
lines
group
should
be
able
to
create
so
effectively.
We
need
to
think
about
this
in
terms
of
delegation
of
resources.
A
So
in
this
case,
if
you
look
at
the
diagram
here,
we've
got
some
type
of
ingress
load
balancer.
It
could
be
nginx
H,
a
proxy
contour
traffic
and
as
we're
deploying
these
ingress
objects,
you
have
the
same
scenario.
You
have
team
a
requesting
host
team,
a
and
Team
B
accidentally
request
requesting
team
a
as
well,
even
though
the
destination
are
two
different
places.
So
the
question
is,
you
know:
what's
gonna
happen
here?
Is
it
gonna
be
a
deterministic
behavior?
Will
it
just
fail
all
together,
because
the
same
thing
was
asked
for
twice?
A
What
would
we
expect
to
occur
and
the
answer
is:
it's
gonna
depend
on
your
ingress
load,
balancer
choice.
What
what
controller
did
you
choose?
Engine
acts
DJ
proxy
contour,
that's
going
to
impact
what
the
behavior
is,
but
nonetheless
we
really
just
don't
want
this
to
be
possible.
So
how
can
we
protect
against
these
types
of
invalid
host
configurations
or
just
invalid
ingress
configurations?
One
approach
that
I've
seen
in
a
couple
different
environments
actually
think
it's
a
suit
for
valid
approach.
A
You
can
run
in
the
kubernetes
cluster
oftentimes,
but
perhaps
outside
to
some
degree,
but
you
could
run
them
in
the
cluster
and
they're,
just
like
a
little
web
service
that
when
the
API
server
gets
a
request,
if
you
have
a
validating,
webhook
admission
controller
hooked
up,
it
can
take
that
request,
shoot
it
over.
To
that
admission
controller,
the
admission
controller
could
run
some
rules
against
it
or
just
logic
and
come
back
to
the
API
server
and
say
hey
the
lines
team.
That's
requesting
this.
They
should
not
be
asking
for
this.
A
Fqdn
deny
this
request,
and
this
hasn't
become
a
really
popular
pattern
with
a
lot
of
things
and
even
the
project
which
you
may
have
used
inside
or
outside
of
kubernetes
called
open
policy
agent
was
designed
to
provide
this
types
of
rules
engine
and
allow
you
to
kind
of
standardize
on
a
language
or
a
syntax.
If
you
will
I
guess
a
DSL,
really
that's
going
to
provide
you
with
these
types
of
rules.
So
that's
one
way
you
can
do
it
and
can
be
completely
valid.
A
Another
way
is,
you
could
think
about
this
in
terms
of
route
delegation.
So
what
if
our
ingress
route
c
RDS
were
powerful
enough
such
that
we
could
have
kind
of
like
an
administrator
name
space
where
we
could
provide
the
delegation
in
one
place
for
which
routes
folks
are
allowed
to
start
creating
ingress
resources
in
that
seems
like
a
pretty
interesting
approach
and
that's
effectively
what
I
want
to
show
you
here.
So
let's
take
a
look
at
this
if
we
back
over
to
our
back
up
over
to
our
terminal
for
a
moment.
A
I'm
gonna
go
to
the
you
know
what
let's,
let's
watch
the
lines
app
for
a
moment
so
inside
of
lines,
you
can
see
the
second
ingress
route
that
I
was
requesting
to
create
called
mountains,
and
that's
where
you
see
this
invalid
fqdn
here
so
first,
let's
rip
this
out
because
obviously
it's
it's
not
supposed
to
be
this
way
in
the
first
place.
So
I'm
gonna
do
a
cube,
cuddle
delete
for
the
lines
app,
and
this
will
be
ingress,
trout
lines.
A
You
know
it
actually
need
to
delete
the
specific
ones.
So,
let's
go
ahead
and
delete
that
so
I
intentionally
put
two
in
restaurants
in
one
file
just
to
show
this
example
of
it
messing
up
so
I'm
going
to
delete
in
the
namespace
lines,
this
ingress
trout
and
then
that
will
go
away
now.
If
we
come
back
to
Mountains
for
a
moment
here
now,
we
can
see
because
of
the
beauty
of
CRD
statuses,
that
this
is
valid
and
if
we
produce
our
dot
output
one
more
time.
A
We
can
also
see
in
this
diagram
that
now
we
have
you
look
towards
the
top.
It's
shifted
around
a
bit.
We
now
have
a
route
through
mountains
that
goes
to
the
mountains
service
itself,
which,
on
a
conceptual
level,
this
looks
a
lot
more
valid
for
what
we
need.
Okay.
So
if
I
come
back
to
mountains,
doc,
Ted's,
calm
and
refresh
now
we
have
a
much
better
looking
picture
of
Indian
Peaks
wilderness,
which
is
a
place
in
Colorado.
If
you've
never
been
it's,
it's
really
beautiful.
A
On
the
way
up
to
Pawnee
pass
and
if
I
go
to
lines
just
to
make
sure
that
we
didn't
break
anything
with
the
lines
group
because
serving
their
background
pictures
is
very
important
too.
We
can
still
produce
pictures
of
people
waiting
in
lines.
If
that's,
if
that's
more
of
your
thing
so
great,
but
obviously
we
haven't
solved
the
problem,
for
how
did
we
get
here
in
the
first
place
and
and
that's
the
crux
of
what
we
want
to
solve
here?
A
So
if
we
back
up
a
little
bit
for
just
a
moment,
I
want
to
introduce
the
notion
of
a
namespace
where
I
can
provide
this
level
of
delegation
now.
Here's
what
this
is
effectively
going
to
look
like
on
a
conceptual
level
and
then
we're
going
to
look
at
it
in
the
terminal,
so
I'm
gonna
introduce
a
root
namespace,
okay,
so
the
root
namespace
is
going
to
be
what
I'm
gonna
call
ingress
system
in
my
in
my
cluster
here
and
inside
of
ingress
system,
I'm
gonna
have
these
delegation
objects
and
these
delegation
objects
are
gonna.
A
Allow
me
to
say
things
like
for
the
delegation.
Mountains
I'm
gonna
give
the
fully
qualified
domain
name.
Mountains
dog
pets
comm
only
to
the
mountains.
Namespace
and
same
goes
for
lines
lines,
dot,
octet
Co
only
to
the
lines
namespace,
so
people
in
the
mountains
namespace
all
they
have
to
worry
about,
is
creating
their
routes
and
might
create
one
for
Mount
Evans
for
Mount
Rainer
or
in
the
lines
namespace
same
thing.
A
You
create
one
for
the
DMV
line,
but
when
somebody
inside
of
the
lines
namespace
creates
another
fully
qualified
domain
name
for
mountains,
it's
gonna
blow
back
and
say:
hey.
You
don't
have
the
ability
to
use
this.
This
is
not
something
that
you've
been
delegated,
which
is
exactly
where
we
want
to
be
now.
A
This
is
going
to
require
a
flag
and
contour,
so
we
can
tell
contour,
which
namespace
to
look
to
to
provide
this
level
of
service
now
I'm,
not
even
sure
if
this
flag
is
correct,
but
I'll
show
you
in
a
moment
in
the
actually
mo
what
the
actual
flag
name
is,
but
nonetheless
there's
a
flag
that
allows
you
to
specify
this
namespace
alright.
So
let's
take
a
look
at
this.
It
should
be
pretty
simple.
So
first
thing
that
we're
gonna
want
to
do
to
make
all
of
this
work
is
obviously
we're.
A
Gonna
want
to
fix
up
contour,
so
I
am
going
to
put
a
watch
on
the
cube
the
pods
inside
of
contour,
so
there's
our
contour
right
there
now
another
thing:
I'm
gonna
do
in
this
bottom
buffer.
If
I
walk
in
and
go
to
the
manifests
for
contour
original.
In
fact,
let's
do
maybe,
let's
do
a
little
dip
here.
So
if
we
do
a
diff
on
manna-fest,
contour
original
and
then
contour
patched
you'll
get
to
see
this
change
that
I'm
gonna
make
firsthand
so
outside
of
a
couple.
A
Little
spacing
dips
that
I
messed
up
you
can
see
inside
of
here
on
the
left
is
our
original
contour
and
then
on.
The
right
is
going
to
be
our
new
contour.
So
here's
the
actual
name
of
that
flag.
It's
ingress
route,
root,
namespaces
and
we're
gonna,
set
that
equal
to
in
grass
system.
So,
just
like
the
diagram
implied
with
this
flag
in
place,
contour
is
going
to
look
to
this
namespace
to
figure
out
whether
the
ingress
resources
that
are
being
requested
are
valid.
Have
they
been
delegated
to
those
namespaces?
A
A
A
Okay,
there
we
go
looking
a
little
bit
better,
so
long
story,
short
I
had
a
small
amount
of
VMs
to
run
contour
on
so
I
messed
up
that
configuration
and
in
fact
another
thing,
I
messed
up
were
my
versions,
so
bear
with
me
as
a
lot
of
people
say:
don't
just
use
master
all
willy-nilly,
which
I'm
using
master
here
so
I'm
supposed
to
be
on
leave
one
dot
10.0.
So
let
me
just
check
that
real,
quick,
so
image,
V
zero,
sorry,
not
one
dot
10.0,
but
0.10.0.
A
So
let's
see
here
we'll
paste
that
in
alright
sleep
that
and
let's
apply
it
one
more
time
cool.
So
if
you
are
looking
for
these
animals,
these
are
also
in
the
blog
post
that
describes
these
steps
feel
free
to
check
that
out
for
the
right
ones.
I've.
Just
been
mucking
around
and
playing
around
so
it
broke
some
of
these
pieces,
so
contour
should
initialize
in
a
moment
here
and
two
out
of
two
should
become
healthy.
A
If
all
goes
well,
there
we
go
and,
like
we
said,
contour
is
now
serving
in
such
a
way
that
these
delegations
need
to
work.
So
if
we
go
back
to
our
mountains
and
hit
refresh
our
piece
is
broken
here,
so
I'm
still
getting
contact
with
envoy,
but
clearly
contour
is
not
able
to
give
it
its
information
anymore,
and
if
we
go
back
and
make
another
dot
output
here
and
do
a
refresh,
we
no
longer
have
beautiful
boxes
so
clearly,
we've
broken
something
which
is
an
expected
behavior.
A
So
let's
go
back
and
do
a
little
bit
of
cleanup
to
start
off.
So
if
we
watch
the
namespace,
so
let's
do
a
watch.
Fur
I
think
we
did
mountains
last.
So,
let's
see
if
we
can
do
that
again,
yeah
we'll
do
lines
just
to
start
out
so
alright.
So
we
have
lines
here.
You
can
see
now
root.
Ingress
trout
cannot
be
defined
in
this
me
space.
So
it's
actually
working
as
we
expected.
It's
letting
us
know:
hey
you're,
not
actually
you're,
trying
to
like
redefine
a
route
you're,
not
using
what
you've
been
delegated.
A
It's
clearly
breaking
right.
So
if
we
come
back
to
our
terminal
and
do
a
cube
cuddle
delete
and
we
delete
this
particular
object,
so
we
will
delete
the
lines
object
in
the
name.
Space
lines
make
that
go
away,
and
then,
let's
do
the
same,
clean
up
for
mountains
here
so
inside
of
mountains.
We've
got
the
same
error.
We
are
going
to
take
mountains
and
delete
that
as
well.
All
right,
so
oops
would
be
helpful
if
the
name
space
was
correct,
so
mountains,
great
all
right.
A
A
Basically,
what
I've
got
going
on
here
is
I'm,
creating
the
ingress
system
and
then
I'm
setting
up
to
delegation
objects
in
here
as
well.
So,
let's
put
a
watch
on
the
ingress
system
here
for
a
moment
all
right,
good
deal,
so
I
have
got
a
delegation
setup
for
ingress
route,
and
that's
this
here
and
another
piece
right
here
now.
What
are
these
delegation
objects
exactly?
Let's
take
a
look
so
taking
a
step
deeper
and
actually
sorry,
I'm
gonna
show
you
it
in
the
UML
form
here.
A
So
if
we
go
to
manifests-
and
we
go
to
the
ingress
system
for
a
moment
here-
so
obviously
I've
got
the
namespace,
which
is
effectively
what
I
showed
you
a
moment
ago
and
then
I've
also
got
the
delegations.
Now
the
delegations
are
just
ingress
routes,
they're,
not
necessarily
anything
special
or
a
different
object
that
we
need
to
worry
about.
You'll
notice,
the
big
difference
between
these
ingress
routes
is
they
specify
a
fully
qualified
domain
name.
A
They
specify
routes
just
like
any
other
resource
would
or
ingress
route
would,
but
particularly
they
have
this
delegate
or
delegate
attribute
inside
of
here,
which
is
effectively
achieving
what
we
on
the
slide.
So
we're
gonna
say
this
fully.
Qualified
domain
name
is
being
delegated
to
this
namespace
and
we
could
even
give
it
specific
paths
if
we
don't
just
want
to
give
it
route
and
everything
on,
but
for
now
it's
just
basically
showing
off
the
fqdn.
Then
four
lines:
octet
comm.
We
have
a
very
similar
model
in
place.
A
We
have
lines
octet
s--,
we
have
the
/d
M
V,
so
in
this
case
we're
gonna
provide
it
only
with
the
DMV
path,
because
for
some
reason
we
want
to
reserve
the
route
and
we're
going
to
give
that
to
the
lines
a
namespace.
So
now
we've
got
that
set
up.
So,
let's
see
if
we
can
bring
our
dag
back
in
order
so
that
it's
working
again
and
actually
route
it
now.
What
will
the
actual
ingress
routes
look
like?
So,
let's
start
off
with
getting
mountains
back
up,
since
that
one
is
rightfully
our
most
popular
service.
A
So
we'll
do
a
watch
on
these
mountains,
so
this
will
be
for
mountains
all
right
and
in
this
case,
I'm
going
to
show
you
the
slightly
different
ingress
route,
mantains
delegated
resource,
so
not
much
different,
still
an
ingress
route,
but
you'll
notice
in
this
case
we're
not
gonna
specialist
best.
We're
not
gonna,
specify
the
virtual
host,
specifically
the
the
fully
qualified
domain
name,
because
that's
no
longer
relevant
to
us.
A
We
have
that
delegated
and
we
are
going
to
be
able
to
set
ourselves
up
with
just
this
path
and
that
is
gonna
wrap
to
the
mountains
service
inside
of
our
cluster.
So
with
the
simplified
model
not
having
to
worry
about,
FPN
is
quite
nice.
If
we
come
in
and
instead
of
editing
it,
we
apply,
it
so
apply.
Mountains
will
now
create
that,
and
it
looks
like
our
status
is
valid
again.
So,
based
on
the
delegation,
it
looks
like
we're
running
this.
A
Let's
start
with
the
dot
output,
which
is
gonna,
give
us
a
looks
like
a
rule
that
looks
a
little
bit
reasonable
here,
so
mountains
going
to
mountains,
that's
good,
we'll
come
back
to
our
browser
and
refresh
and
boom.
We
have
mountains
again,
which
is
which
is
looking
really
solid,
all
right.
So
let's
do
the
same
thing
for
lines
just
making
sure
that
we
can
get
set
up
here.
So
similar
idea
with
lines
we
are
going
to
go
into
the
ingress
throughout
four
lines
will
do
I
our
lines
delegated
all
right
now.
A
Obviously,
lines
is
a
bit
of
a
different
beast,
because
it
has
a
specific
path
that
it's
allowed
to
use
so
we'll
wash
lines
for
a
moment
and
just
for
the
sake
of
testing
this
out.
Let's
assume
that
lines
wants
to
get
back
on
route
again,
so
just
lines:
route
namespace,
all
that
good
stuff.
So
if
we
do
an
apply
on
lines,
it
will
now
create
and
just
like
any
good
status
should
it'll.
A
Let
us
know
hey
you're,
using
what
you
wanted
to
delegate
to,
but
you're
asking
or
what
you
were
delegated
but
you're
asking
for
/or
route,
and
you
only
have
access
to
the
path
prefix
forward,
slash
DMV,
which
is
exactly
what
we'd
expect
to
happen
based
on
the
delegation.
So
let's
edit
that
one
more
time-
and
we
will
do
something
specific-
will
do
DMV
line.
One
as
the
resource-
and
we
will
apply
that
again
and
now,
if
we
come
back
to
octet,
calm
and
do
lines,
we
still
have
an
issue.
Let's
see
valid.
A
Oh
sorry,
of
course,
that
would
fail
right
cuz.
We
just
said
it
should
be
line,
DMV
line
one
and
there's
our
line
so
based
on
delegation,
we
have
successfully
been
able
to
set
up
mountains
to
limit
itself
to
that
fqdn
and
lines
to
limit
itself
to
that
fqdn
as
well.
So
again,
another
powerful
thing
that
we
can
introduce
by
having
this
in
restaurants
CRD
in
place.
A
Okay,
so
the
last
thing
I
want
to
talk
about
is
handling
TLS,
which
is
oftentimes
an
important
use
case
for
ingress
controllers,
a
common
pattern
that
a
lot
of
ingress
controllers
follow.
Is
they
support
the
ability,
for
you,
add
your
TLS
secrets
into
your
namespace
or
perhaps
another
namespace,
and
then
reference
that
secret
from
your
ingress
object
or
an
aggressor
out
object.
A
lot
of
ingress
controllers
also
support
the
ability
to
put
a
default
certificate
in
place.
A
This
is
usually
a
wildcard
certificate
that
companies
are
using
kind
of
as
a
fallback,
so
that,
if
you
don't
specify
your
own
TLS,
it
will
use
some
company
wide
wildcard
certificate.
Now
there
are
some
problems
with
this
model.
One
is
the
default.
Catch-All
is
often
too
much
of
a
catch-all
for
larger
orcs.
A
So
we're
gonna
examine
how
to
add
TLS
to
contour,
which
is
nothing
special,
but
then
we're
gonna
talk
about
how
we
can
use
some
features
to
actually
bridge
the
gap
between
this
multi-team
wildcard
default
search,
type
use
case.
We
want
to
be
a
little
bit
more
restrictive,
so
going
back
to
our
application
here,
I've
refreshed
it
a
bit.
I've
turned
off
delegation
for
routes
just
to
keep
things
simple
and
I
have
a
setup,
that's
pretty
similar
to
what
we
started
with
I've,
taken
the
the
lines
app
out
to
for
simplicity.
A
So
mountains
goes
in
it
routes
to
mountains.
8,000
simple,
as
that.
Now
what
I've
gone
ahead
and
done
is
I've
added
a
ingress
or
sorry
a
secret
to
the
the
mountains.
Namespace
and
I
can
show
you
that
secret
right
here.
So
this
secret
is
a
TLS
cert
and
a
TLS
key
that
are
base64
encoded.
So
obviously,
you'd
wanna
do
more
than
this.
If
you're
worried
about
people
seeing
this
key
and
you
have
it
in
the
namespace
of
mountains
and
it's
called
octets
TLS.
A
A
Let's
save
that
up
and
in
a
moment
we'll
see
that,
under
the
TLS
secret
column,
we
now
can
see
octet
TLS
and
if
we
do
the
dot
output
we
will
refresh-
and
let's
see
here
so
octet
TLS
is
the
name
so
make
sure
we
have
this
called
octet
TLS,
that's
TLS
in
the
mountians
namespace
make
sure
that
I
had
that
applied
because
perhaps
I
didn't
create
it.
Okay,
that
would
be
very
helpful.
A
So
now
it
exists,
which
is
super
important,
and
if
we
refresh
this,
we
can
now
see
ourselves
going
from
mountains
to
the
secret
and
that
will
route
over
here,
and
we
also
can
do
things
like
allow
for
insecure
routing
on
still
HTTP
for
the
service.
But
those
are
all
things
you
can
look
up
in
the
docs.
What
this
means
is,
if
I
refresh
you,
can
now
see
I'm
on
HTTP,
my
certificates
kind
of
silly,
but
it's
just
for
the
sake
of
example:
I
have
star
octets
com,
so
this
is
actually
a
wild
card.
A
A
It's
gonna
push
back
and
say:
no,
you
can't
do
this,
so
this
is
actually
something
that
you
can
currently
do
in
contour
zero,
ten
plus
this
slides
a
little
bit
outdated,
but
nonetheless
you'll
be
able
to
see
this
right
here
and
and
in
dive
in
and
test
it
yourself.
So
let's
try
to
move
this
model
where
we
hold
the
Stila
secrets
in
this
administrative
ingress
system,
namespace.
So
first
things.
A
First,
let's
go
back
to
here
and
that
TLS
secret
just
to
make
sure
we're
not
cheating,
let's
go
ahead
and
delete
that
real,
quick,
okay
and
in
our
watch
up
top.
Let's
set
up
another
watch
in
the
ingress
system.
Namespace
now,
in
this
case
I'm
going
to
be
looking
for
secrets
in
TLS
delegation
which
I've
already
uploaded
some
of
them
here,
but
I'll
show
you
them.
So
if
we
edit
that
manifest
wildcard
TLS
and
we
put
this
inside
of
the
namespace
ingress
system,
so
we're
uploading
that
same
certificate
and
key.
A
So
we
will
go
ahead
and
apply
that
all
right
so
remains
unchanged.
Just
to
make
sure
nothing
has
changed
here.
So
that's
effectively.
What
we've
got
here
called
octets
TLS
and
then
we've
got
this
certificate
delegation
object.
So
let's
look
at
this
as
well.
So
I
have
this
in
manifest
TLS
delegation,
and
this
looks
just
like
what
we
saw
in
the
slides.
We
have
the
particular
secret
name
that
we're
referencing
and
then
we
have
the
target
namespaces
mountains
and
trails
that
we
are
going
to
allow
to
utilize
this
secret.
A
So
we'll
save
that
all
right
and
now
we're
looking
good.
So
if
we
go
back
and
watch
the
mountains
namespace,
you
can
see
here,
let's
go
ahead
and
just
put
our
other
watch
back
in
real
quick.
So
that
looks
a
little
better
cool,
so
you'll
notice
that
mountains
is
still
saying
it's
valid,
which
it
is
and
it's
referencing
this
TLS
secret.
But
if
we
come
in
and
produce
the
dot
output
again
and
then
I
do
a
quick
refresh
on
this
you'll
notice
that
the
graph
no
longer
looks
quite
right.
A
In
fact,
you'll
notice,
the
HTTP
path
is
completely
gone.
We
are
only
routing
to
the
HTTP
service
through
normal
HTTP.
Now
this
is
actually
expected
because,
if
you
think
about
it,
our
ingress
route
now
needs
to
reference
the
octet
TLS
that
exists
in
the
ingress
system
namespace.
So
that's
a
bit
of
a
change
for
us.
A
So
if
we
edit
this
one
more
time,
okay
and
in
secret
name,
we
instead
put
in
the
ingress
secret
namespace,
so
now
we're
kind
of
qualifying
that
I'm,
sorry,
not
secret,
but
ingress
system,
namespace,
we'll
save
that
secret
up
or
that
change
up
really.
In
a
moment,
it
will
refresh
again
the
beauty
of
the
see
RDS.
We
can
now
see
that
we're
referencing,
this
particular
TLS
object,
and
if
we
go
in
and
reproduce
our
dot
we
will
refresh
and
there
we
have
it
so
now
that
the
secret
exists.
A
This
is
an
important
thing
of
kind
of
how
the
dag
is
created
right.
So
it's
not
gonna
actually
make
that
route
or
that
part
of
the
dag,
unless
it
can
satisfy
these
things,
you're
referencing.
So
now
it
can,
and
if
we
go
back
to
our
mountains
app
and
refresh
it's
business
as
usual,
we
now
have
mountains
in
here
as
well.
A
Now,
if
we
go
back
and
hypothetically
apply
the
lines,
so
let's
actually
look
at
the
lines
real,
quick,
cuz,
I
haven't
looked
at
this
one
in
a
little
while
so
we'll
do
ingress
or
outlines
I
guess
just
dot
yeah!
Well,
since
I
don't
have
the
delegation
set
up
okay,
cool,
let's,
let's
test
this
out
real
quick,
so
we'll
get
rid
of
the
mountains,
because
I
was
just
using
that
for
testing
cool,
so
we're
gonna,
add
TLS
in
and
then
we'll
put
in
a
secret
name.
A
Okay
in
this
secret
name,
we
want
to
kind
be
the
same
thing
right.
We
want
to
be
able
to
reference
this
same
ingress
system
secret.
So
if
I
watch
this
for
oops,
if
I
watch
this
for
lines
now,
we've
got
this
in
place,
looks
good
and
we
will
save
this
and
apply
it.
So
cute
cuddle
apply
good
deal
and
it
should
show
up
in
here.
Alright.
Now
one
of
the
things
that
it
has
done
is
its
reference
to
TLS
secret.
A
Now,
what
will
be
good,
eventually
and
I'm
sure
this
is
something
that
we'll
have
in
a
future
release,
hopefully
or
at
least
something
we'll
open
a
ticket
for
is
the
status
probably
shouldn't
say
valid,
I
wouldn't
think
offhand.
But
if
we
generate
the
dag
for
a
moment,
so
we
will
run
the
dot.
I
will
open
this
up
and
refresh
you'll
now
see
that
lines.
Octet
has
been
created
on
the
HTTP
path,
but
notice.
A
The
dag
is
not
referencing
it
on
HTTPS,
and
this
is
for
reasons
you
could
probably
guess
we
have
not
delegated
the
ability
to
use
this
secret.
So
contour
is
not
going
to
satisfy
that.
If
we
go
back
to
our
application
here
and
I
do
a
line
stock
pets
like
we
used
to
it
still
works,
but
if
I
do
an
HTTP
on
line,
not
octets,
it's
not
going
to
work
and
again
that's
the
beauty
of
this
delegation.
We're
now
hosting
our
secrets.
A
Inside
of
this
administrative
namespace,
we're
putting
our
delegation
rule
in
an
object
and
we're
ensuring
that
lines
is
unable
to
do
this,
so
you
can
see
kind
of
the
power
of
this
delegation
model
and
that's
about
it.
So,
hopefully,
this
gives
you
kind
of
some
good
insight
around
the
ingress
route.
Crd
and
some
of
the
things
I
think
you'll
see
certain
ingress
controllers
start
doing
like
traffic
not
too
long
ago,
released
in
restaurant
CRD
as
well.
A
That
I'm
haven't
looked
at
it,
but
I'm,
assuming
it
does
a
lot
of
similar
things
in
regards
to
advanced
functionality.
If
you're
interested
in
contour
check
out
the
project
on
github,
if
you
want
to
get
an
even
more
in-depth
or
at
least
a
different
perspective
on
some
of
these
things,
Joe
Beda
has
put
together
a
TGI
kei
episode,
and
the
link
is
right
here,
really
cool
walkthrough
of
some
of
the
awesome
things
for
contour
and
I
hope.
A
You
found
this
useful
if
you
did
my
Twitter
handle
is
in
the
bottom
left
and
you're
also
welcome
to
subscribe
to
this
video
and
check
out
my
blog
in
the
description
I'll
be
producing,
hopefully
a
lot
more
kubernetes
and
linux-based
content
very
soon.
So
thanks
again
for
your
time
and
I
hope,
you
found
this
useful.