PostgreSQL k8s Charm

charm
,
1

I’ve put together a PostgreSQL Charm for Kubernetes that is ready for wider testing and feedback.

Here is an example deploying PostgreSQL and Mattermost into a k8s model:

juju deploy -n3 cs:~postgresql-charmers/postgresql-k8s postgresql
juju deploy cs:~mattermost-charmers/mattermost --config juju-external-hostname=foo.internal
juju add-relation mattermost postgresql:db
juju expose mattermost

The postgresql-k8s charm deploys PostgreSQL 12, in a high availability configuration (automatic failover requires 3 or more units). The deployment uses repmgr & repmgrd to manage replication and failover, and the charm sets up Kubernetes Service endpoints to route connections through to the current master or load balance to the available standby databases.

postgresql-k8s is a drop in replacement for the IaaS PostgreSQL Charm. It supports cross model relations and may be used as a server for both k8s and IaaS client charms. However, it is not (yet) configurable, and does not provide many features available in the IaaS PostgreSQL Charm. I hope that, if possible, new features are in the form of separate charms which can be related to the PostgreSQL k8s charm, rather than bloating the core charm with options and features that are not always necessary. For example, a pgbackup charm to make logical dumps and exfiltrate to bulk storage, rather than embed this and several variations in the charm. I expect the IaaS charm to take a similar approach over time.

Operator Framework client charms should use the ops-lib-pgsql library to manage their PostgreSQL relations, and Reactive Framework charms should use interface:pgsql.

Bugs can be reported on Launchpad, and feedback here or to postgresql-charmers@lists.launchpad.net.

Code is available in git at Git : Code : charm-k8s-postgresql or git clone git+ssh://git.launchpad.net/charm-k8s-postgresql postgresql-k8s.

2 Likes
2

Excellent stuff. I’ll be testing it with tt-rss later this week :slight_smile:

3

A new version has been published, now requiring Juju 2.9. The charm tripped over two incompatibilities with juju 2.8:

  • The juju-app label used by pods to locate the master pod was renamed to app.kubernetes.io/name.
  • The headless services used to make pod names DNS resolvable no longer resolve. I don’t know what caused that, but Juju 2.9 provides mechanisms that make them unnecessary so they are gone.

When testing, it is worth being a little patient before adding a relation to a client charm. The charm thinks things are ready when the k8s pods have been spun up, and will happily inform relations. However, the pods take some time to setup and there may not yet be any working databases listening for the client requests (Juju automatically retrying failed hooks will take care of this in most cases). I don’t think this race can be addressed until Juju pays attention to the pod readyness checks, invoking the charm when they change state.

4

Thanks, I was seeing problems with this before per Bug #1902680 “OperationalError on charm deployment in k8s model” : Bugs : charm-k8s-postgresql but can confirm it’s working now with revno 4 of the charm.