14 points eatonphil | 7 comments | | HN request time: 0.868s | source | bottom
1. richwater ◴[] No.44572399[source]
This article reeks of AI generation
replies(2): >>44572458 #>>44572487 #
2. Flux159 ◴[] No.44572454[source]
I'm not sure I would say this is solved - having used CNPG with GKE, I ended up moving off of hosting Postgres inside of Kubernetes & moving to Cloud SQL and Spanner for storing state in my apps.

Few issues I found was that having stateful sets caused GKE to be unable to automatically update in my cluster setup. I had a read-write and read replica for a few postgres databases & the operator wasn't consistent with what pod id was read-writeable (you were able to retrieve this info from metadata though, so could script around it). Then having to setup backups to GCS manually & needing to ensure that they would work correctly to restore - easier to just pay GCP to deal with all of this with Cloud SQL.

3. kassner ◴[] No.44572458[source]
I’d say more of a copy-paste from a different website. Most of the code blocks have a “CopyEdit” on line 2.
4. daveguy ◴[] No.44572487[source]
I found it way more coherent, succinct, insightful, and well organized than the vast majority of slop that comes out of an LLM.
5. ghc ◴[] No.44572509[source]
What is this, AI slop? Kubernetes operators have been around for ages. Heck, the OReilly book on them (https://www.amazon.com/Kubernetes-Operators-Automating-Conta...) was published in 2020.
6. michalion ◴[] No.44572602[source]
The tone of the article makes is sound like an ad. Not to mention promoting your own product.