Could anyone speak to how this compares to other Postgres solutions for Kubernetes?
back
6 comments
We are currently moving to CNPG and have tried CrunchyData and Zalando in the process. The other two we abandoned while trying it out.
Zalando: - Relies on WAL-E which is now obsolete - Documentation all over the place - Hacky setup that deviates from K8s standards (no easy way to set user through supplying secrets, for instance).
In general, it feels like an operator to be used internally at Zalando according to their conventions that they just open sourced. It doesn’t seem like they want (or get time) to support other conventions. I don’t think this is a bad thing, it’s already great Zalando open sourced this. Just important to know when you decide to use it.
CrunchyData: - Incomplete documentation (Certain values settings are missing from their API specs) - Hacky user setup. - Doesn’t support running without backups enabled. (Obviously, you’d never want to run without backups setup on prod. But when testing, it’s nice to not need to have a perfect setup from the start. Without backups, it will let the database pods fill up their PVC’s with a WAL. Even when not doing any writes. It fills up at about 10GB/day.) - Backups seem to randomly fail.
It looks pretty OK otherwise.
CNPG: - Adheres to K8S standards - Seem to realise that an Operator will (currently) not fully replace a DBA. Their kubectl plug-in is great to interact with the cluster.
Obviously we still need to test rollovers and restoring from backups, but so far it’s been easy to setup.
It does suffer from what most operators suffer from; their CRD is a mess. The UID of the Postgres Container is specified on the same indentation level as my switchOverDelay, superuserSecret and bootstrap spec. Would be nice if these would follow a more logical grouping (pod spec, users, switchover).
Can confirm Zalando & Crunchy are quite a mess, contrary to CNPG. See my other post https://news.ycombinator.com/item?id=37618886
Why is wal-e obsolete? I’m assuming you mean the golang replacement wal-g.
See the GitHub: https://github.com/wal-e/wal-e
Unmaintained would’ve made more sense to say, but the maintainer choose the words “obsolete” so I took those. :)
Seems to be obsolete due to a lack of interest and contributions.
I've never used it myself, but while doing research I noticed that it received a lot of praise from users.
One thing that did catch my attention is that it doesn't use statefulsets for the postgres pods. I mostly agree with their reasons, but I haven't taken the time to understand their implementation.
The rationale is here: https://cloudnative-pg.io/documentation/1.20/controller/
I found that to be well-written, so another point for CloudNativePG
Strimzi (Kafka operator) is moving away from StatefulSets for the same reason.
A good comparison with other operators here [2022]: https://blog.palark.com/cloudnativepg-and-other-kubernetes-o...
Personally I've only used Kubegres (https://www.kubegres.io/), which didn't even make the above list. It's ok for a personal project.
All k8s solutions for postgres take subtly different approaches. It seems that they've all converged on the Operator pattern. The basics are easy: run a database process which persists data to a cloud disk of your choice. The hard parts are how to update, migrate, backup, restore, monitor, failover, replicate, etc. These kubernetes "operators" promise to fulfill the role of a DBA but, just like hiring a DBA, it requires buy-in to their approach.
From my experiences with Strimzi, I think of it as "half-managed", like, it'll make doing things like upgrades easy as, but yeah, it's just tooling that makes self-management easier.
I’ve been using it in prod for a while now, pretty happy with it. Solid, integrated pgbouncer, crd based, good license.
I do wish there was a simpler way to handle major version upgrades of pg.
When I looked at some alternatives, these were my thoughts (may be out of date by now)
- kubegres: maintained by one guy, lots of GitHub issues with no responses
- crunchy data pgo: licensing is not obvious, seems to require license in some cases
- stackgres: agpl, no thanks
- zalando: they know pg extremely well, but it’s not kubernetes native. Doesn’t include pgbouncer. Doesn’t handle automatic failover when a node dies, and during testing it often got confused when killing a node.
> Doesn’t handle automatic failover when a node dies
Patroni, the most popular autofailover solution for Postgres, is developed in Zalando. Of course it's included in Zalando operator by default.
I appreciate your perspective, thanks. Major version bumps do seem to be difficult sometimes with pg in my limited experience.
If you are interested, I suggest this article I wrote that covers the current state of major upgrades with CloudNativePG: https://www.enterprisedb.com/blog/current-state-major-postgr...
Exactly what I was wondering about as well. I have no prod experience with it, but e.g. Zalando’s operator has been solid for me.
It’s the opposite.
A Kubernetes solution for Postgres.
Haha, that might be a better way of putting it. "A solution for running Postgres in Kubernetes"