►
Description
PostgreSQL is a powerful, open source object-relational database system. It has more than 15 years of active development and a proven architecture that has earned it a strong reputation for reliability, data integrity, and correctness. By containerizing PostgreSQL, we have enabled rapid deployment of PostgreSQL on a variety of different environments including Docker, Kubernetes, and OpenShift. The Crunchy PostgreSQL Containers‘ open source project delivers PostgreSQL-as-a-Service in addition to administration and monitoring tools in a standardized, scalable, and consistent manner.
In this talk, Sarah Conway, will give an introduction to the project and discuss how Kubernetes users of these containers can leverage an associated project, PostgresOperator [], that uses these containers and provides a higher level automation.
Sarah is a contributor to both Crunchy PostgreSQL Containers Project & Kubernetes’ PostgreSQL Operator open source projects. Sarah is a software engineer at Crunchy Data Solutions, Inc. Additionally, she is an active participant and volunteer in the PostgreSQL community through developing and maintaining various Postgres community websites as well as being on the PostgresOpen SV operations committee for four years. You can follow her here on twitter @xenophenes and on GitHub https://github.com/xenophenes
A
A
Well,
hello,
everybody
and
welcome
again
to
another
OpenShift
Commons
briefing.
This
time
we
brought
back
some
folks
from
the
crunchy
world
of
Postgres
and
Sarah
Conway
is
going
to
give
us
a
talk
on
the
Tanner
izing
post,
grace
cloud.
Natives
we've
had
the
mom
in
the
past,
but
I
think
there's
been
some
interesting
new
updates.
So
we'll
really
looking
forward
to
this
talk,
I
want
to
let
Sarah
introduce
yourself
and
we're
hot
live
Q&A
via
the
chat
and
at
the
end
of
the
talk.
A
B
Thanks
so
much
for
having
me
here
today,
Diane,
my
name
is
Sarah
Conway
I'm,
a
software
engineer
at
crunchy
data
I
wanted
to
talk
to
you
today
about
two
projects:
I'm
invested
in
that
I
assist
in
documenting
and
developing
the
container
suite
and
the
puskás
operator.
This
will
cover
the
overviews
of
both
projects,
including
the
whys
and
how's,
in
addition
to
latest
updates
on
the
projects
and
future
plans.
B
So
what's
the
container
suite?
Well,
it's
currently
a
darker
base
set
of
containers
that
focuses
on
providing
Postgres
as
a
service,
along
with
tools
for
administering
and
monitoring
Postgres,
and
these
containers
it's
also
open
source
and
it's
hosted
on
github.
The
link
is,
on
the
last
slide
to
access
the
repository.
B
You
might
ask:
what
are
the
advantages
to
container
izing
Postgres?
Well,
one
advantage
is
the
ability
to
consistently
and
uniformly
deploy
a
database
within
seconds.
It
can
often
be
extremely
complex
to
spin
up
a
post
ghost
database,
given
its
monolithic
structure,
and
so
this
method
makes
things
much
smoother
for
developers
or
database
administrators
dependencies
they're
no
longer
a
problem.
Infrastructure
costs
is
reduced.
Performance
is
massively
improved
over
virtual
machines
and
you
can
allow
developers
to
more
accurately
recreate
a
consistent
environment
through
development
testing
and
production.
Then
you
also
have
a
separation
of
concerns.
B
This
lets
you
perform
a
database
backup
and
restore
or
other
administration
tasks
in
a
lightweight
manner,
for
spending
at
Postgres.
The
ability
to
spit
up
large
numbers
of
databases
with
a
Rapid
Deployment
is
in
high
demand
unless
you
also
easily
support
a
cloud-based
model
of
deployment.
Currently,
the
base
for
the
container
is
this:
through
docker
and
docker
file
files.
When
the
container
suite
was
first
developed,
it
was
sort
of
a
wild
guess
that
docker
would
be
the
way
to
go.
B
It
would
be
where
the
future
of
containers
was
headed,
and
so
everything
is
currently
based
off
of
that.
However,
as
I'll
be
discussing
a
bit
more
later,
on,
kubernetes
and
OpenShift
is
moving
towards
cryo
technology,
and
so
eventually
we'll
be
adopting
that
in
place
of
or
potentially
in
addition
to
docker,
and
so
you
can
see
all
the
benefits
to
container
eyes
in
your
application.
That
you've
heard
also
applies
to
databases.
B
Life
becomes
easier
with
lightweight
applications,
and
it's
a
great
time
to
be
taking
advantage
of
that,
as
the
technology
is
only
continuing
to
improve
all
the
docker
files
are
designed
in
such
a
way
that
they
are
consistent
in
nature
and
are
all
built
with
either
sent
to
a7
or
l7.
This
allows
you
to
not
only
be
aware
of
security
issues
and
address
those
for
those
specific
environments,
but
it
also
allows
you
to
know
that
the
images
will
all
act
as
expected
in
a
consistent
manner.
B
Other
operating
systems
as
a
base
image
will
potentially
be
developed
and
supported
later
on,
but
for
the
time
being,
those
are
the
only
two
we
support.
These
images
can
also
be
deployed
in
three
primary
kinds
of
deployment
models
which
are
docker,
kubernetes
and
openshift.
We
do
have
helm
charts
currently
supported
as
well
for
a
few
of
our
examples,
but
the
widest
range
of
use
cases
are
supported
on
those
three
specific
environments.
B
This
design
strategy
also
allows
for
easy
customization
for
each
environment,
not
only
for
the
docker
files
themselves,
but
on
a
higher
level.
For
instance,
you
can
modify
the
JSON
files
provided
for
the
kubernetes
and
openshift
environments
in
order
to
best
fit
your
needs.
Both
appointments
allow
you
to
deploy
to
a
single
node
or
multi
node
cluster,
while
the
docker
style
is
a
standalone
docker
deployment,
where
you
can
use
docker,
networking
and
docker
swarm
to
fight
to
provide
multi
host
capabilities,
and
then
you
have
the
issue
persistence.
B
All
the
data
for
the
Postgres
database
in
the
containers
is
mounted
externally
to
the
container
you
get
to
the
files
for
the
container
through
a
volume
out,
and
each
of
these
deployments
give
you
a
variety
of
racing.
Mount
your
Tanner's
from
an
abbess
by
default
to
cluster,
to
dynamic
or
sir,
are
safe
to
empty
der
storage
and
a
bunch
of
others
each
with
our
own
advantages,
disadvantages
and
security
issues.
B
So
a
few
of
the
highlighted
features
here
show
what
was
kept
as
a
main
focus.
Well,
the
entire
suite
was
being
first
developed.
The
crunchy
containers
project
was
designed
to
first
address
the
high
demand
for
streaming
replication
environment.
It
used
to
be
an
incredibly
complicated
process
to
set
that
up,
especially
in
a
consistent
manner,
to
being
able
to
run.
Postgis
like
that
is
important.
B
Multiple
locale
support
is
built
into
the
container
suite
as
well
straight
into
the
docker
files,
and
then
you
have
secret
support
and
kubernetes
and
OpenShift
environments.
You
can
store
secrets
for
your
database
using
group
secrets.
A
nice
feature
specifically
for
openshift
is
the
ability
to
choose
a
random
user
ID
for
the
post
quest
user
rather
than
using
the
default,
and
that's
one
example
of
using
rapper
code
inside
of
the
post
ghost
container,
and
then
you
have
flexibility
in
what
you
can
do
with
that.
B
Postgres
image
such
as
being
able
to
backup
your
store
using
PG
based
backup,
PG,
backrest,
and/or,
PG
dump
and
finally,
with
each
minor
or
major
release
that
comes
out
of
the
suite,
we
always
make
sure
to
add
support
for
the
latest
post
guest
version
and
fully
test
that
all
features
work.
As
expected.
A.
B
Major
design
goal
with
this
project
is
to
ensure
users
can
fully
customize
their
version
of
the
product
to
see
your
needs.
For
instance,
the
setup
that
sequel
file
is
mounted
outside
the
container
itself.
The
users
can
modify
this
and
implement
custom
sequel
statements
for
the
newly
created
containers,
so
if
he
has
some
default
rules
or
objects,
you
know
you'll
want
to
create
everytime.
This
massively
speeds
up
the
process,
the
PGH
be
a
and
post
graphs
configuration
files
or
other
examples,
files
that
you're
commonly
going
to
want
to
be
able
to
access
and
customize.
B
So
you
can
choose
to
either
use
the
default
files
that
are
generated
upon
container
creation
by
Postgres,
or
you
can
mount
them
externally
to
the
container
in
the
persistent
volume
clean
to
allow
you
access
to
configure
those
files
to
fit
your
requirements.
This
gives
you
complete
control
over
these
files.
You
also
have
the
option
of
tweaking
specific
values
in
these
files
or
making
small
changes,
such
as
through
switching
the
environment
variables
in
the
initial
project
setup.
B
These
variables
are
defined
in
your
bash
or
C
file
and
cover
requirements
such
as
the
Postgres
version,
the
version
the
container
suite
to
install
whether
you're,
installing
in
a
centrist
or
rel
environment,
what
namespace,
your
and
so
on
and
so
forth.
And,
finally,
you
can
completely
modify
or
edit
the
docker
file
itself
within
the
project.
If
you
want
to
reduce
the
size
or
add
custom
modules
through
the
file,
the
goal
is
to
make
this
sweet
as
extensible
and
widely
useful
as
possible.
B
The
this
design
goal
gives
users
complete
flexibility
and
what
is
being
developed
and
created
in
their
environments
and
gives
them
a
starting
point
to
work
from
in
configuring
their
clusters,
all
tools
we
have
about
16
or
more
different
containers,
all
serving
different
purposes.
Not
all
of
them
are
listed
here,
but
I
want
to
give
just
a
general
overview
of
what's
offered
in
the
suite.
B
So
you
have
the
crunchy
Postgres
container,
which
can
be
run
in
several
different
deployments,
either
by
itself
as
a
single
primary
database
or
with
synchronous
or
asynchronous
replicas,
and
it
also
comes
with
backup
restore
functionality.
The
backup
container
has
the
specific
Postgres
backup
tool
called
PG
based
backup
that
can
be
executed
against
the
country
Postgres
container.
B
The
Prometheus
can
here
tick
these
metrics
and
host
them
in
its
data
store
and
then
from
there
you
have
Griffin
at
which
grass
sees
collected
metrics
in
a
web-based
dashboard.
You
also
have
crunchy
vacuum,
which
performs
a
puskás
vacuum.
This
is
essentially
the
garbage
collector
of
Postgres
and
reclaim
storage
space
in
addition
to
crunch
GD
ba,
which
has
a
cron
scheduler
functionality
for
DBAs
the
tool
PG
admin
for
is
offered
in
container
form
in
order
to
provide
a
GUI
management
access
for
Postgres
databases,
feedback
you
have
backrest
restore,
produces
the
PG
backrest
project.
This
back.
B
This
backs
up
and
restores
databases.
The
upgrade
container
hosts
the
Postgres
upgraded
utility
in
order
to
perform
major
version
upgrades.
And
finally,
you
have
crunchy
proxy,
which
is
a
small
postgis
aware
proxy
daemon.
It
can
route
sequel
statements
to
the
appropriate
postgis
back-end
within
a
streaming
replication
cluster
and
here's
a
simple
graphic
just
showing
how
all
of
these
containers
are
able
to
interact
with
each
other.
B
You
can
see
the
incoming
application
requests
go
through
the
PG
pool
load
balancing
container
here
which
distributes
the
workload
between
the
primary
replicas
pods
crunchy,
collect
holes,
data
from
the
databases
and
is
processed
into
the
metrics
dashboard.
Where
it's
displayed
through
qivana
after
being
held
in
the
crunchy
Prometheus
datastore,
then
you
have
PG
aDNA
4,
which
is
the
graphical
interface
in
addition
to
PG
Bajor,
and
both
of
these
are
pulling
data
directly
from
the
Postgres
container.
B
B
We
end
up
following
in
their
tracks
and
implementing
new
technologies
in
line
with
their
changes
other
than
that
we're
working
on
continuing
our
continuing
to
stabilize
project
releases,
including
better
testing
processes,
in
addition
to
major
objects
to
documentation
and
examples
over
time,
we're
looking
at
adding
and
new
examples
and
news
cases.
Some
examples
of
this
is
better
PG
backrest
integration
and
the
ability
to
employ
new
Postgres
security
features
in
the
suite.
B
So
we
have
a
couple
customers
who
approached
us
with
a
problem
they
wanted
to
deploy
over
a
thousand
database
applications
and
they
needed
a
way
to
manage
them.
That
solution
became
the
operator.
The
post
case
operator
works
directly
with
kubernetes
in
order
to
provide
operator
capabilities
from
managing
post
guest
clusters
deployed
within
a
kubernetes
or
open
shipped
environment.
This
uses
a
straight
board
command
line
interface.
The
project
also
incorporates
a
REST,
API
and
rest
client
for
interfacing,
with
the
operator.
B
First
of
all,
you
can
find
all
of
this
code
we're
going
to
talk
about
today
on
github
as
a
repository.
It's
a
completely
open
source
project,
so
please
feel
free
to
create
issues
and
make
recommendations
for
features
you'd
like
to
see,
as
we
are
continuing
to
develop
this
project
everything's
there
that
you'll
need,
including
some
basic
documentation.
So
it's
pretty
easy
to
pull
this
down,
build.
It
run
examples
and
just
experiment
with
it.
You
can
install
it
on
anything
that
can
create
a
go
length
binary.
B
It
connects
to
the
kubernetes
cluster
pgo
offers
an
easy
way
for
users
to
make
use
of
the
puskás
operator
and
also
gives
a
view
of
everything
you've
created.
You
can
just
say
show
me
my
post
guest
databases
without
actually
having
to
interact
with
kubernetes
an
operator
is
really
just
a
controller
or
a
piece
of
software,
and
in
this
context
the
focus
of
the
operator
is
on
controlling
deployments
of
Postgres
components
within
the
kubernetes
or
open
chat
cluster.
If
you're
familiar
with
controller
patterns
in
general.
That's
what
this
is
doing.
B
B
You
can
also
use
an
operator
to
automate
things
in
the
world
of
databases,
there's
all
kinds
of
workflows
that
DBAs
would
do
in
this
context.
The
way
we
can
do
is
automate
a
lot
of
those
manual
tasks
and
the
operator
itself
is
a
place
where
we
can
build
those
types
of
praana
mation
layers.
This
particular
operator
itself
has
built-in
Cobra,
which
is
a
go
link
library
and
it
uses
the
kubernetes
client
api
for
Galang.
There's
a
link
there.
B
It's
a
pretty
interesting,
open
source
project
client
go
that
forms
the
basis
for
the
operator,
and
it
allows
me
to
interact
with
the
kubernetes
api
with
customized
code.
These
interactions
include
things
like
updating
labels,
the
containers
creating
and
deleting
containers
everything
it
does
is
based
upon
leveraging
that
client
API.
B
This
operator
is
different
from
most
other
operators,
in
that
this
one
has
a
command-line
interface
that
allows
for
easy
interaction
from
a
command.
Like
perspective,
the
operator
works
a
lot
like
qu
cuddle
or
the
OC
command,
and
that
allows
you
from
your
desktop
the
ability
to
interact
directly
with
the
never
shipped
api's,
and
whenever
you
do
that,
you
can
get
information
back
from
the
cluster.
B
You
can
also
create
objects
using
the
command
line
interface
and
that's
the
primary
means
right
now
for
the
operator
understand
what
you
want
it
to
do
and
for
you
to
cause
it
to
do
things.
The
operator
runs
as
a
standard
deployment.
You
run
it
just
like
any
other
deployment
in
your
environment
and
after
being
deployed,
it
sits
out
there
and
watches
for
changes
on
custom
resource
definitions
that
we
define
to
manage
Postgres
deployments.
B
Cr
DS
are
a
customized
template
based
approach
for
allowing
users
and
ability
to
define
the
makeup
of
a
puskás
cluster
kubernetes
recently
switched
over
to
these
in
place
of
third-party
resources.
They're,
essentially
serving
a
same
purpose
of
them.
They're
just
a
means
to
catalog
and
store
metadata
and
interact
with
the
operator
through
the
standard
Cuban
IDs
API,
it
may
be
a
primary
database
can
a
container
or
a
series
of
replica
containers
or
a
series
of
services
for
those.
B
Maybe
even
a
post
pest
base
router
proxy,
but
all
those
things
make
up
what
we're
calling
a
post
gives
cluster
you
can
find
those
in
a
template.
The
operator
is
designed
so
that
you
can
add
your
own
set
of
templates
to
meet
your
particular
requirements
and
there's
a
default
initial
definition
that
over
time
you'll
see
new
ones
added
into.
B
There
are
six
different
options
or
no
six
different
objects
that
the
operator
considers
to
be
what
defines
a
post
rest
cluster
here
there
that
are
created
with
just
one
command
in
post
quests.
You
can
have
a
primary
database
alongside
a
series
of
read-only
replica
databases,
connect
to
it
in
its
replicated
State,
and
then
you
can
put
services
out
in
front
of
those
databases,
and
these
also
have
related
person,
persistent
volume
claims
and
there's
lots
of
other
things
going
on
here.
B
B
This
is
a
common
question
why
the
operator,
when
it's
possible
to
just
run
the
containers,
build
templates
and
deploy
I've
been
working
that
way
for
a
couple
years,
The
Container
suite
has
fleshed-out
documentation
plenty
of
examples
and
easy
at
run
scripts
and
if
you're
a
developer,
a
good
DevOps
guy
is
fairly
simple
to
put
together
something
similar.
That
suits
your
needs.
B
Well,
the
operator
is
useful
for
users
that
require
a
large
number
of
puskás
containers
and
one
of
means
automating
their
DBA
tasks
or
simply
want
to
ease
your
user
interface
and
managing
the
deployment
of
Postgres
compressors
I've
listed
a
few
reasons
here,
where
you
might
want
to
consider
using
the
operator.
It's
really
geared
towards
people
who
wish
to
automate
workflows
around
databases.
These
are
things
that
a
DBA
would
typically
want
to
do,
such
as
backing
up
or
restoring
databases,
reducing
human
errors.
B
You
don't
necessarily
have
to
build
your
own
set
of
scripts
around
the
base
level
container
to
do
certain
things
and
when
you
start
working
with
a
large
number
of
database
deployments
that
can
really
get
unwieldy
over
time,
given
all
the
things
that
make
up
a
functional,
robust,
Postgres
cluster.
So
without
some
sort
of
automation,
you
have
a
lot
of
things.
You
have
to
manually
keep
track
of
some
people
that
are
deploying
lots
of
databases.
B
They
want
the
ability
to
implement
a
set
of
standard
practices
or
policies
around
their
databases,
so
the
operator
gives
them
a
set
of
means
to
do
so,
and
it
allows
for
very
specific
needs
using
sequel
files.
Once
you
have
the
pgo
client
up
and
running,
it's
really
very
simple
to
actually
run
and
execute
commands
to
do
complex
tasks.
It's
quite
easy
to
use
I'll
be
showing
some
examples
of
the
interface
later
on.
The
operator
really
shines
when
it
comes
to
large-scale
deployments.
B
If
you
have
say
hundreds
of
Posca
state
basis
that
you
want
to
manage,
that's
the
main
value
with
the
operator.
It
gives
you
the
ability
to
collect
and
maintain
metadata
on
all
these
clusters,
and
you
can
query
based
on
that.
It
helps
you
navigate
across
large
numbers
of
databases
on
openshift,
complex
orchestrations
is
another
one.
It
gives
you
the
ability
to
develop
advanced
pieces
and
a
database
multi
step
or
multi
component
tasks.
That
would
otherwise
be
complex
to
do.
B
B
Crunchy
has
built
a
container
catalog
to
support
deployment
and
administration
of
Postgres.
These
containers
are
the
building
blocks
used
by
the
operator,
so
the
operator
depends
on
the
set
of
base
containers
to
behave
and
work
to
deploy
Postgres.
The
crunchy
containers
suite
actually
supplies
five
of
these
containers.
The
crunchy
Postgres
back
up,
collect
metrics
and
upgrade
containers
to
be
specific,
and
the
operator
will
use
these
as
building
blocks.
B
The
operator
can
be
manipulated
using
a
set
of
commands
issued
by
the
command
line.
Interface,
client
called
pgo
from
the
command
line.
You
can
do
a
variety
of
commands
and
the
first
thing
is
creating
a
cluster
deployment
which
allows
you
to
create
the
services
deployments
QVC's
and
everything
else
in
that
one
command.
Likewise,
you
can
delete
the
cluster
or
show
all
the
running
parts.
B
Pgo
tests
simply
runs
a
sequence
of
piece,
equal
commands
against
the
cluster,
and
this
ensures
everything's
up
and
working
and
will
also
print
out
the
equivalent
commands
that
are
used
if
you
want
to
actually
manually
connect
to
the
cluster
or
test
it.
The
only
thing
to
note
with
the
delete
command
is
that
it
does
not
delete
the
PBC.
This
allows
you
to
ensure
that
your
PVC
with
all
your
post
custody
at
a--,
is
not
deleted
by
mistake.
B
Additionally,
this
allows
for
the
workflow
for
backing
up
and
restoring
a
database
or
an
upgrade
to
drop
the
containers,
but
keep
the
Phoebe
C's
working
around
them.
Pgo
show
PVC,
allows
you
to
display
the
content
to
the
dedicated
persistent
volume
claim
similar
to
the
LS
command.
Pgo
scale
lets
you
scale
up
the
number
of
read-only
replicas
in
the
deployment
from
from
the
default
of
zero.
B
When
you
scale
up
the
number
of
replicas
to
one,
it
will
have
spin
up
a
read-only
replica
which
will
eventually
rise
to
the
same
level
as
the
master
database
after
a
period
of
time,
depending
on
how
large
your
master
database
is
right.
Now,
these
replicas
are
asynchronous,
but
we
will
later
be
adding
and
support
for
synchronous
replicas.
In
addition
to
the
ability
to
scale
down
replicas,
the
default
is
set
to
zero,
because
it's
pretty
unnecessary
for
testing
environments
or
most
common
uses
of
the
operator
have
more
than
that.
B
Pgo
back
have
performed
a
full
database,
backup
with
the
PG
based
backup
utility
and
it's
tortoises
back
up
on
a
persistent
volume
claim,
with
youth
in
reference
to
restore
PG,
restore,
takes
those
backup,
PVC
and
path
flags
and
creates
a
new
database
from
that
backup
to
create
the
restore
cluster,
and
you
can
also
specify
secret
fum
in
order
to
copy
through
credentials
over
from
that
previous
cluster.
That
will
have
its
own
set
of
credentials.
B
Pto
upgrade
is
the
ability
to
perform
a
major
or
minor
puskás
upgrade.
This
is
useful
if
you,
for
example,
have
a
database
running
Postgres,
9.6
and
you're
looking
to
upgrade
to
the
next
point.
Release
all
you
need
to
do
is
say:
PG
upgrade
and
perceives
to
take
down
the
image
and
bring
it
back
up
with
a
new
image
with
the
same
data.
The
default,
if
you
don't
specify
a
flag,
is
a
minor
upgrade.
B
If
you
specify
the
major
upgrade
flag,
this
causes
a
job
to
be
executed,
which
runs
the
Postgres
upgrade
utility
and
this
pins
up
a
new
version
and
upgrades
old
data
into
a
new
persistent
volume
claim,
causing
the
containers
to
be
dropped
and
recreated
to
use
the
new
PBC
it's
pretty
yeah,
and
then
we
have
the
create
policy
command,
which
is
a
way
to
create
a
sequel
based
policy
and
give
it
a
common
name.
This
is
useful
for
people
with
this
series
of
sequel
statements
that
they
want
to
apply
against
the
database.
That's
post,
guest
user.
B
These
can
be
security,
related
application
related,
really
anything
in
like,
but
basically
their
pieces.
The
sequel
that
you'd
want
to
name
and
then
you
can
apply
those
towards
a
series
of
clusters
based
on
a
selector
criteria.
This
sequel
will
eventually
get
applied
and
run
on
the
puskás
database
by
the
post
cast
user
by
default.
Although
you
can
always
define
a
specific
user
inside
of
those
sequel
statements,
pgo
label
allows
you
to
create
a
label
to
be
applied
to
a
subset
clusters.
B
B
Finally,
pgo
user
update
passwords
allows
you
to
change
the
password
for
all
users
and
in
my
cluster
kick
cluster.
There
are
many
more
commands
and
variations
of
commands
in
this,
including
new
user
administration,
commands
in
the
last
release,
and
you
can
find
explanations
and
examples
of
all
of
these
in
that
github
link.
B
Now,
for
the
highlights
of
the
last
few
releases
for
the
operator,
the
main
changes
in
the
last
three
releases
was
the
addition
of
basic
username
password
authentication,
including
password
management
and
the
ability
to
define
expiration
dates
for
passwords.
These
credentials
are
currently
stored
in
kubernetes
secrets.
We
also
added
TLS
support
for
the
API
server
and
now
listens
on
port
8
443,
with
sample
certificates
and
keys
included
in
version.
2.3
modifications
were
also
done
to
build
on
top
of
kubernetes
one
point
important
five
independent
scenes,
such
as
client
go
and
API
machinery.
B
There
are
multiple
plants
in
place
right
now,
namely
focusing
on
adding
in
new
use
cases
that
allow
for
advanced
Postgres
administration
and
automation
of
common
DBA
tasks.
For
example,
the
ability
was
added
to
delete
a
clusters,
data
files
and
backups
in
order
to
completely
clean
up
a
deployed
cluster.
This
command
also
removes
the
PVCs,
whereas
before
those
PVCs
would
have
would
have
had
to
be
deleted
individually.
B
B
A
Was
great
Sarah
and
very
timely?
There's
been
a
lot
of
releases
since
the
last
time.
Anyone
from
crunchy
talk
so
that
that's
really
good
to
see
the
progress
and
you
guys
have
been
sort
of
our
poster
child
for
how
to
cut
container
ace
services.
So
it's
been
wonderful
working
with
your
team.
There's
a
couple
of
questions,
the
first
one
we
may
have
missed
it,
but
is
that
pgo
API,
something
you
install
separately
or
is
that
a
container
deployment
it.
B
A
B
B
We
do
like
I
said
we
only
use
an
offense
at
this
time.
That's
what
we
walk
you
through
in
the
instructions
and
how
that's
how
the
examples
are
set
up.
We
are
looking
at
moving
it
towards
the
use
of
bless,
your
storage,
we're
thinking
about
making
that
the
standard
for
this
week
and
including
including
the
installation
instructions.
B
A
I
think,
that's
all
the
questions
we
have
I'm
gonna,
get
people
a
couple,
more
checks
and
who
we
ended
up
with
quite
a
few
people
listening
in.
So
that's
good
and
it's
really
you've
done
a
great
job
in
giving
the
resources
for
where
people
can
can
get
a
hold
of
more
information
or
ask
more
questions.
So
thank
you
for
that.
A
few
more
minutes
to
see
if
there's
anything
else,
Peter
did
that
answer.
Your
question
about
storage
is
my
question
to
you:
is
his
voice
isn't
activated
today,
so
he's
just
doing
stuff?
A
Food
chat,
I
think
that
I
think
you've
answered
everyone's
questions
and
done
an
awesome
job
of
covering
a
lot
of
information.
So
if
people
are
looking
or
are
using
crunchies
containerized
Postgres,
please
reach
out
to
Sarah
and
give
them
your
feedback
ask
for
new
issues
and
we'll
post
this
presentation
up
on
the
open
ship
blog
shortly,
along
with
the
slides
and
all
the
links.
So
thanks
again
Sarah
for
taking
this
one
on
and
and
giving
us
this
good
background
err.