4 ms·

Could anyone speak to how this compares to other Postgres solutions for Kubernetes?

rollulus 3y ago
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.
zinclozenge 3y ago
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.
- remram 3y ago
  The rationale is here: https://cloudnative-pg.io/documentation/1.20/controller/ https://cloudnative-pg.io/documentation/1.20/controller/
  - uneekname 3y ago
    I found that to be well-written, so another point for CloudNativePG
  - EdwardDiego 3y ago
    Strimzi (Kafka operator) is moving away from StatefulSets for the same reason.
nz_cal 3y ago
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.
- uneekname 3y ago
  I appreciate your perspective, thanks. Major version bumps do seem to be difficult sometimes with pg in my limited experience.
  - gbartolini 3y ago
    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-postgresql-upgrades-cloudnativepg-kubernetes https://www.enterprisedb.com/blog/current-state-major-postgr...
- samokhvalov 3y ago
  > 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.
sieabahlpark 3y ago
[dead]
fijiaarone 3y ago
It’s the opposite. A Kubernetes solution for Postgres.
- uneekname 3y ago
  Haha, that might be a better way of putting it. "A solution for running Postgres in Kubernetes"
perrygeo 3y ago
A good comparison with other operators here [2022]: https://blog.palark.com/cloudnativepg-and-other-kubernetes-operators-for-postgresql/ https://blog.palark.com/cloudnativepg-and-other-kubernetes-o... Personally I've only used Kubegres (https://www.kubegres.io/ 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.
- EdwardDiego 3y ago
  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.
JimBlackwood 3y ago
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).
- smartbit 3y ago
  Can confirm Zalando & Crunchy are quite a mess, contrary to CNPG. See my other post https://news.ycombinator.com/item?id=37618886 https://news.ycombinator.com/item?id=37618886
- koolba 3y ago
  Why is wal-e obsolete? I’m assuming you mean the golang replacement wal-g.
  - JimBlackwood 3y ago
    See the GitHub: https://github.com/wal-e/wal-e 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.

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.

zinclozenge 3y ago

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.

remram 3y ago
The rationale is here: https://cloudnative-pg.io/documentation/1.20/controller/ https://cloudnative-pg.io/documentation/1.20/controller/
- uneekname 3y ago
  I found that to be well-written, so another point for CloudNativePG
- EdwardDiego 3y ago
  Strimzi (Kafka operator) is moving away from StatefulSets for the same reason.

nz_cal 3y ago

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.

uneekname 3y ago
I appreciate your perspective, thanks. Major version bumps do seem to be difficult sometimes with pg in my limited experience.
- gbartolini 3y ago
  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-postgresql-upgrades-cloudnativepg-kubernetes https://www.enterprisedb.com/blog/current-state-major-postgr...
samokhvalov 3y ago
> 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.

sieabahlpark 3y ago

[dead]

fijiaarone 3y ago

It’s the opposite. A Kubernetes solution for Postgres.

uneekname 3y ago
Haha, that might be a better way of putting it. "A solution for running Postgres in Kubernetes"

perrygeo 3y ago

A good comparison with other operators here [2022]: https://blog.palark.com/cloudnativepg-and-other-kubernetes-operators-for-postgresql/ https://blog.palark.com/cloudnativepg-and-other-kubernetes-o... Personally I've only used Kubegres (https://www.kubegres.io/ 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.

EdwardDiego 3y ago
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.

JimBlackwood 3y ago

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).

smartbit 3y ago
Can confirm Zalando & Crunchy are quite a mess, contrary to CNPG. See my other post https://news.ycombinator.com/item?id=37618886 https://news.ycombinator.com/item?id=37618886
koolba 3y ago
Why is wal-e obsolete? I’m assuming you mean the golang replacement wal-g.
- JimBlackwood 3y ago
  See the GitHub: https://github.com/wal-e/wal-e 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.