Show HN: KubeDB – Kubernetes-ready production-grade databases • Hacker News Board

Re: Show HN: KubeDB – Kubernetes-ready production-grade databases

#31

Post by merlinsbrain » Mon, Dec 17, 2018, 9:11 PM UTC

snug wrote: post #25

xena wrote: post #8

On by default analytics makes me not want to touch this, sorry.

+1 I hope this is just pre-release. I imagine once 1.0 it'll be opt-in.

I’ve never understood why people are willing to give all their data to Facebook or any other hosted product which collects data, but are unhappy when open source projects collect anonymized metrics to improve the product.

In this case there’s a flag advertized to turn it off, hopefully someone will be reading the docs before it’s deployed in production?

Do you think AWS and GCP don’t collect metrics?

Happy to hear the other side, my knee-jerk reaction is also usually “you don’t need this data”, but when thinking as an owner, i would find this data invaluable to improve the product, getting funding (please donate, there are X millions of users) etc.

Re: Show HN: KubeDB – Kubernetes-ready production-grade databases

#32

Post by gigatexal » Mon, Dec 17, 2018, 10:31 PM UTC

tamalsaha001 wrote: post #28

gigatexal wrote: post #18

No MySQL clustering means no adoption from me for now.

I understand. This is one of primary feature we targeting to suppose in the next quarter. Can you tell me what type of clustering support do you use? Example: Percona, Galera cluster, Vitess ?

Hah if you can make vitess not a terrible experience that would be awesome.

But just Percona clustering would do.

Re: Show HN: KubeDB – Kubernetes-ready production-grade databases

#33

Post by gigatexal » Mon, Dec 17, 2018, 10:31 PM UTC

tamalsaha001 wrote: post #29

gigatexal wrote: post #9

Can TLS encryption be used here and does it support encrypting the storage?

Are you talking about TLS encryption for connection url? If so, it is supported for Elasticseach. The others ones are not there yet. Though it might be possible using the available configuration options. We are also looking to modifying the snapshot option to store encrypted snapshots in future releases.

That and also mTLS for data in flight.

Re: Show HN: KubeDB – Kubernetes-ready production-grade databases

#34

Post by alexnewman » Tue, Dec 18, 2018, 4:16 AM UTC

Is this production worthy?

Re: Show HN: KubeDB – Kubernetes-ready production-grade databases

#35

Post by tie_ » Tue, Dec 18, 2018, 7:55 PM UTC

Kudos for the interesting approach! I do think that DB management on Kubernetes belongs to operators, and maintaining a collection of them would be great.

This being said, you should not be using TPR, but rather CRDs (see https://coreos.com/blog/custom-resource-kubernetes-v17). The welcome video is not really convincing either - condensing it to an animated gif would make it much more attractive imho.

Re: Show HN: KubeDB – Kubernetes-ready production-grade databases

#36

Post by manigandham » Sun, Dec 30, 2018, 3:54 PM UTC

noahdesu wrote: post #4

This seems to serve a purpose similar to Rook [0] for deploying distributed (or non-distributed) storage systems, including database. For example, Rook can deploy CockroachDB and also Ceph, which would have a lot of the same challenges as deploying some of the databases supported by KubeDB. [0]: https://rook.io disclaimer: red hat employee working some on rook.

Rook stretching to databases looks like a random tangent trying to do everything at once. The project should focus on being a solid distributed storage provider first and let users run databases themselves on those volumes. It's especially strange since these databases already have their own storage replication and would be duplicating work.