PostgreSQL: Kubegres is available as open source(postgresql.org)
postgresql.org
PostgreSQL: Kubegres is available as open source
https://www.postgresql.org/about/news/kubegres-is-available-as-open-source-2197/
27 comments
Since this is just a PR announcement by a third-party posted on an official PostgreSQL page: what is the difference between this and established PostgreSQL operators by Zalando and CrunchyData?
I was wondering this too and found: https://www.kubegres.io/#kubegres_compared
It seems like the big difference is that it uses the standard PostgreSQL Docker images and doesn't bundle together as many things as Zalando or Crunchy Data. They'd likely argue that makes it easier to learn and a smaller surface area for attacks or things to go wrong.
Crunchy Data includes lots of add-ons like pgBouncer, pgAdmin 4, pgMonitor, and a bunch more. That might be a lot for someone that just wants a simple replicated PostgreSQL setup.
But I don't know much about Kubegress. It's repository has only 67 commits and 3 contributors so it's not as widely used as something like Crunchy Data or Zalando which have thousands of commits and hundreds of contributors. Likewise, Crunchy Data and Zalando both have 2,000+ stars compared to 387 for Kubegress.
That's not necessarily a sign of quality and part of that could be that Kubegress had a bunch of development before being open-sourced, that being later to the game makes it harder to build community, and that creating something simple might not require as many commits since you're creating something simple.
It seems like the big difference is that it uses the standard PostgreSQL Docker images and doesn't bundle together as many things as Zalando or Crunchy Data. They'd likely argue that makes it easier to learn and a smaller surface area for attacks or things to go wrong.
Crunchy Data includes lots of add-ons like pgBouncer, pgAdmin 4, pgMonitor, and a bunch more. That might be a lot for someone that just wants a simple replicated PostgreSQL setup.
But I don't know much about Kubegress. It's repository has only 67 commits and 3 contributors so it's not as widely used as something like Crunchy Data or Zalando which have thousands of commits and hundreds of contributors. Likewise, Crunchy Data and Zalando both have 2,000+ stars compared to 387 for Kubegress.
That's not necessarily a sign of quality and part of that could be that Kubegress had a bunch of development before being open-sourced, that being later to the game makes it harder to build community, and that creating something simple might not require as many commits since you're creating something simple.
Then again you don't need a whole lot to have those features coupled with k8s. Kiss solution.
[deleted]
I love this sort of thing. Something I appreciate is looking through the resulting YAML config at the best practices and rich experience by the team that wrote it.
It reminds me of receiving "golden images" from vendors with a precisely best-practice install and configuration of their software.
It reminds me of receiving "golden images" from vendors with a precisely best-practice install and configuration of their software.
I've interacted with the kubegres creator and maintainer in the past and it was a good experience, wishing them luck giving Zalando and Crunchy operators a run for their money.
See https://www.reddit.com/r/PostgreSQL/comments/mqrsbn/kubegres...
See https://www.reddit.com/r/PostgreSQL/comments/mqrsbn/kubegres...
generally hope 'self hosting your DB' becomes a spectrum rather than a choice to use or not use RDS
it's frustrating that you can't use something like timescaledb on a paas (i.e. that timescale needs to manage their own instances to operate their business).
not sure kube is the cheapest or safest way to run a DB, but there should be something platform-like for hosting persistent data
it's frustrating that you can't use something like timescaledb on a paas (i.e. that timescale needs to manage their own instances to operate their business).
not sure kube is the cheapest or safest way to run a DB, but there should be something platform-like for hosting persistent data
Any comparison with the other solutions? (e.g. the ones from https://blog.flant.com/comparing-kubernetes-operators-for-po...)
Does Kubegres works with any TCP proxy, and if does - is there any recommendations which one?
Running ingress via Load Balancer is quite costly option in cloud context. At the moment is seems that nodeport is only realistic alternative.
I wonder how is this compared to Stolon https://github.com/sorintlab/stolon?
Where I can read how modern k8s deals with persistent storage? It looks like after pg cluster shutdown you lose all data.
https://kubernetes.io/docs/concepts/storage/persistent-volum...
I use https://rook.io/ to set storage up usually, they have a bunch of different options and good documentation.
I use https://rook.io/ to set storage up usually, they have a bunch of different options and good documentation.
From what I understand, you still have to solve the usual hard challenges of HA:
1) Applications reconnecting to the new Postgres master and retrying queries
2) Persistent storage available in multiple AZs or regions for your Postgres pods (impossible on AWS for example)
1) Applications reconnecting to the new Postgres master and retrying queries
2) Persistent storage available in multiple AZs or regions for your Postgres pods (impossible on AWS for example)
How does this compare to cockroach?
So I can create 2 servers running kubegres, kill one and then all data should be intact? And no downtime?
These things aren't magical. You will have some downtime because your connection to the database will be interrupted (after all, it just died, no way around it), and depending on your configuration, you may lose some data; you need at least one synchronous replica to ensure that no data is lost on an uncontrolled failover. If you have a two-node "cluster" with synchronous replication, then either one going down will stop writes on the master, so you would need at least three nodes.
Mind you, no clustered system can provide you zero downtime and zero data loss without essentially the same constraints. If you have an unplanned failure, there's going to be a blip somewhere. It's up to the rest of the system to recover from it gracefully.
When configuring any kind of cluster involving data (especially one that's supposed to recover automatically from faults), make sure you understand how it behaves and adjust for your application, because quite often the default configurations might accept some data loss in unplanned failover or conflict scenarios.
Mind you, no clustered system can provide you zero downtime and zero data loss without essentially the same constraints. If you have an unplanned failure, there's going to be a blip somewhere. It's up to the rest of the system to recover from it gracefully.
When configuring any kind of cluster involving data (especially one that's supposed to recover automatically from faults), make sure you understand how it behaves and adjust for your application, because quite often the default configurations might accept some data loss in unplanned failover or conflict scenarios.
will probably lose some data but easy enough to test with this thing
Is it logical for AWS to offer RDS over K8s?
Logical for AWS or logical for their customers? Frankly probably not either way. RDS excels due to it deep integration with AWS proprietory block store. If you want your data in PVs RDS dose not offer enough, if you want you data on RDS then K8S scheduling wouldn't add much.
they already do in a way through aws-service-operator and replacement aws controllers for kubernetes (ACK)
https://aws.amazon.com/blogs/opensource/aws-service-operator... https://github.com/aws-controllers-k8s/community
https://aws.amazon.com/blogs/opensource/aws-service-operator... https://github.com/aws-controllers-k8s/community
The ACK operator runs in k8s, but I'm pretty sure RDS instances created via ACK will still run natively in AWS.
ACK is a just a k8s native mechanism for defining the resource and managing its config/state.
More a replacement for Cloudformation or terraform.
Source: I read some stuff and am not 100% confident.
ACK is a just a k8s native mechanism for defining the resource and managing its config/state.
More a replacement for Cloudformation or terraform.
Source: I read some stuff and am not 100% confident.