►
From YouTube: Zero Downtime Upgrading Strategies to Kong Gateway 3.x
Description
Are you running Kong Gateway below 3.0 and need help upgrading and what to look out for? Then this presentation is for you!
In this talk, Andrew Kew (Senior Technical Account Manager & Field Engineer at Kong) will discuss a few upgrade strategies from Kong Gateway 2.x to 3.x to ensure a zero downtime and smooth upgrade. Next to that, you will learn what to look out for when upgrading to 3.x. At the end of the presentation, Andrew will talk through some of the new features in Kong Gateway 3.0.
A
So
hello,
everyone
welcome
good
morning,
good
afternoon
good
evening
from
wherever
you're
joining
us
I'm
so
happy
to
have
all
of
you
here
today.
My
name
is
Dalia
and
I
work
on
Kong's
Community
team
as
a
global
Community
manager.
So
today
we
have
a
very
interesting
presentation
for
you
how
you
can
upgrade
to
con
gateway
to
above
3.0
with
zero
downtime.
We
have
Andrew
here
he
will
introduce
himself
and
he
will
tell
you
all
the
strategies
you
need
to
know
to
make
that
upgrade.
A
We
will
take
all
the
questions
at
the
end,
so
please
use
the
Q
a
function
and
input
them
there.
We
will
answer
them
as
soon
as
he's
done
with
the
presentation
and
with
that
I
like
to
pass
it
along
to
Andrew,
go
ahead.
President.
B
Thanks
thanks,
Talia
hi
welcome
everyone.
So,
as
Dahlia
said
today,
the
topic
is
around
upgrading
Kong
to
Kong
three
with
zero
downtime.
B
My
name
is
Andrew
Q
I'm,
a
senior
field,
engineer
and
technical
account
manager
at
com
I
help
a
number
of
their
strategic
customers
and
Enterprise
customers
with
you
know,
getting
Kong
installed,
upgraded
and
all
the
the
ecosystems
around
Kong,
getting
that
sort
of
all
to
production
and
and
ready
for
them
to
use
so
jumping
into
today's
talk,
a
quick
agenda
just
about
what
I'm
going
to
be
talking
about.
First,
we'll
just
go
through
some
of
the
Kong
deployment
modes.
B
So
then
that
might
be
a
couple
of
you
on
the
call
that
maybe
aren't
familiar
with
all
the
different
deployment
modes.
So
when
I'm
talking
about
them
later
in
the
talk,
it
should
hopefully
make
a
bit
more
sense.
B
B
Within
that
I'll
talk
about
some
upgrade
strategies,
so
how
you
can
upgrade
some
of
the
considerations,
things
to
think
about
things,
to
consider
when
you're
doing
an
upgrade,
how
you
choose
a
strategy
which
trance
strategy
should
I
choose,
based
on
what
I've
just
explained
a
little
bit
about
Kong,
LTS
and
then,
lastly,
just
finishing
off
with
upgrading
of
additional
tools
as
well,
because
Kong
is
your
API
Gateway,
but
you
do
have
a
number
of
other
tools
as
well
that
you'll
need
to
take
into
account
accounts
and
upgrade
when
you
are
doing
that
upgrade
strategy.
B
So
before
we
kick
off
with
with
everything,
I
think
it's
quite
nice
to
start
off
just
with
the
poll.
So
dollar,
if
you
don't
mind,
kicking
the
poll
off
so
yeah.
If
everyone
could
just
answer
the
poll,
I
guess
you
know
what
I'm
looking
at
here
is
is
probably
just
understanding.
You
know
from
all
the
all
the
attendees
today
effectively
what
gateways
you
are
using.
You
may
be
here
just
to
see
what
Kong's
about
you
may
already
use
Kong.
B
What
versions
you
currently
are
using
as
well
and
then,
if
you've
tried
a
a
migration,
maybe
you've
already
tried
the
concrete
migration,
unsuccessfully
or
maybe
you've
got
to
a
sticking
point
and
hoping
that
you
know
this
might
shed
some
light
for
you
as
well
on
that
so
yeah
just
give
give
everyone
a
couple
of
minutes
just
to
fill
that
in,
and
it
gives
me
a
good
insight
as
well
I
think
as
to
the
level
that
I
pitched
the
the
talk
at
as
well.
B
I
have
run
this
before
at
an
in-person,
Meetup
and
I.
Think
most
of
the
attendees
didn't
know
Kong
so
I
think
there
was
a
lot
that
went
straight
over
their
heads
just
because
I
got
quite
detailed
with
with
a
couple
of
the
aspects.
So
it's
just
good
to
know.
You
know
the
the
audience
that
we've
got
today.
A
A
All
right,
let
me
end
it
cool,
so
what
API
Gateway
to
use?
We
have
the
con
Gateway,
the
most
popular
one
with
88
percent.
What
version
of
Kong
most
people
actually
use
two
point
something
with
76,
so
this
talk
will
be.
A
And
then
the
last
one
we
have
heavy
tried
con
3.0
migration
before
the
answer
is
no
88.
So,
okay.
B
Thanks
yeah
yeah,
so
that's
really
good
to
hear
so
you
know
still
a
number
of
you
on
on
Kong
version
two
and
looking
for
I
guess
some
insights
and
information
on
how
to
upgrade
so.
This
is
the
perfect
talk
for
you,
so
brilliant
all
right,
so
cool
I'm,
going
to
close
that,
let's,
let's
jump
straight
into
it
so
before
I
start
off,
like
I
said
before
I'm,
just
going
to
run
through
a
couple
of
bits
and
pieces
about
Kong
just
to
make
sure
everyone's
familiar
with.
B
You
know
all
of
the
deployment
modes
that
you
can
actually
deploy,
Kong
in
so
the
first
one
is
the
traditional
mode.
So
traditional
is
a
mode
of
Kong
that
you
normally
deploy
in
sort
of
proof
of
concept
phase
and
it
effectively
is
Kong
running
all
together
in
one
instance,
whether
that's
an
ec2
instance
or
in
a
single
pod.
B
It
can
be
db-backed
or
dbless
but
effectively
having
it
all
in
in
one
place.
So
you
know
if
you
had
to
replicate
that
or
do
high
availability,
it
would
be
replicating
the
entire
Kong
Suite.
So
again,
that's
mostly
for
poc's
hybrid
is
probably
the
most
recommended
deployment
mode
for
Kong
and
is
what
we
recommend
at
Kong
for
our
clients
to
use
in
into
production.
The
difference
here
between
traditional
and
hybrid.
B
It
is
we're
now
removing
the
data
planes,
so
the
proxy
out
of
the
control
plane
and
they
effectively
sit
below
the
control
plane
and
connect
to
the
control
plane
via
a
websocket.
So
the
communication
between
the
two
is
done
via
this
websocket
and
that's
how
the
data
planes
get
to
get
told
about
the
configuration
changes.
The
control
plane
is
still
connected
to
the
database
and
that's
how
the
configuration
changes
are
made
and
what's
really
good
about
this
particular
mode.
B
Is
that
if
the
communication
between
the
control
plane
and
the
data
plane
goes
down,
your
data
planes
still
keep
running
on
the
last
known
configuration.
You
can
then
scale
out
your
data
planes
as
well,
and
it
gives
you
the
ability
to
ensure
that
your
data
planes
can
manage
your
your
predicted
traffic
that
you've
got
coming
through
the
next
install
mode
is
the
Kong
Ingress
controller.
This
is
a
kubernetes
native
way
of
deploying
Kong
recommended
to
deploy
this
in
dbless
mode.
B
You
can
effectively
deploy
your
data
planes
with
your
proxy
and
your
Ingress
controller
in
a
single
pod.
There
is
a
mode
to
actually
have
the
Ingress
controller
in
Standalone
mode
outside
and
just
deploy
your
proxies
as
well,
but
this
is
normally
a
mode
that's
used
when
you
want
to
deploy
Kong
and
configure
Kong
in
a
kubernetes
native
way
and,
lastly,
the
connect
SAS
offering
so
that's
Kong's,
new
SAS,
offering
which
is
effectively
a
a
SAS
control,
plane
and
developer
portal.
That
is
all
managed
by
Kong.
B
So
you
don't
have
to
manage
any
of
that
yourself.
You
just
deploy
your
data
planes
and
you
can
effectively
deploy
different,
bundles
or
different
releases
of
data
planes
connected
to
different
sets
of
configurations
which
is
the
New
Concept
called
runtime
groups,
which
I
won't
go
into
more
detail.
That's
probably
more
along
the
lines
of
a
a
connect
talk
but
yeah.
That
is
definitely
another
deployment
mode
where
you're,
just
managing
your
data,
planes
and
Kong
is
managing
the
control
plane
and
the
developer
portal
as
well.
So
those
are
all
the
the
deployment
modes.
B
B
A
number
of
Enterprise
and
open
source
features
that
have
been
added,
but
some
just
to
highlight
the
secrets
management
when
General
availability,
which
I
think
is
a
really
nice
addition
being
able
to
connect
Kong
up
to
a
hasher
called
Vault
or
AWS
Secrets
manager
and
then
being
able
to
reference
all
of
your
sensitive
data
and
effectively
when
Kong
comes
up
when
it
starts,
it
connects
out
to
your
secret
management
system
and
it
replaces
those
placeholders
with
the
values
that
come
out
of
your
secret
management,
so
anything
that
you
have
committed
into
your
repositories,
anything
that
gets
deployed
as
part
of
your
you
know:
kubernetes
resources,
all
of
that
stays,
as
is
as
the
placeholders
and
none
of
it
gets.
B
The
new
Kong
or
the
new
data
plane,
rust
router
is
probably
another
one
worth
mentioning,
so
the
router
on
the
data
plane
has
been
Rewritten
using
the
rust
language.
This
has
been
a
really
big
step
forward
in
the
Kong
data
planes
and
has
added
quite
a
lot
of
good
performance.
B
Improvements
in
the
in
the
router
also
opened
up
a
whole
lot
of
other
aspects
to
allow
Kong
to
start
improving
on
and
adding
to
the
the
features
to
the
router
they've
released
the
new
DSL
that
allows
you
to
effectively
express
your
roots.
So
you
know
it's
just
a
starting
point
now,
but
there's
a
lot
more
to
come.
B
I
think
down
the
road
with
regards
to
that
DSL
and
what
you
can
actually
do
if,
from
the
core
of
Kong,
there's
been
quite
a
lot
of
changes
with
regards
to
the
images
so
the
if
you're
running
a
kubernetes,
the
docker
images,
so
a
Ubi
and
slim
image,
which
has
been
released
but
I'll
talk
a
little
bit
more
about
that
in
a
second.
When
I
talk
about
the
considerations,
I
think
the
other
one
that's
worth
mentioning
as
well,
which
is
also
an
open
source.
B
Improvement
is
open,
Telemetry,
so
open
Telemetry
has
been
brought
into
Kong
and
added
to
the
core
of
Kong,
which
gives
you
the
ability
to
be
able
to
trace
through
Kong
what
that
gives.
You
is
insights
into
what's
going
on
at
an
nginx
phase
level,
and
that
gives
you
the
ability
to
see
the
latencies
for
all
of
the
plugins
that
you're
running
for
each
request.
The
pvk
which
you
use
to
develop
your
custom
plugins
now
has
a
open,
Telemetry
Library
within
the
pdk.
B
B
Moving
on
to
Kong,
3.1
I
think
nicknamed
the
plug-in
release.
Most
of
the
changes
here
were
effectively
Enterprise
plugins,
so
new
plugins
that
got
added
or
improvements
ones
so
released
in
December
of
last
year.
One's
worth
calling
out
I
think
app
Dynamics,
it's
definitely
a
observability
tool
that
a
lot
of
our
Enterprise
customers
have
been
asking
for.
B
So
that's
that
plug-in
is
now
is
now
there
within
Kong
3.1
enhancements
and
improvements
to
the
mock,
plug
the
mock
plug-in
as
well,
so
giving
you
the
ability
to
effectively
give
com,
give
the
plug-in
your
open,
API
spec
and
get
Kong
to
mock
out
your
endpoints.
B
Quite
a
very
nice
and
simple
way
to
get
your
mock
mocking
out
of
of
your
endpoint,
especially
on
the
developer
portal,
so
yeah
something
worth
looking
into
for
sure.
And,
lastly,
the
JWT
decryption
plugin.
So,
given
you
the
ability
to
decrypt
your
JWT
tokens
at
the
Kong
layer
and
then
obviously
being
able
to
do
things
like
sort
of
validate
and
have
a
look
at
those
those
tokens.
B
If
you
need
to
moving
on
to
the
next
version,
Kong
3.2,
not
as
many
features
I
guess
released
in
this
version,
but
I
think
some
very
important
ones
and
one's
worth
calling
out
the
data
plane
scale
out
feature
I'm
going
to
talk
about
in
a
little
bit
more
detail
in
a
second.
But
definitely
one
worth
calling
out
giving
you
the
ability
out
of
the
box
to
ensure
that
your
data
planes
are
highly
available,
even
in
the
case
of
losing
the
control
plane.
B
This
release
was
released
in
February
of
this
year,
so
only
a
couple
of
months
ago,
our
plugins
are
now
fips
140-2
compliant.
That's
a
cryptography
compliance
and
all
of
the
cryptography
libraries
that
Kong
does
use
now
and
users
within
their
plugins
is
now
based
off
of
this.
After
this
compliance
and,
lastly,
probably
the
latency
based
steering.
B
So
a
really
nice
feature,
that's
been
added
to
Kong
3.2,
so
taking
a
deeper
look
into
this
data
plane
scalar
feature,
and
this
diagram
is
a
really
nice
diagram
to
show
exactly
what
it
is
that
I'm
talking
about.
So
if
you
have
the
event
you're
running
in
hybrid
mode
and
your
connection
to
the
control
plane
goes
away,
whether
that's
a
network
connection
or
your
database
goes
down
or
your
control
plane
goes
down,
but
you
need
to
scale
out
with
some
more
data
planes.
B
Maybe
at
that
point
you
hit
some
Peak
traffic
and
you
need
to
scale
out.
You
know
with
some
more
data
planes
effectively.
What
this
scale
out
feature
does.
Is
it
allows
your
data
planes
to
connect
to
some
external
storage,
whether
it's
you
know
AWS,
S3
or
any
of
the
other
Cloud
providers
and
get
a
backed
up
version
of
your
configuration.
B
So
you
effectively
configure
your
control
plane
to
back
up
that
configuration
into
this
external
storage
and
then,
when
the
data
plane
comes
up,
if
it
can't
connect
to
the
control
plane,
it
will
effectively
connect
to
your
external
storage,
pull
the
configuration
load
itself
up
and
then
start
managing
traffic.
Once
the
connection
comes
back
again,
it
will
connect
to
the
control
plane
and
then
obviously
receive
any
additional
configurations
if
there
have
been
any
since
that
that
backup.
This
leads
really
nicely
into
a
sneak.
B
Peek
feature
that
I'm
going
to
be
showing
you
about
ensuring
that
your
data
planes
are
ready
to
actually
manage
the
traffic
once
the
configuration
is
loaded
and
that's
what
I'm
going
to
talk
about
next.
So,
as
mentioned
a
bit
of
a
sneak
peek
I'm
going
to
look,
give
you
a
bit
of
a
sneak
peek
as
to
what's
coming
in
Kong
3.3.
B
So
this
is
scheduled
for
deployment
this
week
so
week
commencing
a
week
beginning
the
15th
of
May,
so
I
have
been
told
that
it
will
be,
at
least
by
the
end
of
this
week.
A
couple
of
really
good
features
here
that
I
think
is
is
worth
calling
out.
So
there's
now
a
open
API
spec
for
the
admin
and
developer
portal
apis.
So
if
you
go
to
developers,
konghq.com
you're
able
to
actually
view
those
specs
now
in
a
Swagger
UI,
and
you
effectively
will
be
able
to
see
see
that
test
it
out.
B
You
know,
have
a
look
at
the
the
responses
and
and
effectively
understand
what
the
apis
look
like.
A
really
nice
way
of
sort
of
playing
playing
around
with
the
apis
I
think
one
one
of
the
the
most
exciting
ones
from
my
standpoint
is
the
new
Readiness
endpoints,
and
this
is
the
one
I
was
talking
about
effectively
with
the
data
plane
scale
out.
So
what's
really
great
about
this
new
Readiness
endpoint
is,
it
will
effectively
only
return
a
200
once
your
data
planes
configuration
has
been
loaded.
B
So
it's
it's
a
it's
an
atomic
operation,
so
it
will
only
give
a
200
once
everything
is
ready
and
your
data
plane
is
is
ready
to
ready
to
start
managing
traffic.
B
That's
effectively,
I'm
still
hinging
off
of
the
status
endpoints
on
Port
h100,
just
for
the
path
of
status,
config,
so
yeah
as
soon
as
you've
upgraded
to
this
version,
you
can
update
your
Readiness
probe
in
kubernetes
and
you'll,
be
able
to
start
using
that
I'm
sure
the
the
home
chart
from
Kong
will
get
updated
with
this
new
version,
with
that
new
Readiness
endpoint
as
well
and
you'll
be
able
to
start
using
that
from
a
database
standpoint.
B
We're
now
officially
support
Aurora
in
AWS,
and
we
give
the
ability
to
do
your
Prudential
management
using
AWS
database
IAM
and
that
effectively
ensures
that
you
don't
have
to
store
your
username
and
passwords
for
the
configuration
for
the
database
within
your
servers
or
your
deployments.
You
can
effectively
use
the
AWS
credential
management
and
IAM
to
manage
the
connection
to
the
database
and
to
or
to
RDS,
postgres
or
or
Aurora
so
I
think
some
really
some
really
great
features
added
to
to
kong3
and
one
other
last
one
is
the
the
one.
B
That's
sticking
out
right
in
the
middle
is
a
a
connect
Edition
and
this
connect
Improvement
is
effectively
given
you
the
ability
to
add
additional
metadata
to
your
data
planes,
and
this
is
really
nice.
You
know
to
especially
get
more
information
when
you're
using
connect
to
effectively
understand.
B
Maybe
you
know
what
cloud
provider
they're
running
on
what
version
of
Kong
they're
running
on
you
know,
maybe
what
even
region
it's
running
in
as
well,
so
just
getting
that
additional
metadata
stored
with
each
of
your
data
planes
that
are
deployed
with
all
of
your
runtime
groups
as
well,
so
yeah
that
that's
effectively
the
new
changes
that
have
come
out
in
Kong
three.
B
Now,
let's
talk
about
upgrade
strategies,
so
how
effectively
can
you
upgrade
to
Kong?
So
these
are
going
to
be
very
general
strategies.
B
What
I
will
do
afterwards
is
then
talk
about,
depending
on
your
deployment
mode,
which
deployment
strategies
we
recommend
to
upgrade
strategies.
We
recommend
you
using
so
the
first
is
called
dual
cluster
strategy,
so
this
is
probably
the
most
recommended
strategy
for
you.
You
know
it
gives
you
zero
downtime
and
gives
you
the
ability
to
roll
back
as
well.
B
The
downside
to
this
is
you
need
additional
resource
so,
depending
on,
if
you've
got
the
capacity
to
effectively
replicate
everything.
If
you
do
have
that,
then
this
this
strategy
is
for
you
effectively.
What
you
do
is
you
deploy
a
new
database,
you
backup
your
current
database
and
you
sync
make
that
change
into
the
new
database.
You
deploy
your
new
Kong
instance.
You
run
the
migration
jobs
which
effectively
migrates
the
schema
within
the
database,
and
then
you
start
Canary
releasing
your
traffic
across
between
the
two
instances
and
slowly.
B
You
know,
obviously,
just
checking
that
you're,
you
know,
checking
your
observability
making
sure
that
you're
not
getting
any
errors
and
then
obviously
start
slowly,
reducing
the
the
amount
of
traffic
going
to
your
old
instance
and
increasing
the
amounts
on
your
new
instance
and
then
once
you've
moved
the
full
way
across.
You
can
then
pull
down
your
your
older
instance
in
this
case
Kong
2.8.
B
B
B
So
you
will
be
able
to
get
back
to
your
your
previous
state,
but
obviously,
while
you're
getting
yourself
back,
there's
going
to
be
a
bit
of
downtime.
So
how
does
this
work?
You
back
up
your
current
database
and
you
decommission
your
current
Kong.
So
that's
the
one
that
I've
got
here
in
red
2.8.
You
deploy
your
new
one
pointer
to
the
database
and
you
run
your
migration
up
and
your
migration
finish
jobs.
There
is
a
place
for
this,
and
I
will
talk
about
it
in
a
bit
more
but
effectively.
B
This
is
what
you
would
use
in
your
control
plane,
especially
if
you
don't
mind
a
little
bit
of
downtime.
This
is
what
you
can
use
there.
You
can
also,
as
mentioned
and
with
the
star
there.
You
can
also
you
know,
use
Helm
to
help
with
a
lot
of
this.
B
You
know
Helm
does
have
the
effects
of
the
jobs
that
run
the
migration
up
and
finish
for
you,
so
you
can
simplify
this
a
bit
more
using
helm
moving
on
to
the
next
one,
the
rolling
upgrade
strategy,
so
this
effectively
is
designed
for
Kong
in
dibilis
or,
if
you're
running
your
upgrading,
your
data
plane
So
within
hybrid
again.
This
gives
you
zero
downtime
and
the
rollback
strategy
as
well.
B
So
how
this
works?
Is
you
back
up
the
con
configuration
if
you're
in
DB
list,
if
you're
in
the
day
the
data
planes
within
hybrid?
You
don't
need
to
do
that
and
then
effectively.
You
continuously
install
the
new
Kong
nodes
migrate,
the
traffic
across
once
you're
happy
with
that
and
everything's
going
fine.
You
then
tear
down
the
on
the
old
Kong
nodes.
B
Okay,
so
those
are
the
upgrade
strategies,
but
what
do
I
need
to
consider?
What
are
the
things
I
need
to
think
about
when
I'm,
when
I'm
upgrading?
So
one
of
the
this
slide
talks
about
the
general
up
upgrade
consideration,
so
this
is
not
just
for
Kong
3,
but
for
any
Kong
upgrade.
One
of
the
big
things
to
understand
is
that
Kong
only
supports
one
minor
version
upgrade
at
a
time.
B
So
you
know
if
you
are
going
from
Kong
2.8
to
Kong
3,
you
need
to
go
to
from
two
to
eight
to
three
zero.
Three
one,
three
two
and
I'll
show
that
in
a
bit
more
detail
make
sure
you
stop
all
of
the
changes
to
your
data.
Before
you
start
your
upgrades,
you
know
turn
your
crcd
pipelines
off.
Stop
access
to
Kong
manager,
stop
access
to
Kong
admin
API
just
make
sure
that
the
data
isn't
changing.
B
It's
not
a
moving
goal
post
when
you're
trying
to
upgrade
make
sure
you've
reviewed
the
changelog
on
the
Kong
documentation
site
read:
what's
what's
come,
what's
changed,
it
will
be
highlighted
any
deprecations.
You
know
any
breaking
changes.
It's
always
imperative
that
you
read
the
change
log
before
you
do
any
changes
if
you've
got
your
customizations
to
Kong
itself
or
the
con
configuration
make
sure
you
reapply
that
in
your
new
instance,
any
new
con
configuration
parameters
make
sure
you've
added
those
and
again
that's
highlighted
in
the
change
log.
B
If
you've
had
to
customize
your
nginx
template,
you
need
to
make
sure
those
customizations
are
ported
across,
especially
with
kong3.
There
has
been
a
change
to
the
nginx
template,
so
if
you
have
duplicated
it
within
your
environment,
make
sure
you're
going
to
have
to
unfortunately
either
manually
or
try
with
Git
to
merge
the
changes
between
the
two
templates.
B
If
you've
got
any
custom,
plugins
there's
been
a
large
amount
of
changes
within
the
custom
plugins
and
the
pdk
within
Kong
in
Kong
3
lots
of
libraries
that
have
been
either
renamed
or
deprecated
so
definitely
worth
reading
the
change
logs
I
can't
go
through
all
of
them
now.
Otherwise
we
would
be
here
for
two
hours,
but
something
if
you've
got
custom
plugins
make
sure
you
have
tested
those
and
taken
into
account
all
the
pdk,
changes
and,
last
but
not
least,
take
a
backup.
Make
sure
you
back
up
before
you
do
the
upgrade.
B
Do
a
database
backup
database
dump
and
also
run
a
con
config
DB
export,
so
you've
got
two
backups
of
the
database
of
the
data
and
two
ways
of
being
able
to
refresh
the
data.
If
you
need
beam
now,
some
Kong
three
upgrade
considerations.
I
mentioned
before
about
the
changes
with
the
images
so
effectively
in
Docker
Hub,
where
the
images
are
hosted,
the
convenience
tags
so
like
3.0.0,
with
sort
of
no
no
operating
system
on
the
end
of
it.
B
Those
tags
have
now
moved
they
used
to
point
to
the
Alpine
version
of
Kong.
It
now
points
to
Debian
as
of
3.2.
The
Alpine
image
has
been
deprecated
and
is
no
longer
available.
So
if
you
have
been
using
the
convenience
tags-
and
you
have
maybe
built
your
own
custom-
the
golden
Ami
and
please
test
it
out
and
take
into
consideration-
it's
switched
from
Alpine
to
Debian,
and
you
may
have
to
take
that
and
consist
into
consideration
if
you've
added
anything
additional
to
your
golden
Ami
I
recommend
you
know
migrating
to
either
Debian
or
Ubuntu.
B
The
configuration
cache
on
the
data
plane.
So
in
Kong,
three
they've
changed
to
using
a
new
in-memory
data
storage
system
called
lmdb.
So
if
you
are
doing
anything
around
the
configuration
cache
file
on
your
data
planes,
you
will
need
to
make
some
changes.
The
name
of
the
file,
as
well
as
the
location,
has
changed.
B
So
that's
something
that's
very
important
that
you
need
to
take
into
account
with
the
new
rust
router
that
the
data
planes
have,
because
it's
been
Rewritten
in
Rust.
That
means
there's
been
new
libraries
that
have
been
used.
The
libraries
use
a
new
regex
engine
and
I've
got
a
link
here
to
that
regex
engine,
the
the
documentation
about
it.
But
if
you
are
using
regex
Roots,
you
need
to
ensure
that
you
are
testing
them
because
there
have
been
some
changes
and
the
behavior
of
that
library
is
slightly
different.
B
One
of
the
changes
in
Kong
3
is
it
used
to
intelligently
infer
whether
the
route
is
a
regex
roots
or
not.
Now,
in
Kong
3
you've
got
to
be
explicit.
You
have
to
mark
your
routes
with
the
tildeer
at
the
start
and
that
effectively
tells
Kong.
This
is
a
regex
route.
The
migration
of
your
configurations
using
the
Kong
DB
migration
scripts.
We'll,
add
this
for
you,
so
it
it
will
migrate
the
data
for
you,
but
still
worth
testing
after
a
migration
in
a
lower
environment,
to
make
sure
that
still
works.
B
There
is
some
missing
functionality:
the
look
around
and
back
references
which
are
regex
features.
Those
are
missing
in
this
engine,
so
if
you
are
using
them,
that's
something
you'll
need
to
consider
with
the
upgrade.
The
new
engine
also
won't
accept
escaping
of
characters
when
they're
not
needed.
That
will
actually
cause
a
failure.
So
if
you
are
escaping
characters,
make
sure
you
aren't
just
escaping
everything
to
make
sure
that
it's
all
safe,
you
need
to
make
sure
that
what
you're
escaping
needs
to
be
escaped,
otherwise
the
regex
engine
will
fail.
B
And,
lastly,
Unicode
support
is
now
added
in
in
the
new
engine,
which
is
great,
as
mentioned
already
before
you
know:
custom,
plugins
and
the
pdk.
B
Anyone
with
custom
plugins,
please
test
it
out,
get
the
new
version
of
of
Pongo
and
actually
test
out
your
custom
plugins
and
make
sure
that
they
are
ready
for
Kong
3
and
the
migration,
the
plugin,
so
the
built-in
plugins
in
kong3,
the
priorities
of
them
have
changed
if
you
depend
on
the
priority,
so
the
order
that
the
plugins
are
running
in,
please
look
into
that
and
make
sure
that
the
change
in
order
does
not
affect
the
the
order
of
logic
that
you're,
expecting
things
to
to
run
in
Kong
has
released
some
new
plugins
changes
to
current
plugins
and
deprecations.
B
Again,
I
can't
go
through
all
of
them.
There
are
quite
a
lot,
but
please
read
the
changelog
to
see
all
of
those
changes
and,
lastly,
just
an
example
of
some
configuration
parameters
which
I
think
are
worth
highlighting
as
well
again.
This
is
not
an
exhaustive
list,
but
these
are
probably
the
most
important
ones:
the
router
flavor.
So
this
root
of
flavor
that
refers
to
that
new
rust
router
I
spoke
about
they're.
Effectively
are
three
values
you
can
set
this
at
traditional,
which
effectively
runs
Kong
in
using
the
2.8
router.
B
So
your
Roots
still
described
as
Jason
there's
traditional
compatible,
which
runs
the
3.x
rust
router,
but
still
your
roots
described
in
Json
and,
lastly,
the
Expressions
feel
that
you
still
use
as
the
3.xrust
router,
but
your
roots
are
now
expressed
in
the
new
expression
format
using
the
new
DSL
that
has
been
released.
You
can't
mix
and
match.
Unfortunately,
so
you
need
to
choose
one
of
these
and
you,
you
know.
In
other
words,
you,
you
can't
have
some
Json
some
Expressions.
B
The
next
field
is
the
lmdb
map
size.
So
this
effectively
is
the
size
of
the
memory
map
that
stores
the
configuration
on
the
database.
It
is
defaulted
to
128
Megs
if
you
have
a
very
large
configuration.
So
you
have
a
lot
of
root
services
and
plugins.
This
is
going
to
be
a
field
that
you're
going
to
need
to
tweak.
So
it's
definitely
one
that
you'll
need
to
look
at
if
you've
got
a
lot
of
configuration
and,
lastly,
the
deployments
prefix
size.
This
is
a
home
chart,
parameter
and
effectively.
B
This
is
used
to
set
the
size
of
the
persistent
volume
on
your
kubernetes
cluster
for
the
prefix
directory.
This
is
where
Kong
stores
on
disk
the
lmdb
cache
file.
Again,
if
you've
got
a
very
large
configuration,
you'll
need
to
change
this
defaults
to
256
Megs.
So
you
know
configuration
B
and
C
those
two
parameters:
you'll
need
to
tweak
them
based
on
your
use
case
and
the
size
size
of
your
configuration.
B
B
So
those
are
your
two
options
with
the
traditional
deployment
which
one
to
choose
is
obviously
based
on
your
sensitivity
to
downtime
in
dbless
deployments.
So
DB
list
deployment,
as
mentioned
before
the
rolling
upgrade
strategy,
is
the
strategy
for
you
in
hybrid
deployments,
hybrid
can
be
broken
up
into
two
aspects:
your
control
plane
and
your
data
plane.
B
Your
control
plane
can
be
treated
as
a
traditional
deployment
so
effectively
you
can
upgrade
your
control
plane,
but
leave
your
data
plane
serving
traffic,
so
you
can
either
go
with
your
dual
cluster
or
you're
in
place
again,
depending
on
your
sensitivity
to
downtime
your
data
planes.
Those
effectively
you'll
use
the
rolling
upgrade
strategy.
B
The
Kong
Ingress
controller,
as
mentioned
before
you
know
this-
is
run
in
a
DB
list
mode.
You'll
use
your
rolling
upgrade
strategy,
but
there
are
a
couple
of
additional
manual
tasks
that
you
need
to
take
into
account
for
those
of
you
who
work
with
Helm,
charts
and
and
and
know
the
limitations
of
them.
You
know
that
they
don't
manage
your
crds,
so
it
will
install
your
crds
on
your
first
installation,
but
upgrading
doing
a
Helm
release
upgrade
won't
upgrade
any
of
the
crds.
B
It
will
be
marked
in
the
change
log
for
the
Ingress
controller.
If
you
need
to
you'll
need
to
upgrade
your
crds
manually,
do
your
rolling
upgrade
strategy
and
then,
lastly,
upgrade
your
kubernetes
resources,
so
any
of
them
that
have
changed.
If
there's
been
a
plug-in
change,
a
configuration
change,
then
that's
something
that
you
can
do
after
your
upgrade.
B
So
that's
most
of
all
that
that's
all
of
your
Enterprise
upgrade
strategies.
Now
having
a
look
at
your
connect,
SAS
strategy,
so
with
connect
SAS
strategy,
you
can
actually
follow
two
of
them.
You
can
do
your
your
dual
cluster
upgrade
so
similar
to
your
your
cluster,
upgrade
with
a
lowercase
C,
but
there's
no
database,
because,
obviously
that's
all
managed
by
The
Connect
SAS
offering.
But
what
you
have.
The
ability
to
do
here
is
actually
deploy
different
versions
of
Kong
and
have
them
connect
up
to
the
same
runtime
group
within
connect.
B
A
really
nice
feature
within
connect
gives
you
the
ability
to
not
have
to
worry
about
any
sort
of
configuration.
Migration
connect
will
understand
and
know
the
version
of
your
your
data
plane
and
send
the
correct
configuration
down
down
to
the
data
plane.
The
other
way
of
doing
it
is
a
rolling
upgrade
strategy,
with
just
a
standard
way
of
upgrading
your
data
plane
lines
like
you
would
in
your
hybrid
deployment
mode.
B
So
just
to
reiterate,
once
again,
you
know
currently
Kong
only
supports
one
minor
upgrade.
So
if
you
are
upgrading
your
traditional
deployments
or
your
dblist
deployments,
you
need
to,
unfortunately,
upgrade
one
version
at
a
time
so
going
from
Kong
2.8,
you
would
need
to
go
to
Kong,
3.0,
3.1
and
then
lastly,
3.2
and
by
the
end
of
this
week,
you
will
have
3.3
just
want
to
give
you
an
example
of
some
upgrade
strategies
within
car
within
hybrid
sorry
and
what
that
looks
like.
B
So
this
example
is
using
an
In-Place
and
rolling
strategy,
so
this
unfortunately
has
a
bit
of
downtime
with
your
control
plane.
So
if
you're
happy
with
that,
then
that
works
really
well,
but
there's
no
additional
resources
which
is
really
good.
So
how
do
you
do
this?
Well
effectively?
You
upgrade
your
control
plane
from
Kong
2
to
Kong
3.0,
and
do
the
database
changes
database
migrations?
B
Once
that's
done,
you
then
upgrade
your
data
plane
to
the
same
version
in
Kong
connect
them
all
up,
make
sure
everything
is
working
once
you've
done
that
you
can
then
upgrade
your
control
plane
to
3.1
your
data
plane
to
3.1
your
control,
planes
are
3.2
and
your
data
plane
to
3.2.
You
know
doing
this
incrementally
also
helps
to
ensure
that
if
you
do
have
errors,
you
know
which
error
or
which
version
has
caused
the
error,
and
you
know
going
to
directly
to
Kong
3.2
or
the
latest
version
of
Kong.
B
There
have
been
so
many
changes
so
actually
being
able
to
understand
where
the
issues
lie.
If
there
have
been
any
issues
becomes
quite
difficult,
which
is
why
we
recommend
this
way
of
deploying
oh
upgrading,
looking
at
hybrid
using
a
dual
cluster
deployment.
So
again,
this
gives
you
no
downtime,
but
you
need
the
additional
resources,
which
is
why
I've
marked
that
in
yellow.
So
how
do
you
do
this
well
effectively?
B
What
you
do
is
you
create
a
new
database
as
mentioned
before,
and
then
you
upgrade
your
control
plane
to
the
first
version,
and
you
do
the
the
schema
upgrades
for
that
version.
You
then
upgrade
to
three
one.
Do
the
schema
updates
update
to
three
two?
Do
that
and
then
once
you've
done,
that
to
effectively
just
deploy
a
new
version
of
your
data
planes
for
the
Target
version
that
you've
you've
ended
up
on.
So
in
this
case
Kong
3.2,
and
then
you
can
start
migrating
traffic
across
again,
because
this
is
a
dual
cluster.
B
You've
got
a
replica
of
the
configuration
and
of
your
your
your
installations,
so
you've
got
a
really
good
rollback
strategy
within
this
example.
B
Lastly,
one
that
I
wanted
to
talk
about
was
actually
the
connect
upgrade
as
well,
if
you're
not
on
on
connect.
Yet
you
know
a
precursor
to
this
would
be
to
actually
upgrade
to
connect
first
and
then,
once
you
have
upgraded
to
connect
like
mentioning
before
you
know,
what
you
would
be
able
to
do
is
effectively
connect
your
data
planes
of
one
version
into
your
runtime
group
and
then
deploy
a
second
version
of
Kong.
B
In
this
case,
your
target
version
of
3.2-
you
don't
have
to
go
through
each
of
the
versions
here,
because
connects
itself
will
manage
the
change
in
configuration.
You
can
then
Canary
release
the
traffic
across
and
once
you're
happy,
you
can
then
effectively
deprecate
or
uninstall.
Your
older
version
of
Kong
a
a
really
nice
feature
within
connect
and
runtime
groups.
This
ability
to
have
different
versions
of
your
data
planes
connected
to
runtime
groups
within
the
SAS,
offering
okay.
B
So
talking
about
that,
if
you're
not
on
connect-
and
you
actually
are
on
Enterprise-
and
you
are
wondering
about
support-
and
you
know-
maybe
how
how
this
upgrade
is
going
to
be
a
little
bit
easier
in
the
future-
you
know:
don't
don't
fret.
The
long-term
support
has
been
released
by
com.
2.8
is
long-term
supports
until
March
2025.
The
aim
is
to
do
a
one-step
upgrade
from
LTS
version
to
LTS
version.
B
B
So
what
else
do
I
need
to
consider
with
this
upgrade?
You
know
I've
spoken
about
upgrading
your
con
Gateway.
That's
probably
only
one
aspect
of
what
you
currently
use:
you've
also
got
your
crcd
pipelines,
hopefully
using
deck.
B
If
you
are,
you
need
to
make
sure
that
you've
upgraded
to
at
least
version
1.15
1.15
is
where
the
the
features
of
Kong
3
have
been
added
and
deck
then
understands
and
is
able
to
configure
that
across
so
ensure
that
you,
you
know,
upgraded
your
your
agents
if
you've
got
agents
or
images
that
you're
using
to
run
depending
on
what
CI
CD
platform
you're
using
if
you've
got
declarative,
config
stored
in
your
database,
the
schema
of
that
config
has
actually
changed.
B
So
you
will
need
to
effectively
update
the
configuration
that's
stored
if
you've
got
that
in,
like
a
repository,
deck
actually
has
a
capability
to
do
that.
There's
a
a
command
called
deck
convert,
so
you
can
actually
convert
the
declarative
config
or
have
it
as
part
of
your
pipeline
where
it
takes
the
version
to
config.
Does
a
con
a
deck
convert
on
the
Fly
and
then
syncs
that
across
to
your
configuration
but
I
think
actually
getting
what's
in
the
repository.
B
Updated
is
is
worthwhile
doing
if
you're,
using
Pongo,
as
mentioned
before,
to
test
out
your
custom
plugins
just
upgrade
to
the
latest
version
of
Pongo.
That
will
then
ensure
that
you
can
test
your
plugins
and
ensure
that
they
are
kong3
compatible.
And
lastly,
if
you're
running
the
Kong
developer
portal,
you
know
make
sure
that
you
have
effectively
once
you've
got
to
your
targeted
version.
You
have
pulled
the
latest
versions.
The
latest
sorry
versions
to
the
templates
merge
that
into
your
developer
portal
and
then
push
them
as
well.
B
So
that's
definitely
something
worthwhile
thinking.
You
can
either
do
that
via
the
GitHub
repo,
where
we've
got
the
the
portal
templates
or
using
the
portal
CLI,
where
you
can
run
a
portal
fetch
on
your
target
version
and
fetch
the
latest
template
changes
from
the
from
the
portal
so
making
all
of
those
changes.
You
know
you
probably
want
to
make
sure
you've
made
all
of
them,
and
then
you
know
you
should
be
in
a
really
good
state
to
ensure
that
you've
upgraded
Kong
to
the
latest
version
of
Kong
3..
B
So
we've
come
to
the
end
of
the
presentation.
Hopefully,
today
was
very
informative
to
everyone.
I
hope
you
learned
something
I'm
sure
there
are.
There
are
some
questions,
so
you
know
feel
free
to
reach
out
to
me
via
email
there's,
my
email
on
the
screen,
as
well
as
my
LinkedIn
profile.
B
If
you
want
to
connect
with
me
on
on
LinkedIn,
you
know
I'm
happy
to
run
through
and
have
a
conversation
with
anyone
who
has
any
questions
around
what
I've
spoken
about
today,
but
you
know
obviously
reach
out
to
the
to
Kong
themselves
as
well
or
or
even
go
on
to
the
Kong
slack
workspace
as
well.
B
You
know
I'm
on
there
too,
ask
any
of
the
questions
that
you
need,
and
you
know
myself
and
the
community
will
be
able
to
help
you
if
you've
got
any
questions
so
yep,
that's
the
end
of
the
there
I
see.
We've
got
a
number
of
questions
and
stuff
in
the
chat
in
that
Dahlia.
A
Yeah
exactly
I
was
going
to
say
thank
you
so
much
that
was
super
informative.
Let's
see
the
questions,
we
have
quite
a
few
in
the
Q
a
function.
Let's
see.
B
Okay,
so
there's
actually
two
there's
two
different
chats,
but
let
me
try.
Let
me
try
and
have
a
look
at
them
here
so
cute.
Any
answer
then
answered.
No,
so
q,
a
so
John,
Williams,
What
scenario
or
requirements
would
help
to
in
deciding
the
development
modes
hybrid
versus
Kik,
so
I
mean
I,
guess
I
I
did
talk
a
little
bit
about
that
as
well.
B
You
know
the
the
the
the
thing
about
hybrid
is
that
you
have
to
take
into
account
the
upgrading
of
your
control
plane
as
well,
but
I
think
the
data
planes
and
your
kick
data
planes
or
proxies.
They
can
follow
the
same
upgrade
strategy.
So
you
don't
have
to
worry
about
choosing
something
else
there,
but
hybrid
has
an
additional
upgrade
part
to
to
to
to
to
to
take
into
account
with
the
the
control
plane.
B
So
hopefully,
hopefully
that
has
answered
your
questions.
Is
there
backwards
compatibility
guaranteed?
There's
you
know,
Kong
follows
semantic.
Versioning
there
isn't
backwards,
compatibility
between
Kong,
3
and
kong2.
There
are
a
number
of
breaking
changes,
but
there
is
backwards.
Compatibility
within
your
minor
version
within
Kong
three
so
again
we're
following
semantic
versioning
with
major
and
minor
and
Patch,
so
the
miners
and
Patch
won't
have
any
breaking
changes
unless
we
have
explicitly
called
it
out.
B
Oh
sorry,
that's
jumping
around
Daniel
Hill
really
surprises
he
data
plane
metadata
for
connect,
Only
Winners
is
coming
to
con
Gateway.
So
the
the
metadata
yeah
really
nice
feature,
and
that's
a
really
good
ask
it
currently
is
a
feature
as
part
of
what
are
called
runtime
groups
if
you're
familiar
with
connect.
So,
unfortunately,
right
now,
runtime
groups
are
not
available
as
part
of
on-prem
ee
I
think
there
might
be
a
possibility
of
it
coming
further
down
the
road
but
you're
looking
at
maybe
next
year.
B
Edwin,
unfortunately,
we're
still
running
Cassandra.
Is
it
possible
to
migrate
easily
from
Cassandra
to
postgres?
We
tried
an
export,
but
it
errored
out
with
a
key
not
provided
we're
having
key
ring
as
well
as
their
portal
yeah.
So
yeah,
unfortunately,
you
know,
Cassandra
has
been
deprecated
now
and
Kong
is
not
supporting
it
if
you
are
using
keyring,
so
things
are
encrypted.
B
Personally,
I
I
haven't
done
a
Cassandra
to
postgres
migration,
but
if
you
are
having
issues
with
that,
Edwin
I
think
you
know
log
a
a
support
ticket
or
come
to
the
the
community
via
the
slack
workspace-
and
you
know
we
can
always
ask
that
to
the
engineering
team
and
see
if
they've
got
any
strategies
on
how
we
can
best
help
you
with
that
Francisco.
Can
we
go
from
2.5
to
the
latest
three,
or
should
we
upgrade
to
Something
in
the
mid
first
year?
B
I
should
have
mentioned
that
I
would
recommend
upgrading
to
2.8
first,
so
you
should
be
able
to
do
do
that
upgrade
in
sort
of
one
file
swoop.
There
have
been
some
break-in
changes
between
2.5
and
2.8,
so
you
will
have
to
work
on
that.
There
have
been
some
configuration
name,
changes,
I
think
it
was
around
about
2.7,
but
then
you
have
to
do
the
incremental
upgrades
version
by
version.
B
As
mentioned
already,
the
problem
with
the
one
step
upgrading
is
concave
deployed
in
a
number
of
different
ways,
and
it's
you
know
it's
almost
too
complex
to
ensure
that
every
use
case
is
actually
taken
into
account.
So
once
you've
got
to
version,
2.8
then
just
follow
the
strategies
of
doing
one
minor
version
upgrade
at
a
time
the
sea,
when
upgrading
Kong
from
version
two
to
three.
Is
there
any
considerations
regarding
plugins?
B
Yes,
there
are,
as
already
mentioned,
if
you've
got
custom
plugins,
please
have
a
look
at
the
pdk.
Changes.
That's
very
important.
The
out
of
the
box
plugins
as
well.
Some
have
been
deprecated.
Some
have
had
some
configurations
changed.
One
I
would
like
to
highlight
is
probably
the
Prometheus
plugin
so
out
of
the
box
in
Kong
3.
The
Prometheus
plugin
now
has
five
new
configuration
parameters
so
effectively
you.
It
won't
be
logging
all
of
the
metrics
out
of
the
box.
This
is
to
give
you
the
ability
to
increase
the
performance.
B
If
you
didn't
want,
if
you
don't
want
all
of
the
metrics,
you
can
effectively
turn
them
on
or
off,
but
effectively
during
the
upgrade
to
Kong
3.
You
might
all
of
a
sudden
go.
Where
are
all
my
metrics
in
Prometheus
effectively?
You
know
this
is
one
use
case
where
you
need
to
make
sure
that
you
now
are
adding
additional
configuration
to
that
plugin
so
that
you're
getting
the
metrics
that
you're
interested
pushed
into
Prometheus.
B
That's
one
example
again,
please
read
the
change
log
to
get
a
more
exhaustive
list
again
if
I
went
through
all
the
plugins
I'll
probably
need
a
session
just
for
the
plugins,
so
sorry
Francesca
any
considerations
for
existing
exposed
apis,
configured,
plugins
and
custom
plugins.
B
If
I'm
reading
that
correctly
I
guess
you're
looking
for
some
kind
of
considerations
for
upgrading
things
that
are
apparently
already
exposed,
you
know
again
make
sure
that
you
effectively
deploy
this
in
a
lower
environment,
make
sure
you've
tested
it
out
and
then,
depending
on
your
upgrade
or
your
sorry,
your
sensitivity
to
downtime
choose
which
of
the
the
upgrade
strategies
you
know
you
currently
want
to
use.
B
I'll
give
you
a
good
example:
I
actually
recently
have
tested
out
deploying
the
Kong
developer
portal
running
on
ec2,
using
Auto
scale
groups
using
terraform
and
using
a
feature
called
lifecycle
managements
within
your
terraform
Resources
with
zero
downtime.
It
deployed
a
new
ec2
instance.
You
know
brought
them
up
made
sure
that
they
were
running
and
then
effectively
behind
the
scenes
to
swap
the
auto
scale
groups
under
my
load.
Balancer-
and
you
know,
I
was
testing
it
out,
got
zero
downtime.
So
there
definitely
are
strategies.
B
You
know
bringing
it
into
your
infrastructure
as
code
systems
that
you
can.
You
can
effectively
deploy
things
that
are
currently
being
run
with
there
being
zero
downtime,
but
again
make
sure
you've
tested
this
in
lower
environments
to
ensure
that
everything
will
go
smoothly.
When
you
do
your
production
release,
Chuck
plan
carry
fly,
clarify
what
very
large
is
with
regards
to
numbers
of
routes.
Hundreds
thousand
cents
very
good
question,
I
would
probably
say
large,
is,
is
in
the
thousands.
B
So
when
you
get
to
you,
know
sort
of
maybe
around
between
five
and
ten
thousand
Kong
entities,
so
an
entity
is
anything
from
a
service
route
or
a
plug-in.
All
of
it
contributes
towards
the
size
of
the
configuration.
So
when
you're
getting
into
the
thousands,
that's
where
you
know
you'll
need
to
be
tweaking
things
when
you're
sort
of
down
in
the
lower
hundreds
you'll,
probably
be
fine,
as
is
but
again
depending
on
your
use
case.
You
need
to
make
sure
that
you
are
testing
it
in
your
lower
environments.
B
Anonymous,
router
or
router
flavor
is
not
included
in
three.
So
how
is
it?
How
is
it
then
possible
to
migrate
I?
Think
you
mean
in
two:
if
you
need
to
migrate
your
roots
and
have
regex
thinking
about
yeah
so
effectively.
What
happens?
Is
you
know
when
you
migrate
to
Kong
three,
the
Kong
migration
script
to
migration?
Up
and
finish
it
will
do
the
migration
of
your
regex
routes
to
ensure
that
they
are
picked
up
by
the
new
Kong
router
Kong
3
does
have
the
router
flavor
parameter
I'm.
B
Setting
that
to
like
I
said
traditional
compatible
is
the
way
to
go
with
your
first
deployment
from
two
to
three
so
yeah
you,
you
should
be
fine
in
doing
that
and
then
once
you're
on
Con
3.
You
know,
then,
just
migrates
all
the
way
up,
leaving
that
router
flavor
to
the
same
value.
B
Why
you
consider
going
from
2A
to
three
a
minor
version
upgrade.
Isn't
there
a
two
nine
good
question
currently
right
now
there
isn't
a
two
nine.
There
are
still
patch
versions
that
are
coming
into
into
Kong,
2.8
I.
Don't
think
there
is
a
2.9
schedule,
I
understand
going
from
2A
to
3.0,
isn't
a
minor
upgrade,
but
it
is
a
major
version,
but
it
is,
you
know
effectively
the
when
you
do
a
major
version.
B
You
need
to
go
to
the
version.0
of
that
major
version,
and
that
is
supported
within
the
the
upgrade
strategy.
Hopefully,
that
makes
sense
I'm
on
Kong
version.
2.5,
which
versions
are
upgraded
first
Francesco,
like
I,
said
I
would
upgrade
to
2.8,
so
the
latest
2.8
first
and
then
once
you're
on
2.8
I
then
upgrade
to
three.
After
that
John
Williams,
when
upgrading
on
the
hybrid
mode.
B
How
does
the
control
plane
upgrade
does
not
impact
the
data
pane
runtimes?
No
again,
you
know,
because
your
data
planes
don't
need
to
be
connected
to
your
control
plane
to
actually
serve
traffic.
You
know
the
the
control
plane
upgrade
won't
affect
your
data
planes.
They
will
still
be
able
to
run
on
the
last
the
last
known
configuration,
so
that
should
be
able
to
help
you
help
you
there
has
come
3.x
been
open
sourced.
B
Yes,
the
open
source
version
of
Kong
3
is
available.
I
know
it
did
talk
a
lot
about
Enterprise
and
Enterprise
features,
but
kong.3
is
there.
There
are
a
lot
of
capabilities
that
are
there
as
well.
I
would
follow
the
same
upgrade
strategy
with
Kong
open
source
as
well:
okay,
Francesco
and
then
that's
based
on
the
upgrade
documentation.
We
can
go
from
two
to
three
to
one
directly.
Are
there
any
concerns
to
this
upgrade?
B
Why
do
you
recommend
so
there
have
been
some
changes
and
I
know
you
have
linked
to
there.
There
have
been
some
changes
to
the
con.
The
the
documentation
I've
been
advised
to
recommend
going
to
3.0.
First
again,
it's
very
based
on
your
use
case.
If
you've
got
a
very
simply
a
simple
deployment
of
Kong,
you
could
probably
go.
You
know
from
3.0
from
2.8
to
3.1,
but
I
recommend
doing
it
in
a
methodical,
upgrade
strategy
and
it'll
ensure
that
you,
if
you
do,
have
any
any
issues
at
each
upgrade.
B
You
then
are
it's
easy
to
work
out.
What
has
gone
wrong
for
you
to
then
fix
that
to
then
effectively
move
on.
So
that's
all
the
Q
and
A's.
Hopefully,
oh
we've
got
a
new
one
from
Anonymous
we're
on
2.7
plan
to
switch
from
on-prem
to
hybrid
I.
Guess
you
mean
a
traditional?
B
Would
you
suggest
to
upgrade
first
to
make
the
switch
to
hybrid,
first,
very
good,
question
yeah
I
think
effectively,
maybe
I'm
upgrading
to
2.8
first
getting
that
out
of
the
way
and
then
switching
to
hybrid
might
be
the
might
be
the
best
way
to
do
it.
There's
less
things
to
to
worry
about.
B
You
know
you
then
only
have
to
update
or
upgrade
one
node
rather
than
your
control
planes
and
your
data
planes
so
it'll
be
a
lot
less
for
you
to
upgrade.
If
you
do
first
from
your
versions
to
2.8
and
then
do
traditional
to
hybrid
after
that
cool,
that's
all
the
Q,
a
I
know
we're
starting
to
run
out
of
time
Dalia.
B
There
might
be
a
couple
of
questions
in
the
chats
as
well.
Let's
see
here
saml
for
Kong
3
manager.
Let
me
actually
3.1
I.
Think
I
actually
mentioned
that.
Let
me
go
back.
Let
me
close.
This
go
back
in
my
slides.
B
I
know
there
has
been
talk
of
it.
Oh
there
was
Samuel
here,
I
think
it
was
the
I
think
it
was
the
saml
3.0.
It's
a
saml
plug-in
so
I,
don't
know
whether
the
the
there
is
with
the
Kong
manager,
but
it's
something
we
can
have
a
look
up.
David
and
and
I
can
check
with
you
to
be
honest.
Most
of
my
customers,
you
use
oidc
for
doing
their
platform.
Authentication.
B
All
right,
let's
upgrade
okay,
I,
think
a
lot
of
these
were
in
the
Q,
a
reasons
behind
the
migration
to
Debian
or
Ubuntu,
based
images
so
yeah
effectively.
What
the
reason
for
that
is.
B
It
was
the
deprecation
of
Alpine
and
effectively
a
lot
of
the
libraries
that
com
needed
to
actually
install
Kong
weren't
part
of
the
Alpine
image
and
just
to
help
Kong.
You
know
when
it
comes
to
security
vulnerabilities.
They
don't
want
to
have
to
also
manage
operating
system
vulnerabilities,
but
just
vulnerabilities
that
affect
Kong
itself
so
going
to
Debian
was
the
the
best
direction
for
them.
Debian
comes
packaged
with
everything
that
Kong
needs
to
to
be
installed.
B
You
know
when
it
comes
to
your
images,
make
sure
you're
building
your
own
golden
images.
Kong
is
there
to
manage
the
security
vulnerabilities
for
Kong
itself
and
not
the
operating
system
of
vulnerabilities.
You
know
that
needs
to
be
something
for
yourself
to
take
care
of
latest
documentation
for
Pongo.
B
B
Okay,
I.
Don't
think
that
was
a
question,
that's
management,
that
is
what
version
of
ee
in
order
to
upgrade
to
connect
good
question,
so
actually,
I
I
would
get
on
to
2.8
at
least
to
get
to
connect,
and
then
there
will
be
a
mechanism
to
convert
your
config
using
deck
into
a
a
a
connect
format.
To
then
push
that
into
connect
so
get
on
to
2.8
for
sure
to
do
that
cool.
That's
all
the
questions.
A
Thank
you
so
much
and
thank
you
everyone
for
joining.
It
was
a
pleasure
having
you
I
hope.
This
was
useful
for
you.
Our
next
user
call
is
on
June
13th.
You
can
find
the
link
here
and
I
hope
to
see
you.
There
have
a
great
evening
great
day
and
see
you
soon.
Thanks.