Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pgo: The Postgres operator from crunchy data

github.com

Post reply on HN
Print view View original

21–30 of 38 posts

Re: Pgo: The Postgres operator from crunchy data

#21

Post by gbartolini »

hardwaresofton wrote: post #12
noodlesUK wrote: post #10

How does this compare with something like kubegres? https://www.kubegres.io/

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

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

Re: Pgo: The Postgres operator from crunchy data

#22

Post by gbartolini »

uberduper wrote: post #16

I cannot trust critical infrastructure components to 3rd party kubernetes operators. I don't like operators (I didn't write) in general because I find them too opinionated and obfuscated. It's unbelievable to me that someone would deploy a production datastore using one.

Can you please elaborate about obfuscation?

Regarding being opinionated I believe that it is what we expect from an operator. An operator simulates what human DBAs in this case would do. I am a maintainer of CloudNativePG, and I have been running and supporting PostgreSQL in production for 15+ years, creating also another open source software for backups (Barman). In CloudNativePG we have basically translated our recipes into Go code and tests.

Many people believe that databases should not run in Kubernetes. I not only believe the opposite, I believe that running Postgres in Kubernetes represents the best way, potentially, to run Postgres out there.

Re: Pgo: The Postgres operator from crunchy data

#23

Post by gbartolini »

bo0tzz wrote: post #5
vbezhenar wrote: post #2

Another popular alternative: https://github.com/zalando/postgres-operator New player from Enterprise DB: https://github.com/cloudnative-pg/cloudnative-pg

+1 for cnpg - I couldn't get any of the other operators to work well for me, but cnpg has been a blast.

Thank you!

Re: Pgo: The Postgres operator from crunchy data

#24

Post by gbartolini »

kmarc wrote: post #8

I used this in the past. Helped a lot with provisioning micro-pg-clusters. But honestly, the project always felt like a one-man-show, some (realy great) dev had a working set of scripts and kubernetized / operatorized it, but the whole thing feels hacky as hell. I'd still give a try if I ever needed postgresql again, but I would also know that I need to implement (again) my set of scripts and hacks on top of it.

Maintainer of CloudNativePG here.

Back then, we evaluated Crunchy Operator's source code. Being primarily imperative and using an external tool for failover, where the two main reasons we decided to start a new project in 2019 which was entirely declarative and purely based on the Kubernetes API server for cluster status. Such project was released open source last April under the name CloudNativePG and hopefully it will enter the CNCF Sandbox soon (fingers crossed).

Re: Pgo: The Postgres operator from crunchy data

#25

Post by sylvainkalache »

In case some of you are interested in learning more about running databases on Kubernetes, or more generally stateful workloads, there is a community dedicated to that https://dok.community/

I a am part of the community team. We have weekly live streams/blog posts about the topic and a Slack channel.

Re: Pgo: The Postgres operator from crunchy data

#26

Post by uberduper »

gbartolini wrote: post #22
uberduper wrote: post #16

I cannot trust critical infrastructure components to 3rd party kubernetes operators. I don't like operators (I didn't write) in general because I find them too opinionated and obfuscated. It's unbelievable to me that someone would deploy a production datastore using one.

Can you please elaborate about obfuscation? Regarding being opinionated I believe that it is what we expect from an operator. An operator simulates what human DBAs in this case would do. I am a maintainer of CloudNativePG, and I have been running and supporting PostgreSQL in production for 15+ years, creating also another open source software for backups (Barman). In CloudNativePG we have basically translated our rec…

What I've seen from teams that use operators is that nobody ends up understanding how to manage the situation when something goes awry.

I've run into way too many exotic edge cases with kubernetes to trust an operator to do the right thing with data I care about. Most especially when the operator is also managing the replication and replicas and their underlying storage.

I am pro running datastores and other stateful workloads on kubernetes. I've been running databases on kubernetes since petSets.

Re: Pgo: The Postgres operator from crunchy data

#27

Post by smartbit »

hardwaresofton wrote: post #12
noodlesUK wrote: post #10

How does this compare with something like kubegres? https://www.kubegres.io/

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

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.

Re: Pgo: The Postgres operator from crunchy data

#28

Post by smartbit »

kmarc wrote: post #8

I used this in the past. Helped a lot with provisioning micro-pg-clusters. But honestly, the project always felt like a one-man-show, some (realy great) dev had a working set of scripts and kubernetized / operatorized it, but the whole thing feels hacky as hell. I'd still give a try if I ever needed postgresql again, but I would also know that I need to implement (again) my set of scripts and hacks on top of it.

> the whole thing feels hacky as hell

Couldn’t agree with you more, especially if you’re used to the quality of strimzi.

Re: Pgo: The Postgres operator from crunchy data

#29

Post by hardwaresofton »

smartbit wrote: post #27
hardwaresofton wrote: post #12

Earlier quoted context omitted.

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

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.

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)

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

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.

Re: Pgo: The Postgres operator from crunchy data

#30

Post by nwmcsween »

PeterZaitsev wrote: post #14
mdasen wrote: post #6

https://www.crunchydata.com/developers/terms-of-use Before using Crunchy Data, I'd read their terms of use. "without an active Crunchy Data Support Subscription or other signed written agreement with Crunchy Data are not intended for... using the services provided under the Program (or any part of the services) for a production environment, production applications or with production data" https://hub.docker.com/r/cru…

CEO Percona Here. It is more than "Percona Thinks" We have number of customers who started using Crunchy Kubernetes Operator based solution thinking it is Open Source and were contacted by Crunchy Sales team to indicate they need subscription to use it. This was one of the reasons for them to move to Percona Operator for PostgreSQL which does not require any commercial relationship with Percona to use in practice and…

The percona pgo fork is quite a few versions behind the crunchydata pgo which has more declarative configuration, this is what ultimately made me reconsider persona pgo.
Post reply on HN