►
From YouTube: Webinar: How to migrate databases into Kubernetes?
Description
Deploying databases like Postgres and MySQL into Kubernetes can be challenging, see how declarative configuration can make your life easier enabling self-service storage provisioning for your stateful workloads. We will show a live example of how to migrate databases from a standalone server to a Kubernetes cluster.
You will learn:
– How to deploy databases in production in Kubernetes
– How to implement automatic failover with high availability
– How to migrate a database into a Kubernetes cluster
– How to build a database as a service with Kubernetes
This webinar is ideal for anyone looking to move stateful workloads like databases into Kubernetes.
Presenters:
Alex Chircop, CEO & Founder @StorageOS
Ferran Castell, Product Reliability Engineer @StorageOS
A
So
good
morning,
good
evening,
good
afternoon,
depending
on
where
you
are
in
the
world,
thank
you
for
joining
today's
cncf
webinar
I'd
like
to
thank
you
all
for
joining
us.
Today's
webinar
is
how
to
migrate
databases
into
kubernetes,
I'm
christy,
tan
and
I'll,
be
moderating
today's
webinar.
We
would
like
to
welcome
our
presenters
today,
alex
cherkov,
ceo
and
founder
of
storage
os
and
for
ron
castell
pro
product
reliability,
engineer
at
storage
os
a
few
housekeeping
items
before
we
get
started
during
the
webinar.
A
A
A
B
Thank
you,
kirsty
and
good
morning,
good
afternoon
and
good
evening,
depending
where
you're
dialing
in
from
so
a
little
bit
about
myself.
My
name
is
alex
kirkup,
I'm
the
founder
and
ceo
of
storage
os.
I
also
hold
two
hats
and
I'm
the
co-chair
of
the
cncf
storage
sig
and
I
am
very
focused
on
on
building
cloud-native
storage
solutions
at
storage
os.
B
C
B
Brilliant
thanks
both
so
before
we
start.
I
just
want
to
give
you
a
bit
of
background
on
on
storage
os
where
we
come
from.
So
at
storage
os.
We
are
building
cloud
native
platforms
for
customers
and
users
who
are
who
are
running
platforms
in
the
clouds
on
prem
or
in
hybrid
environments.
So
one
of
the
things
we
come
across
very
often
is
customers
wanting
to
run
databases
in
kubernetes,
so
we're
going
to
share
some
of
the
experiences.
B
As
I
mentioned,
I've
also
got
my
other
hat,
so
I'm
going
to
do
a
little
bit
of
sick
advertising
here.
The
the
cncf
storage
sig
is
a
is
a
public
group.
It's
it
works
with
the
cncf
toc
team
and
we
help
create
content
for
end
users
as
well
as
review
projects
and
provide
technical
storage
expertise
to
the
sig
to
the
to
the
toc.
The
calls
are
open
and
are
open
every
second
or
fourth
wednesday
of
the
month.
B
So
we'd
love
to
see
you
there.
Okay,
so
I
talked
about
what
we're
seeing
in.
In
our
end
users,
communities.
Of
course
everybody
begins.
Their
client
native
journey,
typically
with
with
containers
and
containers,
changed
the
the
have
changed.
The
container
landscape
have
changed
the
application
landscape
because
they've
broken
the
dependencies
between
an
application
and
an
individual
specific
server.
So
this
concept
of
of
cattle
versus
pets
which
which
we
hear
about
quite
a
bit
containers
allow
applications
to
be
portable
and,
of
course,
the
minutes.
B
Applications
are
portable,
they
can
be
orchestrated,
and
this
is
where
kubernetes
comes
in
so
kubernetes
being
that
container
orchestrator
allows
allows
developers
to
be
able
to
compose
and
declare
what
they
need
out
of
their
applications
by
defining,
for
example,
compute
requirements
or
or
network
requirements
and
kubernetes.
I
guess,
plays
like
an
expert
tetris
game
with
your
applications
to
abstract
away
your
infrastructure
and
fit
the
applications
in
the
in
the
most
efficient
way
to
the
to
the
available
resources
and,
of
course,
because
it
has
the
automation,
it
can
do
lots
of
advanced
services.
B
So
one
of
the
one
of
the
key
things,
one
of
the
key
things
with
with
kubernetes
and
and
cloud
native
storage,
relates
to
the
this
key
concept
that
the
containers
and
the
applications
are
portable.
So
in
this
case,
when
I
refer
to
an
application,
I'm
talking
about
your
database
because
every
type
of
database
is
is
now
mostly
available
as
as
a
container
too.
So
you
know
popular
databases
like
postgres
or
or
mysql,
for
example,
as
well
as
databases
like
say,
or
cassandra.
B
B
One
of
the
key
things
here,
though,
is
that
those
applications,
those
those
databases,
are
inherently
portable
and
they
benefit
from
the
ability
for
kubernetes
to
dynamically
scale
out
and
scale
down
a
cluster
and
to
be
able
to
upgrade
nodes
on
the
fly,
whether
it's
because
you
want
to
upgrade
the
resources
of
nodes
or
you
want
to.
You-
want
to
upgrade
nodes
for
for
to
make
sure
that
software
is
current
and
security
patches
are
applied,
for
example.
B
We
talked
a
lot
about
the
fact
that
in
kubernetes
the
environments
are
declarative
and
reproducible.
So
what
do
we
mean
by
that?
Well
in
much
the
same
way
that
you
can
specify
the
containers
that
are
needed
in
this
case
the
database
and
then
the
compute
and
memory
and
network
requirements?
You
can
also
declare
the
storage
requirements
and
items
like
scaling
or
availability,
for
example,
and
the
reason
why
this
is
so
incredibly
powerful
is
because
it
makes
your
environment
recoverable
and
reproducible
so
you're.
B
B
So
we
talked
a
bit
about,
we
talked
a
bit
about
how
that
dynamic
provisioning
works
so
I'll,
give
you
a
little
example
of
what
we're
referring
to
specifically
for
a
database.
So,
within
a
database
we
start
off
with
a
storage
class.
A
storage
class
is
a
way
to
abstract
away
the
the
definition
for
accessing
a
storage
provider
that
kubernetes
is
going
to
talk.
B
B
For
for
the
purposes
of
of
this
particular
webinar,
and
this
example,
where
we're
restricting
ourselves
to
providing
examples
that
are
related
to
starting
a
database
using
a
simple
pod
or
a
stateful
set,
and
that's
mostly
for
for
simplicity,
but
for
for
completeness
sake.
I'm
I'm
mentioning
the
fact
that
you
know
operators
are
available
for
most
types
of
databases
to
provide
that
database
lifecycle.
B
B
The
the
point
that
I'm
wanting
to
emphasize
here
is
that
most
of
this
definition
is
now
very,
very
server-centric
and
it's
based
on
a
scale-up
architecture
which,
which
obviously
gets
more
expensive,
based
on
based
on
the
the
capacity
of
those
of
those
individual
servers,
but
more
than
that,
the
the
functionality
becomes
becomes
operationally
more
complex
and
and
prone
to
failure.
Simply
because
of
the
fact
that
that
we're
talking
about
running
multiple
databases
within
within
that
large
instance.
B
B
B
We
can
then
continue
to
break
out
the
additional
kubernetes
that
destroy
the
additional
postgres
databases
into
their
own
mini
instances,
effectively
making
them
portable
standalone
products
that
can
be
distributed
across
the
different
nodes
in
the
cluster
so
so
effectively.
We're
we're
we're
using
the
the
functionality
of
of
kubernetes
to
turn
each
database
instance
into
a
declarative
self-contained
container.
B
B
So
just
summarizing
databases
are,
of
course,
stateful
workloads
and
in
order
to
take
real
advantage
of
these
kubernetes
workloads
and
kubernetes
environments,
it's
important
that
that
you
are
able
to
apply
the
same,
declarative
construct
and
composable
construct
that
you
apply
to
your
to
your
applications
to
to
the
stateful
workloads.
To
like
databases.
B
Other.
A
couple
of
other
aspects
that
I'd
like
to
cover
is
that
by
splitting
out
each
database
instance
each
database
into
into
its
own
separate
containerized
database
instance.
We
have
better
performance
and
better
throughput,
typically,
because
kubernetes
can
now
balance
the
loads
more
effectively
into
into
multiple
instances.
B
We
have.
We
have
the
concept
that
each
one
of
those
database
instances
can
be
tuned
and
resources
allocated
individually
per
database,
so
so
you're
not
having
to
to
worry
about
one
large
instance
for
multiple
databases
and,
of
course,
by
by
having
by
scaling
outwards
only
rather
than
focusing
on
a
vertical
scale.
Up
with
kubernetes.
B
Failing
all
right.
So
with
that,
I'm
going
to
pass
on
to
I'm
going
to
pass
the
battle
on
to
to
furan
who's
going
to
give
us
a
live
demo
talking,
providing
a
demo
to
show
us
how
to
actually
move
a
database
from
a
standard
server
into
kubernetes.
So
this
is
probably
the
exciting
part
of
the
of
the
environment
and
I'll
pass
over
to
right.
Now,
I'll
stop
showing
my
screen.
C
Thank
you
alex
I'll
start,
sharing
mine,
second
great
cool,
so,
as
alex
mentioned,
we're
going
to
go
into
a
live
demo.
First
of
all,
let
me
give
you
a
bit
of
introduction
what
we
have.
We
have
a
kubernetes
cluster
four
nodes
in
google
cloud
could
be
somewhere
else,
but
google
cloud
is
is
as
good
as
as
any
other
and
we're
gonna
do
actually
what
alex
explained
about
sending
the
main
data
a
main
database
into
multiple
ones
in
kubernetes,
so
we
have
one
main
server
with
postgres.
C
So,
let's
have
a
look:
we
can
see
actually
that
we
have
multiple
databases,
those
databases
or
schemas.
I
created
with
ordinal
numbers
those
databases
for
simplicity,
so
we
actually
can
see
what
we
are
migrating,
but
keeping
keep
in
mind
or
try
to
understand
that
this
is
something
that
we
are
creating
a
database
for
each
micro
service
or
for
each
component
of
our
application
or
for
each
part
of
our
holding
our
company
et
cetera.
So
there
are
different
ways
of
distributing
how
our
data
is
stored.
C
C
We
keep
them
separate
by
the
way
everything
I'm
going
to
use
today
is
available
in
github
and
we're
going
to
share
the
links
for
for
the
yamas
etc,
and
I
want
to
encourage
that
everything
you
see
today
is
something
that
I
highly
recommend
to
using
to
see
icd
environments,
so
we're
going
to
do
it
by
hand.
So
you
actually
can
see
what
is
under
the
hood
or
in
the
kubernetes
constructs.
But
you
use
you,
you
would
use
a
ci
cd
or
junking
server.
C
Whatever
tool
you
prefer
to
actually
run
those
automations,
it
will
make
your
life
way
way
easier.
So,
first
of
all,
I'm
going
to
deploy
a
postgres
server
on
every
single
one
of
these
namespaces,
so
we're
going
to
have
10
databases
or
10
instances
of
postgres
itself
to
do
so.
I'm
going
to
use
these
yamus
that,
as
I
said,
they're
in
a
github
repository
completely
public
and
and
then
we're
gonna
migrate.
The
data.
C
C
C
They
said
this
is
a
coordinate
controller
that
will
enforce
in
our
case,
to
have
one
instance
of
the
application
always
running.
We
are
using
a
fairly
standard
or
fairly
common
postgres
instance
and,
very
importantly,
we're
going
to
mount
a
volume
into
pg
data
into
slash
pg
data.
That
is
where
postgres
will
write
the
data.
If
you
want
to
use
and
split
the
write
ahead,
log
and
all
other
components
that
postgres
allows
for
speed
or
whatever
you
can
do
that
here
create
different
volumes,
because
this
is
the
clarity
it's
very
easy
to
just
provision.
C
Your
volumes,
where
are
the
volumes
coming
from
these
volumes,
are
coming
from
a
template
that
template
is
a
persistent
volume,
claim
template
so
for
every
application.
For
every
part
that
this
controller
starts,
it
will
have
one
persistent
volume
claim
always
associated
to
it
in
this
case,
we're
just
referencing
the
storage
class
that
we
want
to
use
for
our
for
our
software
defined
storage
backend,
but
there
are
actually
different
ones
in
this.
C
C
So
we
have
multiple,
there
are
two
of
them
that
are
software
based,
and
there
is
one
actually
that
is
the
the
world
cloud
volumes,
so
you
can,
and
actually
you
can
add,
more
and
create
different
storage
classes
that
will
actually
have
different
capabilities
or
options
for
for
your
specific
use
cases.
Now,
let's
actually
have
a
look
at
the
pods
that
we
have
created,
I'm
going
to
use
k,
n
s
which
actually
is
very
cool
tool
for
for
live
information.
C
We
can
see
that
for
every
namespace
there
is
one
bot
one
possible
spot
for
every
single
one
of
those
microservices.
So
now
every
microservice
can
have
its
own
database
cool
every
one
of
those
databases
have
a
volume
associated,
let's
say
up
three
to
say
something
get
bbc
and
we
can
see
that
there
is
a
pvc
associated
to
it.
So
now
we
have
10
instances
of
postgres
running
and
they
have
10
volumes
associated
to
each
other
cool.
Now
we
have
postgres
running,
we
have
the
main
server
running
now,
let's
run
the
migration.
C
C
C
There
is
one
thing
that
we
actually
need
to
have
before
we
do
the
the
import
itself,
and
that
is
a
way
to
connect
our
postgres
servers,
our
many
instances
into
kubernetes
to
the
main
server.
We
do
that
using
this
external
service,
it's
a
standard
ammo
if
you're
not
familiar
with
external
services
with
kubernetes.
Don't
worry
too
much
just
for
context.
What
we
are
doing
is
we
are
telling
kubernetes
that
there
is
an
ip
that
we
want
to
access
from
inside
the
cluster,
but
we
want
to
give
it
a
name.
C
C
So
we
see
the
endpoints.
Actually,
it's
mapped
to
a
specific
ap,
where
my
postgres
server
is
running
cool.
This
is
important
because
when
we
want
to
do
things
from
an
automated
point
of
view,
we
want
to
change
configuration
while
we
don't
have
to
change
anything
else.
So
how
are
we
going
to
run
the
migration
I'm
going
to
use
a
job?
A
job
is
a
kubernetes
construct
or
kubernetes
controller
that
will
execute
my
container
or
in
this
case
my
task
once
what
this
task
does
is
a
simple
pg
dump
and
pipe
to
pg
restore.
C
Of
course,
if
you
have
big
databases,
I
have
small
databases
today,
but
if
you
have
big
databases,
you
can
add
the
size
of
the
migration
in
here
or
the
size
of
every
chunk
of
data.
That
is
migrated.
So
you
can
control
a
bit
of
the
the
flow
on
on
the
data
and
be
more
sophisticated
with
that.
But
essentially
it's
very
simple.
There
is
a
source,
a
source
and
a
destination
where
these
source
and
destination
variables
come
from.
C
The
content
map
itself
is
again
it's
quite
simple:
we
have
a
database.
This
is
only
one
database,
so
we
will
have
to
use
some
templating
and
some
or
patching
to
be
able
to
specify
the
source
database
that
we
want
to
migrate,
user
and
password,
of
course,
use
secrets
for
this.
This
is
just
a
demo,
the
source
and
the
destination,
and
this
is
very
important.
The
source
and
destination
are
those
dns
names.
I
was
mentioning
before
the
source.
Is
this
external
name
that
points
to
the
main
postgres
server
while
destination?
C
Is
the
name
of
the
pot
dot
the
service,
because
I'm
using
a
stateful
set
along
a
headless
service,
which
is
a
service
that
goes
along
with
the
stateful
sets?
I
can
always
access
my
application
with
the
same
name
podname.servicename,
because
this
spot
will
run
in
the
same
name
space
as
every
database.
C
C
C
Of
course
you
can
use,
for
instance,
customize
or
hum
or
any
tool
that
you
find,
or
you
prefer
for
your
own
templating.
I
just
want
to
keep
it
simple
and
on
the
other
hand,
you
can
do
that
from
a
cicd
point
of
view
very
easy
to
do
that.
You
have
your
applications
or
microservices
listed
you
simply
iterate
over
them,
and
you
tell
every
configuration
or
every
application
which
configuration
has
to
apply.
C
Well,
they
are
created,
let's
go
and
keep
looking
at
the
real-time
information.
We
can
see
that
the
populate
itself
you
can
see
there
are
different
ones
and
for
every
name
space
we
keep
having
one
actually,
because,
obviously
the
data
is
quite
small,
they're
finishing
fairly
fast.
Let's
have
a
look
at
the
logs
of
of
one
of
them,
let's
say
up
six
blocks
and
we
can
see
simple
pg
restore
restoring
our
data
that
database
my
data.
So
now,
let's
go
into
one
of
the
applications
themselves.
C
C
We
have
the
same
data
as
before,
something
for
the
trivial
it's
just
a
pg
restore
in
our
case,
which
is
restored,
is
not
blocking
so
for
prediction
is
pretty
alright.
For
other
databases,
like
my
sql,
if
you
use
my
sql
down,
be
careful
because
that's
blocking
there
are
different
tools
so
adapt
to
your
your
specific
use
case
as
as
always
in
engineering,
we
have
to
always
find
the
best
solution
for
our
use
case,
not
for
every
someone
else's
use
case
so
pretty
much.
C
We
have
now
10
databases
with
their
own
applications
and
they
are
segmented,
so
we
just
migrated
in
a
matter
of
for
10
minutes.
While
I
was
talking
databases
from
one
big
instance
that
can
be
difficult
to
maintain
difficult
to
upgrade
to
multiple
databases
where
their
concern
is
split.
Let's
say
that
app.
One,
for
instance,
is
very
intense
on
reits.
C
That
application
that
database
can
be
scaled
for
reads
can
be
improved
to
scale
better
for
reads:
let's
say
we
cannot
read
replicas
or
we
can
scale
the
size
of
that
stateful
cell
or
the
pot
itself
to
scale
horizontally
to
make
it
bigger,
or
we
can
specify
different,
different
different
configurations.
Well,
maybe
app2
has
a
different
concern,
for
instance,
is
a
microservice
for
user
logins,
where
latency
is
not
as
important,
but
consistency
is
really
really
highly
important.
Backups
doesn't
have
to
be
the
same
time.
We
have
different
concern.
We
have
different
tuning
options.
C
We
can
improve
our
availability
and
actually
the
blast
radius
of
that.
The
our
databases,
if
our
main
big
instance
of
postgres,
goes
down
even
it's
a
cluster
itself.
If
we
have
a
problem
with
that
cluster,
we
will
end
up
with
a
situation
where
all
our
information,
all
our
services,
are
done
with
this
model.
Of
course
it
has
caveats.
There
is
an
overhead
of
running
a
database
that
depends
on
your
use
case
and
how
you
want
to
split
that
you
will
have
a
better
scalability
and
a
better
micro
service
architecture,
in
my
opinion,
at
least
cool.
C
B
That's
fantastic
thanks.
So
much
faran
we've
had
a
few
questions
come
in,
so
we
can.
We
can
go
through
them.
One
olivier
asked
if
we
can
share
the
the
repo
that
we're
using
for
the
for
the
use
case.
So
perhaps
if
you
can
send
that
to
the
chat
window
and
now
and-
and
I
can
mention
that
we
also
had
a
question
around
what
is
the
opinion
about
local
pv
for
for
postgres,
with
replicas
such
as
crunchy
or
with
stolen
implementation?
B
So
this
is.
This
is
a
question
that
that
comes
up
that
comes
out
fairly,
often
right.
We
we
often
we
often
have
a
discussion
about
the
pros
and
cons
of
of
different
instances
effectively.
If
you
are
thinking
of
a
database
like
postgres
availability
can
be
done
at
the
postgres
level
with
replication
at
the
database
level.
It
can
also
be
done
at
the
storage
level,
or
perhaps
it
can
be
done
with
with
both
the
each
each
of
those.
B
Each
of
those
options
has
perhaps
different
use
cases
so
using
a
local,
a
local
pv,
which
is
effectively
a
disk.
That's
only
available
on
an
individual
node
means
that
that
postgres
instance
is
is
very
tightly
coupled
to
that
to
that
node
and
it
does
make
services
like
like
failover,
a
bit
more
a
bit
more
complicated.
If
the
disk
on
that
particular
node
is
fails,
it
means
that
that
it's
not
straightforward
to
move
the
database
to
another
node.
B
B
On
the
flip
side,
if
you're
using
a
storage
system,
that's
providing
storage
level
replication,
you
know
and
again
there
are
a
number
of
different
options.
How
to
do
that?
You
tend
to
have
better
portability,
so
databases
can
database
instances
can
move
around
horizontally
across
the
different
nodes
within
the
cluster
and
additionally,
you
have
you
have
the
benefit
that
you
have
an
extremely
low
recovery
time.
B
So,
for
example,
if
you
have
a
very
small
database
and
you're
doing
database
level
replication,
then
if
a
database
fails,
it
might
be
quite
quick
to
to
to
sync
up
another
replica
of
the
database,
but
if
the
database
is
large
that
you
know
creating
another
replica
instance
of
database
could
could
take
a
long
time
and
and
potentially
that
impacts
performance.
You
know
from
from
a
disk
and
from
a
network
resource
point
of
view,
while
that
recovery
is
happening.
C
B
It
is
a
good
question,
so
the
answer
is,
it
depends
and
I'll
I'll
I'll
I'll
sort
of
expand
on
that
slightly.
So,
in
the
past,
we've
often
thought
of
the
attributes
of
the
storage
system
in
terms
of
how
the
access
method
for
that
storage
system
is
defined
right,
so
san
being
sort
of
block
based
devices
or
nas
being,
for
example,.
C
B
File
system
based
device
or
or
das,
being
directly
attached
storage
to
an
individual
node.
The
reality
is,
though,
in
in
a
kubernetes
type
environment.
We
have
a
lot
more
layers
to
a
storage
system.
So
I
guess
the
important
thing
to
understand.
First
is
what
are
the
attributes
of
your
database
or
your
application?
B
Often,
databases
may
not
necessarily
be
may
not
necessarily
be
optimized
for
throughput,
but
they
probably
are.
They
probably
do
require
lower
latency
if,
if
they
are
to
handle
transactional
performance,
for
example,
and
and
also
databases
typically
have
storage
attributes
that
require
strong
consistency
for
for
data
integrity
and
strong
data
durability.
B
So
one
of
the
things
that
that
changes
quite
quite
dramatically
in
in
cloud
native
world
is
that
because
of
those
layers,
it's
no
longer
safe
to
assume
that
the
way
you
consume
the
storage,
say,
fire
a
block,
a
distributed
block
system
or
or
say
a
fire
system
is
defines
the
attributes
such
as
performance
or
or
latency.
Because,
for
example,
we
see
file
systems
that
are
sometimes
built
on
top
of
object
stores.
C
There
is
a
question
talking
about
the
size
of
the
persistent
volume
in
the
context
of
databases
in
kubernetes.
That
is
definitely
a
situation
where
it's
not
easy
to
to
know
which
kind
of
size
you
want
to
put.
Obviously
persistent
volume
claims
are
declarative
and
when
they
are
declarative,
you
have
to
set
them
at
bootstrap.
So
when
you
create
the
pvc
you
set
that
image
that
size.
Of
course,
you
don't
know
how
it
grows.
C
So
if
your
database
runs
out
of
the
space
because
you
put
25
gigs
and
it's
not
enough,
most
of
or
or
I
would
say
most
but
some
of
the
the
solutions,
mostly
the
the
software
defined
storage
solutions,
allow
resize
of
pvcs.
So
it
couldn't
really
be
a
problem
for
that.
Of
course,
the
answer
is:
it
depends
on
the
size
of
your
database
and
your
data
for
each
state
for
for
each
data
set,
but
in
the
end
you
can
just
resize,
based
on
on
the
storage
provider,.
B
C
Yeah
100
the
what
we
did
today
was
no
more
than
connecting
one
application
to
another.
We
didn't
care
about
the
infrastructure
we
just
needed.
Obviously
the
plumbing
of
or
the
network
in
between.
So
as
soon
as
your
kubernetes
cluster
can
access,
whether
if
you
have
a
vpn
access
in
between
instances,
they
are
in
the
same
subnets
or
they
are
visible
through
the
network
from
your
bare
metal
through
vpn,
for
instance,
to
a
cloud
environment
or
wherever
it
is.
C
You
can
just
come
here
one
of
these
databases
to
pull
that
data
to
replicate
from
from
that
master.
From
a
podcast
point
of
view,
that's
not
problematic.
Actually,
it's
fairly
easy.
It's
a
synchronous
when
it's
ready,
it's
ready.
The
only
thing
you
have
to
do
is
set
up
the
configuration
we
created
a
conflict
map.
C
While
I
didn't
show
the
conflict
map
today,
but
when
we
created
stateful
set
to
create
the
application
itself,
the
the
podcast
application
that
has
a
conflict
map
which,
in
there
you
can
specify
all
the
configuration
and
you
can
configure
there
a
slave
or
or
more
commonly
called
a
a
passive
instance
of
a
master.
So
I
could
highly
recommend,
though,
if
you
do
that,
and
you
have
higher
latencies
more
than
five
six
milliseconds
to
do
a
synchronous
and
to
do
a
transaction
log
replication
through
postgres,
for
instance,
is
good
enough
for
that.
B
Brilliant
thanks
for
anne
we've
also
had
a
follow-up
question
on
the
database
sizing.
The
the
question
is
about
what
is
the
recommended
size
of
database
storage
to
be
effective
in
in
a
kubernetes
database?
I
think
that's
that's
a
fairly
open-ended
question.
I
don't
think
you
know
there
is
a
specific
size
that
we
would
necessarily
recommend
it.
It
can
be
as
small
as
a
a
few
gig
all
the
way
up
to
you
know
several
terabytes
based
on
you
know
the
actual
size
of
your
database.
B
However,
that
said,
one
of
the
things
that
is
worth
understanding
is
again
how
size
translates
to
the
different
attributes
within
within
your
storage
system.
So,
for
example,
depending
on
the
storage
provider,
you
may
you
might
find
that
perhaps
there
are
iop
thresholds
or
input
output,
operation,
thresholds
or
or
megabyte
per
second
throughput
thresholds
that
are
correlated
to
the
to
the
size
of
the
volume.
So
so
sometimes
you
may
find
yourself
having
to
over
provision
the
size
of
the
volume
to
ensure
that
you
have.
C
B
B
So
so
storage
os
will
will
largely
coexist
with
additional
workloads
which
are
running
on
the
cluster
and
and
typically,
it's
often
deployed
in
a
hyperconverged
type
of
topology,
where
nodes
are
used
to
provide
storage
to
the
pool,
but
also
for
those
nodes,
also
run
the
same
applications
that
that
run
on
the
pool.
Of
course,
the
amount
of
cpu
that
any
storage
system,
utilizes
will
be
will
be
tied
to
the
actual
amount
of
activity.
B
B
B
Storage
are
actually
deployed
as
a
container
and
providing
storage
to
to
a
cluster.
That
way,
I
think
the
answer
to
this
to
this
question
is
in
terms
of
does
container,
attach
storage,
lend
itself
to
databases.
The
answer
is
obviously.
Yes,
there
are
a
number
of
cncf
projects
you
know
like
like
longhorn,
which
which
falls
into
this
category
as
well.
As
you
know,
a
number
of
different
vendor-supported
projects
like
storage,
os
that
work
in
this
method
and
effectively
create
volumes
out
of
the
available
storage
on
individual
nodes
within
within
the
cluster.
B
So,
yes,
I
think
it
is
a
particularly
good
fit
for
databases.
It's
a
very
common
use
cases,
things
like
databases
and
and
maybe
message
queues
are-
are
one
of
the
most
common
use
cases
in
terms
of
stateful
workloads
that
move
into
kubernetes
first
and
a
lot
of
the
services
offer
some.
You
know
more
advanced
functionality
like
which
we
haven't
talked
about
today,
but
things
like
affinity
and
locality
which
which
provide
additional
benefits
to
to
databases
within
within
the
kubernetes
environment.
B
C
C
Let
me
let
me
re-ask
the
question
a
lot:
is
it
possible
to
run
postgresql
cluster
like
primary
replica
setup
in
kubernetes,
also
hollow
balance
and
sharing
working
kubernetes
kubernetes?
I
would
say
that
is
no
different
from
running
that
in
a
different
server.
What
happens
is
that
you
have
an
orchestrator
that
will
leverage
the
startup
of
applications
anywhere
in
the
cluster
real
fast
and
that's
that's
fantastic.
You
no
longer
have
nodes
tied
to
applications.
C
C
In
fact,
because
kubernetes
gives
you
the
networking
interface
and
the
dns
itself
is
actually
very
easy
to
configure
primary
replicas
or
read
replicas
or
active
passive
model,
I
actually
would
say
regret
because
it's
easy,
active
passive
use,
a
storage
system,
because
that
will
be
way
more
difficult
and
it's
done
for
you,
so
you
don't
actually
need
to
do
so.
When
we're
thinking
about
primary
replicas,
you
can
configure
very,
very
easy,
a
service
that
is
for
the
primary
and
then
another
service.
C
The
load
balancers
that
run
in
kubernetes,
it's
a
it's
a
level,
four
load
balancing.
So
it's
based
on
networking.
It's
not
really!
You
can
configure
that
if
you
want,
but
you
don't
need
to,
you
can
configure
a
load
balancer
itself
physically,
but
you
don't
need
to
because
all
everything
is
handled,
whether
it's,
whether
it
is
with
ipbs
or
ip
tables,
or
different
components
of
the
cni,
the
access
to
network
you
can
do
by
name.
So
when
you
have
to
sharp
you,
you
will
hit
any
of
the
pots
that
serve
a
service.
C
So
when
you
have
to
chart
you
have
to
keep
the
sharding
in
your
own
application.
All
posters
can
do
that
for
you,
because
the
routers
are
in
front
and
they're
front-ended.
If
you
use,
for
instance,
elasticsearch
elasticsearch
does
something
similar,
you
hit
some
front-end
part
of
the
application.
That
knows
where
the
back-end
data
is,
and
it
does
all
the
aggregation
when
it
comes
to
sharding,
etc.
So
it's
fairly
easy
and
in
fact
I
would
say
that
it
makes
your
life
easier
to
run
this
kind
of
infrastructure
components
in
kubernetes,
at
least
in
my
opinion,.