►
From YouTube: PostgreSQL on PetSet by Josh Berkus, Red Hat
Description
PostgreSQL on PetSet - Josh Berkus, Red Hat
Now that we have PetSet, let's deploy some databases on it! Version 1.3's PetSet was designed to answer a lot of the needs of people deploying databases and other stateful services on Kubernetes. In this talk, we'll demonstrate how to use PetSet features in order to support deploying both single-master and clustered PostgreSQL. As a bonus, these database applications will be deployed to my portable micro-cluster.
About Josh Berkus
Josh works on Project Atomic at Red Hat, but is better known for his long work on the PostgreSQL Project. His passions are databases, containers, devops, cooking and pottery.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
A
A
Retailer
in
europe
and
they've
been
doing
a
lot
of
work
on
Patroni
here
and
on
automation,
and
that
sort
of
thing,
so
the
lion's
share
of
what
I
would
show
you
was
done
by
this
on-land
of
folks.
So
talk
about
pet
set.
Well,
actually,
no
we're
not
gonna
talk
about
pet
said
when
talk
about
stateful
said
anybody
here
missed
the
rename.
On
that
the
I
mean
the
rename
was
a
good
idea.
Pet
set
was
a
a
working
name
and
it
was
never
supposed
to
be
the
final
name,
there's
all
about
stateful
containers.
A
A
The
reason
I
got
involved
with
kubernetes
to
begin
with
is
because
I
wanted
to
automate
Postgres.
That
was
the
whole
thing
is
I've
been
working
on
the
posters
project
for
18
years,
and
so
kubernetes
comes
along
and
I'm
like
oh
wow,
a
tool
to
solve
a
bunch
of
the
automation
problems
that
I
have,
but
the
tool
wasn't
quite
ready
to
actually
solve
those
automation
problems.
Now,
one
of
the
other
projects
has
been
working
on
is
something
called
Patroni.
A
A
It's
an
offshoot
of
composed
iOS
thing,
but
the
important
thing
for
you
to
know
is
it's
a
demon
and
it
controls
Postgres
and
when
you're
launching
containerized
postcodes,
it
runs
as
the
primary
process
in
the
container,
which
is
important
for
automation,
because
it
means
that
I
know
that
if
Patroni
is
not
running,
then
Postgres
is
not
running
which
eliminates
a
whole
set
of
split
brain
cases.
So
an
Patroni
works
in
production.
A
You
know
running
on
the
land,
oh
and
hundreds
of
database
servers
and
that
sort
of
thing
running
in
a
few
other
sites,
but
outside
of
kubernetes,
it's
not
not
through
kubernetes,
and
so
we
actually
want
to
automated
this
in
kubernetes.
Now,
one
of
the
important
things
is
that
here
we're
talking
about
single
master
replication
with
postcodes
the
primary
way
to
actually
have
a
bunch
of
postman
instances
right.
A
You
got
one
master
and
you
have
zero
too
many
replicas,
and
this
is
still
you
know,
there's
more
advanced,
clustered
versions
of
post,
post
and
development,
but
a
lot
of
them
are
fairly
alpha.
At
this
point,
plus
for
simple
cases,
single
master
replication
is
just
easier
to
manage
and
easier
to
understand.
But
that
means
that
when
we're
automating
it
we
have
to
play
this
game
called
where's
the
master
right,
because
we
want
to
deploy
a
bunch
of
identical
Postma's
nodes
and
have
the
Postma's
master
just
come
up
and
the
rest
become
replicas.
A
That
master
then
something
to
determine
that
and
that's
actually
what
Patroni
does,
but
when
we
were
trying
to
automate
what
I
was
trying
to
automate
this
through
kubernetes
I
ran
into
a
number
of
problems.
Doing
this
in
kubernetes,
1.2
and
I'll
explain
these
problems
to
deal,
but
this
problem
is
basically
amounted
to
node
identity,
replication
connections,
connections
to
the
master,
storage,
persistence
and
shard,
and
now
that
I'm
actually
working
uncharted
Postgres
I,
don't
I
won't
be
showing
you
a
working
copy
that
today,
but
I
will
have
one
online
next
week.
A
Don't
want
to
put
any
other
load
on
that
and
there
weren't
any
non
hackish
way
is
to
do
this
before
stateful
said,
because
you
didn't
have
an
address
that
kubernetes
understood.
That
said,
I
want
this
particular
replica.
So
what
we
would
and
similar
to
this
problem
is
something
we
call
replication
identity,
which
is
that
the
current
master
needs
to
know
the
identity
of
all
the
replicas
that
are
connected
to
it.
A
Among
other
things,
the
master
needs
to
know.
If
replicas
get
out
of
sync,
it
needs
to
know
what
data
it
has
to
save
for
those
out
of
sync
replicas,
something
called
replication
slots
which,
which
actually
has
a
more
messy
problem.
That'll
explain
it
in
a
minute,
and
so
we
also
need
to
the
master
also
needs
to
have
an
identity
for
each
of
those
replicas.
So
the
way
that
we
tried
to
do
this
under
earlier
versions
of
kubernetes
was
to
just
push
the
pod
IP
address
to
say:
okay,
we've
got
these
pot.
Ip
addresses
they're
unique.
A
You
can
actually
connect
to
the
individual
nodes
for
that,
and
so
we're
going
to
push
the
pot
IP
addresses
and
use
that
as
our
de-facto
node
identity
and
hang
everything
else
off
of
that.
Well
there,
a
number
of
problems
with
using
the
pot
IP
addresses
one
of
them
was
that
that
doesn't
really
mesh
with
kubernetes
services.
A
So
it
meant
that
we
couldn't
actually
Bernays
services
to
funnel
connections
to
the
replicas,
because
kubernetes
services
don't
pay
any
attention
to
the
pot
IP
for
a
variety
of
reasons,
but
then
there
were
also
the
thorny
problems
right
if
kubernetes
needs
to
migrate
stuff
due
to
resource
usage,
sometimes
the
IPS
will
change
the.
If
the
IP
is
change
and
you
cycle
through
your
set
IPS
can
get
reused.
A
A
There
also
were
some
other
permutations
of
it
that
were
really
messy
to
solve
and
will
quiet
hack
as
things
and
one
of
these
give
you
an
illustration.
This
is
through
something
called
replication
slots,
so
they
do
a
replication
slot
in
post
Prezi.
Is
you
basically
put
every
time
the
replica
slips
down
new
data
from
the
master?
You
know
data,
that's
changed,
table
updates
and
inserts,
and
that
sort
of
thing
it
puts
a
bookmark
that
tells
the
master
where
it
left
off.
A
In
case
it
loses
the
connection
and
that's
important,
because
if
you
do
lose
the
connection
between
the
replicas
in
the
master,
you
wanted
to
pick
up
when
it's
left
off,
so
the
master
isn't
saving
any
more
data
than
it
absolutely
has
to,
because
it
can,
if
it
saves
too
much,
storage
can
really
balloon.
Well.
The
problem
is
that
if
you
have
a
lot
of
sort
of
intermediate
failures
and
you
have
replicas
coming
up
and
down
all
the
time,
some
of
those
IP
addresses
are
going
to
change,
and
so
what
happens?
He
is
what
was
dot.
A
And
if
you
have
a
very
high
transaction
rate,
you
may
have
very
little
time
to
react
to
us,
and
so
then
that
forces
you
to
have
a
watchdog
process
that
looks
for
replication
slots
that
are
not
being
used
anymore
and
deletes
them
so
that
they're
not
storing
up
that
anymore,
but
there's
a
problem
with
learning
that
watchdog
process.
If
the
watchdog
process
reacts
too
fast,
then
the
replica
comes
back
and
it
can't
get
data
anymore,
because
it's
slot
is
gone.
A
So
not
really
a
solvable
problem
in
the
context
of
kubernetes,
1.2
and
I
feel
kind
of
illustrates
one
of
the
the
issues
that
we
were
having
without
stateful
sets.
So
there
were
a
lot
of
sort
of
workarounds
in
this
one.
Was
that
implementing
this
in,
like
1.2,
we
actually
ended
up
failing
over
a
lot
more
often
than
we
really
needed
to
you
a
custom
proxy
for
handling
master,
etc.
Connections
was
absolutely
essential,
then
that
custom
proxy
actually
has
to
read
separate
information.
That's
outside
of
kubernetes.
A
Your
discovery
basically
does
not
use
qu
Bernays
discovery.
You
have
to
create
headless
services
to
front
these
things
in
the
headless
services
connect
to
pod
IPs,
and
if
anybody
has
done
that
before
you
know
it's
a
little
unreliable
again,
because
those
IPS
can
change
around
and
then
you
know,
I'll
watchdog
or
cleanup
process
to
actually
deal
with
all
of
the
sort
of
fallout
for
things
that
don't
just
work,
and
so
it
ends
up
being
a
relatively
sort
of
complicated
topology
even
at
on
a
minimal
thing
right.
A
You've
gotta
at
least
have
in
addition
to
kubernetes
and
a
separate
etcd
or
other
dcs
cluster.
You
have
to
have
your
post
businesses
running
patron.
You
have
to
have
a
custom
proxy
and
you
actually
have
to
have
some
kind
of
a
cleanup
watchdog
service
and
in
order
for
all
of
this
to
work,
which
is
messy
and
and
what
I
really
hated
about
it
is
it
meant
that
most
of
my
automating,
a
post
process
was
happening
outside
of
kubernetes.
A
All
the
kubernetes
was
doing
for
me
was
making
sure
that
I
had
a
certain
number
of
Postgres
containers
up
and
running
and
the
proc.
You
know
these
other
processes
were
up
and
running,
but
all
the
other
animation
took
place
outside
of
goober
neighs
who's,
not
what
I
wanted
out
of
kubernetes
I
wanted
kubernetes
to
do
the
automation
for
me.
A
So
there
are
also
some
other
issues,
storage
issues
and
that
this
was
even
worse
and
sort
of
fundamentally
insoluble,
which
is
that,
if
you
wanted
to
have
persistent
volumes
to
store
your
databases,
then
there
was
no
understanding
that
the
different
replicas
would
have
separate.
Persistent
volume
claims,
unless
you
actually
effectively
did
all
that
by
hand
again,
which
meant
which
didn't
work
for
databases
at
all,
because
right,
they
all
need
read
right
to
their
own
storage
and
there
was
no
opportunity
to
reuse
a
persistent
volume,
those
associated
with
particular
replicas.
A
One
of
the
ways
we
actually
handled
this
was
to
do.
Daemon
set
a
beaut,
we
called
demon
set
abuse
or
even
though
we
have
is
a
group
of
replicas,
we
treated
as
a
daemon
set
and
then
his
host
path
to
actually
join
to
some
sort
of
network
storage
and
therefore
each
node
has
access
to
its
own
claim
and
network
storage
were
to
handle
the
volume
management,
basically
in
the
application
and
I
didn't
want
to
think
about
doing
this
charted
Postgres
under
under
kubernetes
won't
play.
This
is
just
be
a
nightmare
yeah.
A
You
know
effectively,
you
start
looking
at
you
start
saying.
Maybe
this
will
be
easier
to
do
without
kubernetes
it
would
be,
but
now
we
have
stateful
set
and
things
are
beautiful,
so
our
architecture
diagram
gets
a
lot
simpler
under
stateful
set
for
your
single
master,
Patroni
Postgres
right.
We
need
kubernetes
and
we
need
a
distributed.
Configuration
management
cluster,
listen
instance,
etcd,
and
then
we've
got
post
quiz
and
number
of
post
questions.
This
is
running
the
Patroni
daemon
and
they're,
communicating
with
the
ECT
and
they're
communicating
with
kubernetes,
and
that's
all
that
you
need.
A
So
there
are
basically
we've
got
five
components
here.
We
have
again
distributed
configuration
service
cluster,
the
headless
service
that
you
need
to
create
for
a
Repat
set
and
the
sustainer
with
patsaks
don't
show
you
that
in
a
minute,
every
stateful
set
a
stateful
set
of
replicas
running
Patroni
a
master
only
service
at
a
minimum.
A
You
can
also
create
a
separate
load
balancing
service
for
reeds,
depending
on
your
use
case
and
then
optionally,
a
persistent
volume
claim
or
president
volume
template,
which
is
how
you
use
it
in
stateful,
set
I
for
storage
for
durable
storage
for
the
databases
now.
The
reason
why
I
say
that
that's
optional
is
that
you
don't
always
want
and
largely
what
that
depends
on
is
how
big
your
databases
are
going
to
be
so
the
so.
If
you
have
a
large
database,
then
you're
going
to
definitely
want
persistent
volumes.
A
No
one
wants
store
that
large
database
on
persistent
volumes
so
that
you
can
actually
reuse
the
data.
And
if
you
have
a
bunch
of
small
databases,
it's
actually
a
lot
easier
to
use
a
ephemeral
storage
that
is
node
storage
via
empty
there
and
big
here
is
defined.
As
how
long
does
it
take
you
to
make
a
copy
of
the
database
via
the
replication
protocol
right
if
the
answer
is
a
very
short
time,
the
answer
is
a
couple
of
seconds,
then
you're
easier,
creating
lots
of
ephemeral
copies.
A
If
the
answer
is
an
hour
or
more,
then
you're,
probably
a
lot
better
off
using
persistent
volume.
Clamps
and
that's
just
a
you-
know,
sort
of
application
specific
decision,
so
let's
actually
show
you
that
in
terms
of
setup,
so
now,
by
the
way,
if
you
have
any
trouble
seeing
this
on
this,
if
you
go
to
github.com
J
burkas
atomic
DB,
the
code
is
actually
in
there.
So
you
can
get
a
closer
look
at
it.
But
I'll
show
you
this
here
so
I.
A
First,
we
have
to
bring
up
an
HDD
cluster
and
by
the
way,
I
don't
know
if
you've
looked
at
like
doing
this
under
stateful
set.
But
this
made
doing
doing
this
particular
action.
Much
less
complicated
like
this
is
the
entire
business
to
bring
up
an
EDC
cluster.
That's
using
empty
ddr4,
node
data.
You
know,
we've
got
our
hitless
service,
which
is
a
requirement
of
a
pet
set,
and
you
know
secrete
this
headless
service
requirement
of
a
pet
set.
A
A
A
Don't
recommend
using
cout
burn
the
the
e
2zii
cluster
that
kubernetes
uses
for
its
own
management
I,
don't
recommend
using
the
same
one
for
apps,
bring
up
a
second
one
for
apps
there's
a
couple
of
reasons
for
that.
One
is
potentially
performance,
because
if
kubernetes,
if
the
easy
clusters
so
busy
kubernetes
can't
can't
ask
it
things,
then
your
whole
cluster
is
paralyzed
and
the
big
role
in
the
security
right
is
the
I'm
gonna.
Give
you
an
example
here.
A
Actually
the
easy
that
kubernetes
is
running
on
here
is
actually
secured,
SSL,
etc
and
and
I've
actually
brought
up
this
one
for
the
my
demo
here,
completely
unsecured,
so
yeah
the
so,
but
that's
etz,
and
you
came
here
to
see
Postgres.
So
we've
got
a
couple
of
things
for
for
sending
in
Postgres
right
we've
got.
Obviously
you
have
to
have
some
secrets
in
a
real
production
thing.
I
would
actually
be
using
probably
hashey
core
vault
for
for
these
for
rotation,
etc.
The
yeah
the
things
that
secrets
in
kubernetes
are
really
not
that
secret.
A
A
The
something
like
vault
actually
can
do
that,
and
one
of
the
reasons
I
you
like
to
use
ball
with
post
coasters
that
vault
has
a
plug-in
for
Postgres,
so
that
I
can
actually
enforce
credential
rotation
and
have
it
work
inside
Postgres,
the
so,
and
then
we
have
our
cluster
and
it's
actually
quite
simple.
So
again,
first
of
all,
you
create
this
headless
service
right
we've
got
and
an
api
version.
We've
got
our
service
here.
A
These
components
are
just
labels
to
grab
it,
and
so,
and
the
important
thing
here
is
we're
selecting
off
the
labels
that
we've
got
on
the
items
and
one
of
the
things
that's
actually
I
need
to
add
a
doc
patch
for
cuz.
It's
not
it's
there
in
the
examples,
but
it's
not
documented
if
you're,
actually
creating
the
headless
service
for
a
pet
set.
Cluster
IP
has
to
be
none.
A
We
don't
get
a
cluster
IP
from
that
the
and
it
will
just
mysteriously
not
work.
If
you
don't
set
that
the,
and
so
then
we've
got
our
pet
set
configuration
here
right
and
so
we've
got
our
basic
declaration.
The
labels
and
that
sort
of
thing,
but
part
of
it,
starts
out
your
pets.
That
starts
out
with
we've
got
a
service
name
and
that
service
name
needs
to
relate
to
the
head
needs
to
be
the
same
as
the
headless
service
we've
just
created.
A
What's
better
to
do
them
in
in
one
go
the
number
of
initial
replicas
that
we
have
template
with
metadata
and
a
bunch
of
other
things,
the
and
here's
our
container
version
and
then
here's
a
whole
bunch
of
environment
variables.
I'm
passing
in
in
order
to
create
Petronius
initial
configuration,
which
includes
things
like
it
needs
to
know
where
to
find
Det
CD.
It
needs
to
know
what
cluster
it's
a
member
of.
It
needs
to.
A
I
set
some
initial
passwords
and
security
information
for
Postgres
because,
although,
as
you
can't
connect
and
then
I
need
to
actually
have
some
downward
API
information
in
order
to
do
discovery,
because
the
nodes
need
to
not
only
be
discoverable
about
the
applications,
but
they
need
to
discover
each
other.
And
so
we
need
to
pass
that
that
information,
which
is
all
available
via
the
download
API
I.
A
Patroni
actually
has
two
ports:
five,
four
three
two
zero
recognizes
the
post
press
port
container
port
is
that's
actually
the
patron
II
API
port,
which
is
important
because
we
need
to
be
able
to
get
information
from
that.
The
nodes
need
to
communicate
with
each
other
and
then
some
volume,
mountains
for
data
etc,
and
these
are
running
FML
because
they
come
up
a
lot
faster.
If
I
do
that.
So
actually
you
know
what
I'm
gonna
kill
these
again,
because.
A
Because
I
want
to
show
you
another
important
thing
about
how
stateful
set
works,
so
one
of
them's,
you
notice
what
stateful
set
here.
Is
it
actually
one
of
its
features?
Is
it
creates
the
nodes
in
numerical
order,
so
those
numbers
that
we're
getting
here,
petronia,
0,
p21,
etc.
Those
are
assigned
by
the
stateful
set
API
I
didn't
actually
create
those
names
and
so
it'll
bring
them
up
there.
A
Ok
and
so
we've
got
all
of
them
up
now,
and
so
then
the
other
question
becomes
well
where's.
The
master
right,
because
part
of
this
whole
game
is
where's
the
master,
and
so
one
of
the
things-
and
this
is
something
that
Alex
and
I-
think
Alex
at
zalando
figured
out-
is
that
in
order
to
do
mm-hmm,
all
of
this
nope
they're
not
finished
coming
up
yet.
Okay,.
B
A
A
Actually,
none
the
because
I
killed
it
off
and
brought
it
back
up.
It's
trying
to
reinitialize
the
same
cluster
which
it
does
not
do
in
an
automated
way,
because
you
could
lose
data
if
it.
If
it,
we
initialized
a
cluster
that
had
already
been
previously
initialized,
but
that
means
that
I
actually
need
to
kill
off.
A
There
we
go
so
so
in
a
couple
of
seconds
that
should
actually
figure
out
that
there
we
go.
It
should
figure
out
that
there's
no
longer
a
leader,
and
so
then,
when
it
figures
out
there's
no
longer
leader,
it
holds
a
leader
election
among
the
notes.
Now,
when
you're
doing
an
initial
deployment,
if
we
hadn't
had
that
initialized
key
blocking,
it
would
always
end
up
being
node
zero,
because
that
one
comes
up
first
right.
But
in
this
case,
because
we
remove
the
key,
it
holds
an
election
and
it's
largely
timing
based.
A
So
if
we
actually
look
at
this,
so
this
is
what
else
figured
out
is
that
we
can
actually
abuse
kubernetes
annotations
for
our
where's,
the
master
instead
of
requiring
an
external
proxy
to
do
this.
So
this
Patroni
rule
tag
doesn't
exist
when
we
do
the
initial
deployment
and
if
you
actually
have
a
tag
that
doesn't
exist.
A
When
you
do
the
initial
deployment,
then
the
individual
application
can
use
the
service
API
in
order
to
add
tags
that
it
owns,
and
that
means
that
we
can,
it
can
basically
set
which
one
is
the
master
and
which
one's
the
replica.
Now,
once
we've
set,
which
one's
the
master
and
which
one's
the
replica,
then
we
want
the
applications
to
connect
to
it
right,
because
this
headless
service
is
really
just
for
the
nodes
to
communicate
with
each
other.
A
A
A
A
A
So
those
will
take
a
minute
to
come
up
there
actually
they're
coming
up
really
fast,
so
the
new
ones
that
come
up.
Obviously
they
come
up
as
replicas
and
they
join
the
masters
part
of
the
replica
set.
They
pull
down
a
copy,
the
database,
they
start
replication
automatically
right,
but
then
the
other
fun
thing
is
that
of
course,
Phil
over
needs
to
work.
A
Oh
yes,
good
point
and
so
hopes
it's
not
what
I
want
to
make
me
in
history,
so
this
will
take
a
few
seconds
to
actually
realize
that
the
Masters
gone
and
to
hold
a
new
leader
election.
The
leader
election,
operates
in
two
stages.
Basically,
first
stage
is
standard
leader
election
via
the
dcs
to
see
who
grabs
the
leader
lock.
Second
stage
is
checking
the
replication
status
of
each
node
to
make
sure
that
we're
not
electing
a
leader
whose
replication
is
broken
or
that's
really
far.
A
A
So
that's
not
working.
It's
pretty
awesome
exit.
There's
a
few
there's
a
few
small
issues
that
I'm
going
to
go
over,
but
as
far
as
automating
single
master,
postcodes
is
now
that
we
have
stateful
set
it
basically
just
works.
Now
you
can
add
extra
refinements
on
in
real
production.
Circumstance,
I
would
actually
want
things
like
an
actual
connection
proxy
for
the
applications
and
the
connection
proxy
would
plug
into
the
service,
and
you
know,
all
of
the
other
usual
tooling.
A
A
A
What
it
depends
on
your
implementation,
on
your
reconnection
implementation
and
in
that
II
is
that
is
any
of
this
person
connection
is
not
going
to
look
up
the
address
well
as
long
as
it
thinks
it
has
a
valid
connection,
so
one
things
can
happen.
Is
you
don't
actually
get
a
failure
until
somebody
tries
to
send
data
and
then,
if
it's
a
badly
programmed
proxy
like
a
lot
of
the
Tomcat
proxies
I've
seen
it
may
not
try
to
reconnect
at
any
intelligent
way?
A
It
may
try
to
reconnect
to
a
caste
connection
which
is
now
wrong,
so
you
may
need
to
actually
do
some
refactoring
of
your
connection,
logic
and
applications
for
this
to
just
work
for
you
and
like
PG
bouncer,
a
lot
of
people
use
the
PG
bouncer
went
back
ends,
go
wait
for
PG
bouncer,
because
PG
bouncer
is
nice
for
scaling
lots
of
connections
for
post
Prez,
but
when
backends
go
away
for
PG
bouncer,
it
tends
to
not
try
to
replace
them
by
lookup.
It
tends
to
just
send
you
error
messages
which
is
really
annoying.
A
Also,
the
the
coop
built-in
kubernetes
dns
is
not
necessarily
super
speedy
compared
to
connecting
like
by
IP
address.
So
there
use
some
extra
lag
and
forming
new
connections,
but
it's
worth
it
for
the
use
of
management.
Now.
So
what
I'm
working
on
right
now
is
working
on
getting
stateful
set
up
with
sharted
post
res
I,
as
well
as
multi
master
synchronous,
replication
so
and
I
actually
have
to
show
off
a
demo
those
next
week
so
at
if
PG
thought,
Silicon
Valley,
so
I
will
be.
A
If
you
follow
up
my
blog
or
anything
that
sort
of
fuel
you'll
see
this
next
week
now,
there's
some
other
things
in
kubernetes
to
finish
up
here:
Oh
complex
replication,
topologies,
so
I
want
to
have
some
asynchronous
replicas
and
some
synchronous
replicas
and
some
cascading
replicas.
That's
that's
a
big
to-do
in
the
Patroni
world
to
actually
support
that
in
a
meaningful
way.
I'm.
You
can
kind
of
do
it
ad
hoc,
but
it
becomes
a
big
management
headache
and
it
is
something
with
people
with
actual
production.
Implementations
need
to
have.
A
We
do,
it
depends,
I
mean
obviously,
if
you're
using
a
cloud
host
that
supports
dynamic
purchases
and
volume
claims,
then
it
works
right.
We're
still
waiting
for
a
lot
of
stuff
and
I'll
actually
talk
about
some
of
that.
So
here's
some
buildings
were
waiting
for
the
affinity,
anti
affinity,
new
affinity,
anti
infinity
stuff
in
1.5,
because
we
don't
want
to
have
multiple
replicas
from
the
same
database
on
the
same
node.
Because
then
you
don't
have
a
che.
A
We're
changing
the
the
affinity,
anti
infinity,
API
and
sort
of
syntax,
the
stuff
that
we
had
before
with
the
annotations
was
really
hard
to
make
simple
rules
like
don't
put
two
nodes
from
this
stateful
set
on
the
same
two
items
from
the
staple
set
on
the
same
node
and
it
would
often
be
ignored
by
the
default
scheduler.
Frankly,
the
but
that's
all
being
fixed
in
1.5.
A
A
We
should
be
able
to
say
hey
this
needs
this
many
high
ops
and
don't
over
allocate
storage
for
it,
and
we
don't
have
that
in
kubernetes
and
and
having
databases
in
kubernetes
are
really
showing
that
kind
of
need
that
also
for
persistent
volumes.
I
want
to
be
able
to
have
more
intelligent
reclaimed
policies,
because
if
a
PVC
has
been
idle
for
like
24
hours,
I
probably
don't
want
to
reclaim
it.
A
I
can't
really
do
that
right
now,
but
but
these
are
tweaks
and-
and
you
know,
we'll
get
there
in
some
form,
so
I've
got
a
whole
set
of
resources,
for
this
I
actually
have
not
pushed
the
current
version.
The
presentation
about
do
this
right
after
that
I
Patroni.
If
you
want
an
actual
like
production
deployment
of
something
like
this,
because
this
one
that
I
have
there,
which
is
the
code,
is
up,
but
it
is
meant
as
a
demo,
so
it's
easily
comprehensible,
a
production
version
would
be
like
the
helm
chart
for
spy.
A
A
D
D
A
I'm,
the
post
ghost
guy
so
I,
don't
actually
know
a
lot
about
Maria
DB,
so
I,
don't
I,
don't
really
have
an
opinion
on
that
versus
RDS.
Rds
is
extremely
popular.
When
I
was
a
post
growth
consultant',
we
admit
a
lot
of
RDS
instances
for
our
customers,
but
we
still
had
to
admit
in
them.
You
know,
as
in
our
customers,
were
still
hiring
us
as
consultants
to
admit
their
RDS
instances.
So
I've
never
quite
understood
the
appeal
of
RDS.
E
C
F
A
A
So
so
that's
basically
my
opinion
of
it
is
the.
The
problem
is
that
PG
pool
tries
to
be
the
Swiss
Army
knife
of
like
posters
management,
it's
connection
manager
and
a
cache
and
a
replication
manager
and
a
query,
pre
parser
and
something
else,
and
it
means
that
it
doesn't
do
any
of
those
things
particularly
well.
So
I
don't
recommend
using
PGP
pool
if
you
want
a
proxy
to
support
your
applications.
F
A
The
question
is:
petronia
automatically
move
with
new
posters
versions
or
both
updates
and
the
new
version.
So
this
is
two
different
questions.
It
does
not
automatically
move
with
updates
it,
but
the
thing
is
because
failover
is
automatic.
What
you
do
is
you
use
a
kubernetes
rolling
upgrade
to
operate.
The
containers
to
the
new
version
of
Postgres
and
failover
will
happen
as
you
do.
The
rolling
upgrade
the
and
then
doing
major
upgrades.
That's
waiting
for
post
crews,
10
after
post
was
10
you'll
be
able
to
do
major
upgrades
via
replication.
C
A
So
question
is
what
sort
of
real
production
workloads
are
being
run
on
this,
because
a
lot
of
people
don't
think
that
you
should
run
databases
on
kubernetes
or
in
containers
etc?
Well,
in
terms
of
like
the
major
production
workload
I'll,
let
the
gentleman
from
solando,
although
he's
not
he's
not
running
it,
they're
not
running
in
Turku
Bernays
right
now,
but
they're
definitely
planning
to.
G
Doing
the
work
we
are
running
everything
in
dhaka
already
but
one-to-one
with
these
two
instances,
so
we
will
have
dedicated
node
pools
on
kubernetes
and
we'll
definitely
move
everything
to
grenadiers
and
there's
a
few
hundred
databases.
We
are
huge
post
quest
fanboys,
so
so
we
are
not
on
kubernetes
right
now,
in
production,
but
probably
and
for
kube
conan
march
will
definitely
have
a
lot
of
experience
to
talk
about
yeah.
E
C
C
G
C
H
H
A
A
B
A
Or
what
those
are?
So
the
question
is
what
they
already
did
versus
what
they're
doing
now.
So
the
the
crunchy
DB
reference
deployment
for
post
pres
was
built
to
work
around
the
limitations,
I
think
of
actually
kubernetes
1.1
and
so
you'll
see
their
diagram.
I.
Don't
have
it
up
here,
but
there's
actually
like
11
different
kinds
of
containers,
a
lot
of
which
are
sort
of
internal
management
containers
and
proxies
and
they've
got
PG
pool
in
the
mix
and
that
sort
of
thing
and
a
lot
of
this,
because
we
couldn't
do
this
stuff
right.
A
We
couldn't
manipulate
the
kubernetes
dns
to
redirect
it
to
the
master
and
do
all
of
these
other
things,
the
one
of
the
things
with
stateful
sets,
etc.
Particularly
once
one
point
four
is
supported
with
openshift
they'll,
be
able
to
simplify
their
architecture
based
on
using
a
lot
of
the
same
techniques.
A
B
D
A
Cuz
I'm
just
doing
a
demo,
I
mean
a
production.
One
like
I
said,
look
at
look
at
silo
and
you've
got
all
of
these
things:
yeah
yeah,
the
so
yeah.
So
you
would
you
know
that
would
be
included
in
this
and
that
sort
of
thing
it's
the
core
failover
and
connection
management.
That's
getting
simple
or
everything
else
is
pretty
much
the
same.
Okay
and
now
we
actually
need
to
go.
So
if
you
have
people
with
more
questions,
I'm
happy
to
take
them
out
in
the
hall.
Thank
you
very
much.