[HN Gopher] Run PostgreSQL. The Kubernetes Way
___________________________________________________________________
Run PostgreSQL. The Kubernetes Way
Author : mooreds
Score : 65 points
Date : 2023-09-22 18:47 UTC (4 hours ago)
(HTM) web link (cloudnative-pg.io)
(TXT) w3m dump (cloudnative-pg.io)
| dvh wrote:
| Was it's always spelled kubernetes? In my "Mandela timeline" it
| was kubernets and just recently switched.
| martijnvds wrote:
| K8s was always K-ubernete-s (8 letters)
| c0brac0bra wrote:
| Always AFAIK. It's a Greek word.
| comradesmith wrote:
| Always kubernetes, but I've heard some engineers with accents
| say it in a way that sounds like "kubernets"
| ghshephard wrote:
| It's been K - 8 letters - S long enough that everyone at work
| just calls it "Kates" now, which initially annoyed me to no
| end, but has kind of grown on me.
| osigurdson wrote:
| It was never called "Kubernets".
| out-of-ideas wrote:
| > _The Kubernetes way_ to me, this translates into: a really
| complicated mess of manifests of layers-of-layers of fun, but
| hidden in an attempt to make it _easy_ ; but when it does work in
| the simplest forms, it works great.
|
| if any lesson ive learned; let kubernetes manage only things that
| wont shoot yourself in the foot with; you wont know until you try
| :)
| lucgagan wrote:
| That is very cool and much needed, but I am _paranoid_ about
| hosting the data myself. I've lost too many databases over the
| years to the most random mistakes. Granted, technology has
| matured a lot over the last decode, but still... the cost (the
| nights spent debugging and troubleshooting) of maintaining the
| database yourself is just not worth it when managed solutions
| exist.
| berkle4455 wrote:
| I think with any database the solution is simply backups no?
| backups that preferably aren't tied to the hosted solution at
| all.
| panyam wrote:
| Actually not quite. Backups (assuming you are doing single
| node) still needs you to decide on your SLOs - RTO (how long
| it takes to restore) and RPO (how much data lose you can
| suffer) numbers. On the instant snazy end you have streaming
| backups and recovery and then on the other extreme you have
| backup once in N hours/days and restore taking how ever long
| it takes to restore (so you have customer outages you need to
| negotiate.
|
| Now let us involve multi node, (both replication and
| partitioning of shards). As shards go and up and down
| ensuring data is in sync etc is a hard consistency problem
| and needs man years of operational excellence and bug fixing.
|
| So when people think databases - they think of the cool stuff
| - the database engine that does relational algebra and
| handles SQL queries. That is (IMO) only 1% of a practical,
| performant, reliable database (offering).
| tetha wrote:
| Also what about the customer that deleted an important
| thing 6 weeks ago and absolutely needs it recovered? BTW,
| it's just one tentant in that DB, the other shouldn't be
| recovered, naturally.
| smartbit wrote:
| The whole clue of cloudnative-pg is that it makes supporting
| Postgres so much easier. I had no experience with PG at all,
| studied the backup an replication chapters of Simon Riggs book
| [0] and deployed Postgres on Lab, Dev & Prod k8s clusters. Not
| a big use case, 5TB of data, constant stream of IoT type of
| data. Backup to Minio on ZFS. Later we added both a hot-standby
| and a backup replica in a secondary site for disaster recovery.
| No production issue like you describe.
|
| Many EDB & 2nd Quadrant have 10+ years Postgres experience, I
| had the pleasure meeting them at Kubecon EU in Amsterdam,
| friendly Italian & UK Engineers I felt I trust to make good
| software. They saw the issues you described and took a step
| forward by engineering a proper Kubernetes Operator,
| introducing it to the public when it reached version 1.5,
| _after_ they had been running it on their customer DBaaS
| production clusters for some time.
| uneekname wrote:
| Could anyone speak to how this compares to other Postgres
| solutions for Kubernetes?
| rollulus wrote:
| 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.
| nz_cal wrote:
| 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 wrote:
| I appreciate your perspective, thanks. Major version bumps do
| seem to be difficult sometimes with pg in my limited
| experience.
| zinclozenge wrote:
| 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 wrote:
| The rationale is here: https://cloudnative-
| pg.io/documentation/1.20/controller/
| uneekname wrote:
| I found that to be well-written, so another point for
| CloudNativePG
| perrygeo wrote:
| A good comparison with other operators here [2022]:
| https://blog.palark.com/cloudnativepg-and-other-kubernetes-o...
|
| Personally I've only used Kubegres (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.
| sieabahlpark wrote:
| [dead]
| fijiaarone wrote:
| It's the opposite. A Kubernetes solution for Postgres.
| uneekname wrote:
| Haha, that might be a better way of putting it. "A solution
| for running Postgres in Kubernetes"
| rgrieselhuber wrote:
| Is it just me or is the color scheme on this website smoking
| crack?
| pphysch wrote:
| They're mixing white and black text on the same background.
| Mixing muddy red with dark blues. Yeah.
| susam wrote:
| You are probably viewing the dark colour scheme of the website.
| The website looks fine in light colour scheme. However in dark
| colour scheme, while it flips the background and text colour
| alright, it does not alter the accent colours sufficiently
| well.
|
| To see what I mean, compare https://i.imgur.com/hhL0fZH.png
| (dark colour scheme) with https://i.imgur.com/rr24RkN.png
| (light colour scheme).
|
| Consider the colour of the text "Try Kubernetes Way" and the
| background colour. In light mode, we have foreground colour
| #DC2626 on background colour #FFFFFF. This has a contrast ratio
| of 4.82. WCAG 2.0 level AA recommends minimum contrast ratio of
| 3.0 for large text. So a contrast of 4.82 is decent enough.
| However in dark mode, we see #991B1B on #075985 which has a
| contrast ratio of only 1.09. This ratio is too low and fails
| all WCAG contrast requirements.
| osigurdson wrote:
| It definitely looks different.
| [deleted]
| deathanatos wrote:
| Do I need an operator, though?
|
| I'd definitely take something over the insanity that is managed
| services and constant ticket filing with the cloud vendors, but
| my gut says I just need a Helm chart that makes it decently easy
| to, a.) bring up PG & some replicas that hopefully have a decent
| consistency story and b.) a backup job that can write to S3 et
| al.
|
| I need a better "seduce to use" for a CRD for Postgres, I guess.
|
| "It doesn't rely on statefulsets [and manages disks itself]" and
| "The Kubernetes way" (and dark red on blue, yeesh) ... just
| doesn't inspire me?
| fivre wrote:
| CRs that simply instantiate an instance aren't all that useful
| IMO. they're much more useful if you have something like
| Prometheus' case where they want to attach configuration to
| various Kubernetes resources and can't easily fit it in
| annotations.
|
| i don't know that i would actually recommend Helm for much
| though, since dealing with templates beyond a basic "sub string
| into field" use case is pain and misery. once you start dealing
| with named helper templates that operate at different scopes
| and all but the simplest control flow, the lack of tooling
| makes debugging templates a nightmare. the operator ecosystem
| has its own problems (i still can't tell what the extra Red Hat
| stuff beyond kubebuilder is really helping with and can't stand
| updating it), but having an actual programming language and all
| the accompanying type checking and testing tools available is a
| major benefit.
|
| if you don't need something complex, kustomize feels much less
| breakage-prone than Helm, though its patches aren't as
| intuitive to write.
| withinboredom wrote:
| The limitations of helm chart templates are what I like. If
| you code review shenanigans, it should be a code smell that
| you're doing something wrong.
|
| Kustomize is terrible. Trying to build a mental model of the
| final output while writing is horrible.
| cogman10 wrote:
| The place the operator looks to be most useful is updating the
| db. It'll do "the right thing" updating the secondary pods
| first, doing a switch over of the primary, then updating the
| old primary pod.
|
| That sort of action is real hard to do with just a plain helm
| chart (especially if you didn't plan for it up front).
| [deleted]
| yheowahwjsbf wrote:
| _> CloudNativePG does not use `StatefulSet`s for managing data
| persistence_
|
| This is awesome. StatefulSets are an endless source of pain.
___________________________________________________________________
(page generated 2023-09-22 23:00 UTC)