►
From YouTube: Kubernetes Ingress Controller v2.2 and v2.3
Description
Michał is discuss the latest update to the Kong Ingress Controller (Version 2.2), which includes our initial implementation of the Kubernetes Gateway API.
A
All
right,
well,
hello.
Everyone
thanks
for
all
of
you
who
are
joining
us
today.
My
name
is
dalia
esposito.
I'm
part
of
the
developer
marketing
here
team
here
at
kong
and
I'd
like
to
welcome
you
all
to
our
february
con
getaway
online
user
call.
Today
we
have
a
very
special
presentation
for
you
from
mihal
flendrick,
who
is
a
staff
engineer
here
at
kong.
A
Mihawk
is
going
to
talk
to
us
about
the
latest,
update
to
the
kong
ingress
controller
version
2.2,
which
includes
our
initial
implementation
of
the
kubernetes
gateway
api
and
the
end
of
the
presentation.
We
will
open
it
up
for
q
and
discussion.
You
will
also
be
able
to
admit
yourself
turn
your
video
on
ask
questions,
but
also,
please
feel
free
to
drop
your
questions
in
the
chat
at
the
bottom
of
the
screen
and
yeah.
We
will
answer.
B
B
I'll
talk
a
little
bit
more
about
the
highlight
of
the
release,
which
is
our
technical
preview
of
the
gateway
api
implementation.
The
2.3
version,
like
this
presentation,
encompasses
both
the
point
two
and
two
point
three,
because
2.3
was
released
only
a
few
days
back
and
yeah.
We
thought
it
would
make
sense
to
include
the
recent
developments
in
this
presentation
as
well.
So
for
a
bit
of
an
introduction,
my
name
is
michael
flanders.
I'm
a
software
engineer
at
kong
on
the
kubernetes
team.
B
Today
my
teammate
shane
at
who's.
Also,
a
software
engineer
on
the
kubernetes
team
is
with
me
who
will
help
me
answering
your
questions
regarding
anything
kubernetes
or
gateway
api
yeah,
so
for
two
words
of
personal
info.
When
I'm
not
at
my
keyboard
reading
through
the
back
tracker
or
email
or
codes
or
typing
codes,
I
go
cycling
on
my
on
my
road
bike
or
or
hiking
on
the
picture.
B
You
can
see
myself
and
my
four-legged
barking
companion
with
pointed
ears
which
detect
every
slightest
noise
in
the
corridor
and
driving
my
neighbors
crazy
with
this
parking.
So
if
you're
here
44
during
this
presentation
in
the
background,
you'll
know
what
I'm
talking
about
so
yeah
for
a
bit
of
an
overview
of
this
presentation,
like
I
said
we're
going
to
get
you
familiar
with
2.2
and
2.3
releases
of
the
congress
controller.
B
Like
I
said,
the
highlight
of
these
two
releases
is
the
technical
preview
of
gateway
api
support
in
this
presentation.
I'll
give
you
a
very
brief
demo
of
what
gateway
api
means
in
kong
and
we'll
go
into
a
little
bit
of
detail
as
to
why
gateway
api
is
such
a
breakthrough
for
congress
controller
and
what
possibilities
it
opens
now
in
the
future.
B
Okay.
So
first,
like
I
said,
the
highlight
of
the
2.2
and
2.3
releases
of
ingress
controller
is
the
technical
preview
level
support
for
gateway.
Api
users
of
kubernetes
know
that
ingress
the
ingress
api
has
been
the
gold
standard
for
defining
how
traffic
from
the
outside
of
the
cluster
will
be
able
to
reach
applications
running
in
a
kubernetes
cluster.
The
ingress
api
is
with
kubernetes
since
since
virtually
the
beginning
and
that
ingress
api
has
some
problems.
B
B
B
B
I
have
done
that
in
the
demo
environment,
which
I'm
going
to
show
you
in
a
second.
If
you
want
to
do
this
yourself,
when
you're
running
the
congress
controller,
you
can
just
follow
the
using
gateway
api
guides
on
conducts,
which
the
link
to
be
sure
alongside
the
slides,
so
the
golden
rule
of
life
demos,
is
that
something
always
breaks.
Let's
hope
it's
not
the
case
for
us
today.
B
B
What
we're
going
to
do
is
go
to
the
examples
directory
of
the
congress
controller
repository
and
here,
if
we
look
into
gateway,
http
router.cml,
we
can
see
that,
in
order
for
us
to
be
able
to
use
gateway
api,
we
need
to
install
gateway
psc
or
these.
So
these
are
definitions
for
types
which
are
necessary
for
gateway
api
to
function,
which
I'll
give
an
overview
of
in
in
a
minute.
B
So
what's
happening
right
now
is
that
the
gateway
api
see
how
these
are
being
installed,
downloaded
from
the
github
repository
of
the
kubernetes
sig.
Okay,
you
can
see
they
have
been
applied
to
the
cluster.
So
now,
next
step
perform
is
go
to
the
example
manifests
that
you
can
use
to
install
the
coindress
controller.
B
The
way
it's
done
here
is
that
the
cone
container
exposes
a
high
port
5353.
So
it's
not
to
need
the.
I
had
the
red
privilege
for
the
root
privileges
for
that
and
an
appropriate
port
mapping
happens,
which
makes
it
like,
together
with
the
service,
configure
this
way.
It
makes
the
whole
thing
work
on
port
53
from
the
outside
of
the
kubernetes
service,
without
the
need
to
open
open
the
low
part
on
the
container.
So
this
is
an
implementation
detail.
B
We
have
changed
the
type
of
the
default
service
from
load
balancer
to
cluster
ip,
because
the
the
kubernetes
cluster
that
I'm
using
doesn't
use
any
load
balancer,
so
we're
just
deploying
the
ingress
controller
in
a
standalone
fashion
there.
So
we
don't
need
to
balance
it,
and
the
third
change
we
have
is
the
aforementioned
feature
gate.
Basically,
we
are
enabling
the
technical
preview
of
the
gateway
api
support
volumes
of
this
computer.
B
B
B
B
B
B
This
means
that
kong
has
properly
processed
the
request,
but
does
not
have
a
matching
route
yet
so
next
step
of
the
demo.
Now
that
we
have
kong
app
and
running
and
ready
to
handle
gateway
api,
we're
going
to
go
to
one
of
the
examples
which
are
bundled
with
the
congress
controller
and
see
how
to
deploy
an
http
route
gateway.
B
B
B
So
something
that
I
will
quickly
pitch
later
in
the
presentation
is
that
one
of
the
notable
games
from
gateway
api
is
that
before
gateway
api,
it
was
the
sole
responsibility
of
the
api
gateway
to
manage
is
of
the
operator
of
of
an
apa
gateway
to
manage
its
lifecycle
gateway.
Api
gives
us
an
opportunity
for
using
the
operator
pattern
to
to
configure
gateway
to
configure
gateways.
B
A
future
version
of
the
coin,
ingress
controller
will
make
it
possible
to
manage
gateways
by
means
of
creating
such
manifest,
so
something
that
we
have
on
the
roadmap
for
the
future
is
that
if
you
create
a
new
gateway
resource
like
this,
with
a
specific
name
and
with
specific
listeners
and
possibly
other
config
than
such
a
gateway
well,
technically
speaking,
an
instance
of
the
of
the
proxy
will
be
provisioned
for
you
with
this
desired
config.
So
this,
like
I
said
this,
is
something
that
is
on
our
roadmap
as
the
manage
node.
B
What
we
support
today
is
the
unmanaged
mod
which
I
will
get
into
a
little
bit
more
detail
about
later
yeah,
so
gateways
are
associated
with
routes
for
this
kind.
So
what
like
I
said
earlier
when
introducing
gateway
api,
it
decouples
the
language
for
describing
routes
and
gateways
from
the
specific
protocol.
Ingress
is
very
specific
about
being
http
first,
the
way
it
works
with
gateway
api
is
that
if
you
have
a
proxy
that
supports
more
protocols
like
http,
tls
tunnels,
dc
tcp
connections,
udp
connections-
jrpc,
you
name
it.
B
These
are
represented
by
different
strongly
typed
resource
kinds
such
as
http.
In
this
case,
so
the
first
part
of
this
demo
is
that
I'm
going
to
show
you
how
I
deploy
an
http
route.
Let
me
kubernetes
cluster
and
kubernetes.
Sorry,
kong
will
pick
it
up
and
configure
an
http
proxy
rule
on
com
by
means
of
this.
B
In
the
second
part
of
this
presentation,
I'll
do
something
very
similar
with
a
udp
route.
So,
as
you
can
see
here,
the
http
route
is
associated
with
gateway,
the
name
kong,
so
meaning
that
this
specific
route
will
be
represented
on
this
gateway
called
com,
and
this
is
a
many-to-many
relationship,
meaning
that
a
gateway
can
support
and
can
handle
multiple
http
routes
and
routes
can
be
associated
with
multiple
gateways
and
one
route
being
supported
by
more
than
one
gateway.
B
The
design
of
the
api
gateway
api
is
such
that
it's
possible
to
express
to
natively
express
matches
based
on
query,
string
parameters,
headers
and
other
things
and
like
if
you
want
to
like,
if,
if
the
congress
controller
decides
to
implement
a
new
matching
type,
there's
there's
a
possibility
for
using
the
extension
point
here
to
implement
more
and
the
same
thing
with
with
backends
like
right.
Now.
What
supported
this
plain,
kubernetes
services,
but
as
service
meshes
or
any
other
type
of
beckons,.
B
B
B
Spirit
we're
seeing
here
so
we
can
do
something
similar
with
the
dpp
route.
So
the
example
for
udp,
as
opposed
to
the
example
http
uses
a
different
service.
In
this
case,
we're
going
to
deploy
coordinates
coordinates
is
a
very
simple
code
native
dns
server.
This
instance
I
have
here
in
this
example.
That's
where
something
very
simple:
it
relays
the
requests
to
arbitrary
internet
domain
names
into
the
default.
Resolver
that's
configured
on
the
pod
and
in
cluster
traffic
gets
forwarded
to
the
kubernetes
service
discovery
mechanism.
B
So
we
deploy
such
a
core
dns
instance
and
what's
going
to
happen
next,
we
have
a
similar
gateway,
custom
gateway,
definition
here
and
so
like
like.
I
said
this
is
redundant
compared
to
the
previous
example,
but
since
both
examples
are
standalone
and
using
them
for
baking
as
they
exist
in
the
kubernetes
ingress
controller
repository,
like
I
said,
these
entries
are
going
to
overwrite
the
entries
which
I
created
as
part
of
the
previous
attempt
with
http
route,
so,
but
that
that's
just
a
just
a
note
and
yeah.
B
B
B
So,
for
those
who
don't
know
dig,
this
is
a
tool
that
you
can
use
to
make
raw
dns
queries
similar
to
nslookup
but
low
level.
So
what
this
means
is
we
are
making
a
dns
query
over
udp
about
the
domain
name
google.com
to
the
ip
address
of
the
kubernetes
service,
which
is
running
the
complex.
If
we
do
this
now
we'll
see
that
the
packet
has
been
sent
and
received
by
nothing
right
as
intended,
because
comp
has
not
been
configured
to
proxy
the
dns
traffic.
B
Yeah,
so
this
is
a
real,
really
quick
reiteration
of
what
I
said.
The
ingress
api
is
a
tightly
coupled
api
from
the
early
days
of
kubernetes,
with
limited
options
for
extensions
and
gateway.
Api,
like
one
of
the
goals
of
k2
api,
is
to
solve
the
tight
coupling
problem.
Yeah
so,
like
I
said,
ingress's
http,
specific
and
gateway
api
allows
for
flexibility
to
describe
any
protocol.
You
want
by
means
of
existing
and
new
possible
types
of
objects.
B
So
today
the
spec
allows
for
tcp
udp,
tls
and
http
out
of
the
box.
When
I'm
saying
tls,
I
mean
raw
tls
streams
and
http
also
includes
https.
There
is
an
ongoing
enhancements
proposal.
Implementing
support
for
grpc
in
the
core
protocol
as
well.
So
we
can
expect
that
grpc
will
be
supported,
will
be
a
part
of
the
core
of
the
core
standard
for
gateway
api
as
well,
but,
like
I
said,
gateway
api
makes
it
possible
to
support
any
other
protocol
by
means
of
just
creating
a
proprietary
resource
yeah.
B
Can
be
used
as
backends
and
such
an
expression
will
be
read
in
the
future
by
the
congress
controller
and
there
will
be
a
possibility
to
proxy
the
traffic
directly
to
the
object
which
is
being
referenced.
Yeah,
like
I
said,
ingress
rules
only
match
paths
in
order
to
do
matching
on
headers
and
things
like
that.
You
need
some
extensions
which
are
more
or
less
convenient
to
use
with
gateway
api,
it's
possible
to
express
them
in
a
native
way,
and
there
is
also
a
big
boost
for
fine
tuning
load.
B
Balancing,
so
ingress
basically
allows
you
to
configure
a
single
service
for
for
a
backend
of
a
rule
and
nothing
more
gateway.
Api
allows
you
to
perform
things
like
progressive
delivery
by
means
of
canarying,
something
like
that
virtually
out
of
the
box
yeah.
So
this
is
a
quick
return
into
the
concept
of
unmanaged
managed
gateways,
which
I
briefly
mentioned
earlier.
B
This
is
a
parts
of
the
api
which
is
a
big
step
forward
and
we
getting
behind
the
increase
controller
are
actively
working
on
the
mechanism
that
will
manage
the
life
cycle
of
the
gateway
and
allow
us
to
configure
configure
the
the
the
details
of
the
configuration
details
of
our
con
gateway
instance
such
as
the
listeners
being
available
on.
So
when
we
reach
that,
when
we
reach
managed
gateways,
it
will
mean
that
we'll
have
implemented
the
operator
pattern
for
con
gateways
running
on
kubernetes.
B
This
is
an
item
that
we
have
on
our
roadmap
for
future
versions
of
kubernetes.
What
we
have
today
is
unmanaged
gateways,
meaning
that
the
gateway,
class
and
gateway
objects
that
you
create
in
a
cluster
with
using
gateway
api
with
the
ingress
controller
today
requires
an
existing
instance
of
gateway
running
in
the
plastic.
This
is
what
the
what
our
installation
methods
for
ingress
controller
have
been
doing,
since
ever
we
are
going
to
move
away
from
that,
and
the
lifecycle
of
gateways
is
going
to
be
managed
by
the
ingress
controller
itself.
B
Yeah,
so
this
is
a
real,
quick
excerpt
from
the
changelog
for
from
versions
2.2
and
2.3.
Like
I
said,
the
highlight
of
those
two
versions
is
the
technical
preview
gateway,
api
and
2.2,
which
released
in
february.
We
introduced
the
technical
preview
so
as
the
first
version
with
which
it's
possible
to
use
gateway.
B
B
Yeah,
and
two
four
will
also
include
weighted
load
balancing,
which
is
which
I
said,
is
a
cornerstone
for
progressive
delivery
using
gateway
api
yeah,
so
2.2
also
included
configurable
kubernetes
api
rate,
limiting,
which
is
an
important
feature
for
I
have
users
of
kik
who
have
lots
of
resources
in
the
cluster
lots
of
services
spots,
everything
all
the
resources,
because
dangerous
controllers
can
easily
generate
pressure
on
the
kubernetes
api,
and
we
have
identified
that
heavy
duty
usage
requires
a
fine
tuning
of
those
parameters.
So
this
is
possible.
As
of
2.2.
B
B
B
A
D
So
I
think
I
joined
a
numeral
stock
here.
Hey
thank
you
for
the
presentation
in
the
middle,
so
trying
to
understand
the
api
gateway
is
probably
would
be
replaced.
Gateway
service
will
be
replaying,
replacing
english
controllers
or
english
kind.
Is
that
what
I'm
hearing
sorry
I
mean
I
just
try
and
find
it.
D
C
D
D
C
Allow
you
to
tell
it
the
set,
basically
configure
the
mtls
certificates
for
talking
to
the
kong
admin
api,
which
we
treat
is
basically
our
data
plan
so
before
this
was
all
done.
Kind
of
on
localhost
over
a
local
socket.
But
now
it's
possible
to
like
have
the
gateway
outside
of
the
container
and
also
easily
set
up
mtls,
so
that
that
communication
is
encrypted
and
authenticated.
C
Yeah,
and
by
default
it's
not
exposed
it
like.
I
said
it's
only
over
localhost,
but
we
are
moving
towards
the
future.
There's
an
issue
kick
number
721.
I
think
it
is.
We
are
moving
towards
the
future.
Will
you
where
you
should
be
able
to
have
like
multiple
gateways
controlled
by
a
single
controller?
C
D
A
C
Yep
and
again
from
the
engineering
side,
we
have
github
discussions.
We
have
kong
on
kubernetes
slack,
just
a
few
places
where
you
can
get
in
touch
with
us
kind
of
informally,
like
you,
don't
have
to
create
an
issue
if
you're
just
feeling
like
you
just
want
to
ask
a
simple
question,
and
that
stuff
is
really
helpful
for
us
engineers
to
understand
like
what
kind
of
problems
people
are
running
into
and
stuff,
so
don't
be
a
don't,
be
afraid
to
drop
something
in
there.
A
Yeah,
let's
see
and
yeah
well
that
was
one
last
question.
No,
I
also
wanted
to
let
you
all
know
that
we
launched
our
external
contributor
programs.
You
should
do
anything
cool
with
our
products.
Please
feel
free
to.
Let
us
know
here
and
you
can
win
pretty
cool
swag
depending
on
what
you
do
so
please
check
it
out.
We
would
love
to
contribute
and
win
some
awesome
prizes.
Our
next
user
call
will
be
on
may
10th.
We
hope
to
see
you
all
there
and
thank
you
for
your
time
today.
Thank
you,
shane.