►
From YouTube: Data On Kubernetes, Deploying And Running PostgreSQL And... - Chris Milsted & Gabriele Bartolini
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-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.
Data On Kubernetes, Deploying And Running PostgreSQL And Patterns For Databases In a Kubernetes Cluster. - Chris Milsted, Ondat & Gabriele Bartolini, EDB
Speakers: Chris Milsted, Gabriele Bartolini
In this talk we are going to focus on the newly open sourced Cloud Native PostgreSQL operator. From work in the Data on Kubernetes community, we are seeing databases becoming first class citizens in our kubernetes clusters. This talk is going to look at how to combine the cloudnative-pg operator with a CSI-plugin, and how to leverage these two components to deliver databases which are as fast and resilient as their non-kubernetes equivalents. Wondering how to architect for a zero or low RTO and what the effect of replication has on recovery time for your database? Wondering how to use an object store as well to deliver point in time backups to protect from cyber attacks? In this talk we are going to answer these questions and more mapping to the patterns in the cloud native disaster recovery whitepaper and the data protection whitepaper. Like all good talks we will also have a live demo of this all in action. The time of Data on Kubernetes is now, come and find out how.
B
Rover
one
two:
three:
okay,
good
hi
I'm
Gabriel
bartolini
as
you
have
my
guest
I'm
From
Italy
I
work
for
EDB,
which
is
one
of
the
major
contributors
to
the
pause
gear.
Sql,
open
source
project
I'm
vice
president
and
CTO
of
cloud
native,
and
my
primary
goal
in
the
organization
is
to
enhance
the
podcast
experience
in
the
kubernetes
space.
B
I
I'm,
an
active
member
of
the
postgres
community
and
I've,
been
working
for
PO
with
possess
for
over
two
days,
two
decades.
I
I'm,
an
early
adopter
of
the
devops
culture,
and
here
today,
I
will
briefly
cover
the
cloud
native
PG
open
source
operator.
While
Chris
will
primarily
talk
about
the
storage
part.
A
Between
us,
hopefully,
you
find
it
interesting,
so
we're
going
to
try
and
do
a
bit
about
kind
of
the
intro
set
the
scene,
then
we're
going
to
do
a
lot
about
the
postgres
patterns
and
then
we're
going
to
try
and
do
a
little
demo
at
the
end,
which
I
have
recorded
it,
because
anyone
in
Valencia
know
what
the
Wi-Fi
was
like.
Trying
to
do.
A
live
demo
was
absolutely
impossible,
so
we've
gone
for
the
backup,
safe
video,
but
it
is
running
on
my
laptop.
A
So
if
anyone
does
want
to
come
and
see
it
in
real
life
come
and
find
me
either
here
afterwards
or
at
the
booth
and
we'll
go
in
through
it,
and
do
it
again
and,
as
you
can
see
by
the
picture,
EDB
had
a
party
last
night
and
there
might
have
been
some
alcohol
served
and
yeah.
We.
We
don't
look
like
that.
Normally
in
real
life,
so
the
first
part
is
The.
Click
is
not
clicking
there.
We
go
we're
on
there,
so
the
first
part
is.
A
There
was
a
talk
previously
to
this
one,
which
was
you
know,
data
on
kubernetes,
bring
it
on.
So
we're
not
going
to
try
and
convince
you
to
put
data
in
kubernetes
we're
going
to
assume
that
you're
all
given
in
this
room
that
this
is
the
case.
But
if
you
are
interested
and
want
to
know
more,
both
of
our
companies
are
very
active
members
and
proud
supporters
of
the
data
and
kubernetes
and
they've
got
these
great
reports.
A
So
if
you
or
your
boss
or
your
teams
or
anyone,
is
interested
in
convincing
people
to
run
data
in
kubernetes,
please
go
and
download
this
report.
There's
a
QR
code
in
the
bottom
right
hand,
side
and
the
slides,
which
you
can
click
on
that
and
you'll
get
access
to
the
report.
Anything
else
you
want
to
say
about
that
one's
gabrielli.
A
A
You
still
have
to
think
about
exactly
the
same
problems,
but
it's
a
lot
easier
and
there's
a
lot
of
nice
Automation
and
things
that
happen
either
from
the
kubernetes
side
or
from
the
cloud
native
postgres
operator
side
to
make
your
job
a
lot
easier.
So
it
is
much
easier
to
automate
and
get
this
all
to
work
without
having
to
spend
you
know
months
and
sacrificing
whatever
animals
your
country
would
do,
but
the
the
main
thing
which
I'm
going
to
just
leave.
You
is
the
bottom,
two
lights,
bottom,
three
acronyms,
so
the
maximum
tolerable
downtime.
A
This
is
a
business
and
application
Level
question,
and
then
that
leads
you
on
to
the
two
technical
things:
your
recovery
time
objective
and
your
recovery
Point
objective,
how
much
data
can
I
afford
to
lose
in
the
event
of
an
outage
and
how
long
have
I
got
to
get
the
systems
back
up
and
running,
so
we're
going
to
try
and
frame
kind
of
the
different
scenarios
and
the
different
patterns
we're
going
to
talk
about
in
these
different
terminologies,
but
the
big.
The
key
thing
for
me
is
resiliency.
Nothing
changes.
B
B
Thank
you.
Thank
you
Chris.
So,
oh,
this
is
tough.
Okay,
because
I'm
trying
to
put
pause
SQL
in
one
slide,
and
you
know
having
also
a
former
core
member
of
postgresia.
You
know
you
know
this
is
gonna,
be
tough,
but
anyway,
I
want
to
ask
who's
in
this
room
already
using
postgresql
in
production,
wow,
okay,
and
no.
No,
keep
your
hand
up.
Please
and
who's
do
using
that
in
kubernetes,
yeah
see
I
see
many
hands
going
down.
B
Okay,
so
hopefully
you
know
you
are
convinced
after
this
talk
that
this
is
not
only
possible
but
as
I
Define
it
that's
the
best
overall
overall
experience
of
posca
SQL,
okay,
I
think
that
possible
kubernetes
work
very
well.
So
for
those
of
you
who
instead
are
not
familiar
with
pause,
guess,
ql
or
simply
pause,
guess
it's
one
of
the
most
successful
and
Innovative
open
source
project
server.
B
However,
I
feel
it's
important
to
restate
some
of
the
extraordinary
capabilities
that
come
out
of
the
box
with
posgus
many
Enterprise
level
features
that
have
been
consistently
introduced
in
the
project
year
after
year.
One
major
release
after
the
other
postgresql
implements
the
primary
standby
architecture,
with
a
single
primary
and
an
optional
number
of
read-only
replicas
suitable
for
high
availability
and
Rich
scalability
purposes.
B
This
is
possible
through
its
native
streaming
replication
protocol,
which
is
available
in
different
different
flavors
physical,
logical,
asynchronous
and
synchronous
by
the
way,
even
a
transaction
level.
You
can
set
these
these
stuff
so
and
also
cascading
postgres,
also
support
file
based
replication,
which
is
extremely
useful
in
multi-region
setups,
especially
when
used
in
conjunction
with
object
stores
in
the
cloud.
Then
we've
got
continuous,
backup
and
point
in
time,
recovery
that
completes
complete
the
business
continuity
requirements,
enabling
it
to
achieve
rpo0
and
very
low
rtos
in
several
disaster
scenarios.
B
There
are
a
few
operators
for
posgus
out
there,
but
Cloud
native
PG
is
fundamentally
different
from
the
rest.
Okay,
it's
open
source;
it
distributes
it
under
Apache,
License
2.0,
but
in
May
this
year
it's
it's.
Intellectually,
intellectual
property
has
been
donated
by
ADB
to
event
on
neutral
and
openly
governed
Community,
with
the
long-term
aspiration
to
pursue
the
cnci
for
graduation
process,
we've
applied
to
the
cncf
sandbox
and
we
are
currently
in
the
review
process
on
the
technical
side.
B
Because
of
this,
because
we
extend
the
controller,
we
don't
use
a
tool
like
patroni
or
web
manager
to
which,
for
example,
I
contributed
in
the
past
in
the
first
version
of
rep
manager,
stolen
and
so
on.
In
order
to
have
finite
control
on
the
postgres
cluster,
we
we've
made
the
decision
to
not
to
rely
on
stateful
sets
but
to
directly
manage
PVCs.
B
Cloud
native
PG
is
fully
declarative
and
relies
on
kubernetes
resources
to
facilitate
the
integration
with
applications
such
as
Services
Mutual
TLS,
via
Secrets,
Affinity
control
and
so
on.
Out
of
the
box,
it
provides
observability
through
endpoints
for
the
native
Prometheus
exporters,
as
well
as
direct
login
Json
log
for
to
standard
output.
B
B
Let's
go
to
storage,
so
storage
is
the
most
critical
component
of
a
database.
That's
always
been
like
that
by
myself,
VM
VMS
and
kubernetes
as
well,
and
you
must
plan
for
day
from
Day
Zero
to
run
database
workloads
as
I
was
mentioning
before
Cloud
native
PG
doesn't
make
use
of
stateful
sets,
and
you
can
learn
more
about
why
by
scanning
this
QR
code.
B
B
So
one
of
the
amazing
thing
amazing
things
of
kubernetes
is
that
it
enables
us
to
build
a
virtual
data
center
using
declarative
configuration.
So
infrastructure
is
code,
so
I
will
go
through
some
examples
here
of
architectures
from
the
most
basic
one
to
a
disaster.
Recovery
example
that
spans
over
multiple
regions
on
kubernetes
clusters.
B
This
second
example
relies
on
taints,
but
you
can
use
also
not
selectors
if
you
want
to
separate
applications
and
dedicate
some
nodes
to
pause
this
workload,
while
still
using
a
shared
network
storage.
In
this
case,
as
you
can
see,
the
third
example,
we
decide
to
dedicate
some
storage
to
posca's
workloads,
while
in
this
one
we
directly
attach
local
storage
on
the
nodes
being
reserved
for
posgus.
B
Here
we
go
even
further
by
dedicating
a
single
node
to
a
single
pause,
guess
instance,
with
local
storage
again,
and
this
example
instead
describes
a
three
node
cluster
posgus
cluster,
with
the
primary
in
this
in
two
standbys,
where
each
node
has
local
storage
and
sits
in
the
different
availability
Zone
thanks
to
topology
key
okay.
So
we
can
do
this
in
a
in
a
declarative
way.
B
These
fine
and
pull
instead
uses
the
concept
of
a
feature.
We
call
replica
cluster
where
we
create
another
postgres
cluster
in
a
different
in
a
different
kubernetes
cluster,
which
normally
is
in
any
different
region
and
use
streaming
replication
with
a
direct
connection.
So,
of
course
you
need
to
go
through
security
and
so
on
to
make
it
happen.
B
Otherwise,
if
you
want,
you
can
simply
use
asynchronous
replication
with
file
shipping
using
an
object
store
that
enables
to
transfer
data
across
regions
or,
if
you
want
both,
because
that's
that's
done
directly
by
fosgis
pause,
gets
fall
back
falls
back
in
case
the
network
goes
down
okay,
so,
as
you
can
see,
just
by
using
kubernetes,
you
can
easily
open
up
for
multi-cloud
environments
or
hybrid
Cloud
environments.
It's
it's
your
choice,
okay,
so
which
one
to
pick
so
really
any.
You
know
you
can
pick
any
any
the
one
that
suits
for
your
use
case.
B
B
B
We
use
Convention
of
a
configuration.
You
call
this
my
appdb
and
we
have
a
primary
and
two-stand
buys.
We
set
the
Affinity
to
prefer,
you
know
using
clusters
in
in
different
nodes,
and
we
set
the
storage
for
PG
Dasa
and
the
store
Storage
storage
for
walls,
and
this
is
what
happens
under
the
hood.
Okay,
we
we
initialize
the
first
PVC
and
we
run
in
ADB
in
ADB-
is
the
process
that
creates
the
PG
data
of
a
primary
and
once
the
PVC
is,
is
initialized.
B
We,
the
cloud
native
PG,
starts
the
pod
and
when
the
party
is
up,
we
Define
the
the
kubernetes
service
that
will
be
used
by
applications.
So
we
have
three
services,
one
for
read,
write
one
for
read-only
and
one
for
read
operations
and
and
then
we
use
Mutual
TLS.
We
said
already
Mutual
TLS
to
communicate
with
with
the
application
you
can
use
TLS
certificates.
You
can
integrate
that
with
search
manager.
If
you
want
all
out
of
the
box,
then
we
use
PG.
B
B
B
B
A
B
A
B
B
B
A
Yeah,
the
other
thing
is:
go,
do
go
and
read
that
thing
about
it
doesn't
as
a
kubernetes,
normal
person
who's
been
using
kubernetes
for
about
seven
eight
years
now.
I
did
not
understand
what
was
going
on
when
I
first
started
using
it,
because
there
were
no
staple
sets.
There
was
no
replica
sets,
there
were
no
deployments
and
I
went.
What
is
going
on
so
do
go
and
read
the
article
it's
good.
A
It
explains
why
it
does
this
and
why
it
does
it's
a
kind
of
a
manual
decide
to
fail
over,
because
you
don't
want
to
throw
away
PG
data
and
then
have
to
re-synchronize
it.
So
it
makes
a
lot
of
sense
once
you
kind
of
read
the
documentation
from
the
operator,
so
I'm
going
to
try
and
go
really
quickly
about
through
these
bits
and
then
go
through
the
demo,
which
I'm
going
to
try
and
narrate
at
the
speed
of
light,
which
is
going
to
be
very
entertaining.
A
The
first
thing
just
to
say
is
that
the
storage,
as
gabrielly
said,
is
the
most
critical
and
I
think
picking
the
faster
storage
that
you
need
to
actually
run.
Your
workload
is
really
critical
as
well,
so
the
demo
we're
going
to
show
is
on
a
cloud
provider,
but
it's
actually
running
on
i3en
instances
on
an
eks
cluster.
So
we're
going
to
be
running
the
demo
on
local
nvme
drives,
so
everything
I'm,
showing
you
will
work
on
any
cloud
provider
or
on-premise
or
any
execution
venue.
A
So
the
demo
is
deliberately
done
to
show
you
that
this
will
run
anywhere
and
you
can
do
this.
The
same
way
as
I
said
on
that
on
the
storage
layer,
I'm
using
I
can
do
the
replication
encryption
fault
tolerance.
So
what
we're
going
to
do
is
we're
going
to
try
and
build
a
demo
where
we
complement
the
cloud
native
postgres
components.
So
things
like
at
rest,
encryption,
which
the
cloud
native
postgres
thing
does
not
do
we're
going
to
turn
that
on
on
the
storage
layer,
so.
A
We're
only
allowed
to
speak
together
from
now
on.
That's
the
contract,
yeah,
okay,
but
the
other
thing
to
say
as
well.
You
can
very
easily
turn
stuff
on
and
off
in
the
different
layers,
so
to
go
ahead
and
just
say:
I'll
just
use
the
storage
class
without
understanding
what
that
storage
class
does
under
the
covers.
If
you've
got
a
storage
array,
that's
replicating
data
to
a
second
site.
You
turn
on
storage
replication
and
you
turn
on
postgres
level
replication.
A
You
can
end
up
with
18
copies
of
the
data
written
to
disk
and
your
you
know.
Your
database
is
only
as
fast
as
the
slowest
right.
So
please
do
ask
your
kubernetes
team
what
the
storage
class
actually
does
and
what
it
looks
like
because
it
really
does
matter.
So
that's
all
I
want
to
say
there.
So
in
this
case
we're
going
to
use
a
couple
of
storage
classes.
A
It's
a
kubernetes
talks.
There's
some
yaml
we're
gonna,
see
that
in
the
video,
so
I'm
not
going
to
talk
too
much
in
detail
other
than
just
say
what
you
can
do
with
the
on
that
layer
is,
you
can
just
add
these
annotations,
so
you
can
turn
on
features
and
turn
off
features
in
different
storage
classes
on
kind
of
dynamically.
A
So
we
will
map
and
the
one
on
the
left
has
got
the
storage
os.com
replicas
2,
the
one
on
the
right
does
not
have
that
so
we're
going
to
do
replication
on
the
storage
class
on
the
left,
at
the
storage
layer
and
replication
at
the
postgres
layer
on
the
right
hand,
side-
and
the
only
other
thing
to
say
is
that
we
talked
about
the
RTO
RPO.
We
talked
about
the
patterns.
The
really
important
thing
is
to
match
them.
You
know
the
right
component
to
the
right,
RTO
RPO.
A
If
you
replicate
at
the
storage
layer-
and
you
only
have
a
single
database
pod-
you
will
have
an
outage
when
we
kill
the
Pod
or
kill
a
node
in
our
kubernetes
cluster.
If
you're
using
postgres
replication,
it
will
just
promote
a
primary
sorry,
a
standby
to
be
a
primary,
and
you
will
not
have
an
impact
to
your
application
running
on
your
kubernetes
cluster.
If
we
kill
a
node
so
think
about
what
your
application
and
your
business
application
design
needs
and
turn
the
right
bits
on
at
the
right
level.
A
A
So
if
you've
got
a
thousand
pods
and
you
need
to
orchestrate
the
backup
of
all
of
them
at
the
same
time
to
recover
an
application,
you
would
want
to
use
a
backup
manager
and
you
wanted
to
do
some
orchestration,
so
we've
got
Partnerships
with
people
like
castan
and
Cloud
Casa,
for
example.
So
you'd
want
to
use
one
of
these
orchestration
engines
to
back
everything
up
at
the
same
time,
because
it's
pointless
backing
up
one
thing
than
the
next
thing
and
having
all
your
application
out
of
sync.
A
A
B
A
It's
going
to
be
a
bit
small,
isn't
it
I
did
try
this
at
home
and
it
did
work
okay
on
on
a
flat
screen,
monitor
so
I
did
test
it.
But
okay,
the
video
I'll
post
on
my
GitHub
I'll,
put
a
link
in
the
notes
at
the
end,
so
you
can
go
ahead
and
we'll
be
on
the
recording
as
well.
But
the
main
thing
is
at
this
bottom
side:
I'm
using
eks
CTL.
A
So
at
the
very
bottom
there
there
was
a
set
of
steps
which
was
to
Prime
the
nvme
drive,
which
so
we're
using
a
local
nvme.
So
this
will
work
as
I
said
in
any
execution
venue,
I've
got
some
yaml
files
up
there,
so
I've
got
two
storage
classes
and
I've
also
got
two
database
files.
So
what
I'm
going
to
do
is
I
think
in
a
second
to
show
you
the
the
storage
classes.
So
in
this
one
we've
got
a
storage
class
which
has
got
the
which
doesn't
have
the
replication
triggered
in
it.
A
But
what
we
know
in
there
there's
one
of
these
annotations
is
storageos.com
forward.
Slash
encryption
equals
true,
so
every
persistent
volume
there
will
be
a
per
persistent
volume,
encryption
key
created
and
then
that
will
be
backed
off
to
by
default.
Of
course,
it's
a
kubernetes
secret,
so
that
will
go
into
the
kubernetes
xcd,
but
there's
also
other
projects,
so
there's
an
open
source
project
which
we've
contributed
to
called
trusso.
So
you
can
integrate
that
into
something
like
a
hashicor
vault,
so
you
can
have
at
rest
encryption
integrated
into
a
Key
Management
Service.
A
A
So
this
is
our
Standalone
database.
I
called
it
Standalone,
because
there's
one
of
them
thought
brilliant
naming
convention
there
and
the
instances
at
the
top
is
set
to
one.
So
in
this
case,
I've
only
got
a
single
PG
data
and
a
single
wow
volume.
So
at
the
bottom,
there's
a
storage
class
for
the
well
storage
and
storage
is
the
PG
data
storage.
A
So
what
we
want
to
do
is
we
want
to
take
the
Standalone
database
and
run
it
on
the
replicated
storage
and
then
we're
going
to
have
another
database
which
is
going
to
be
the
replicated
storage
and
we're
going
to
run
that
on
this
on
the
sorry
replicated
database
and
we're
going
to
run
it
on
the
non-replicated
storage.
Now,
there's
a
really
nice
tool
which
I
found
out.
A
So
you
can
call
that
and
it'll
tell
you
what's
going
on
and
the
thing
you're
looking
for
is
there's
some
okay
labels
in
there,
and
you
can
also
see
things
like
which
one
of
my
right
ahead
logs
how
far
ahead
through
my
transaction
processing
am
I,
and
so
we've
set
up
basically
two
databases
and
they're
nicely
running
at
the
right
speed
and
we've
got
we're
using
local
nvmes.
The
great
thing
about
these
local
nvmes
is
their
sub
millisecond
disk
latency
for
rights,
so
even
with
three-way
replication
across
three
availability
zones.
So
this
is
run.
A
This
was
demo
was
recorded
in
the
Dublin,
so
e
West
1a1b1c,
even
with
three-way
replica
synchronous
replication
between
three
different
zones,
we
can
get
about
30,
000
iops,
just
out
of
the
smallest
instances
you
could
you
can
get
from
that
class,
so
we
can
get
more
and
more
workload
through
these
just
by
beefing
up
the
size
of
the
instances
and
beefing
up
the
size
of
the
network.
Links,
for
example,
there's
also
a
command
line
interface
to
to
the
on
that
storage
layer.
A
So
I've
got
some
commands
here
where
I'm
just
going
to
you
know
pick
a
persistent
volume
claim.
So
this
is
the
thing
that
is
the
you
know
the
most
critical
thing
that
the
Cloud
native
postgres
keys
off
and
just
to
show
you
look,
there's
this
master
line
and
if
we
pick
another,
if
we
pick
another
persistent
volume
claim
from
the
from
the
replicated
database.
Sorry,
the
Standalone
database,
where
we've
got
storage
replication
on
what
you'll
see
is
there'll,
be
a
master
and
there'll
be
a
replica
and
a
replica
so
I'm.
A
A
I
can
set
the
demo
up.
So
we've
got
the
primary
and
the
Standalone
database
running
on
the
same
node
I've
run
through
lots
of
scenarios.
It
doesn't
really
matter
all
I'm
trying
to
show
is
the
different
recovery
mechanisms
that
go
on
in
under
the
covers.
What
I
found
really
interesting
is
there's
about.
I.
Think
it's
about.
A
But
if
you
look
at
the
AWS
console,
there's
already
four
nodes
there.
So
AWS
has
not
waited
there's
already
another
node
in
the
1B
availability.
Zone,
that's
been
spun
up
and
then
what
we
do
is
we
go
through
and
we
basically
see
what's
going
on.
What's
so
not
ready,
scheduling,
disabled
kubernetes
hasn't
even
noticed,
the
machine
has
died.
Yet
kubernetes
is
just
like
it's
not
ready.
It's
not
ready.
A
Eks
has
already
actually
created
a
new
instance
and
is
trying
to
join
it
to
the
cluster.
In
the
background.
So
there's
some
really
interesting
timing,
things
and
the
one
thing
I
took
away
from
this
is:
if
you're
going
to
do
failure
and
disaster
recovery-
and
you
know
testing,
you
need
to
test
the
timing
issues
because
things
can
go
wrong
all
over
the
place.
I
was
Finding
when
I
was
building
the
demos
and
stuff.
So
look,
it
still
doesn't
know
it's
it's
gone.
It
still
thinks
there's
three
nodes
there.
A
So
what
will
happen
and
we
can
speed
up
the
the
demo
a
little
bit
and
just
kind
of
skip
towards
the
end.
What
you'll
see
as
we
go
through?
This
is
once
kubernetes
notices
and
the
timers
have
expired.
This
for
the
Standalone
database.
Kubernetes
go.
Oh
I
just
need
to
start
the
Pod
again,
so
kubernetes
will
spin
the
Pod
up
and
because
at
the
storage
layer
we
were
replicating
the
storage
between
1a1b
and
1C.
A
The
three
availability
zones
at
the
storage
layer,
we'll
promote
one
of
the
storage
replicas
to
be
the
master
of
the
storage
layer
and
that
will
just
connect
to
the
Pod
and
the
Pod
will
start
running
and
I.
Think
I
do
a
bit
where
I
scroll
up
and
I
look
at
the
Riser
head
log,
just
to
prove
that
the
Well
Log
is
where
we
left
it.
Well,
it's
actually
it's
actually
one
more
because
I
think
when
it
does
its
recovery.
It
starts
a
new
Well
Log
as.
A
A
So
if
you
see
on
the
top
left,
I
don't
know,
I
was
I,
almost
missed
it
there,
and
here
we
go
see
a
cube.
Ctlc
and
PG
destroy
replica,
replicated
db2
and
what
you
should
have
seen
in
the
top
left
is
the
pods
back
up
and
happy
and
running
and
in
the
bottom
left.
So
those
were
the
two
cmpg
status
boxes
for
the
Standalone
database
and
the
replicated
database.
A
What
you
would
have
seen
is
those
two
pods
are
now
back
up
and
sorry.
The
the
Standalone
database
with
the
storage
replication
has
just
recovered
and
is
back
up
and
running.
There
was
an
outage
to
the
operations
because
until
kubernetes
and
the
timers
had
all
triggered
in
and
until
the
Pod
had
been
rescheduled,
the
database
was
not
there
and
was
not
alive
and
was
not
healthy
and
not
responding
to
requests,
whereas
the
replicated
DB,
the
cloud
native
postgres
database
was
happy
and
was
running
all
the
way
through.
A
So
we've
gone
through
this,
and
we've
got
okay,
okay
and
we've
done
a
destroy
so
that
pod
will
be
being
restarted.
So
we've
had
a
database
running
on
a
node
we've
unplugged
that
node
from
the
kubernetes
cluster
in
a
very,
very
forceful,
terminated
fashion
and
while
you've
been
watching
this-
and
this
is
real
time
within
I-
think
it's
about
six
minutes
totally
lapsed.
Both
of
those
databases
have
recovered
and
I.
The
one
thing
I
would
say
as
well.
A
I
took
away
from
it
is
I'm,
not
a
postgres
person
by
core
background,
but
the
Simplicity
and
the
ease
and
the
automation.
The
operation
that
this
Cloud
native
postgres
stuff
I
mean
it
was
like
15
lines
of
yaml
to
just
get
a
database
up
and
running,
and
it
just
it
made
my
life
so
much
easier.
And
it's
really
you
know
you
see
you
can
build
very
resilient
patterns.
So
if
you
want
an
RTO
RPO
of
zero,
you
can
use
this
stuff
and
you
can
build.
A
B
I
mean,
ultimately,
it's
all
about
freedom,
I
like
to
say
this
word,
because
it's
it's
up
to
us
and
that's
what
kubernetes
gives
us
okay
open
source
in
general,
we
have
the
possibility
to
run,
for
example,
a
full
open
source
stack
and
another
thing
that
is
important,
especially
I'm.
A
European
for
the
gdpr,
for
example,
is
to
own
our
data.
B
We
have
the
possibility
now
to
retain
control
of
the
data,
full
control
of
the
data
and
decide
if
we
want
the
data
in
on-premise
on
a
multi-cloud,
hybrid
Cloud,
whatever
using
the
same
the
same
infrastructure
by
the
same
configuration
then
custom
optimization.
Maybe
you
want
to
add
more
about
these.
You
know
yeah.
A
So
I
mean
if
you,
if
you
want
to
run
the
database
at
the
lowest
price
point
and
it's
a
very
data
intensive
workload,
you
will
not
find
a
cheaper
way
than
running
it
on
local
nvmes.
No
one's
ever
done
that
because
there's
no,
no
one
ever
thinks
to
do
it,
maybe,
but
using
something
like
on
that.
There's
a
CSI
plugin
that
can
orchestrate
local
nvmes
and
you
get
that
sub
millisecond
response.
So
you
can
do
massive
volumes
of
transactions
through
your
databases.
B
Yeah,
correct
and
again
I
mean
this
is
something
that
I'm
really
happy,
because
we
learned
a
lot
working
with
with,
with
Chris
and
his
team.
We
are
database
people
with
storage
people.
We
actually
understood
each
other's
point
of
view
and
I
think
we
we
are
much
better
now
I
think
we
have
a
better
understanding
of
everything
and
then
finally
devops,
because
if
we
are
here
in
my
opinion,
it's
because
we
have
done
a
journey
that
puts
closer
developers
and
database
administrator
infrastructure
administrators.
B
A
Believe
it's
been
a
great
lot
of
fun.
I
think
we
need
to
wrap
up
now
we're
at
the
end
of
a
time
we'll
hang
around
for
questions.
We've
also
got
a
draw
for
a
massive
Lego
batwing
at
the
on
that
Booth.
So
if
anyone
wants
to
come
and
try
and
win
that
there's
only
about
40
50
people
entered
so
there's
a
really
good
chance,
we're
at
the
back
right
hand
corner
of
the
of
the
of
the
exhibition
Hall
and
we're
going
to
draw
at
half
past
five.