►
Description
Learning Kubernetes ingress and ingress controller from Nick Young, the tech lead of Contour!
A
B
A
A
B
Yeah
so
yeah,
so
I've
got
my
I've
got
a
some
test
set
up
here
now.
I
just
wanted
to
talk
through
briefly
a
little
bit,
though,
about
what
ingress
is
you
can
see?
The
you
can
see
the
this
is
a
sample
ingress
object
that
I
actually
have
running
in
a
cluster
that
we
can
see
on
the
right
hand
side,
but
an
ingress
object
is
all
about
taking
your
stuff,
that's
running
in
your
cluster
and
exposing
it
outside
the
cluster.
B
B
Incidentally,
if
you
are
still
using
the
v1
beta1
objects,
you
really
should
move
to
gau
because
you're,
probably
on
an
old
version
of
kubernetes
as
well.
So
it's
all
about
just
exposing
exposing
services
generally
http
services
on
on
the
internet,
and
so
to
do
that
it
has
a
few
things.
So
the
main
thing
here
is
this:
rule.
Stanza
that
will
sort
of
expose
a
host
here.
B
Then
then
the
traffic
won't
get
to
your
ingress
controller,
and
so
nothing
will
happen.
So
I've
already
done
all
of
that
in
this
case,
and
so
this
this
is
actually
a
working
domain.
If
you're
watching
the
stream,
you
can
go
there
right
now
and
see
see
the
http
bin
service
and
try
it
out
if
you
like
so
yeah,
so
I
think
that's
sort
of
the
real
basics,
the
real
basics
of
what
an
ingress
is
for.
B
B
A
B
B
B
B
B
C
B
B
Okay,
so
yeah
in
here
you
can
see
here.
The
service
is
exposed
on
port
80,
but
we're
doing
tls.
What
this
means
is
that
this
is
asking
the
ingress
controller
to
actually
terminate
tls
and
and
then
send
http
from
the
ingress
controller
to
your
backend
service.
Now
the
way
that
you
do
this
is
you
need
to
have
this.
You
can
see
this
tls
stands.
It
actually
points
to
a
secret
name.
B
You
can
see
here
that
we
have
a
there's
a
contour
test,
one
service
secret
here,
that's
actually
created
by
cert
manager,
previously
yeah,
here's
one
I
prepared
earlier.
I
created
some
certificates
and
I
have
a
working
search
manager
set
up
here.
That
will
do
all
of
the
hard
work
to
manage
those
search
form
for
us,
nice,
yeah,
yeah,
yeah.
B
So
a
good
question,
though
yeah
so
yeah,
that's
that,
and
so
it
means
that
it's
up
to
you,
how
you
you
know
how
you
do
this
most
of
the
time
you're
you
consider
your
cluster
internal
networking
to
be
relatively
secure,
so
it's
not
always
necessary
to
do
tls
on
the
front
side
and
the
back
side
of
the
of
the
of
the
connection.
But
it
is
absolutely
a
thing
that
you
can
do.
B
There
are
ways
to
do
it
with
ingress,
but
it's
a
bit
complicated,
because
one
of
the
biggest
one
of
the
biggest
issues
with
ingress
is
that
what
I
am
showing
you
here
is
as
much
as
the
spec
as
it
stands
can
actually
do
right.
You
can't
do
anything
more
fancy
than
have
a
tls.
Have
a
tailor,
expose
a
tls
service.
You
or
you
can
have
multiple
services
backing
it
and
you
can
do
some
stuff
with
path
matching
and
things
like
that.
B
But
in
terms
of
like
actually
terminating
things
you
can
your
choices
are
tls
or
no
tls.
You
can't
say
I
want
to
do
back-end,
tls
or
mutual
tls,
or
you
know
any
any
other
sort
of
more
other
advanced
stuff
that
you
might
want
to
do
you
can't
it's
just
not
possible
to
describe
it
inside
the
ingress
object.
That's
one
of
the
reasons
why,
if
you
use
an
english
controller,
almost
all
of
them
have
have
a
custom
cid
or
something
like
that.
B
B
B
So
it's
in
the
project,
contour
namespace,
it's
got
a
contour
deployment
and
then
a
series
of
envoy
deployments
and
the
and
then
so
so
it's
gonna
onboard
daemon
set
a
contour
deployment
and,
most
importantly,
an
envoy
load
balancer
service.
What
this
does
is
this
sets
up
in
the
cloud
that
I'm
using
it
sets
up
a
connection
between
this
ip
address
and
routing
to
the
routing
the
traffic
to
the
actual
envoy
service.
B
So
that's
how
the
traffic
that
you,
actually
when
you
and
your
browser
at
home,
actually
go
to
contour
test1.younglike.dev,
your
your
browser
is
actually
looking
up
dns
for
contour
test.youngneck.dev.
It
gets
this
ip
address
and
then
routes
to
the
load.
Balancer
that's
running
in
this
is
a
gke
cluster
runs
in
gke
and
then
that
sends
the
traffic
down
to
the
envoys
and
then
the
envoy
send
the
traffic
down
to
the
http
bin
service.
It's
all
right,
I'll
I'll
draw
a
diagram
of
this.
B
In
a
little
bit,
I've
got
a
mirror
board
ready,
but
that's
how
the
that's?
How
the
con
that's,
how
the
traffic
flow
actually
works,
and
so,
in
order
for
you
each
time
that
you
install
an
ingress
controller
and
a
cluster,
it
needs
to
set
up
this
like
traffic
path,
and
so
the
you
know
when
contour
does
it,
you
know
most
of
the
we
use
a
surface
type
load
balancer
here.
If
you
set
up
other
ingress
controllers,
they'll,
probably
use
a
service
of
type
load
balancer
as
well.
B
That's
one
of
the
things
that
most
ingress
controllers
use
in
this
cluster.
I've
actually
also
set
up.
I
think
I've
also
set
up
the
ingress
engine
x
controller
so
that
we
could
have
two
options,
and
so
this
has
another
a
separate
load,
balancer
ip
that
goes
to
the
to
the
ingress
engine
x
deployment
and
so
that
that
then
is
described
in
this
file.
The
contour
test,
two
one.
B
You
can
see
that
this
one
says
and
the
the
way
that
you
choose
between
these
is
with
this
ingress
class
name,
field,
contour
or
nginx.
So
now,
there's
a
this
english
class
name
field
is
a
little
interesting.
It's
it's
a
sort
of
a
modern
update
of
an
old
annotation
that
we
used
to
set.
That
was
just
a
string,
and
so
you
would
tell
your
english
controller
when
it
starts
up.
B
Hey
look
for
this
string
in
the
in
this
in
the
ingress
class
annotation
and
that's
how
you
would
have
them
there's
a
little
bit
more
complexity
to
it
now,
but
I
don't
know
if
it's
worth
getting
into
just
now.
The
important
thing
is
contour
test:
one
is
using
the
contour
ingress
controller
and
contour
test
2
is
using
nginx.
So
if
I.
B
B
B
A
It's
clear
to
me
so
far
and
for
for
people
who
are
watching
this
show,
if
you
want
to
asking
questions
in
real
time,
you
can
log
in
your
youtube,
account
and
leave
your
question
in
a
comment,
and
we
can
see
the
comment
in
real
time
and
answer
your
question
during
the
show.
So
for
those
who
who
are
first
for
our
first
time
watching
our
show.
Please
remember
to
do
that.
B
Yeah,
so
I
think
you
I've,
I
mean
there's
some
other
stuff
that
we
can
do
here
that
you
can
do
here
considerably.
We
can
change
this
english
class
name
to
contour,
but
the
I'd
need
to
do
dns
updates
to
make
contour
test
two
point
to
the
contour
load:
balancer,
not
the
nginx
one
and
that'll
take
like
five
to
ten
minutes
to
propagate.
So
I
don't
know
but
yeah.
That's
if
I,
if
you
did,
want
to
swap
contour
test
2
to
use
contour
instead,
that's
all
you've
got
to
do
is
do
this.
B
And
you
and
save
it
and
apply
it,
and
then
that
will
change
that
will
expose
this.
This
host
name
on
the
contour
load
balancer,
but
yeah,
as
I
said,
because
the
because
that
means
you've
got
to
update
the
dns
for
contour
test
2.
That
means
that
until
I,
until
the
dns
update
happens,
all
of
the
traffic
for
contour
test
two
will
flow
to
this
this
ip,
and
once
you
apply
that
change,
then
nginx
won't
be
serving
it
anymore,
so
it
will
just
404.
B
C
B
B
B
B
B
B
B
Yeah,
so
let
me
maybe
I'll
just
put
that
a
bit
closer,
so
it's
clearer
and
then
so
so
the
traffic
from
the
internet
is
going
to
come
straight
from
the
internet
to
that
ip
by
looking
up
this,
this
domain,
okay,
so
that's
all
fine
and
the
search
type
load.
Balancer
is
going
to
expose
the
envoys
now.
But
the
envoy
has
no
idea
what
it's
serving
and
what
it's
routing
until
it's
configured
and
so
in
contour's
case
we
have
a
separate
deployment.
B
Okay,
so
so,
if
we,
if
you
think
about
what
I
showed
you
before
inside
the
project,
contour
namespace,
there's
a
contoured
deployment
and
an
envoy
daemon
set
and
the
envoy
when
it
starts
up
it.
Actually
it
actually
connects
to
contour
and
contour
is
serving
a
port
and
that
port
serves
the
envoy
xds
protocol.
And
what
happens
is
that
when
contour
starts
up,
it
watches
the
case.
Api.
B
B
B
Come
on,
you
can
do
this
there
we
go
and
send
that
to
the
http
bin
service
and
then
everything
all
the
networking
knows
how
to
do
the
return
path
for
you
so
and
then
everything
works
and
you
see
the
thing
now.
The
other
thing
that's
important
to
note
here
is
that,
of
course,
you're
terminating
tls
at
this
point
on
the
envoy,
so
the
envoy
also
takes
the
the
secret
that
has
the.
B
B
Here,
yeah
yeah,
so
yeah
so
contours
contour
is
the
control
plane
and
the
data
plane
is
envoy.
The
nice
part
about
doing
it
like
this
is
that
you
is
that
it's
possible
to
manage
these
independently,
so
you
can
restart
contour
to
say
upgrade
it
or
if
something
goes
wrong
with
contour.
You
know
only
the
control
plane
stops
working.
B
What
that
means
is
while
you're
updating,
contour
or
if
contour
dies
for
some
reason,
then
envoy
will
keep
accepting
traffic,
but
no
changes
you
make
will
flow
to
envoy
until
the
control
plane
is
running
again,
so
it
makes
it
sort
of
separate
some
responsibilities
and
means
that
you
know
you
can
you
don't
need
to
sort
of
roll
everything
all
at
once?
I
mean
obviously
when
you,
if
you
want
to
upgrade
envoy,
then
and
you're
upgrading
a
demon
set,
then
you
the
each
each
envoy
that
goes
away.
B
You
won't
be
able
to
run
out
traffic,
but
kubernetes
knows
how
to
roll
a
demon
set
safely
for
you.
So
it'll
do
it'll.
Do
when
you,
if
you
update
the
spec
of
the
envoy
demon,
set
to
say
yo,
hey
upgrade
envoy
from
version
120
to
121,
then
kubernetes
knows
how
to
do
that
safely
and
it'll
do
one
at
a
time,
and
as
long
as
you
set
up
your
onward
demon
set
properly,
which
we
have
put
a
lot
of
time
and
effort
into
doing,
then
you
shouldn't
lose
any
traffic.
While
onboard
is
upgrading.
B
Okay
yep,
so,
let's
I'll
do
enginex
looks
a
little
bit
different
I'll
do
a
side
by
side,
even
though
the
cluster
is
actually
going
to
be
the
same
you,
but
the
the
things
will
be
a
little
bit
different,
so
in
in
the
case
of
nginx,
it's
actually
a
little
bit
different.
They,
the
nginx
setup,
is
that
is
that
there's
only
a
single
pod,
that
is
the
control
plane
and
the
data
plane
combined.
B
And
then
this
is,
and
this
one
is
instead
of
http
bin,
it's
echo
service,
so
the
so
so
in
this
case,
it's
mostly
the
same.
You
know:
we've
got
the
update
the
these
and
the
contour
ingress
so
yeah.
So
when
you
install
nginx
ingress,
it
also
creates
a
load
balancer
service
that
exposes,
in
this
case
this
ip
address.
B
I've
already
again,
I'd
already
pre-set
up
the
contour
test.
2
thing,
so
that's
how
it
works
and
then
ingress
engine
x
does
the
same
thing
it.
It
exposes
a
nginx
process
on
port
80
and
then
there's
another
there's
another
container
running
in
there.
That's
that
manages
generating
the
nginx
config
from
watching
the
kubernetes
thing,
and
so
every
time
you
update
the
kubernetes
config,
it
regenerates
the
nginx,
config
and
and
re
and
tells
the
nginx
process
that
there's
a
new
conflict
there
for
it
to
reload.
B
B
Okay,
so
yeah,
so
that's
sort
of
the
the
path
in
both
of
those
options.
You
can
see
that
most
of
it
is
the
same.
So
I
just
okay,
it
doesn't
look
like
we've
got
any
other
questions,
the
so
there's
a
couple
of
things.
I
can
show
you
now
one
of
the
things
I
thought
was
you
obviously
you
in
both
of
these
cases
in
the
the
contour
test,
so
the
contour
one
we've
got
we're
exposing
the
http
bin
service
in
the
nginx
one
we're
exposing
echo
service.
B
B
But
if
we
change
this
to
the
hdbin
service,
as
you
would
imagine,
that's
now
going
to
expose,
and
then
I
apply
that,
of
course,
that's
now
going
to
expose
the
the
http
bin
service
on
that
same
contour
test
two.
I
think
so,
if
you,
if
you
had
to
contour
test
two
in
your
own
browser,
you'll,
see
that
contour
test
new
two
now
also
shows
http
bin
or
same
as
contour
test.
One.
B
I
could
probably
share
that
on
the
screen
as
well
sorry
to
keep
swapping
backwards
and
forwards.
So
much
thank
you
for
being
the
streamyard
operator
yeah.
So
now
you
can
see
that
contour
test
one
and
contour
test
two
are
both
http
bin
and
then
so,
if
I
I'll
leave
it
on
here
for
a
sec,
while
I
just
quickly
go
and
swap
contour
one
to
echo
service.
B
B
Then,
if
I
go
back
and
refresh
contour
test,
one
you'll
see
it's
now
the
echo
service
and
not
have
been
right.
So
I
mean
this
is
pretty
basic
kubernetes
stuff,
but
like
the
that's
one
of
the
best
things
about
it
is
that
you
can
do
cool
stuff
like
that.
You
can
also
have
multiple
back
ends
and
then
it's
up
to
the
the
ingress
controller
as
to
how
it
handles
them.
Most
ingress
controllers
will,
by
default,
do
like
a
round
robin
between
them.
So
if
we
sorry.
B
Yeah,
it
looks
like
it
looks
like
that's,
not
working,
how
I
expected
so
hooray
for
demos
yeah,
so
that
that's
definitely
one
of
the
things
that
people
want
to
be
able
to
do
is
to
have
multiple
back
ends
and
do
a
weighted
awaited
thing
between
them.
It
doesn't
work
so
well
ingress,
because
the
spec
just
doesn't
support
it
very
well,
and
different
people
have
done
it
in
different
ways.
So
that's
one
of
the
things
big
things
that
we
addressed
in
stuff
like
contours,
hp,
proxy
and
the
go
api
as
well.
B
B
So
the
the
basic
ingress
spec
does
not
include
like
details
to
to
do
that.
You
can,
you
can
match
on
path
and
I'm
just
pulling
out
the
spec,
because
it's
been
a
little
while,
since
I
looked
at
the
inquest
back
to
be
honest,
I've
been
all
in
on
gateway
api
for
a
while,
the
yeah,
you
can
match
paths,
you
can
match
host
names
and
that's
pretty
much
it
now
that
it's
not
to
say
that
english
implementations
don't
provide
you
with
ways
to
do
this.
B
In
the
spec
so
yeah,
so
basically,
if
we
look
at
this
thing,
we've
got
you
know,
rules
here
and
we've
got
the
you
know,
host
and
all
that
sort
of
stuff
and
then
so
and
then
there's
the
http
rule
type,
and
you
see
here,
I've
we've
got
paths,
I
don't
have
any
path
set
in
this
one,
it's
so
it's
matching
everything,
but
in
this
paths
one
you
can
say
path
type
and
then
just
the
path.
So
the
path
field
is
literally
just
a
string.
B
That
is,
that
is
matched
using
the
path
type.
So
you
can
have
some
implementation
support
like
regex
for
part
type.
Some
only
support,
prefix
matching
a
few
other
things
like
that.
But
like
that's,
basically,
you
can't
do
using
the
the
base
ingress
spec,
you
can't
do
header,
header,
matching
method,
matching
or
a
bunch
of
other
matching
types
that
people
really
really
want
and
need,
and
so
pretty
much
every
implementation
has
their
own
ways
to
do.
It.
B
B
Is
that
it's
it's
just
a
string,
so
there's
no
type
safety,
there's
no
type,
checking
there's
no,
it's
not
structured,
and
so
there's
no
way
to
to
make
some
of
this
stuff
a
bit
easier,
and
so
one
of
the
things
that
we
did
was
we
came
up
with
our
own
crd
called.
We
originally
made
one
called
ingress
route,
and
then
we
evolved
that
into
http,
proxy
and
http
proxy
does
have
the
way
to
set
all
of
those
things.
Sorry,
let
me
just
I'm
just
pulling
up
the
docs.
B
B
B
We
set
the
virtual
host
in
a
in
a
field
of
its
own
and
then
you
know
we
have
routes
and
the
routes
have
conditions.
So
in
this
case
we've
got
a
one
other.
Can
we
have
a
condition?
That's
a
prefix
path
match
and
that
sends
to
the
service.
That's
named
s1
on
port
80.,
but
in
the,
but
we
have
so
I'm
just
looking
for
it
yeah.
So
so
we
have
a
few
other
things
that
you
can
do.
You
can
have
you
can
mix
and
match
conditions.
B
Now
you
can
do
this
in
ingress
as
well.
So
in
this
case
in
this
one
here,
you've
got
to
you
the
slash
yeah
the
root
pre.
The
root
path
is
going
to
this
valid
service
and
the
slash
subpage
is
going
to
this
service
that
doesn't
exist
now.
Obviously,
usually
you
would
want
to
have
a
service
that
existed,
but
when
that
happened,
what
happens
here
is
that
you
know,
as
as
you
can
do
in
ingress
and
as
you
can
do
in
pretty
much
every
every
implementation.
B
This
sort
of
very
basic
path-based
discrimination
means
that
your
requests
to
exam
www.example.com
subpage
will
be
forwarded
off
to
this
service.
That
doesn't
exist
so
because
the
service
doesn't
exist
in
this
case,
envoy
will
actually
respond
with
a
503,
a
service
unavailable.
If
that
service
did
exist,
then
subpage
would
be
sent
off
to
a
different
kubernetes
service,
and
one
of
the
things
that
one
of
the
things
that
everybody's
implementation
does
by
default
is
that
on
that
path,
when
you
send
that
path
to
your
service,
your
service
will
actually
see
the
request
as
www.example.com
subpage.
B
Now,
a
lot
of
a
lot
of
services
expect
to
see
their
requests
come
in
at
the
root
path
at
slash,
and
so
one
of
the
things
that
we
added
to
http
proxy
is
that
you
can
rewrite
that
path.
So,
let's
I
think
I've
actually
got
a
yeah
here.
We
are
there's
a
better,
so
you
can
rewrite
that
path.
So
what
you
can
do
is
you
can
say
okay,
so
for
any
route,
when
you
have
the
when
you
match
the
thing.
B
B
We've
got
a
rewrite.bar.com
domain
name
that
has
that
is
routing
traffic,
to
slash
v1
api
and
replacing
the
slash
v1
api
route
that
you're
going
to
get
to
slash
app,
slash
api,
slash,
v1,
and
so
what
that's
going
to
mean
is
that
when
you,
when
you
route
traffic
to
this
v1
api,
what
your
app
will
actually
see
is
the
his
request
arriving
at
slash
app
api
v1
instead,
now
a
more
usual
way
to
use.
This
is
to
do
to
say.
Okay,
I
want
my
app
to
be.
B
I
want
this
app
to
be
exposed
at
you
know
the
usual
one
that
I
use
is
slash
api
and
slash
blog
right,
like
you've
got
and
the
marketing
team
say
controls
the
blog
and
the
you
know.
Api
team
controls
the
api,
and
so
the
marketing
team
has
a
look.
I'm
gonna
illustrate
this
in
code
rather
than
trying
to
talk
you
through
it.
B
B
A
B
So
the
so
the
reason
so
yeah
I
mean
the
reason
you
might
want
to
do.
That
is
that,
if
you
say
want
to
do
something
like
this,
so
yeah,
the
simplest
way
is
just
to
say:
okay,
the
slash
goes
to
one
service,
but
what
happens
if
you
want
to
use
on
bar.com
you
want
to.
You
want
to
expose
multiple
services.
B
Okay,
so
now
you've
got
you've
got
bar.com
is
the
virtual
host
is
the
is
actual
host
name
of
your
company
and
you've
got.
You
know
the
and
you've
got
a
you've
got
a
blog
and
you've
got
an
api
right
and
you
don't
want
the
blog
and
the
api
to
go
to
the
same
like
web
service,
and
so
in
this
case,
what's
happening
is
the
slash
blog
url
is
going
to
blog
the
blog
service
and
the
api
url
is
going
to
api
service,
and
that
means
that
you
know
for
your.
B
B
B
Okay,
so
this
one
means
that
you,
if
you
make
requests
to
anything
other
than
slash
blog,
slash
api
right,
then
then
it'll
go
to
this
site.
Services
said
that's,
probably
going
to
end
up
being
like
a
static,
a
static
service
or
something
like
that
that
just
serves
you.
Yeah
just
serves
like
your
your
main
website
right.
But
what
this
means
is
that
these
these
different
things
are
broken
up
into
different
services.
B
B
Yeah
so
remember
that
this
is
this
is
gonna.
This
is
gonna
change
things
from
the
services
point
of
view
right
like
so.
If
you
don't
do
the
prefix
replacement,
the
requests
that
come
to
you
know,
the
blog
service
will
be
to
bar.com
blog
yeah
right,
and
so,
unless
you
have
configured
the
blog
service
to
expect
that
it's
all
its
requests
will
come
in
on
slash
blog
it'll,
be
like
I
don't
know
about
this
blog
path.
B
You
know
I'm
expecting
everything
to
come
in
at
just
at
the
root
path
and
so
and
but
yeah
and
maybe
most
importantly,
maybe
there's
going
to
be
other
stuff
here
right.
You
know,
like
blog
category
or
something
like
that
right
and
all
of
those
you
know
all
of
those
things
will
be
rewritten
to.
As
far
as
your
service
is
concerned,
to
look
like
this
right
so
that
this
slash
blog
part
will
be
chopped
out
of
the
url
for
you
and
and
have
that
that
stuff
appended
on
the
end.
C
B
B
I
can
live
in,
can
live
in
a
separate
namespace,
and
so
what
that
means
is
that,
instead
of
your
instead
of
everybody
needing
to
have
access
to
the
default
namespace
to
be
able
to
manage
their
own
app,
you
can
say
to
people
okay,
marketing
team.
If
you
as
long
as
you
have
a
service,
that's
called
blog
in
your
marketing
namespace,
then
this
this
http
proxy
will
route
traffic
to
that
service,
and
so
it's
up
to
you
what
you
do
with
it.
B
You
can
have
you
know
you
can
have
you
can
swap
the
version
out.
You
can
upgrade
the
version,
all
that
sort
of
stuff
you,
the
http
route,
will
ensure
that
the
the
the
routing
keeps
going
consistently
to
that
service.
If
you
remove
that
service,
then
your
blog
will
disappear.
Right,
like
slash
blog,
will
be
a
503
but
the
but
yeah.
It's
up
that
sort
of
allows
the
marketing
team
to
do
to
do
some
stuff
themselves.
A
B
It's
just
it's:
it's
not
a
valid
field.
There
are
very
good
reasons
for
that
doing
this
sort
of
cross
namespace
reference
is
actually
ver.
It's
actually
can
be
a
security
risk
right,
because
if
you
imagine
that
you
know
we're
doing
something
else
here
right
like
you,
I'm
johnny
mccacker
and
I
get
access
to
the
default
name
space
and
I
find
out
that
the
payroll
system
is
running
in
the
payroll
namespace
right
and
is
the
service
is
called
payroll.
B
By
by
changing
the
thing
to
that,
I
have
now
exposed
payroll
on
bar.com
blog
right,
like
you
said,
because
this
the
person
who
owns
this
has
a
lot
of
power
to
sort
of
expose
anything
that
that
they
have
a
reference
to
right.
So
there
is
a
security
risk
here
that
needs
to
be
managed.
Now,
one
of
the
ways
that
you
can
manage.
B
B
B
Actually
need
any
of
that.
Okay,
what
what
this
is
actually
doing
is,
this
is
saying
include
the
http
proxy
in
the
marketing
namespace,
with
the
name
blog
and
for
all
the
paths
inside.
It
wrap
those
paths
with
this
slash,
blog,
okay
and
so
the
when
you
do
this,
you
can
have
your
blog
namespace
in
your
page,
free
proxy,
in
your
blog
in
your
marketing
namespace,
and
now
you
as
the
marketing
team
own
this
whole
http
proxy,
and
as
long
as
this
http
proxy
exists,
you
can
put
whatever
you
like
in
here.
B
Let's
say
as
far
as
the
this
default
namespace
thing
is
concerned,
I'm
just
routing
to
this
http
proxy,
but
this
http
proxy
says:
okay,
we've
got
two
services,
we
want
you
to
serve
traffic.
Out
of.
I
want
you
to
send
ninety
percent
of
the
traffic
to
the
blog
one
and
ten
percent
of
the
traffic
to
blog
v2.
B
Yeah,
and
so
some
of
this
stuff
is
just
not
possible
in
the
old
ingress
object
and
what
you'd
find
is
pretty
much
every
ingest
controller
that
has
that
you
know,
has
been
around
any
any
length
of
time
has
either
something
like
annotations,
like
ingress,
nginx
does
or
their
own
cid.
That's
similar
to
this.
That
does
the
same
things
that
let
you
do
weighted
load
balancing
to.
Let
you
break
up
the
config
more
more
clearly
lets
you
sort
of
share
the
conflict
between
different
people
and,
most
importantly,
stops.
B
B
What
will
happen
in
that
case
is
kind
of
undefined
right.
Ingress
engine
x
will
actually
load
balance
the
two
services.
So
if
you,
if
I
specify
at
my
echo
service
and
you
specify
your
echo
service,
then
then
the
traffic
will
be
load
balanced
between
them
and
if
we
both
specify
different
paths,
then
it
all
just
kind
of
work.
B
But
what
it
means
is
that
people
can
inadvertently
clobber
other
people's
config
just
by
creating
an
ingress
in
the
one
that
you
could
that
you
own,
and
so
that's
one
of
the
reasons
why
we
have
this
sort
of
delegation
thing
in
http
proxy
to
stop
people
doing
that
right
to
stop
it
to
make
it
so
that
you
can't
do
it.
You
have
to
you
know
only
one.
B
Only
one
http
proxy
can
have
the
bar.com
affiliate
right.
If
you
try
and
have
two,
then
both
of
them
then
there'll
be
errors
on
both
of
them
and
nothing
will
work
and
so
yeah
that's
a
very
deliberate
decision
we
made
to
sort
of
because
we
would,
when
we
were
building
this,
we
had
lots
of
people
who
were
running
multi-tenant
clusters
and-
and
we
wanted
to
make
it
so
that
that
you
know
that
problem
couldn't
arise.
A
B
Yeah
yeah
and
so
yeah.
We,
we
sort
of
started
this
process.
Man
like
over
three
years
ago,
now
that
yeah
we
we
built,
we
started
building
out
http
proxy
in
contour,
and
I
mean
if
we
are
okay,
it's
actually
a
really
good
segue
to
talk
a
little
bit
about
gateway
api.
If
we
have
enough
time
or
are
we
running
out
of
time.
B
Okay,
so
I
can
quickly
talk
through
why
the
gateway
api
ended
up
existing
and
then
we
can
talk
about
talk
through
the
details
of
the
gateway
api.
Another
time
so
you
know,
contour
is
here:
building
a
http
proxy.
You
know
solo
and
the
folks
building
glue
they
have
their
own
set
of
cids.
The
istio
folks
have
their
own
set
of
crds
that
do
the
same
thing.
It's
a
little
bit
more
complicated
because
istio
has
more
more
depth
to
it.
Who
else
is
there
kong?
B
B
So
we
ran
it
again
to
the
gateway
api
and
so
the
gateway
api.
Now
is
the
upstream
effort
to
take
this
sort
of
functionality
that
you
have
in
this
http
proxy
and
make
it
and
make
it
standard
and
make
a
standard
way
to
do
this,
that
everybody
can
do
that
in
an
ideal
world
for
simple
use
cases
I
mean
this
is
what
I'm
talking
about
here
with
wanting
to
do
like
you
know,
wanting
to
split
things
up
on
the
basis
of
teams
and
one
team
wanting
to
do
a
weighted
load.
B
Balance
like
this
should
be
pretty
straightforward.
You
know
this
is
a
reasonably
common
use
case.
It
should
be
reasonably
easy
to
do
this
and,
if
you,
if
you're
using
the
gateway
api,
one
of
our
goals
for
the
gateway
api
is
that
if
you're
using
contour
and
you
use
the
gateway
api-
and
you
describe
something
like
this-
you
can
take
that
exact
same
gateway,
api,
config
and
change
it
to
you,
know
kong
or
ingress
or
nginx
once
they
support
the
go
api
or
some
other
thing
that
supports
a
go
api
and
it
will
just
work.
B
You
can
literally
just
take
that
exact
same
config
and
how
and
be
doing
the
same
thing
here
where
you're
running
two
gateways,
you
can
take
the
the
routes,
the
http
routes
and
put
and
point
them
to
both
gateways
at
once,
and
everything
will
work
and
the
same
service
will
be
exposed
on
two
different
gateways:
two
different
us
controllers
and
everything
will
work
and
there's
nothing
that
you
need
to
change
to
move
between
inquest
controllers.
That's
the
that's
the
goal
of
the
game:
api!
That's
where
we
want
to
get
to.
C
B
B
You
know
we
go
through
a
kubernetes
api
review
and
you
know,
and
all
of
the
same
stuff
that
a
core
one
does,
but
we
deliver
the
actual
resources
with
with
the
with
crds,
and
so
these
are
kind
of
like
blessed
cids
upstream
crds
we're
only
the
first
to
do
this.
Other
people
have
started
looking
at
doing
it
for
bunches
of
other
places,
but
so
what
that
means
is
that,
in
order
to
use
the
gateway
api
first
thing,
you
have
to
install
the
go
api.
B
B
That's
going
to
be
reconciling
those
gateways,
then
you
create
gateways
and
now
gateway
describes
the
the
ports
that
your
that
is
going
to
listen
on
and
the
addresses
that
it
listens
on
and
then
you
add,
and
then
you
add
routes
which
describe
how
the
traffic
that
is
associated
with
a
listener
on
the
gateway
will
be
routed
to
services,
and
so
we
break
apart
the
config
even
more
right,
even
in
http
proxy.
You
have
like
one
object
that
handles
like
all
of
those
responsibilities
in
the
gateway
api.
B
We
kind
of
break
it
up
a
bit
so
that
then
different
people
can
under
the
different
chunks.
So
I
can
be
an
infrastructure
admin
and
my
job
is
to
install
the
go
api,
cids
and
a
controller
that
will
reconcile
them.
I
own
the
gateway
class,
then
I
mean
you're
the
you
can
be
the
the
sort
of
the
cluster
admin
and
you
can
say:
okay,
I
want
to
set
up
a
gateway.
B
That's
going
to
expose
that's
going
to
be
available
to
for
people
that
associate
their
http
routes
too,
and
then
so
that's
your
job
and
then
tj.
You
can
you
you
then
own.
The
http
route
and
you're
like
an
application
developer,
and
you
can
say
okay.
I
want
to
expose
my
app
on
this
on
this
listener
on
this
on
this
domain
name
in
the
same
way
that
you
do
with
ingress,
but
but
it
means
that
we've
sort
of
broken
up
the
different
responsibilities
in
a
really
clean,
logical
way.
C
B
Yeah
yeah,
so
it's
a
little
bit
similar
to
what
they've
done.
They've
sort
of
yeah
broken
things
up
into
gateway
and
routes
as
well,
but
we
also
took
inspiration
from
like
storage
class
and
story.
You
know,
storage,
class
and
pvs,
and
pvcs
and
stuff
like
that,
where
you
know
where
this
is
very
clear.
Hierarchy
of
objects
and
different
people
can
own
different
bits
of
the
hierarchy,
and
so
that's
that's
where
that's
sort
of
the
drivers.
For
for
why
we
were
sort
of
looking
to
do
looking
to
build
a
gay
api.
B
Now
I
kind
of
don't
want
to
actually
get
into
showing
too
much
of
the
yaml
of
that,
because
it's
whole
own
thing.
It's
pretty
complicated,
there's
a
lot
to
take
in
there
and
so
yeah.
I
kind
of
would
rather
leave
this
one
just
to
be
sort
of
you
know,
let's
talk
about
ingress
and
then
the
path
to
gateway
and
then
we'll
save
gateway
api
for
another
day,
because
it's
a
whole
hour
easily
by
itself.
I.
B
B
So
yeah
so
on
kubernetes
slack
we're
in
contour
yeah,
I'm
young,
nick
on
kubernetes
slack.
You
know
I
I'm
young
nick
on
twitter
as
well,
so
please
feel
free
to
ask
me
questions
there.
Yeah,
if
you
have
contour
related
things,
yeah
contour,
hashtag,
contour,
on
a
kubernetes
slack,
also
on
kubernetes
slack,
there's
the
I
think
it's
sig
network
gateway
api
or
something
like
that.
Let
me
just
check
the
name
hang
on.
B
It
is
yeah
hashtag
sig
dash
network
dash
gateway,
dash
api
is
the
go
api
channel
and
so
yeah.
If
you
go
in
there,
there's
plenty
of
people
asking
questions
about
and
and
sort
of
trying
to
get
everything
working.
So
we'll
go
api,
we're
still
very
early
days
for
the
gateway
api
but
yeah.
If
that's
the
place
to
go
to
ask
to
ask
questions.
B
C
B
So
for
contour
we're
going
to
be
continuing,
we've
had
some
there's
been
some
big
developments
recently.
Actually,
so
the
envoy
project
has
recently
started
an
envoy
gateway
project
which
is
basically
an
official
envoy
branded
controller
to
reconcile
gateway,
api
objects,
and
so
the
the
contour
maintainers,
the
vmware
contour
maintainers,
are
involved
in
this
project
and
practically
in
the
future
like
when
envoy
gateway
is
ga
by
that
time.
B
B
That
is
in
a
number
of
years,
though,
I
need
to
be
very
clear,
like
right
now
we're
developing
continuing
development
development
on
contour,
just
like
we
normally
would
because
we've
got
to
wait
for
you
know
to
see
what
happens
with
onboard
gateway,
contours
gateway.
Api
implementation
is
proceeding.
We
are
still
we
are
currently
a
conformant
kp
gateway
implementation,
so
the
gateway
api
has
its
own
set
of
conformance
tests
just
like
kubernetes
and
contour.
B
Currently
passes
all
of
those
or
if
it
has
a
couple
that
it
doesn't
pass,
they
will.
It
will
very
soon
we're
keeping
it
up
to
date
so
and
the
aim
for
envoy
gateway
is
to
make
it
also
a
conformant
implementation
and
then
to
sort
of
we
will
gradually
transition
a
lot
of
the
development
resources
we're
using
on
contour
to
developing
only
gateway
in
terms
of
vmware,
so
yeah
the.
B
I
think
that
the
future
for
contour
is,
I
mean
it
is
mostly
a
completed
product.
You
know
like
it
does
everything
we
need
it
to
do.
It's
gonna
work.
It
is
going
to
be
supported
until
people
are
not
using
it.
So
vmware
have
committed
that
it's
going
to
it's
all
going
to
be
supported
until
people
are
not
using
it
but
yeah.
B
The
future
for
contra
is
that
it'll
be
around
for
a
while
envoy
gateway
will
come,
a
lot
is,
is
coming
and
the
gateway
api
support
will
continue
moving
until
we
can
get
it
to
ga.
That's
the
goal.
That's
you
know,
bring
that
stuff
to
ga
and
have
it
be
a
standard
kubernetes
api
that
everyone
loves
and
everyone's
using.
A
That's
very
awesome:
yeah,
pretty
cool,
really
good,
I'm
looking
forward
to
that,
and
since
we
are
running
out
of
time,
so
thanks
everyone
for
watching
our
episode
and
big
thanks
to
nick
young-
and
I
mean
for
joining
us
today
and
and
share
this
awesome
knowledge
about
ingressing
and
hp
proxy
and
also
do
api
with
us
and
looking
forward
to
our
follow-up
episode
thanks.
Everyone
see
you
next
wednesday.