Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Kubernetes rocks, but this post exemplifies a complaint of mine: there's a glaring lack of examples of production-capable database deployments.

In this Helm chart, your master is a single Pod (which is ephemeral and which you should usually not be creating directly) that stores data in an emptyDir (which is coupled to the lifecycle of the Pod).



Check this out:

https://github.com/gravitational/stolon

this is heavily modified version of

https://github.com/sorintlab/stolon

K8s-native deployment of PostgreSQL


Thanks! That was exactly what I was looking for. From a first glance it seems it's well possible to use it with non-k8s environments (like Rancher's Cattle) as well, using Consul and, possibly, a bit of duct tape.

But can you please tell what's the general difference between the original and the fork? I see that both are active, but nothing in README tells what one has over another.


It's a bit of a failure on our (gravitational) side as we are moving fast and haven't submitted PR yet. We will definitely try to merge upstream soon though. We've added several features and changes to the code compared to Simone's version:

  * S3 backup restore feature
  * RPC to communicate with controller over API
  * Refactored client and updated the CLI
  * Updated and slimmed down base images


Exactly. I was expecting use of the new PetSets. I go and look at Helm charts, and most of them are like some toy project setup.


Petsets are alpha quality (lots of bugs and some missing behaviour in 1.3) and will only reach beta in 1.5, which is probably next year. So it wouldn't really be fair to demo something that cannot be used in production.


1.5 is in 3 months :)

But you're right it is alpha, and we would not recommend running production workloads on them.

Disclosure: I work at Google on Kubernetes




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: