►
Description
Kubernetes Ingress: Your Router, Your Rules - Gerred Dillon, Deis
"How do we get traffic to our Kubernetes Pods? Reaching for a Service may be our first instinct, but we're walled in by the combination of service types and provider integrations Kubernetes provides. Service resources give little in the way of user control, leaving us to bolt on separate abstractions while hoping the functionality we need is available in the next Kubernetes release. These abstractions can easily become another routing layer that deeply couples to our other resources without any benefits from native integration at the cluster manager level.
Wouldn't it be better if we could integrate our applications and traffic in a natural, Kubernetes-native way? The built-in Ingress resource solves common access problems and empowers users to build software for handling custom traffic patterns."
About Gerred Dillon
Gerred Dillon is a Sr. Solutions Architect with Deis, where he works with customers to implement Kubernetes clusters and develop custom software on them. With a deep background in platform engineering, he is working to expand the Kubernetes tools ecosystem to enable all developers to create robust, resilient systems. Gerred and his family live in sunny Colorado.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! 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.
A
Okay,
I
think
we're
going
to
get
started
thanks.
Everyone
for
coming,
and
today
I'd
like
to
talk
to
you
a
little
bit
about
ingress
and
the
title
is
talk-
is
ingress
your
router,
your
rules,
I'm
Jarrod,
Dillon
I'm,
here
with
Deus,
and
if
you
want
to
learn
more
about
any
of
this
or
helm
steward
workflow,
any
of
it
come
talk
to
us
at
our
booth
and
I
spelled.
My
twitter
handle
wrong
up
there.
A
So
just
drop
off
the
last
two
letters,
and
it's
just
at
justice
rise,
don't
know
where
that
came
from
so,
but
what
I
really
want
to
talk
today
about
is
not
necessarily
ingress.
I
want
to
talk
about
container
networking
at
scale
and
I'm,
going
to
break
this
down
and
get
a
little
specific
and
what
I
mean
by
container
networking
by
container
networking
I.
Don't
just
talk
about
your
web
services.
We
all
think
that
we're
running
you
know
websites
and
api's
and
all
sorts
of
front-end
services,
and
that's
great.
A
These
are
all
very
normal
things,
but
I'm
also
talking
about
networking
of
different
workflows.
This
is
kotas
error
out
of
Amsterdam
and
they
deploy
regularly
hundreds
of
services
for
all
their
students.
I'm.
Also
talking
about
deploying
games
on
top
of
kubernetes
game
servers,
minecraft
servers.
If
you
look
at
the
helm,
charts,
we've
got
minecraft
factorio
a
whole
bunch
of
stuff
and
I'm.
A
So
what
do
I
mean
by
scale
I'm
talking
a
little
bit
just
more
than
I
have
a
billion
pods
across
a
thousand
nodes,
and
we
are
talking
a
little
bit
about
that.
Being
able
to
scale
out
is
a
very
important
kubernetes
goal,
but
this
is
a
very
much
mechanical
scaling,
especially
if
you're
a
stateless
application.
It's
pretty
easy
to
do.
I
just
scaled,
my
deployment
up
to
a
billion
container,
pods
and
I'm
good
to
go
as
long
as
I
have
the
notes
for
it.
A
A
A
But
I
want
you
to
look
at
these,
maybe
in
a
slightly
different
mindset.
Then
a
lot
of
the
other
talks
that
you
might
go
to
any
these
rules
expire
at
the
end
of
this
talk,
so
don't
go
home
and
start.
You
know,
quoting
what
I
tell
you
in
this
talk
as
far
as
this
goes
so
I
want
to
think
of
a
pod
as
a
single
internal
resource
and
I
think
you
can
think
of
that.
No
matter
what
like
that
right,
we
have
a
basically
at
one
static
bundle
for
our
site.
A
A
What
we're
really
talking
about
for
this
talk
is
I'm
mapping
a
virtual
IP
to
a
singular
resource,
and
it's
important
that
this
set
in
containers
is
entirely
isolated
as
one
unit
and
really
thinks
about
itself,
and
it
doesn't
care
how
traffic
gets
to
it.
So
if
something
comes
in
the
IP,
Q
proxy
gets
the
traffic
there.
I
don't
care
beyond
that,
and
because
you
haven't
looked
at
enough
manifests
today,
here's
a
pod
manifest
not
fully
filled
out,
but
you
get
you
get
the
gist.
This
is
just
a
Redis
pod
and
pretty
easy
to
fill
in.
A
That's
not
the
interesting
part
of
this
talk.
So
here's
where
things
here
to
get
weird
who
here
just
generally
throws
the
type
load
balancer
on
their
service
and
calls
it
a
day
just
goes
about
their
day
couple:
okay,
yeah
I!
You
know
when
I'm
testing
things
I
do
I
do
and
the
for
this,
for
what
we're
talking
about
today,
I
really
want
to
get
away
from
that
idea
of,
let's
just
slap,
a
load
balancer
on
it
and
call
be
done.
A
I
really
want
to
start
thinking
of
services,
kind
of
as
a
semantically
related
set,
and
that's
really
what
they
are.
If
you
think
about
how
labels
and
selectors
work,
you
have,
you
know
your
phone
application,
API
server
whatever,
but
you
have
a
virtual
IP,
that's
selecting
over
a
set
of
pods
that
match
a
certain
set
of
labels
right
and
again-
and
this
is
this-
is
where
things
change.
A
When
you
start
talking
about
the
or
in
a
bike
space,
what
a
lot
of
people
talk
about
with
a
service
is
a
services
isn't
necessarily
concerned
with
routing
some
people
use
it
that
way,
some
people
expose
external
traffic
via
service
and
that's
great
and
it
has
its
uses.
But
it's
really
that
semantics
set
and
and
just
a
singular
grouping,
that's
a
representation
of
our
resource,
and
it
cares
about
every
member
that
set
and
again
lots
of
manifest.
A
So
here's
here's
that
service
now
we're
here
what
I
really
want
to
talk
about,
and
that
is
our
ingress
resource
and
in
a
degress,
is
a
mapping
of
external
traffic
to
virtual
resources.
It
is
the
rules
by
which
we
take
inbound
network
traffic
and
map
it
to
a
set
of
services.
So
here
we're
starting
to
talk
about
really
networking
primitives
right
virtual
hosts,
external
IP
addresses
domain
names,
load
balancer
rules,
and
this
could
be
a
physical
load.
A
So
before
we
get
into
the
meat
of
that
and
talk
about
about
in
depth,
what
you
can
do
with
ingress
controllers
and
really
how
to
go.
Move
towards
your
own
ingress
controller,
we're
going
to
walk
through
the
standard
configurations
on
an
ingress
resource
and
will
return
to
this.
But
you
can
do
a
lot
of
things
with
them.
You
can
out
of
the
box
without
even
writing
your
own
config
and
things
like
TLS
things
like
path
based
routing
things
like
virtual
hosts
routing
based
on
domains
with
your
own
metadata.
A
You
can
come
up
with
as
many
crazy
custom
rules
as
you
want,
so
here's
a
quick
TLS
ingress
resource
right.
We
have
a
secret,
that's
our
certs
and
you
can
also
use
something
like
cube,
cert
manager
by
Kelsey
Hightower
to
get
at
those
stores
with
let's
encrypt
and
you
create
an
ingress
and
pointing
it
a
secret
and
point
your
back-end.
A
And
now
you
have
a
router
that
ties
up
your
TLS
certs
and
in
your
application
and
you're
done,
you
can
do
much
the
same
with
a
virtual
host
routing,
so
you
can
specify
multiple
rules
inside
of
a
single
virtual
host.
So
here
we
have
some
sort
of
billing
API
and
we
have
a
master
or
production
and
we
have
a
staging
API
both
backing
up
to
different
services,
but
semantically
also
part
of
the
same
ingress,
and
so
this
is
captured
up
up
in
some
sort
of
upstream
router.
That
will
then
take
this
manifest
and
expose
it.
A
We
can
do
the
same
thing
with
path
based
routing,
so
it's
all
pretty
clear.
Those
of
you
on
laptops
are
probably
taking
those
copying,
pasting
them
off
my
screen
and
you
create
the
ingress
resource,
and
maybe
maybe
you
know
you
type
it
all
in
and
run
it
and
great
I'm
about
to
start
sending
traffic
everywhere.
This
is
awesome,
I'm,
going
to
just
start,
creating
an
aggressive
left
and
right
and
nothing
happens
unless
you're
on
gke
GK
users.
A
That's
not
why
we're
here
and
there's
some
problems
with
that
and
the
problem
isn't
just
that
you
created
an
inject.
The
problem
is
in
kubernetes
is
broken,
so
what
is
ingress
really
if
we're
talking
about
creating
an
ingress
resource?
It's
a
little
bit
different
than
just
creating
a
service
resource,
and
things
are
done.
Your
ingress
resource
really
are
just
the
rules
for
routing
your
inbound
traffic
towards
your
cluster
resources,
and
this
is
really
important.
It
says
nothing
about
how
those
rules
should
be
applied.
A
This
is
a
very
declarative
API,
it's
not
imperative
in
any
way,
and
so
I've
just
set
up
the
rules
and
most
of
kubernetes
works
that
way,
so
it
should
be
pretty
familiar
so
before
we
get
to
the
solution.
Why
wouldn't
I
just
use
a
service?
I
mean
we
talked
about
how
easy
it
is
and
and
just
be
done
with
it,
and
you
can
use
a
service.
That's
fine,
but
a
lot
of
use
cases
end
up
where
you
bump
up
against
the
the
Tattered
edges
of
what
a
service
to
do
pretty
quickly.
A
That's
because
services
are
pretty
limited,
they're
tied
to
the
entire
controller
managers,
life
cycle
and
their
routing
rules
are
attached
to
that
life
cycle
of
the
service.
I
delete
the
service,
that's
gone.
If
I'm
deploying
a
helmet
art
who's
using
Helmand
here,
a
lot
of
you,
okay,
check
out
helm
when
you're
done
and
you'll
see
some
helm
later
on,
but
if
I'm,
if
I'm
packaging
up
my
entire
applications,
helm
service
and
I
have
and
I
have
a
service
resource
in
there
and
I
go
to
delete
or
migrate.
My
networking
is
inherently
tied
to
that
chart.
A
I
changed
things
around
and
I've
now
lost
my
elastic
IP
I've
now
lost
my
load.
Balancer
and
I
have
to
make
DNS
changes.
I
have
all
sorts
of
problems.
Angrist
rules
stand
to
decouple.
That's
that
those
networking
problems
from
your
application
and,
most
importantly,
this
we
have
what's
called
an
ingress
controller
and
the
ingress
controller
is
a
control
loop
that
manages
these
rules
and
applies
them
in
certain
ways,
depending
on
what
you're
doing
so.
You
have
to
have
this
thing
running
in
your
cluster.
A
Well,
the
services
do
that
sure,
but
ingress
does
have
some
really
big
advantages
over
them
and
I
think
I've
alluded
to
a
couple
of
them,
but
with
services
you
get
a
can
service
type
of
load,
balancer,
node,
IP,
cluster
IP
and
whatever
else
the
kubernetes
others
add
in
future
versions.
This
is
really
primitive,
round-robin
based
load,
balancing
a
lot
of
people
are
probably
ok
with
that,
but
there's
other
use
cases
for
for
doing
things
like
a
be
deploys
and
bleeding
traffic,
and
you
may
want
to
do
that.
A
The
network
level
you
may
not
always
want
to
do
that
via
rolling
deploy,
especially
if
you're
beginning
to
test
out
different
types
of
applications.
Different
features,
your
flippin
feature
flags
you,
you
may
not
want
to
just
rely
on
the
deployment
mechanism
to
do
that
for
you,
so
we
have
our
ingress
controller
and
instead
this
runs
separately
from
your
kubernetes
master
and.
A
All
these
advantages
are
here
and,
and
you
can
deploy
them
all
separately,
but
the
big
thing
here
is
that
I
may
have
gotten
myself
out
of
order
here.
It's
bring
your
own
controller,
you
if
you
stand
up
an
ingress
resource
and
nothing
happens.
It's
because
you
didn't
have
an
ingress
controller
and
typically
kubernetes
installers,
don't
ship
with
them.
Google
container
engine
does
there's
a
couple
third-party
services
that
do,
but
typically
you
just
won't
have
that
out
of
the
box.
A
So
there's
no,
some
there's
more
upfront
work,
but
you
are
able
to
write
your
own
and
define
your
own
rules
with
that,
and
so,
when
we
create
an
ingress
resource
for
the
first
couple
times
and
nothing
happens,
it's
been.
We
didn't
have
an
ingress
controller
to
apply
our
rules
to
the
networking
fabric
above
our
cluster.
So
it's
important
to
note
that
this
rule
runs
separately
from
your
kubernetes
master,
meaning
you
can
have
one
or
thousand
different
ers
controllers,
depending
on
what
you're
doing
so,
let's
deploy
something
we're
going
to
deploy
an
application
called
croc
hunter.
A
This
is
shamelessly
been
redistributed
from
another
colleague
of
mine,
Lachlan
Evensen,
and
you
can
talk
to
him
about
kubernetes
and
the
Crocs,
your
house
hunting
and
it's
built
as
a
helmet
art.
If
you
haven't
checked
out
how
please
please
do
check
it
out,
I
use
it
heavily
in
the
rest
of
this
talk,
we're
going
to
play
now
and
hope
the
live
demo
gods
are
happy
with
me.
A
Is
this
all
visible
in
the
back
great
okay,
so
I'm
going
to
do
a
helm,
install
our
charts
or
croc
hunter
and
one
thing
I'm
going
to
do
real,
quick
before
we
do?
That
is
I'm
going
to
disable
our
ingress
now,
just
to
throw
some
charts
at
you.
These
are
going
to
be
a
little
bit
more
dense
than
a
normal
chart
just
because
it
is
templated
with
helm.
A
But
the
important
thing
is
here
note
that
we
have
a
standard
deployment
that
you'd
expect
and
we
have
a
service
oops
and
we
have
a
service,
no
we're
in
this
service.
Do
we
say:
ok,
it's
it's
a
type
of
anything,
and
nowhere
do
we
expose
this
to
the
Internet
on
the
note
or
anything,
we're
just
going
to
create
a
service
that
bundles
up
all
of
the
replicas
of
this
deployment
and
represents
them
as
the
singles
that
single
semantic
grouping
I
was
talking
about
so
we're
gonna.
A
A
Cube
cuddle
get
pods,
watch
and
type
it
right.
We'll
see.
We
have
our
it's
important
to
know
that
helm
gave
us
a
random
name
or
a
slot
random
slug
for
application
and
gave
us
three
pots
under
that.
So
we
have
a
nice
running
application.
If
we're
inside
of
our
cluster,
we
could
go
to
a
steer,
qual,
dot
default
cluster
dock
service,
don't
local
or
service
cholesterol,
local
and
we'll
get
it.
But
how
do
we
get
to
that
from
the
outside?
A
We
don't
have
an
external
IP,
so
we
can't
do
that.
We
could
expose
it
via
type
load
balancer.
Of
course
it
would
create.
This
is
a
Google
container
engine
cluster,
so
it
would
create
a
load
balancer
for
us,
but
let's
try
it
with
this
ingress
way.
So
here's
our
ingress
resource
for
this
again
fairly
template
it
out.
A
A
So
I'm
not
running
the
default
GK
a
load
balancer
inside
of
this
I'm,
actually
using
the
ingress,
we're
going
to
be
creating
here
in
the
next
few
minutes
and
it's
an
engine
X
based
load
balancer.
That
gives
me
sub
it
different
sub
domain
routing
rules.
So
let's
go
here
to
croc
hunter
Kate's
Georg
I
can
select.
A
A
A
A
So
the
first
thing
we
do
as
I
say
it
reads
well
enough
and
then
throw
a
bunch
of
engine
X
on
the
screen
is
to
find
a
quick
nginx
template
that
basically
takes
everything
up
and
wraps
it
out
the
the
results
we
want
from
there.
All
we
need
to
do
is
use
a
standard,
kubernetes
client
to
get
our
handle
on
our
ingress
resources
and
make
a
client
and
just
start
parsing
them
for
whatever
namespaces.
We
want
notice
right
above
me
on
the
right.
We
we
use
API
namespace.
A
All
you
can
actually
use
this
to
filter
down
by
different
namespaces.
If
you
only
wanted
to
do
this
for
a
single
namespace
or
you
wanted
to
do
other
interesting
patterns,
all
right
cool,
we
we
have
kubernetes
api,
we
got
a
template,
let's
go
and
start
our
engine
next
process,
so
in
this
in
this
contrived
world,
we're
going
to
have
a
docker
file
that
contains
both
this
binary
and
nginx
process
that
we're
then
going
to
deploy
somewhere.
A
Next,
we're
going
to
go
ahead
and
search
for
all
of
our
ingress
resources.
The
rate
limiter
is
there,
so
we
don't
crush
our
kubernetes
api
server
and
it's
a
pretty
standard
pattern.
I
think
it's
part
of
the
standard
library
actually
in
kubernetes,
and
then
we
list
out
all
of
our
in
Grace's,
no
matter
the
namespace.
We
just
grab
all
of
our
ingress
--is
and
we
check
it
against
some
known
list
that
we
have
and
we
create
an
engine
X
configuration
to
match.
This
is
about
as
simple
as
it
gets.
A
There's
much
more
complicated
ingress
schemes
and
ingress
controllers
traffic's.
One
of
them
there's
a
whole
bunch
of
options,
but
you
know
just
keeping
this
very,
very
simple
and
then
we're
going
to
reload
our
config.
This
is
the
the
gist
of
the
entire
basic
alpha
demo.
Engine
X
controller.
That's
provided
in
the
kubernetes
contribute,
oh,
so
it's
about
80
lines
of
code
and
you
have
the
very
basics
of
a
working
and
rest
controller.
Now
you
can
spin
up
to
do
as
much
as
you
want.
A
The
the
one
that
traffic
provides
or
traffic
provides
is
incredibly
robust,
there's
also
very
robust
ones
for
engine
X
and
because
this
is
all
driven
by
your
own
code.
There's
no
reason
you
couldn't
control
a
physical
load
balancer
as
well,
and-
and
that's
really
the
beauty
of
ingress-
is
that
you
define
kind
of
the
rules
of
what
your
ingress
controller
looks
like.
A
So,
if
we
look
at
just
what
hat,
what
just
happened,
we
get
an
interest
resource
resource,
that's
picked
up,
we
get
a
virtual
host
definition
and
I
can
access
my
my
croc
hunter
service,
all
right,
so
you
might
say:
okay,
my
my
infrastructure
is
a
snowflake.
We
do
things
like
per
branch.
Deploys
that
give
our
QA
team
the
chance
to
review
this
in
advance,
and
we
have
all
sorts
of
interesting,
serious
things
that
you
know.
A
If
you
go
read
Phoenix
project
like
we're
way,
past
they're
great,
go
ahead
and
brace
that
sort
of
like
you,
you
are
able
to
do
that.
You
know.
Building
an
ingress
controller
is
really
easy,
and
everyone
in
this
room
could
do
it.
You
don't
even
necessarily
need
to
write
it
and
go
could
be
in
any
language.
It
can
be
whatever
you
want,
but
you
are
able
to
craft
it
to
your
own
needs
all
right.
So
here's
the
challenge
and
because
I
didn't
want
to
test
the
live
demo
go
that's
too
much.
A
We
have
our
ingress
controller
up
and
running
already,
but
we
want
to
deploy
croc
under
in
a
slightly
different
way.
We
want
to
do
it
Bay
so
on
our
CI
pipeline
set
up,
we
and
really
get
it
into
a
setup
where
our
developers
can
make
as
much
progress
as
far
as
possible
without
being
deterred
and
then
get
those
results
to
our
QA
engineers
again
without
being
deterred
and
being
blocked.
A
So
we'll
start
off
masters
or
route
domain,
and
it's
open
we'll
ignore
the
author
rules
for
the
moment,
but
staging
is
on
a
staging
subdomain
and
it's
based
on
our
staging
branch.
Every
pull
request.
We
do
or
really
for
this
demo
every
feature
branch
we
push
up
will
get
a
feature
branch
deployment
with
its
own
domain,
all
this
controlled
by
CI
and
the
developers
don't
hate
themselves
at
the
end.
A
So
we
need
our
ingress
controller
and
an
ingress.
Now
for
this
I'm
using
build
kite,
we
have
a
couple
other
options
that
we
can
show
you.
We
have
some
good
demos
of
Jenkins
and
really
it's
can
fit
into
whatever
CI
system
you're
using,
but
I've
just
chosen
build
kite
for
the
purposes
of
this,
so
we're
going
to
take
and
add
some
stuff
into
our
croc
hunter
app.
A
A
All
right,
our
new
remote
branch
has
been
stood
up
and
our
bill
is
right
now
running
and
we'll
go
through
the
mechanics
of
this
afterwards,
but
this
is
basically
going
in
and
building
out
our
new
container
and
pushing
it
up
somewhere
that
we
can
end
up
using
it.
So
we
have
our
pipeline.
It's
now
going
to
build
now,
while
that's
happening.
Well,
that's
building!
A
That
is
a
scheduled
up
job
that
would
leave
your
ingress
after
24
hours
or
whatever
amount
of
time
you
set.
The
nice
thing
is:
is
those
options
are
up
to
you
and
you
can
keep
these
simple
through
a
combination
of
of
these
resources,
so
that's
been
pushed
and
now
it's
deployed.
So
now,
if
I
go
to
add
Keuka
new
croc
hunter,
ok,
Dodger
comm.
A
We
have
our
new
deployment
with
that
update.
So
the
nice
thing
is
here:
we
were
able
to
do
that
without
building
any
custom
systems
without
doing
any
hard
work.
We
just
use
the
built-in
resources
that
were
available
to
us
and
that
made
things
really
easy
compared
to
trying
to
try
to
build
out
these
massive
deployment
pipelines
that
really
end
up
being
these.
These
brillo
a
systems
now
we're
working
just
with
in
queue,
Bernays
resources
and
keeping
things
much
much
more
simple.
So.
A
So
when
you
deploy
an
application,
bundle
deploy,
as
you
know,
your
deployment,
your
service,
your
config
map,
all
of
it
and
think
of
that
as
one
unit
and
ingress
can
sit
separately
of
that
ingress
doesn't
have
to
be
part
of
that
unit.
Ingress
really
is
about
how
you
expose
and
route
information
to
that
so
and
really
what
I
want
to
impress
upon
you
is
match
your
routing
to
your
needs.
A
So
thank
you
very
much.
My
demo
run
ran
a
little
shorten
than
intended,
but
or
expected,
but
you
know
please
come
to
me
I'll,
be
at
our
booth.
Talk
to
me
about
Deus
kubernetes,
all
those
sorts
of
things
and
again
this
is
ingress,
your
router,
your
rules
and
I'm
Jared
Dillon.
So
thank
you
and
I
think
we
have
time
for
questions.
If
anyone
wants
them
or
just
come
up
or
whatever.
A
A
So
let
me
repeat
the
question:
if
you
want
l7
load
balancing
between
your
pods,
what
what
I
recommend
is
that
correct?
So
it
depends
if
you're,
using
Google
container
engine
I
would
just
recommend
the
built
and
you're
talking
about
single
service,
multiple
pots,
even
multiple
services,
on
the
same
route.
A
Yeah.
Are
you
talking
about
like
or
you're
talking
about
different?
Do
you
want
load
balance
between
services
or
pods
between
services
on
the
same
Leland,
you
would
probably
have
to
set
up
a
nginx
config
to
cover
that
and
then
you
you
could
do
with
nginx.
You
just
make
sure
you
make
sure
you
have
some
sort
of
metadata
in
there,
so
they
all
get
picked
up
into
the
same
server
back
or
the
same
back
ends,
and
then
that
should
cover
it.
A
A
That's
a
good
question:
how
is
the
days
router
different,
so
the
dance
router
currently
is
not
an
ingress
controller.
It
just
sits
separately,
I
believe
it's
on
a
road
map
to
enable
it
so
that
you
could
use
it
as
an
ingress
controller.
If
you
want
to,
but
we
have,
we
there's
a
lot
of
plans
around
that
so
right
now
it
just
sits
as
a
PHA
with
a
service
in
front
of
it
and
then
it
routes
from
there
yeah
it
works
entirely
on
metadata.
A
A
A
A
question
was:
what's
my
approach
to
a
che:
English
controllers
eye
right
now
prefer
to
run
a
single
replica
of
a
single
ingress
controller.
If
one
pattern
I've
been
I've
had
some
success
with
is
doing
namespace
filtering
on
those,
so
I
will
set
up
one
per
namespace
that
I
care
about
and
then
manage
that
deployment
separately.
So
I
might
have
five
ingress
controllers
for
my
tip
five
different
environments.
A
A
Sure
that's
a
great
question:
how
does
how
does
ingress
handle
non
HTTP
traffic
such
as
sni
based
traffic
or
telnet
or
UDP,
or
any
other
protocol?
That's
that's
not
that
standard.
What
we're
thinking
about
so
that's
dependent
on
what
you're,
using
for
a
controller,
so
nginx
supports
UDP,
load,
balancing
as
well,
and
you
could
write
something
for
it,
but
the
resource
doesn't
change
too
much.