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

31–38 of 38 posts

Re: Pgo: The Postgres operator from crunchy data

#31

Post by kmarc »

smartbit wrote: post #28
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.

Did we work on the same project? I was also responsible to integrate strimzi (redhat amq streams) and gosh that's a quality piece of software!

Re: Pgo: The Postgres operator from crunchy data

#32

Post by Johnnyq72 »

CloudNativePG community member here.

I think this is a super interesting space. What I mean by that is the fact we have Postgres, which is arguably one of the most successful publicly governed open source project out there, for many decades! That meats on of the most vibrant and transformative publicly governed projects as well, called Kubernetes (CNCF).

Why then consider a (proprietary) vendor governed (open source) project to bring these two technologies together? With CloudNativePG, you bring these two super strong communities together using these exact same governance principles, enabling everyone to benefit and contribute.

It is my conviction that this is going to be one of those elements that is going to contribute to the ongoing transformation of data management today.

Re: Pgo: The Postgres operator from crunchy data

#33

Post by gbartolini »

uberduper wrote: post #26
gbartolini wrote: post #22

Earlier quoted context omitted.

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…

I agree with your view point and concerns.

That is why we took the approach to reduce the number of components and integrate everything in Kubernetes, especially with logging (we directly log in JSON to standard output) and the usage of application containers, which enables us to cover the case of troubleshooting via the fencing mechanism (your pods are up, you can access storage, but Postgres is down, giving you the possibility to check even possible data corruption issues).

Also, the status is directly available in Kubernetes, so in our view easier for Kubernetes administrators.

Finally, the source code is open source and directly available for inspection - if you want to understand what is happening.

Re: Pgo: The Postgres operator from crunchy data

#34

Post by Johnnyq72 »

uberduper wrote: post #26
gbartolini wrote: post #22

Earlier quoted context omitted.

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…

So, instead of (re-)inventing the wheel, with something like CloudNativePG, I would encourage your team to look into this, perhaps help contribute to better documentation. I believe that would be the way to a) get your project to benefit from using an operator for Postgres (hence scaling / benefitting more and more quickly) and it would b) help a great bunch of other folks to also benefit from that shared knowledge.

Re: Pgo: The Postgres operator from crunchy data

#35

Post by Johnnyq72 »

Johnnyq72 wrote: post #32

CloudNativePG community member here. I think this is a super interesting space. What I mean by that is the fact we have Postgres, which is arguably one of the most successful publicly governed open source project out there, for many decades! That meats on of the most vibrant and transformative publicly governed projects as well, called Kubernetes (CNCF). Why then consider a (proprietary) vendor governed (open source)…

For those who would be interested, I wrote a bit about it here: http://jk-consult.nl/a-new-north-star-has-risen/

Re: Pgo: The Postgres operator from crunchy data

#36

Post by loganloganlogan »

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

Another great resources is https://operatorhub.io/ which lets you search by certain parameters; as well as https://dok.community/landscape/.

Re: Pgo: The Postgres operator from crunchy data

#37

Post by loganloganlogan »

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.

This survey (1) shows that the majority of orgs develop their own operators, perhaps related to what you say here. Do you think industry standards for operators would move things in the right direction?

(1) https://dok.community/wp-content/uploads/2021/10/DoK_Report_...

Re: Pgo: The Postgres operator from crunchy data

#38

Post by hardwaresofton »

gbartolini wrote: post #21
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...

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

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!

Post reply on HN