►
From YouTube: Webinar: Kubernetes Ingress: Simplify Cluster Management Across Any Platform or Environment
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
I
I
If you want to follow along with the demo, all commands can be found here: https://gist.github.com/hbagdi/0e127a748e598bf9fcac28da7be621f2
Kubernetes has changed how we think about application development, but it has also introduced additional complexity into the way we manage microservices. What is a simple way to extend Kubernetes for highly-available applications at scale?
This webinar will take you on a deep dive into Kong, an open source API gateway for Kubernetes Ingress. Kong’s Ingress Controller implements authentication, load-balancing, traffic throttling, transformations, caching, metrics, and logging across Kubernetes clusters.
Harry will take the audience through a live demo installation:
Installation
Basic Ingress
Auth Protection
Traffic Transformation
Rate-limiting
A
All
right
we're
gonna
go
ahead
and
get
started
now.
Thank
you.
Everybody
who
is
joining
us
today
welcome
to
today's
the
MCF,
webinar
kubernetes
ingress,
simplified
cluster
management
across
any
platform
or
environment,
I'm,
Kaitlin,
Barnard
marketing
manager
at
calm
and
I'll
be
helping
to
moderate
today's
webinar
I'd
also
like
to
welcome
our
presenter
today,
Harry
banjee
who's,
a
senior
cloud
engineer
at
car,
so
just
to
cover
a
few
housekeeping
items
before
we
get
started
during
the
webinar
you're,
not
able
to
speak
as
an
attendee.
A
So
there
is
a
Q&A
box
at
the
bottom
of
your
screen
as
we
go
through
the
webinar,
please
feel
free
to
drop
any
questions
that
you
have
in
there
and
then
we'll
get
to
as
many
as
we
can.
At
the
end,
the
webinar
is
also
being
recorded
and
will
be
available
online
later,
along
with
the
slides.
So
with
that
I'll
hand
it
over
to
Harry
to
kick
off
today's
presentation,
Thank.
B
You
Caitlin,
hello.
Everyone
welcome
to
this
webinar
on
simplifying
ingres
using
Cuba.
It
is
using
conch,
so
we
are
going
to
focus
on
Cuban.
It
is
English
and
how
Cong
can
help
you
do
an
acomplished
ingress
across
communities
cluster,
but
also
across
other
clusters.
If
you
wish
to
so
little
about
today's
agenda,
we're
just
going
to
go
a
brief
overview
of
what
ingress
is
for
those
people
were
not
familiar
with
the
terminology
and
how
you
want
to
how
why
it
came
into
existence.
B
And
what
can
it
allow
you
to
do
we'll
go
a
little
bit
into
Cong
like
how
Cong
came
into
existence?
What
Kong
can
do
for
you
and
how
Kong
can
do
ingress
and
a
little
bit
more
than
embrace
actually,
and
then
we
will
just
dive
into
a
demo
session,
which
I
think
is
a
pretty
comprehensive
demo
which
allows
you
to
figure
out
not
only
just
ingress,
but
a
lot
of
you
know,
authentication
and
other
stuffs
that
you
can
do
at
the
ingress
layer
in
kubernetes
all
right.
B
So
a
little
bit
about
myself
as
Kate
inside
I
am
an
engineer
at
Congo.
I,
open
source
enthusiastic
maintain
a
couple
of
open
source
projects
wrong
with
conch
I,
come
from
qmu
KVM
virtualization
background
for
those
people
who
are
not
familiar
with
that.
That's
what
powers
cloud
computing
environment.
So,
if
all
the
VMS
that
you
see
running
in
any
of
your
cloud
providers
underneath
it,
you
have
the
linux
k,
vm
here,
and
so
I
have
moved
up
the
stack
and
now
a
champ
I'm
kind
of
championing
Kuban.
It
is
at
Kong
and
outside
Israel.
B
So
with
that
Cuban
it
is
ingress.
So
you
you
almost
be
familiar
with.
You
know
you
can
install
services
into
Cuba.
Nowadays
you
can
get
them
running,
beat
your
stateful
pods
or
be
it
your
stateless
services.
You
can
get
your
thoughts
running.
You
know,
persistence,
volume
claims,
but
once
you
have
everything
in
there,
how
do
you
see?
How
do
you
actually
give
people
outside
the
people
access
to
your
services?
You
know:
how
do
you
give
services
which
are
not
running
in
Cuba,
noticed
and
running
outside?
B
How
do
you
get
access
to
those
services
and
that's
where
kubernetes
comes
into
picture?
Sorry,
that's!
Where
English
content
comes
into
play.
Ingress
is
not
something
new.
Even
like
20
years
ago
we
had
this
concept
of
you
know
dmz,
like
Demilitarized,
Zone
subnets,
where
you
would
run
your
you
know
the
first
firewall
the
proxy
and
and
that's
where
all
the
traffic
that
you
get
into
your
network
comes
from
there
and
that
gets
propagated
into
the
entire
cluster,
and
you
know
that's
get
forwarded
to
whatever
services
you
are
running,
so
why?
Why
should
you
do
that?
B
I,
don't
think!
That's
needs
a
lot
of
convincing,
but
we
still
go
around
see.
Like
you
know,
one
port
of
entry
is
something
that
you
know
all
your
Ops
guys
will
love.
You
know
if
you
want
to
firewall
some
traffic
or
you
know
if
you
are
being
ddosed
or
if
you
are
being
any
kind
of
security
measures
that
you
would
like
to
take.
You
would
like
to
take
that
at
that
first
layer,
any
kind
of
audits
you'd
like
to
do
you
would
like
to
do
it
that
one
single
point.
B
Well,
you
could
ask
well
Harry,
you
can
go
and
create
a
service
of
pipe
load,
balancer
and
that's
it
like.
If
you
are
running
in
a
cloud
provider,
environment
I
will
get
a
load
balancer
and
I
can
send
traffic
for
that
API
or
web
service
or
whatever
I
am
running,
and
that
solves
my
problem.
So
why
not
do
that?
And
why
do
this
entering
this
management?
B
So
the
reason
being
like
he
said,
you
know
one
point
of
entry
and
also
a
lot
of
traffic
management
and
connection
management.
You'd
want
to
terminate
TCP
as
early
as
possible
to
speed
up
a
little
bit
whatever
it
may
be,
to
reduce
the
overhead
of
three-way
handshake
same
with
TLS
termination.
You
might
want
to
encrypt
traffic
different
three
internally
inside
your
cluster,
so
that
you
know
you
have
some
more
visibility
into
traffic
when
you're
debugging
or
if
you
are
solving
the
production
issue,
and
that's
where
you
know
things
like
service
mesh
also
come
in.
B
You
also
want
to
do
load
balancing
at
that
layer.
So
if
you,
if
you
are
rude
balancing
across
the
zones
in
to
avoid
failures,
when
you
know
one
of
your
Easy's
go
down,
you
would
want
to
do
that.
It's
at
that
layer,
you
would
also
want
to
do
know
canary
deployments,
then
you
can
probably
do
it
the
ingress
of
the
DMZ
layer
itself.
You
could
also
move
it
further
into
the
stack
depending
on
how
your
operations
looks
like,
but
you
usually
people
can
do
a
lot
more
at
the
indus
layer.
B
B
Lets
you
define
routing
principles,
its
routing
policies
for
your
cluster,
so
any
traffic
that
comes
to
your
cuba
net
is
clustered
catch
goes
through
that
ingress
layer
and
then
the
traffic
any
request
matches
against
a
specific
ingress
rule
and
that
gets
sent
or
forwarded
to
your
service
that
is
running
inside
your
cluster.
It's
pretty
vendor
neutral,
so
you
know
we
are
using
any
kind
of
proxy.
It
does
not
really
matter.
You
can
swap
out
proxies
easily
and
that's
what
that's
that's
the
main
reason
liking
us
is
getting
so
popular.
Is
it's
pretty
much
vendor
neutral?
B
It
has
been
stagnant
for
a
pretty
for
a
long
time,
and
now
the
community
is
again
picked
up.
It
has
it's
now
going
through
a
transition,
and
it's
going
through
to
a
v1
API
very
soon,
now
I
think
in
Cuban
it
is
1.17.
So
let's
look
at
the
speck
here
right,
Rick,
so
it
this
is.
This
is
pretty
standard
Cuban.
It
is
manifest
and
on
the
on
the
left,
you
can
see
that
this
was.
This
is
currently
until
Cuban.
It
is
1.15.
This
was
under
the
extensions
now
to
be
one
meter.
B
One
API
group
extensions
API
group
has
been
deprecated
in
is
we
are
trying
to
remove
that
from
Cuban
interests,
so
increase
was,
is
being
put
into
ingress
into
the
networking
API
group
and
is
is
being
g8
soon
with
some
suffixes
to
get
you'll
also
want
to
expand
it
a
lot
more
since
it
it's
it's
a
very
narrow,
spec,
an
epi.
So
let's,
let's
look
at
the
ingress
spec
here,
so
pretty
standard
Cuban.
B
B
So
if
the,
if
the
request
path
starts
with
slash
bills,
will
forward
it
to
the
bills
service
that
we
are
running
right
and
this
will
service
will
be
located
in
the
same
name
namespace
as
the
ingress
rule.
So
here
we
are
not
defining
a
namespace,
so
this
will
go
into
the
default
namespace.
You
can
create
ingress
rules
in
any
namespace.
You
wish,
but
it
should
be
the
same
in
space
as
your
service.
We
want
to
keep
that
namespace
soft
isolation
inside
Cuba
notice,
and
then
we
have
the
slash
orders
path.
B
Slash
orders
gets
forwarded
to
the
orders
service
that
is
running
inside
Cuba
notice.
That
gets
402
on
to
the
HTTP
port
443.
So
this
is.
This
is
not
the
complete
spec,
but
it's
a
pretty
small
example.
It
shows
the
power
of
it.
Like
you
know,
you
can
specify
you
can
you
can
be
couple
the
service
that
you
are
running
and
how
the
traffic
actually
needs
to
get
it
and
folks
are
familiar
with
you
know:
H
a
proxy
or
nginx
or
Apache
could
probably
start
thinking
about
it.
B
Okay,
how
would
I
write
my
you
know,
server
blocks
or
location
blocks
and
how
would
I
go
about
handling
these
so
that
sound
like
the
main
focus
here,
is
being
vendor
nutri
now.
An
important
point
here
to
be
noted
is
this
ingress
resource
ships
with
cuban
artists,
but
cuba
notice.
If
you
create
this
ingress
resource,
let's
say
you're
running
mini
cube.
Nothing
would
actually
happen.
A
B
So
these
policies
are
read
by
you
know
you:
can
there
are
popular
ingress
controllers
out
there
con
being
one
of
them
they
can.
They
can
read
these
policies
and
configure
themselves
to
to
route
traffic
accordingly.
So
that's
where
it
comes
in
where
you
have
this
ingress
API
inside
kubernetes,
but
it
won't
ship
with
an
ingress
controller
if
you're
running
gke
chaos
or
any
of
the
managed
offering
they
do
come,
you
know
some
some
basic
in
various
controllers.
So
that's
that's
another
option
that
you
have
so
this
is
where
it
comes
saying.
B
Okay,
we
have
this
in
here
it's
now.
How
do
we
go
about
and
actually
start
using
it,
because
if
you
just
create
this
ingress
resource,
nothing
is
going
to
happen.
So
that's
where
con
comes
in
the
Kong
is
one
of
the
popular
images
controllers
that
we
that
are
out
there
and
so
I'm
going
to
go
a
little
bit
into
like
how
what
Kong
is
and
why
you
should
be
using
that
for
in
this,
so
Congress
of
currently
very
popular
cloud
native
API
gateway,
although
it's
not
an
API
gateway
anymore,
it's
going
more
towards.
B
You
know
like
how
you
can
orchestrate
micro
services,
how
you
can
you
know
even
do
service
mesh
with
Kong.
It
was
initially
open
sourced
in
2015
by
a
company
called
misshape,
and
then
it's
an
Apache
to
soar
in
a
fairly
liberal
license
minute.
One
daughter
was
announced
last
year.
It's
been
running
in
production
for
about
about
for
us
about
three
years
now
and
last
year
the
one
daughter
launch
announced
feature
completeness
of
the
product.
B
The
most
important
point
here
to
note
that
I
would
like
to
emphasize
is
platform
agnostic
City.
So
this
this
presentation
is
focusing
on
Cuban.
It
is
focus
of
Kong,
but
we
do
but
anything
that
we
do
develop
in
our
crew.
Core
product
is
never
Cuban.
It
is
specific.
Most
of
our
customers
run.
You
know
in
a
hybrid
environment,
any.
B
That
we
don't,
you
know
we
are
seeing
a
lot
of
Cuban,
it
is
adoption,
but
then
you
know
you
have
their
metal
data
centers
still
around.
You
have
OpenStack
still
around.
You
know
it's
not
that
everybody's
just
moved
to
you,
know
public
cloud
or
everybody's,
just
implementing
kubernetes
solutions
in
their
shops.
People
stay
use,
other
orchestrated
orchestration
solutions
and
Kong
works
across
them,
so
Kong
can
be
deployed
in
in
all
of
these
environment
and
Kong
can
work
with
service
discovery
mechanisms
of
all
these
environment.
B
So
that's
where
we
want
to
be
very,
very
Cuban
at
is
friendly
and
Cuban.
It
is
integrations,
are
extremely
important
to
us,
but
that's
not
the
only
platform
that
we
would
like
to
focus
our
efforts
on
yeah.
So
going
into
a
little
bit
of
details
of
you
know.
What
actually
Kong
can
do
for
me
is
so
this
is
a
rough
overview
of
what
Konkan
completions
right.
So
on
the
left
side,
I
have
declined.
Now
this
client
can
be
anybody,
you
need
any
user
of
an
API
right,
so
it
can
be.
B
You
can
have
like
a
public
API
like
Twitter
or
Google,
and
your
clients
could
be
accessing
your
API
is
over
the
Internet
and
you
know
coming
through
that
route.
What
you're
trying
can
also
be.
You
know
your
internal
services
like
if
you
are
running
a
micro
services
architecture
in
insider
organization.
You
can
have
one
service
talk
to
another
and
that
traffic
can
flow.
Why
a
Kong!
Instead
on
the
right-hand
side,
we
have
got
a
few
services,
and
these
are
services
of
all
kind.
So
we
see
we
have
a
G
RPC
service.
B
We
have
no
arrests,
simple
JSON
over
HTTP,
and
you
know
other
other
kind
of
restful
services
that
you
could
be
running
JSON
over
HTTP
being
the
most
popular
one
today
and
G
RPC
slowing
eating
that
up,
and
then
we
have
the
database
traffic.
You
know
so
you
could
have
you
know
you
know
Brady's
protocols
flowing
through
you
could
have
my
sequel.
B
You
could
also
have
something
much
more
like
different
l4
protocol,
something
like
you
know,
Kafka
flowing
through
as
well,
so
you
can
flick
proxy
any
traffic
through
Kong
and
then
Kong
can
do
a
certain
magic
on
top
of
those
requests
right.
So,
as
the
request
flows
through
Kong
Kong
can
change
the
request
or
Kong
can
implement
certain
policies
that
you
wanted
to
do
it.
So
each
of
the
boxes
that
I've
drawn
here
are
sort
of
plugins
in
Kong.
Kong
is
an
extensible
architecture
and
it's
like
a
plug-in
based
architecture.
B
You
know
I
want
to
maybe
do
sticky
sessions
with
it
and
also
I
want
some
Prometheus
metrics
out
of
it
well
for
my
G
RPC
service
I
want
some
data
dot
matrix
out
of
it
right
and
then
maybe
for
the
database
traffic
that
I'm
seeing
you
know
if
I
have
high
latency
I
want
to
do
certain
kind
of
logging
for
those
slow
queries
right
and
all
that
you
can
little
customized
and
Kong
and
get
that
done.
A
very
popular
feature,
meaning
rate.
B
You
know,
like
you,
don't
want
people
to
be
hitting
your
traffic,
so
you
could
do
all
these
in
these
services
as
well.
The
reason
Kong
is
exists.
Is
we
try
to
try
things
out
so
rather
than
asking
each
and
every
application
thing
that
you
have
for
these
features,
you
can
just
run
Kong
in
front
of
them
and
the
services
are.
You
know
core
business
logic
of
that
service
is
only
inside
the
service.
You
are
not
implementing
rate,
limiting
in
know,
20
different
ways
you
know
and
be
so
that
also
gives
you
a
lot
of
homogeneous.
B
You
know
nature
of
if
you
are,
if
an
external
developer
is
reading,
something
they
naturally
know.
Ok,
this
is
how
your
API
works.
So
Kong
is
built
on
top
of
a
very
stack
is
what
I
would
like
to
say
so,
underneath
it's
in
Jeanette's
Ingenix
needs
no
introduction
to
this
audience.
I
hope
it's
been
around
for
about
a
decade
now,
Oh,
actually
more
than
a
decade.
It's
it
powers.
B
A
huge
part
of
Internet
on
top
of
in
genetics
is
a
it's
kind
of
less
popular
than
nginx,
but
it's
called
it's
called
open
touristy,
which
extends
in
Gen
X
with
Lua
and
logit,
and
so
Luanda
jitter.
Like
you
know,
flu
is
very
popular
scripting
languages
that
was
then
initially
used
only
I
think
in
its
it's
more
powerful,
powerful
in
the
gaming
community
and
you
know
embedded
systems,
but
it
with
low
budget.
You
can
get
like
you
know
a
or
C
sealer
near
like
hardware
performance.
B
It
compiles
down
to
very
fast
bytecode,
and
so
that's
another
open
source
product
that
originally
came
out
of
cloud
flavor,
so
proud
flare
stack
is
entirely
in
you
know
C
and
Lua
and
that's
being
ins
in
excel.
You
were
and
that's
where
it
was
born,
and
now
it's
it's
being
maintained
and
has
a
thriving
community
around
it
and
by
the
way
this
is
open.
Dusty
is
what
actually
powers
ingress
engine
X,
which
was
the
first
in
engineer,
which
was
the
first
English
controller
that
kubernetes
community
developed.
B
So
a
open
dusty
is
a
sort
of
subset
of
engineering.
So
if
you
have
any
engine
X
configuration,
you
can
also
provide
that
to
understand
it
will
work
out
of
the
box.
It
has
more
features,
and
you
know
inside
embedded
inside
which,
which
make
it
pretty
much
dynamic
and
then
Kong
is
built
on
top
of
open
dusty,
which,
when
we're
we
make
it,
you
know
really
API,
driven
and
crowd
native,
proud
native
being,
maybe
we
wanted
to
not
have
you
know
like
you,
don't
have
to
restart
any
processes.
B
You
know
if
configurations
change
very
often
now
as
your
Cuba
notice.
So
this
is
scale
we
won't
come
to
automatically
handle
traffic
across
those
balanced
load,
balance
across
the
ocean
and
it's
completely
API
driven.
So
you
can
script
it
to
do
a
lot
of
things.
You
know
that
are
specific
to
your
infrastructure,
but
we
also
ship
the
things
which
are
you
know
like
standardized.
You
know
something
like
rate
limiting.
B
If
anybody
wants
to
use
it,
we
ship
with
the
standard
plug
in,
but
then
you
can
change
it,
extend
it
as
in
ways
you
would
like
to
do
it.
So
how
do
we
do
ingress
with
Kong?
We
have
a
Kong
interest
controller
that
makes
Kong
super
super
nice
and
friendly
with
kubernetes.
So
this
is
a
very
fairly
simple
architecture.
As
you
can
see,
you
have
the
API
server
on
the
left.
Here
in
the
middle,
you
have
comm
pods,
which
run
two
containers.
B
One
container
is
calm,
which
is
the
runtime,
which
is
the
proxy
that
we
use
and
we
have
a
co-located
controller
which
talks
book
unit
is
API
server,
I,
don't
hand
and
saw
back
and
everything
reach.
These
reads
the
ingress
resources
that
we
created
and
configures
kong
accordingly
and
then
that
that
gets
proxy
to
your
services.
You
know
and
then
Kong
can
execute
authentication
and
whatnot
on
these
things.
B
So,
as
I
was
saying,
the
the
ingress
spec
is
fairly
narrow.
As
you
could
see,
it's
currently
HTTP
only
you
can
route
based
on
you
know,
host
header
you
can
draw
based
on
you
know.
The
paths
you
have
you
can
put
in
some
TLS
settings
as
well,
but
Kong
Kong
can
do
a
lot
more
than
that,
and
we
want
you
to
do
that.
We
want
you
to
use
Kong
for
all
those
things.
Excuse
me.
B
So
we
we
have
a
concept
of
plugins,
so
we
have
a
few
different
CR
DS
and
we
will
get
this
more
into
these
into
the
demo.
What
these
allow
you
to
do
is,
you
know,
extend
the
ingress
API
using
you,
know
annotations
and
CR
DS
to
do
more
things
and
extend
the
regular
ingress.
These
are
specific
things
as
well.
So
that's
why
the
some
of
these
can
be
incorporated
into
the
ingress
API
and
that's
something
that
we
are
trying
to
work
with
the
community.
B
A
B
Good
awesome:
ok,
let's
see
so
I'm
running
a
gke
cluster
right
now,
just
for
the
ease
of
the
demo
and
whatever
I
do
is
actually
going
to
be
accessible
on
the
Internet.
Nobody
actually
does
all
right
so
I'm
going
to
follow
Ritchie
a
script.
So
we
have
the
English
controller
that
we're
it's
a
simple
Amal
that
we
are
going
to
install
right
now,
so
Kong
University
wheelers
is
yeah
man
that
we
are
installing
oops.
B
Okay,
that's
better!
So
we
are
installing
everything
in
a
specific
name,
space
called
Kong
and
we
install
the
custom
resource
definitions
that
I
just
showed
you
in
the
slide,
and
we
have
some
car
back
related
resources
and
a
service
account
which,
which
gives
Kong
the
permission
to
talk
to
the
API
server.
B
And
then
we
have
a
deployment
and
a
config
map
to
configure
calm
all
right,
let's
see
so
we
can
do
this,
so
we
have
got
the
ingress
control
or
up
and
running
as
you
can
see,
we
have
got
two
pods
and
both
are
ready
to
run.
We
should
also
have
a
service,
so
we
have
the
proxy
service,
which
is
a
pipe
load
balancer
right.
So
you
only
have,
ideally,
you
would
only
have
one
load
balancer
service,
that
is
Kong
and
everything
would
flow
through
this
right.
B
B
So,
oh
everything,
so
that
includes
a
pod
that
includes
a
service
deployment
and
replica
set
replica
set,
belongs
to
this
deployment
rate
and
replica
set
is
what
is
powering
a
pod
here
we
are
running
only
one
pod
right
now.
Obviously
you
don't
do
this
in
production
run
multiple
instances
for
some
redundancy
to
provide
some
protection
or
against
failure
of
you
know
a
specific
node,
let's
see
if
Google
God
first
balancer
for
Kong
alright,
so
we
got
an
external
IP
here.
This
should
be
routable
on
the
Internet.
B
B
You
can
see
here
that
you
know
Congress
pointed
with
a
message
saying
no
routes
nor
out
matched
with
those
values.
This
is
because
we
have
not
created
any
ingress
rule.
Currently,
there's
no
resources.
Pancho
Kong
does
not
know
how
to
proxy
any
requests,
how
to
set
how
to
forward
it
inside
your
kubernetes
cluster.
B
So,
and
you
can
see,
we
are
running
like
the
response
is
indeed
coming
from
Kong,
so
so
that
that
gives
you
the
hint.
So
what
we
are
going
to
do
next
is
going
to
install
two
services.
These
are
very
simple,
fairly
demo
services.
What
we
have
got
here
is
HTTP
bin,
which
is
the
same
issue
to
be
been
dot
or
service.
You
know
which
echoes,
request,
content,
and
you
can
configure
it
to
do
a
few
different
it
based
on
search
requests.
B
B
I've
got
HTTP
bin
external
DNS
or
something
that
I'm
using
currently
to
to
manage
DNS
of
my
cube,
and
it
is
clustered
you
can
ignore
that
for
this
demo,
so
let's
go
ahead
and
create
an
ingress
rule
here
right.
So
what
we
just
did
here
to
kind
is
ingress.
If
you
see
the
API
version
is
extensions,
because
this
is
a
older
communities
cluster
and
we
have
got
a
couple
of
rules
here.
The
first
rule
says
there
is
no
chill
gets.
B
Okay,
so
that
gives
you
a
nice
pretty
printed
form
where
the
first
one
is,
we
haven't
set
any
host
header.
So
that
means
any
any
request
that
comes.
That
starts
with
/foo
gets
forwarded
to
the
echo
service
that
we
created
and
anything
that
comes
to
http
Ben
dot.
You
know
for
IDO
comm
gets
forwarded
to
HTTP
bin,
alright.
B
/F
nothing
happens
because
there
is
no
request,
there's
nothing
that
gets
forwarded
and
then,
if
we
do
/foo,
you
can
see
that
you
know
you've
got
some
information
here,
so
we
look
at
some,
so
the
headers
first,
so
you
can
see.
We've
got
the
actual
server
which
responded
with
to
a
request
for
a
KO
server
and
the
request
was
proxy.
Do
I
account
so
kong
actually
matched
this
rule
against
our
ingress
rule
that
we
created
and
forwarded
it
upstream
and
then
we
have?
You
know
which
a
copepod
actually
responded.
B
Since
we
have
four
convoluted
balance
by
default,
it
will
do
a
round-robin
load
balancing,
but
you
could
configure
it
to
do.
Sticky
sessions
or
hash-based
based
on
you
know,
source
IP
or
some
only
cookie
based
as
well.
If
you
wanted,
and
then
we
have
some
request
information.
So
if
we
do
something
like
let's
say,
X
poster
we'll
see
that
the
method
is
now
post
right
and
if
we
slash
four
demos,
C
and
CF
we'll
see
the
real
path
is
/mo
CN,
CF,
okay.
So
that's
like
basic
ingress.
B
That's
working
here
right
now,
let's
see
so
I'm
going
to
see.
If
we
can
do
this
so
I'm
running
I'm
running
some
automation
here
to
populate
cloud:
fair
DNS
with
the
hi
cluster
IP
that
we
just
got
and
okay,
so
we
can
see
that
DNS
propagation
has
happened
successfully.
So
we
had
this
rule
of
HTTP
been
dot.
You
know,
42
comm
goes
to
the
HTTP
bin
service.
So
if
you
are
familiar
with
HTTP,
then
you
can
do
slash
status
200.
It
will
return
back
a
200,
ok
and
you
can
see
you
know.
B
And
it
will
send
back
the
headers
that
we
are
sending
right
so
far
and
we
will
see
that
the
request
actually
focused
goes
through
Kong,
and
these
are
all
the
request
headers
that
are
coming
through,
so
that
you
see
Kong
here,
because
these
are
all
the
request-
header
well
being
sick
on
the
responsible.
So
this
is
all
pretty
pretty
much
pretty
basic
right.
You,
you
only
have
you
got
ingress
you
created
in
this
rule?
You
can
proxy
services.
B
Now
we
are
going
to
get
into
Kong,
specifically
parts
here,
so
I'm
going
to
go
ahead
and
create
account
plug-in
resources.
So
let's
go
through
this.
So
what
we
are
saying
here
is
we're
giving
it
a
any
name,
and
then
we
have
a
config
of
the
plug-in.
So
we
are
saying
that,
for
whenever
this
plug-in
gets
executed,
add
a
require,
add
a
header
and
add
the
header
demo
or
colon
injected
by
comm
right
and
the
plug-in
that
we
are
using
right
now
is
the
response
transformer,
because
we
want
to
transform
responses.
B
We
do
not
want
to
transfer
requests.
You
can
also
use
request
transformer
and
they
know
before
sends
that
request
to
your
service.
Kong
will
inject
this
header,
while
right
now,
when
the
response
comes
back
to
your
service
to
Kong
before
sending
the
response
back
to
the
client,
Kong
will
inject
this
header.
Okay.
A
B
Let's
execute
the
request
and
see
the
so
I'm
just
outputting
the
headers,
because
we
are
not
dealing
with.
We
don't
care
about
the
body.
For
this
part,
we
don't
see
that
request.
The
request
actually
has
that
header,
the
reason
being
we
created
this
plug-in,
but
we
didn't
configure
com2
when
to
actually
join
this
plug-in
like
when
do
we
do?
We
want
to
execute
this
plug-in
on
every
request
or
for
some
request
so
for
that?
What
we'll
do
is
we'll
go
ahead
and
annotate
our
ingress
rule.
B
Right,
you
can
hand
you
can
specify
some
other
plug-in
as
well
here,
so
it
can
run
as
many
plugins
as
you
want,
and
then
we
edit
that
now
we
go
ahead
and
execute
this
request
and
we
see
that
the
demo
header
is
actually
injected
by
and
if
we
call,
let's
say,
HTTP
bin,
because
that
is
inside
the
same
ingress
rule.
You
can
see
that
it
still
is
injected
by
a
common
tree,
so
so
that
that's
how
you
this
is
the
basic
version.
B
Will,
you
know,
can
inject
header,
you
can
also
remove
a
header
or
you
can
replace
a
header
with
the
content
of
some
other
request
or
you
can
append
to
a
header
now
you
can
have
so
you
can
do
a
lot
of
those
things,
but
I
hope
this
this.
This
gets
the
message
that
you
know.
Okay,
you
can
do
transformations
on
requests
and
responses
as
well.
B
Next
I
will
go
through
an
authentication
plugin,
so
we
have
got
HTTP
bin
and
if
you
are
opening,
we
should
EP
bin
right
now
in
your
browser,
so
you'll
see
that
anybody
can
access
it.
I've
only
got
one
part
of
it
running
so
even
if
enough
of
you
are
actually
hitting
that
you'll
probably
need
ask
me
and
I
don't
want
to
found
that
to
happen
right.
So
what
we
will
do
is
we
will
enable
the
plug-in.
B
So
this
is
another
like
you
can
have
external
or
clock
in
or
you
can
have
you
know
plugins
that
can
do.
Does
the
authentication
for
you.
So
if
we
have
the
key
earth
plugin
right
so
every
time
you
make
a
request,
we
will
ask
for
any
PRI
key.
If
the
API
key
is
not
present,
then
Kong
will
reject
the
ret
request.
So
we
created
this
plug-in
and
now
we
will
annotate
the
service
HTTP
bin
with
this
plug-in.
So
you
see
the
last
time,
I
annotated
a
name
and
ingress
resource.
B
Well,
this
time
I
am
annotating
a
service,
the
reason
being,
no
matter
which
ingress
role
it.
The
request
comes
from
I
want
the
service
to
be
always
authenticated
right.
So
any
time
if
we
have
defined
HTTP
bin
dot,
you
know
42
calm,
but
if
we
also
had
HTTP
dot,
you
know
42
dot-com
both
require,
and
these
are
in
separate
ingress
rules.
Both
will
have
authentication
enabled
so
now
I
enable
that
now,
let's
send
a
request
to
http
bin,
and
you
see
no
API
cough
key
found
in
request.
B
The
response
comes
from
Kong
and
it's
a
is
401
unauthorized.
So
now
nobody
can
actually
add
the
service.
So
if
we
want
to
get
access
what
the
way
we
do
it
and
you
can
also
use
YDC
or
LDAP
or
if
you
want
you
know,
if
you
want
to
authenticate
against
an
identity
provider
that
you
are
running
Rock
all
that
is
also
possible.
B
So
what
I
am
going
to
do
here
is
I'm,
going
to
use
two
other
custom
resource
definitions
that
we
have
so
I'm,
going
to
create
a
user
named
'harry
and
I'm,
going
to
associate
credential
with
that
user.
So
I
just
created
a
consumer
Harry,
and
this
is
specific
implementation
and
then
I
associate
that
consumer
Harry
with
an
API
key
right.
So
the
type
of
the
authen
credential
is
key,
odd
and
the
key
here
being
super
secret.
So
this
is
an
API
key.
B
You
know
if
you
are
using
any
public
API
is
they
usually
have
or
three
API
key
based
authentication
variable,
so
now
I'm
going
to
go
ahead
and
make
the
request
using
this
API
key.
So
you
can
see
you
know
we
got
the
response
back
here,
so
it
responded
back.
We
get
the
headers
back
here,
so
let's
fumble
with
the
API
key,
and
we
will
see
that
invalid
authentication,
credential
so
Congress
doing
the
authentication
for
us
we
are.
We
did
not
actually
edit
HTP
pin
at
all.
We
have
not
touched
it
HTTP
pin
at
all.
B
Now
you
have
now,
let's,
let's
do
another
popular
plug-in,
which
is
called
rate
limiting
rate
rate
limiting
is
an
extremely
popular
use
case
for
Kong,
and
here
we
are
doing
something
a
little
different.
So
what
here
we
are
doing
here
is
we
are
adding
a
label
called
global
and
we
are
setting
that
to
true
what
this
means
is.
This
this
plug-in
will
always
execute
no
matter
where
the
request
comes
from
right.
B
So,
even
if
we
click
any
any
ingress
rule,
it
comes
from
or
it
will
be
matched
and
we'll
allow
five
requests
per
minute
and
we'll
have
a
policy
of
local
policy
is
something
that
you
can
dig
deeper.
You
can
have
radius
to
have.
You
know
radius
based
rate
limiting
and
those
things,
so
those
are
more
like
implementation
details.
So
we
do
this.
B
So
now
we
sent
a
request
to
HTTP
bin
and
we
can
see
kong
injected
rate
limit
header
right,
so
you
have
also
the
other
plugin
that
we
had
enabled
before
is
executing
authentication
is
also
going
on,
and
kong
is
also
doing
rate
limiting
now
so
right.
So
we
are
allowing
five
requests
per
minute
and
we
can
make
four
more
requests
right
and
if
we
execute
this
thing,
so
let's
do
even
this
one.
B
So
if
we
send
a
request
to
the
other
service,
we
will
see
that
you
still
get
rate
limited
right,
so
no
matter
which
service
you
are
accessing,
you
are
being
rate
limited
now
here
the
rate
limit
was
four
again
because
the
minute
rolled
around,
so
it's
a
minute,
Behe's
root
rate
limiting.
So
that's
why
it
rolled
around.
Now,
if
you
keep
on
executing
this
request
a
few
times,
you
can
make
one
more
request.
B
You
can
not
make
any
request,
and
now
you
get
four
too
many
requests
of
4:29
rate,
so
you're
being
denied
access
to
the
service.
If
you
make
more
than
fire
request,
so
you
can
configure
this
again
to
be
hourly
per
second
or
whatever
rate
you
have,
and
then
you
know,
maybe
you
want
authentication
enabled
for
rate
limits,
maybe
not
all
that's
also
configurable
as
well.
B
B
Next,
what
we
are
going
to
do
is
show
of
another
plug-in,
which
is
also
pretty
popular.
We
recently
open
sourced
this
one
is
the
proxy
cache.
So
it's
basically
response
caching,
and
we
will
also
enable
this
at
the
global
level.
So
by
global
level,
you
don't
need
to
associate
with
a
specific
ingre
specific
service.
Comm
will
execute
that
for
every
request
that
flows
through
it
right
and
if
you
want
to
enable
it
on
for
a
specific
ingress
rule,
you
can
do
that
as
well.
So
it's
pretty
flexible
based
on
you
know
each
team's
requirement.
B
You
can
configure
them
and
have
them
configure
it
or
maybe
Rob's
people
to
do
it.
So
let's
go
ahead
and
now
try
to
access
in
point
now
we
have
got
a
few
things
going
on
here,
so
we
have
the
rate
limit
of
obviously
that's
going
on.
We
also
have
got
X
cache
key
annex
my
bypass
key
cache
status.
So
here
we
see
the
cache
status
is
bypass.
The
reason
being
by
default.
Kong
will
not
cache
HTML
that's
coming
from
the
backend,
but
if
were
to
be
I,
think
only
do
application
JSON.
That's
also
configurable.
B
Obviously
like
what
kind
of
content
types
do
you
want
to
cache?
So
let's
do
let's
do
headers.
So
if
we
do
headers,
so
we
can
pick
the
headers,
but
we
see
that
the
cache
status
is
Miss
here,
because
it
was
the
first
request.
That'll
be
executed
and
we
are
caching
things
in
memory
right.
We
can
also
cache
things
in
Redis
and
you
know
if
you
have
multiple
traffic
multiple
services
going
through.
You
can
cache
based
on
selectively
as
well.
So
we
see
the
caches
hit.
I.
B
Think
if
I
add
another
header
here
yeah,
so
you
see
so
in
the
last
request,
what
what
we
did?
We
got
a
cache
hit
right
and
then
the
next
request
that
I
sent
I
actually
changed.
The
header
rate
I
added
a
full
bar
header,
but
that
didn't
appear
in
this
response.
So
if
you
enable
caching
blindly,
this
is
a
wrong
response
right.
The
services
Sydney
is
a
response
is
being
cast
which
should
not
be
cached.
So
this
is
how
I
mean
if
there
are
n
points
that
you
would
like
to
cache.
B
You
know
which
are
sending
back
metadata
so
that
come
results
to
the
cached
info.
When
your
service
is
not
available,
you
can
do
those
magics
easy
yeah.
So
that's
what
we
are
doing.
We
are
caching,
we
are
rate
limiting.
We
are.
We
have
you
know,
authentication
enabled
here,
so
that's
all
that
I
have
for
demo
right
now.
Let's
see,
there
are
a
lot
of
other
features
that
exist
and
those
are
specific
to
Cuba
notice
as
well.
So
we
integrate
heavily
with
no
Prometheus.
B
We
integrate
with
open
tracing
as
well,
so
you
can
use
those
to
you
know,
get
matrix.
You
know
every
request
this
that
flows
into
your
cluster.
You,
you
have
a
Cuban
at
its
dashboard
and
you
don't
have
to
instrument
your
services.
You
know
you
don't
have
to
implement
Prometheus
matrix
for
in
each
and
every
service
that
you
need.
You
can
just
get
that
out
of
Kong
for
you
and
obviously
we
will
have
like
more
black
box
matrix,
meaning
you
know,
we'll
have
sir.
You
know
request.
B
Latency
is
bandwidth
being
consumed,
error
rates,
you
know
based
on
HTTP
requests
or
maybe
TCP
timeouts
or
if
you
have
G
RPC,
then
you
have
our
PC
error
rates,
so
con
can
do
all
that
we
also
integrate
heavily
with
you
know:
cert
managed
on
an
external
DNS
I
am
using
external
DNS
right
now.
So
if
you
create
any
DNS
entry,
if
I
create
an
interest
resource,
it
actually
automatically
populates
my
DNS
server
and
then
you
know,
as
you
could
see,
I
created
that
HTTP
pin
rule
and
it
automatically
created
an
ad
called
for
it.
B
We
also
do
a
lot
of
you
know,
route
by
header
and
HTTP
method.
If
you
won't,
like
you,
know
more
fine-grained
routing,
we
do
not.
We
introduced
something
called
Kong
ingress
which
allows
you
to
you
know:
tweet
load-balancing
configurations.
Other
you
know.
Health
checking
in
circuit
breakers
are
also
possible
so
that
all
can
be
done
at
Kong
Kong
itself
and
we
have
a
very
strong
roadmap.
So
Kong
currently
actually
can
proxy
GRP
see
it
can
proxy.
You
know
TCP
TLS
issue
as
well.
B
So
if
you
have
like
a
custom
protocol-
and
you
just
want
to
do
TLS
termination,
SATCOM
can
do
that
for
you.
If
you
have
a
custom
protocol,
you
can
do.
Protocol
parsing
at
Kong
can
do
that.
G
RPC
routing
is
just
recently
landed
with
1.3,
so
you
can,
you
know,
expose
your
G
RPC
service,
Viacom
and
Cong
will
do
the
routing
for
you.
You
can
do
transformation
logging
again
again.
B
You
are
running
inside
Cuba
notice,
which
is
a
requirement
by
some
of
our
users,
and
we
have
a
few
other
admission
web
box
and
making
it
all
the
more
easier
to
use.
So
that's
that's
the
roadmap
that
we
have
for
this
year
and
that's
it.
That's
all
that
I
have
for
this
presentation.
Installation
is
pretty
simple.
It's
open
source
feel
free
to
try
it
out.
We've
been
getting
a
lot
of
feedback
from
the
community
and
adoption
so
very
happy
with
that.
B
A
We
have
a
lot
of
questions
coming
in,
so
thank
you,
Harry
for
a
great
presentation
and
if
you
have
questions,
please
drop
them
in
the
Q&A
tab
at
the
bottom
of
your
screen.
I
will
say
that
we
do
have
a
lot
coming
in,
so
if
we
don't
get
to
them
in
the
next
15
minutes,
we
do
have
a
Kong
slack
channel
on
the
kubernetes
slack.
So
please
join
us
there.
A
You
want
to
dive
deeper
in
debt
and
I
also
will
just
say
that
we
have
a
few
events
coming
up
later
this
year,
so
we
have
clung
summit
coming
up,
October,
2nd
and
3rd
in
San
Francisco.
We
have
ghost
and
great
Kong
specific
workshop
sessions
as
well
as
more
sessions
around
cloud
native
technologies
in
the
community.
So
there
is
a
code
here
that
we're
offering
the
peer
interested
in
joining
us.
If
you
go
the
next
one.
A
We
will
be
a
cube
cotton
cloud
made
of
cotton,
San
Diego.
This
would
be
our
just
cute
con
today.
So
we'll
have
a
day,
zero
event
there.
We
will
cover
best
service
mesh
content,
so
the
link
to
our
Colo
isn't
up
yet,
but
I
will
add
that
to
the
slides
once
it
in
and
we'll
also
have
a
booth
there.
So
it's
not
by
and
say
hi
these
questions
so
going
back
to
the
demo.
I
want
to
I'm
gonna
start
here.
Just
make
sure
we
clarified
many
points.
A
B
B
What
we
have
is,
we
have
two
pods
running
here
so
and
we
we
we
have
a
controller
running
inside
one
in
the
we
have
one
pod
running
with
two
containers
and
on
all
the
containers
is
a
controller,
so
we
do
not
need
anything
to
in
the
master
at
all,
and
the
controller
will
talk
to
the
master
node
the
API
server
and
get
those
ingress.
Yeah
means
those
yeah
means
are
stored
inside
yet
CD,
that's
Cuban,
it
is
object
store.
So
you
don't
need
to
configure
anything
special
inside
your
Cuban.
It
is
control
plane
at
all.
B
B
So
by
default,
if
you
don't
annotate
an
ingress
class,
then
any
ingress
controller
will
accept
that
that
ingress-
and
you
know
configure
it.
If
you
have.
Let's
say
you
know
if
you
have
GCE
like
GCP
ingress
running
and
you
have
kong
running
and
your
another
controller
running
then
if
you
annotate
it
with
conch
only
then
that
would
be
accepted
so
by
default.
If
there
is
no
annotation
present,
we
will
accept
that
rule.
B
But
if
you
want
to
you
know
segregate
those
ingress
rules
for
different
controllers,
you
can
specify
those
classes
or
maybe
you
can
run
multi
Kong
ingress
controls
as
well,
one
for
internal
traffic,
one
for
external
traffic
or
you
know
for
different
business
units.
If
that's
your
use
case
and
then
annotate
of
those
classes,
and
then
you
can
segregate
that.
So
that's.
A
B
That's
okay,
yeah,
so
the
load
balancer
that
we
are
using
here
in
case
of
we're
using
gke.
So
if
you
see
we
have
only
one
IP
address
right.
So
if
we
go
back
to
the
demo
get
service
comm,
we
see
that
there
is
only
one
IP
address.
What
is
happening
under
the
hood
as
Google
is
provisioning,
a
global
load
balancer
which
uses
anycast.
So
even
though
there
is
only
one
external
IP
address,
this
is
actually
being
handled
by
a
array
of
machines
right
so
Google.
So
this
is
a
managed
load
balancer
by
Google.
B
So,
and
it
comes
with
a
promise
of
you
know,
if
a
single
machine
goes
down,
it
won't
fail.
So
that's
why
it's
not
a
single
point
of
failure
and
same
with
com.
You
should
probably
run
multiple
instances
of
Kong
pods
so
and
these
pods
are
stateless.
So
if
even
if
one
of
those
dies,
you
don't
have
a
failure.
So
if
you're
running
into
this
inside,
let's
say
Amazon's
eks
I
think
they
call
it
e
KS,
yeah,
Amazon's
load
balancer
are
usually
are
provisioned
with
two
IP
addresses
right.
So
that's
for
a
little
bit
of
failover.
B
So
you
can
and
those
IP
addresses
change
and
you
get
installed
a
cname.
So
in
that
case
you
have
two
of
those,
so
it
really
depends
on
specific
implementations
of
you
know:
load
balancer
service,
so
any
load
balance
of
service
has
different
implementation
based
on
the
cloud
providers
that
you
are
using
or
if
you
are
in
bare
metal,
you
might
not
actually
have
those
so
yeah
I
hope
that
answers
that
question.
B
That's
a
very
good
question:
I've
tested
it
fit
about
500
resources,
and
this
was
for
like
a
test
inside
know,
one
of
the
liabilities
that
we're
using
that
we
are
doing
pagination
and
those
things
correctly.
If
you
are
using
a
lot
lot
of
ingres
resources,
that's
not
a
problem.
The
Cong
interested
easily
be
able
to
handle
those.
If
you
are
using,
it's
not
recommended
that
you
use
a
lot
of
consumers
and
credentials,
but
ingress
resources.
Creating
a
lot
of
those
and
a
lot
of
plugins
should
not
be
a
problem.
B
If
you
go
like,
let's
say,
beyond
thousand
increase
resources,
you
you'll
have
to
tweak
certain
Kong
settings,
so
you'll
have
to
cute
a
little
bit
of
memory,
and
this
is
really
depending
on
you
know
your
traffic
patterns,
so
you
tweak
them
as
you
go,
but
by
default,
I
think
it
it's
there's
no
hard
limit
that
we
have
imposed
or
that
we
have
run
into
yet.
So
maybe,
if
you
find
one,
please
do
report
back.
B
So
that
ties
back
against
into
the
same
ingress,
tat
class,
annotation
discussion
right,
so
what
you
can
do
is
you
can
annotate
the
certain
ingress
rules
will
be
advocated
with
the
ingress
class
of
in
genetics
and
then
sultan
can
be
annotated
with
ingress
class
of
kong
right,
and
this
class
itself
is
also
configurable
as
well,
so
you'll
annotate
these
and
then
those
like
the
ingress
rules,
annotated
with
that
particular
ingress
type.
Only
those
will
be
satisfied
with
by
kong
right.
B
So
you
definitely
do
not
want
it
to
happen
that
you
have
to
ingress
controllers
fighting
for
the
same
ingress
right.
If
you,
if
we
see
here,
cube,
CTL,
ok,
ingress,
we
will
see
that
the
address
of
this
is
updated
with
the
address
of
the
load
balancer
right.
So
if
you
have
to
load
two
ingress
controllers
running
and
they
constantly
keep
on
over
changing
your
address
and
keep
on
fighting
to
satisfy
those
resources
which
might
result
into
conflict
so
with
with
increased
or
class
annotations,
which
is
very
widely
adopted.
A
B
Obviously,
I
have
my
bias
here,
but
I
would
rather
ask
you
to
go
to
the
nginx,
English
controller
documentation
and
then
go
to
kongstrup
citrate,
so
both
of
them
are
powered
by
the
same
underlying
stock
right
engine
X
on
top
of
openness,
T
and
then
you
have
Kong
and
engine
X
has
directly
open
resti.
So
the
way
a
lot
of
libraries
that
are
used
even
in
the
engine,
X
ingress
are
shared
right.
Both
of
me
try
to
make
engine
X
as
dynamic
as
possible
with
Kong.
B
What
you
get
is
a
lot
of
other
enhancements
that
don't
come
with
out
of
the
box
with
the
engine.
X
ingress.
You
have
this
plug-in
architecture,
so
you
can
do
authentication.
You
can
do
just
caching
and
these
things-
and
these
are
all
customizable
right.
So
if
certain
plugin
doesn't
fit
your
need,
you
can
always
tweak
those
or
if
you
have
some,
you
know
a
specific
implementation
that
you
want
to
do
inside.
You
know
new
or
you
can
write
your
own
custom
plugin.
B
We
also
have
server,
let's
plug
in,
so
you
can
execute
blob
of
Lua
code
inside
comm,
so
for
every
request
that
goes
through
your
building,
say
P
I,
and
you
want
to
do
some
special
magic.
You,
you
can
write
up
just
a
small
bit
of
Lua
script.
Put
that
inside
Kong
and
Kong
will
execute
that
so
that
plug-in
that
plug-in
based
architecture
gives
you
a
lot
and
then
comes
to
a
lot
of
load,
balancing
and
TLS
management
right.
So
you
can
do
a
lot
of
things
like
you
know,
upstream
TLS,
downstream
TLS
mutual
TLS.
B
If
that
need
need
it,
so
those
things
are
much
much
much
easier
for
you
to
run
that
also
engine
X
ingress
is
something
very,
very
specific
to
kubernetes.
So
if
you
are
adopting
Kong
into
this
controller-
and
let's
say
your
certain
part
of
your
organization
does
not
run
in
Cuba
notice,
you
can
still
they
can
still
run
Kong
and
you
can
have
a
lot
of
knowledge
here,
a
lot
of
transparency,
another
advantage.
If
you
were
to
phase
out
kubernetes
in
future,
you
can
just
there
is
a
small
command
for
dumping.
B
The
ingress
controller
configuration
you
can
just
export
that
and
import
that
in
a
different
environment
and
things
would
work
so
you
won't
have
to
again
start
from
scratch
rebuilding
that
environment.
So
these
are
the
things
which
make
it
pretty
ability,
extensible,
but
also
very
much
compatible
with
other
other
orchestration
platforms
that
you
have
a
lot
of
like
the
community
around
it.
The
plug-in
community
is
huge
so
that
you
can
take
that
advantage.
This.
B
Yeah,
so
you
can
so
if
you
I,
don't
know
if
you
saw
it
or
not
in
the
demo
fever
limiting
actually
by
consumer,
so
you
can
definitely
do
that.
So
you
know
based
on
authentication
based
on
you
know,
if
you
have
a
DC
authentication
you
can,
you
know,
have
that
consumer
created
automatically
in
Kong.
If
you're
doing
API
key
authentication
for
every
consumer,
you
can
have
a
rate
limit.
You
can
also
have
a
different
rate
limit
for
every
consumer
as
well.
So
you
know,
maybe
you
have
certain
consumers
are
who
are
paying
you
more?
B
You
give
them
higher
rate
limit
and
who
are
paying
you.
Let's
give
them
a
lower
limit
or
you
can
have
a
uniform
limit
across
all
the
consumers
as
well
or
you
can
have
exceptions.
You
know
so,
for
every
four
HTTP
min
service
I
have
X
rate
limit
file
for
my
Billings
API
have
vile
appropriate
limits.
All
that
is
pretty
configurable
out-of-the-box.
B
Don't
think
that's
possible
I
do
okay,
so
that
might
be
possible
with
if
you
do,
header
based
routing.
So
you
know
based
on
the
Ori
origin,
hider
you,
you
change
your
request
or
response
path
or
patterns.
You
can
do
that,
but
this
should
be
something
very,
very
easily
possible
with
a
small
patch
right.
You
can
easily
do
that.
It's
I'm
not
too
sure
if
it's
possible
out-of-the-box,
but
you
might
have
to
write
like
a
small,
newer,
snippet
I.
Do
that.
B
The
good
question,
so
we
are
trying
to
make
kong
easier
and
more
and
more
easier
to
run.
There
is
a
conch
operator
that
is
more
like
an
alpha
stage
operator
and
trying
to
put
in
some
resources
into
that.
So
definitely
check
that
out
the
link.
There
would
be
kong,
slash
kong
operator
on
github,
so
you
can
go
to
get
about
comm,
/
kong,
slash,
Kong
operator.
You
can
check
that
out.
B
B
The
current
demo
that
we
ran
is
DB
less
actually,
so
we
are
running
it
already
be
less
mode.
That
means
Kong
is
not
backed
by
any
database.
You
can
also
install
Kong
with
a
database
which
is
the
more
popular
and
the
more
like
DB.
Less
came
out
only
I
think
earlier
this
year
with
a
database.
Also,
you
can
manage
that,
so
you
can
have
some
custom
configuration
that
you
want
to
put
manually
inside
the
database.
You
can
do
that
and
rest
of
the
configuration
in
manage
my
ingress
controller.
B
A
B
So
you
can
do
that,
so
what
you
can
do,
the
there
is,
you
can
create
one
ingress
resource
which,
by
which
applies
a
plug
which
secures
all
the
endpoint.
Then
you
create
another,
and
then
you
know
so
you
annotate
that
with
that
authentication,
plug-in
lets
say
very
example.
You
want
don't
want
slash
health
to
be
authenticated,
then
you
can
create
another
ingress
resource
which
is
more
specific
right.
So
it's
a
slash
service,
a
requires
authentication
but
then
slash
service.
B
A
slash
health
does
not
require
authentication,
and
then
you
can
make
it
more
granular
or
more
general
as
well,
so
maybe
slash
service.
A
slash
public
does
not
require
authentication
at
all,
and
so
you
can
do
that
as
well.
That's
skirt
only
possible
pretty
easily.
You
just
have
to
create
another
ingress
resource.
B
B
So
you
know
if
you
want,
you
know
a
nicer
UI
to
manage
Kong,
you
want,
you
know,
developer
portal
functionalities,
you
want,
you
know,
arbok
accesses
inside
the
Kong,
a
P
is
itself
and
that's
where
enterprise
comes
in
and
then
we
are
doing
a
lot
of
things
around
the
you
know,
machine
learning
and
how
we
can
help
you
further
manager.
Api
is
better.
So,
since
Kong
has
access
to
the
traffic,
it
can
figure
out.
Okay,
what's
going
wrong
or
what
has
recently
changed.
So
all
those
are
enterprise
features.
B
The
core
routing
always
remains
inside
the
open
source
version
and
the
Kong
enterprise
actually
just
inherits
that
and
builds
on
top
of
it.
These
enterprise
features
which,
if
yeah
that's,
that's,
that's
the
basic
gist.
I
work,
a
lot
on
the
open
source
sites.
I
am
doing
a
really
terrible
job
of
explaining
what
enterprises
so
yeah.
A
Just
to
reinforce
everything
we've
covered
here
is
an
open
source
feature.
Yes,
yes,
okay,
unfortunately
part
time.
I
know
we
have
more
questions
that
we
didn't
get
to.
So
we
will
take
this
offline
and
get
you
all
answers
to
those.
If
you
want
to
chat
in
the
meantime
again,
please
join
us
ponds,
lack
the
kubernetes
slack
in
the
comm
channel
and
thank
you
all
for
the
great
questions
and
for
joining
us.
Today,
again,
the
recording
and
slides
will
be
online
later
and
we
look
forward
to
seeing
you
at
a
future
scenes.
Webinar
thanks.
Everyone
thank.