Creating a PostgreSQL Cluster Using Helm(blog.kubernetes.io)
blog.kubernetes.io
Creating a PostgreSQL Cluster Using Helm
http://blog.kubernetes.io/2016/09/creating-postgresql-cluster-using-helm.html
38 comments
Check this out:
https://github.com/gravitational/stolon
this is heavily modified version of
https://github.com/sorintlab/stolon
K8s-native deployment of PostgreSQL
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.
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 imagesExactly. 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
But you're right it is alpha, and we would not recommend running production workloads on them.
Disclosure: I work at Google on Kubernetes
I assumed at first this was about the emacs plugin (Google seems to agree that it's quite popular, see pic) and was a bit confused (yet intrigued!).
http://imgur.com/VlXfKoK
https://github.com/emacs-helm/helm
edit: search from incognito window (without my profile's emacs bias): http://imgur.com/QXkBlLq
http://imgur.com/VlXfKoK
https://github.com/emacs-helm/helm
edit: search from incognito window (without my profile's emacs bias): http://imgur.com/QXkBlLq
Same reaction: "I mean, Helm can do anything but this is getting ridiculous."
Yeah the title of the helm readme is "Kubernetes Helm" which would have been more appropriate here. On the kubernetes blog it's implied.
We (https://tech.zalando.com) also made some work to use Helm to deploy Patroni (https://github.com/zalando/patroni), our solution HA PostgreSQL. We have a PR open, if you want to have a look: https://github.com/kubernetes/charts/pull/57 ... comments are always helpful.
Is anyone else very wary about keeping things with persistent state in containers (like databases)?
The persistent state is really just the data, not the process. With kubernetes you store the data on a persistent volume (which could be EBS, iSCSI, etc) and the process runs in the container. Host dies? Kubernetes can re-attach that volume on another host, start up a new container and you are back in business.
*Note: looks like in this example they are not setting up a persistent volume.
*Note: looks like in this example they are not setting up a persistent volume.
> Kubernetes can re-attach that volume on another host, start up a new container and you are back in business.
There are still some bugs with this, particularly on AWS. Getting better with every release, though.
There are still some bugs with this, particularly on AWS. Getting better with every release, though.
We just played with Elastic File System mounted into a Pod via `nfs` and it worked like a charm, with the additional "oh, wow" of being able to attach the same EFS to several Pods at the same time. I was also thrilled that they mounted with the root uid intact so there wasn't any kind of dumb permission juggling.
I did say "played with" because we haven't beat on it to know if one could run Jira, Gitlab, Prometheus, that kind of workload. I wouldn't at this point try Postgres but maybe it'd work.
I did say "played with" because we haven't beat on it to know if one could run Jira, Gitlab, Prometheus, that kind of workload. I wouldn't at this point try Postgres but maybe it'd work.
I wonder how suitable EFS is for Postgres. It's supposedly low-latency, high-throughput and supports Unix locking semantics and so on. On the other hand, it's NFS (one of the worst protocols out there), and there have been reports of less than impressive latencies. EFS is also a lot more expensive than EBS.
EFS is also a lot more expensive than EBS.
That may be true, but getting a k8s cluster unwedged from EBS volume state mismanagement is expensive, too.
What I really want is the hutzpah to run GlusterFS but I am not yet brave enough to be in the keeping-a-production-FS-alive business.
That may be true, but getting a k8s cluster unwedged from EBS volume state mismanagement is expensive, too.
What I really want is the hutzpah to run GlusterFS but I am not yet brave enough to be in the keeping-a-production-FS-alive business.
I use my postgres with EBS though.
Can you elaborate? I run my postgres on k8s with EBS.
Probably the most severe issue: https://github.com/kubernetes/kubernetes/issues/29324. You won't encounter it until a pod is rescheduled, though.
Another strategy is to use https://github.com/wal-e/wal-e to continuously backup and restore from S3 on boot (e.g. https://github.com/deis/postgres). But restores will be slower and it probably doesn't come with strong durability guarantees.
Ideally, yes. It's not actually the case though. Again, ideally.
Well tested databases have evolved to have to survive arbitrary power cuts- even in the middle of a transaction; and so have slowly become reliable enough to trust to start from on-disk state only.
Good f-in' luck bringing your db flavor of the month back online from disk state alone. Hope you didn't have any transactions open to your DB before it got rescheduled to a different node in your cluster.
Well tested databases have evolved to have to survive arbitrary power cuts- even in the middle of a transaction; and so have slowly become reliable enough to trust to start from on-disk state only.
Good f-in' luck bringing your db flavor of the month back online from disk state alone. Hope you didn't have any transactions open to your DB before it got rescheduled to a different node in your cluster.
I work at a shop that has everything in docker containers. We have mostly coreos clusters, but we're slowly moving to mesos/marathon.
And I do mean everything. We've got .NET apps running in docker containers, perl scripts .. they went hard in on docker.
But our databases: Amazon RDS instances.
It's one of the few things that isn't dockerized.
I've personally been looking at a lot of docker solutions for my own projects and I'm still weary of a lot of the data storage solutions out there.
And I do mean everything. We've got .NET apps running in docker containers, perl scripts .. they went hard in on docker.
But our databases: Amazon RDS instances.
It's one of the few things that isn't dockerized.
I've personally been looking at a lot of docker solutions for my own projects and I'm still weary of a lot of the data storage solutions out there.
When I looked at it two months ago, I was having issues getting it to build and deploy on my cluster. After having issues trying to dissect the simple examples, I eventually wrote something similar with python & bash wrapped up in a docker container.
My requirements were deploying 30 different apps using pretty much every kin do k8s objects and deploy custom consul configuration. It could have been done with helm, but the quick and dirty was jinja2 to the rescue.
My requirements were deploying 30 different apps using pretty much every kin do k8s objects and deploy custom consul configuration. It could have been done with helm, but the quick and dirty was jinja2 to the rescue.
This is bad example, because it creates more questions than it answers:
- what if the master pod dies (or I transfer it to another node pool)?
- how do I make sure if everything dies, my data is safe?
- how do I use peristent disks in this scenario?
- how can I have a service that handles both the master and the replicas?
- what happens when I update the node pool to a new version of Kubernetes
- How can I achieve true HA?
- what if the master pod dies (or I transfer it to another node pool)?
- how do I make sure if everything dies, my data is safe?
- how do I use peristent disks in this scenario?
- how can I have a service that handles both the master and the replicas?
- what happens when I update the node pool to a new version of Kubernetes
- How can I achieve true HA?
[deleted]
I am curious why petsets were not mentioned? I was planning to move my postgres to petset. Do you do find running master within single pod enough?
Pet sets aren't really stable yet. Once they are I assume people will start using them for DB masters. http://kubernetes.io/docs/user-guide/petset/#alpha-limitatio...
Alpha quality, not stable, several limitations in current release. Planned for beta in 1.5 (next year, probably).
1.5 is scheduled for early december, according to this: https://github.com/kubernetes/kubernetes/milestones
One more completely custom method of provisioning, rather than using operating system packages and simple shell scripts inside of their preinstall, postinstall, preremove, and postremove sections. How wonderful.
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).