3 ms·

What I find the hardest to figure out is how to properly deploy databases in kubernetes. What kind of volumes should I use and how do I configure them for produ

What I find the hardest to figure out is how to properly deploy databases in kubernetes. What kind of volumes should I use and how do I configure them for production instead of some hello world situation?

djsumdog 8y ago
I think in ever docker ecosystem shop I've worked at, Databases are always on RDS. For large storage, we bought NAS solutions in the local data center. Our DC/OS cluster was primarily for things that didn't need to keep any sort of state. We had a few containers that needed NFS access and that was a lot of special work with the platform team, using labels to pin containers to certain nodes.
afroisalreadyin 8y ago
A database would normally be deployed as a stateful set, with the data stored in a volume, created and maintained by a PVC (persistent volume claim). This mechanism ensures that in the case of your pod dying and getting recreated on a different volume, it would see the same data as before, with the PVC getting mounted on the same pod. This mechanism is still one of the weaker links in the Kubernetes chain, in my experience, as the PVC feature is implemented completely differently on each platform, and is prone to bugs (see https://github.com/kubernetes/kubernetes/issues/60101 https://github.com/kubernetes/kubernetes/issues/60101, from Kubernetes version 1.7 on Azure, for example). Kelsey Hightower himself mentioned in a tweet that he prefers hosted solutions for persistency, and Kubernetes for stateless applications. Also, you should have a look at operators for managing applications on Kubernetes, such as this one for PostgreSQL: https://github.com/zalando-incubator/postgres-operator https://github.com/zalando-incubator/postgres-operator.
threeseed 8y ago
Depends on your database. Some like Cassandra are easier since it is multi-master and so you could just use local storage and if the node goes down then it's not the end of the world. There is an interesting solution for MySQL: https://vitess.io https://vitess.io which apparently is used by Youtube and Slack.

djsumdog 8y ago

I think in ever docker ecosystem shop I've worked at, Databases are always on RDS. For large storage, we bought NAS solutions in the local data center. Our DC/OS cluster was primarily for things that didn't need to keep any sort of state. We had a few containers that needed NFS access and that was a lot of special work with the platform team, using labels to pin containers to certain nodes.

afroisalreadyin 8y ago

A database would normally be deployed as a stateful set, with the data stored in a volume, created and maintained by a PVC (persistent volume claim). This mechanism ensures that in the case of your pod dying and getting recreated on a different volume, it would see the same data as before, with the PVC getting mounted on the same pod. This mechanism is still one of the weaker links in the Kubernetes chain, in my experience, as the PVC feature is implemented completely differently on each platform, and is prone to bugs (see https://github.com/kubernetes/kubernetes/issues/60101 https://github.com/kubernetes/kubernetes/issues/60101, from Kubernetes version 1.7 on Azure, for example). Kelsey Hightower himself mentioned in a tweet that he prefers hosted solutions for persistency, and Kubernetes for stateless applications. Also, you should have a look at operators for managing applications on Kubernetes, such as this one for PostgreSQL: https://github.com/zalando-incubator/postgres-operator https://github.com/zalando-incubator/postgres-operator.

threeseed 8y ago

Depends on your database. Some like Cassandra are easier since it is multi-master and so you could just use local storage and if the node goes down then it's not the end of the world. There is an interesting solution for MySQL: https://vitess.io https://vitess.io which apparently is used by Youtube and Slack.