3 ms·

Have chatted with the guy who builds kubegres, it’s a really solid solution and is meant to be better integrated (CRDs) and more of the reliable parts of the pg

Have chatted with the guy who builds kubegres, it’s a really solid solution and is meant to be better integrated (CRDs) and more of the reliable parts of the pg stack. It looks super solid. Unfortunately I can’t vouch for it in production yet since I still write my own resources but for me Zalando is #1 and Kubegres is either 2nd or 3rd. https://www.reddit.com/r/PostgreSQL/comments/mqrsbn/kubegres_is_a_kubernetes_operator_for_postgresql/ https://www.reddit.com/r/PostgreSQL/comments/mqrsbn/kubegres...

gbartolini 4y ago
As maintainer of the project, I suggest looking at CloudNativePG, which is production ready (cloudnative-pg.io).
- hardwaresofton 4y ago
  Super late, but just got a chance to take a look -- maybe worth a mention that it's started by you folks over at EDB! Feels like all the Postgres enterprises are making kubernetes operators these days -- probably seeing it as a way to stay in the game/relevant. Just like before when I benefited from EDBs contributions to pg as a whole (and advancing the cause of pg), I look forward to benefiting again!
smartbit 4y ago
Could you elaborate why Zalando is #1? We abandonded Zalando after failing to set it up properly. Don’t remember the details, but do remember that the setup is leaning towards the internal infrastructure at Zalando.
- hardwaresofton 4y ago
  I personally preferred Zalando for the following reasons (this is from quite early on, when Zalando and Crunchy were the only options and differed more in approach): - Focus on CRDs versus outside tools (crunchy used to insist on pgo and while it's not required, I don't really want another CLI to manage/use) - Amount of open conversation, conference talks etc around Zalando's solution and why they've built their solution/how they've scaled it - No specific need for pgadmin/badger/extra logging features (I might feel differently these days!) - Customizable pods These days both of these projects are very similar overall, and I haven't compared them recently. Looking back at my notes I had this written down: > Looks like Zalando is probably the winner (https://www.youtube.com/watch?v=WBdNVrffOSo https://www.youtube.com/watch?v=WBdNVrffOSo) The video is old and in Japanese but basically: - scale in/out are similar - RBAC control is similar - Automatic version upgrades (only Zalando supported rolling update at the time) - Zalando had PVC-driven volume resize vs Crunchy required cluster change It's been a year so maybe they're probably even more similar now but I'd love to hear what I'm missing if I'm wrong. Some more resources: https://blog.flant.com/comparing-kubernetes-operators-for-postgresql https://blog.flant.com/comparing-kubernetes-operators-for-po... https://www.youtube.com/watch?v=3TFXztwat_s https://www.youtube.com/watch?v=3TFXztwat_s These days I might lean Crunchy -- but a lot of the things that would be gaps (like no built in postgres support) I would actually opt to solve myself with a different operator (ex. Prometheus Operator) or just adding a deployment myself (when needed). Taking another quick look today, the differences I see are: - customizable tablespaces with Crunchy - local backups with pgbackrest + crunchy (and in general wal-g is preferred to wal-e so zalando is a little behind there) Neither of them have citus though, which I think will be a huge game changer as a default-include for their pg images.

gbartolini 4y ago

As maintainer of the project, I suggest looking at CloudNativePG, which is production ready (cloudnative-pg.io).

hardwaresofton 4y ago
Super late, but just got a chance to take a look -- maybe worth a mention that it's started by you folks over at EDB! Feels like all the Postgres enterprises are making kubernetes operators these days -- probably seeing it as a way to stay in the game/relevant. Just like before when I benefited from EDBs contributions to pg as a whole (and advancing the cause of pg), I look forward to benefiting again!

smartbit 4y ago

Could you elaborate why Zalando is #1? We abandonded Zalando after failing to set it up properly. Don’t remember the details, but do remember that the setup is leaning towards the internal infrastructure at Zalando.

hardwaresofton 4y ago
I personally preferred Zalando for the following reasons (this is from quite early on, when Zalando and Crunchy were the only options and differed more in approach): - Focus on CRDs versus outside tools (crunchy used to insist on pgo and while it's not required, I don't really want another CLI to manage/use) - Amount of open conversation, conference talks etc around Zalando's solution and why they've built their solution/how they've scaled it - No specific need for pgadmin/badger/extra logging features (I might feel differently these days!) - Customizable pods These days both of these projects are very similar overall, and I haven't compared them recently. Looking back at my notes I had this written down: > Looks like Zalando is probably the winner (https://www.youtube.com/watch?v=WBdNVrffOSo https://www.youtube.com/watch?v=WBdNVrffOSo) The video is old and in Japanese but basically: - scale in/out are similar - RBAC control is similar - Automatic version upgrades (only Zalando supported rolling update at the time) - Zalando had PVC-driven volume resize vs Crunchy required cluster change It's been a year so maybe they're probably even more similar now but I'd love to hear what I'm missing if I'm wrong. Some more resources: https://blog.flant.com/comparing-kubernetes-operators-for-postgresql https://blog.flant.com/comparing-kubernetes-operators-for-po... https://www.youtube.com/watch?v=3TFXztwat_s https://www.youtube.com/watch?v=3TFXztwat_s These days I might lean Crunchy -- but a lot of the things that would be gaps (like no built in postgres support) I would actually opt to solve myself with a different operator (ex. Prometheus Operator) or just adding a deployment myself (when needed). Taking another quick look today, the differences I see are: - customizable tablespaces with Crunchy - local backups with pgbackrest + crunchy (and in general wal-g is preferred to wal-e so zalando is a little behind there) Neither of them have citus though, which I think will be a huge game changer as a default-include for their pg images.